RocketMQ集群与运维集群搭建方式集群特点集群模式集群的搭建单Master模式多Master模式多Master和Slave模式-异步复制多Master和Slave模式-同步双写运维常见问题集群搭建方式集群特点NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的Broker

RocketMQ一些开发建议生产者消费者Broker客户端配置系统配置动态扩缩容各种故障对消息的影响生产者Tags的使用一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤：message.setTags(“TagA”)。Keys的使用每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可

RocketMQ其他特性（下）消息查询按照MessageId查询消息按照Message Key查询消息消息优先级底层网络通信 - Netty高性能之道Remoting通信类结构协议设计与编解码消息的通信方式和流程Reactor主从多线程模型限流Sentinel 介绍Sentinel原理消息查询区别于消息消费：先尝后买尝就是消息查询买：消息的消费RocketMQ支持按照下面两种维度（“按照Message Id查询消息”、“按照Message Key查询消息”）进行消息查询按照MessageId查询

@TOC消息重试顺序消息的重试对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ 会自动不断进行消息重试（每次间隔时间为 1 秒），这时，应用会出现消息消费被阻塞的情况。因此，在使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。无序消息的重试对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继

RocketMQ其他特性同步复制和异步复制同步复制异步复制配置总结高可用机制消息消费高可用消息发送高可用刷盘机制同步刷盘异步刷盘负载均衡Producer的负载均衡Consumer的负载均衡同步复制和异步复制如果一个Broker组有Master和Slave，消息需要从Master复制到Slave 上，有同步和异步两种复制方式。同步复制同步复制方式是等Master和Slave均写 成功后才反馈给客户端写成功状态；在同步复制方式下，如果Master出故障，Slave上有全部的备份数据，容易恢复，但是同步

RocketMQ零拷贝原理零拷贝原理PageCachecache和buffer的区别HeapByteBuffer和DirectByteBuffer缓冲IO和直接IO内存映射文件（Mmap）直接内存读取并发送文件的过程Mmap读取并发送文件的过程Sendfile零拷贝读取并发送文件的过程零拷贝（zero copy）小结零拷贝原理PageCache由内存中的物理page组成，其内容对应磁盘上的block。page cache的大小是动态变化的。backing store: cache缓存的存储设备

RocketMQ消息特性消息发送消息消费消息存储存储介质关系型数据库DB文件系统存储结构消息过滤消息发送生产者向消息队列里写入消息，不同的业务场景需要生产者采用不同的写入策略。比如同步发送、异步发送、Oneway发送、延迟发送、发送事务消息等。 默认使用的是DefaultMQProducer类，发送消息要经过五个步骤：1）设置Producer的GroupName。2）设置InstanceName，当一个Jvm需要启动多个Producer的时候，通过设置不同的InstanceName来区分，不设置的话

RocketMQ架构与特性简介部署架构RocketMQ特性消费模式Push or PullRocketMQ中的角色及相关术语简介RocketMQ是阿里巴巴中间件团队自研的一款高性能、高吞吐量、低延迟、高可用、高可靠（具备金融级稳定性）的分布式消息中间件，开源后并于2016年捐赠给Apache社区孵化，目前已经成为了Apache顶级项目。当前在国内被广泛的使用，包括互联网、电商、金融、企业服务等领域，包括：字节跳动、滴滴、微众银行等知名的互联网公司。使用场景应用解耦系统的耦合性越高，容错性就越低。

集群应用场景消息传递Kafka可以很好地替代传统邮件代理。消息代理的使用有多种原因（将处理与数据生产者分离，缓冲未处理的消息等）。与大多数邮件系统相比，Kafka具有更好的吞吐量，内置的分区，复制和容错功能，这使其成为大规模邮件处理应用程序的理想解决方案。根据经验，消息传递的使用通常吞吐量较低，但是可能需要较低的端到端延迟，并且通常取决于Kafka提供的强大的持久性保证。在这个领域，Kafka与ActiveMQ或 RabbitMQ等传统消息传递系统相当。网站活动路由Kafka最初的用例是能够将用户

Kafka的延时队列与消息重复解决方案延时队列重试队列消息重复的场景及解决方案生产者阶段重复场景生产者发送重复解决方案生产者和broke阶段消息丢失场景解决生产者和broke阶段消息丢失消费者数据重复场景及解决方案解决方案延时队列设想一下，两个follower副本都已经拉取到了leader副本的最新位置，此时又向leader副本发送拉取请求，而leader副本并没有新的消息写入，那么此时leader副本该如何处理呢？可以直接返回空的拉取结果给follower副本，不过在leader副本一直没有新消息写

Kafka的一致性概念Follower副本何时更新LEOFollower副本何时更新HWLeader副本何时更新LEOLeader副本何时更新HW值HW和LEO正常更新案例HW和LEO异常案例Leader Epoch使用概念水位标记水位或水印（watermark）一词，表示位置信息，即位移（offset）。Kafka源码中使用的名字是高水位，HW（high watermark）。副本角色Kafka分区使用多个副本(replica)提供高可用。LEO和HW每个分区副本对象都有两个重要的属性：L

Kafka的broker选举与可靠性控制器broker选举可靠性保证概念副本的分配：失效副本副本复制控制器Kafka集群包含若干个broker，broker.id指定broker的编号，编号不要重复。Kafka集群上创建的主题，包含若干个分区。每个分区包含若干个副本，副本因子包括了Follower副本和Leader副本。副本又分为ISR（同步副本分区）和OSR（非同步副本分区）。控制器就是一个broker。控制器除了一般broker的功能，还负责Leader分区的选举。broker选举集

Kafka的事务事务事务场景几个关键概念和推导事务语义多分区原子写入粉碎“僵尸实例”事务消息定义事务配置事务概览事务组生产者ID和事务组状态事务协调器事务流程事务的中止基本事务流程的失败主题的压缩事务相关配置Broker configsProducer configsConsumer configs幂等性幂等性幂等性实现事务操作总结事务事务场景如producer发的多条消息组成一个事务这些消息需要对consumer同时可见或者同时不可见 。producer可能会给多个topic，多个partiti

Kafka的日志存储物理存储日志存储概述日志存储索引清理日志删除日志压缩策略磁盘存储零拷贝页缓存顺序写入总结物理存储日志存储概述Kafka 消息是以主题为单位进行归类，各个主题之间是彼此独立的，互不影响。每个主题又可以分为一个或多个分区。每个分区各自存在一个记录消息数据的日志文件。图中，创建了一个 tp_demo_01 主题，其存在6个 Parition，对应的每个Parition下存在一个[Topic-Parition] 命名的消息日志文件。在理想情况下，数据流量分摊到各个 Paritio

Kafka主题与分区主题分区副本的分配分区副本机制Leader选举分区重新分配自动再均衡修改分区副本分区分配策略RangeAssignorRoundRobinAssignorStickyAssignor总结主题分区副本的分配副本分配的三个目标：均衡地将副本分散于各个broker上对于某个broker上分配的分区，它的其他副本在其他broker上如果所有的broker都有机架信息，尽量将分区的各个副本分配到不同机架上的broker。在不考虑机架信息的情况下：第一个副本分区通过轮询的方式挑

Kafka消费者与消费组简介消费者概念入门消费者、消费组心跳机制消息接收必要参数配置订阅反序列化位移提交消费者位移管理再均衡避免重平衡消费者拦截器消费组管理什么是消费者组消费者位移(consumer position)位移管理(offset management)再谈再均衡再均衡过程总结简介上节开了个头，探讨了kafka中的生产者的流程和思想，本节将继续研究消费者特性。消费者概念入门消费者、消费组消费者从订阅的主题消费消息，消费消息的偏移量保存在Kafka的名字是 __consumer_offs

Kafka生产者生产者消息发送数据生产流程解析必要参数配置原理剖析生产者参数配置补充总结生产者消息发送数据生产流程解析Producer创建时，会创建一个Sender线程并设置为守护线程。生产消息时，内部其实是异步流程；生产的消息先经过拦截器->序列化器->分区器，然后将消息缓存在缓冲区（该缓冲区也是在Producer创建时创建）。批次发送的条件为：缓冲区数据大小达到batch.size或者linger.ms达到上限，哪个先达到就算哪个。批次发送后，发往指定分区，然后落盘到bro

Kafka架构Kafka概念和基本架构Kafka介绍Kafka优势Kafka应用场景基本架构消息和批次模式主题和分区生产者和消费者broker和集群核心概念ProducerConsumerBrokerTopicPartitionReplicasOffset副本高级特性解析生产者消息发送数据生产流程解析必要参数配置原理剖析生产者参数配置补充总结Kafka概念和基本架构Kafka介绍Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的

RabbitMQ的集群与运维集群方案原理单机多实例部署集群管理RabbitMQ镜像集群配置负载均衡-HAProxy配置HAProxy监控总结集群方案原理对于无状态应用（如普通的微服务）很容易实现负载均衡、高可用集群。而对于有状态的系统（如数据库等）就比较复杂。业界实践：主备模式：单活，容量对等，可以实现故障转移。使用独立存储时需要借助复制、镜像同步等技术，数据会有延迟、不一致等问题（CAP定律），使用共享存储时就不会有状态同步这个问题。主从模式：一定程度的双活，容量对等，最常见的是读写分离。

RabbitMQ的高级特性前言消息可靠性异常捕获机制AMQP/RabbitMQ的事务机制发送端确认机制持久化存储机制Consumer ACK消费端限流消息可靠性保障消息幂等性处理可靠性分析TTL机制死信队列延迟队列总结前言本节主要介绍一下rabbitMQ的一些高级特性，诸如ttl，延迟，死信队列等。消息可靠性你用支付宝给商家支付，如果是个仔细的人，会考虑我转账的话，会不会把我的钱扣了，商家没有收到我的钱？一般我们使用支付宝或微信转账支付的时候，都是扫码，支付，然后立刻得到结果，说你支付了多少钱，如

RabbitMQ简介与使用背景介绍背景介绍

聊聊消息中间件消息中间件概述分布式架构通信原理SOA架构微服务架构分布式同步通信的问题分布式异步通信模式消息中间件简介消息中间件概念主流消息中间件及选型选取原则RabbitMQRocketMQKafka消息中间件应用场景电商秒杀案例支付宝购买电影票JMS规范和AMQP协议JMS经典模式详解JMS消息体系架构对象模型模式传递方式JMS在应用集群中的问题AMQP协议剖析协议架构AMQP中的概念AMQP 传输层架构简要概述数据类型协议协商数据帧界定AMQP客户端实现JMS客户端总结消息中间件概述分布式架构通信