前言

前几天有个小伙伴找我诉苦，说他在抖音二面被问到了一个场景题——“如何设计一个高并发点赞系统？ ”

他说他当时脑子一片空白，支支吾吾说了几句“用Redis”、“用消息队列”，然后就没然后了。

这个问题其实是个经典的架构设计题。

面试官真正想考察的，不是你会不会用Redis，而是你面对一个高并发场景时，能不能跳出CRUD的思维定式，从整体架构的角度去思考问题。

今天这篇文章专门跟大家一起聊聊这个话题，希望看完后，你也能跟面试官聊上半小时。

一、点赞系统的核心挑战是什么？

有些小伙伴可能会说：“点赞不就是update一下数据库的计数吗？有什么难的？”

前言

当你的用户疯狂点击提交按钮时，你的系统准备好迎接这场“连击风暴”了吗？

在电商系统的实战中，我见过太多因重复提交导致的资损事故——用户一次点击，系统却创建了多个订单，导致库存错乱、用户重复支付、客服投诉爆棚。

有些小伙伴在工作中可能遇到过这样的场景：大促期间，用户反馈“明明只点了一次，为什么扣了两次款？”

开发同学查了半天日志，发现同一个用户请求在毫秒级内真的到达了服务器两次。

今天这篇文章就跟大家聊聊高并发下防止重复提交订单，希望对你会有所帮助。

01 为什么会重复提交？

在深入解决方案前，我们必须搞清楚重复提交是如何发生的。

常见的场景有：

1. 用户无意识重复点击：网络延迟时，用户心急多次点击提交按钮
2. 前端防抖失效：前端做了防抖处理，但被绕过或配置不当
3. 网络超时重试：请求超时后，客户端或网关自动重试
4. 恶意攻击：竞争对手或黑客故意重复提交
5. 后端处理超时：第一个请求处理慢，客户端以为失败又发一次

前言

"快看我们的秒杀系统！库存显示-500了！"

3年前的这个电话让我记忆犹新。

当时某电商大促，我们自认为完美的分布式架构，在0点整瞬间被击穿。

数据库连接池耗尽，库存表出现负数，客服电话被打爆...

今天这篇文章跟大家一起聊聊商品超卖的问题，希望对你会有所帮助。

1 为什么会发生超卖？

首先我们一起看看为什么会发送超卖？

1.1 数据库的"最后防线"漏洞

我们用下面的列子，给大家介绍一下商品超卖是如何发生的。

public boolean buy(int goodsId) {
    // 1. 查询库存
    int stock = getStockFromDatabase(goodsId);
    if (stock > 0) {
        // 2. 扣减库存
        updateStock(goodsId, stock - 1);
        return true;
    }
    return false;
}

前言

最近有位小伙伴去美团面试，被问到一个高频题：“高并发场景下，如何保证接口的幂等性？”

他答出了“唯一索引”和“token机制”，但被追问“如果重复请求并发执行，两个请求同时发现token有效怎么办？”

他就卡住了。

事实上，幂等性设计是高并发系统中最容易被忽视、出事后果却最严重的环节之一。

今天就专门跟大家一起聊聊接口幂等性的话题，希望对你会有所帮助。

一、什么是幂等性？

幂等（Idempotent）：同一个接口，无论调用一次还是多次，对系统产生的副作用都是一样的。

举个反例：支付接口。如果用户点了一次“确认支付”按钮，前端因为网络超时重试了三次，结果银行扣了三次钱，这就是典型的非幂等。