從大學到工作，感覺最大的成長就是認知上的。
比如，最初需要考慮的是功能如果實現，怎麼把它給實現了。現在要考慮的是如何讓服務變得高可用。
這需要我們開始拓寬自己的技術視野，一個技術，一箇中間件不是搭建一下使用一下就完事了，更應該去關注它的高可用。
# # 有多少高可用
有多少中間件，就有多少高可用。比如緩存中間件redis，就要有redis高可用；比如使用了消息隊列，就要有消息隊列的高可用。
那爲什麼不是實現功能就行了呢，因爲一旦考慮使用中間件，來幫我們解耦也好，幫我們提升性能也好過，又或者說，使用中間件來解決系統不能解決的問題。
代碼的設計原則中有一個最少知道原則，就像一個祕密，最好是你一個人知道，這樣最安全，你只用擔心做夢的時候會說出來而已，一旦有第二個人知道，就多了一份風險。同樣的道理，系統設計也是，在使用中間件的時候，就已經把祕密告訴了別人，這樣維護起來一定是增加了難度。選用中間件的時候，其實也是一種權衡，往往呢，引入中間件，給我們帶來的提升更大一點，所以還是會用中間件。那麼既然不得不用，那就不得不考慮它的高可用，否則就像一個祕密只有某幾個人知道，不能讓更多人的人知道一樣，一旦有一個人說出去了，就不是祕密了。那麼對系統而言，這叫單點故障，如果中間件出了任何問題，將會導致整個系統不可用。所以說是非常嚴重的。
# # 那麼多中間件，那麼多高可用，是不是思想應該是一樣的呢
程序的思想並沒有那麼高大上，普通的就像生活中的小事一樣。
比如你想做一件事，要保證一定要做好它，這件事的時間跨度又比較長。可是人總會生病，總要喫飯。那怎麼解決呢，其實每個人都會想到，就是在找一個人和你你起幹，在後邊看着，你不能幹的時候，它立馬頂上來。這種就是最早的高可用實現方案，就是副本的概念。
多副本最早的是 Master/Slave 架構，即簡單地用 Slave 去同步 Master 的數據，RocketMQ 最早也是這種實現。分爲同步模式（Sync Mode）和異步模式（Async Mode），區別就是 Master 是否等數據同步到 Slave 之後再返回 Client。這兩種方式目前在 RocketMQ 社區廣泛使用的版本中都有支持，原理圖如下圖 1 所示。
你做的事，慢慢做大了了，你一個人忙活不起來了，所以你想開分店。每個店都需要有一個 Master，有一到多個 slaver。
店開多了，老闆還是要有的，就理解成 CEO 吧，生活中你是老大，就一直是老大了，但是計算機裏邊並不是，而是使用選舉策略進行選舉。沒錯就像村裏選村長一樣，少數服從多數。
說到高可用，通過上邊的例子，那就是集羣了。集羣是能解決一個人幹不了的事，但是同樣會帶來多個人的麻煩。一個人幹活沒人吵架，兩個人幹活，你就有可能和另外一個人有分歧的時候，如果一起集羣裏邊有三個人，那你就有可能和兩個人有意見分歧的一個道理。
到底聽誰的，如何選舉出來一個領導人，以及如何保證消息的互通，就是集羣需要解決的最大的問題。
先來看一下三種實現高可用的方案：https://www.infoq.cn/article/f6y4QRiDitBN6uRKp*fq
再一起看一下 zookeeper 實現的 Paxos 算法，就是用來選舉的：https://www.zhihu.com/question/19787937
# # 通過集羣來實現高可用
通過集羣來做到高可用，就一定繞不開兩個問題，一個是選舉領導人，一個是消息共享。在上邊的文章中應該也看到了DLedger
# # Redis 的高可用方案選擇
https://yq.aliyun.com/articles/626532
# # 高可用的通性問題
~待整理