海量消息的直播互动系统---融云
融云是做即时性消息通宵的一个平台，由于这个产品和我们目前正在开发的pushservice比较像，所以后期思考的比较多，和讲师也多次线下沟通，但是由于某些原因，具体的业务细节并没有进行详谈，方案上有很多可借鉴之处。
其业务模型如下：
下面分析下他这个模型：
在一个实时消息推送系统中需要保证不同QoS级别的消息，想一些红包之类就需要完全高可靠，像一些弹幕就需要通过设置消息可靠性的等级来推送，有的就不需要保证太强的可靠性。由于是直播间，那消息量和用户量都是没有上线的，且瞬间并发量很高。总结起来有以下几个特点：
1、链接数无上线
2、瞬时消息峰值较高
3、红包礼物要求保障可靠性
4、系统稳定性好
5、系统可伸缩性好
其业务模型大致如下，客户端发送一个消息到服务端时，服务端返回一个应答ack，确认消息已经收到，这里每个消息都一个递增的消息id，然后服务端将消息id发送给客户端，客户端来去这个id所对应的消息，当然也可以一次发送某一段的消息id，客户端B收到消息后，来服务端查询，如果查询不到可以继续查询（或等待下一次消息id的推送）。
这样做的几个原因：
1、通知的推送无需消息质量的保障
2、服务端的消息存储顺序和和到达客户端的顺序一致
3、消息密集时可以将消息合并进行处理
4、可以控制消息的下发条数
5、以存储分级实现消息分级
6、不以消息的条数控制服务器的规模，以用户连接数来控制
这里有个疑问：为什么不是主动推送消息到客户端B，等客户端B应答ACK？
如果推送超时，那么需要重新推送。而现在不需要（主要和直播这种业务模型有关，这里可以采用定时器，或者等下一条消息推送到了，就会触发下一次推送，通常下一条消息到了的可能性较大）。（注释：服务端和客户端之间的通讯采用的是私有化的MQTT实现）
还有个疑问就是如何保障缓存区不溢出？
每个类型的消息都有一个队列，可靠性高的就不设置队列限制，反之就采用LRU算法来限制队列。
其组网架构如下：
时间：2014-2015.8
同一直播间的用户会落到同一节点。
业务与消息在同一服务
最大支持单一直播间9000人（爆个内幕：直播服务上面显示的人数一般都是现有人数的xx倍）
这里有个问题就是连接层和业务层是两个集群，（私下沟通：其集群内的通讯都是通过ak来完成）那么在集群通讯的时候，另外一个集群只有一个receptionlist节点来接受消息，在一定程度上会形成消息瓶颈。（这里在微信问了讲师，还没回，好像被我问烦了。。。）可能需要我们自己实测一下。
2.0版本
2.0的版本将消息服务和直播服务分开了。。。
2.1的时候有加了一个控制层，估计是用来做路由的，将某条消息路由到某个固定的连接
还需要了解的技术点：
一致性hash保证连接，环形队列保证？
gj8:[~N
