高併發和秒殺系統設計

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