不可否认零拷贝对于Rocket MQ的高性能表现有着积极正面的作用，但是笔者认为只是锦上添花，并非决定性因素。Rocket MQ性能卓越的原因绝非零拷贝就可以一言以蔽之。

RocketMQ中关于重置消费位点这一功能的实现浅析，本文力求从整体架构上带你了解其实现原理，并不会细致到到方法级别。

想必你已经了解RocketMQ的设计哲学是，同一时刻同一个Queue只能被一个Consumer持有， 但同一个Consumer可以同时消费多个队列，为了订阅、消费模型的高效

文章结尾一口气说出若干种重复消费的情形。分布式平台上幂等性相关语义的保证，是我们构造安全、可信赖系统的永恒追求。

严格意义上的推送模式在Rocket MQ中其实并不存在。以往的经验告诉我们:推送模式往往需要Broker与Consumer两者建立长链接，Poducer将消息成功发送至Broker后，Broker会源

本文的目的是破除迷信，笔者试图从源码上修正一些市面上大多数文章对Rocket MQ推送模式错误理解。

本文档探讨了改进Java平台中的"序列化"的可能方向。这只是一份探索性文档，并不针对日后Java平台构建任何特定版本中任何特定功能的计划。

截止目前，Rocket MQ的官方文档尚未明确表示自身具备的Crash-Safe的能力。所以这个概念是笔者(掘金-颜如玉)根据自身理解提出的。指明这个事实是因为想象到了有的读者如若遇到“咬文嚼字”老学

Rocket MQ为了兼顾各种场景，所以提供了普通消费和顺序消费两种方式。顺序消息可以保证全局消息投递、消费顺序一致性，适用于消息时间先后敏感的场景，但是大多数情况我们只需要关系业务逻辑是否能正确执行