如何设计一个实时数据库更新系统？

Question

我正在使用 WPF 和 .Net 为桌面设计一个类似 whatsapp 的信使应用程序。现在，当用户创建组时，我希望该组的其他成员收到他们被添加到组的通知。我的前端是用 C#.Net 构建的，它连接到一个 RESTful Web 服务（Ruby on Rails）。我正在为数据库使用 Postgres。我还有一个 Redis 层来缓存我的 Rails 模型。

我正在考虑以下选项。

1) 使用 Postgres 内置的 NOTIFY/LISTEN 机制，客户端可以直接订阅。我在这里预见到两个问题 i) Postgres 可能无法处理直接订阅的 10000 个客户端。 ii) 如果客户端断开连接，则无法保证送达

2) 使用客户端可以订阅的 Redis 的 Pub/Sub 机制。我仍然担心这里无法保证交货。

3) 使用像 RabbitMQ 这样的消息队列。该队列的生产者将是 postgres，它将通过触发器推送消息。消费者当然是 .Net 客户端。

到目前为止，我倾向于使用第三个选项。

有人对如何设计有任何建议吗？

Answer 1

在像 WhatsApp 本身这样的应用程序中，手机中运行的客户端是大型复杂的基于事件的分布式系统的组成部分。

如果没有更多上下文，就不可能指出正确的方向。也就是说：

• 对于选项 1：您似乎暗示每个客户端（如在 WhatsApp 客户端中）将直接（或通过某些 Web 服务）与 Postgres 作为事件总线进行通信，这不合理且无法扩展，因为您只能拥有一个 Postgres 实例。
• 对于选项 2：您会遇到与选项 1 相同的问题，但故障模式更差。
• 对于选项 3：RabbitMQ 似乎是一个合理的盟友。它在自然界中分布并且可以很好地扩展。事实上，它就像大多数 WhatsApp 一样在 erlang 上运行。然而，在 Postgres 中使用触发器来发布消息并没有多大意义。

您需要消息总线，因为您需要在后台执行大量更新，而不是直接将您的用户彼此连接起来。如您所说，客户端可以离线。

架构更多是关于推迟决策而不是采取决策。

我建议你从简单开始。首先构建一个小型、单一、同步系统，将更新作为持久数据推送给所有相关用户。例如;在一组 n 个用户中，只需将 n 条记录写入一个表。可靠地跟踪谁收到并阅读了什么已经很复杂了。

然后可以使用 RabbitMQ 或类似的工具将这个繁重的“组”更新移动到长时间运行的进程中，但是一个拥有数千个用户的系统可以在没有这样的东西的情况下很好地工作，特别是因为从用户 A 到用户 B 的简单消息不需要多次写入。