作为我学习分布式系统的一部分，我正在构建一个聊天应用程序。目前我的设计是让每台服务器都知道它们连接的客户端（这是将使用共识算法复制的状态）。
有一个负载均衡器，客户端最初连接到该负载均衡器，该负载均衡器会响应客户端随后应与之通信的服务器。来自客户端的后续命令直接转到它已分配到的实例。为了管理状态，我正在考虑使用Raft algorithm 达成共识。
【问题讨论】：
标签： architecture scalability distributed
不知道为什么要在这里实现像 Raft 这样的共识算法。传统上，RAFT 用于选举领导者。听起来你不需要这个。比如：
客户端 > 负载平衡器（haproxy）> 聊天服务器池
Haproxy（负载平衡器）可以对您的服务器池执行运行状况检查。如果服务器死亡，它将从池中删除。当服务器变热/压力大时，它可能会“失败”从池中删除健康检查（后端服务器应通过健康检查抛出 503 http 状态）当流量停止时，服务器将重新添加回池中。您可以提醒/监控健康聊天服务器池成员的数量。
在客户端处理错误。如果检测到错误，请重新连接到负载平衡器并获取新服务器。所有聊天状态不应保存在临时聊天服务器实例上，而应保存在 Redis 等某种全局数据存储中。
这使您具有高度可扩展性。在极端情况下，您可能会遇到 Redis 的数据存储问题，但可以通过 Redis 集群或分片聊天来缓解。
【讨论】：