question about unique id for log entry! about raft HOT 10 CLOSED

Yes you can. May I ask what you need the unique ID for? Just because it feels a bit of a smell that you're going to be using the log index.

from raft.

I plan to use it as cache version number.

For example If client read a value by key from non-leader/leader/standby node, there is a version number return with it.

When I commit the cache update operate on leader node(the key/value and version number submit by client), I will compare the version number. If the version number is less than leader local value, then the action will be rejected.

from raft.

There are cases where an entry is added to the log, but not committed, in that case the entry could be overwritten at the same position by another entry and the id will no longer be unique. The id will be unique once the entry is committed.

from raft.

Thanks for the explain.

Now I think I can safely send unique id to client after apply_callback get fired.

I also want to use non-leader/standby node response for readonly query, And I think apply_callback only called from leader node (because only leader submit raft_apply request) ?

Is there a callback get fired when non-leader is confirmed when a entry is committed? And I am not sure in witch step the entry get apply to non-leader FSM.

from raft.

Right, lile @MathieuBordere says, it's safe to assume the log index ID will be unique when you apply the entry to your FSM (i.e. when the entry is committed and the apply callback is fired).

Since in Raft read-only queries non non-leader nodes are meant to still read only committed entries that were already applied to the local FSM, then the above assumption still holds and your ID will be unique. The point though is that even if you are reading a committed value, if the node is not the leader there's no guarantee that it is the latest value (e.g. another value might have been committed in the meantime and still has to reach that particular node). Normally in Raft a node (either leader or non-leader) should never serve to the client data from uncommitted entries, also because those were not yet applied to the FSM and so in general it's not easy to figure out what the application state should be (I can elaborate on this last remark if it's not clear, but I guess what I said earlier is enough).

from raft.

Thanks for the explain.

For non-leader node, FSM->apply get called mean the log entry is committed. (I guess this mean most of node already store this value and it will never get lost).

Only the leader can update the key's value with raft_apply, if leader check the value submit by client don't have the version match leader's FSM version with same key, he know the client submit a request with expired input arguments, then will reject the request and client will get the new value from leader and submit a new request into leader.

I guess this is safe and avoid one RTT if there is no other client update the same key.

from raft.

I ask this question is want to be sure: If client get key/value/version from non-leader FSM, they can safely submit to leader late and leader will make sure it only update the value that client want to modify is fresh.

from raft.

Thanks for the explain.

For non-leader node, FSM->apply get called mean the log entry is committed. (I guess this mean most of node already store this value and it will never get lost).

Correct.

Only the leader can update the key's value with raft_apply, if leader check the value submit by client don't have the version match leader's FSM version with same key, he know the client submit a request with expired input arguments, then will reject the request and client will get the new value from leader and submit a new request into leader.

I guess this is safe and avoid one RTT if there is no other client update the same key.

Yes, that sounds safe.

from raft.

I ask this question is want to be sure: If client get key/value/version from non-leader FSM, they can safely submit to leader late and leader will make sure it only update the value that client want to modify is fresh.

Yes, if the client gets the value from a non-leader node using a read-only request, then when it tries to update the value the leader can reject the request if the ID is out of date.

from raft.

thanks for the explain!

from raft.