决战圣地玛丽乔亚Day52----RocketMQ的主从结构，扩容，高可用
主从结构：
方案1：多master无slave模式
缺点：
- 若broker宕机，则broker上未被消费的消息在broker恢复前无法消费
方案2：多“master-slave”异步复制模式
给master分配slave从节点，生产者发消息给master后，异步将master的数据增量复制到slave
优点：master出现异常后，slave能继续提供消费服务。
缺点：broker宕机后，slave永远无法成为master，即producer无法再向该mater写入消息
方案3：多“master-slave”同步复制模式（同步双写）
producer写数据时，同步向master和slave同步写入，都写入成功才向producer返回“写入成功”的响应。
优点：数据的可靠性比上面强
缺点：broker宕机后，slave永远无法成为master，即producer无法再向该mater写入消息
方案4：DLedger(多副本)模式（唯一的推荐使用方案）
前提：在RocketMQ4.5版本以后提供了DLedger集群架构，要求一个broker集群中至少要提供有三个broker集群分片（即多对“1master多slave”），一旦master节点宕机，DLedger会自动从剩下的多个slave中选举出一个新的master继续对外提供服务。master与slave之间的数据同步可以支持异步模式和同步模式。
优点：master节点异常时，能自动选举出新master提供服务
缺点：耗费资源较多
RocketMQ的DLedger模式是一种基于多副本的高可用模式，主要用于解决消息丢失和数据不一致的问题。DLedger模式是基于Apache DistributedLog项目实现的。 DLedger模式的特点如下：
- 多副本：采用多副本模式，每个副本都有完整的数据，可以保证数据的可靠性和一致性。
- 无单点故障：采用Raft协议选举Leader，保证系统没有单点故障。
- 强一致性：采用Raft协议保证强一致性，可以避免数据不一致的问题。
- 高可用性：当Leader节点出现故障时，系统可以自动选举新的Leader，保证系统的高可用性。
- 自动恢复：当数据不一致时，系统可以自动进行数据恢复，保证数据的正确性。 在DLedger模式下，每个节点都存储完整的数据，这样可以保证数据的可靠性和一致性。当消息发送到一个节点时，该节点会将消息写入本地磁盘，并将消息同步给其他节点。当消息被多数节点确认后，该消息被视为已提交，然后可以被消费者消费。如果出现节点故障，其他节点会自动选举新的Leader，保证系统的高可用性。如果数据不一致，系统会自动进行数据恢复，保证数据的正确性。 总之，DLedger模式是一种高可用、可靠、一致性强的消息存储模式，可以有效解决消息丢失和数据不一致的问题。
具体关于Dledger的详情：
https://blog.csdn.net/qq924862077/article/details/104547599/
重复消费问题：
生产重复消息：
当一条消息已被成功发送到 消费者 并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 如果此时 生产者 意识到消息发送失败并尝试再次发送消息，消费者 后续会收到两条内容相同并且 ID 也相同的消息。
方案
- 避免消费重复产生，找到原因，并做代码的限制。
- 消费数据时利用Java代码做ID的重复校验，重复则放弃，并返回异常信息。也可以考虑针对数据库有条件的插入语句，限制重复插入。
- 消费数据时，通过订阅的记录和消费的结果来判断，此消息是否重复订阅过，如果重复订阅，则不在数据库中插入数据。
消费消息时重复：
消息已投递到 消费者 并完成业务处理，当 消费者 给 MQ 反馈应答的时候网络闪断。 为了保证消息至少被消费一次，消息队列 MQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者 后续会收到两条内容相同并且 ID 也相同的消息。
- 消费数据时利用Java代码做ID的重复校验，重复则放弃，并返回异常信息。也可以考虑针对数据库有条件的插入语句，限制重复插入。
消费时出现异常：
消息已投递到 消费者 并完成 业务A 处理，但是 业务B 处理时，发生异常，造成该条消息会标记 消费失败 ，那么为了保证消息至少被消费一次，该条消息会消费多次，直到达到消费16次，会自动放入死信队列。
解决方法：
- 分布式事务锁（一般是zookeeper和redis搭建）
RocketMQ的结构：
可以详细参考这篇文章
https://blog.csdn.net/wui66655/article/details/123091578
浙公网安备 33010602011771号