架构修炼之道读书笔记（2）

JMS 模型
- 点对点（只会有一个消费者）
- 发布订阅（订阅该主题的消费者都会受到消息）
观察者模式和发布/订阅
- 两者模式上有点相似之处
- 观察者模式在时间空间上都是耦合的
- 发布/订阅多了一个队列，这样发布订阅是彻底解耦的，空间和时间都达到了解耦的目的
MQ为了保证消息不丢失所以可能引入消息重复，所以尽量保证消息是幂等的
- 最好是根据业务ID来进行判断消息是否幂等，MQ的message id可能会重复
MQ的使用场景
- 使各个系统达到解耦操作
- 削峰填谷：降低系统的使用量（使用pull模式，控制拉取速度）
数据异构方向（将数据按需异地构建存储）
- 完整克隆（不适合数据持续增长）
- 标记同步（适合业务简单的，类似日志）
- binlog存储，可以较好的保持数据一致性
- MQ方式，业务数据写入DB的同时发一份给MQ,很难保持数据的一致性

实现消息推送的方式
- 自建的方式：1.基于http的方式，基于http1.1的长连接方式实现 2.基于tcp方式，使用类似netty的框架简化开发
- 第三方平台：极光推送友盟推送

涉及到五个部分： session 管理，心跳，消息接收，消息推送，消息追踪

架构修炼之道读书笔记（2）

会话信息中保存了用户PIN、连接创建时间、这次request产生的AsyncContext上下文信息。一般存到redis中
心跳的目的是判断连接客户端是否还活着，隔一段时间比如5s发一次心跳包，一般是从客户端往服务端发送心跳包
通过MQ接收业务变更信息，通过MQ的广播机制保证每台推送系统服务器都能够收到业务变更信息
整个消息推送链相对比较长，需要做到对每个环节的埋点和跟踪，便与后续问题的跟踪处理。在业务中是通过kafka+hbase的方式，系统中把埋点数据写到本地，由采集器将数据发送到kafka，进而消费kafka插入到hbase集群

在长连接中推送的是消息通知，不是消息实体。所以客户端还会在发送一次请求，去拉取真正的数据，这就是半拉半推方式（比较节省资源）
Netty实现消息推送，也是类似原理，包含session 管理，心跳，消息接收，消息推送，消息追踪
服务器可以跑多少连接

通过四元组可以标识一个连接，一般压测的的客户端连接数字受到端口数的限制，服务器一遍可以保持的连接数数十万个
服务器可以跑多少线程：线程数量 = （机器本身可用内存-jvm分配的堆内存）/Xss的值，同时受到操作系统单进程能使用的最大内存限制（32bit 为 2G）

一次RPC调用的耗时
- 调用端RPC框架执行时间：拦截业务请求，对象序列化，收到响应的时候，反序列化对象
- 网络发送时间：数据包在网络上传输的时间耗时
- 服务端RPC执行时间：服务端队列等待时间，请求拦截+反序列化
- 服务端业务代码处理业务时间