高并发和秒杀系统设计

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. https://www.toutiao.com/a6744868257422918156/ 互联网架构“高并发”到底怎么玩？ 介绍了从负载均衡层、业务逻辑层、数据库层三个方面如何进行扩展。
6. https://www.toutiao.com/a6735675989742846467/ 这一次，彻底弄懂“秒杀系统” 介绍了从客户端层、代理层、应用层、数据库层的设计
7. https://www.toutiao.com/a6749132208927146503/ 每秒上千订单场景下的分布式锁高并发优化实践 介绍了利用分布式锁来进行“超卖”的解决方案，并且介绍了利用分段来进行优化。
8. https://www.toutiao.com/a6749352569287475720/ 面试和工作中都会遇到的一个棘手问题：系统如何才能支持高并发 介绍了如何逐步支持高并发，业务系统集群部署、数据库分库分表、主从分离、读写分离、缓存、MQ消峰等方式，这些都是概念性的，真实的场景比这些都要复杂。
9. https://www.toutiao.com/a6750063880317174284/ 在高性能分布式系统上，你是怎么使用锁的？介绍了如何使用redis来进行锁的操作。
10. https://www.toutiao.com/a6749875923564102155/ 秒杀架构实践（乐观锁策略） 介绍了乐观锁更新 + 分布式限流 + Redis 缓存 + Kafka 异步
11. https://www.toutiao.com/a6750931539883721219/ Lock与synchronized 的区别 说的很明了