微信为什么信息传输那么快？

Question

微信同一时间差不多10亿人在线。微信在聊天时，一方发信息，对方几乎一秒内就能收到，背后是什么样的技术架构呢？

技术难点：

你发信息后收到信息的服务器很大可能跟对方连接的服务器不是同一台。这时候，收到信息的服务器如何可以如此快地找到对方连接所在的服务器转发信息过去，然后对方服务器迅雷找到目标连接将信息推送给对方？关键是，时间非常短。

使用redis cluster存储聊天时各人连接的服务器信息是一个自然而然想到的方案，但微信服务器同时收到的信息是海量的，每一个信息转发时都要访问redis，这会不会对redis形成巨大的压力从而降低redis的性能？

Answer 1

具体情况我不清楚，但是有点设想：

还记得你的微信 id 吗，就是不能改的那个，基于它做一个 Hash，然后再各个纬度上继续 Hash，你连上去的时候基本上固定都是被一个区域里负载均衡了的服务器集群所接收，这样别人找你只需要对你的 id 做哈希即可.

另外，服务器收到 A把消息内容发送给B 这个动作的时候，不需要落盘，可能会送到队列（宏观上，且队列集群本身也做前面说的哈希），用来尝试 push 消息给 B 或者在 B 离线的时候暂存，这里队列要不要两条我不太清楚，因为不知道微信的 两个终端（移动端和 WEB 端）同时在线时的同步消息功能到底是两个终端自己同步还是经由服务器同步，如果是前者那么就不需要两条队列，如果是后者也许需要单独一条队列来处理消息暂存。

前者不一定是 push，也可能是消息送进队列后，客户端是订阅者模式可以直接获取到通知然后主动 pull. 不然我想不到什么好方法能让 PC 和移动客户端能同时收同一条消息（如果队列也区分 PC 和移动也不是不行，只是这样资源成本应该不小毕竟本来就有 N份冗余了，现在再 x2 不知道吃不吃得消.

剩下的就是那些哈希表怎么弄才能访问快：全放内存啊，现在服务器内存又不值钱，这个大哈希表在集群中满足 AP 就行？（我猜的.大不了重试嘛

Answer 2

以前用Hazlcast（java的）做过类似场景，

维护一个分布式Map(UserId，[ServerId])，然后发消息时，做以下两部：
通过Map(toUserId)查到ServerId，把消息“路由过去”。。。