如何保證訊息不丟失

就我們市面上常見的訊息佇列而言，只要配置得當，我們的訊息就不會丟。

先來看看這個圖，

可以看到一共有三個階段，分別是生產訊息、儲存訊息和消費訊息。我們從這三個階段分別入手來看看如何確保訊息不會丟失。

生產訊息

生產者傳送訊息至Broker，需要處理Broker的響應，不論是同步還是非同步傳送訊息，同步和非同步回撥都需要做好try-catch，妥善的處理響應，如果Broker返回寫入失敗等錯誤訊息，需要重試傳送。當多次傳送失敗需要作報警，日誌記錄等。

這樣就能保證在生產訊息階段訊息不會丟失。

儲存訊息

儲存訊息階段需要在訊息刷盤之後再給生產者響應，假設訊息寫入快取中就返回響應，那麼機器突然斷電這訊息就沒了，而生產者以為已經發送成功了。

如果Broker是叢集部署，有多副本機制，即訊息不僅僅要寫入當前Broker,還需要寫入副本機中。那配置成至少寫入兩臺機子後再給生產者響應。這樣基本上就能保證儲存的可靠了。一臺掛了還有一臺還在呢（假如怕兩臺都掛了..那就再多些）。

那假如來個地震機房機子都掛了呢？emmmmmm...大公司基本上都有異地多活。

消費訊息

這裡經常會有同學犯錯，有些同學當消費者拿到訊息之後直接存入記憶體佇列中就直接返回給Broker消費成功，這是不對的。

你需要考慮拿到訊息放在記憶體之後消費者就宕機了怎麼辦。所以我們應該在消費者真正執行完業務邏輯之後，再發送給Broker消費成功，這才是真正的消費了。

所以只要我們在訊息業務邏輯處理完成之後再給Broker

小結一下

可以看出，保證訊息的可靠性需要三方配合。

生產者需要處理好Broker的響應，出錯情況下利用重試、報警等手段。

Broker需要控制響應的時機，單機情況下是訊息刷盤後返回響應，叢集多副本情況下，即傳送至兩個副本及以上的情況下再返回響應。

消費者需要在執行完真正的業務邏輯之後再返回響應給Broker。

但是要注意訊息可靠性增強了，效能就下降了，等待訊息刷盤、多副本同步後返回都會影響效能。因此還是看業務，例如日誌的傳輸可能丟那麼一兩條關係不大，因此沒必要等訊息刷盤再響應。

如何處理重複訊息

我們先來看看能不能避免訊息的重複。

假設我們傳送訊息，就管發，不管Broker

但是一般情況我們是不允許這樣的，這樣訊息就完全不可靠了，我們的基本需求是訊息至少得發到Broker上，那就得等Broker的響應，那麼就可能存在Broker已經寫入了，當時響應由於網路原因生產者沒有收到，然後生產者又重發了一次，此時訊息就重複了。

再看消費者消費的時候，假設我們消費者拿到訊息消費了，業務邏輯已經走完了，事務提交了，此時需要更新Consumer offset了，然後這個消費者掛了，另一個消費者頂上，此時Consumer offset還沒更新，於是又拿到剛才那條訊息，業務又被執行了一遍。於是訊息又重複了。

可以看到正常業務而言訊息重複是不可避免的，因此我們只能從另一個角度來解決重複訊息的問題。

關鍵點就是冪等。既然我們不能防止重複訊息的產生，那麼我們只能在業務上處理重複訊息所帶來的影響。

冪等處理重複訊息

冪等是數學上的概念，我們就理解為同樣的引數多次呼叫同一個介面和呼叫一次產生的結果是一致的。

例如這條 SQLupdate t1 set money = 150 where id = 1 and money = 100;執行多少遍money都是150，這就叫冪等。

因此需要改造業務處理邏輯，使得在重複訊息的情況下也不會影響最終的結果。

可以通過上面我那條 SQL 一樣，做了個前置條件判斷，即money = 100情況，並且直接修改，更通用的是做個version即版本號控制，對比訊息中的版本號和資料庫中的版本號。

或者通過資料庫的約束例如唯一鍵，例如insert into update on duplicate key...。

或者記錄關鍵的key，比如處理訂單這種，記錄訂單ID，假如有重複的訊息過來，先判斷下這個ID是否已經被處理過了，如果沒處理再進行下一步。當然也可以用全域性唯一ID等等。

基本上就這麼幾個套路，真正應用到實際中還是得看具體業務細節。

如何保證訊息的有序性

有序性分：全域性有序和部分有序。

全域性有序

如果要保證訊息的全域性有序，首先只能由一個生產者往Topic傳送訊息，並且一個Topic內部只能有一個佇列（分割槽）。消費者也必須是單執行緒消費這個佇列。這樣的訊息就是全域性有序的！

不過一般情況下我們都不需要全域性有序，即使是同步MySQL Binlog也只需要保證單表訊息有序即可。

部分有序

因此絕大部分的有序需求是部分有序，部分有序我們就可以將Topic內部劃分成我們需要的佇列數，把訊息通過特定的策略發往固定的佇列中，然後每個佇列對應一個單執行緒處理的消費者。這樣即完成了部分有序的需求，又可以通過佇列數量的併發來提高訊息處理效率。

圖中我畫了多個生產者，一個生產者也可以，只要同類訊息發往指定的佇列即可。

如果處理訊息堆積

訊息的堆積往往是因為生產者的生產速度與消費者的消費速度不匹配。有可能是因為訊息消費失敗反覆重試造成的，也有可能就是消費者消費能力弱，漸漸地訊息就積壓了。

因此我們需要先定位消費慢的原因，如果是bug則處理bug，如果是因為本身消費能力較弱，我們可以優化下消費邏輯，比如之前是一條一條訊息消費處理的，這次我們批量處理，比如資料庫的插入，一條一條插和批量插效率是不一樣的。

假如邏輯我們已經都優化了，但還是慢，那就得考慮水平擴容了，增加Topic的佇列數和消費者數量，注意佇列數一定要增加，不然新增加的消費者是沒東西消費的。一個Topic中，一個佇列只會分配給一個消費者。

當然你消費者內部是單執行緒還是多執行緒消費那看具體場景。不過要注意上面提高的訊息丟失的問題，如果你是將接受到的訊息寫入記憶體佇列之後，然後就返回響應給Broker，然後多執行緒向記憶體佇列消費訊息，假設此時消費者宕機了，記憶體佇列裡面還未消費的訊息也就丟了。