caching - Redis集群-网络延迟

Question

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

我无法从互联网上找到很多关于此的答案。非常感谢您对此提出意见。

Answer 1

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

• 写入和读取操作之间的比率。显然，读取操作越多，架构就越相关。 IMO 的主要好处不一定是延迟 yield ，而是可扩展性、它带来的额外可靠性以及网络资源消耗。

• 本地 Redis 访问成本与远程 Redis 访问成本之间的比率。不要假设远程 Redis 访问的唯一成本是网络延迟。它不是。在我的系统上，本地 Redis 访问成本约为 50 us(平均，工作量非常低)，而远程访问成本为 120 us(平均，工作量非常低)。网络延迟约为 60 us。使用您自己的数据在您自己的系统/网络上测量同类数字。

这里有一些建议:

• 不要对多个从实例使用单个 Redis 主实例。它将限制系统的可扩展性。如果你想扩展，你需要建立一个奴隶的层次结构。例如，让 master 复制到 8 个 slave。每个从站复制到在您的 64 个应用程序服务器上本地运行的 8 个其他从站。如果您需要添加更多节点，您可以在主节点或从节点级别调整复制因子，或者在此树中再添加一层以获得极高的可扩展性。它为您带来了灵 active 。

• 考虑在应用程序和本地从站之间使用 unix 套接字，而不是 TCP 套接字。如果它对延迟和吞吐量都有好处。

关于您的最后一个问题，您确实需要评估本地和远程的平均延迟时间来决定这样做是否值得。请注意，Redis 用于同步主从的协议(protocol)接近于正常的客户端服务器流量。应用于主站的每个 SET 命令也将应用于从站。因此网络带宽消耗是相似的。所以最后，这实际上是您期望的读取次数和写入次数的问题。