RocketMQ实战与原理解析读书笔记_2020.03.16

发表于 | 分类于 | 次

书名 BOOK TITLE：RocketMQ实战与原理解析

第一部分：整体架构

主要内容：

  1. 场景：解耦，异步，削峰，分发

  2. 整体架构

    1. Producer

    2. Consumer

    3. NameServer（集群）

    4. Broker（集群，每个Broker主从架构）

      1. Topic

        1. Consumer Groups 维度

        2. Message Queues 维度

  3. Consumer

    1. 消息模式

      1. cluster：消息只会被一个consumer消费

      2. broadcast：消息会被所有consumer消费

    2. 数据拉取方式

      1. push-长轮询：使用长轮询的方式实现。需要C/S的配合，C默认阻塞15s，S收到请求的时候，如果没有新的消息，会分3次阻塞，每次持续5s，阻塞过程中若发现数据，则返回，知道结束都没发现新消息则返回空

      2. pull：遍历Topic下的所有Message Queue，本地维护offset

    3. ConsumerGroup：消息在ConsumerGroup维度是广播的，对于具体的Consumer的模式要根据消息模式

    4. 流控：push-长轮询通过在本地维护一个ProcessQueuey（Tree Map：key是offset + 读写锁），存放所有未处理的消息（Message Queue在本地的映射），通过计算消息大小，offset跨度等等实现流控

  4. Producer

    1. 默认的：结合重试+注意处理返回结果。slave的同步机制，磁盘flush机制都有可能出现异常

    2. 延时的：只支持预设值

    3. 自定义的：发送到指定的Message Queue

    4. 事务的：二阶段提交协议。Client预提交一个事务，Server持久化到磁盘，Client执行事物的其他操作，根据结果，提交或者回滚server的事务。如果client提交或者回滚，则使用回查接口查询该事务是要回滚还是提交

  5. Offset

    1. push-长轮询 或者 cluster模式，offset由server管理

    2. pull方式 或者 broadcast，需要Client自己维护offset，包括offset持久化

    3. Consumer提交的自定义offset只会在server拿不到offset的时候起作用

联想：

问题

第二部分：NameServer

主要内容：

  1. 维护Broker信息

  2. 维护Topic信息

  3. Broker创建topic之后注册相应的数据到NameServer

  4. 通信框架Netty

联想：

问题

第三部分：Broker

主要内容：

  1. Commit Log & commit queue

  2. 高可用：master-slave架构

    1. consumer高可用：master主读写，master扛不住的时候自动切换到slave

    2. producer高可用：topic的Message Queue分布在各个broker上，挂掉一个也还是可以继续使用

  3. 同步/异步刷盘：同步写入到磁盘再返回成功，异步写入文件系统就返回

  4. 同步/异步复制：master-slave之间的数据复制策略

联想：

问题

第四部分：可靠性

主要内容：

  1. 顺序消息

    1. 全局顺序：一个topic下创建一个MessageQueue，Producer/Consumer的并发也设置为1

    2. 局部顺序：通过业务id将消息投递到指定的的message queue，在consumer queue消费的时候加锁实现顺序访问

  2. 消息重复：无法做到exactly-once，RocketMq选择确保一定投递，但是消息可能会重复，需要业务方做好幂等控制

    1. Producer带重试发出消息，broker接收成功，但是返回ack的时候失败了，producer重试则消息重复

  3. 故障控制

    1. 多master，每个master带slave

    2. master-slave使用sync/async同步

    3. producer使用sync/async

    4. 刷盘策略使用sync/async

  4. 消息优先级

    1. topic拆分

    2. 单topic下使用更多的message queue

    3. 使用PullConsumer定制消息处理

联想：

问题

第五部分：吞吐量

主要内容：

  1. 消息过滤：

    1. tag消息过滤

    2. sql

    3. server filter

  2. 提升consumer的处理能力

    1. 增加consumer：加机器，加consumer实例，不要超过message queue的个数

    2. consumer端并发处理，一次性拉取更多数据合并批处理

    3. 合理跳过消息

  3. consumer的负载均衡

    1. push-consumer：把message queue分配给具体的consumer处理

    2. pull-consumer：可以获得所有的message queue，可以自定义负载均衡的实现

  4. 提升producer的发送速度

    1. 增加producer的并发量

    2. oneway方式发送，不等待应答

联想：

问题