目前我正在使用没有RethinkDB的socket.io：
客户端向socket.io发出事件，socket.io接收事件，发送到各种其他客户端，并保存到数据库以保持持久性。新的客户端连接将从db获取现有数据，然后通过socket.io监听新事件。
如何切换到RethinkDB和更改源可以帮助我？
我看到同样使用RethinkDB的方式是客户端可以执行POST（插入到RethinkDB中）而不是发送到socket.io，然后socket.io正在观看RethinkDB更改并向其发送给所有客户端收到新数据。
这种方法如何比我当前的方法更好地使用RethinkDB和changefeed？对我来说，他们都觉得他们完成了同样的事情，但是我没有看到RethinkDB方法有任何明显的优势，因为我要去db而不是直接从服务器上的socket.io发出它会肯定会慢一点。
答案 0 :(得分：37)
首先，让我们澄清socket.io和RethinkDB更改源之间的关系。 Socket.io用于客户端（浏览器）和服务器（Node.js）之间的实时通信。 RethinkDB changfeeds是您的服务器（Node.js）监听数据库中的更改的方式。客户端无法直接与RethinkDB通信。
实时应用程序的一个非常典型的体系结构是让RethinkDB更改源订阅数据库中的更改，然后使用socket.io将这些更改传递给客户端。客户端通常还会发出可以写入数据库的消息，具体取决于您的应用程序逻辑。
是的，您可以通过socket.io发出所有消息，然后将所有消息传递给所有客户端，然后将这些消息写入数据库以保持持久性。这种情况更快，但这种方法存在许多缺点。
<强> 1。数据库是单一的事实来源
最容易发现的问题如下：
这些只是一些简单的示例，由于您的体系结构，您将丢失或丢失不同步的数据。只是重申一下，你将失去数据，因为你的主要真相来源是内存。您可能还会在Node.js应用程序和数据库中的数据之间出现差异。
关键是数据库应始终是您的唯一事实来源，您应该只在数据写入磁盘时确认数据。我不知道其他人晚上怎么能睡觉。
<强> 2。高级查询
如果您只是通过socket.io将所有客户端的所有新消息传递给所有客户端，那么您现在必须在客户端中使用一些非常复杂的逻辑来过滤掉实际上非常重要的所有数据。考虑到您通过客户端实际使用的网络传递了大量无用的数据。
另一种方法是编写一个pub / sub系统，您可以在其中订阅某些频道（或类似的频道），以便过滤掉对客户端实际重要的数据。
RethinkDB通过提供它可以附加到更改源的自己的查询语言来解决这个问题。例如，如果客户需要我的users表中年龄在20到30岁之间的所有用户，他们居住在加利福尼亚州，距离旧金山10英里，并且在最后一次购买了一本书。 6个monhts，这可以用ReQL（RethinkDB的查询语言）表示，并且可以为该查询设置更改源，以便客户端仅在相关更改时得到通知。仅使用Socket.io和Node.js就更难了。
第3。可扩展性
RethinkDB解决的最后一个问题是，它是一个更加可扩展的解决方案，只需将所有内容存储在内存中（通过Socket.io和Node.js）。由于RethinkDB是从头开始构建的，因此您可以拥有一个包含20个RethinkDB节点的集群，其中包含分片和副本。您编写的每个RethinkDB查询都是默认分发的。现在，您可以拥有20多个无状态的Node.js节点，并且都在监听changfeeds。因为数据库是事实的核心来源，所以这不是问题。
替代方案是将自己限制在一个服务器上，拥有一些其他发布/订阅系统（例如，建立在像Reddis这样的东西上），只有一个你调查的数据库......可能还有更多例子，但你可以看到我在这里的地方。
我很想知道这是否能解答您的问题，以及我是否能够从您来自哪里。首先要了解如何构建应用程序有点困难，但对于大多数实时体系结构来说，它确实是一个优雅的解决方案。