如果业务应用层数据特别大，是不是有明显的读写性能问题？

[shenyuhit]

场景：braft server 有3台，用来做一致性存储使用，比如底层是leveldb，有几个疑惑的问题 0、加入每次写操作都是2K的数据，那每一次log里面就需要有2K+logmeta的数据？ 1、如果应用数据特别大，并且用户量比较大，假如有100W个用户，每个用户数据2K，那么每次 snapshot 的时候就是2G的数据？这个时候必然很慢或者卡住 2、是不是每台节点上都会有自己的leveldb文件？ 但是各自管理自己的读写？ 3、如果有一个全新的节点上来？installSnapshot 需要把全量数据推过去？ 那这个启动的过程可能会异常的慢？

[PFZheng]

0. 嗯，压缩算法可能让数据更小，但是基本原理是这样的。主要是 raft 写下去的日志在 commit 前可能会被 truncate，从正确性的角度，这一步不能省略。leveldb自己的log选项可以根据需要进行调节，保证snapshot的点持久化即可，然后通过日志回放来保证数据正确性
1. 基于 leveldb/rocksdb 的 snapshot 可以做到什么都不做，只生成一个文件列表（这个文件列表不需要是真实存在的文件，怎么解释业务自己决定，通过 snapshot file system adaptor 来 hook 读写过程即可），拖snapshot的时候拖取更新的版本的数据。靠日志回放来保证最终的正确性
2. 每个节点单独维护
3. 需要拖取全量数据，启动过程代价和 snapshot load 是一样的

[PFZheng]

如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法

[shenyuhit]

3. 需要拖取全量数据，启动过程代价和 snapshot load 是一样的

这一点，新的节点启动的时候，假如我本机有10G的leveldb文件数据？ 这10G的文件 同步到新节点的机器上 是braft 自动控制的？ 还是我需要实现 哪些接口？ example 里面的例子我没有看到这一块的逻辑怎么处理~

[PFZheng]

基于 rocksdb 的 snaposhot load 一般不需要做什么事情，snapshot save 可以只写记录一个伪文件名，snapshot_file，add 进 snapshot 的 file 列表即可。拖取数据的时候会稍微复杂一些。需要自己定义一个 FileSystemAdaptor 实例，在 open 的时候识别 snapshot_file 文件，然后构造自定义的 FileAdaptor，对于 leader，raft 会调用的 read 接口，raft对于 follower 会调用 write 的接口，至于这个伪文件的实际数据，业务可以自行解释。

[zhongleihe]

如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法

tidb单个tikv实例能够支持几十万的raft复制组，如果braft也搞几十万的raft复制组，写log预计会有性能问题，因为braft是每个复制组一个日志文件，会出现大量的随机读写。这块有什么规划吗?

[PFZheng]

如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法

tidb单个tikv实例能够支持几十万的raft复制组，如果braft也搞几十万的raft复制组，写log预计会有性能问题，因为braft是每个复制组一个日志文件，会出现大量的随机读写。这块有什么规划吗?

用户是可以自己定制 log storage 的，只要满足必须的接口即可，多路日志合并到一路 segment log 是可行的，内部确实有业务已经这么做了。不过，目前内部的这些相关实现在都与业务耦合比较深，暂时还没有做一个通用功能的规划。 另外，几十万个 raft 复制组在一个单机上不是一个理想的部署方式，因为，如果不支持心跳合并，光心跳压力就会很高。

[zhongleihe]

如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法

tidb单个tikv实例能够支持几十万的raft复制组，如果braft也搞几十万的raft复制组，写log预计会有性能问题，因为braft是每个复制组一个日志文件，会出现大量的随机读写。这块有什么规划吗?

用户是可以自己定制 log storage 的，只要满足必须的接口即可，多路日志合并到一路 segment log 是可行的，内部确实有业务已经这么做了。不过，目前内部的这些相关实现在都与业务耦合比较深，暂时还没有做一个通用功能的规划。 另外，几十万个 raft 复制组在一个单机上不是一个理想的部署方式，因为，如果不支持心跳合并，光心跳压力就会很高。

几十万只是个极限情况，一般情况在千级别。其实我们正在在braft基础上把segment log合并到一路，目前已经可以跑完单元测试，正在做性能测试。请问你们有微信交流群或者其他类型的群吗？可以方便交流

[PFZheng]

如果数据量很大/请求压力的话，单个raft复制组无法搞定的话，需要业务自己去做shard的逻辑，把数据打散到不同的raft复制组，可以参照 tidb 的做法

tidb单个tikv实例能够支持几十万的raft复制组，如果braft也搞几十万的raft复制组，写log预计会有性能问题，因为braft是每个复制组一个日志文件，会出现大量的随机读写。这块有什么规划吗?

用户是可以自己定制 log storage 的，只要满足必须的接口即可，多路日志合并到一路 segment log 是可行的，内部确实有业务已经这么做了。不过，目前内部的这些相关实现在都与业务耦合比较深，暂时还没有做一个通用功能的规划。 另外，几十万个 raft 复制组在一个单机上不是一个理想的部署方式，因为，如果不支持心跳合并，光心跳压力就会很高。

几十万只是个极限情况，一般情况在千级别。其实我们正在在braft基础上把segment log合并到一路，目前已经可以跑完单元测试，正在做性能测试。请问你们有微信交流群或者其他类型的群吗？可以方便交流

暂时没有微信群。欢迎贡献 patch～ 这里一路 segment log 不见得是性能最好的，可以对比下打散到若干路的日志上。

[zergvszerg]

请问有计划实现合并心跳吗？