使用Raft协议集成分布式数据系统（客户端，服务器）的thrift实现

Question

所以，首先，抱歉我的英语。我不是母语人士。

问题是..我已经使用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的实现）。

Answer 1

首先，你必须问问自己为什么你的项目的第二阶段使用一致性算法？该项目是否需要强一致性？您是否考虑过其他复制协议（八卦，主要备份等）

无论您使用哪种Raft实现，大多数实现在系统中建模状态的方式都是状态机。对系统状态的更改必须通过Raft协议传递给领导者并复制到关注者，如果要保持一致性/容错保证，对系统状态的查询也必须通过协议。

如果要在服务器中嵌入Copycat，只需使用LocalTransport，它允许您与进程内服务器通信。 CopycatServer不必在远程计算机上运行。在您的Thrift服务器中嵌入Copycat客户端和服务器是完全现实和理性的。在Thrift服务器中，创建一个CopycatServer，其中包含可以表示系统状态更改的状态机，以及使用CopycatClient与本地服务器通信的LocalTransport。

您也可以考虑使用Atomix，其中AtomixReplica为您处理此本地客户端/服务器嵌入模式。它还包括大量示例状态机和客户端API。

但正如我所说，无论您使用的是Copycat / Atomix还是其他Raft实现，您仍然需要以相同的方式对状态更改进行建模。必须将对系统状态的每次更改提交给Raft领导者，然后将其记录并复制到关注者并应用于状态机。状态机复制模型非常适合有状态系统。存储大量状态或需要在外部数据库中存储状态的系统的替代方案是持久状态机。我发现这是许多用户在Raft中寻找的东西。但是你必须要小心如何在Raft集群中实现持久状态机，否则你将冒着重复写入的风险。

但是，您应首先确定是否需要像Raft这样的复杂协议来解决您尝试解决的问题。首先回答问题是什么，以及复制协议需要什么。你需要分区容差吗？你需要强大的一致性吗？你需要高可用性吗？吞吐量要求是否排除使用基于领导者的协议？为什么不写入任何被复制的外部数据库？

我是Copycat和Atomix的作者。当您回答其中一些问题并确定这是否确实是正确的方向时，请随时加入我们的聊天。

Answer 2

对我的问题提出一些更一般性的评论：

  

但是Thrift以他的方式创建了服务器和客户端（像Grafosd.Client客户端=新...），而Grafosd是由Thrift生成的。

Thrift本身（仅）使用的序列化和RPC机制。更复杂的协议或API通常是在Thrift之上设计的，使用Thrift - 但不是在Thrift内部。这就像使用汽车将材料运输到建筑工地。决定建筑的不是汽车。汽车只是完成工作的手段。

在这方面，Thrift（或任何其他类似的机制）只是该背景下的工具。我建议首先让它在心理上清楚，哪一块拼图属于哪里，以便从系统设计中获得最佳效果。

  

另外，Thrift将数据存储在Handler中？

我建议总是让处理程序无状态。如果你需要一个州，那很好，但把它存放在其他地方。节俭本身没有任何东西。它是服务器端开发人员手中的处理程序实现，可能需要存储状态或其他信息。