高並發和秒殺系統設計

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 的區別 說的很明了