我目前正在开发一个系统，该系统大量使用redis 进行一系列网络服务。
该系统的关键标准之一是快速响应。
目前布局(忽略负载均衡器等)如下:
- 2 x Front End Play Framework 2.x 服务器
- 2 x Job Handling/Persistence Play Framework 2.x 服务器
- 1 x MySQL 服务器
- 2 x Redis 服务器，1 master，1 slave
在此设置中，redis 服务于 2 个任务 - 作为共享缓存和消息总线。
目前，前端服务器托管一个与 Redis 整体交互的服务。
前端服务器尝试在读取服务器池(目前是主服务器和 1 个从服务器)之间平衡读取，但作为 Redis，它们需要向主服务器进行写入。它们通过在队列上发送消息来处理缓存更新等，这些消息由作业处理服务器拾取。
作业处理服务器对 Redis 写入服务器进行阻塞监听 (BLPOP)，并在必要时处理任务。他们只有与 MySQL 的连接。
目前只读副本服务器是一个专用服务器 - 如果当前主服务器出现故障，可以将其切换为写主服务器。
我正在考虑在每个前端服务器上放置一个 redis 的读取副本从属服务器，这意味着读取延迟会更短，并且写入(队列的消息)被推送到单独连接上的写入服务器。
如果我需要扩展，我可以添加更多带有读取从属的前端服务器。
这对我来说听起来像是双赢，因为即使写入服务器暂时退出，前端服务器仍然可以至少从其本地从属服务器读取数据并采取相应行动。
谁能想出为什么这不是一个好主意？
最佳答案
我理解这种方法的优点……但考虑一下:当您只需要扩展一个组件(即 FE 服务器或 Redis)而不需要扩展另一个时会发生什么？例如，更多的流量可能意味着您将需要更多的应用服务器来处理它，而 Redises 的负载将大大减少。另一方面，如果您的数据集增长和/或更多负载放在 Redises 上 - 您将需要扩展这些而不是应用程序。
设计应该符合您的要求，并且您建议的设置的简单性具有一定的吸引力(即按比例缩放，只需添加另一个相同的乐高积木)，但根据我微薄的经验 - 任何听起来好得令人难以置信的事情通常都是如此。从长远来看，即使现在这对你有用，你也可能会发现自己在路上遇到了麻烦。我的建议 - 将您的 Redis 与您的应用程序服务器分开，处理和/或围绕网络工作，并确保每一层都可用并可自行扩展。
关于Web 服务器上的 Redis 只读副本，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21852705/