https://www.bilibili.com/video/BV1L4411y7mn?p=24
1.如何保证高可用
2.消息丢失怎么办，重复消费问题，消息顺序如何保证
3.消息一致性，A成功传给BCD D挂了，如何一致
默认是负载均衡模式，还有一个广播模式
P24.张三：创建订单，扣减库存，付款订单，完成订单
Broker默认会把消息依次放入多个队列
消费者多线程的同时消费多个消息
1.保证消息选举顺序
2.局部消息顺序
只要保证张三的消息顺序即可
把张三的消息丢在一个队列里，一个线程处理一个队列的模式
发送的时候增加一个顺序标记MessageQueue 消息队列选择器
producer.send(msg,new MessageQueueSelector(){
},orderID);
消费的时候掉用顺序标记MessageListenerOrderly
发送的时候，设置延迟时间setDelayTimeLevel(2)，消费者就要延迟消费
2表示级别 对应5ms 最高1ms到2小时 18个级别
不能超过4M，超过需要分割
消息发送带有事务，生产者发送后要进行提交，消费者才能进行消费 这类消息要half 消息
1）事务消息发送及提交
2）事务补偿
补偿机制用来解决消息Commit或者Rollback发生超时或者失败的情况
事务消息三个状态，提交，回滚，中间状态unknown
P38 MQ在下单的使用
下单，库存扣减，优惠券，用户积分，成功是用PRC顺序掉用，如果失败发送失败消息给MQ，直接反馈失败消息给客户。库存，优惠券和用户模块监听MQ进行回滚
MQ在支付回调的使用
第三方支付后返回成功给系统，系统要做的事情1.修改订单 2.记录支付日志，3.修改客户积分。 直接把成功消息发给MQ，另外三个服务器监听MQ 异步处理
######华丽的分割线######
P89开始讲解高级功能，如何存储消息，如何高可用，注册复制
P91 写性能 Rocket MQ 用顺序写文件方式，写入速度很快
消息发送 读性能：普通读过程
磁盘数据--内核态内存--用户态内存--网络驱动内核内存--网卡 > 用户
四步，零拷贝 采用了Java的MappedByteBuffer ，省略了用户态内存哪一步
一次只能映射1.5G到2G，所以CommitLog大小为1G的原因
1.CommitLog 2.ConsumerQueue 存储消息索引 3. IndexFile 提供Key或者时间查找的方式
1.安全性：同步刷盘 Producer - Java Heap - Memory -Disk Flush到Disk才返回成功
2.高性能：异步刷盘 不用Flush到Disk就相应成功
NameServer 用集群搭建
1.Consumer 会默认从Master读，Master繁忙，自动切换到Slave去读
2.Broker双主双从保证写入高可用 发送的时候指到不用的Broker,这样有一个主节点挂了，可以发给另外的主节点
Consumer集群
Producer集群
1.同步复制 2.异步复制
配置文件里主节点分同步和异步，从节点配成Slave
建议刷盘：配制成异步（保证吞吐量），主从复制用同步复制（最小保证数据不丢失）
1.Producer 负载均衡
通过Topic 路由发送轮询消息给不同的Broker Queue，且会分发给不同的Boker
消费者
1.集群模式 a.顺序领取任务，b.平均分摊每一条queue,环状轮流分queue的形式给多个消费者（消费者数量不要大于queue的数量）
2.广播模式
没有负载，每个消费者都消费每一条消息
前面没有消费完，如果失败了发生阻塞，后面不能消费消息，要关注消息前面是否失败，及时处理
无序消息（普通，定时，延时，事务消息）失败后，通过返回状态达到消息重试的目的。无序只对集群，广播不能重试
1）次数最多16次，每次重试时间不同 逐渐递增 1 10秒 2.30秒
最长为4小时46分钟16次重试后，不再投递，这个消息就进入死信队列
三种返回触发消息重试
失败后，不想重试，java代码，直接return Action.commitMessage;
重试次数，可以手工设置，超过16次，每次都是2小时，最大次数20次
一个GroupID 下设置，那么所有消费者都生效这个 重试设置
最后启动的实例会覆盖前面的设置。重试都失败，进入死信队列
特征1.不能再被消费
特征2.有死信消息3天，3天后自动删除
特点：
1.一个队列对应一个GroupID，而不是某个消费者实例
2.一个GROUPID没有死消息，不创建死信队列
3.一个队列包含了GroupID对应所有的死信消息，不论属于哪个Topic
处理
1.选择RokctMQ重新发送
2.专门对死信队列的操作，去操作这些死信
一条消息不管消费多少次，结果一致
重复消息
发送时重复发送
网络原因，生产者没有收到应答，重复发送
投递时消息重复
消费后，网络闪断，没有给MQ正确的响应，重复投递
负载均衡模式消息重复
某个MQ的Broker发生down机，或者重启，扩容，重新负载均衡，不同的消费者消费了相同的消息
手段1. Message ID。不建议，MQ会产生重复messageID
手段2.用业务唯一标识，消息业务key message.setKey("order10001");
处理过的消息，存起来（问题不同的JVM如何保证？有个方案是利用redis集群）