企业官网建设流程全解析

1. 消息中间件选型：从业务场景倒推技术决策

1.1 为什么消息中间件成了分布式系统的标配

做后端开发这些年，消息中间件几乎是我每个项目都绕不开的基础设施。早些年做单体应用的时候，模块之间直接方法调用就完事了，同步阻塞、强耦合，但业务量小、团队人少，倒也没觉得有什么问题。后来系统开始拆服务，数据库连接数暴涨，一个下单请求要串行调用库存、积分、通知、日志四五个下游服务，响应时间从200毫秒飙到2秒多，高峰期还经常因为某个下游服务超时导致整个链路雪崩。那时候才真正意识到，服务之间的通信方式必须换一种思路。

消息中间件解决的核心问题就三个：异步解耦、削峰填谷、最终一致性。异步解耦是说生产者把消息丢进队列就返回，不用等消费者处理完，下游服务挂了也不影响主流程；削峰填谷是把瞬时高并发请求先积压在队列里，消费者按自己的节奏慢慢消费，避免数据库被打穿；最终一致性则是通过消息重试和事务消息机制，保证跨服务的数据最终能对齐。这三个能力叠加起来，基本上就是分布式系统稳定性的基石。

我见过不少团队在项目初期不重视消息中间件选型，随便挑一个用，结果业务量上来之后各种问题暴露：消息积压几十万条、消费重复导致数据错乱、Broker宕机后消息丢失。这些问题排查起来极其痛苦，因为消息中间件是底层基础设施，一旦出问题影响面是整个业务链路。所以选型这件事，值得在项目启动阶段就认真对待。

1.2 四款主流中间件的定位差异

ActiveMQ、RabbitMQ、RocketMQ、Kafka这四款产品，虽然都叫消息中间件，但设计目标和适用场景差别很大。我习惯用一个类比来理解它们：ActiveMQ像老式邮政系统，功能齐全但效率一般；RabbitMQ像精密的分拣中心，路由灵活、投递可靠；RocketMQ像电商大促的订单处理流水线，高吞吐、强顺序；Kafka像高速公路上的数据传送带，为海量数据流而生。

ActiveMQ是最早一批开源消息中间件，完全支持JMS规范，支持队列和主题两种模式，还支持XA分布式事务。它的优势在于协议支持广泛，AMQP、MQTT、STOMP、OpenWire都能接，适合需要兼容多种客户端协议的场景。但它的单机吞吐量在万级左右，社区活跃度逐年下降，新项目我基本不推荐用了。

RabbitMQ基于Erlang语言开发，天然支持AMQP协议，路由能力是四款里最强的。Exchange有direct、topic、fanout、headers四种类型，配合Binding Key和Routing Key能实现非常灵活的消息分发。它的管理界面做得很好，开箱即用，适合业务逻辑复杂、对消息路由要求高的场景。缺点是Erlang生态相对小众，二次开发门槛高，而且单机吞吐量在几万级，超大规模场景需要做集群分片。

RocketMQ是阿里开源后来捐给Apache的，Java语言开发，天然适合Java技术栈团队。它的核心优势是高吞吐、低延迟、强顺序、支持事务消息。单机吞吐量能到十万级，消息可以严格保证分区顺序，事务消息机制能解决分布式事务问题。电商、金融、物流这类对消息可靠性要求极高的场景，RocketMQ是首选。缺点是社区文档相对Kafka少一些，运维复杂度中等。

Kafka最初是LinkedIn为日志收集设计的，后来发展成流处理平台。它的核心概念是Topic、Partition、Offset，天然支持水平扩展，单机吞吐量能到百万级。Kafka的强项是高吞吐、持久化、流式处理，配合Kafka Streams或Flink能做实时计算。缺点是功能相对单一，不支持事务消息（新版有但语义不同），延迟比RocketMQ高，不适合做业务消息队列。

1.3 选型决策表：什么场景用什么

我把这些年踩过的坑和实际项目经验整理成一张决策表，选型的时候直接对照着看就行：

选型的核心逻辑是：先看吞吐量需求，再看功能需求，最后看团队技术栈。日消息量百万级以下、路由复杂选RabbitMQ；日消息量千万级以上、需要事务消息选RocketMQ；日志采集、流式计算、大数据管道选Kafka；ActiveMQ除非是老系统维护，新项目基本可以跳过。

注意：不要盲目追求高吞吐。我见过一个日活几千的小项目硬上Kafka，结果运维成本比业务开发还高。消息中间件是手段不是目的，够用就好。

2. 核心机制拆解：四款中间件的底层原理

2.1 RabbitMQ的Exchange路由机制

RabbitMQ最核心的设计就是Exchange和Queue的解耦。生产者不直接把消息发给队列，而是发给Exchange，Exchange根据Binding规则把消息路由到一个或多个Queue。这个设计的好处是生产者和消费者完全不知道对方的存在，路由逻辑集中在Exchange层，改路由规则不用动业务代码。

四种Exchange类型各有用途。Direct Exchange根据Routing Key精确匹配，比如订单创建消息Routing Key设为order.create，只有绑定这个Key的队列能收到。Topic Exchange支持通配符匹配，order.*能匹配order.create和order.cancel，order.#能匹配order.create.success，适合做消息分类订阅。Fanout Exchange忽略Routing Key，广播给所有绑定的队列，适合做配置刷新通知。Headers Exchange根据消息头匹配，用得比较少。

实际项目中Topic Exchange用得最多。我之前做一个订单系统，订单状态变更消息用order.status.{orderId}作为Routing Key，下游的库存服务订阅order.status.*，积分服务订阅order.status.paid，通知服务订阅order.status.#，一套消息多个服务各取所需，扩展新服务只需要加一个队列绑定，完全不影响现有逻辑。

消息确认机制是RabbitMQ保证可靠性的关键。生产者端有Publisher Confirm，Broker收到消息后回一个ack，生产者收到ack才认为发送成功。消费者端有Consumer Ack，消费者处理完业务逻辑后手动ack，Broker收到ack才删除消息。如果消费者处理失败或者连接断开，消息会重新入队投递给其他消费者。这两个机制配合使用，基本能保证消息不丢。

提示：Consumer Ack一定要在业务逻辑执行完之后再发，不要在收到消息就ack。我踩过这个坑，消费者收到消息立刻ack，然后业务处理抛异常，消息已经删了，数据就丢了。

2.2 RocketMQ的存储模型与事务消息

RocketMQ的存储设计是它高吞吐的核心。所有消息顺序写入CommitLog文件，不管来自哪个Topic，这样写入是纯顺序IO，速度极快。然后通过ConsumeQueue做索引，每个Topic的每个Queue对应一个ConsumeQueue文件，里面存的是消息在CommitLog中的偏移量、消息大小、Tag哈希值。消费者先读ConsumeQueue找到偏移量，再回CommitLog读实际消息内容。这个设计叫读写分离，写的时候顺序写，读的时候随机读但走PageCache，整体性能很高。

事务消息是RocketMQ区别于其他中间件的重要特性。它的流程分两阶段：生产者先发一条半消息到Broker，这条消息对消费者不可见；然后生产者执行本地事务；本地事务执行成功后向Broker发送Commit，Broker把半消息标记为可消费，消费者才能收到；如果本地事务失败则发送Rollback，Broker删除半消息。如果生产者发送Commit或Rollback失败，Broker会定时回查生产者的本地事务状态，根据回查结果决定Commit还是Rollback。

这个机制解决的是本地事务和消息发送的原子性问题。比如下单扣库存，本地数据库扣减库存和发送扣减积分消息必须同时成功或同时失败。用事务消息就能保证：本地扣库存成功则积分消息一定发出，本地扣库存失败则积分消息一定不发。

// RocketMQ事务消息生产者示例 TransactionMQProducer producer = new TransactionMQProducer("order_producer_group"); producer.setNamesrvAddr("127.0.0.1:9876"); producer.setTransactionListener(new TransactionListener() { @Override public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { // 执行本地事务：扣减库存 boolean success = inventoryService.deductStock(orderId); return success ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE; } @Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { // Broker回查：查询本地事务是否执行成功 boolean success = inventoryService.isStockDeducted(orderId); return success ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE; } }); producer.start();

2.3 Kafka的分区与消费者组模型

Kafka的Topic在物理上分成多个Partition，每个Partition是一个有序的、不可变的消息序列，消息写入时追加到末尾，每条消息有一个唯一的Offset。Partition可以分布在不同的Broker上，这是Kafka水平扩展的基础。一个Topic有3个Partition分布在3个Broker上，吞吐量理论上就是单Broker的3倍。

消费者组是Kafka实现并行消费的机制。同一个消费者组内的多个消费者实例，每个负责消费一部分Partition，一个Partition只能被组内一个消费者消费。如果消费者数量超过Partition数量，多出来的消费者会空闲。所以Partition数量决定了最大并行度，创建Topic时要根据预期消费能力合理设置。

Partition内消息严格有序，但跨Partition不保证顺序。如果需要全局有序，只能把Topic设成单Partition，但这样就失去了并行能力。实际项目中通常是局部有序：比如订单消息用orderId做Partition Key，同一个订单的消息落到同一个Partition，保证单订单有序，不同订单之间并行处理。

# Kafka创建Topic，3分区2副本 kafka-topics.sh --create \ --bootstrap-server localhost:9092 \ --topic order-topic \ --partitions 3 \ --replication-factor 2

副本机制是Kafka保证可用性的关键。每个Partition有1个Leader和多个Follower，生产者和消费者只跟Leader交互，Follower从Leader同步数据。Leader挂了，从ISR（In-Sync Replica）中选一个新Leader。acks参数控制生产者的可靠性：acks=0不等待确认，最快但可能丢消息；acks=1等Leader确认，Leader挂了可能丢；acks=all等所有ISR确认，最可靠但最慢。业务消息建议用acks=all。

2.4 ActiveMQ的JMS规范与持久化

ActiveMQ是JMS规范的完整实现，支持Point-to-Point和Publish/Subscribe两种消息模型。Point-to-Point模式下消息进入Queue，一个消息只能被一个消费者消费；Publish/Subscribe模式下消息进入Topic，所有订阅者都能收到。JMS还定义了五种消息类型：TextMessage、MapMessage、BytesMessage、StreamMessage、ObjectMessage，覆盖了常见的消息格式。

持久化方面，ActiveMQ支持KahaDB、LevelDB、JDBC三种方式。KahaDB是默认的，基于文件索引，性能不错；LevelDB是Google的KV存储，适合高并发；JDBC把消息存数据库，可靠性最高但性能最差。非持久化消息存在内存里，Broker重启就丢，只适合允许丢失的场景。

ActiveMQ的短板在于吞吐量上不去。它的架构设计比较老，单Broker在万级消息量下CPU就开始吃紧。而且社区版本更新缓慢，很多新特性跟不上。我现在只在维护老系统的时候还会用到它，新项目基本不考虑。

3. 实战落地：从环境搭建到生产配置

3.1 RabbitMQ集群搭建与镜像队列配置

RabbitMQ单机版只能用于开发测试，生产环境必须做集群。RabbitMQ集群有两种模式：普通集群和镜像集群。普通集群只同步元数据（Exchange、Queue、Binding的定义），消息实体只存在创建Queue的那个节点上，其他节点收到消息会转发过去。这种模式的问题是，如果Queue所在节点挂了，消息就丢了。镜像集群会把Queue的消息同步到多个节点，可靠性高很多。

搭建镜像集群的步骤：先在多台机器上安装RabbitMQ，确保Erlang Cookie一致，然后加入集群，最后配置镜像策略。

# 节点1 rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl start_app # 节点2加入节点1 rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster rabbit@node1 rabbitmqctl start_app # 配置镜像队列策略：所有队列镜像到所有节点 rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}' --apply-to queues

镜像队列的同步机制是：Master节点处理读写，Slave节点从Master同步数据。生产者发消息给Master，Master同步给Slave后才返回确认。消费者从Master消费，Master删除消息后通知Slave删除。如果Master挂了，最老的Slave会被提升为新Master。

注意：镜像队列会带来额外的同步开销，节点越多性能越差。生产环境建议用3节点集群，ha-mode设为exactly，ha-params设为2，即每个队列有1个Master加1个Slave，兼顾可靠性和性能。

3.2 RocketMQ双主双从部署要点

RocketMQ生产环境推荐双主双从架构，两个NameServer、两个Broker Master、两个Broker Slave。NameServer是无状态节点，互相不通信，Broker向所有NameServer注册，生产者从NameServer拉取Broker地址。Broker Master处理读写，Slave从Master同步数据，Master挂了Slave可以切换为Master继续提供服务。

Broker的配置文件关键参数：

# broker-a.properties brokerClusterName=DefaultCluster brokerName=broker-a brokerId=0 namesrvAddr=192.168.1.1:9876;192.168.1.2:9876 brokerRole=ASYNC_MASTER flushDiskType=ASYNC_FLUSH # 主从同步方式：ASYNC_MASTER异步复制，SYNC_MASTER同步复制 # 刷盘方式：ASYNC_FLUSH异步刷盘，SYNC_FLUSH同步刷盘

brokerRole和flushDiskType是两个关键取舍。同步复制（SYNC_MASTER）保证消息写到Slave才返回成功，可靠性高但延迟大；异步复制（ASYNC_MASTER）Master写完就返回，Slave异步同步，性能好但Master挂了可能丢少量消息。同步刷盘（SYNC_FLUSH）保证消息写到磁盘才返回，异步刷盘（ASYNC_FLUSH）先写PageCache就返回。金融级场景用同步复制加同步刷盘，普通业务用异步复制加异步刷盘。

消息发送的重试机制也很重要。RocketMQ默认同步发送失败重试2次，异步发送失败重试0次。重试时要设置sendMsgTimeout，默认3秒，网络抖动场景可以调到5秒。如果重试还失败，需要业务层做补偿，比如落库记录失败消息，定时任务扫描重发。

3.3 Kafka生产环境参数调优

Kafka生产者的核心参数是acks、retries、batch.size、linger.ms。acks=all保证消息不丢，retries设一个较大的值比如Integer.MAX_VALUE配合delivery.timeout.ms控制总超时。batch.size默认16KB，调大到64KB能提升吞吐但增加延迟；linger.ms默认0，调大到5-100ms能让消息攒批发送，吞吐量提升明显。

Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("acks", "all"); props.put("retries", Integer.MAX_VALUE); props.put("batch.size", 65536); props.put("linger.ms", 20); props.put("buffer.memory", 33554432); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

消费者端关键是enable.auto.commit和auto.offset.reset。enable.auto.commit=true会自动提交Offset，但可能在业务处理完成前就提交了，导致消息丢失。生产环境建议设为false，业务处理完后手动提交。auto.offset.reset在无Offset或Offset越界时生效，earliest从最早开始消费，latest从最新开始，业务消息一般用earliest避免漏消费。

props.put("enable.auto.commit", "false"); props.put("auto.offset.reset", "earliest"); props.put("max.poll.records", 500); // 业务处理完后手动提交 consumer.commitSync();

max.poll.records控制一次poll拉取的最大消息数，默认500。如果单条消息处理耗时长，要调小这个值，否则两次poll间隔超过max.poll.interval.ms（默认5分钟），消费者会被踢出组触发Rebalance。

3.4 消息幂等与去重方案

消息中间件只能保证至少一次投递，不能保证恰好一次，所以消费者必须做幂等处理。幂等的核心思路是给每条消息一个唯一ID，消费前先查这个ID是否处理过，处理过就跳过。

方案一：数据库唯一索引。建一张消息消费记录表，message_id做唯一索引，消费前先insert，插入成功说明没消费过，插入冲突说明已消费。这个方案简单可靠，但每次消费多一次数据库操作。

方案二：Redis去重。用SETNX message_id 1 EX 86400，设置成功说明没消费过，失败说明已消费。性能比数据库好，但Redis挂了可能重复消费，适合对幂等要求不那么严格的场景。

方案三：业务状态机。订单状态从待支付到已支付，更新时加WHERE status='待支付'条件，更新影响行数为0说明已经处理过。这个方案不需要额外存储，但要求业务有状态流转。

-- 方案一：消息消费记录表 CREATE TABLE message_consume_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, message_id VARCHAR(64) NOT NULL, consume_time DATETIME NOT NULL, UNIQUE KEY uk_message_id (message_id) ); -- 消费前先插入 INSERT INTO message_consume_log (message_id, consume_time) VALUES (?, NOW()); -- 插入成功则继续业务处理，插入冲突则跳过

提示：消息ID最好由生产者生成并放在消息头里，不要用消息中间件自带的MessageId。因为消息重试时MessageId会变，但业务消息ID不变，用业务ID才能正确去重。

4. 常见问题排查与避坑经验

4.1 消息积压的应急处理

消息积压是最常见的线上问题，表现是消费Lag持续增长，队列里堆积几十万甚至上百万条消息。原因通常有三个：消费者处理太慢、消费者数量不够、消费者挂了。

应急处理的第一步是定位瓶颈。看消费者CPU和内存是否打满，如果打满说明单机处理能力到顶了，需要扩容消费者。如果没打满，看是不是消费逻辑里有阻塞操作，比如同步调用外部接口、数据库慢查询。

第二步是临时扩容。RabbitMQ可以增加消费者实例，但要注意Queue的Prefetch Count设置，太大导致单个消费者积压，太小导致频繁网络往返。RocketMQ和Kafka可以增加消费者实例，但Kafka的并行度受Partition数量限制，Partition不够要先扩Partition。

第三步是降级处理。如果积压太多短时间消费不完，可以临时把消息转存到数据库或文件，先让队列清空，再慢慢处理转存的消息。这个方案我实际用过一次，大促期间订单消息积压了80万条，临时写了个消费者把消息批量落库，队列清空后再用定时任务慢慢处理，业务基本没受影响。

// RabbitMQ消费者Prefetch设置 channel.basicQos(10); // 每次最多预取10条 // 太大：单消费者积压，其他消费者空闲 // 太小：频繁网络往返，吞吐下降 // 建议值：根据消费耗时调整，一般10-50

4.2 消息丢失的排查链路

消息丢失可能发生在生产者、Broker、消费者三个环节，排查要逐段确认。

生产者端：确认是否用了Confirm机制。RabbitMQ的Publisher Confirm、RocketMQ的SendResult、Kafka的acks=all，都是保证消息到达Broker的手段。如果没开，网络抖动时消息可能丢。

Broker端：确认是否持久化。RabbitMQ的Queue和Message都要设durable，RocketMQ的flushDiskType要设SYNC_FLUSH，Kafka的replication.factor要大于1且min.insync.replicas要大于1。如果Broker挂了重启，非持久化消息就丢了。

消费者端：确认是否手动Ack。如果自动Ack，消费者收到消息就确认，业务处理失败消息已经删了。手动Ack要在业务处理成功后调用，处理失败要Nack或Reject让消息重新入队。

4.3 消费重复的根因与治理

消费重复的根因是消息中间件的至少一次语义。网络超时导致生产者重发、消费者Ack丢失导致Broker重投、Rebalance导致Offset回退，都会造成重复消费。治理思路就是前面说的幂等，但有几个细节要注意。

幂等键的选择：要用业务唯一键，不要用消息中间件的MessageId。比如订单消息用orderId，支付消息用paymentId。如果一条消息包含多个业务操作，每个操作都要有自己的幂等键。

幂等存储的清理：消息消费记录表会越来越大，需要定期清理。可以按时间分区，保留最近7天或30天的记录，更早的归档或删除。Redis去重可以设TTL自动过期。

幂等和事务的配合：如果消费逻辑涉及多个数据库操作，幂等判断和业务操作要在同一个事务里。先insert消费记录，再执行业务操作，同一个事务提交。如果业务操作失败，消费记录也回滚，下次重试还能继续。

@Transactional public void consume(Message message) { // 1. 幂等判断 try { messageLogMapper.insert(message.getBizId()); } catch (DuplicateKeyException e) { return; // 已消费，直接返回 } // 2. 业务操作 orderService.process(message); // 3. 事务提交，消费记录和业务操作一起生效 }

4.4 顺序消息的实现与陷阱

顺序消息在订单、支付、库存场景很常见，但实现起来有不少坑。RabbitMQ本身不支持顺序消息，因为多个消费者并发消费同一个Queue，消息顺序无法保证。要实现顺序，只能单消费者消费单Queue，但这样吞吐量上不去。

RocketMQ支持分区顺序消息，生产者把同一业务ID的消息发到同一个Queue，消费者用MessageListenerOrderly顺序消费。关键是发送时选择Queue要用业务ID做哈希，保证同一业务的消息落到同一Queue。

// RocketMQ顺序消息发送 producer.send(msg, new MessageQueueSelector() { @Override public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) { Long orderId = (Long) arg; int index = (int) (orderId % mqs.size()); return mqs.get(index); } }, orderId);

Kafka的顺序消息靠Partition保证，同一Partition内有序。生产者用业务ID做Partition Key，消费者单线程消费每个Partition。但要注意消费者Rebalance会导致顺序错乱，因为Rebalance后Partition可能分配给不同的消费者，之前没处理完的消息和新消息可能交叉。解决方法是Rebalance时先提交Offset再释放Partition，或者用Kafka的静态成员机制避免频繁Rebalance。

注意：顺序消息和并发消费是矛盾的。要顺序就得牺牲并发，要并发就保证不了全局顺序。实际项目中通常是局部有序，比如同一订单有序，不同订单并行，这样兼顾了顺序和吞吐。

5. 学习路径与笔记整理方法

5.1 四款中间件的学习优先级

如果你刚开始接触消息中间件，我建议的学习顺序是：RabbitMQ → RocketMQ → Kafka → ActiveMQ。RabbitMQ的概念最清晰，Exchange、Queue、Binding这套模型容易理解，管理界面也友好，适合入门。RocketMQ是Java技术栈的，源码可读性强，事务消息和顺序消息是进阶重点。Kafka的概念相对抽象，Partition、Offset、Consumer Group需要花时间理解，但它是大数据领域的标配，值得深入。ActiveMQ放在最后，了解基本概念就行，新项目基本用不上。

学习的时候不要只看文档，一定要动手搭环境。RabbitMQ用Docker一条命令就能跑起来，RocketMQ和Kafka稍微麻烦点但也有Docker镜像。搭好之后写个Demo，生产者发消息、消费者收消息，把Confirm、Ack、重试、死信队列这些机制都手动试一遍，比看十遍文档都管用。

5.2 笔记整理的结构化方法

消息中间件的知识点很散，不做笔记很容易学了后面忘前面。我的笔记结构分四层：概念层、机制层、实操层、问题层。

概念层记录核心术语和模型，比如RabbitMQ的Exchange类型、Kafka的Partition和Offset。机制层记录底层原理，比如RocketMQ的CommitLog存储、Kafka的ISR副本同步。实操层记录配置参数和代码示例，比如生产者和消费者的关键参数、集群搭建步骤。问题层记录踩过的坑和解决方案，比如消息积压怎么处理、消息丢失怎么排查。

每学完一个中间件，画一张架构图，把生产者、Broker、消费者、存储、网络这几个部分的关系画清楚。然后写一个最小可运行Demo，把核心流程跑通。最后整理一份对比表，把四款中间件的相同点和不同点列出来，选型的时候直接查表。

5.3 从会用到底层原理的进阶路线

会用消息中间件只是第一步，真正拉开差距的是底层原理和源码。RabbitMQ的Erlang源码门槛高，可以从AMQP协议入手，理解帧结构和信道复用。RocketMQ的Java源码可读性好，重点看CommitLog写入、ConsumeQueue索引、事务消息回查、顺序消息锁。Kafka的Scala源码可以看Partition Leader选举、ISR同步、Rebalance协议。

进阶的另一个方向是运维和调优。消息中间件的性能瓶颈通常在磁盘IO、网络带宽、PageCache。学会看监控指标：RabbitMQ的队列深度和消费者数量、RocketMQ的CommitLog写入延迟和ConsumeQueue堆积、Kafka的ISR数量和UnderReplicatedPartitions。根据指标调参数，比如RocketMQ的刷盘方式、Kafka的副本同步线程数。

最后是源码级问题排查。线上出问题的时候，日志只能看到表面现象，真正定位根因要看源码。比如RocketMQ消息发送超时，可能是Broker的PageCache繁忙、可能是网络重传、可能是刷盘线程阻塞，看源码才能知道具体卡在哪一步。这个能力需要长期积累，但一旦掌握，排查问题的效率会有质的提升。

我个人在实际操作中的体会是，消息中间件这东西，光看文档学不会，必须上手搭、上手调、上手踩坑。我最早用RabbitMQ的时候，因为没设Prefetch Count，一个消费者把消息全拉走了，其他消费者闲着，队列积压了几万条。后来调了Prefetch，又遇到消费者处理慢导致心跳超时被踢出集群。这些坑踩过一遍，比看任何教程都记得牢。所以建议你在学习的时候，不要怕出错，环境搭起来，参数改起来，日志看起来，问题解决一次，理解就深一层。