昨天回答的太差了，明明都是些很簡單的東西，我居然回答的那麼差
，讓我很有挫敗感
， 一些概念性的東西這裡就不說了，下面兩個問題，重新梳理一下：
1，一致性雜湊虛擬節點與真實節點對映關係的建立：現在我們使用的是字串構成的圓環， 每台真實伺服器生成n個虛擬節點，虛擬節點生成的規則為， 用$i遍歷從0到n-1， 對字串"_"做md5， 生成乙個虛擬節點。如果是整形圓環， 可以每台伺服器生成n個虛擬節點， 同樣遍歷從0到n-1，每次遍歷生成0到2^32-1的乙個隨機數， 這個隨機數作為虛擬節點。
2，秒殺問題：我對秒殺業務並不熟悉， 所以這裡我只能假設業務：m個使用者在乙個時間點搶n個商品，m有可能在0到幾千萬不等， n為1到數千。要做乙個這樣的系統， 業務會分為兩個階段，第乙個階段是秒殺開始前某個時間到秒殺開始， 這個階段可以稱之為準備階段，使用者在準備階段等待秒殺； 第二個階段就是秒殺開始到所有參與秒殺的使用者獲得秒殺結果， 這個就稱為秒殺階段吧。
首先要有乙個展示秒殺商品的頁面， 在這個頁面上做乙個秒殺活動開始的倒計時，
在準備階段內使用者會陸續開啟這個秒殺的頁面， 並且可能不停的重新整理頁面。這裡需要考慮兩個問題：
第乙個是秒殺頁面的展示， 我們知道乙個html頁面還是比較大的，即使做了壓縮，http頭和內容的大小也可能高達數十k，加上其他的css， js，等資源，如果同時有幾千萬人參與乙個商品的搶購，一般機房頻寬也就只有1g~10g，網路頻寬就極有可能成為瓶頸
，所以 這個頁面上各類靜態資源首先應分開存放，然後放到cdn節點上分散壓力，由於cdn節點遍布全國各地， 能緩衝掉絕大部分的壓力， 而且還比機房頻寬便宜~
第二個是倒計時， 出於效能原因這個一般由js呼叫客戶端本地時間，就有可能出現客戶端時鐘與伺服器時鐘不一致， 另外伺服器之間也是有可能出現時鐘不一致。客戶端與伺服器時鐘不一致可以採用客戶端定時和伺服器同步時間， 這裡考慮一下效能問題，用於同步時間的介面由於不涉及到後端邏輯， 只需要將當前web伺服器的時間傳送給客戶端就可以了， 因此速度很快， 就我以前測試的結果來看，一台標準的web伺服器2w+qps不會有問題，如果100w人同時刷，100w qps也只需要50臺web， 一台硬體lb就可以了~，並且web伺服器群是可以很容易的橫向擴充套件的(lb+dns輪詢)， 這個介面可以只返回一小段json格式的資料，而且可以優化一下減少不必要cookie和其他http頭的資訊，所以資料量不會很大， 一般來說網路不會成為瓶頸，即使成為瓶頸也可以考慮多機房專線連通，加智慧型dns的解決方案 ；web
伺服器之間時間不同步可以採用統一時間伺服器的方式， 比如每隔1分鐘所有參與秒殺活動的web伺服器就與時間伺服器做一次時間同步。
準備階段的就是這些了， 下面正式開始進行秒殺，兩種思路， 第一種為中心化，第二種為去中心化。這裡假設一種場景， 100w人搶1個商品，如果用去中心化的思路顯然沒法搞（我昨天說的使用商品池就是去中心化的思路， 晚上想來是有問題的）， 但這種業務很可能是大量存在的， 所以我們嘗試使用中心化的思路。
先想的簡單一點， 1個商品在中心化的商品伺服器上， 當乙個秒殺的請求到來的時候， 我們需要鎖住這個商品，判斷商品狀態，修改這個商品的狀態為已被秒殺， 然後釋放鎖。這個過程就算再優化， 再快，我就算給你單台100w qps，那如果有1000w人來秒殺，1000w請求同時從web伺服器湧來， 它也頂不住， 因為它無法擴充套件， 所以我們需要想一點辦法。
我想到的辦法是加乙個候選人中介軟體在web伺服器和中心商品伺服器之間（見附件的架構圖），在候選人中介軟體中維護乙個候選人佇列（所有候選人佇列中的佇列單元數量之和需要大於秒殺商品數量）， 當請求從web伺服器**過來的時候， 首先判斷這個佇列是否已滿， 如果沒滿就將請求放入佇列中排隊，佇列滿以後的所有請求直接返回秒殺失敗。中介軟體在處理web伺服器請求的同時，**佇列中的請求給中心商品伺服器（這裡可以使用生產者-消費者模型），中心商品伺服器將前面n個成功秒殺的結果返回後， 返回秒殺結束。中介軟體收到商品伺服器返回的秒殺結束，給佇列中的所有請求返回失敗， 以後進來的請求也全部返回失敗， 這樣就大大降低了中心商品伺服器的請求數， 甚至可以在候選人中介軟體和中心商品伺服器之間再加一層候選人中介軟體，這樣形成乙個多層次的快取架構，流量每經過一層就會減少， 最後將到達中心商品伺服器的流量控制在一定的範圍內。
最後還要考慮一些單點的問題， 這裡時間伺服器和後面的中心商品伺服器都是單點。
時間伺服器好辦， 可以採用樹狀結構的時間伺服器模型， 所有時間伺服器都去同步root節點的時間伺服器， 然後web伺服器設定同步多台時間伺服器，當一台down掉的話web伺服器還可以和另外的時間伺服器繼續同步，如果root節點的時間伺服器down掉， 就從下層的伺服器裡面拿一台出來做root就可以了。
中心商品伺服器的話可以使用一些同步複製的技術，比如底層的drbd或者類似mysql的 semi synchronous。當運氣實在太背~，一台商品伺服器在秒殺的過程中down掉，另外一台可以迅速接管。另外還可以使用共享儲存的方式，不過據說這個比較昂貴哈~。
寫這麼多，還花了個圖， 累死我了， 看來還是夜深人靜的時候思路清晰一些，如果以後還有面試機會， 請半夜打**來~
美妙的秒殺架構
秒殺程式問題根源在於 海量的請求在爭搶有限的資源，秒殺其實和火車票非常像，都是對有限資源的搶占。這一點和微博不一樣，微博不需要加鎖，是客戶端來拉去，資源是不受限的。首先是要對於架構進行分層，最上面是展示層，其次是站點層，然後是服務層，最後才是資料層。秒殺架構的核心其實 保護資料層，因為在整套秒殺架構...
設想秒殺架構
b color red 背景設想 color b 千萬使用者在同一時間點向伺服器傳送請求 b color red 伺服器猜測 color b 1 千台lvs或者nginx等負載均衡伺服器 2 上萬台web伺服器集群處理前端伺服器 後的http請求 3 千台memcache等快取伺服器或者redis類...
關於秒殺架構的思考
秒殺構架到如今是乙個很常見的業務場景，多數情況要考慮到瞬時的流量峰值不至於壓垮系統，但同時又要保證整個業務系統的可用性,許多大公司在面試的時候也會問到關於秒殺的問題。秒殺場景的業務場景包括 比較優惠 推廣效果比較好 在短時間內順時將商品售空 技術需求分析重點考慮以下幾點 關於商品的超買超賣的問題 訂...