braft
braft copied to clipboard
baidu
有对线性一致性读的支持吗
配置文件里加上： --raft_enable_leader_lease=true 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读
配置文件里加上： --raft_enable_leader_lease=true 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读
leader apply比较快，而follower apply慢，但某个点follower当选了leader，只依赖leader的判断这个时候不能直接读吧？
配置文件里加上： --raft_enable_leader_lease=true 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读
leader apply比较快，而follower apply慢，但某个点follower当选了leader，只依赖leader的判断这个时候不能直接读吧？
braft里保证了这个事情。这个lease的有效时间是从on_leader_start开始的，也就是所有的已commit数据已经全部apply完了
配置文件里加上： --raft_enable_leader_lease=true 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读
leader apply比较快，而follower apply慢，但某个点follower当选了leader，只依赖leader的判断这个时候不能直接读吧？
braft里保证了这个事情。这个lease的有效时间是从on_leader_start开始的，也就是所有的已commit数据已经全部apply完了
但是似乎只能保证线性读，不能保证在一个node上读写是否并发是吧？对于写操作的话由于apply的时候是顺序的不会有并发问题。
配置文件里加上： --raft_enable_leader_lease=true 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读
leader apply比较快，而follower apply慢，但某个点follower当选了leader，只依赖leader的判断这个时候不能直接读吧？
braft里保证了这个事情。这个lease的有效时间是从on_leader_start开始的，也就是所有的已commit数据已经全部apply完了
但是似乎只能保证线性读，不能保证在一个node上读写是否并发是吧？对于写操作的话由于apply的时候是顺序的不会有并发问题。
不知道你所指的是哪个case，可以举个例子吗？
但是似乎只能保证线性读，不能保证在一个node上读写是否并发是吧？对于写操作的话由于apply的时候是顺序的不会有并发问题。
不知道你所指的是哪个case，可以举个例子吗？
感谢回复，我的意思是，开启了raft_enable_leader_lease之后，某次读操作和正在进行的写操作之间是无序执行的吧？这样对于数据结构来说要处理并发访问的问题，而如果只有写操作的话，由于写操作在进行apply的时候是串行进行的，并不需要考虑并发问题。
要是开启了raft_enable_leader_lease之后，可以提交一个请求，该请求只到各节点确认leader lease而不记录日志，但是确认之后依然可以由on_apply来通知调用者这次读是lease valid的就好了，这样整个node上不论读还是写都是串行执行的，不需要考虑并发问题。
但是似乎只能保证线性读，不能保证在一个node上读写是否并发是吧？对于写操作的话由于apply的时候是顺序的不会有并发问题。
不知道你所指的是哪个case，可以举个例子吗？
感谢回复，我的意思是，开启了raft_enable_leader_lease之后，某次读操作和正在进行的写操作之间是无序执行的吧？这样对于数据结构来说要处理并发访问的问题，而如果只有写操作的话，由于写操作在进行apply的时候是串行进行的，并不需要考虑并发问题。
要是开启了raft_enable_leader_lease之后，可以提交一个请求，该请求只到各节点确认leader lease而不记录日志，但是确认之后依然可以由on_apply来通知调用者这次读是lease valid的就好了，这样整个node上不论读还是写都是串行执行的，不需要考虑并发问题。
这里其实和业务有关系，正常情况下，并发的没完成的写，读到新数据或者旧数据都是可以的，只需要保证不回退即可。
至于你说的这个，有一个简单的实现方式，可以开放 fsmcaller 的execution queue接口出来，允许用户提交task进去，由于brpc的execution queue是串行的，on_apply也是在这里执行的，可以满足你的这个需求
这里其实和业务有关系，正常情况下，并发的没完成的写，读到新数据或者旧数据都是可以的，只需要保证不回退即可。
是的，这个业务倒是ok的，主要是不想让代码中为此维护一些互斥锁之类的。
至于你说的这个，有一个简单的实现方式，可以开放 fsmcaller 的execution queue接口出来，允许用户提交task进去，由于brpc的execution queue是串行的，on_apply也是在这里执行的，可以满足你的这个需求
OK，我觉得这个倒是一个不错的方案，可以看下改造难度，感谢。
有考虑支持ReadIndex来保证线性一致性读吗？考虑到节点时钟问题，lease read不是完全可靠
目前没有这个计划，ReadIndex 的性能是相对较差的，一个粗糙的模拟是每次读之前append一条log，在log的回调里读。另外 lease 并没有依赖绝对时钟，节点上时间流逝速度接近的话问题不大（从心跳时刻开始的流逝速度）。
有考虑支持ReadIndex来保证线性一致性读吗？考虑到节点时钟问题，lease read不是完全可靠
目前没有这个计划，ReadIndex 的性能是相对较差的，一个粗糙的模拟是每次读之前append一条log，在log的回调里读。另外 lease 并没有依赖绝对时钟，节点上时间流逝速度接近的话问题不大（从心跳时刻开始的流逝速度）。
@PFZheng 如果每次读都append log就代价太大了。lease主要还是怕时钟skew吧，有的机器快，有的机器慢，这样其实pre-vote+leadership expiration应该可以解决？
有考虑支持ReadIndex来保证线性一致性读吗？考虑到节点时钟问题，lease read不是完全可靠
目前没有这个计划，ReadIndex 的性能是相对较差的，一个粗糙的模拟是每次读之前append一条log，在log的回调里读。另外 lease 并没有依赖绝对时钟，节点上时间流逝速度接近的话问题不大（从心跳时刻开始的流逝速度）。
@PFZheng 如果每次读都append log就代价太大了。lease主要还是怕时钟skew吧，有的机器快，有的机器慢，这样其实pre-vote+leadership expiration应该可以解决？
lease 看的是 lease 期间同机器上的相对时间，短时间的skew不会很大，这个已经考虑在内了