背景介绍：为什么需要分布式锁？

先看常见场景：

传统锁（如 ReentrantLock）仅在当前进程内有效，无法跨 JVM 实例、跨服务节点协调。

1. 什么是单例？什么是分布式单例？

我们先说说**单例模式（Singleton）**是干嘛的。

在 Java 里，我们希望一个类的对象只存在一份实例，整个程序都共享这个对象，这就是单例模式。我们可能写过这样的代码：

public class Singleton {
    private static final Singleton INSTANCE = new Singleton();
    public static Singleton getInstance() {
        return INSTANCE;
    }
}

背景：什么是短链接？为什么要设计它？

在实际开发中，我们经常会遇到一些超长 URL，例如：

https://www.jd.com/special/activity/2024-07-13/ads/campaign?id=987654321&user=abc

为什么这个问题很重要？

面试官问这个问题，其实是想考我们两个核心能力：

1. 对消息消费流程是否熟悉？
2. 能否根据业务需求选择合适的方式？

但很多人回答都是一句话：“Kafka 用拉，RabbitMQ 用推”，没有深入细节、没有类比解释、没有系统思考。

本篇我们从 0 到 1，搞清楚以下问题：

• 推模式 vs 拉模式到底差在哪？
• 各有什么优缺点？
• 哪些场景适合推？哪些适合拉？
• Kafka、RabbitMQ 等主流 MQ 怎么选的？
• 实战中如何设计出一个可控的消费流程？

什么是消息队列？一句话说清楚

消息队列（Message Queue）是一个系统中用来传话的“快递中转站”。

它负责把“消息”从发送方（生产者）传递到接收方（消费者）—— 而且还能：

• 保证不会丢件（消息不丢失）
• 顺序到达（支持顺序消费）
• 如果收件人晚点来也没关系（异步解耦）

举个例子：

淘宝订单支付成功后，会发生很多事：

• 给我们发短信
• 给仓库发发货请求
• 给商家发账单

一句话介绍什么是秒杀？

秒杀（flash sale）= 瞬间有大量用户同时请求一个极少的库存资源（比如抢 10 台手机，100 万人点进来）

它是对系统并发能力、限流策略、数据一致性、业务稳定性的全方位考验。

秒杀系统的核心难点（我们必须解决）

1. 瞬时流量暴涨：百万请求在 1 秒内涌入
2. 防止超卖：库存不能卖超
3. 用户去重：一个用户只能买一次
4. 系统抗压：要保护核心系统不被打挂
5. 兜底方案：即使秒杀失败，也能优雅提示

背景场景（题目）

有一张数据库表，包含以下字段：

• id：主键，自增
• start_time：业务开始时间
• end_time：业务结束时间

表中一共有 5000 万条记录，每条记录代表一个“时间段”（例如一个用户会话、一次任务执行等）。

问题是：在所有时间点中，哪一秒并发量最大？最多有多少条记录在该秒同时处于活动状态？

前言：什么是 RPC？为啥要它？

先打个比方：

我们去餐厅点菜，只负责“点”，不关心厨师怎么做、厨房在哪。我们说：“要一份麻辣烫”，然后等着吃。

RPC（Remote Procedure Call，远程过程调用） 就像这样：

• 我们是客户端
• 餐厅是服务器
• 厨房逻辑封装好了
• 我们用“本地方式”发出“远程请求”，结果返回到我们手里

一句话理解：RPC 让我们像调用本地函数一样，去调用另一台服务器上的服务。

1. 背景介绍

在一次支付宝的营销活动中，由于 运营配置错误，原本应该给用户发放「满减」优惠券，却被误配成了「8 折优惠」，导致大规模资金损失。

核心问题：运营人员在配置营销模板时，把优惠额度和优惠类型都写错了。

这类事故提醒我们：系统要有能力帮助用户防止低级错误，避免人为疏忽带来巨大损失。

2. 事故的本质原因

根据公开信息，事故原因是：

• 运维或运营人员配置营销活动模板时出错。
• 系统缺乏多重防护机制，错误配置直接生效。
• 缺乏实时监控与熔断机制。