• QQ 業務特點：細粒度數據查詢
  • 即使并發量很大，鎖沖突其實不大，數據水平切分后，因為帶上了 uid，gid 等字段，用戶層面幾乎沒有鎖沖突
• weibo業務特點:讀多寫少，有少量讀寫鎖沖突
  • 微博的核心業務是feed流:
    • 發消息，寫操作
    • 刷消息，讀操作
  • 微博業務顯然是讀多寫少的，在用戶刷消息時，自己feed流里的消息，是由別人發出的。
• 秒殺業務特點:數據量少，寫多讀多,極大鎖沖突
  • 12306的核心業務是:
    • 查票，讀操作
    • 買票，寫操作
  • stock(id, num) //核心數據結構：某一列車有多少張余票
  • 在用戶量很大，并發量很大時，有極大的鎖沖突。
• 方向上“降低數據層鎖沖突”，具體兩大要點:
  • (1)降讀：用緩存
  • (2)降寫：把請求攔截在系統上游
• 用緩存降低數據層讀請求，不展開
  • 秒殺買票，這是一個典型的讀多寫少的業務場景:
    • 車次查詢，讀，量大
    • 余票查詢，讀，量大
    • 下單和支付，寫，量小
  • 一趟火車2000張票，200w個 人同時來買，最多2000個人下單成功，其他人都是查詢庫存，寫.
  • 比例只有0.1%，讀比例占99.9%，非常適合使用緩存來優化。
• 如何將請求，攔截在系統上游?
  • 先看看上下游分層架構，秒殺業務，常見的系統分層架構如何?
    • 瀏覽器->站點->服務->數據
  • 第一層，端上的請求攔截(瀏覽器/APP)，可以做一些限速策略，限制用戶在 X 秒內只能做一次請求
  • 第二層，站點層的請求攔截，使用 session，用戶 uid 或 token 等識別同一用戶，進行限速攔截，高級一點可以返回頁面緩存，即返回上一次的內容
  • 第三層，服務層的請求攔截，知道了業務層的抗壓能力和庫存，可以根據此進行限速，使用消息隊列或內存中的隊列
  • 第四層，數據庫閑庭信步，基本不需要做什么，因為到這里訪問量應該很低了
• (1)按照上面的優化方案,其實壓力最大的反而是站點層，假設真實有效的請求數是每秒100w，這部分的壓力怎么處理?
  • 站點層的擴容非常容易，測算出機器的處理能力，直接加機器即可，此外其實不需要所有的請求都處理返回，可以服務降級，把大部分的請求失敗掉即可，保護系統是最優先原則
• (2)站點層限速，是個每個uid的請求計數放到redis里么?吞吐量很大情況下，高并發訪問redis，網絡帶寬會不會成為瓶頸?
  • redis 可以做水平切分，如果擔心網絡帶寬，可以使用內存隊列
• 任何脫離業務的架構設計都是耍流氓，產品+技術，不可分割，產品上，能夠如何“優化"，以簡化系統架構設計呢?
  • case 1 下單與支付分離
    • 一般來說，下單和支付放在同一個流程里，能夠提高轉化率。
    • 對于秒殺場景，產品上，下單流程和支付流程異步，放在兩個環節里，能夠降低數據庫寫壓力。
    • 12306， 下單成功后，系統占住庫存，45分鐘之內支付即可。
  • case 2 分城市用戶規則差異化
    • 一般來說，所有用戶規則相同，體驗會更好。
    • 對于秒殺場景，產品上，不同地域分時售票，雖然不是所有用戶規則相同，但能夠極大降低系統壓力。
    • 北京9:00開始售票，上海9:30開始售票，廣州XX開始售票，能夠分擔系統壓力。
  • case 3 按鈕只能點一次
    • 秒殺場景，由于短時間內并發較大，系統返回較慢，用戶心情十分焦急，可能會頻繁點擊按鈕，對系統造成壓力。
    • 產品上可以優化為，一旦點擊，不管系統是否返回，按鈕立刻置灰，不給用戶機會頻繁點擊。
  • case 4 庫存顯示粒度加粗
    • 一般來說，顯示具體的庫存數量，能夠加強用戶體驗。
    • 對于秒殺場景，產品上，只顯示有/無車票，而不是顯示具體票數目，能夠降低緩存淘汰率。
    • 顯示庫存會淘汰N次，顯示有無只會淘汰1次。更多的，用戶關注是否有票，而不是票有幾張。
• 總結
  • 一、秒殺業務為什么難?數據量并不大，但鎖沖突巨大
  • 二、系統架構優化，方向上，降低數據層鎖沖突
    • (1) 降讀:用緩存
    • (2) 降寫:把請求攔截在系統上游
  • 三、架構難度大，產品要折衷

總結

以上是生活随笔為你收集整理的《秒杀系统架构设计》学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。