一、RocketMQ概述
1.1）RocketMQ产生的原因
Kafka一个分区只能由消费组中一个消费者消费，多出来的消费者也无法增加性能
1.2）RocketMQ如何支持多分区
Kafka直接访问CommitLog，而RocketMQ先读取ComsumeQueue中的Offset，随机读到Offset再去CommitLog中顺序读——缺点可能出现CommitLog中的消息对应ComsumeQueue中没有Offset
二、定义与概念
同步发送：发送后等待服务端给响应发送成功之后信息才给用户提示
异步发送：直接提示用户已发送，等到服务端响应发送成功后再用回调函数处理
推动式消费：有一个进程执行对RocketMQ拉取消息，再将消息发送给消费者，在消费者眼中看不到进程以为是Broker推送的
Topic：比如同一份消息需要发送给PC，APP，站内短信，邮件，针对不同渠道信息不同排版使用不同Topic进行隔离
Name Server：提供zookeeper一部分功能维护Broker列表，特色功能可通过名字找主题。相互独立类似于Redis sentinel互相独立相互监视，好处是权利平行解决不需要配置主从
Pull Comsumer：对应消费端主动性高，不管生产端发送多少我根据自己能力消费
Push Comsumer：不在乎消费端有没有消费完就主动推
Producer Group：提供备份防止一个Producer挂掉可以进行顶替
集群消费：相当于Kafka轮询
广播消费：消除了Kafka一个Partition只能被消费者组中一个消费者消费，一个Partition可以被所有Comsumer全量接收
三、安装 & 启动
nohup不挂起运行，客户端终止服务端不停止运行；&指后台启动
./tools.sh org.apache.rocketmq.example.quickstart.Producer
安装RocketMQ Dashboard
四、基于rocketmq-client 项目实战
单向消息应用于对发送性能要求高，但对数据完整性要求低场景
nohup ./mqbroker -c ../conf/broker.conf &
2PC强一致性：在所有分布式事务中一阶段所有操作成功，TM二阶段执行提交，一阶段有一个操作失败，TM二阶段将全部操作回滚
UNKNOWN状态的消息会执行checkLocalTransaction()方法
顺序消费取余保证相同文件按顺序存储在同一个MessageQueue中
五、设计与架构
5.1）Producer & Consumer
5.2）NameServer
5.3）BrokerServer
5.4）概念补充
UserProperties参考生产者SQL过滤代码
5.5）消息存储
maxOffset相当于Kafka中Log End Offset
5.6）页缓存与内存映射
页缓存
内存映射
微服务比较火因分为两部分，不同服务配置不同性能的机器，一个服务又要高CPU又要大磁盘拆不开：
计算型：采用高CPU，高内存
IO型：大内存，SSD大磁盘
5.7）消息刷盘
同步保证数据正确性（银行没有容错率），异步加快执行效率（出错概率低）
5.8）高可用性
主从集群
主从复制
5.9）负载均衡
5.9.1）Producer端
setLatencyFaultEnable开启会将Broker进行排序，latency时间越短Broker越排前
5.9.2）Consumer端概述
ConsumerManager保存所有消费者列表，channelInfoTable
5.9.3）Consumer端集群模式
5.10）消息重试
Message ID代表消息的唯一性
5.11）死信队列
有点像垃圾回收站
