從單機到多機：多機一定比單機快嗎？秒殺到底有沒有必要用分布式鎖？

一、單機場景

單機能承受的 TPS

• tomcat 500~1000
• mysql 200~800

在單機狀態下，tomcat 能接受的請求肯定比 mysql 更多，此時資料庫成為系統瓶頸，為了解決這個問題，可以將自增的累加器（例如請求次數、商品剩余等等）等“公共值”快取起來，放在 JVM 里面，僅讓有效請求到達資料庫，讓 DB 的 TPS 有最大利用價值，

Tomcat 是多執行緒的，會產生并發問題，我們考慮不同商品數量的情況：

• 最小，只有一件商品供秒殺，此時多執行緒在扣減商品的時候，要排隊串行，串行放進佇列里，不需要加鎖了
• 最大，很多件商品的時候，由于商品與商品之間是無關的，不同商品可以看做是并行的，同一個商品在同一個佇列里，也不用加鎖了

思考，如果第一件商品10件，第二件商品9999件，第三件商品500件，都在資料庫里，如果沒有前置判斷的話，夾雜著的請求很快會讓1件的商品賣光，后續還有很多對賣光商品的請求，白白占用了資料庫的性能，所以我們需要前置的攔截，讓最終進來的請求都是還有庫存的商品，

目前來看，是不是不用鎖了？是的，但是我們大多數人很少在開發的時候去做執行緒的資源隔離，而是直接把請求打出去，當所有請求是并發達到資料庫的時候，我們控制不了請求的順序性，所以才會有鎖的概念，

二、多機場景

場景：單機 1 個 tomcat -> 多機 2 個 tomcat

多機情況下，只有一件商品的時候，也需要加鎖，防止超賣，鎖是一個參照物，用來參照哪個執行緒取到了、哪個執行緒沒取到，鎖自身要具備排他性，即只能有一個執行緒取到，那么如何實作排他性？

• redis worker 執行緒是串行的

• zk 兩階段提交，主從，主是串行的

1、在分布式場景下，有了分布式鎖，還需要單機鎖嗎？

首先要理解的是，我們在資料庫上目的是做有效請求的過濾，讓沒有意義的操作不去消耗它的資源和網路帶寬，在微服務當中，在任何一個節點上，我們都要關注請求的有效性，雖然微服務是“不主動、不拒絕、不負責”，即使打過去的是無效請求，也會正確回傳，但 呼叫方必須考慮請求的“有效性”，不隨便去浪費服務方的資源，這是呼叫方個人價值的體現，這是面試的時候你要強調的，可以區別于其他人的，

回到這個問題，在分布式場景下，有了分布式鎖，還需要單機鎖嗎？

• 舉一個例子，如果有兩臺機器一共10個執行緒去搶鎖，在只有1件商品的情況下，最終只有1個執行緒能拿到鎖，而服務方承受的I/O的負載是O(10)，

• 同樣的情況，如果你對每個單機加鎖，服務方承受的I/O的負載就只有O(2)，在整體的性能上會有提高，另外，如果不想用本地鎖，也想達到O(2)的效率的話，你也可以在每個單機上用邏輯做資源隔離，通過佇列實作串行，

2、多件商品情況下，商品之間其實是無關的

商品之間無關，所以多件商品和一件商品的情況類似，在用戶下單后，n 件商品經過過濾，最終每件商品只有有效請求到達資料庫，大大減少了資料庫的壓力，

比如，限制每個用戶只能買 3 種商品，每個商品限購 2 件，系統應該怎么設計？

根據“只能有效請求到達資料庫”原則，多余秒殺的商品不應該到達資料庫浪費I/O資源，因此應該做前置過濾，解決方法是將 redis 集群前移，在 redis 里面將售賣規則創建成 key，后續用業務邏輯判斷此次用戶請求是否能夠生成訂單，

比如，一個用戶請求到達之后，去 redis 取商品種類、商品單品數量、用戶 id，帶著想要秒殺的商品的 itemid 一起回傳到 tomcat，由業務邏輯判斷這個用戶能不能下單，從而識別“有效請求”，你也可以用 redis 事務來處理一個用戶的多個減庫存，防止超出限購數量，識別了有效請求（防止超賣）后，生成訂單即可，因為第三方支付是異步的，后續訂單可以走佇列了，無需再加鎖，佇列的遷移到后續的分庫分表，是后續調優要考慮的問題，

另外，商品數量足夠大的話，不同商品可能放在 redis 不同的節點中，稍顯復雜，這個是開發人員要考慮的邏輯，redis 磁區后，就不能使用 LUA 腳本和事務實作上述多個判斷邏輯了，需要自己寫邏輯實作了，

3、服務的無狀態性：多機一定比單機快嗎？都說秒殺場景一定要用分布式鎖，真的是這樣嗎？

首先要理解一個概念，就是 服務的狀態性，累加器、公共值，屬于狀態資料，為了維護多機的狀態，要保持資料的同步，去做事件傳遞，去做分布式協調，zk 是主從架構，性能并不高，僅應該用來維護核心且不經常發生變化的那些資料的一致性，并不是一個很好的用于資料同步的技術方案，正確的方式是做服務狀態的遷出，而不是去多臺機器上做資料的同步，

單機情況下，沒有到達瓶頸的時候，單筆業務處理速度是最快的，加機器并不能提升速度，反而由于網路開銷，讓單筆請求變慢，而且單機是不需要外部鎖的，而多機要做一致性、同步問題，反而加機器會讓整個系統變慢，

那為什么常說多機會變快？這樣說的前提是：不只有一件商品，如果只有一件商品，最終都要成為串行去扣這一件商品的庫存，多機一定不會帶來速度的提升，而在多件商品的情況下，多機可以讓無關的商品之間并行，不同商品的減庫存進入不同的機器并同時執行，而受制于一臺機器的性能問題，雖然可能會排隊，但最終的表現是，多機能夠“讓無關請求并行起來”，因此才會有所謂的“快”，

最后，無論你怎么變，（考慮到多機存在的資料同步問題和單機存在的CPU調度問題），在“沒有資源瓶頸”的時候，并行總是會比串行慢，串行才是效率最高的方式，

4、升華：從商家的角度，秒殺的目的是什么？

從商家的角度，不是每個人都能拿到秒殺的便宜，秒殺是為了引流，應該用更低的成本獲得更多的用戶使用這個平臺，完成秒殺，在秒殺的同時，也應該做限購，即一個用戶只能拿走一件商品，加了限購的秒殺才是完善的秒殺系統，

秒殺場景下，會有很多人刷單，因此才更應該僅讓有效請求到達資料庫，根據上面的方案，無效請求都讓 redis +業務邏輯 擋住了，保護了mysql，

那如果用戶下單之后不付款，交易失敗怎么辦？你仍然要從商家的角度考慮，實際上，賣少了沒關系，但不能超賣，況且，如果秒殺沒有結束，你可以把庫存加回去，這就是產品經理和程式員要換位思考，

5、秒殺系統還需要分布式鎖嗎？

不需要了，redis 所有的操作是串行的，每一個操作擁有了原子性和排他性，分布式鎖成本是很高的，上述解決方案將 redis 集群前移來做請求有效性識別、減庫存這些事情，就不需要做分布式鎖了，

所以，對于任何系統設計，不要上來就推導“多機”的架構模式，

6、redis 宕機了怎么辦？

程式員代碼不能解決所有問題，要在其他地方做補償，例如你還是要靠運維、靠linux內核調優、靠監控系統、靠服務器硬體的冗余能力，在秒殺這樣的特殊場景，你還是需要對服務器細心照顧、特殊對待，不要因為技術而技術，要從企業的角度其實追求可用性，

如果不斷的追求某個問題的解決方案，很可能會引入其他的問題，也不要把平時的解決方案放進特殊場景中使用，可能會引起蝴蝶效應，風險很大，美團發布過一篇實戰文章，在大量并發情況下關閉健康檢查，避免一些節點被剔除，必要的時候，讓一些用戶的請求失效，雖然可能會讓用戶體驗上稍微慢一些，但保證整個服務的可用性才是最重要的，站在產品經理的角度來看，這個方案可以了，

7、那分布式鎖豈不是沒用了？什么場景需要分布式鎖呢？

分布式鎖其實是在解決并發問題，未來很多公司采用回應式編程、流式編程模型（而且已經有公司落地了），無狀態、無鎖化將是趨勢，

如果你學過大資料的話會更好理解，map reduce 計算框架，map 處理資料初始狀態進行加工，同一資料做 reduce 的時候會有磁區概念，最后分治匯總，

所以，在開發的時候，我們應該盡量去規避分布式鎖，去采用無鎖化的方式解決問題，