可靠性、实时、有序、高可用－－没有最好的设计，只有最适合的
1.基础模块定义
- signal 信令单元
- online/login 在线控制单元，负责维护用户在线状态（userid,routeid,brigeid,pwd,clienttype）
- im/gim 消息控制单元/视频控制单元 维护用户好友关系、群组关系或者会议关系
- pub 公众号控制单元 公众号群组及关系维护
- msgbox 信箱
- msgwriter 负责持久消息，同步持久缓存
- msgcore负责缓存消息，一条消息体，多条接收者
- push 消息推送模块
- 只负责推送消息和公众号的广播推送
- route 路由
- bridge 类似于channel。给终端发送消息时通过routeid找到路由组，通过bridgeid找到具体用户的连接通道即可推送消息。
route --一对多–> brige --一对一–>socket/ip:port
2.登陆过程
带注解啰嗦版
3.消息发送过程
带注解啰嗦版
设计师关注的点：
成本、收益比
程序猿关注的几个问题：
1.大群的消息群发性能如何保障。
用分布式push以千为单元切分任务，可以保障每个push节点最大分发任务为1千。由多个push交给多个route去推送，而route 和brige负责的链路数可以保障在可用范围内即可。
2.持久的方式，比如大量的历史数据。
首先群消息体只记录一条信息匹配该条信息的是接收都组，其次用ＤＢ分表，分区持久无压力。
3.session分布
session由redis集群保障可用和可分布，而且故障只会影响部分用户重新登陆即可。
4.消息的收发有序保障
牺牲绝对消息顺序，保障分布特性（无序、无事务）。由服务器时间截保障消息有序（本地时间截用于较正发送在途延时&网络环回时长？）
5. 容灾保障
常规分布式系统天生具备容灾，大象采取低成本的热容方式。必要时需部分用户重新登陆。