Redis集群-网络延迟

Question

有一个新的Redis集群设置，我认识的一个团队正在致力于改进基于Redis的应用程序数据缓存。设置如下，一个Redis集群有一个Redis主服务器和许多从服务器，比如40-50个(但当应用程序被缩放时可以增长得更多)，每个虚拟机都有一个Redis实例。有人告诉我，这种设置帮助部署在每台虚拟机上的服务器上的应用程序查询本地Redis实例中的数据，而不是查询网络中的实例，以避免网络延迟。定期地，Redis主服务器只使用任何修改、新创建或删除的数据(由关系数据库支持的数据)更新，比如每5秒左右更新一次。这将启动所有Redis从实例的数据同步操作。Redis (从服务器)的数据使用者(部署在所有虚拟机上的应用程序)读取更新后的值来进行处理。这种方法是解决应用程序在从数据中心网络中的Redis实例查询时所面临的网络延迟问题的正确方法吗？当Redis掌握了与其所有从节点同步数据时，这种设置不会产生大量的网络流量吗？

我在网上找不到多少答案。你对此的意见是非常感谢的。

Answer 1

这种架构的相关性在很大程度上取决于工作负载。以下是重要的标准：

• 读写操作之间的比率。显然，读取操作越多，体系结构就越相关。IMO的主要好处不一定是延迟增加，而是它带来的可伸缩性、额外的可靠性和网络资源消耗。
• 本地Redis访问成本与远程Redis访问成本之间的比率。不要假设远程Redis访问的唯一成本是网络延迟。事实并非如此。在我的系统上，本地Redis访问成本约为50美元(平均而言，工作量非常低)，而远程访问成本为120美元(平均而言，工作量非常低)。网络延迟约为60μs。用你自己的数据在你自己的系统/网络上测量相同的数字。

以下是一些建议：

• 不要对许多从实例使用单个Redis主程序。这将限制系统的可伸缩性。如果你想扩大规模，你需要建立一个奴隶的层次结构。例如，让主从复制到8个奴隶。每个从服务器复制到在64台应用服务器上本地运行的其他8个从服务器。如果需要添加更多节点，可以在主或从级别优化复制因子，或者在此树中再添加一个层以实现极端的可伸缩性。它给你带来了灵活性。
• 考虑在应用程序和本地从节点之间使用unix套接字，而不是TCP套接字。如果它对延迟和吞吐量都有好处的话。

关于最后一个问题，您确实需要评估本地和远程的平均延迟，以确定这是否值得。请注意，Redis用于同步主服务器和从服务器的协议接近于正常的客户端服务器通信量。应用在主服务器上的每一组命令，也将应用到从服务器上。因此，网络带宽消耗也是相似的。所以说到底，这真的是一个你期望读多少次和写多少次的问题。