doc001
doc001
如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法
基于 rocksdb 的 snaposhot load 一般不需要做什么事情，snapshot save 可以只写记录一个伪文件名，snapshot_file，add 进 snapshot 的 file 列表即可。拖取数据的时候会稍微复杂一些。需要自己定义一个 FileSystemAdaptor 实例，在 open 的时候识别 snapshot_file 文件，然后构造自定义的 FileAdaptor，对于 leader，raft 会调用的 read 接口，raft对于 follower 会调用 write 的接口，至于这个伪文件的实际数据，业务可以自行解释。
> > 如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法 > > tidb单个tikv实例能够支持几十万的raft复制组，如果braft也搞几十万的raft复制组，写log预计会有性能问题，因为braft是每个复制组一个日志文件，会出现大量的随机读写。这块有什么规划吗? 用户是可以自己定制 log storage 的，只要满足必须的接口即可，多路日志合并到一路 segment log 是可行的，内部确实有业务已经这么做了。不过，目前内部的这些相关实现在都与业务耦合比较深，暂时还没有做一个通用功能的规划。 另外，几十万个 raft 复制组在一个单机上不是一个理想的部署方式，因为，如果不支持心跳合并，光心跳压力就会很高。
> > > > 如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法 > > > > > > > > > tidb单个tikv实例能够支持几十万的raft复制组，如果braft也搞几十万的raft复制组，写log预计会有性能问题，因为braft是每个复制组一个日志文件，会出现大量的随机读写。这块有什么规划吗? > > > > > > 用户是可以自己定制 log storage 的，只要满足必须的接口即可，多路日志合并到一路 segment log 是可行的，内部确实有业务已经这么做了。不过，目前内部的这些相关实现在都与业务耦合比较深，暂时还没有做一个通用功能的规划。...
这个braft代码不会自动处理，业务可以通过shutdown重新start来恢复，这个效果和重启是一样的
> Replace `include(FindProtobuf)` with "manual detection" of protobuffer because: > > 1. We can make the names of dependencies consistent in a form of > `XXX_INCLUDE_PATH` and `XXX_LIB`. > Before...
If can_linearizable_read return false, what should the caller do?
I don't know if it's necessary to provide such an interface or mechanism. A log become committed log doesn't mean that the state change is visible to clients. Only after...
Ok, it's implementation related issue. I suggest don't provide a function called can_linearizable_read(), this may make people using other implementation confused. Instead, provide a simple function to get last_applied_index. Another...