RocketMq源码学习

NameServer的主要作用是为消息的生产者和消息消费者提供关于主题Topic的路由信息，那么NameServer需要存储路由的基础信息，还要管理Broker节点，包括路由注册、路由删除等。

消息堆积的场景 1.业务高峰期业务量激增,生产太快。 2.消费者不充足。 3.由于某个队列的消息迟迟不能被消费导致消费进度无法提交。 4.生产者未感知Broker消费堆积持续向Broker推送消息。

如果我们的项目中引入了MQ，还要面消息丢失问题，今天我们就来聊聊消息是怎么丢失以及如何保证消息零丢失。

RocketMQ中存在很多导致消息重读消费的情况，今天就探讨一下这些情况。并且官方说大多数情况下消息不会重复,所以如果业务场景中需要保证消息不能重复消费，那么就需要根据业务场景合理的设计幂等。

当一条消息消费失败自动进行消息重试达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，rocketmq会将其发送到该消费者对应的特殊队列中即死信队列。

当消费者消费顺序消息失败,消费者会在本地自动不断进行消息重试。消费者消费无序消息失败时可以通过设置返回状态达到重试的目的。广播模式保证每条消息至少被每台客户端消费一次但是并不会对消费失败消息失败重投。

负载均衡用来在多个资源中分配负载,达到最优化资源使用,避免单台服务器过载。RocketMQ中的负载均衡主要可以分为生产者发送消息的负载均衡和消费者订阅消息的负载均衡以及消费者分配队列的负载均衡。

主从之间配置成SYNC_MASTER的复制方式，这样即使有一台机器出故障，仍然可以保证数据不丢。主从刷盘配置为ASYNC_FLUSH可以保证m和s都写入到了内存中,这样可以保证吞吐量。

分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。RocketMQ消息存储在磁盘上，能保证断电恢复,且可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写

① 事务消息发送与提交: a.发送消息 b.服务响应消息写入结果 c.根据发送结果执行本地事务 d.根据本地事务状态执行提交或者回滚 ② 事务消息的补偿阶段:用于解决消息提交或者回滚异常。

两阶段提交协议经常被用来实现分布式事务,但是由于其性能问题,导致根本不适合高并发的系统。于是我们引入了消息队列来解决分布式事务。

1.发送半消息。 2.服务端响应消息写入结果。 3. 根据发送结果执行本地事务。 4.根据本地事务状态执行Commit或者Rollback。

RocketMq并不支持任意时间的延时，需要设置几个固定的延时等级，从1s到2h分别对应着等级1到18。

生产者进行消息发送时可以一次发送多条消息，批量发送消息能显著提高传递小消息的性能。单批次消息总长度不能超过4M。

rocketmq 先将不同延时等级的消息存入内部对应延时队列中，然后不断的从延时队列中拉取消息判断是否到期，然后进行投递到对应的topic中。

生产者发送消息发送到同一个queue中。消费者只从这个queue上消费就保证了顺序。当queue只有一个则是全局有序；如果多个queue则为分区有序即相对每个queue，消息都是有序的。

消费模式:集群:消费者组内所有消费者一起消费全量消息,目的提高消费速率,广播:消费者组内每个消费者单独消费全量消息,目的消息共享。消息拉取:推模式:及时+可能导致积压,拉模式:不及时+不积压

同步消息:可靠性,使用较广泛,如重要消息通知、短信通知。 异步消息:延时性,通常用在对响应时间敏感的业务场景，即发送端不能容忍长时间等待Broker响应。 单向消息:不关心结果,例如日志发送。

主从同步配置:同步模式保证尽量不丢消息，性能会有损耗。 异步模式数据同步要求较为宽松，极端情况下可能会丢消息但性能较好。 刷盘策略:追求高性能,异步刷盘。追求数据的安全性,同步刷盘。

1.应用解耦,降低系统之间的强依赖 2.流量削峰,削峰填谷 3.数据分发,降低耦合度 4.异步调用,提高响应时间