设计一个消息处理系统

Question

我被要求创建一个如下的消息处理系统。由于我不确定这是否适合发布此内容，请随时将其移至任何其他合适的 SC 小组。

问题

服务器每时每刻都有大约 100 到 500 个客户端连接。当客户端连接到服务器时，服务器会加载部分数据并将其缓存在内存中以便更快地访问。服务器每秒将为所有客户端接收 200~1000 条消息。这些消息相对较小（大约 500 字节）。对缓存中数据的任何更改都应尽快保存到磁盘。当客户端断开连接时，他们的所有数据都会保存到磁盘并从缓存中删除。每条消息都包含一些指令和一条将保存为文件的文本消息。指令应尽可能快地执行（接近即时），并且所有使用该文件的客户端都应获得更新。只能延迟将修改后的消息写入磁盘。

这是我在图表中的解决方案

我的解决方案由一个 Web 服务器（http 或套接字）、一个消息队列以及两个或多个文件服务器和指令服务器实例组成。

• Web 服务器抓取客户端消息，如果消息队列中有可供客户端使用的消息，则将其推送回客户端。
• 指令处理器从队列中获取指令并创建必要的消息以供文件服务器处理（获取/设置文件），并等待文件在队列中可用，并等待更多进程为客户端创建另一条消息。
• 文件服务器仅根据文件类型提供来自缓存或物理文件的文件。

担忧：

• 在高峰时间，连接的客户端总数可能会同时超过 10000 个，并且从客户端接收的消息总数增加到 10~15K。 我应该能够尽快清除队列并恢复正常状态（显然正在处理请求）。
• 我应该能够即时添加额外的指令处理器和文件服务器，而无需关闭其他实例。
• 万一文件服务器崩溃，它不应该丢失文件，因此它必须在有任何更改且处理时间可用时立即将文件写入磁盘。
• 文件系统应为 b+ 树格式，以便某些应用程序（本地报告应用程序）无需通过队列服务器即可轻松访问文件

我的解决方案

我正在考虑将 node.js 用于套接字/Web 服务器。并且可能是用于文件服务器的 NoSQL 数据库和队列服务器，例如 rabbitMQ 或 Node_Redis 和 Redis。

问题：

• 有没有更好的方法来构建这个系统？
• 对于该系统的组件，我还有哪些其他选择？
• 是否可以在同一台服务器机器甚至同一应用程序（不同线程）中运行所有实例？

Answer 1

这里有几个漏洞，主要是 Web 服务器将消息“推送”回客户端。这在基于 Web 的世界中并不适用。您可以尝试使用 websockets，但一般来说，这最终是基于轮询的。

我不知道要执行什么“指令”，但是保存 1000 条 500 字节的消息是微不足道的。许多 NoSQL 解决方案拥有每秒百万以上的写入容量。特别是如果您让提交到磁盘滞后。

不要为文件返回的队列而烦恼。一个好的 NoSQL 解决方案会更好地扩展。构建一个 Cassandra 集群，对其进行负载测试，直到它能够处理您的峰值负载。

这将您的架构简化为 1 个或多个 Web 服务器、客户端轮询该服务器以获取文件更新、将“消息”提交到“指令服务器”（在 Web 开发人员术语中也称为应用程序服务器）的队列，和一个 no-sql 数据库供指令服务器写入文件。

这使得扩展变得容易，您总是可以添加更多的 Web 服务器，并且为您的 no-sql 服务器提供合适的集群大小，您也应该可以在那里水平扩展。你唯一真正的瓶颈是你的指令服务器队列，你总是可以向它扔更多的指令服务器。