消息系统架构介绍
下面是对消息系统的大概介绍 ， 之前一些同学可能在gopher china上可以看到分享 ， 这里简单讲解下架构和各个组件功能，额外补充一些当时遗漏的信息：
架构图如下，所有的service都 written by golang.
几个大概重要组件介绍如下：
dispatcher service根据客户端请求信息，将应网络和区域的长连接服务器的，一组IP传送给客户端 。客户端根据返回的IP，建立长连接，连接Room service.
room Service，长连接网关，hold用户连接，并将用户注册进register service，本身也做一些接入安全策略、白名单、IP限制等 。
register service是我们全局session存储组件，存储和索引用户的相关信息，以供获取和查询 。
coordinator service用来转发用户的上行数据，包括接入方订阅的用户状态信息的回调 ， 另外做需要协调各个组件的异步操作，比如kick用户操作,需要从register拿出其他用户做异步操作.
saver service是存储访问层，承担了对redis和mysql的操作 ， 另外也提供部分业务逻辑相关的内存缓存，比如广播信息的加载可以在saver中进行缓存 。另外一些策略 ， 比如客户端sdk由于被恶意或者意外修改，每次加载了消息，不回复ack，那服务端就不会删除消息，消息就会被反复加载，形成死循环 ， 可以通过在saver中做策略和判断 。（客户端总是不可信的） 。
center service提供给接入方的内部api服务器，比如单播或者广播接口，状态查询接口等一系列api,包括运维和管理的api 。
举两个常见例子，了解工作机制：比如发一条单播给一个用户，center先请求Register获取这个用户之前注册的连接通道标识、room实例地址，通过room service下发给长连接 Center Service比较重的工作如全网广播，需要把所有的任务分解成一系列的子任务，分发给所有center，然后在所有的子任务里，分别获取在线和离线的所有用户，再批量推到Room Service 。通常整个集群在那一瞬间压力很大 。
deployd/agent service用于部署管理各个进程，收集各组件的状态和信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度
关于推送的服务端架构
常见的推送模型有长轮训拉取 ， 服务端直接推送（360消息系统目前主要是这种），推拉结合（推送只发通知，推送后根据通知去拉取消息）.
拉取的方式不说了，现在并不常用了，早期很多是nginx+lua+redis，长轮训，主要问题是开销比较大，时效性也不好，能做的优化策略不多 。
直接推送的系统，目前就是360消息系统这种，消息类型是消耗型的，并且对于同一个用户并不允许重复消耗,如果需要多终端重复消耗，需要抽象成不同用户 。
推的好处是实时性好，开销?。?直接将消息下发给客户端，不需要客户端走从接入层到存储层主动拉取.
但纯推送模型 ， 有个很大问题，由于系统是异步的，他的时序性无法精确保证 。这对于push需求来说是够用的，但如果复用推送系统做im类型通信，可能并不合适 。
对于严格要求时序性，消息可以重复消耗的系统，目前也都是走推拉结合的模型，就是只使用我们的推送系统发通知 ， 并附带id等给客户端做拉取的判断策略 ， 客户端根据推送的key ， 主动从业务服务器拉取消息 。并且当主从同步延迟的时候，跟进推送的key做延迟拉取策略 。同时也可以通过消息本身的QoS，做纯粹的推送策略，比如一些“正在打字的”低优先级消息，不需要主动拉取了 ， 通过推送直接消耗掉 。
推荐阅读
- 扶绥小程序开发吧，扶绥微服务的微信号
- 银河系下载，银河系软件
- gis图例中删除图层名，arcgis删除图例项
- linux命令入门 linux入门基础命令
- gis如何计算两点间距离，gis点距离分析
- 搭建睡眠直播教程，直播睡眠的叫什么
- python2的延时函数的简单介绍
- 一帆短视频号怎么赚钱，一帆视频注册
- excel或者符号怎么用，excel或者符号运算