高并发和秒杀系统设计

1. https://www.toutiao.com/a6747973409193329164/ 高并发场景下强一致预算/库存扣减方案 介绍了利用分库分表的方法来支持高并发的减库存方法
2. https://www.toutiao.com/a6746754139641872899/ “12306”是如何支撑百万QPS的？ 介绍了利用预扣库存（本地库存+redis统一库存管理）的方式支持高并发购票
3. https://www.toutiao.com/a6746868799296766476/ 为什么不用synchronized？从构建分布式秒杀系统告诉你 介绍了synchronized和ReentrantLock的区别
4. https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650781722&idx=1&sn=ee4523e2fe87aa157568f48b7f7db381&chksm=f3f90d8fc48e8499367378de6a346cab4b9f70f4e538eacf1b5e61a60e4bebfd9988d8742a34&scene=0&xtrack=1#rd 基于Redis设计一个百万级用户的高并发系统 介绍了一个抽奖系统的流量削峰架构的设计方案：第一层负载均衡层，可以设置过滤掉用户一分钟内重复的请求；第二层，利用redis维护一个抽奖状态，抽奖服务业务层更新redis（已经抽完了），负载均衡层感知了redis的状态，那么接下来的请求都被拦截；第三层，负载均衡那个层面，已经把比如50万流量中的48万都拦截掉了，但是可能还是会有2万流量进入抽奖服务，数据库的压力就会增加，利用redis替换数据库，实现抽奖业务逻辑。第四层，如礼品服务、发货等，可以通过消息队列进行流量消峰，做异步处理。整体架构图如上。

   总结如下：其实对于商品秒杀、抽奖活动、抢红包类的系统而言，架构设计的思路很多都是类似的，核心思路都是对于这种瞬时超高流量的系统，尽可能在负载均衡层就把99%的无效流量拦截掉。然后在1%的流量进入核心业务服务后，此时每秒并发还是可能会上万，那么可以基于Redis实现核心业务逻辑 ，抗住上万并发。最后对于类似秒杀商品发货、抽奖商品发货、红包资金转账之类的非常耗时的操作，完全可以基于MQ来限流削峰，后台有一个服务慢慢执行即可。

5. 的