我一直在研究筏共识算法的一个问题，我试图解决，我已经决定，筏确实是要走的路。
然而，由于我正在工作的环境的性质，一次至少有20个pod，使用autoscale它可以一路增加到100+。为了简单起见，我们假设50+ pod。
所以，由于领导者选择机制是相当“灵活”的，拥有比互联网上的例子（3 - 5 - 7等）更多的pod自然让我认为在20-50-100 pod环境中这样做是棘手/危险的。
我找不到任何关于在如此大规模下使用Raft的风险的信息。我知道etcd和K8S在内部使用Raft，所以也许这不会像我想的那样是一个问题。所以我的问题是，在有许多pod的大规模环境中使用Raft是否有任何潜在的主要缺点？
顺便说一下，我将在一个带有NodeJS微服务的K8S环境中使用它。根据服务发现的可用性，我将使用简单的TCP连接或使用中间Redis pub-sub进行通信。
谢谢你，谢谢
1条答案
按热度按时间uqjltbpv1#
我不认为Raft在这两个用例上会有效率：
我可以推荐看看Pasifica方法吗？这就是Kafka的工作方式-非常可扩展和时间证明的系统。
PacificA背后的想法很简单：将控制平面与控制平面解耦。10个节点位于数据平面，3-5-或-7是控制平面。更多详细描述请访问：https://kafka.apache.org/documentation/#design_replicatedlog
作为一个侧节点，当一个人需要一个超过7个节点的集群时，PacificA通常是一个很好的选择。