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

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

我正在考虑下列选择

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

2） 使用Redis的发布/订阅机制，客户端可以订阅该机制。我仍然担心这里不能保证交货

3） 使用RabbitMQ之类的消息传递队列。此队列的生产者将是postgres，它将通过触发器推入消息。消费者当然是.Net客户端

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

---

有人对如何设计这个有什么建议吗？

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

没有更多的背景，就不可能指向正确的方向。也就是说：

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

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

架构更多的是推迟决策，而不是做出决策

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

---

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

以任何方式实现它，一旦成功，你选择什么并不重要。你最后做了什么？你能分享你的经验吗？