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

　　2. 設計要點：

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

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

　　- 數據用緩存抗，不直接落到數據庫。

　　- 讀數據的時候不做強一致性教研，寫數據的時候再做。

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

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

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

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

　　3. 其他業務和技術保障措施：

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

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

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

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

　　1. 分布式ID生成器產生ID

　　2. ID轉62進制字符串

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