奈學百萬業務架構師

愛分享 愛生活 加油 2021

百度網盤

提取碼：qhhv 

概述

整理了一些常見的架構設計面試題，主要記錄關鍵點，具體細節就不詳細敘述了，案例慢慢補充。目前想起如下問題：

• 秒殺系統
• 短連接生成
• 高併發的紅包系統
• 分佈式ID生成
• 分佈式限流
• 分佈式定時任務
• 新浪微博怎麼推送微博
• 大文件有限內存排序

秒殺系統

秒殺系統基本面試被問爛了，網上資料也不少，基本整理了內容以下：

設計難點：併發量大，應用、數據庫都承受不了。另外難控制超賣。

設計要點：

• 將請求儘可能攔截在系統上游，html儘可能靜態化，部署到cdn上面。按鈕及時設置爲不可用，禁止用戶重複提交請求。
• 設置頁面緩存，針對同一個頁面和uid一段時間內返回緩存頁面。
• 數據用緩存抗，不直接落到數據庫。
• 讀數據的時候不作強一致性教研，寫數據的時候再作。
• 在每臺物理機上也緩存商品信息等等變更不大的相關的數據
• 像商品中的標題和描述這些自己不變的會在秒殺開始以前全量推送到秒殺機器上並一直緩存直到秒殺結束。
• 像庫存這種動態數據會採用被動失效的方式緩存必定時間（通常是數秒），失效後再去Tair緩存拉取最新的數據。
• 若是容許的話，用異步的模式，等緩存都落庫以後再返回結果。
• 若是容許的話，增長答題教研等驗證措施。

其餘業務和技術保障措施：

• 業務隔離。把秒殺作成一種營銷活動，賣家要參加秒殺這種營銷活動須要單獨報名，從技術上來講，賣家報名後對咱們來講就是已知熱點，當真正開始時咱們能夠提早作好預熱。
• 系統隔離。系統隔離更可能是運行時的隔離，能夠經過分組部署的方式和另外 99% 分開。秒殺還申請了單獨的域名，目的也是讓請求落到不一樣的集羣中。
• 數據隔離。秒殺所調用的數據大部分都是熱數據，好比會啓用單獨 cache 集羣或 MySQL 數據庫來放熱點數據，目前也是不想0.01%的數據影響另外99.99%。

另外須要複習緩存穿透、雪崩等等問題，主要的流量都落在了緩存數據庫上，須要針對緩存數據庫的高可用做保障。

短連接生成

這個應該是比較公認的方案了：

1. 分佈式ID生成器產生ID
2. ID轉62進制字符串
3. 記錄數據庫，根據業務要求肯定過時時間，能夠保留部分永久連接

主要難點在於分佈式ID生成。鑑於短鏈通常沒有嚴格遞增的需求，可使用預先分發一個號段，而後生成的方式。

看了下新浪微博的短連接，8位，理論上能夠保存超過200萬億對關係，具體怎麼存儲的還有待研究。

紅包系統

紅包系統其實很像秒殺系統，只不過同一個秒殺的總量不大，可是全局的併發量很是大，好比春晚可能幾百萬人同時搶紅包。

主要技術難點也相似，主要在數據庫，減庫存的時候會搶鎖。另外因爲業務需求不一樣，沒辦法異步，也不能超賣，事務更加嚴格。

不能採用的方式：

• 樂觀鎖：手慢會失敗，DB 面臨更大壓力，因此不能採用。
• 直接用緩存頂，涉及到錢，一旦緩存掛掉就完了。

建議的方式：

• 接入層垂直切分，根據紅包ID，發紅包、搶紅包、拆紅包、查詳情詳情等等都在同一臺機器上處理，互不影響，分而治之。
• 請求進行排隊，到數據庫的時候是串行的，就不涉及搶鎖的問題了。
• 爲了防止隊列太長過載致使隊列被降級，直接打到數據庫上，因此數據庫前面再加上一個緩存，用CAS自增控制併發，過高的併發直接返回失敗。
• 紅包冷熱數據分離，按時間分表。

分佈式ID

分佈式ID生成大概也算老生常談的問題了，主要關鍵在因而否須要嚴格遞增，嚴格遞增的話效率必然大降。

不須要遞增的話比較簡單:

• 一種方式是預先分片，好比十臺機器，每臺先分一千個ID，一號機從0開始，二號從1000開始等等。缺點是大體上能夠被人看出來業務量。
• 另外一種方式是相似雪花算法，每一個機器有個id，而後基於時間算一個id，再加上一個遞增id。好比以下美團的方案。缺點是機器的時間戳不能回撥，回撥的話會出現問題。