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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。