從星巴克到分布式架構
--乙個故事教你搞懂高併發、分布式
singfun--
從前有這麼一家咖啡店，名字叫星巴克，這家咖啡店剛開始，只有乙個員工(大學學的是咖啡學，碩士學位)，這名員工每天的工作既擔任收銀員，又進行調製咖啡
假如有一天這名員工病了，，好傢伙，，收銀工作和調製咖啡工作都沒法幹了，，那就莫得了，所以，這兩項工作要解耦（耦：古代指的是兩人並肩而耕地，乙個不耕了，好傢伙，這地就沒法耕了），解耦就是你調咖啡的工作不會影響到我收銀的工作，怎麼做呢，再招乙個員工當收銀員，原先那個員工專職做咖啡師，這樣就完成了系統解耦(即收銀和調配咖啡那個工作互不干擾)。
系統解耦之後，當咯裡咯當，小店又開始進行營業了，開始經營的模式是什麼呢，就是收銀員列印乙個訂單等待咖啡師調製好之後，才進行下乙個列印單，那排隊的客戶不幹了，一看前面有那麼多人，我要乙個乙個等，我需要排隊到什麼時候，流失了很多客戶，後來調整了一下策略，就是使用佇列思想，來乙個訂單我打乙個來乙個訂單我打乙個，先讓顧客拿著單子心裡有乙個安慰:我的咖啡正在製作，這時候發現有的乘客又開始抱怨了，我先來的為什麼最後乙個拿走咖啡，你客戶體驗度差，那客戶也就loser了，後來收銀員進行了把客戶訂單進行佇列儲存，交給咖啡師進行順序調配，即先來先配製，這就是訊息佇列的作用:提高系統響應速度，順序處理，削峰
後來的後來。隨著生意的火爆，僅有的一名咖啡師日夜勞作，廢寢忘食，食不果腹，腹背受敵，敵我不分，身體扛不住了倒下了，這時候考慮到業務的增加，人手也應該增加，，於是老闆又招了乙個咖啡師，兩個咖啡師同時工作，提高了工作效率，，隨著生意的火爆，顧客又開始抱怨了，我在這拿著單子等了乙個小時還沒等到，麻煩給我退了吧，這時候老闆又招了5個咖啡師，這一共七個咖啡師組成了集群，(集群：同乙個業務部署在多台機器上，提高系統可用性)提高了系統的處理速度，後來收銀員也由於不堪重負，就隨風而去了，，於是老闆痛改前非，非常抱歉的又招了5個收銀員，這5個收銀員組成了什麼?同志們(集群)，後來呢由於小店只有乙個排隊打單的通道，排隊很長，都到大門外了，既不美觀，也影響後面收銀員的工作，這樣又遺失了一部分客戶，怎麼做呢，再開乙個通道，配一套收銀，配咖啡的，，這兩套組成什麼(群體集群)，
然後呢，老闆又發現了乙個問題，乙個咖啡師要完成兌水，兌咖啡的工作，兌糖的一系列工作，看起來有點慢，老闆繼續把這個咖啡的過程細化 ，兌水的 對咖啡的，兌糖的業務由三個咖啡師分別完成，這就是分布式的特點(統一業務進行拆分，本來3個小時完成的，現在只需要乙個小時，為什麼要乙個小時，你想哈，三個人一起往乙個桶裡灌水快，還是乙個人往桶裡灌水快，很顯然易見嘛，理想情況下哈)
隨著業務的發展，老闆又開了5個通道，為了防止資源的過度浪費，，老闆在門口弄了乙個總的進入通道，這個通道有什麼特點呢，他可以根據裡面引導購買者平均分配到各個購買通道(比如一共5個通道，10個人，第乙個進來的去一號購買通道，第二個進來的去二號購買通道，，依次，第六個進來的進那個通道？，當然是去一號購買通道，了)這個就是我們用的負(承擔的意思) 載均衡器的作用，即使均勻分配，這時候老闆發現還是有的通道處理的很快，有的通道處理的很慢(同樣的訂單下)，這時候調整負載均衡器權重，給處理快的通道分配更高的權重，即多分配一些資源，當然他們的工資也會相應增加，
然後呢又出現了有乙個問題，來一乙個單子 有的要糖，有的不要糖，有的不要兌咖啡，有的要兌咖啡，每次都同時調動三個業務，兌水，對咖啡，堆糖，每個人員都需要看一眼這個訂單要不要兌咖啡，要不要兌水，人員調配有點亂，老闆設定了乙個訊息分發匯流排 ，兌水系統，兌咖啡系統，兌糖系統，設定了乙個，這個單子要兌水，兌糖，發給訊息分發匯流排中介軟體，把那個兌水的，兌糖的系統同時調出來，用哪個調哪個，這就是訊息中介軟體(系統化進行資源統一調配，統一管理)的作用
下面給出概念 集群：同乙個業務部署在多台機器上，提高系統可用性
分布式：不同的業務模組部署在不同的伺服器上或者同乙個業務模組分拆多個子業務，部署在不同的伺服器上，解決高併發的問題
————————————————
你如何設計乙個高併發專案？
工作3年左右面試通常會被問到這個問題。我之前也被問到過這個問題，感覺自己回答的點不夠全面，現在重新整理下，包含不限於以下幾點 1 框架設計 對專案拆分成功能單一小專案 參考購物 使用分布式框架，如 dubbo框架，微服務框架。2 資料庫 資料庫集群部署，主備設計，讀寫分離，對資料量大讀寫操作頻繁的表...
設計乙個高併發系統
公升級過程為 最初系統 新增負載均衡 資料庫分庫分表 讀寫分離 快取集群 訊息中介軟體集群 假設系統機器是4核8g，資料庫伺服器是16核32g。日活使用者1w，系統層面每秒10次請求，資料庫層每秒30次請求。使用者量增長了50倍，日活使用者50萬，高峰期對系統每秒請求500 s，對資料庫的每秒請求1...
簡單的搭建乙個高併發低時延系統
首先宣告一點 這裡的 高併發 是相對的，相對於硬體而言，而不是絕對的高併發。後者需要分布式來實現，這裡不做討論。本文關注的是單機的高併發。系統的另乙個指標是呼叫時延和語音時延。這是這個系統的關鍵。最終我們的系統拿到使用者現場測試的時候，效果可能有點太好，對方測試不大相信。其實降低時延只要幾個地方把握...