前不久，朋友的公司，出現了比較大的故障。故障引起的原因也比較好解釋，因為使用了ActiveMQ的高可用級别(M-S架構，雙寫完成ACK），結果在高峰期間，造成了生産端消息擁堵，諸多請求無法落地，資料錯亂。

背景

據他說，他們的應用，級别比電信應用還要高（牛皮一定要吹），是以消息系統要求一條消息都不能丢。他做到了，但是服務不能用了。

這個Case有何而來呢？據說是來自一次高管會議上，某位上司對其中的一個小問題情緒激動：他測試環境測試的某條資料，直接不見了，生産環境并未複現。矛頭最終指向了消息系統，直接上升到斷電後怎麼辦雲雲。

上司發威，事情要特事特辦。架構組扯蛋似的熬夜讨論了改進的方案，從Kafka到RocketMQ，從落盤DB到更新到StoreHA方案，不亦樂乎。最終的讨論結果，就是采用極高可用的方式。上司的條件滿足了，消息系統也是高可用的，但整個業務不是。最終的MQ吞吐量，連個DB都不如。

典型的槍杆子需求引起的優化故障。一定不少見。

思考

高可用是個僞命題，雖然有CAP等耳熟能詳的理論支援，還是有很多人陷入了這個誤區，包括技術決策人。架構作為全局把控人，能出現這樣的錯誤，純屬低級。下面，是我自己對高可用的一點思考。

高可用不是元件高可用，是業務高可用

拿消息隊列來說，并不是說保證消息隊列的存活和消息的可靠，就完成了工作。還需要考慮生産端和消費端的拓撲和高可用。比如，生産端異常關閉，緩沖區的處理，低吞吐環境下的消息過盛處理；消費端的消息積壓，

以及死信處理。

你要是沒有提前對業務進行容量分析，也沒有相應的擴容手段，更沒有對容易發生問題的環節進行監控，那麼鍋就是你的，沒得跑。

業務先能用，然後講可靠

業務都跑不下去了，你的服務端元件無論多麼的可靠，也是廢物。拿秒殺系統來說，你不會要求它先可靠的落地，反而會用一些次可靠的緩存系統進行緩沖，此所謂可用。隻有保證了業務的正常流轉，才能談可靠性。

主要流程不能阻斷，可靠性降級

這就是大家常說的熔斷。比如一個收銀系統，不會等着你的背景真正處理了各種記賬邏輯才會傳回成功。它的主要目的就是收款，先讓你把錢花出去再說，你不能因為一個消息發送失敗，就要求支付也一塊失敗。這個時候，消息就作為一個旁路應用存在，必須設定合理的逾時，以至熔斷。

再比如放在事務中的一些高耗時操作，都是要命的玩法。

不能玩就限流，别硬撐

限流就是讓使用者在最外層就阻斷，不讓請求進來。使用者雖然會看到失敗的請求，但不會産生危害性的請求（邏輯交錯執行的資料錯亂）。撐不住就承認算了，請求導到背景，搞死了某個基礎元件，更嚴重。

資料不能丢，我還能找回來

分布式系統談的最多的就是最終一緻性，但鮮有人知，最終一緻性包括人工環節，甚至客服的介入。一般，産生異常資料的機率還是比較小的，人工可以處理過來。另外，還有其他優化手段：

1、格式化的詳盡日志，能夠根據日志恢複

2、幂等業務，請求保證at least once語義

3、通過掃描，重試等手段，進行異常資料處理

别把高可用挂在嘴上，那很sb

談高可用很牛逼麼？并不見得。你要能分析

提出方

的品性和認知能力，分析各種技術手段的後果。并不是誰的權利大誰的觀點就正确，很多上司揮舞完大棒，腦子裡就已經忘掉了2/3，不是本質問題不用關心。

分布式系統是個複雜的整體，不要以偏概全，搞定了某個元件并不等于搞定真個系統。上司會認為這樣，你不能。