1. 設計難點： 并發(fā)量大，應用、數(shù)據(jù)庫都承受不了。另外難控制超賣。

　　2. 設計要點：

　　- 將請求盡量攔截在系統(tǒng)上游，html盡量靜態(tài)化，部署到cdn上面。按鈕及時設置為不可用，禁止用戶重復提交請求。

　　- 設置頁面緩存，針對同一個頁面和uid一段時間內(nèi)返回緩存頁面。

　　- 數(shù)據(jù)用緩存抗，不直接落到數(shù)據(jù)庫。

　　- 讀數(shù)據(jù)的時候不做強一致性教研，寫數(shù)據(jù)的時候再做。

　　- 在每臺物理機上也緩存商品信息等等變動不大的相關的數(shù)據(jù)

　　- 像商品中的標題和描述這些本身不變的會在秒殺開始之前全量推送到秒殺機器上并一直緩存直到秒殺結(jié)束。

　　- 像庫存這種動態(tài)數(shù)據(jù)會采用被動失效的方式緩存一定時間(一般是數(shù)秒)，失效后再去Tair緩存拉取最新的數(shù)據(jù)。 - 如果允許的話，用異步的模式，等緩存都落庫之后再返回結(jié)果。

　　- 如果允許的話，增加答題教研等驗證措施。

　　3. 其他業(yè)務和技術保障措施：

　　- 業(yè)務隔離。把秒殺做成一種營銷活動，賣家要參加秒殺這種營銷活動需要單獨報名，從技術上來說，賣家報名后對我們來說就是已知熱點，當真正開始時我們可以提前做好預熱。

　　- 系統(tǒng)隔離。系統(tǒng)隔離更多是運行時的隔離，可以通過分組部署的方式和另外 99% 分開。秒殺還申請了單獨的域名，目的也是讓請求落到不同的集群中。

　　- 數(shù)據(jù)隔離。秒殺所調(diào)用的數(shù)據(jù)大部分都是熱數(shù)據(jù)，比如會啟用單獨 cache 集群或 MySQL數(shù)據(jù)庫來放熱點數(shù)據(jù)，目前也是不想0.01%的數(shù)據(jù)影響另外99.99%。另外需要復習緩存穿透、雪崩等等問題，主要的流量都落在了緩存數(shù)據(jù)庫上，需要針對緩存數(shù)據(jù)庫的高可用作保障。

　　4. 短鏈接生成 這個應該是比較公認的方案了：

　　1. 分布式ID生成器產(chǎn)生ID

　　2. ID轉(zhuǎn)62進制字符串

　　3. 記錄數(shù)據(jù)庫，根據(jù)業(yè)務要求確定過期時間，可以保留部分永久鏈接 主要難點在于分布式ID生成。鑒于短鏈一般沒有嚴格遞增的需求，可以使用預先分發(fā)一個號段，然后生成的方式。看了下新浪微博的短鏈接，8位，理論上可以保存超過200萬億對關系，具體怎么存儲的還有待研究。