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

MQ 之道

• JMS 模型

  • 点对点（只会有一个消费者）
  • 发布订阅 （订阅该主题的消费者都会受到消息）

• 观察者模式 和 发布/订阅

  • 两者模式上有点相似之处
  • 观察者模式在时间空间上都是耦合的
  • 发布/订阅多了一个队列，这样发布订阅是彻底解耦的，空间和时间都达到了解耦的目的

• MQ为了保证消息不丢失所以可能引入消息重复，所以尽量保证消息是幂等的

  • 最好是根据业务ID来进行判断消息是否幂等，MQ的message id可能会重复

• MQ的使用场景

  • 使各个系统达到解耦操作
  • 削峰填谷：降低系统的使用量（使用pull模式，控制拉取速度）

• 数据异构方向（将数据按需异地构建存储）

  • 完整克隆（不适合数据持续增长）
  • 标记同步（适合业务简单的，类似日志）
  • binlog存储，可以较好的保持数据一致性
  • MQ方式，业务数据写入DB的同时发一份给MQ,很难保持数据的一致性

消息推送之道

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

HTTP长连接的组成

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

• 会话信息中保存了用户PIN、连接创建时间、这次request产生的AsyncContext上下文信息。 一般存到redis中

• 心跳的目的是判断连接客户端是否还活着，隔一段时间比如5s发一次心跳包，一般是从客户端往服务端发送心跳包

• 通过MQ接收业务变更信息，通过MQ的广播机制保证每台推送系统服务器都能够收到业务变更信息

• 整个消息推送链相对比较长，需要做到对每个环节的埋点和跟踪，便与后续问题的跟踪处理。在业务中是通过kafka+hbase的方式，系统中把埋点数据写到本地，由采集器将数据发送到kafka，进而消费kafka插入到hbase集群

  在长连接中推送的是消息通知，不是消息实体。所以客户端还会在发送一次请求，去拉取真正的数据，这就是半拉半推方式（比较节省资源）

• Netty实现消息推送，也是类似原理，包含session 管理，心跳，消息接收，消息推送，消息追踪

• 服务器可以跑多少连接

  通过四元组可以标识一个连接，一般压测的的客户端连接数字受到端口数的限制，服务器一遍可以保持的连接数数十万个

• 服务器可以跑多少线程 ： 线程数量 = （机器本身可用内存-jvm分配的堆内存）/Xss的值，同时受到操作系统单进程能使用的最大内存限制（32bit 为 2G）

RPC之道

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