環境
MacBook Pro
前言
今天讀了如下文章，產生了一些感想和總結；
https://doocs.github.io/advanced-java/#/./docs/high-concurrency/how-to-ensure-the-order-of-messages
如何保證消息的順序性
對順序有嚴格要求的話，真正能保證順序的是一個隊列讓一個線程去消費。
而且還必須保證數據足夠分散。不然都跑到一個隊列裏，一個線程來消費的話，
這樣吞吐量就很小。
而如何去分散數據到不同的隊列中得根據具體業務來。
拿股票來說，委託爲 股票、期貨，這種就沒必要公用一個隊列（queue）了，而是股票一個隊列、期貨一個隊列。當然這個例子並不好，因爲即使股票是一個隊列，假設有100萬股民在同時交易，一個線程也處理不及時。所以得進一步去細分，比如按IP地址來細分，華北和華南在細分一下。
反正永遠要記住，多線程執行，你不知道哪個線程先執行，哪個後執行。所以對於有順序要求的消息來說，一定是一個線程去消費一個隊列。而我們需要做的就是讓隊列的數據量都很均勻。也就是要不斷細分，直到系統能承受爲止。
分佈式的本質
分佈式就是看 數據是不是足夠分散~
集羣模式的分散：一份數據，多個節點都有，並且擁有的都是完整的數據；
好處：是有利於讀寫分離，主節點寫，從節點讀。
壞處：①網絡開銷非常大，因爲主節點修改後，都得同步給從節點，而從節點可能有10個，100個，1000個。② 當數據量超過了單個節點的承受能力時，這時，你加機器做水平擴展也沒用。
好的分佈式應該是：一份數據存在多個機器上，每個機器只存部分數據 – 其實就是分片.
上面的分片只是解決了分散的問題，假設有三臺機器，其中一臺掛了，就會導致數據丟失，
所以還需要有replica(副本集)，對每個分片進行備份；
當有這麼多副本集後，又會有新的問題，那就是哪個節點誰來做老大（leader）呢？總不能隨機吧（計算機真的有隨機嗎？只不過是個超大型的循環罷了）
主流的做法：在多個副本集中選舉出一個leader。讀寫都由這個節點負責，爲啥呢？爲了確保數據的一致性，因爲當寫入數據時，需要同步到相應的follower節點上，這個過程是需要時間。
當然如果，我們希望分佈式集羣就是可用性高於一致性的話，那麼也可以主節點寫，follower從節點讀。