二手
NodeJS、Socket.io
问题
假设有 2 个用户 U1 和 U2,通过 Socket.io 连接到一个应用程序。算法如下:
- U1 完全断开互联网连接(例如关闭互联网)
- U2 向 U1 发送消息。
- U1 尚未收到消息,因为 Internet 已关闭
- 服务器检测U1因心跳超时而断开连接
- U1 重新连接到 socket.io
- U1 从未收到来自 U2 的消息 - 我猜它在第 4 步丢失了。
可能的解释
我想我明白为什么会这样:
- 在第 4 步中,Server 也会杀死套接字实例和发送到 U1 的消息队列
- 此外,在第 5 步 U1 和 Server 会创建新连接(它不会被重复使用),因此即使消息仍在排队,之前的连接也会丢失。
需要帮助
如何防止此类数据丢失?我必须使用心跳,因为我不会让人们永远卡在应用程序中。此外,我仍然必须提供重新连接的可能性,因为当我部署新版本的应用程序时,我希望零停机时间。
附:我称之为“消息”的东西不仅仅是我可以存储在数据库中的文本消息,而是有值(value)的系统消息,必须保证传递,否则 UI 会搞砸。
谢谢!
加法1
我已经有一个用户帐户系统。而且,我的应用程序已经很复杂了。添加离线/在线状态无济于事,因为我已经有了这种东西。问题是不同的。
查看第 2 步。在此步骤中,从技术上讲,我们不能说 U1 是否离线,他只是失去连接,可以说 2 秒钟,可能是因为网络不好。所以 U2 向他发送了一条消息,但 U1 没有收到它,因为他的互联网仍然关闭(第 3 步)。需要第 4 步来检测离线用户,假设超时为 60 秒。最终,再过 10 秒,U1 的互联网连接就建立起来了,他重新连接到了 socket.io。但是来自 U2 的消息在空间中丢失了,因为服务器 U1 因超时而断开连接。
这就是问题所在,我不想 100% 交付。
解决方案
- 在 {} 用户中收集发射(发射名称和数据),由随机发射 ID 标识。发送发射
- 在客户端确认发射(使用 emitID 将发射发送回服务器)
- 如果确认 - 从由 emitID 标识的 {} 中删除对象
- 如果用户重新连接 - 检查此用户的 {} 并循环遍历它,为 {} 中的每个对象执行第 1 步
- 当断开连接或/和连接时,如有必要,为用户刷新 {}
// Server
const pendingEmits = {};
socket.on('reconnection', () => resendAllPendingLimits);
socket.on('confirm', (emitID) => { delete(pendingEmits[emitID]); });
// Client
socket.on('something', () => {
socket.emit('confirm', emitID);
});
解决方案 2(有点)
于 2020 年 2 月 1 日添加。
虽然这不是 Websockets 的真正解决方案,但有人可能仍然觉得它很方便。我们从 Websockets 迁移到 SSE + Ajax。 SSE 允许您从客户端连接以保持持久的 TCP 连接并实时接收来自服务器的消息。要将消息从客户端发送到服务器 - 只需使用 Ajax。存在延迟和开销等缺点,但 SSE 保证可靠性,因为它是 TCP 连接。
由于我们使用 Express,因此我们将此库用于 SSE https://github.com/dpskvn/express-sse ,但您可以选择适合您的那一款。
IE 和大多数 Edge 版本不支持 SSE,因此您需要一个 polyfill:https://github.com/Yaffle/EventSource .
最佳答案
其他人在其他答案和评论中暗示了这一点,但根本问题是 Socket.IO 只是一种交付机制,您不能单独依赖它来实现可靠的交付。唯一能确定消息已成功传递给客户的人是客户自己。对于这种系统,我建议做出以下断言:
- 消息不会直接发送给客户;相反,它们会被发送到服务器并存储在某种数据存储中。
- 客户端负责在重新连接时询问“我错过了什么”,并将查询数据存储中存储的消息以更新其状态。
- 如果在接收方客户端连接时向服务器发送消息,该消息将实时发送到客户端。
当然,根据您的应用程序的需要,您可以调整其中的一部分——例如,您可以使用 Redis 列表或排序集来处理消息,如果您知道一个事实,则将其清除客户端是最新的。
这里有几个例子:
幸福之路:
- U1 和 U2 都连接到系统。
- U2 向服务器发送一条 U1 应该接收的消息。
- 服务器将消息存储在某种持久性存储中,用某种时间戳或顺序 ID 为 U1 标记它。
- 服务器通过 Socket.IO 向 U1 发送消息。
- U1 的客户端确认(可能通过 Socket.IO 回调)它收到了消息。
- 服务器从数据存储中删除持久化消息。
离线路径:
- U1 失去互联网连接。
- U2 向服务器发送一条 U1 应该接收的消息。
- 服务器将消息存储在某种持久性存储中,用某种时间戳或顺序 ID 为 U1 标记它。
- 服务器通过 Socket.IO 向 U1 发送消息。
- U1 的客户不确认收货,因为他们处于离线状态。
- 也许 U2 向 U1 发送了更多消息;它们都以相同的方式存储在数据存储中。
- 当 U1 重新连接时,它会询问服务器“我看到的最后一条消息是 X/我有状态 X,我错过了什么。”
- 服务器根据 U1 的请求向 U1 发送它从数据存储中遗漏的所有消息
- U1 的客户端确认收到,服务器从数据存储中删除这些消息。
如果您绝对希望有保证的交付,那么重要的是设计您的系统,使连接实际上并不重要,实时交付只是一个奖励;这几乎总是涉及某种数据存储。正如 user568109 在评论中提到的那样,有一些消息传递系统可以抽象出所述消息的存储和传递,并且可能值得研究这种预构建的解决方案。 (您可能仍然需要自己编写 Socket.IO 集成。)
如果您对将消息存储在数据库中不感兴趣,则可以将它们存储在本地数组中;服务器尝试向 U1 发送消息,并将其存储在“待处理消息”列表中,直到 U1 的客户端确认它收到它。如果客户端离线,那么当它回来时,它可以告诉服务器“嘿,我已断开连接,请将我错过的任何内容发送给我”,然后服务器可以遍历这些消息。
幸运的是,Socket.IO 提供了一种机制,允许客户端“响应”类似于原生 JS 回调的消息。这是一些伪代码:
// server
pendingMessagesForSocket = [];
function sendMessage(message) {
pendingMessagesForSocket.push(message);
socket.emit('message', message, function() {
pendingMessagesForSocket.remove(message);
}
};
socket.on('reconnection', function(lastKnownMessage) {
// you may want to make sure you resend them in order, or one at a time, etc.
for (message in pendingMessagesForSocket since lastKnownMessage) {
socket.emit('message', message, function() {
pendingMessagesForSocket.remove(message);
}
}
});
// client
socket.on('connection', function() {
if (previouslyConnected) {
socket.emit('reconnection', lastKnownMessage);
} else {
// first connection; any further connections means we disconnected
previouslyConnected = true;
}
});
socket.on('message', function(data, callback) {
// Do something with `data`
lastKnownMessage = data;
callback(); // confirm we received the message
});
这与上一个建议非常相似,只是没有持久数据存储。
您可能还对 event sourcing 的概念感兴趣.
关于node.js - Websocket 传输可靠性(重新连接期间的 Socket.io 数据丢失),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20685208/