消息中间件面试题库

生成时间：2026-05-24 20:36

本轮消息中间件面试题（带答案）

【面试题】1. Kafka消息存储的索引机制是怎样的？.index和.timeindex文件分别起什么作用？

【标准答案】

Kafka的消息索引采用稀疏索引设计，包含两种索引文件配合Log Segment实现高效查找。

.index文件（偏移量索引）：

存储offset到物理位置的映射
每条索引记录：8字节offset + 4字节position（物理位置）
紏疏索引：不是每条消息都有索引项，默认每4KB数据生成一条索引
查找流程：二分查找定位索引项 → 从对应物理位置开始顺序扫描 → 找到目标消息

.timeindex文件（时间戳索引）：

存储时间戳到offset的映射
每条索引记录：8字节timestamp + 8字节offset
用于按时间查找消息，比如"查找24小时前的消息"
Consumer重置offset时，指定timestamp会用到此索引

索引配置参数：

properties

# 索引间隔字节，越小索引越密集但内存占用越大
log.index.interval.bytes=4096  # 默认4KB

# 索引文件大小上限
log.index.size.max.bytes=10485760  # 默认10MB

稀疏索引的优势：

内存占用小：索引文件可以全部加载到内存
查找高效：先二分定位粗略位置，再顺序扫描少量消息
平衡了查找效率和内存消耗

面试加分点：

索引文件损坏Kafka会自动重建，从对应的.log文件重新生成
稀疏索引意味着"精确查找需要顺序扫描"，这是Kafka的设计权衡
冷Segment的索引文件也会被mmap映射，但访问时会触发缺页中断

【面试题】2. RabbitMQ的Connection和Channel是什么关系？为什么建议多Channel复用单Connection？

【标准答案】

Connection是TCP连接，Channel是Connection内的轻量级逻辑通道，一条Connection可以承载多个Channel。

Connection职责：

建立客户端与Broker的TCP连接
认证鉴权（用户名密码）
心跳检测维持连接
TLS加密通道
资源消耗大：每条Connection占用一个TCP端口、Broker端内存和文件句柄

Channel职责：

实际的消息发送和接收
每个Channel独立的消息确认流程
每个Channel独立的Consumer
资源消耗小：Broker端只是轻量级对象

为什么多Channel复用单Connection：

减少TCP开销：
- 每条Connection需要TCP握手、认证、心跳维护
- Channel创建销毁成本低，复用Connection避免频繁建连
节省Broker资源：
- Broker为每条Connection维护状态、内存缓冲、文件句柄
- 单Connection多Channel减少Broker压力
提高吞吐：
- 不同Channel可以并行发送消息
- Connection带宽被多个Channel共享利用

最佳实践：

java

// Spring AMQP配置
ConnectionFactory factory = new ConnectionFactory();
Connection connection = factory.newConnection();  // 单Connection

// 业务逻辑用不同Channel
Channel channel1 = connection.createChannel();  // 生产者Channel
Channel channel2 = connection.createChannel();  // 消费者Channel

注意事项：

单Connection的Channel数不宜过多（建议不超过几十个）
Channel共享Connection带宽，高吞吐场景可能需要多Connection
Channel异常不会影响Connection，但Connection断开所有Channel失效

面试加分点：

RabbitMQ Java Client默认Connection自动重连，Channel需要手动重建
生产者和消费者建议用不同Channel，避免相互影响
Connection断开后，未ACK的消息会重回队列

【面试题】3. Kafka Producer的分区策略有哪些？自定义分区器如何设计？热点Key问题怎么解决？

【标准答案】

Kafka Producer决定消息发到哪个分区，默认三种策略，也可自定义。

默认分区策略：

策略	触发条件	分区规则
DefaultPartitioner	有Key	Key哈希 % 分区数
UniformSticky	无Key	随机选择并粘滞
RoundRobin	无Key（旧版）	轮询所有分区

有Key的分区规则：

java

// Key哈希后对分区数取模
partition = Utils.murmur2(keyBytes) % numPartitions

相同Key的消息永远发到同一分区，保证分区有序。

自定义分区器设计：

java

public class OrderPartitioner implements Partitioner {
    @Override
    public int partition(String topic, Object key, byte[] keyBytes,
                         Object value, byte[] valueBytes, Cluster cluster) {
        // 按业务规则分区
        String orderId = (String) key;
        int regionCode = getRegion(orderId);  // 根据订单ID提取区域
        
        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
        int numPartitions = partitions.size();
        
        // 按区域分配分区组
        return (regionCode % numPartitions);
    }
    
    @Override
    public void close() {}
    
    @Override
    public void configure(Map<String, ?> configs) {}
}

// Producer配置
props.put("partitioner.class", "OrderPartitioner");

热点Key问题及解决方案：

问题：某个Key消息量极大，导致对应分区负载过高、消费延迟。

解决方案：

Key打散：在Key后加随机后缀，如orderId_001、orderId_002，分散到多个分区
时间窗口分区：按时间粒度分区，如每分钟一个分区Key
自定义分区器：检测热点Key，动态分配到不同分区
增加分区数：扩容分区，热点压力被分散（但要注意已有数据不迁移）

面试加分点：

Key为null时，新版Producer用粘滞分区策略，会粘滞一个分区直到batch满
分区数变化时，相同Key可能分配到不同分区，破坏顺序性
建议分区数规划好就固定，不要频繁调整

【面试题】4. RocketMQ的DLedger模式是什么？和传统主从架构相比有什么优势？

【标准答案】

DLedger是RocketMQ 4.5+引入的基于Raft协议的高可用架构，解决传统主从架构的自动切换难题。

传统主从架构的痛点：

Master宕机后，Slave无法自动升为Master
需要人工介入或外部脚本切换
切换期间服务不可用或需要客户端改配置
单Master写入，Slave只读，无法充分利用集群资源

DLedger架构设计：

基于Raft协议实现Leader选举和日志复制
多节点组成DLedger Group（通常3节点）
Leader负责写入，Follower同步复制
Leader故障自动选举新Leader（秒级完成）
客户端配置NameServer地址，自动感知新Leader

DLedger核心流程：

Producer发送消息到DLedger Leader
Leader写入本地CommitLog + 复制到Follower
Raft Quorum确认后返回成功（多数节点确认）
Leader故障，Raft协议触发选举
新Leader继续服务，客户端无感知切换

DLedger vs 传统主从：

维度	传统主从	DLedger
自动切换	不支持	支持（秒级）
数据一致性	异步复制可能丢失	Raft强一致
写入可用性	单点风险	Quorum容忍少数节点故障
部署复杂度	低	中（需多节点）
性能	高（异步复制）	中（需等待Quorum确认）

配置示例：

properties

# broker.conf
enableDLegerCommitLog=true
dLegerGroup=group1
dLegerPeers=n0@ip1:port1;n1@ip2:port2;n2@ip3:port3
dLegerSelfId=n0

面试加分点：

DLedger牺牲部分性能换取高可用，适合对数据可靠性要求极高的场景
3节点DLedger可以容忍1节点故障，5节点可以容忍2节点故障
金融、支付等核心业务建议用DLedger，普通业务可用传统主从

【面试题】5. Spring Kafka和Spring RocketMQ分别如何集成？有哪些关键配置和最佳实践？

【标准答案】

Spring提供了Kafka和RocketMQ的集成封装，简化了生产者和消费者的开发。

Spring Kafka集成：

yaml

# application.yml
spring:
  kafka:
    bootstrap-servers: localhost:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
      acks: all
      retries: 3
    consumer:
      group-id: order-consumer
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      auto-offset-reset: earliest
      enable-auto-commit: false  # 手动提交，保证可靠性

java

// 生产者
@Service
public class OrderProducer {
    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;
    
    public void sendOrder(Order order) {
        kafkaTemplate.send("order-topic", order.getId(), order.toJson())
            .addCallback(result -> log.info("发送成功"),
                        ex -> log.error("发送失败", ex));
    }
}

// 消费者
@KafkaListener(topics = "order-topic", groupId = "order-consumer")
public void consume(ConsumerRecord<String, String> record, 
                    @Header(KafkaHeaders.RECEIVED_PARTITION) int partition,
                    Acknowledgment ack) {
    try {
        Order order = Order.fromJson(record.value());
        processOrder(order);
        ack.acknowledge();  // 手动确认
    } catch (Exception e) {
        // 不确认，消息会重试
    }
}

Spring RocketMQ集成：

yaml

# application.yml
rocketmq:
  name-server: localhost:9876
  producer:
    group: order-producer
    send-message-timeout: 3000
    retry-times-when-send-failed: 2

java

// 生产者
@Service
public class OrderProducer {
    @Autowired
    private RocketMQTemplate rocketMQTemplate;
    
    public void sendOrder(Order order) {
        rocketMQTemplate.asyncSend("order-topic", order, 
            new SendCallback() {
                @Override
                public void onSuccess(SendResult result) {
                    log.info("发送成功: {}", result.getMsgId());
                }
                @Override
                public void onException(Throwable e) {
                    log.error("发送失败", e);
                }
            });
    }
}

// 消费者
@Service
@RocketMQMessageListener(topic = "order-topic", 
                          consumerGroup = "order-consumer",
                          consumeMode = ConsumeMode.CONCURRENTLY)
public class OrderConsumer implements RocketMQListener<Order> {
    @Override
    public void onMessage(Order order) {
        processOrder(order);  // 成功自动确认，失败自动重试
    }
}

最佳实践：

实践	Kafka	RocketMQ
消费确认	手动enable-auto-commit=false	自动确认+重试机制
异常处理	捕获异常不ack，触发重试	返回RECONSUME_LATER
幂等设计	消息key+业务去重	消息key+业务去重
并发消费	@KafkaListener并发容器	consumeMode=CONCURRENTLY
顺序消费	单分区单消费者	consumeMode=ORDERLY

面试加分点：

Spring Kafka的@KafkaListener支持批量消费：设置batch=true，方法参数用List
RocketMQ的消息体可以直接用对象，框架自动序列化
生产环境务必关闭自动提交offset，用手动确认保证可靠性

【面试题】6. 消息中间件的安全机制怎么设计？认证、授权、ACL、TLS加密分别如何实现？

【标准答案】

消息中间件在生产环境暴露内网甚至外网，安全机制必不可少。三层防护：认证、授权、加密。

Kafka安全机制：

认证（Authentication）：

properties

# SASL认证配置
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN

# JAAS配置文件
KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin-secret"
    user_producer="producer-secret";
};

授权（ACL）：

bash

# 创建ACL规则
kafka-acls.sh --bootstrap-server localhost:9092 \
  --add --allow-principal User:producer \
  --operation Write --topic order-topic

kafka-acls.sh --bootstrap-server localhost:9092 \
  --add --allow-principal User:consumer \
  --operation Read --topic order-topic \
  --operation Describe --topic order-topic

TLS加密：

properties

ssl.enabled.protocols=TLSv1.2,TLSv1.3
ssl.keystore.location=/path/to/keystore.jks
ssl.keystore.password=changeit
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=changeit

RabbitMQ安全机制：

bash

# 用户和虚拟主机
rabbitmqctl add_user producer producer-pass
rabbitmqctl set_permissions -p /vhost1 producer ".*" ".*" ".*"

# TLS配置（rabbitmq.conf）
listeners.ssl.default = 5671
ssl_options.cacertfile = /path/to/ca_certificate.pem
ssl_options.certfile = /path/to/server_certificate.pem
ssl_options.keyfile = /path/to/server_key.pem

RocketMQ安全机制：

properties

# ACL配置（acl.yml）
globalWhiteRemoteAddresses:
  - 10.10.103.*

accounts:
  - accessKey: producer
    secretKey: producer-secret
    whiteRemoteAddress: ""
    admin: false
    defaultTopicPerm: DENY
    topicPerms:
      - order-topic=PUB
      - order-topic=SUB

安全机制对比：

维度	Kafka	RabbitMQ	RocketMQ
认证方式	SASL（PLAIN/GSSAPI/SCRAM）	内置用户密码	accessKey/secretKey
授权粒度	Topic/Group级别ACL	vhost+用户权限	Topic级别ACL
加密支持	TLS	TLS	TLS（较少用）

面试加分点：

Kafka ACL支持Topic、Group、Cluster多个资源类型，operation包括Read、Write、Describe、Create等
RabbitMQ的vhost是隔离边界，不同vhost完全隔离，相当于"逻辑集群"
生产环境建议：认证+授权+TLS三层防护，最小权限原则

【面试题】7. Kafka消息Schema演进如何处理？Schema Registry是什么？向后兼容和向前兼容的区别是什么？

【标准答案】

消息Schema演进是数据格式变更时保证新旧消费者兼容的关键问题，Schema Registry提供标准化解决方案。

Schema Registry是什么：

Confluent开源组件，管理Kafka消息Schema
Producer发送消息前先注册Schema到Registry
Consumer消费时从Registry获取Schema解析消息
支持多种格式：Avro、JSON、Protobuf

Schema演进流程：

Producer发送新Schema，Registry验证兼容性
Schema注册成功，分配唯一Schema ID
消息只携带Schema ID，不携带完整Schema
Consumer根据Schema ID从Registry获取Schema解析

兼容性规则：

兼容类型	定义	示例
BACKWARD（向后兼容）	新Schema能读旧数据	删除可选字段、添加可选字段
FORWARD（向前兼容）	旧Schema能读新数据	添加可选字段（有默认值）
FULL（完全兼容）	同时满足向后和向前	添加可选字段+默认值、删除可选字段

Avro Schema演进规则：

json

// 原Schema
{
  "type": "record",
  "name": "Order",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"}
  ]
}

// 向后兼容修改：添加可选字段（有默认值）
{
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "currency", "type": ["null", "string"], "default": null}
  ]
}

// 不兼容修改：删除必填字段、修改字段类型
{
  "fields": [
    {"name": "orderId", "type": "string"}  // 删除amount字段，不兼容！
  ]
}

Schema Registry配置：

properties

# Producer配置
schema.registry.url=http://localhost:8081
value.serializer=io.confluent.kafka.serializers.KafkaAvroSerializer

# Consumer配置
value.deserializer=io.confluent.kafka.serializers.KafkaAvroDeserializer
schema.registry.url=http://localhost:8081

面试加分点：

BACKWARD兼容性最常用：新消费者能处理历史数据
Schema Registry支持版本管理，每个Schema有版本号，可回滚
Avro Schema ID嵌入消息头，消息体只包含数据，比携带完整Schema节省空间

【面试题】8. 本地消息表方案是如何实现分布式事务的？和RocketMQ事务消息相比有什么优劣？

【标准答案】

本地消息表是分布式事务的经典方案，核心思路是"本地事务+消息表+定时扫描"。

实现流程：

业务操作+写消息表（同一本地事务）：

sql

BEGIN TRANSACTION;
-- 1. 执行业务操作
UPDATE account SET balance = balance - 100 WHERE id = 1;

-- 2. 写入消息表（同一事务）
INSERT INTO message_table (msg_id, topic, content, status, create_time)
VALUES ('msg_001', 'transfer-topic', '{"to": 2, "amount": 100}', 'PENDING', NOW());

COMMIT;

定时任务扫描消息表：

java

@Scheduled(fixedRate = 5000)
public void scanMessageTable() {
    List<Message> pendingMessages = messageDao.selectByStatus("PENDING");
    for (Message msg : pendingMessages) {
        try {
            mqProducer.send(msg.getTopic(), msg.getContent());
            messageDao.updateStatus(msg.getMsgId(), "SENT");
        } catch (Exception e) {
            // 发送失败，下次扫描重试
            log.error("消息发送失败", e);
        }
    }
}

消费者处理消息：

java

@Consumer(topic = "transfer-topic")
public void processTransfer(Message msg) {
    // 幂等处理：检查是否已处理
    if (transferDao.exists(msg.getMsgId())) {
        return;  // 已处理，跳过
    }
    
    // 执行下游业务
    transferService.addBalance(msg.getToAccount(), msg.getAmount());
    
    // 记录处理状态
    transferDao.saveRecord(msg.getMsgId(), "DONE");
}

关键设计点：

业务操作和写消息表在同一事务，保证原子性
消息表记录消息状态：PENDING → SENT → DONE
定时任务保证最终投递，不怕MQ短暂不可用
消费者幂等处理，防止重复消费

与RocketMQ事务消息对比：

维度	本地消息表	RocketMQ事务消息
依赖	任何MQ	必须RocketMQ
回查机制	定时任务扫描消息表	Broker主动回查
消息可见性	发送成功才可见	半消息暂存，提交后可见
架构复杂度	需建消息表+定时任务	框架内置
适用范围	跨团队、跨MQ	RocketMQ用户

选型建议：

用RocketMQ → 优先事务消息，架构简洁
用其他MQ或跨团队协作 → 本地消息表，通用性强
对实时性要求高 → RocketMQ事务消息，回查更快

面试加分点：

本地消息表本质是把"分布式事务"拆成"本地事务+异步投递"
消息表要设计幂等字段，防止定时任务重复扫描
消息表记录状态和重试次数，超过阈值可人工介入

【面试题】9. RabbitMQ的Federation插件是什么？如何实现跨机房消息同步？

【标准答案】

Federation是RabbitMQ官方插件，实现跨Broker、跨机房的消息同步，解决异地多活和消息备份需求。

Federation架构：

上游Broker（Upstream）：消息源
下游Broker（Downstream）：消息接收方
Federation Exchange/Queue：特殊的Exchange/Queue，从Upstream拉取消息
单向同步：Upstream → Downstream

典型场景：

场景	方案
异地多活	多机房部署Broker，Federation双向同步
数据备份	主Broker Federation到备份Broker
跨团队协作	团队A的Broker Federation到团队B的Broker
跨云迁移	云厂商A的Broker Federation到云厂商B

Federation Exchange配置：

bash

# 启用插件
rabbitmq-plugins enable rabbitmq_federation
rabbitmq-plugins enable rabbitmq_federation_management

# 配置Upstream
rabbitmqctl set_parameter federation-upstream upstream1 \
  '{"uri":"amqp://user:pass@upstream-host:5672","ack-mode":"on-confirm"}'

# 创建Federation Exchange
rabbitmqctl set_parameter federation exchange-federation \
  '{"upstream":"upstream1","exchange":"source-exchange"}'

工作原理：

Downstream创建Federation Exchange
Federation插件在Downstream建立到Upstream的连接
Federation Exchange绑定Upstream的源Exchange
Upstream消息路由到源exchange → Federation插件拉取 → Downstream本地exchange
Downstream消费者正常订阅本地exchange

Federation vs Shovel：

维度	Federation	Shovel
传输方向	单向（Upstream→Downstream）	双向可选
数据源	Exchange或Queue	Queue
消息确认	Upstream确认后才删除	配置确认模式
适用场景	广播同步、异地订阅	点对点迁移、备份
配置复杂度	中等	较低

跨机房部署最佳实践：

单向Federation：主机房→灾备机房，主写备读
双向Federation：两地都可写入，注意消息循环（设置federation-upstream-set避免）
网络优化：专线或VPN，控制带宽避免拥塞
监控：Federation连接状态、消息延迟、同步吞吐

面试加分点：

Federation是"拉取"模式，Downstream主动从Upstream拉消息，不是推送
Federation Exchange可以在Downstream再绑定本地Queue，实现"跨机房订阅"
Shovel适合Queue级别的点对点迁移，Federation适合Exchange级别的广播同步

【面试题】10. 实时计算管道中Kafka的角色是什么？和Flink、Spark Streaming如何配合？

【标准答案】

Kafka在实时计算管道中扮演"数据中枢"角色，是流处理架构的核心组件。

Kafka在实时管道的三种角色：

角色	说明	典型场景
数据采集层	业务数据写入Kafka	日志采集、事件流、埋点数据
数据缓冲层	解耦采集和处理	流量削峰、容错缓冲
数据交换层	流处理结果的输出	实时指标、告警触发、数据同步

Kafka + Flink集成：

java

// Flink Kafka Source
KafkaSource<String> source = KafkaSource.<String>builder()
    .setBootstrapServers("localhost:9092")
    .setTopics("events-topic")
    .setGroupId("flink-consumer")
    .setStartingOffsets(OffsetsInitializer.earliest())
    .setValueOnlyDeserializer(new SimpleStringSchema())
    .build();

DataStream<String> stream = env.fromSource(source, WatermarkStrategy.noWatermarks(), "Kafka Source");

// Flink Kafka Sink
KafkaSink<String> sink = KafkaSink.<String>builder()
    .setBootstrapServers("localhost:9092")
    .setRecordSerializer(KafkaRecordSerializationSchema.builder()
        .setTopic("output-topic")
        .setValueSerializationSchema(new SimpleStringSchema())
        .build())
    .setDeliveryGuarantee(DeliveryGuarantee.EXACTLY_ONCE)
    .build();

stream.sinkTo(sink);

Kafka + Spark Streaming集成：

scala

// Spark Kafka Source
val kafkaParams = Map[String, Object](
  "bootstrap.servers" -> "localhost:9092",
  "key.deserializer" -> classOf[StringDeserializer],
  "value.deserializer" -> classOf[StringDeserializer],
  "group.id" -> "spark-consumer",
  "auto.offset.reset" -> "latest",
  "enable.auto.commit" -> (false: java.lang.Boolean)
)

val stream = KafkaUtils.createDirectStream[String, String](
  ssc,
  PreferConsistent,
  Subscribe[String, String](Array("events-topic"), kafkaParams)
)

// 处理后写入Kafka
stream.map(record => process(record.value()))
  .foreachRDD { rdd =>
    rdd.foreach { message =>
      val producer = new KafkaProducer[String, String](kafkaParams)
      producer.send(new ProducerRecord("output-topic", message))
      producer.close()
    }
  }

端到端Exactly-Once保证：

组件	机制
Kafka	事务消息+幂等Producer
Flink	Kafka Source+Sink+Checkpoint三合一事务
Spark	Structured Streaming+Checkpoint+Kafka事务

Flink Exactly-Once实现：

Kafka Source记录offset到Flink Checkpoint
Kafka Sink使用Flink Kafka Producer的事务模式
Checkpoint完成时，事务提交，offset更新
失败恢复时，从Checkpoint恢复offset和事务状态

实时管道架构示例：

[业务系统] → [Kafka Topic A] → [Flink实时处理] → [Kafka Topic B] → [实时服务]
                                      ↓
                              [Kafka Topic C] → [数据仓库/ES]

面试加分点：

Flink Checkpoint间隔影响吞吐和延迟，建议1秒-5秒
Kafka作为"有状态流"的存储，offset管理是Exactly-Once的关键
热数据Kafka + 冷数据HDFS/S3，形成Lambda架构的实时层

消息中间件面试题库 ​

本轮 消息中间件面试题（带答案） ​

【面试题】1. Kafka消息存储的索引机制是怎样的？.index和.timeindex文件分别起什么作用？ ​

【面试题】2. RabbitMQ的Connection和Channel是什么关系？为什么建议多Channel复用单Connection？ ​

【面试题】3. Kafka Producer的分区策略有哪些？自定义分区器如何设计？热点Key问题怎么解决？ ​

【面试题】4. RocketMQ的DLedger模式是什么？和传统主从架构相比有什么优势？ ​

【面试题】5. Spring Kafka和Spring RocketMQ分别如何集成？有哪些关键配置和最佳实践？ ​

【面试题】6. 消息中间件的安全机制怎么设计？认证、授权、ACL、TLS加密分别如何实现？ ​

【面试题】7. Kafka消息Schema演进如何处理？Schema Registry是什么？向后兼容和向前兼容的区别是什么？ ​

【面试题】8. 本地消息表方案是如何实现分布式事务的？和RocketMQ事务消息相比有什么优劣？ ​

【面试题】9. RabbitMQ的Federation插件是什么？如何实现跨机房消息同步？ ​

【面试题】10. 实时计算管道中Kafka的角色是什么？和Flink、Spark Streaming如何配合？ ​

消息中间件面试题库

本轮消息中间件面试题（带答案）

【面试题】1. Kafka消息存储的索引机制是怎样的？.index和.timeindex文件分别起什么作用？

【面试题】2. RabbitMQ的Connection和Channel是什么关系？为什么建议多Channel复用单Connection？

【面试题】3. Kafka Producer的分区策略有哪些？自定义分区器如何设计？热点Key问题怎么解决？

【面试题】4. RocketMQ的DLedger模式是什么？和传统主从架构相比有什么优势？

【面试题】5. Spring Kafka和Spring RocketMQ分别如何集成？有哪些关键配置和最佳实践？

【面试题】6. 消息中间件的安全机制怎么设计？认证、授权、ACL、TLS加密分别如何实现？

【面试题】7. Kafka消息Schema演进如何处理？Schema Registry是什么？向后兼容和向前兼容的区别是什么？

【面试题】8. 本地消息表方案是如何实现分布式事务的？和RocketMQ事务消息相比有什么优劣？

【面试题】9. RabbitMQ的Federation插件是什么？如何实现跨机房消息同步？

【面试题】10. 实时计算管道中Kafka的角色是什么？和Flink、Spark Streaming如何配合？