个人觉得完美的raft工具

[zxuanhong]

Your question

1. 集群成员关系通过swim等协议确定(针对大规模集群，心跳性能太差)，或者说提供非心跳的成员确定方案。
2. 每个节点保存集群元数据(方便节点重启后重新加载相关配置)，元数据通过gossip协议扩散到整个集群，以便确保集群元数据每个节点一致。
3. 集群通过gossip协议确定整个集群唯一调度员(管理集群，对集群分区进行调度)

所以完美的raft不是单一协议，而是多协议配合。能生产直接简单配置就能使用。而不需要再去搞一套配置管理等等基本每个使用者都会去处理的东西(如果基本都需要去处理那还不如直接弄好)

[shihuili1218]

swim在大规模集群消耗是巨大的，另外raft心跳信息会携带lastcommitted，才能使得raft能“一阶段”达成共识。使用swim完全不符合raft理念。

使用gossip能将数据扩散到整个集群，但是最终仍然要收敛到leader来确认是否达成共识，那么收敛时间(达成共识时间)将无限期推延

[zxuanhong]

gossip仅仅用来向整个集群扩展节点信息。方便进行raft分区调度。而不是还要再客户在封装一层。心跳在大规模集群消耗才巨大吧？？？？

我认为，应该先有集群成员资源信息，，然后利用集群成员资源来构建raft。而不是每个raft启动时就干死。 我个人比较喜欢atomix的构建方式，他是先有一个集群资源(利用消息系统，也就是最所有的协议，交互都在这个集群消息系统上去处理)，然后再集群资源的基础上去选择其中一些成员来构建raft 分区

总体而言，我不认为一个能生产应用的raft协议，仅仅只是为了完成raft协议。而应该有一定管理能力。而不是每个人拿到了都去处理一遍。

[killme2008]

有 n 种手段去做个集群信息的广播。

jraft 定位还是一个算法类库，没准备做成框架。所以这个讨论可以结束了。按你的场景选择合适的就好了。

[zxuanhong]

目前要实现动态调度，必须得知道整个集群有哪些节点信息，然后才知道怎么去动态调度。怎么去管理。或者说那些节点分配的分区过多，那些多少。而且进行动态调度后怎么重启才能保持之前的raft分区然后重新加载，这些都是需要有个集群管理信息才能去很好的处理。

然而既然是集群了，raft也是为集群而生。那为啥关键的部分却是缺少的了？？？？让每个用户都去构建或者做一套？？？。我认为是为应用而生，jraft不应该为论文而生。这显得非常死板。

[killme2008]

回到问题上来。集群信息提供了管理工具

CliService

文档 https://www.sofastack.tech/projects/sofa-jraft/jraft-user-guide/

4.2 CLI 服务。

比较遗憾，这个文档比较挫，没办法锚点跳转，请搜索。

[killme2008]

@fengjiachun 这文档也不复杂，就一个markdown，感觉可以考虑维护到仓库里来，那个网站链接真的相当挫，锚点都不行。

[killme2008]

@zxuanhong 理论上讲，你是可以一开始分配几个节点（甚至一个节点也可以），作为 init configuration 来构建起一个 raft group。后续的管理都可以通过这个 cli 工具，这也是相对推荐的方式。

[zxuanhong]

@killme2008 个人认为，对raft集群动态管理，raft分区动态管理，我相信90%使用者非常愿意看到官方提供对应的案例。 同时我感觉对你们而言应该很简单，那能否提供一个案例了。 kv哪个我感觉太复杂了(成员动态管理好像也不行，为了能动态管理还得创建一个pd集群)。 仅仅是提供一个扩展案例，这不违法jraft作为一个算法的基本准则吧。而且又是金融级别的raft工具，我相信你们应该自己实现过吧！！！

落地、应用才是检验一切的真理。非常希望官方能提供一个案例。我很坚信90%的人很乐意看到有这样的案例。

1. 比如节点动态增减后(这里的节点是计算机节点)能感知集群成员信息然后进行对应raft分区调度与创建。
2. 集群重启后还能恢复动态加入的节点(非初始节点，初始节点我更愿意理解为集群引导节点，也就是种子节点)以及动态创建的分区
3. 能对分区进行动态增减，而不是直接调用jraft工具传入对应分区的参与者，应该利用现有节点信息自动创建分区参与者(不需要指定分区参与者，比如副本设置为3，那么自动创建包含有三个参与者的raft分区)

等等。。。