socket.io vs RethinkDB changefeed [英] socket.io vs RethinkDB changefeed

问题描述

目前我正在使用没有 RethinkDB 的 socket.io，如下所示:

Currently I'm using socket.io without RethinkDB like this:

客户端向 socket.io 发出事件，socket.io 接收事件，向其他各种客户端发出事件，并保存到数据库以进行持久化.连接的新客户端将从数据库中获取现有数据，然后通过 socket.io 侦听新事件.

Clients emit events to socket.io, which receives the events, emits to various other clients, and saves to the db for persistence. A new client connecting will get existing data from the db then listen to new events over socket.io.

切换到 RethinkDB 和 changefeed 对我有什么帮助?

How would switching to RethinkDB and the changefeed help me here?

我看到与 RethinkDB 相同的工作方式是客户端可以执行 POST(插入到 RethinkDB 中)而不是发送到 socket.io，然后 socket.io 正在监视 RethinkDB changefeed 并在它发生时发送给所有客户端接收新数据.

The way I see the same working with RethinkDB is the client could do a POST (which inserts into RethinkDB) instead of emitting to socket.io, and then socket.io is watching a RethinkDB changefeed and emitting to all clients when it receives new data.

这种使用 RethinkDB 和 changefeed 的方法如何比我当前的方法更好?对我来说，他们都觉得他们完成了同样的事情，但我没有看到 RethinkDB 方法有任何明显的优势，因为我会去数据库而不是直接从服务器上的 socket.io 发出它会肯定会慢一点.

How is this method using RethinkDB and the changefeed better than my current method? To me they both feel like they accomplish the same thing, but I don't see any obvious advantage in the RethinkDB method, and because I'd be going to the db rather than emitting from socket.io on the server straight away it will surely be a bit slower.

推荐答案

首先，让我们澄清 socket.io 和 RethinkDB changefeeds 之间的关系.Socket.io 用于客户端(浏览器)和服务器(Node.js)之间的实时通信.RethinkDB changfeeds 是您的服务器 (Node.js) 侦听数据库更改的方式.客户端无法直接与 RethinkDB 通信.

First, let's clarify the relationship between socket.io and RethinkDB changefeeds. Socket.io is intended for realtime communication between client (the browser) and the server (Node.js). RethinkDB changfeeds are way for your server (Node.js) to listen to changes in the database. The client can't communicate with RethinkDB directly.

实时应用程序的一个非常典型的架构是让 RethinkDB changefeeds 订阅数据库中的更改，然后使用 socket.io 将这些更改传递给客户端.客户端通常还会发出可以写入数据库的消息，具体取决于您的应用程序逻辑.

A very typical architecture for a realtime app is to have RethinkDB changefeeds subscribe to changes in the database and then use socket.io to pass those changes to the client. The client usually also emits messages which can get written to your database, depending on your application logic.

是的，您可以通过 socket.io 发出所有消息，然后将所有消息传递给所有客户端，然后将这些消息写入数据库以进行持久化.这也确实更快，但这种方法有许多缺点.

Yes, you could just emit all messages through socket.io then pass all messages to all clients, and then just write those messages to the database for persistence. It's also true that this is faster, but there are a number of disadvantages to this approach.

1.数据库作为单一事实来源

最容易发现的问题如下:

The easiest problem to spot is the following:

• 如果您的应用无法向数据库?
• 如果您尝试插入数据库的数据无效或重复，会发生什么情况?您是否编写应用程序逻辑来处理此问题?
• 如果 Node.js 服务器在发送之前出现故障会发生什么写查询?

这些只是一些简单的示例，在这些示例中，由于您的架构，您将丢失数据或数据不同步.重申一下，您将丢失数据，因为您的主要数据来源是内存.您的 Node.js 应用程序和数据库中的数据也可能存在差异.

These are just some quick examples in which, because of your architecture, you will lose or have out-of-sync data. And just to reiterate this, you WILL lose data, because your main source of truth is in-memory. You might also have discrepancies between the data in your Node.js app and your DB.

关键是数据库应该始终是您唯一的真实来源，并且您应该只在将数据写入磁盘时确认数据.我不知道否则怎么会有人晚上睡觉.

The point is that the database should always be your single source of truth and you should only acknowledge data when it's written to disk. I'm not sure how anyone would be able to sleep at night otherwise.

2.高级查询

如果您只是通过 socket.io 将所有客户端的所有新消息传递给所有客户端，那么您现在必须在客户端中有一些非常复杂的逻辑，以便过滤掉所有真正重要的数据.考虑到您正在通过网络传递大量客户端实际上不会使用的无用数据.

If you just pass all new messages from all clients to all clients through socket.io, you now have to have some pretty complex logic in your client in order to filter out all the data that's actually important. Take into consideration that you're passing a lot of useless data through the network that the client won't actually use.

另一种方法是编写一个发布/订阅系统，您可以在其中订阅某些频道(或类似频道)，以便过滤掉对客户而言真正重要的数据.

The alternative is writing a pub/sub system in which you subscribe to certain channels (or something like that) in order to filter out the data that's actually important to the client.

RethinkDB 通过提供它自己的查询语言来解决这个问题，您可以将其附加到 changefeeds.例如，如果客户需要我 users 表中年龄在 20 到 30 岁之间的所有用户，这些用户居住在加利福尼亚州，距离旧金山 10 英里，并且已经购买了一本书在过去的 6 个月内，这可以用 ReQL(RethinkDB 的查询语言)表示，并且可以为该查询设置更改源，以便仅在 相关 更改时通知客户端.仅使用 Socket.io 和 Node.js 就很难做到这一点.

RethinkDB solves this by providing it's very own query language that you can attach to changefeeds. If the client, for example, needs all the users in my users table between the ages of 20 to 30, that live in the state of California, 10 miles from San Francisco, and who have bought a book within the last 6 monhts, this can be expressed in ReQL (RethinkDB's query language) and a changefeed can be setup for that query, so that the client only gets notified when relevant changes. This is much harder to do with just Socket.io and Node.js.

3.可扩展性

RethinkDB 解决的最后一个问题是，它是一种更具可扩展性的解决方案，只需将所有内容存储在内存中(通过 Socket.io 和 Node.js).因为 RethinkDB 是从头开始构建的分布式，您可以拥有 20 多个带有分片和副本的 RethinkDB 节点的集群.默认情况下，您编写的每个 RethinkDB 查询都是分布式的.现在，您可以拥有 20 多个其他无状态的 Node.js 节点，它们都在监听 changfeeds.因为数据库是事实的中心来源，所以这不是问题.

The last problem that RethinkDB solves is that it's a much more scalable solution to just storing everything in memory (through Socket.io and Node.js). Because RethinkDB is built from the ground up to be distributed, you can have a cluster of 20+ RethinkDB nodes with shards and replicas. Every RethinkDB query you write is distributed by default. Now, you can have 20+ other Node.js nodes that are stateless and are all listening to changfeeds. Because the database is the central source of truth, this is not a problem.

另一种选择是将自己限制在一台服务器上，拥有其他一些发布/订阅系统(例如，建立在 Reddis 之类的系统上)，只有一个您可以轮询的数据库……可能还有更多示例，但您可以看到我要去哪里.

The alternative would be to limit yourself to one server, have some other pub/sub system (built on something like Reddis, for example), have only a single database that you poll... There's probably more examples, but you can see where I'm going with this.

我很想知道这是否回答了您的问题，以及我是否了解您来自哪里.刚开始了解如何构建应用程序有点困难，但对于大多数实时架构来说，它确实是一个优雅的解决方案.

I'd love to hear if this answered your question and if I'm getting where you're coming from. It's a little hard to get how to structure your applications at first, but it really is an elegant solution for most realtime architectures.

这篇关于socket.io vs RethinkDB changefeed的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！