微博熱搜、天貓秒殺、12306搶票，都是高併發，難點相同嗎？

又是一年春運搶票時，12306 又掛了。同爲高併發，微博熱搜、天貓秒殺、12306 搶票有什麼不一樣呢？

本文徹底基於我的的有限的經驗和了解，若是文中有什麼問題還請你們一塊兒討論和指正。

微博熱搜

「微博熱搜」是一個典型的讀多寫少場景。讀今日的熱點新聞，寫本身的微博評論。

做爲一個後端開發，看到「讀多寫少」，第一反應就應該想到要加緩存。

但是，爲何微博老是宕機，抵擋不住 xxx 明星出軌新聞流量？

對微博來講，難點在於熱點沒法預測，在面對突發流量時，如何快速擴容。

電商秒殺

電商秒殺的大部分作法都是先定日子，而後上報要參與的秒殺商品，最後倒計時秒殺。

也就是說，何時會有秒殺活動，哪些商品會參與秒殺，這些數據在秒殺前服務端是均可以獲取到的。

而這些數據，也正是關鍵的「熱點數據」。

有了熱點數據以後，服務端能夠在秒殺開始前，先加載好相關熱點數據的緩存，作好預熱。

同時，在秒殺前作好相應的限流、擴容準備，已應對即將到來的突發流量。

秒殺的限流，能夠從客戶端開始作起，js 動態的 sleep 一會，延遲請求，讓用戶看一會秒殺的排隊動畫。

至於服務端，徹底能夠只由一臺服務器真正的處理用戶秒殺請求，別的服務器能夠不操做任何數據，只記錄用戶秒殺參與日誌。

12306 搶票

12306 搶票是一個類秒殺的業務，其核心爲：查票、買票。

那麼，12306 的秒殺和電商的秒殺有什麼不同嗎？

電商秒殺：秒殺的對象是商品，一個商品的 sku 個數老是有限的，客戶端直接將用戶想要購買的 skuId 傳給服務端便可。

12306 搶票：秒殺的對象是票。「票」是一個很特殊的商品，好比從杭州到北京，沿路會通過若干各站點。起始站點、車次、時間，各類不一樣的選擇會組合出各類不一樣的結果，即使是「查票」這一個功能，服務端可能也須要大量的計算。不一樣的組合方式可能就是不一樣的下單行爲，而秒殺，直接秒對應的商品便可。