海潮的专栏

转自：https://zhuanlan.zhihu.com/p/25069846 感谢原作者RocketMQ原理（1）——服务端组件介绍Jaskey Lam1 年前RocketMQ服务端的组件有三个，NameServer，Broker，FilterServer（可选，部署于和Broker同一台机器）Name ServerName Server是RocketMQ的寻址服务。用于把Broker的路由信

转自：https://zhuanlan.zhihu.com/p/25092361 感谢原作者RocketMQ中有很多独有的概念，其中包括一些术语和角色。理清楚基本的概念是理解原理的第一步，也是对排查生产问题找到线索的必要条件。以下一一介绍笔者认为RocketMQ中最重要的一些概念和术语。--------------------------------------------------------

转自 :https://zhuanlan.zhihu.com/p/25140744RocketMQ是一个分布式具有高度可扩展性的消息中间件。本文旨在探索在broker端，生产端，以及消费端是如何做到横向扩展以及负载均衡的。Broker端水平扩展Broker负载均衡Broker是以group为单位提供服务。一个group里面分master和slave,master和slave存储的数据一样，slav

https://zhuanlan.zhihu.com/p/25140744 中剖析过，consumer的每个实例是靠队列分配来决定如何消费消息的。那么消费进度具体是如何管理的，又是如何保证消息成功消费的（RocketMQ有保证消息肯定消费成功的特性（失败则重试）？本文将详细解析消息具体是如何ack的，又是如何保证消费肯定成功的。由于以上工作所有的机制都实现在PushConsumer中，所以本文的原

RocketMQ原理（4）--消息ACK机制及消费进度管理 - 知乎专栏文中提过，所有的消费均是客户端发起Pull请求的，告诉消息的offset位置，broker去查询并返回。但是有一点需要非常明确的是，消息消费后，消息其实并没有物理地被清除，这是一个非常特殊的设计。本文来探索此设计的一些细节。消费完后的消息去哪里了？消息的存储是一直存在于CommitLog中的，由于CommitLog是以文件为单

RocketMQ的客户端和服务端采取完全不一样的配置机制——客户端没有配置文件，所有的配置选项需要开发者使用对应的配置的setter进行设置。由于现在网上基本找不到一套较为完善的配置文档，今天来讲讲截止至RocketMQ 4.0，客户端已有的所有配置的含义。本文尽可能不深入讨论配置相关的原理和源码（除非笔者认为有必要交代对应的背景），尽可能以最简单的描述说清楚作为一个开发者从使用的角度需要明白的那

RocketMQ的通信协议其实很简单，但是无论是官方的用户手册，还是网上的博客，并没有很清晰简单地把其中所有的内容和原理讲明白。 对于需要扩展其他语言SDK的开发来说，意味着必须要深入到Java源码才能弄懂其概念。笔者通过深入源码，本文希望以尽量简短的语言描述清楚协议的每个字段及其意义。注：现最新版RocketMQ已经可以支持Protobuf协议，但本文只探究默认的基于JSON的协议。无论是发送消

RocketMQ broker服务端以组为单位提供服务的，拥有着一样的brokerName则认为是一个组。其中brokerId=0的就是master，大于0的则为slave。消息同步策略master和slave都可以提供读服务，但是只有master允许做写入操作，slave仅从master同步数据并不断上报自己的同步进度（slave自己的物理max offset）。在Broker配置中，如果是有三