我目前正在开发一个系统，该系统大量使用redis来处理一系列Web服务。
该系统的一个关键标准是快速响应。
目前布局（忽略负载平衡器等）如下：
在此设置中，redis提供2个任务 - 作为共享缓存和消息总线。
目前，前端服务器托管的服务与Redis完全交互。
前端服务器尝试平衡读取服务器池（当前是主服务器和1个从服务器）的读取，但是作为Redis，他们需要对主服务器进行写入。它们通过在队列上发送消息来处理缓存更新等，这些消息由作业处理服务器拾取。
作业处理服务器阻止侦听（BLPOP）到Redis写入服务器并在必要时处理任务。他们与MySQL有唯一的联系。
目前，只读副本服务器是一个专用服务器 - 如果当前主服务器出现故障，可以将其切换为写主服务器。
我正在考虑在每个前端服务器上放置一个redis的读取副本，这意味着读取延迟会更少，并且写入（队列消息）会在单独的连接上被推送到写入服务器。
如果我需要扩展，我可以添加更多带有读取从属服务器的前端服务器。
对我而言，这听起来像是一场双赢，即使写入服务器暂时退出，前端服务器仍然可以至少从本地从站读取数据并采取相应行动。
任何人都可以想到为什么这可能不是一个好主意？
答案 0 :(得分：1)
我理解这种方法的优点......但请考虑一下：当您只需要扩展一个组件（即FE服务器或Redis）而不是另一个组件时会发生什么？例如，更多的流量可能意味着您需要更多的应用服务器来处理它，而Redises的负载会大大减少。另一方面，如果您的数据集增长和/或更多负载放在Redises上 - 您需要扩展这些而不是应用程序。
设计应该符合您的要求，并且您建议的设置的简单性具有明确的吸引力（即扩展，只需添加另一个相同的乐高积木），但从我微薄的经验 - 任何听起来好得不真实的东西通常是。从长远来看，即使现在这对你有用，你可能会发现自己陷入了困境。我的建议 - 将您的Redis与您的应用程序服务器分开，处理和/或在网络中工作，并确保每个层都可用且可自行扩展。