消息发送与数据库事务的先后顺序是分布式系统的关键设计决策，需根据数据一致性等级和系统容错能力权衡。以下是深度分析和实战方案：

一、消息在事务内发送（高危操作）

典型代码结构：

1
2
3
4
5
6
7
8
9
10
11

@Transactional
public void processOrder(Order order) {
    // 1. 数据库操作
    orderDao.insert(order); 
    
    // 2. 事务内发送消息
    mqProducer.send(msg); // ⚠️ 危险操作
    
    // 3. 后续业务操作
    couponService.useCoupon(order.getCouponId()); 
}

致命问题：

1. 消息发送成功但事务回滚

   • 场景：发送消息后useCoupon()抛异常 → 事务回滚
   • 结果：消息已发出但数据库无数据（消费者拿到幽灵消息）

2. 事务提交耗时导致消息延迟

   • MySQL默认事务提交需写binlog（耗时10ms~1s不等）
   • 消息发送被阻塞 → 系统RT陡增

3. 事务超时引发连锁故障

   1 2 3 4

   graph TD A[事务执行30s] --> B{MySQL wait_timeout=30s} B -->|超时| C[自动回滚] C --> D[消息已发送] --> E[数据不一致]

二、消息在事务后发送（推荐方案）

代码结构：

1
2
3
4
5
6
7
8
9
10
11

public void processOrder(Order order) {
    // 1. 执行纯数据库事务
    transactionTemplate.execute(status -> {
        orderDao.insert(order);
        couponService.useCoupon(order.getCouponId());
        return true;
    });
    
    // 2. 事务提交成功后发送消息（⚠️仍有风险）
    mqProducer.send(msg); 
}

潜在风险：

三、终极解决方案：事务型消息

方案1：本地消息表（100%可靠）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Transactional
public void processOrder(Order order) {
    // 1. 业务表和消息表同库事务
    orderDao.insert(order); 
    messageDao.insertLocalMsg(order.getId()); // 同事务写入
    
    // 事务提交后...
}

// 独立线程扫描发送
@Async
public void sendPendingMessages() {
    List<Message> messages = messageDao.getPendingMsgs();
    messages.forEach(msg -> {
        if (mqProducer.send(msg)) {
            messageDao.markAsSent(msg.getId()); // 更新状态
        }
    });
}

优势：

• 消息状态持久化存储，宕机可恢复
• 本地事务保证消息写入原子性

方案2：RocketMQ事务消息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 事务消息发送
public void processWithTransactionMsg(Order order) {
    // 1. 发送半消息（对消费者不可见）
    Message msg = new Message("ORDER_TOPIC", order.toString().getBytes());
    TransactionSendResult sendResult = producer.sendMessageInTransaction(msg, null);
    
    // 2. executeLocalTransaction()中处理数据库事务
}

// 实现事务监听器
class OrderTransactionListener implements TransactionListener {
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        // 在此方法内执行数据库事务（与消息发送解耦）
        orderService.processOrder(msg); 
        return LocalTransactionState.COMMIT_MESSAGE;
    }
}

核心逻辑：

1. Half Message先到达Broker
2. Broker返回成功后执行本地事务
3. 根据事务结果Commit/Rollback消息

四、选型决策树

1
2
3
4
5
6

graph TD
    A[需要强一致性?] -->|是| B{能改数据库Schema?}
    B -->|能| C[本地消息表方案]
    B -->|不能| D[RocketMQ事务消息]
    A -->|最终一致可接受| E[普通消息异步发送]
    E --> F[添加消费端幂等]

各方案对比

五、容灾设计要点

1. 生产端：

   • 本地消息表：增加重试次数限制（避免无限重试）

   1 2	UPDATE message_table SET retry_count=retry_count+1 WHERE status='FAILED' AND retry_count<10

   • RocketMQ：监控RMQ_SYS_TRANS_HALF_TOPIC堆积

2. 消费端：

   -

   强制幂等设计

   （三个维度）：

   1 2 3 4

   boolean isProcessed = redis.setnx("order:"+orderId, "1", 24h); if(isProcessed) { // 业务处理 }

   • 死信队列兜底：人工介入排查

某跨境支付系统实战数据：采用本地消息表方案后，日均2000万笔交易中消息丢失率从0.1%降至0.0001%，事务消息延迟稳定在50ms内。

结论：

• 绝对禁止在数据库事务内直接调用MQ发送
• 核心业务必用事务型消息方案（本地表/RocketMQ事务）
• 非关键业务可用事务后发送+消费端强幂等兜底

RocketMQ事务消息的核心设计是通过”半消息机制+事务状态回查”实现分布式系统的事务最终一致性，以下是深度拆解：

RocketMQ事务消息（核心：消息驱动最终一致）

实现原理（两阶段提交）

1
2
3
4
5
6
7
8
9
10
11
12

sequenceDiagram
    Producer->>Broker: 1. 发送半消息（RMQ_SYS_TRANS_HALF_TOPIC）
    Producer->>Producer: 2. 执行本地事务（如更新订单状态）
    alt 事务成功
        Producer->>Broker: 3a. 提交消息（转存至业务Topic）
    else 事务失败
        Producer->>Broker: 3b. 回滚消息（删除）
    end
    Broker->>Consumer: 4. 投递消息（若已提交）
    loop 状态不明确时
        Broker->>Producer: 5. 定时回查事务状态
    end

关键步骤详解

1. Half Message（半消息）

   • 消息暂时存入RMQ_SYS_TRANS_HALF_TOPIC（消费者不可见）
   • 规避：业务未执行先被消费的问题

2. 本地事务执行

   1 2 3 4 5 6 7 8 9 10 11 12 13

   // 事务监听器伪代码 public class OrderTransactionListener implements TransactionListener { @Override public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { try { // 执行数据库事务（如创建订单） createOrder(arg); return LocalTransactionState.COMMIT_MESSAGE; } catch (Exception e) { return LocalTransactionState.ROLLBACK_MESSAGE; } } }

3. 事务状态回查（兜底机制）

   • 触发场景：生产者宕机/网络超时未返回事务状态

   • Broker行为：

     • 每隔30秒扫描半消息（可配置）
     • 回调生产者的checkLocalTransaction方法

   • 生产者需实现：

     1 2 3 4 5 6 7 8 9

     @Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { // 根据msgKey查询本地事务状态 Order order = orderDao.findByMsgKey(msg.getKeys()); if(order != null && order.getStatus()== PAID) return LocalTransactionState.COMMIT_MESSAGE; else return LocalTransactionState.ROLLBACK_MESSAGE; }

异常场景处理

生产实践最佳方案

1. 事务表设计（支撑回查）

   1 2 3 4 5 6

   CREATE TABLE trans_log ( msg_key VARCHAR(64) PRIMARY KEY, -- RocketMQ消息Key biz_id BIGINT NOT NULL, -- 业务主键 status TINYINT DEFAULT 0, -- 0:未知 1:成功 2:失败 create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

2. 消费者幂等

   1 2 3 4 5 6 7 8 9

   consumer.registerMessageListener((MessageListenerOrderly) (msgs, context) -> { for (MessageExt msg : msgs) { String msgKey = msg.getKeys(); if(redis.setnx("consumed:"+msgKey, "1", 24h)) { processMessage(msg); // 业务处理 } } return ConsumeOrderlyStatus.SUCCESS; });

3. 监控指标

   • RMQ_SYS_TRANS_HALF_TOPIC堆积量
   • 事务回查失败次数（TransactionCheckTimes）
   • 消息Commit/Rollback比例

在阿里云双十一中，该方案支撑每秒20万笔交易事务，端到端延迟<500ms。关键点：本地事务与消息必须共用同一个数据源连接（保证原子性）

代码流程详解

executeLocalTransaction 方法调用时机

当生产者调用 sendMessageInTransaction() 发送事务消息时，RocketMQ 会按以下顺序处理：

1. 发送半消息：消息先发送到 Broker，但此时对消费者不可见
2. 触发本地事务：Broker 确认半消息存储成功后，立即回调生产者的 executeLocalTransaction() 方法
3. 决定消息命运：根据该方法返回值决定后续操作：
   • COMMIT → 提交消息（对消费者可见）
   • ROLLBACK → 删除消息
   • UNKNOWN → 进入回查流程

✅ 典型场景：创建订单时同步执行 DB 事务，根据 DB 事务结果返回 COMMIT/ROLLBACK

checkLocalTransaction 方法调用时机

当出现以下情况时，Broker 会主动发起事务状态回查：

1. 半消息未决超时：executeLocalTransaction() 返回 UNKNOWN 后，默认 60秒 触发首次回查
2. 生产者断连：生产者宕机/网络断开，导致未返回事务状态
3. 定时回查机制：Broker 周期性扫描半消息（默认配置：首次回查间隔 60 秒，后续每 30 秒一次，最多 15 次）

✅ 典型场景：支付超时订单检查，根据订单最终状态决定提交/回滚消息

双方法协作流程

1
2
3
4
5
6
7
8
9
10
11

sequenceDiagram
    Producer->>Broker: 1. 发送半消息
    Broker-->>Producer: 2. 存储成功确认
    Producer->>Producer: 3. 执行 executeLocalTransaction()
    alt 返回 COMMIT/ROLLBACK
        Producer->>Broker: 4. 提交最终状态
    else 返回 UNKNOWN 或超时未响应
        Broker->>Producer: 5. 启动定时回查 (checkLocalTransaction)
        Producer->>Broker: 6. 返回事务最终状态
    end
    Broker->>Consumer: 7. 投递已提交消息

关键设计解析

生产实践建议

1. 事务状态持久化
   在 DB 事务中同步记录事务状态，供回查时使用：

   1 2 3 4 5

   @Transactional public void createOrder(String orderId) { orderDao.insert(order); // 业务数据 txLogDao.insert(orderId, "PENDING"); // 事务状态记录 }

2. 回查幂等设计

   1 2 3 4 5 6 7 8

   public RocketMQLocalTransactionState checkLocalTransaction(Message msg) { String orderId = parseMsg(msg); // 查询事务日志表（非业务表） TxLog txLog = txLogDao.selectById(orderId); if (txLog == null) return ROLLBACK; return "SUCCESS".equals(txLog.getStatus()) ? COMMIT : ROLLBACK; }

3. 超时配置优化（在 Broker 端调整）

   1 2 3 4

   # broker.conf transactionTimeout=20 # 超时阈值(秒) transactionCheckMax=5 # 最大回查次数 transactionCheckInterval=30000 # 回查间隔(ms)

⚠️ 注意：避免在 executeLocalTransaction() 中执行耗时操作，否则可能因超时触发回查导致重复执行！

要解决数据库事务提交与消息发送的原子性问题（避免数据与消息状态不一致），需通过事务消息方案实现两阶段操作的事务保障。以下是经过大规模生产验证的四大方案：

方案1：本地消息表（最经典方案）

核心思想：将消息作为数据库事务的一部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

sequenceDiagram
    participant App
    participant DB
    participant Msg_Table
    participant MQ
    
    App->>DB: 开启事务
    App->>DB: 更新业务数据
    App->>Msg_Table: 插入待发送消息(state=PENDING)
    App->>DB: 提交事务（含数据+消息）
    activate App
    App->>MQ: 发送消息
    alt 发送成功
        App->>Msg_Table: 更新消息状态为SENT
    else 发送失败
        App->>Msg_Table: 标记状态为FAILED
        App->>后台任务: 触发重试
    end
    deactivate App

关键实现：

1. 创建消息事务表

   1 2 3 4 5 6 7 8 9

   CREATE TABLE message_transaction ( id BIGINT AUTO_INCREMENT PRIMARY KEY, biz_id VARCHAR(64) NOT NULL, -- 业务ID(如订单号) topic VARCHAR(255) NOT NULL, payload TEXT NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0:待发送 1:已发送 2:失败 retry_count INT DEFAULT 0, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

2. 使用Spring事务管理器保证原子性

   1 2 3 4 5 6 7 8

   @Transactional public void executeBusiness(String orderId) { // 1. 更新业务表 orderDao.updateStatus(orderId, PAID); // 2. 写入本地消息表 (同一个事务) messageDao.insertMessage(new Message(orderId, "payment_success", ...)); }

3. 独立线程池异步发送+重试

   1 2 3 4 5 6 7 8 9 10 11 12

   // 独立线程池，轮询本地消息表，发送到MQ，如果失败则重试 @Scheduled(fixedDelay = 10000) public void retryFailedMessages() { List<Message> messages = messageDao.findFailedMessages(); messages.forEach(msg -> { if (mqProducer.send(msg)) { messageDao.updateStatus(msg.id, SENT); } else { messageDao.increaseRetryCount(msg.id); } }); }

方案2：RocketMQ事务消息（无侵入方案）

架构优势：无需自建消息表，依赖MQ中间件能力

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// 事务消息生产方
TransactionMQProducer producer = new TransactionMQProducer("GROUP");
producer.setTransactionListener(new TransactionListener() {
    // 执行本地事务
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
            // 1. 解析业务参数
            Order order = parseOrder(msg);
            
            // 2. 执行数据库事务（关键：与事务消息绑定）
            orderService.payOrder(order);
            
            return LocalTransactionState.COMMIT_MESSAGE;
        } catch (Exception e) {
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    }

    // 事务回查（兜底），
    // 这里根据业务状态来检查是继续发送消息还是回滚消息
    // 如果订单已经支付，代表数据库写入成功，可以继续发送消息，否则回滚消息
    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        String orderId = msg.getKeys();
        Order order = orderService.getById(orderId);
        return order.isPaid() ? 
            LocalTransactionState.COMMIT_MESSAGE :
            LocalTransactionState.ROLLBACK_MESSAGE;
    }
});

// 发送事务消息
Message msg = new Message("PAY_TOPIC", order.toString().getBytes());
producer.sendMessageInTransaction(msg, null);

防丢失设计：

1. 半消息先存Broker（消费者不可见）
2. 生产者确认本地事务状态（COMMIT/ROLLBACK）
3. Broker未收到确认时主动回查
4. 消息持久化到磁盘+同步复制到Slave

方案3：事务同步监听（MySQL Binlog方案）

适用场景：无法修改业务代码的遗留系统

1
2
3
4

graph LR
    A[业务DB] -->|Binlog| B[Canal Server]
    B --> C[RocketMQ]
    C --> D[业务消费者]

实现步骤：

1. 部署Canal Server捕获MySQL变更

2. 过滤关键业务表的UPDATE事件

   1 2 3 4 5 6 7 8 9

   // Canal消息处理器 public void handleBinlogEvent(Event event) { if (isOrderPaidEvent(event)) { // 构造领域事件消息 PaymentEvent paymentEvent = buildEvent(event); // 发送消息到MQ mqProducer.send(new Message("ORDER_PAID", paymentEvent)); } }

3. 消费方实现幂等处理

   1 2 3 4 5

   consumer.subscribe("ORDER_PAID", (msg) -> { String uniqueId = msg.getProperty("biz_id"); if(idempotentChecker.processed(uniqueId)) return; paymentService.handlePaymentEvent(msg); });

优势：业务代码零改造
​时延​：毫秒级（取决于Binlog解析速度）

方案4：最大努力通知（最终一致）

适用场景：可接受分钟级延迟的非核心业务
​架构设计​：

1. 事务成功后先写Redis标记状态

   1	SET order:1001:msg_pending "1" EX 600 # 10分钟有效期

2. 定时任务轮询补偿

   1 2 3 4 5 6 7 8 9 10 11

   @Scheduled(fixedRate = 60000) public void notifyDownstream() { Set<String> pendingOrders = redis.keys("order:*:msg_pending"); pendingOrders.forEach(orderId -> { Order order = orderService.getById(orderId); if (order.isPaid()) { boolean success = notifyService.sendPaymentMsg(order); if(success) redis.del("order:"+orderId+":msg_pending"); } }); }

方案选型建议

避坑指南：

1. 消费方必须实现幂等（通过业务唯一ID）
2. 本地消息表方案要控制重试次数（避免无限循环）
3. 事务消息方案需建立消息状态监控大盘
4. 所有方案都需要设计消息TTL（避免积压）

某电商支付系统数据：采用方案1后，在订单量日均1000万的场景下，消息丢失率从0.1%降至0.0001%，事务补偿延迟<500ms。核心关键点：将消息存储与业务数据放在同一个数据库事务中。

蚂蚁国际

• 如何保证数据库事务提交和发消息之间的一致性，避免出现消息发出失败导致数据跟消息不同步的问题

  通常采用本地消息表或事务消息机制。

  本地消息表方案：

  • 在数据库操作的同一事务下，先写入业务数据，再插入一条一条待发送的消息到本地消息表。只有事务提交成功，消息才正式入库；
  • 异步任务根据消息表轮询发送消息，并记录发送状态，如果投递失败，则进行重试，直至投递成功。
  • 消息消费与幂等处理：下游服务在消费消息时需支持幂性，避免重复处理带来数据的不一致性。
  • 状态监控与告警：通过状态字段和定时检检测机制，若消息长时间未投递成功，则触发告警或人工干预。

  

  事务消息（如MQ支持的二阶段提交）：将消息投递与数据库事务结合，如使用阿里MQ、RocketMQ的事务消息，业务操作与消息发送联合提交，仅当两者均成功才算完成。

  补偿机制：通过异步定时任务扫描消息表，补发未送达或异常状态的消息，确保不因短暂故障丢失数据。

• 消息发送是放在事务里面还是事务外面？能讲讲理由和考虑吗？

  消息一般放在本地事务提交之后，即“事务外”发送。原因是如果消息放在事务内，事务提交前即发送则一旦事务回滚，消息已不可靠的发出，会出现数据与消息同步风险。事务外发送则先提交则先提交数据库，可以通过补偿机制（如消息重试、失败消息表、DeadLetterQueue、人工兜底）保障后续一致性。

• 介绍下事务消息的原理，如何保证数据库事务与消息的一致性的？

• 事务消息在第二阶段提交时，消息队列的commit操作失败，这个消息是否会一直处于半成功状态（half process）状态

  不会

  • Broker内置事务回查线程，默认每30秒扫描半消息队列（RMQ_SYS_TRANS_HALF_TOPIC）
  • 发现未Commit的消息 → 主动回调生产者实现的checkLocalTransaction()方法

  1 2 3 4

  // Broker配置示例（broker.conf） transactionCheckInterval=30000 // 回查间隔(ms) transactionTimeOut=60000 // 消息超时时间(ms) transactionCheckMaxCount=5 // 最大回查次数

  消息生命周期兜底

  状态	处理机制
  滞留超过60秒	首次触发回查
  连续5次回查无果	自动视为失败 → 移至死信队列
  消息存储超7天(默认)	Broker物理删除

• 事务消息：能梳理一下从事务开启、发送消息到事务结束，整个流程的具体每一步动作是什么吗？

  分为消息预发送、事务执行、事务提交确认三个阶段，以保证数据库操作与消息发送的一致性

  • Producer发送一条“半消息”（Half Message)，消息队列记录该消息但不会立即投递给消费者
  • 执行业务操作：Producer本地开启事务，进行如订单创建等操作；如果数据库操作出现异常，则回滚并告知消息队列取消“半消息”
  • 消费端执行：下游系统收到消息后根据实际业务进行处理，并可以通过幂等或补偿机制确保处理可靠。
  • 消息队列通常有超时与回查机制，避免“半消息”长期滞留影响下游

• 用过哪些分布式事务的中间件，介绍下他们的原理

  除订单、支付等数据一致性要求高的场景，一般采用最终一致性方案

  RocketMQ

  两阶段提交 2PC

  三阶段提交 3PC

  Seata

• 分布式事务中间件Seata的原理

• 分库分表，设计一个订单表，根据什么维度来分库分表

  最常见通过用户ID、业务单号、时间等。

• 如果是基于user ID做订单表分库分表的情况下，如果需要查某个商户的全部交易数据，怎么实现

  每条交易数据冗余记录商家ID字段，并为商家ID建立二级索引

• 分库分表如何设计

• 如何保证分布式ID不会出现重复，从而保证唯一性

• MySql的乐观锁与悲观锁，如何实现的？

  悲观锁：SELECT * FROM table WHERE id = 1 FOR UPDATE;

  乐观锁：UPDATE table SET name='xxx', version=${version}+1 WHERE id = 1 AND version = ${version}

• 介绍下Redis分布式锁，redis的set跟setNX有什么区别

  • SetNX (SET if Not eXists) 是旧命令，不能同时设置过期时间，需要额外使用EXPIRE来设置时间；而这2个命令不是原子性的！如果在执行完SetNX后、执行EXPIRE前系统崩溃了，那么锁永远不会释放
  • Set是新命令：可以使用一条原子命令设置键值并指定过期时间，完美的解决了SetNX+EXPIRE非原子性的问题。

• 除了redis，还有哪些可以作为分布式锁

  ZooKeeper (ZK):

  • 实现： 利用其临时有序节点。所有客户端尝试在指定目录下创建临时有序节点（如 lock-0000000001）。客户端检查自己创建的节点是否是当前目录下序号最小的节点，如果是，则获得锁；如果不是，则向序号比自己小的上一个节点注册Watcher监听其删除事件（被动等待锁释放通知）。持有锁的客户端完成业务后主动删除自己创建的节点（锁自动释放，因为它是临时节点）。释放锁会触发监听者的回调。
  • 优势： 强一致性（CP模型），原生有序节点实现公平锁，临时节点避免死锁，Watch机制实现阻塞等待。
  • 劣势： 性能低于Redis（网络通信和ZK节点操作较重），需要额外维护ZK集群。

  etcd:

  • 实现： 利用其 Lease（租约）机制和键的 Revision（全局修订版号）。客户端创建一个Lease（指定TTL），然后尝试往一个指定键下写入数据（存储唯一标识），并关联这个Lease（lease_id）并设置 prev_kv=true（类似CAS）。如果写入成功（表示key不存在或版本匹配），则获得锁。Lease会由etcd在TTL到期后自动删除关联的键值对释放锁（防死锁）。客户端可以通过KeepAlive续租维持锁。判断是否获取锁是通过Revision实现的。
  • 优势： 提供强一致性（基于Raft协议），高可用（通常部署集群），Lease机制天然解决锁超时释放问题。
  • 劣势： 部署和配置比Redis略复杂，相对较新一些。

• 对比下redis分布式锁跟zookeeper分布式锁

  redis：AP，实现简单，非公平锁；极端情况会出现主从不一致的问题，锁未同步导致丢失，导致多个请求拿到锁。

  zookeeper：强一致性（CP模型），原生有序节点实现公平锁，临时节点避免死锁，Watch机制实现阻塞等待（不需要不断重复尝试获取锁）

• Redlock算法？

滴滴

• HashMap JDK1.7跟1.8的区别

  特性	JDK 1.7	JDK 1.8
  数据结构	数组 + 单向链表	数组 + 单向链表/红黑树（链表>8时树化）
  插入方式	头插法（可能死循环）	尾插法（避免死循环）
  哈希算法	多次位扰动（4次位运算+5次异或）	简化扰动（1次位运算+1次异或）
  扩容机制	先扩容再插入	先插入再扩容（判断是否需要扩容）
  节点重哈希	全部重新计算索引（indexFor）	无需全重算，通过高位判断新位置

  核心优化：

  • 树化：链表过长时转为红黑树（阈值=8），查询时间复杂度从 O(n) 降至 O(log n)。
  • 尾插法：解决多线程下扩容死循环问题（非线程安全本质未变）。
  • 扩容优化：新索引 = 原位置 或 原位置+旧容量（通过 (e.hash & oldCap) == 0 判断）。

• 锁升级过程，分别占用了什么资源

• 介绍下ThreadLocal，以及有什么问题

• 线程池的参数，以及流程

  参数	说明
  corePoolSize	核心线程数（即使空闲也保留）
  maximumPoolSize	最大线程数（任务队列满时启用）
  keepAliveTime	非核心线程空闲存活时间
  workQueue	任务队列（ArrayBlockingQueue等）
  threadFactory	线程创建工厂（可定制线程名等）
  handler	拒绝策略（AbortPolicy、CallerRunsPolicy等）

  执行流程：

  1. 提交任务 → 核心线程未满 → 创建线程执行。
  2. 核心线程已满 → 任务入队列。
  3. 队列满且线程数 < maxPoolSize → 创建非核心线程执行。
  4. 线程数 = maxPoolSize 且队列满 → 触发拒绝策略。

  拒绝策略示例：

  • AbortPolicy：抛 RejectedExecutionException（默认）。
  • CallerRunsPolicy：由提交任务的线程执行任务。

• 从业务层和中间件出发（以kafka为例）如何防止消息丢失，以及如何防止消息重复消费

  防丢失：消费者关闭自动提交，手动提交offset；异常消息放到死信队列，交给人工处理等

• 如何保证缓存跟数据库的一致性（延迟双删，或者binlog异步消费更新缓存）

  方案	优点	缺点
  延迟双删	实现简单	强依赖延迟时间（可能仍有不一致）
  binlog异步消费	最终一致性强（无业务侵入）	架构复杂（需监听binlog的组件如Canal）

  延迟双删步骤：

  1. 删除缓存
  2. 更新数据库
  3. 延迟一定时间（如500ms）后再次删除缓存（清理期间读请求加载的脏数据）

  binlog方案：

  1. 数据库更新 → binlog记录变更。
  2. Canal监听binlog → 发送MQ → 消费服务更新缓存。

  关键点：

  • 允许短暂不一致（根据业务容忍度选择方案）。
  • 避免”先删缓存再更新DB“的并发问题（旧数据回填）。
  • 使用 分布式锁 控制并发读写（仅必要时）。

HashKey

• 请设计一个高并发的系统，前端后端如何优化

  高并发系统设计需从架构、基础设施和代码层优化，确保可扩展性和低延迟：

  • 前端优化：
    • CDN（内容分发网络）：缓存静态资源（如图片、CSS、JS），分散用户请求到边缘节点，减少源服务器压力。
    • 异步加载：使用AJAX或WebSockets实现部分页面刷新，减少全页请求。
    • 资源压缩：压缩图片（WebP格式）、JS/CSS文件，减少传输大小。
    • 浏览器缓存：设置HTTP缓存头（如Cache-Control），复用静态资源。
    • 懒加载：延迟非核心资源（如滚动时加载图片），提高首屏速度。
  • 后端优化：
    • 负载均衡：使用Nginx或HAProxy分发请求到多个应用服务器，避免单点故障。支持动态扩缩容。
    • 服务拆分：微服务架构（如Spring Cloud），分离功能模块（如用户服务、支付服务），降低耦合。
    • 缓存策略：
      • Redis/Memcached缓存热点数据（如用户会话、商品信息）。
      • 本地缓存（如Caffeine）减少远程调用。
    • 数据库优化：
      • 分库分表：水平分片（如按用户ID哈希）处理大数据表；垂直分表拆分大字段。
      • 读写分离：主库写，多个从库读，配合复制（如MySQL Replication）。
    • 异步处理：消息队列（如Kafka或RabbitMQ）解耦耗时操作（如日志、邮件发送），提高响应速度。
    • 连接池与线程池：使用HikariCP数据库连接池、Java ThreadPoolExecutor，复用资源，避免创建开销。
    • 地理分布：多机房部署，结合DNS或全局负载均衡（如AWS Global Accelerator），减少延迟。
    • 容错机制：熔断（如Hystrix）、降级（非核心功能兜底）、自动扩缩（如Kubernetes）。
  • 监控与测试：
    • 监控工具：Prometheus + Grafana跟踪QPS、延迟。
    • 压测：使用JMeter或k6模拟高负载，验证优化效果。
      关键点：优化需结合实际业务（如电商系统侧重缓存，金融系统侧重分布式事务），基准是RPS（每秒请求数）提升和P99延迟降低。

• Kafka是如何保证顺序性

  Kafka通过分区（Partition）机制保证消息顺序性：

  • 分区内有序：每个Partition是一个FIFO队列，消息写入和消费严格有序。
  • Producer端：消息发送时指定key（如订单ID），相同key通过哈希函数路由到同一Partition，确保同key消息顺序。
  • Consumer端：每个Partition由一个Consumer实例消费，保证Partition内顺序处理；Consumer Group协调多Consumer并行，但每个Partition仅被一个Consumer占用。
    ​示例​：订单创建、支付、完成事件，按订单ID分发到同一Partition，确保处理顺序。
    ​注意​：全局顺序需所有消息进一个Partition，但会牺牲并发，故通常仅关键数据保证顺序。

• Kafka如何保证消息不丢失的

  消息不丢失需Producer、Broker、Consumer三端保障：

  • Producer端：
    • acks=all：Producer需所有ISR（In-Sync Replica）副本确认写入成功。
    • 重试机制：retries=Integer.MAX_VALUE，自动重试发送失败消息。
    • 幂等性：enable.idempotence=true避免网络重试时消息重复。
  • Broker端：
    • 副本机制：Topic设置replication.factor >= 2，数据多节点冗余。
    • 持久化：消息写入磁盘（日志文件），避免内存丢失。
    • ISR机制：Leader副本仅同步给ISR列表中的Follower，确保多数副本一致。
  • Consumer端：
    • 手动提交Offset：enable.auto.commit=false，业务处理成功后显式commit()，避免未处理即提交。
    • Exactly-Once语义：事务API（Kafka >=0.11）保障消费原子性。
      ​风险点​：Broker宕机需快速恢复（如Kafka Controller选举），分区重平衡可能导致短暂丢失，可结合min.insync.replicas配置提升安全性。

• 【线上】kafka如果遇到大量消息堆积，怎么办？

  短期应急：

  • 扩增Consumer Group实例数，提升并行度（需保证分区数>=Consumer实例数，多余的消费者无效）
  • 写一个分发的程序，将topic均匀分发到临时topic
  • 同时起N台消费者，消费不同的临时Topic

  长期优化：

  提高消费并行度：批量消费，一次拉取更多的消息，多线程消费；Consumer内缓存消息分批处理，减少网络IO。

  架构调整：重试队列，异常消息写入死信队列，重试或人工处理，避免阻塞主流程；检查分区数据倾斜，调整key哈希逻辑。

• 高并发修改一个变量或多个变量，如何实现

  单机环境：synchronized、ReentrantLock、volatile变量确保可见性

  分布式环境：redis SetNX分布式锁；一致性协议，用Raft/Paxoss（如etcd），但开销大

  优化策略：

  减少竞争

  • 乐观锁
  • 分治：变量分片（如用户ID哈希到不同锁实例）

  无状态设计：转换变量为事件源（Event Sourcing），通过消息队列串行处理。

• Websocket跟Http的区别，Websocket如何实现监听某一个topic

  特性	HTTP	WebSocket
  协议模型	请求-响应（半双工）	双向通信（全双工）
  连接方式	短连接（无状态）	长连接（持握后保持）
  通信模式	客户端主动发起	服务端可主动推送
  开销	HTTP头大（每请求冗余信息）	初始握手后帧头小
  使用场景	API调用、网页加载	实时应用（聊天、游戏、监控）

  WebSocket协议本身无Topic概念，需应用层实现：

  • 连接时订阅：客户端通过握手后的消息指定Topic，如JSON消息：

    1	{"action": "subscribe", "topic": "stockUpdates"}

  • 服务端映射：服务端维护连接池（如Map<topic, List<WebSocketSession>>），根据Topic广播消息。

  • 框架支持：Spring WebSocket的@SubscribeMapping("/topic/stockUpdates")，STOMP协议内置Topic路由。
    ​核心​：Topic是逻辑分区，由后端代码和客户端协议约定。

• redis分布式锁，如果业务超时，阻塞别的业务怎么办

  setNX添加EXPIRE过期时间，如果业务没处理完，要么自动续期，要么强制timeout，释放锁

• 如果业务没处理完，redis分布式锁过期了怎么办

  守护线程定期续期（Redission的看门狗机制），超时钱刷新TTL

• Redis WATCH命令

  Redis WATCH用于乐观锁机制，确保事务期间键不被修改

  机制：

  • WATCH key监控键，启动事务（MULTI）。
  • 执行事务命令（EXEC）前，若键被其他客户端修改，事务失败（返回nil）。
  • 基于CAS（Compare and Swap），无锁并发控制。

  用例：如银行转账，保证余额一致：

  1 2 3 4 5

  WATCH balance:user1 balance:user2 MULTI DECRBY balance:user1 100 INCRBY balance:user2 100 EXEC # 若balance在WATCH后变化，EXEC失败

  限制：

  • 非原子事务：失败需重试（循环逻辑），增加代码复杂度。
  • 性能：监控多键时，冲突可能频繁。
    ​替代​：高并发场景更适合分布式锁或数据库事务。

• 如何在1s中处理100w条交易数据

  架构设计：

  数据分片：哈希分片（按照用户ID）到多节点，并行处理（100个节点各处理1w条）

  单个节点的优化：

  批量操作：批量插入数据库（Batch INSERT）、批量提交（如Kafka batch.size）

  异步IO：非阻塞读写（如NIO）、线程池处理

  数据库优化：向量化写入（如ClickHouse）、列式存储

  估算：

  100w/1s/1000节点，每个节点处理1000TPS

  假设单节点，单核处理100TPS，需10个线程。

• 线程池的参数，worker类里面的属性，线程什么时候会被回收，返回什么属性会被回收

  Worker类属性：内部类Worker（实现Runnable）管理线程：

  • thread：持有的线程实例（通过Factory创建）。
  • firstTask：初始任务（可为null）。
  • completedTasks：完成任务计数。

  什么条件下线程会被回收：

  当getTask()方法返回null的时候，线程将会被回收；因为getTask()方法是被runWorker方法调用，在runWorker方法中，如果getTask()返回null，则线程会自动销毁：processWorkerExit

  getTask()方法注释：Returns: task, or null if the worker must exit, in which case workerCount is decremented

  • 线程在workQueue.poll(keepAliveTime, ...)超时后返回null
  • 线程退出runWorker()循环，结束run()方法。
  • 线程对象失去引用，由JVM垃圾回收。

• MySql 5亿数据如何优化，加速查询

  考虑ES

• redis几种数据结构

• redis 2个100万数据的set求交集，大概花费多久时间

  预计5-30ms（不考虑网络传输耗时），百万级别哈希查找在内存中极快。

  SINTER set1 set2命令，Set底层为哈希表结构，求交集时Redis采用双重遍历+哈希查找

  1. 先找到最小的集合（若大小接近则任选其一）
  2. 遍历最小集合的每个元素，在其他集合中哈希查找（O(1) 操作），如果再任意一个其他集合中没有找到，直接跳到下一个元素
  3. 时间复杂度近似 O(M*N)

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

  // Redis 7.0 源码片段 (t_set.c) void sinterGenericCommand(client *c, robj **setkeys, unsigned long setnum) { // 步骤1：找出最小集合 robj *minset = NULL; long minsize = LONG_MAX; for (j = 0; j < setnum; j++) { if (setTypeSize(sets[j]) < minsize) { minset = sets[j]; minsize = setTypeSize(sets[j]); } } // 步骤2：遍历最小集合元素 setTypeIterator *si = setTypeInitIterator(minset); while ((encoding = setTypeNext(si, &curobj)) != -1) { int ismember = 1; // 检查元素是否存在于所有其他集合 for (j = 0; j < setnum; j++) { if (sets[j] == minset) continue; if (!setTypeIsMember(sets[j], curobj)) { // 哈希查找 O(1) ismember = 0; break; } } if (ismember) addReplyBulk(c, curobj); } setTypeReleaseIterator(si); }

妈妈再也不担心我面试被Redis问得脸都绿了

前言

Redis 作为一个开源的，高级的键值存储和一个适用的解决方案，已经越来越在构建 「高性能」、「可扩展」 的 Web 应用上发挥着举足轻重的作用。

当今互联网技术架构中 Redis 已然成为了应用得最广泛的中间件之一，它也是中高级后端工程 技术面试 中面试官最喜欢问的工程技能之一，不仅仅要求着我们对 基本的使用 进行掌握，更要深层次地理解 Redis 内部实现 的细节原理。

熟练掌握 Redis，甚至可以毫不夸张地说已经半只脚踏入心仪的公司了。下面我们一起来盘点回顾一下 Redis 的面试经典问题，就不要再被面试官问得 脸都绿了 呀！

• Ps：我把 重要的知识点 都做成了 图片，希望各位 **”用餐愉快”。(不错记得付餐费.. 点个赞留个言..)

一、基础篇

■什么是 Redis ？

先解释 Redis 基本概念

Redis (Remote Dictionary Server) 是一个使用 C 语言 编写的，开源的 (BSD许可) 高性能 非关系型 (NoSQL) 的 键值对数据库。

简单提一下 Redis 数据结构

Redis 可以存储 键 和 不同类型数据结构值 之间的映射关系。键的类型只能是字符串，而值除了支持最 基础的五种数据类型 外，还支持一些 高级数据类型：

“

一定要说出一些高级数据结构 *(当然你自己也要了解.. 下面会说到的别担心)*，这样面试官的眼睛才会亮。

Redis 小总结

与传统数据库不同的是 Redis 的数据是 存在内存 中的，所以 读写速度 非常 快，因此 Redis 被广泛应用于 缓存 方向，每秒可以处理超过 10 万次读写操作，是已知性能最快的 Key-Value 数据库。另外，Redis 也经常用来做 分布式锁。

除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

■Redis 优缺点

优点

• 读写性能优异， Redis能读的速度是 110000 次/s，写的速度是 81000 次/s。
• 支持数据持久化，支持 AOF 和 RDB 两种持久化方式。
• 支持事务，Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作合并后的原子性执行。
• 数据结构丰富，除了支持 string 类型的 value 外还支持 hash、set、zset、list 等数据结构。
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库 容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。
• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了 系统的可用性。
• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

■为什么要用缓存？为什么使用 Redis？

提一下现在 Web 应用的现状

在日常的 Web 应用对数据库的访问中，读操作的次数远超写操作，比例大概在 1:9 到 3:7，所以需要读的可能性是比写的可能大得多的。当我们使用 SQL 语句去数据库进行读写操作时，数据库就会 去磁盘把对应的数据索引取回来，这是一个相对较慢的过程。

使用 Redis or 使用缓存带来的优势

如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，那么这样 速度 明显就会快上不少 *(高性能)*，并且会 极大减小数据库的压力 *(特别是在高并发情况下)*。

“

记得是 两个角度 啊.. 高性能 和 高并发..

也要提一下使用缓存的考虑

但是使用内存进行数据存储开销也是比较大的，限于成本 的原因，一般我们只是使用 Redis 存储一些 常用和主要的数据，比如用户登录的信息等。

一般而言在使用 Redis 进行存储的时候，我们需要从以下几个方面来考虑：

• 业务数据常用吗？命中率如何？ 如果命中率很低，就没有必要写入缓存；
• 该业务数据是读操作多，还是写操作多？ 如果写操作多，频繁需要写入数据库，也没有必要使用缓存；
• 业务数据大小如何？ 如果要存储几百兆字节的文件，会给缓存带来很大的压力，这样也没有必要；

在考虑了这些问题之后，如果觉得有必要使用缓存，那么就使用它！

■使用缓存会出现什么问题？

一般来说有如下几个问题，回答思路遵照 是什么 → 为什么 → 怎么解决：

1. 缓存雪崩问题；
2. 缓存穿透问题；
3. 缓存和数据库双写一致性问题；

缓存雪崩问题

另外对于 “Redis 挂掉了，请求全部走数据库” 这样的情况，我们还可以有如下的思路：

• 事发前：实现 Redis 的高可用(主从架构 + Sentinel 或者 Redis Cluster)，尽量避免 Redis 挂掉这种情况发生。
• 事发中：万一 Redis 真的挂了，我们可以设置本地缓存(ehcache) + 限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
• 事发后：Redis 持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

缓存穿透问题

缓存与数据库双写一致问题

双写一致性上图还是稍微粗糙了些，你还需要知道两种方案 (先操作数据库和先操作缓存) 分别都有什么优势和对应的问题，这里不作赘述，可以参考一下下方的文章，写得非常详细。

“

• 面试前必须要知道的Redis面试题 | Java3y - https://mp.weixin.qq.com/s/3Fmv7h5p2QDtLxc9n1dp5A

■Redis 为什么早期版本选择单线程？

官方解释

因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是 机器内存的大小 或者 网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。

简单总结一下

1. 使用单线程模型能带来更好的 可维护性，方便开发和调试；
2. 使用单线程模型也能 并发 的处理客户端的请求；*(I/O 多路复用机制)*
3. Redis 服务中运行的绝大多数操作的 性能瓶颈都不是 CPU；

“

强烈推荐 各位亲看一下这篇文章：

• 为什么 Redis 选择单线程模型 · Why’s THE Design? - https://draveness.me/whys-the-design-redis-single-thread

■Redis 为什么这么快？

简单总结：

1. 纯内存操作：读取不需要进行磁盘 I/O，所以比传统数据库要快上不少；*(但不要有误区说磁盘就一定慢，例如 Kafka 就是使用磁盘顺序读取但仍然较快)*
2. 单线程，无锁竞争：这保证了没有线程的上下文切换，不会因为多线程的一些操作而降低性能；
3. 多路 I/O 复用模型，非阻塞 I/O：采用多路 I/O 复用技术可以让单个线程高效的处理多个网络连接请求（尽量减少网络 IO 的时间消耗）；
4. 高效的数据结构，加上底层做了大量优化：Redis 对于底层的数据结构和内存占用做了大量的优化，例如不同长度的字符串使用不同的结构体表示，HyperLogLog 的密集型存储结构等等..

二、数据结构篇

■简述一下 Redis 常用数据结构及实现？

首先在 Redis 内部会使用一个 RedisObject 对象来表示所有的 key 和 value：

其次 Redis 为了 平衡空间和时间效率，针对 value 的具体类型在底层会采用不同的数据结构来实现，下图展示了他们之间的映射关系：*(好像乱糟糟的，但至少能看清楚..)*

■Redis 的 SDS 和 C 中字符串相比有什么优势？

先简单总结一下

C 语言使用了一个长度为 N+1 的字符数组来表示长度为 N 的字符串，并且字符数组最后一个元素总是 \0，这种简单的字符串表示方式 不符合 Redis 对字符串在安全性、效率以及功能方面的要求。

再来说 C 语言字符串的问题

这样简单的数据结构可能会造成以下一些问题：

• 获取字符串长度为 O(N) 级别的操作 → 因为 C 不保存数组的长度，每次都需要遍历一遍整个数组；
• 不能很好的杜绝 缓冲区溢出/内存泄漏 的问题 → 跟上述问题原因一样，如果执行拼接 or 缩短字符串的操作，如果操作不当就很容易造成上述问题；
• C 字符串 只能保存文本数据 → 因为 C 语言中的字符串必须符合某种编码（比如 ASCII），例如中间出现的 '\0' 可能会被判定为提前结束的字符串而识别不了；

Redis 如何解决的 | SDS 的优势

如果去看 Redis 的源码 sds.h/sdshdr 文件，你会看到 SDS 完整的实现细节，这里简单来说一下 Redis 如何解决的：

1. 多增加 len 表示当前字符串的长度：这样就可以直接获取长度了，复杂度 O(1)；
2. 自动扩展空间：当 SDS 需要对字符串进行修改时，首先借助于 len 和 alloc 检查空间是否满足修改所需的要求，如果空间不够的话，SDS 会自动扩展空间，避免了像 C 字符串操作中的覆盖情况；
3. 有效降低内存分配次数：C 字符串在涉及增加或者清除操作时会改变底层数组的大小造成重新分配，SDS 使用了 空间预分配 和 惰性空间释放 机制，简单理解就是每次在扩展时是成倍的多分配的，在缩容是也是先留着并不正式归还给 OS；
4. 二进制安全：C 语言字符串只能保存 ascii 码，对于图片、音频等信息无法保存，SDS 是二进制安全的，写入什么读取就是什么，不做任何过滤和限制；

■字典是如何实现的？Rehash 了解吗？

先总体聊一下 Redis 中的字典

字典是 Redis 服务器中出现最为频繁的复合型数据结构。除了 hash 结构的数据会用到字典外，整个 Redis 数据库的所有 key 和 value 也组成了一个 全局字典，还有带过期时间的 key 也是一个字典。*(存储在 RedisDb 数据结构中)*

说明字典内部结构和 rehash

Redis 中的字典相当于 Java 中的 HashMap，内部实现也差不多类似，都是通过 “数组 + 链表” 的 链地址法 来解决部分 哈希冲突，同时这样的结构也吸收了两种不同数据结构的优点。

字典结构内部包含 两个 hashtable，通常情况下只有一个 hashtable 有值，但是在字典扩容缩容时，需要分配新的 hashtable，然后进行 渐进式搬迁 *(rehash)*，这时候两个 hashtable 分别存储旧的和新的 hashtable，待搬迁结束后，旧的将被删除，新的 hashtable 取而代之。

扩缩容的条件

正常情况下，当 hash 表中 元素的个数等于第一维数组的长度时，就会开始扩容，扩容的新数组是 原数组大小的 2 倍。不过如果 Redis 正在做 bgsave(持久化命令)，为了减少内存也得过多分离，Redis 尽量不去扩容，但是如果 hash 表非常满了，达到了第一维数组长度的 5 倍了，这个时候就会 强制扩容。

当 hash 表因为元素逐渐被删除变得越来越稀疏时，Redis 会对 hash 表进行缩容来减少 hash 表的第一维数组空间占用。所用的条件是 **元素个数低于数组长度的 10%**，缩容不会考虑 Redis 是否在做 bgsave。

■跳跃表是如何实现的？原理？

“

这是 Redis 中比较重要的一个数据结构，建议阅读 之前写过的文章，里面详细介绍了原理和一些细节：

• Redis(2)——跳跃表

■HyperLogLog 有了解吗？

“

建议阅读 之前的系列文章：

• Redis(4)——神奇的HyperLoglog解决统计问题

■布隆过滤器有了解吗？

“

建议阅读 之前的系列文章：

• Redis(5)——亿级数据过滤和布隆过滤器

■GeoHash 了解吗？

“

建议阅读 之前的系列文章：

• Redis(6)——GeoHash查找附近的人

■压缩列表了解吗？

这是 Redis 为了节约内存 而使用的一种数据结构，zset 和 hash 容器对象会在元素个数较少的时候，采用压缩列表（ziplist）进行存储。压缩列表是 一块连续的内存空间，元素之间紧挨着存储，没有任何冗余空隙。

“

因为之前自己也没有学习过，所以找了一篇比较好比较容易理解的文章：

• 图解Redis之数据结构篇——压缩列表 - https://mp.weixin.qq.com/s/nba0FUEAVRs0vi24KUoyQg
• 这一篇稍微底层稍微硬核一点：http://www.web-lovers.com/redis-source-ziplist.html

■快速列表 quicklist 了解吗？

Redis 早期版本存储 list 列表数据结构使用的是压缩列表 ziplist 和普通的双向链表 linkedlist，也就是说当元素少时使用 ziplist，当元素多时用 linkedlist。但考虑到链表的附加空间相对较高，prev 和 next 指针就要占去 16 个字节（64 位操作系统占用 8 个字节），另外每个节点的内存都是单独分配，会家具内存的碎片化，影响内存管理效率。

后来 Redis 新版本（3.2）对列表数据结构进行了改造，使用 quicklist 代替了 ziplist 和 linkedlist。

“

同上..建议阅读一下以下的文章：

• Redis列表list 底层原理 - https://zhuanlan.zhihu.com/p/102422311

■Stream 结构有了解吗？

Redis Stream 从概念上来说，就像是一个 仅追加内容 的 消息链表，把所有加入的消息都一个一个串起来，每个消息都有一个唯一的 ID 和内容，这很简单，让它复杂的是从 Kafka 借鉴的另一种概念：消费者组(Consumer Group) *(思路一致，实现不同)*：

上图就展示了一个典型的 Stream 结构。每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用 xadd 指令追加消息时自动创建。我们对图中的一些概念做一下解释：

• Consumer Group：消费者组，可以简单看成记录流状态的一种数据结构。消费者既可以选择使用 XREAD 命令进行 独立消费，也可以多个消费者同时加入一个消费者组进行 组内消费。同一个消费者组内的消费者共享所有的 Stream 信息，同一条消息只会有一个消费者消费到，这样就可以应用在分布式的应用场景中来保证消息的唯一性。
• last_delivered_id：用来表示消费者组消费在 Stream 上 消费位置 的游标信息。每个消费者组都有一个 Stream 内 唯一的名称，消费者组不会自动创建，需要使用 XGROUP CREATE 指令来显式创建，并且需要指定从哪一个消息 ID 开始消费，用来初始化 last_delivered_id 这个变量。
• pending_ids：每个消费者内部都有的一个状态变量，用来表示 已经 被客户端 获取，但是 还没有 ack 的消息。记录的目的是为了 保证客户端至少消费了消息一次，而不会在网络传输的中途丢失而没有对消息进行处理。如果客户端没有 ack，那么这个变量里面的消息 ID 就会越来越多，一旦某个消息被 ack，它就会对应开始减少。这个变量也被 Redis 官方称为 PEL *(Pending Entries List)*。

Stream 消息太多怎么办？

很容易想到，要是消息积累太多，Stream 的链表岂不是很长，内容会不会爆掉就是个问题了。xdel 指令又不会删除消息，它只是给消息做了个标志位。

Redis 自然考虑到了这一点，所以它提供了一个定长 Stream 功能。在 xadd 的指令提供一个定长长度 maxlen，就可以将老的消息干掉，确保最多不超过指定长度，使用起来也很简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

> XADD mystream MAXLEN 2 * value 1
1526654998691-0
> XADD mystream MAXLEN 2 * value 2
1526654999635-0
> XADD mystream MAXLEN 2 * value 3
1526655000369-0
> XLEN mystream
(integer) 2
> XRANGE mystream - +
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

如果使用 MAXLEN 选项，当 Stream 的达到指定长度后，老的消息会自动被淘汰掉，因此 Stream 的大小是恒定的。目前还没有选项让 Stream 只保留给定数量的条目，因为为了一致地运行，这样的命令必须在很长一段时间内阻塞以淘汰消息。*(例如在添加数据的高峰期间，你不得不长暂停来淘汰旧消息和添加新的消息)*

另外使用 MAXLEN 选项的花销是很大的，Stream 为了节省内存空间，采用了一种特殊的结构表示，而这种结构的调整是需要额外的花销的。所以我们可以使用一种带有 ~ 的特殊命令：

1

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...

它会基于当前的结构合理地对节点执行裁剪，来保证至少会有 1000 条数据，可能是 1010 也可能是 1030。

PEL 是如何避免消息丢失的？

在客户端消费者读取 Stream 消息时，Redis 服务器将消息回复给客户端的过程中，客户端突然断开了连接，消息就丢失了。但是 PEL 里已经保存了发出去的消息 ID，待客户端重新连上之后，可以再次收到 PEL 中的消息 ID 列表。不过此时 xreadgroup 的起始消息 ID 不能为参数 > ，而必须是任意有效的消息 ID，一般将参数设为 0-0，表示读取所有的 PEL 消息以及自 last_delivered_id 之后的新消息。

和 Kafka 对比起来呢？

Redis 基于内存存储，这意味着它会比基于磁盘的 Kafka 快上一些，也意味着使用 Redis 我们 不能长时间存储大量数据。不过如果您想以 最小延迟 实时处理消息的话，您可以考虑 Redis，但是如果 消息很大并且应该重用数据 的话，则应该首先考虑使用 Kafka。

另外从某些角度来说，Redis Stream 也更适用于小型、廉价的应用程序，因为 Kafka 相对来说更难配置一些。

“

推荐阅读 之前的系列文章，里面 也对 Pub/ Sub 做了详细的描述：

• Redis(8)——发布/订阅与Stream

三、持久化篇

■什么是持久化？

先简单谈一谈是什么

Redis 的数据 全部存储 在 内存 中，如果 突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制，它会将内存中的数据库状态 保存到磁盘 中。

解释一下持久化发生了什么

我们来稍微考虑一下 Redis 作为一个 “内存数据库” 要做的关于持久化的事情。通常来说，从客户端发起请求开始，到服务器真实地写入磁盘，需要发生如下几件事情：

详细版 的文字描述大概就是下面这样：

1. 客户端向数据库 发送写命令 (数据在客户端的内存中)
2. 数据库 接收 到客户端的 写请求 (数据在服务器的内存中)
3. 数据库 调用系统 API 将数据写入磁盘 (数据在内核缓冲区中)
4. 操作系统将 写缓冲区 传输到 磁盘控控制器 (数据在磁盘缓存中)
5. 操作系统的磁盘控制器将数据 写入实际的物理媒介 中 (数据在磁盘中)

分析如何保证持久化安全

如果我们故障仅仅涉及到 软件层面 (该进程被管理员终止或程序崩溃) 并且没有接触到内核，那么在 上述步骤 3 成功返回之后，我们就认为成功了。即使进程崩溃，操作系统仍然会帮助我们把数据正确地写入磁盘。

如果我们考虑 停电/ 火灾 等 更具灾难性 的事情，那么只有在完成了第 5 步之后，才是安全的。

机房”火了“

所以我们可以总结得出数据安全最重要的阶段是：步骤三、四、五，即：

• 数据库软件调用写操作将用户空间的缓冲区转移到内核缓冲区的频率是多少？
• 内核多久从缓冲区取数据刷新到磁盘控制器？
• 磁盘控制器多久把数据写入物理媒介一次？
• 注意： 如果真的发生灾难性的事件，我们可以从上图的过程中看到，任何一步都可能被意外打断丢失，所以只能 尽可能地保证 数据的安全，这对于所有数据库来说都是一样的。

我们从 第三步 开始。Linux 系统提供了清晰、易用的用于操作文件的 POSIX file API，20 多年过去，仍然还有很多人对于这一套 API 的设计津津乐道，我想其中一个原因就是因为你光从 API 的命名就能够很清晰地知道这一套 API 的用途：

1
2
3
4

int open(const char *path, int oflag, .../*,mode_t mode */);
int close (int filedes);int remove( const char *fname );
ssize_t write(int fildes, constvoid *buf, size_t nbyte);
ssize_t read(int fildes, void *buf, size_t nbyte);

• 参考自：API 设计最佳实践的思考 - https://www.cnblogs.com/yuanjiangw/p/10846560.html

所以，我们有很好的可用的 API 来完成 第三步，但是对于成功返回之前，我们对系统调用花费的时间没有太多的控制权。

然后我们来说说 第四步。我们知道，除了早期对电脑特别了解那帮人 *(操作系统就这帮人搞的)*，实际的物理硬件都不是我们能够 直接操作 的，都是通过 操作系统调用 来达到目的的。为了防止过慢的 I/O 操作拖慢整个系统的运行，操作系统层面做了很多的努力，譬如说 上述第四步 提到的 写缓冲区，并不是所有的写操作都会被立即写入磁盘，而是要先经过一个缓冲区，默认情况下，Linux 将在 30 秒 后实际提交写入。

但是很明显，30 秒 并不是 Redis 能够承受的，这意味着，如果发生故障，那么最近 30 秒内写入的所有数据都可能会丢失。幸好 PROSIX API 提供了另一个解决方案：fsync，该命令会 强制 内核将 缓冲区 写入 磁盘，但这是一个非常消耗性能的操作，每次调用都会 阻塞等待 直到设备报告 IO 完成，所以一般在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作。

到目前为止，我们了解到了如何控制 第三步 和 第四步，但是对于 第五步，我们 完全无法控制。也许一些内核实现将试图告诉驱动实际提交物理介质上的数据，或者控制器可能会为了提高速度而重新排序写操作，不会尽快将数据真正写到磁盘上，而是会等待几个多毫秒。这完全是我们无法控制的。

“

普通人简单说一下第一条就过了，如果你详细地对后面两方面 侃侃而谈，那面试官就会对你另眼相看了。

■Redis 中的两种持久化方式？

方式一：快照

Redis 快照 是最简单的 Redis 持久性模式。当满足特定条件时，它将生成数据集的时间点快照，例如，如果先前的快照是在 2 分钟前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照。此条件可以由用户配置 Redis 实例来控制，也可以在运行时修改而无需重新启动服务器。快照作为包含整个数据集的单个 .rdb 文件生成。

方式二：AOF

快照不是很持久。如果运行 Redis 的计算机停止运行，电源线出现故障或者您 kill -9 的实例意外发生，则写入 Redis 的最新数据将丢失。尽管这对于某些应用程序可能不是什么大问题，但有些使用案例具有充分的耐用性，在这些情况下，快照并不是可行的选择。

AOF(Append Only File - 仅追加文件) 它的工作方式非常简单：每次执行 修改内存 中数据集的写操作时，都会 记录 该操作。假设 AOF 日志记录了自 Redis 实例创建以来 所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例 顺序执行所有的指令，也就是 「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

Redis 4.0 的混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小：

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

“

关于两种持久化方式的更多细节 (原理) 可以参考：

• Redis(7)——持久化【一文了解】

■RDB 和 AOF 各自有什么优缺点？

RDB | 优点

1. 只有一个文件 dump.rdb，方便持久化。
2. 容灾性好，一个文件可以保存到安全的磁盘。
3. 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以使 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能
4. 相对于数据集大时，比 AOF 的 启动效率 更高。

RDB | 缺点

1. 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 Redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候；

AOF | 优点

1. 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。
2. 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
3. AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）

AOF | 缺点

1. AOF 文件比 RDB 文件大，且 恢复速度慢。
2. 数据集大 的时候，比 rdb 启动效率低。

■两种方式如何选择？

• 一般来说， 如果想达到足以媲美 PostgreSQL 的 数据安全性，你应该 同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
• 如果你非常关心你的数据， 但仍然 可以承受数分钟以内的数据丢失，那么你可以 只使用 RDB 持久化。
• 有很多用户都只使用 AOF 持久化，但并不推荐这种方式，因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免 AOF 程序的 bug。
• 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

■Redis 的数据恢复

Redis 的数据恢复有着如下的优先级：

1. 如果只配置 AOF ，重启时加载 AOF 文件恢复数据；
2. 如果同时配置了 RDB 和 AOF ，启动只加载 AOF 文件恢复数据；
3. 如果只配置 RDB，启动将加载 dump 文件恢复数据。

拷贝 AOF 文件到 Redis 的数据目录，启动 redis-server AOF 的数据恢复过程：Redis 虚拟一个客户端，读取 AOF 文件恢复 Redis 命令和参数，然后执行命令从而恢复数据，这些过程主要在 loadAppendOnlyFile() 中实现。

拷贝 RDB 文件到 Redis 的数据目录，启动 redis-server 即可，因为 RDB 文件和重启前保存的是真实数据而不是命令状态和参数。

四、集群篇

■主从同步了解吗？

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为 **主节点(master)**，后者称为 **从节点(slave)**。且数据的复制是 单向 的，只能由主节点到从节点。Redis 主从复制支持 主从同步 和 从从同步 两种，后者是 Redis 后续版本新增的功能，以减轻主节点的同步负担。

主从复制主要的作用

• 数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复 *(实际上是一种服务的冗余)*。
• 负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载。尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。
• 高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的 基础，因此说主从复制是 Redis 高可用的基础。

实现原理

为了节省篇幅，我把主要的步骤都 浓缩 在了上图中，其实也可以 简化成三个阶段：准备阶段-数据同步阶段-命令传播阶段。

“

更多细节 推荐阅读 之前的系列文章，不仅有原理讲解，还有实战环节：

• Redis(9)——史上最强【集群】入门实践教程

■哨兵模式了解吗？

上图 展示了一个典型的哨兵架构图，它由两部分组成，哨兵节点和数据节点：

• 哨兵节点： 哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据；
• 数据节点： 主节点和从节点都是数据节点；

在复制的基础上，哨兵实现了 自动化的故障恢复 功能，下方是官方对于哨兵功能的描述：

• 监控（Monitoring）： 哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）： 当 主节点 不能正常工作时，哨兵会开始 自动故障转移操作，它会将失效主节点的其中一个 从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）： 客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
• 通知（Notification）： 哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移。而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

新的主服务器是怎样被挑选出来的？

故障转移操作的第一步 要做的就是在已下线主服务器属下的所有从服务器中，挑选出一个状态良好、数据完整的从服务器，然后向这个从服务器发送 slaveof no one 命令，将这个从服务器转换为主服务器。但是这个从服务器是怎么样被挑选出来的呢？

简单来说 Sentinel 使用以下规则来选择新的主服务器：

1. 在失效主服务器属下的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被 淘汰。
2. 在失效主服务器属下的从服务器当中， 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被 淘汰。
3. 在 经历了以上两轮淘汰之后 剩下来的从服务器中， 我们选出 复制偏移量（replication offset）最大 的那个 从服务器 作为新的主服务器；如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么 带有最小运行 ID 的那个从服务器成为新的主服务器。

“

更多细节 推荐阅读 之前的系列文章，不仅有原理讲解，还有实战环节：

• Redis(9)——史上最强【集群】入门实践教程

■Redis 集群使用过吗？原理？

上图 展示了 Redis Cluster 典型的架构图，集群中的每一个 Redis 节点都 互相两两相连，客户端任意 直连 到集群中的 任意一台，就可以对其他 Redis 节点进行 读写 的操作。

基本原理

Redis 集群中内置了 16384 个哈希槽。当客户端连接到 Redis 集群之后，会同时得到一份关于这个 集群的配置信息，当客户端具体对某一个 key 值进行操作时，会计算出它的一个 Hash 值，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，Redis 会根据节点数量 大致均等 的将哈希槽映射到不同的节点。

再结合集群的配置信息就能够知道这个 key 值应该存储在哪一个具体的 Redis 节点中，如果不属于自己管，那么就会使用一个特殊的 MOVED 命令来进行一个跳转，告诉客户端去连接这个节点以获取数据：

1
2

GET x
-MOVED 3999 127.0.0.1:6381

MOVED 指令第一个参数 3999 是 key 对应的槽位编号，后面是目标节点地址，MOVED 命令前面有一个减号，表示这是一个错误的消息。客户端在收到 MOVED 指令后，就立即纠正本地的 槽位映射表，那么下一次再访问 key 时就能够到正确的地方去获取了。

集群的主要作用

1. 数据分区： 数据分区 (或称数据分片) 是集群最核心的功能。集群将数据分散到多个节点，一方面 突破了 Redis 单机内存大小的限制，存储容量大大增加；另一方面 每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。Redis 单机内存大小受限问题，在介绍持久化和主从复制时都有提及，例如，如果单机内存太大，bgsave 和 bgrewriteaof 的 fork 操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出……
2. 高可用： 集群支持主从复制和主节点的 自动故障转移 （与哨兵类似），当任一节点发生故障时，集群仍然可以对外提供服务。

■集群中数据如何分区？

Redis 采用方案三。

方案一：哈希值 % 节点数

哈希取余分区思路非常简单：计算 key 的 hash 值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。

不过该方案最大的问题是，当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要 重新计算映射关系，引发大规模数据迁移。

方案二：一致性哈希分区

一致性哈希算法将 整个哈希值空间 组织成一个虚拟的圆环，范围是 *[0 - 232 - 1]*，对于每一个数据，根据 key 计算 hash 值，确数据在环上的位置，然后从此位置沿顺时针行走，找到的第一台服务器就是其应该映射到的服务器：

与哈希取余分区相比，一致性哈希分区将 增减节点的影响限制在相邻节点。以上图为例，如果在 node1 和 node2 之间增加 node5，则只有 node2 中的一部分数据会迁移到 node5；如果去掉 node2，则原 node2 中的数据只会迁移到 node4 中，只有 node4 会受影响。

一致性哈希分区的主要问题在于，当 节点数量较少 时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡。还是以上图为例，如果去掉 node2，node4 中的数据由总数据的 1/4 左右变为 1/2 左右，与其他节点相比负载过高。

方案三：带有虚拟节点的一致性哈希分区

该方案在 一致性哈希分区的基础上，引入了 虚拟节点 的概念。Redis 集群使用的便是该方案，其中的虚拟节点称为 槽（slot）。槽是介于数据和实际节点之间的虚拟概念，每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。

在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽 解耦 了 数据和实际节点 之间的关系，增加或删除节点对系统的影响很小。仍以上图为例，系统中有 4 个实际节点，假设为其分配 16 个槽(0-15)；

• 槽 0-3 位于 node1；4-7 位于 node2；以此类推….

如果此时删除 node2，只需要将槽 4-7 重新分配即可，例如槽 4-5 分配给 node1，槽 6 分配给 node3，槽 7 分配给 node4；可以看出删除 node2 后，数据在其他节点的分布仍然较为均衡。

■节点之间的通信机制了解吗？

集群的建立离不开节点之间的通信，例如我们在 快速体验 中刚启动六个集群节点之后通过 redis-cli 命令帮助我们搭建起来了集群，实际上背后每个集群之间的两两连接是通过了 CLUSTER MEET <ip> <port> 命令发送 MEET 消息完成的，下面我们展开详细说说。

两个端口

在 哨兵系统 中，节点分为 数据节点 和 哨兵节点：前者存储数据，后者实现额外的控制功能。在 集群 中，没有数据节点与非数据节点之分：所有的节点都存储数据，也都参与集群状态的维护。为此，集群中的每个节点，都提供了两个 TCP 端口：

• 普通端口： 即我们在前面指定的端口 *(7000等)*。普通端口主要用于为客户端提供服务 （与单机节点类似）；但在节点间数据迁移时也会使用。
• 集群端口： 端口号是普通端口 + 10000 （10000是固定值，无法改变），如 7000 节点的集群端口为 17000。集群端口只用于节点之间的通信，如搭建集群、增减节点、故障转移等操作时节点间的通信；不要使用客户端连接集群接口。为了保证集群可以正常工作，在配置防火墙时，要同时开启普通端口和集群端口。

Gossip 协议

节点间通信，按照通信协议可以分为几种类型：单对单、广播、Gossip 协议等。重点是广播和 Gossip 的对比。

• 广播是指向集群内所有节点发送消息。优点 是集群的收敛速度快(集群收敛是指集群内所有节点获得的集群信息是一致的)，缺点 是每条消息都要发送给所有节点，CPU、带宽等消耗较大。
• Gossip 协议的特点是：在节点数量有限的网络中，每个节点都 “随机” 的与部分节点通信 （并不是真正的随机，而是根据特定的规则选择通信的节点），经过一番杂乱无章的通信，每个节点的状态很快会达到一致。Gossip 协议的 优点 有负载 (比广播) 低、去中心化、容错性高 (因为通信有冗余) 等；缺点 主要是集群的收敛速度慢。

消息类型

集群中的节点采用 固定频率（每秒10次） 的 定时任务 进行通信相关的工作：判断是否需要发送消息及消息类型、确定接收节点、发送消息等。如果集群状态发生了变化，如增减节点、槽状态变更，通过节点间的通信，所有节点会很快得知整个集群的状态，使集群收敛。

节点间发送的消息主要分为 5 种：meet 消息、ping 消息、pong 消息、fail 消息、publish 消息。不同的消息类型，通信协议、发送的频率和时机、接收节点的选择等是不同的：

• MEET 消息： 在节点握手阶段，当节点收到客户端的 CLUSTER MEET 命令时，会向新加入的节点发送 MEET 消息，请求新节点加入到当前集群；新节点收到 MEET 消息后会回复一个 PONG 消息。
• PING 消息： 集群里每个节点每秒钟会选择部分节点发送 PING 消息，接收者收到消息后会回复一个 PONG 消息。PING 消息的内容是自身节点和部分其他节点的状态信息，作用是彼此交换信息，以及检测节点是否在线。PING 消息使用 Gossip 协议发送，接收节点的选择兼顾了收敛速度和带宽成本，具体规则如下：(1)随机找 5 个节点，在其中选择最久没有通信的 1 个节点；(2)扫描节点列表，选择最近一次收到 PONG 消息时间大于 cluster_node_timeout / 2 的所有节点，防止这些节点长时间未更新。
• PONG消息： PONG 消息封装了自身状态数据。可以分为两种：第一种 是在接到 MEET/PING 消息后回复的 PONG 消息；第二种 是指节点向集群广播 PONG 消息，这样其他节点可以获知该节点的最新信息，例如故障恢复后新的主节点会广播 PONG 消息。
• FAIL 消息： 当一个主节点判断另一个主节点进入 FAIL 状态时，会向集群广播这一 FAIL 消息；接收节点会将这一 FAIL 消息保存起来，便于后续的判断。
• PUBLISH 消息： 节点收到 PUBLISH 命令后，会先执行该命令，然后向集群广播这一消息，接收节点也会执行该 PUBLISH 命令。

■集群数据如何存储的有了解吗？

节点需要专门的数据结构来存储集群的状态。所谓集群的状态，是一个比较大的概念，包括：集群是否处于上线状态、集群中有哪些节点、节点是否可达、节点的主从状态、槽的分布……

节点为了存储集群状态而提供的数据结构中，最关键的是 clusterNode 和 clusterState 结构：前者记录了一个节点的状态，后者记录了集群作为一个整体的状态。

clusterNode 结构

clusterNode 结构保存了 一个节点的当前状态，包括创建时间、节点 id、ip 和端口号等。每个节点都会用一个 clusterNode 结构记录自己的状态，并为集群内所有其他节点都创建一个 clusterNode 结构来记录节点状态。

下面列举了 clusterNode 的部分字段，并说明了字段的含义和作用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

typedefstruct clusterNode {
    //节点创建时间
    mstime_t ctime;
    //节点id
    char name[REDIS_CLUSTER_NAMELEN];
    //节点的ip和端口号
    char ip[REDIS_IP_STR_LEN];
    int port;
    //节点标识：整型，每个bit都代表了不同状态，如节点的主从状态、是否在线、是否在握手等
    int flags;
    //配置纪元：故障转移时起作用，类似于哨兵的配置纪元
    uint64_t configEpoch;
    //槽在该节点中的分布：占用16384/8个字节，16384个比特；每个比特对应一个槽：比特值为1，则该比特对应的槽在节点中；比特值为0，则该比特对应的槽不在节点中
    unsignedchar slots[16384/8];
    //节点中槽的数量
    int numslots;
    …………
} clusterNode;

除了上述字段，clusterNode 还包含节点连接、主从复制、故障发现和转移需要的信息等。

clusterState 结构

clusterState 结构保存了在当前节点视角下，集群所处的状态。主要字段包括：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

typedefstruct clusterState {
    //自身节点
    clusterNode *myself;
    //配置纪元
    uint64_t currentEpoch;
    //集群状态：在线还是下线
    int state;
    //集群中至少包含一个槽的节点数量
    int size;
    //哈希表，节点名称->clusterNode节点指针
    dict *nodes;
    //槽分布信息：数组的每个元素都是一个指向clusterNode结构的指针；如果槽还没有分配给任何节点，则为NULL
    clusterNode *slots[16384];
    …………
} clusterState;

除此之外，clusterState 还包括故障转移、槽迁移等需要的信息。

五、其他问题

■Redis 如何实现分布式锁？

“

推荐阅读 之前的系列文章：Redis(3)——分布式锁深入探究

■Redis 过期键的删除策略？

简单描述

先抛开 Redis 想一下几种可能的删除策略：

1. 定时删除:在设置键的过期时间的同时，创建一个定时器 timer). 让定时器在键的过期时间来临时，立即执行对键的删除操作。
2. 惰性删除:放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键;如果没有过期，就返回该键。
3. 定期删除:每隔一段时间程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

在上述的三种策略中定时删除和定期删除属于不同时间粒度的 主动删除，惰性删除属于 被动删除。

三种策略都有各自的优缺点

1. 定时删除对内存使用率有优势，但是对 CPU 不友好；
2. 惰性删除对内存不友好，如果某些键值对一直不被使用，那么会造成一定量的内存浪费；
3. 定期删除是定时删除和惰性删除的折中。

Redis 中的实现

Reids 采用的是 惰性删除和定时删除 的结合，一般来说可以借助最小堆来实现定时器，不过 Redis 的设计考虑到时间事件的有限种类和数量，使用了无序链表存储时间事件，这样如果在此基础上实现定时删除，就意味着 O(N) 遍历获取最近需要删除的数据。

■Redis 的淘汰策略有哪些？

Redis 有六种淘汰策略

4.0 版本后增加以下两种

• volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
• allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

■Redis常见性能问题和解决方案？

1. Master 最好不要做任何持久化工作，包括内存快照和 AOF 日志文件，特别是不要启用内存快照做持久化。
2. 如果数据比较关键，某个 Slave 开启 AOF 备份数据，策略为每秒同步一次。
3. 为了主从复制的速度和连接的稳定性，Slave 和 Master 最好在同一个局域网内。
4. 尽量避免在压力较大的主库上增加从库。
5. Master 调用 BGREWRITEAOF 重写 AOF 文件，AOF 在重写的时候会占大量的 CPU 和内存资源，导致服务 load 过高，出现短暂服务暂停现象。
6. 为了 Master 的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现 Slave 对 Master 的替换，也即，如果 Master 挂了，可以立马启用 Slave1 做 Master，其他不变。

■假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

使用 keys 指令可以扫出指定模式的 key 列表。但是要注意 keys 指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用 scan 指令，scan 指令可以无阻塞的提取出指定模式的 key 列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用 keys 指令长。

■More..

参考资料

1. 3w字深度好文|Redis面试全攻略，读完这个就可以和面试官大战几个回合了 - https://mp.weixin.qq.com/s/f9N13fnyTtnu2D5sKZiu9
2. 大厂面试！我和面试官之间关于Redis的一场对弈！- https://mp.weixin.qq.com/s/DHTPSfmWTZpdTmlytzLz1
3. Redis面试题（2020最新版） - https://blog.csdn.net/ThinkWon/article/details/103522351

“

• 本文已收录至我的 Github 程序员成长系列 【More Than Java】，学习，不止 Code，欢迎 star：https://github.com/wmyskxz/MoreThanJava
• 个人公众号 ：wmyskxz，个人独立域名博客：wmyskxz.com，坚持原创输出，下方扫码关注，2020，与您共同成长！

非常感谢各位人才能 看到这里，如果觉得本篇文章写得不错，觉得 「我没有三颗心脏」有点东西 的话，求点赞，求关注，求分享，求留言！

创作不易，各位的支持和认可，就是我创作的最大动力，我们下篇文章见！

点击留言

在大量模糊查询的场景下（尤其是中缀模糊匹配如 %搜索词%），传统数据库索引（如B+树）通常力不从心，而倒排索引（或其升级版）是更优的选择。以下是详细分析和解决方案：

一、数据库索引的模糊匹配能力

1. 支持的模糊查询类型

2. 性能陷阱示例

1
2

-- 即使有name索引，以下查询仍触发全表扫描（耗时>10秒，百万数据）
SELECT * FROM users WHERE name LIKE '%小明%';

二、高性能模糊搜索方案推荐

✅ 首选方案：倒排索引搜索引擎

• 代表技术：Elasticsearch / Apache Solr
• 核心优势：
  • 通配符优化：内部将 *搜索* 转化为多词组合查询
  • 边缘N-Gram分词：自动生成 搜 -> 搜索 -> 索引 等变体
  • BM25排序：相关度智能排序

性能对比（百万数据）：

✅ 次选方案：数据库专用索引

• 适用场景：轻度模糊查询，且无法引入新组件
• 技术手段：

  1 2 3 4 5 6

  -- PostgreSQL的trigram扩展 CREATE EXTENSION pg_trgm; CREATE INDEX idx_name_trgm ON users USING gin(name gin_trgm_ops); -- 查询优化 SELECT * FROM users WHERE name LIKE '%小明%'; -- 命中索引

• 限制：
  • 索引体积膨胀3-5倍
  • 仅支持 LIKE，不支持正则表达式等高级搜索

三、决策树：如何选择技术方案？

1
2
3
4
5
6
7

graph TD
    A[是否高频中缀模糊查询？] -->|是| B[是否接受新组件？]
    A -->|否| C[数据库前缀索引]
    B -->|是| D[Elasticsearch/Solr]
    B -->|否| E[数据库专用索引<br>(pg_trgm/Full-Text)]
    D --> F[支持：通配符/正则/语义搜索]
    E --> G[支持：基本LIKE/分词搜索]

四、极端场景下的黑科技

1. 向量化模糊搜索（SIMD优化）

   • 原理：用AVX512指令并行比较64字节文本块
   • 开源实现：https://github.com/simdjson/simdjson（JSON解析中的模糊匹配加速）

2. 确定性有穷自动机（DFA）

   • 适用场景：固定模式模糊匹配（如139****1234）
   • 实现代码：

     1 2 3 4 5

     import ahocorasick automaton = ahocorasick.Automaton() for pattern in ['%apple%', '%banana%']: automaton.add_word(pattern.strip('%'), pattern) automaton.make_automaton()

五、各方案成本对比

总结建议

1. 高频复杂模糊查询：Elasticsearch/Solr是生产环境首选，通配符性能是数据库的 100倍以上
2. 轻度模糊查询：
   • PostgreSQL用 pg_trgm
   • MySQL 8.0+ 用 ngram Full-Text索引
3. 超低延迟需求：开发 基于SIMD+DFA的定制化引擎（仅在内存充足时有效）

📌 紧急避坑提示：
切勿在数据库无索引时直接跑 %xxx%！
切勿在ES中使用前导通配符 *xxx（性能杀手）！

计算机基础

网络

操作系统

• 操作系统面试题

JAVA基础

多线程

• 多线程面试题

JVM

• JVM面试题

中间件

Redis

基础

• redis常见面试题
• 妈妈再也不担心我面试被Redis问得脸都绿了

进阶

• redis集群及架构

MySQL

基础

• MySQL常见面试题

进阶

• InnoDB解决幻读的方案–LBCC&MVCC

分库分表最佳实践

TODO

系统架构设计

• 系统架构设计面试题

场景设计题

• 如何设计微博feeds流

算法

刷题网站

• codetop
• 代码随想录
• CS-Notes 剑指 Offer 题解
• CS-Notes Leetcode 题解

综合面经

• 2022面经
• 2021面经
• 2021面经第二波
• 20+互联网公司面试总结

快速检索：

• 那些年我们背过的JAVA面试题
• 系统设计面试题
• JavaGuide
• CS-Notes

redis集群的架构、问题，附脑洞

Redis 是一种开源（BSD 许可）、数据结构存储在内存中的系统，用作数据库、缓存和消息队列。Redis 提供了诸如字符串、散列、列表、集合、带范围查询的排序集合、位图、超级日志、地理空间索引和流等数据结构。Redis 内置复制、Lua 脚本、LRU 驱逐、事务和不同级别的磁盘持久化，并通过 Redis Sentinel 和 Redis Cluster 自动分区提供高可用性。

1 集群的优势

下面是redis集群的几个明显优势。

1.1 伸缩性，数据规模不断增大的时候，容易扩容

单实例模式：只能垂直扩展，增大机器内存的容量；

集群模式：支持垂直扩展，也支持水平扩展，有更好的灵活性，也可以支持更大的容量；