Skip to content

Conversation

@Little-Wallace
Copy link

Problem

If we build a raft group based on RocksDB, we hope the data of raft can be applied in order of raft-log-index. But it will be slowly if there are a lot of entries waiting to be applied, one thread can not consume them as soon as possible.

And for TiKV batch-system, we hope to process data from different regions in a first-come, first-served manner. This also need to guarantee the order of entries consumed in different thread.

Solution

We hope we can write these keys in parallel by multiple thread. We only need to guarantee that one entry must start writing operation after theses entries whose log-index are less than it. We will use a atomic applied index to decide whether one entry is writing to db.

let mut wb = db.new_write_batch();
let mut starting = vec![];
while let Some(m) = receiver.try_recv() {
      let region = globalRegionMap.get(m.get_region_id());
      if region.last_applying_index.load(Odering::Acquire) + 1 == m.get_first_log_index() {
           starting.push((region.last_applying_index.clone(), m.get_last_log_index()));
           for (k,v) in m.kvs() {
                wb.put(m);
           }
      } else {
           region.restore_entries(m);
      }
}
db.prepare(&wb);
for (k,v) in starting {
     k.store(v, Ordering::release);
}
db.submit(&wb);

@Little-Wallace Little-Wallace changed the title [WIP] Split Write operation into two phase. [WIP] Split Write operation for raft-concurrent-apply Oct 19, 2021
Signed-off-by: Little-Wallace <[email protected]>
@Little-Wallace
Copy link
Author

/test

Signed-off-by: Little-Wallace <[email protected]>
Signed-off-by: Little-Wallace <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant