所以，首先，抱歉我的英语 . 我不是母语人士 .
问题是..我已经使用Thrift实现了一个带有分布式数据（3台服务器）的Cliente-Server应用程序 . 现在（项目的最后阶段）是使用Raft的一些实现（因为Im使用Java，一个选项是copycat）来复制每个服务器 . 但是Thrift以他的方式创建了服务器和客户端（像Grafosd.Client客户端=新...）和Grafosd由Thrift生成 . 另外，Thrift将数据存储在Handler？中 . 而copycat以不同的方式创建服务器和客户端（类似于CopycatClient client = builder.build（）;） . 并且数据存储在StateMachine中？
所以我很难整合两者 . 有人已经使用Thrift Client-Server和Raft协议的一些实现？ （没有必要的copycat，它可以是Java中任何Raft的实现） .
2 回答
首先，您必须问自己为什么项目的第二阶段使用一致性算法？该项目是否需要强一致性？您是否考虑过其他复制协议（八卦，主要备份等）
无论您使用哪种Raft实现，大多数实现在系统中建模状态的方式都是状态机 . 对系统状态的更改必须通过Raft协议传递给领导者并复制到关注者，如果要保留一致性/容错保证，系统状态的查询也必须通过协议 .
如果要在服务器中嵌入Copycat，只需使用
LocalTransport，它允许您与进程内服务器通信 .CopycatServer并不是完全现实和合理的，可以在您的Thrift服务器中嵌入Copycat客户端和服务器 . 在Thrift服务器中，创建一个CopycatServer，其中包含可以表示系统状态更改的状态机，以及使用LocalTransport与本地服务器通信的CopycatClient.您还可以考虑使用Atomix，其中
AtomixReplica为您处理此本地客户端/服务器嵌入模式 . 它还包括大量示例状态机和客户端API .但正如我所说，无论您使用Copycat / Atomix还是其他Raft实现，您仍然需要以相同的方式对状态更改进行建模 . 必须将对系统状态的每次更改提交给Raft领导者，并将其记录并复制到关注者并应用于状态机 . 状态机复制模型非常适合有状态系统 . 存储大量状态或需要在外部数据库中存储状态的系统的替代方案是持久状态机 . 我发现这是许多用户在Raft中寻找的东西 . 但是你必须要小心如何在Raft集群中实现持久状态机，否则你将冒着重复写入的风险 .
不过，您应首先确定是否需要像Raft这样的复杂协议来解决您要解决的问题 . 首先回答问题是什么，以及复制协议需要什么 . 你需要分区容差吗？你需要强大的一致性吗？你需要高可用性吗？吞吐量要求是否排除使用基于领导者的协议？为什么不写入任何复制的外部数据库？
我是Copycat和Atomix的作者 . 当您回答其中一些问题并确定这是否确实是正确的方向时，请随时加入我们的聊天 .
对我的问题提出一些更普遍的评论：
Thrift本身（仅）使用的序列化和RPC机制 . 更复杂的协议或API通常是在Thrift之上设计的，使用Thrift - 但不是在Thrift内部 . 这就像使用汽车将材料运输到建筑工地 . 决定建筑的不是汽车 . 汽车只是完成工作的手段 .
在这方面，Thrift（或任何其他类似机制）只是该背景下的工具 . 我建议首先让它在心理上清楚，哪一块拼图属于哪里可以充分利用你的系统设计 .
我建议永远做处理者无国籍 . 如果你需要一个州，那很好，但把它存放在其他地方 . 节俭本身没有任何东西 . 这是处理器实现，它可能需要存储状态或其他信息的服务器端开发人员 .