remaindertime

说到RocketMq的持久化，我们可能第一时间想到的是Message的持久化，Message通过Broker最终持久化到磁盘的CommitLog文件,但是这仅仅只是将Message进行了存储

前言 在之前对Message在Producer发送、Broker存储、Consumer消费的源码逻辑进行了分析，了解了Message整个生命周期的动态去向。但在面试中常常会被问到一些特殊消息的实现原理

​  前言 是由公司业务改造搜索功能，使用ES搜索引擎中间件，那么我们需要将mysql中的数据同步至ES服务中，最总选择使用alibaba的canal增量订阅和解析工具。

前言 上一篇我们对Consumer的启动流程就进行了解析，有了消费者那么消费的Message从何而来呢，这就是本篇学习的重点。本篇会讲到MessageQueue的分配、Message的拉取以及消费等，

背景 随着业务发展， 用户访问量激增，单台服务器已经无法满足现有的访问压力，研究后需要将后台服务从原来的单台升级为多台服务器，那么原来的访问方式无法满足，所以引入nginx来代理多台服务器，统一请求入

前面我们讲到了生产者的启动以及发送消息到Broker中，然后再到Broker存储消息都进行了源码分析。有了Broekr这个中间“媒人”，那么光有生产者怎么能行呢，我们的消费者是不是也该出场了呢。

前言 在面试中我们经常会听到这样的回答，生产者将message发送给broker服务，然后消费者从broker中获取消息并消费，为了保证message在broker服务中不丢失，mq会对消息数据进行持

前言 上一篇我们已经对RocketMq生产者启动源码进行了学习《从零开始读RocketMq源码(一)生产者启动》那么本篇我们将对生产者发送消息的源码进行学习 准备 如果没看前一篇的，这里还是要强调本篇

前言 大概一年半前自己写了一篇《云原生》一文搞懂RocketMQ队列概述，这篇对rocketmq的相关概念和使用方法进行了整理概述，就像结尾说的都太局限于表面，简单使用还能将就，但一出现问题自己也很难