实时的websockets发布-订阅(chat)聊天，带有历史记录。

我对 Disqus 他们评论系统的创作很感兴趣：http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html 基础设施中最令人印象深刻的部分是 Nginx 推流模块：

• 仍在运行 5 台 Nginx 机器。
• 使用支持 EventSource、WebSocket、长轮询和永久 Iframe 的 NginxPushStream。
• 所有用户都连接到这些机器。
• 正常情况下，每台机器每秒可处理 3200 个连接，100 万个连接，TX 150K 次/秒和 RX 130K 次/秒，TX 150 mbits/s 和 RX 80 mbits/s，端到端延迟小于 15 毫秒（比 JavaScript 能渲染评论更快）。
• 资源耗尽一开始有很多问题。Nginx 和操作系统的配置会有助于减轻问题，并将其调整为处理大量移动数据的情况。

显然，此 Nginx 模块不支持数据存储。只支持通过 push_stream_store_messages 指令支持的内存机制，但正如作者所说：

存储消息的主要目标是将消息传递给在发布消息时离线的订阅者。

很明显，Disqus 不会直接将消息发布到 Nginx，而是通过管理存储消息的 Redis 的 Go 后端，随后通过内部 POST 发布到保持订阅者的 Nginx。

有人有通过 Redis 在页面加载前获取消息历史记录的经验吗？即使我们使用新消息的推流模块，您必须一次性推送旧的消息历史记录或者将其呈现为纯 HTML，然后再发布有关在页面加载后出现的新消息的订阅消息。

逻辑应尽可能解耦。我不打算在实时消息通信的用户和 Nginx之间引入阻塞机制。下面是一个好的解决方案吗？

1. 客户端从网页中推送消息（通过Websockets）。
2. Ajax 请求直接到达推流位置，在 Ajax 完成回调时，它要求后端将消息存储在 Redis 中（反向上锁与后端）。
3. 一旦用户刷新页面，后端获取 Redis 列表并显示历史记录。
4. 用户可以查看历史记录并发布新消息。

它只需要开发 2 个后端请求：接受消息并存储到 Redis，获取数据并在页面加载时显示。最好是轻量级的非阻塞后端，例如 Lua 模块 或称为 Webdis 的 HTTP 接口。

我想知道聪明人对体系结构的机制的意见，不需要代码示例。