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

Question

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

我正在考虑以下选项。

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

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

3）使用RabbitMQ之类的消息传递队列。该队列的产生者将是postgres，它将通过触发器推送消息。课程的使用者将是.Net客户。

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

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

Answer 1

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

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

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

您需要一条消息总线，因为您将在后台进行大量更新，而不是直接将用户彼此连接。如您所说，客户端可以处于脱机状态。

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

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

然后，可以使用RabbitMQ或类似工具将这个繁重的“组”更新移至长期运行的进程中，但是具有数千个用户的系统可以很好地工作而无需这样做，尤其是因为从用户A到用户B的一条简单消息会不需要很多写。