業務分析
技術挑戰
請求響應要快：無論成功失敗，需要盡快返回給使用者
架構設計
前端：靜態化
站點層：限制請求數
服務層：樂觀鎖寫快取
資料庫cap：讀寫高可用，一致性，擴容
資料負載，網路頻寬
站點層（web伺服器壓力）
伺服器層（應用伺服器壓力）
資料層（資料庫壓力）
應該根據庫存總量進行流量控制，假如庫存總量是1萬，需要10臺伺服器處理，但參與秒殺的訪客可能有5萬，
理論上需要50臺伺服器支撐，但是完全沒有必要為了那4萬將要被淘汰的訪客去新增40臺伺服器，因為根本沒有意義。
需要多少太伺服器是根據業務量和伺服器處理能力來決定，而不是根據qps來決定的。
悲觀鎖思路
佇列思路
樂觀鎖思路
通過乙個賬號，一次性發出多個請求
多個賬號，相同ip，一次性傳送多個請求
多個賬號，不同ip，一次性傳送多個請求
秒殺系統架構設計
最近聊天總有人問秒殺的架構設計，秒殺這種業務場景一直是個熱門話題，網上也看了很多，感覺大牛分享的12306的搶票架構挺不錯的。文章講的從網路接入開始，不是那種空洞的架構。1，client請求接入到內網後，通過ospf協議進行第一步負載均衡，2，請求被 到多台lvs負載均衡器，lvs是網路層負載，效率...
秒殺系統的架構設計
秒殺系統，是典型的短時大量突發訪問類問題。對這類問題，有三種優化效能的思路 寫入記憶體而不是寫入硬碟 非同步處理而不是同步處理 分布式處理 用上這三招，不論秒殺時負載多大，都能輕鬆應對。更好的是，redis能夠滿足上述三點。因此，用redis就能輕鬆實現秒殺系統。用我這個方案，無論是電商平台 秒殺，...
架構設計常見的幾類問題
一 儲存系統的常見弊病 普通的儲存系統，往往存在 1 資料非高可用 2 單點寫入 的問題，解決的方 如何？二 儲存系統多點寫入問題 1 儲存系統能否支援多點寫入？2 多點寫入可能存在什麼問題？3 常見的解決方案是什麼？三 雜湊與雜湊的可逆性 1 由hash反推資料，是否可行？2 如何能夠得到 特定h...