有一个新的Redis集群设置，我公司中的一个团队正在研究，以便改进基于Redis的应用程序数据缓存。设置如下，Redis群集带有Redis主服务器和许多从服务器，比如说40-50（但是当应用程序扩展时可以增长更多），每个虚拟机一个Redis实例。我被告知这种设置可以帮助每个虚拟机上的服务器中部署的应用程序查询本地Redis实例中的数据，而不是查询网络中的实例，以避免网络延迟。定期更新Redis主服务器仅更新任何修改或新创建或删除的数据（由关系数据库支持的数据），例如每5秒钟左右更新一次。这将启动与所有Redis从属实例的数据同步操作。 Redis（从属服务器）上的数据使用者（部署在所有虚拟机上的应用程序）读取更新的值以进行处理。这种方法对于应用程序在查询数据中心网络内的Redis实例时遇到的网络延迟问题是否正确？当Redis主数据库与所有从属节点同步数据时，此设置是否会产生大量网络流量？
我无法从互联网上找到很多答案。非常感谢您对此的看法。
答案 0 :(得分：2)
这种架构的相关性很大程度上取决于工作量。以下是重要标准：
写入和读取操作之间的比率。显然，读取操作越多，架构就越相关。 IMO的主要好处不一定是延迟增益，而是可扩展性，它带来的额外可靠性以及网络资源消耗。
本地Redis访问的成本与远程Redis访问的成本之间的比率。不要认为远程Redis访问的唯一成本是网络延迟。它不是。在我的系统上，本地Redis访问成本约为50 us（平均而言，工作负载非常低），而远程访问则需要120 us（平均而言，工作负载非常低）。网络延迟约为60 us。使用您自己的数据在您自己的系统/网络上测量相同类型的数字。
以下是一些建议：
不要对许多从属实例使用单个Redis主服务器。它将限制系统的可扩展性。如果要缩放，则需要构建从属层次结构。例如，让主副本复制到8个从属。每个从站复制到64个应用程序服务器上本地运行的其他8个从站。如果需要添加更多节点，可以在主或从级别调整复制因子，或在此树中再添加一个层以获得极高的可伸缩性。它为您带来灵活性。
考虑在应用程序和本地从属服务器之间使用unix socket，而不是TCP套接字。如果它对延迟和吞吐量都有好处。
关于您的上一个问题，您确实需要评估平均本地和远程延迟，以确定这是否值得。请注意，Redis用于同步主站和从站的协议接近正常的客户端服务器流量。应用于主站的每个SET命令也将应用于从站。因此，网络带宽消耗类似。所以最后，这实际上取决于你期望的读取次数和写入次数。