秒殺程式問題根源在於：海量的請求在爭搶有限的資源，秒殺其實和火車票非常像，都是對有限資源的搶占。這一點和微博不一樣，微博不需要加鎖，是客戶端來拉去，資源是不受限的。
首先是要對於架構進行分層，最上面是展示層，其次是站點層，然後是服務層，最後才是資料層。秒殺架構的核心其實：保護資料層，因為在整套秒殺架構中，其實最危險的就是資料層，因為資料層（db）的併發量在各層中是最小的，所以，要把不必要的操作在資料層之上就hold住。
首先是展示層，每次查詢間隔控制n秒，比如按鈕置灰；避免等待過程中使用者頻繁提交；
但是如果是程式設計師使用者呢？他們可以模擬客戶端迴圈傳送請求，這個時候，就需要站點層進行過濾，過濾的規則是uid（session）資訊，如果某個session5秒內進行了兩次操作，則進行遮蔽；可以通過nginx來進行分流，並根據hash值來將同乙個session定位到同一臺機器上面。
如果使用者是黑客呢？手中掌握了10w肉雞，呵呵，可能誇張一些，但是如果情況確實是海量使用者來訪問，那麼核心在於服務層，前兩層主要過濾非法請求，服務層才是真正過濾合法請求：佇列。比如北京大連只有2000張，ok，排隊列，數量超過的直接返回請稍後再試，讓使用者再次重新整理頁面，看到真實數量。服務層才是真實的和資料庫互動，這個時候資料庫的壓力已經非常小，首先請求一定是合法請求，其次佇列已經把訪問數量進行控制。
看完了這篇文章頓時感到非常暢快，之前對於秒殺這種高併發一直有些懵懂，現下了解了。
秒殺的架構
昨天回答的太差了，明明都是些很簡單的東西，我居然回答的那麼差 讓我很有挫敗感 一些概念性的東西這裡就不說了，下面兩個問題，重新梳理一下 1，一致性雜湊虛擬節點與真實節點對映關係的建立 現在我們使用的是字串構成的圓環，每台真實伺服器生成n個虛擬節點，虛擬節點生成的規則為，用 i遍歷從0到n 1，對字串...
設想秒殺架構
b color red 背景設想 color b 千萬使用者在同一時間點向伺服器傳送請求 b color red 伺服器猜測 color b 1 千台lvs或者nginx等負載均衡伺服器 2 上萬台web伺服器集群處理前端伺服器 後的http請求 3 千台memcache等快取伺服器或者redis類...
關於秒殺架構的思考
秒殺構架到如今是乙個很常見的業務場景，多數情況要考慮到瞬時的流量峰值不至於壓垮系統，但同時又要保證整個業務系統的可用性,許多大公司在面試的時候也會問到關於秒殺的問題。秒殺場景的業務場景包括 比較優惠 推廣效果比較好 在短時間內順時將商品售空 技術需求分析重點考慮以下幾點 關於商品的超買超賣的問題 訂...