我有兴趣创建Disqus对其评论系统所做的工作：http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html
基础设施中最令人印象深刻的部分是Nginx推送流模块：
仍在5台Nginx机器上运行。
使用NginxPushStream，它支持EventSource，WebSocket，Long 轮询和永远的iframe。
所有用户都已连接到这些计算机。
在正常的一天，每台机器看到3200个连接/秒，100万个 连接，150K包/ s TX和130K包/ s RX，150 mbits / s TX 和80 mbits / s RC，端到端延迟<15ms（比...更快） Javascript可以发表评论）
首先出现资源耗尽的许多问题。配置 为Nginx和OS提供帮助缓解问题， 调整它们以处理具有许多连接移动的场景 数据
显然这个Nginx模块不支持数据存储。只有 push_stream_store_messages 指令支持的内存机制，但as author said：
存储邮件的主要目标是将邮件传递给 邮件发布时处于脱机状态的订阅者。
很明显，Disqus不会直接向Nginx发布消息，而是通过Go后端设法在Redis中存储消息，然后通过内部POST发布到Nginx，从而保留订阅者。
在我们使用推送流模块获取新消息之前，是否有人有过在页面加载时通过Redis获取消息历史记录的经验？您是否必须一次性推送旧邮件历史记录或以纯HTML格式呈现，然后将pubsub用于加载页面后出现的新邮件？
逻辑需要尽可能地解耦。我不打算在用户和Nginx之间引入阻止机制来进行实时消息通信。这会是一个很好的解决方案吗？
只需要开发2个后端请求：接受消息并在Redis中存储，获取数据并在页面加载时显示。最好是需要轻型非阻塞后端，如Lua module甚至是Redis的HTTP接口，称为Webdis。
我想从架构的角度了解智能人对该机制的看法，没有预期的代码示例。