JMS 模型
点对点（只会有一个消费者）发布订阅 （订阅该主题的消费者都会受到消息）观察者模式 和 发布/订阅
两者模式上有点相似之处观察者模式在时间空间上都是耦合的发布/订阅多了一个队列，这样发布订阅是彻底解耦的，空间和时间都达到了解耦的目的MQ为了保证消息不丢失所以可能引入消息重复，所以尽量保证消息是幂等的
最好是根据业务ID来进行判断消息是否幂等，MQ的message id可能会重复MQ的使用场景
使各个系统达到解耦操作削峰填谷：降低系统的使用量（使用pull模式，控制拉取速度）数据异构方向（将数据按需异地构建存储）
完整克隆（不适合数据持续增长）标记同步（适合业务简单的，类似日志）binlog存储，可以较好的保持数据一致性MQ方式，业务数据写入DB的同时发一份给MQ,很难保持数据的一致性涉及到五个部分： session 管理，心跳，消息接收，消息推送，消息追踪
会话信息中保存了用户PIN、连接创建时间、这次request产生的AsyncContext上下文信息。 一般存到redis中
心跳的目的是判断连接客户端是否还活着，隔一段时间比如5s发一次心跳包，一般是从客户端往服务端发送心跳包
通过MQ接收业务变更信息，通过MQ的广播机制保证每台推送系统服务器都能够收到业务变更信息
整个消息推送链相对比较长，需要做到对每个环节的埋点和跟踪，便与后续问题的跟踪处理。在业务中是通过kafka+hbase的方式，系统中把埋点数据写到本地，由采集器将数据发送到kafka，进而消费kafka插入到hbase集群
在长连接中推送的是消息通知，不是消息实体。所以客户端还会在发送一次请求，去拉取真正的数据，这就是半拉半推方式（比较节省资源）
Netty实现消息推送，也是类似原理，包含session 管理，心跳，消息接收，消息推送，消息追踪
服务器可以跑多少连接
通过四元组可以标识一个连接，一般压测的的客户端连接数字受到端口数的限制，服务器一遍可以保持的连接数数十万个
服务器可以跑多少线程 ： 线程数量 = （机器本身可用内存-jvm分配的堆内存）/Xss的值，同时受到操作系统单进程能使用的最大内存限制（32bit 为 2G）
