kafka rabbitMQ及rocketMQ佇列的訊息可靠性保證分析

2022-05-13 21:49:36

1.訊息丟失

1.生產者傳送失敗

所有訊息佇列都可能發生的問題

生產者傳送訊息後，佇列未成功接收（網路原因或其他）而生產者不知情，訊息丟失
生產者傳送訊息後，佇列接收成功->生產者確認，但訊息並未持久化，佇列崩潰，訊息丟失

針對這類問題，三種訊息佇列都提供了生產者訊息傳送確認的模式，例如將kafka的acks引數設定為大於0，將rabbitMQ的通道設定為confirm模式。而在rocketMQ中會返回訊息傳送狀態碼。其中rabbitMQ和rocketMQ還提供了生產者事務操作。

只有某些訊息佇列才會發生的問題

kafka和rabbitMQ在叢集狀態下當前首領不可用時會進行首領選舉。在kafka中，如果把acks設定為1（只要首領節點收到生產者傳送的訊息即確認傳送成功）時，若當前首領收到的訊息但還未同步至從任一節點就崩潰了，kafka會在還來不及判定的非同步從節點中選舉出首領，這時訊息丟失，解決方式是將acks設定未all，即全部從節點同步成功再確認。而在rabbitMQ中，新加入的映象節點不會同步在此之前的訊息，當老的訊息還未完全消費完，老節點全部崩潰時，新節點被選舉為首領時，會丟失所有未消費的舊訊息（目前好像沒有什麼好的解決方式）。
kafka中，即使及時的將所有未同步訊息的節點成功判定未非同步節點，也要在訊息丟失和系統不可用之間做出權衡，如果不希望訊息丟失，則在首領節點恢復前整個系統不可用，通過引數unclean.leader.election.enable可以設定非同步副本是否能成為首領節點。

rocketMQ叢集環境下，broker主從使用非同步複製模式時，若master節點崩潰且資料無法恢復，會丟失還未同步至從節點的部分訊息，解決方式是使用同步雙寫的方式同步訊息，但會降低吞吐率。

2.消費者消費失敗

與生產者類似，若消費者在消費訊息失敗時未告知訊息佇列，此訊息丟失。kafka，rabbitMQ，rocketMQ都提供了相似的消費成功確認機制來解決這個問題，rabbitMQ通過auto_ack引數設定自動確認或手動確認。

而rocketMQ和kafka通過訊息偏移量來控制資訊消費，rocketMQ在pull模式下需要自己維護偏移量。

3.佇列因為自身體原因丟失資料

這個很好理解，例如rabbitMQ預設將訊息儲存再記憶體中，如果佇列崩潰，訊息自然丟失

2.訊息順序

1.kafka

kafka保證同一分割區內訊息的順序，也就是說，如果要讓某一topic內訊息全部有序，只能為該topic設定一個分割區，這會降低該主題的吞吐量。通常使用訊息的key值將訊息散佈到不同分割區上，以此保證訊息的區域性有序性，但這種區域性有序性的保證僅僅在訊息寫入分割區時是有序的才能保證，例如生產者按順序訊息寫入訊息A，訊息B，訊息A寫入失敗，訊息B寫入成功，生產者重發訊息A且成功，這時候兩個訊息的順序就顛倒了，解決方式是設定max.in.flight.requests.per.connection為1,指定生產者在收到訊息成功傳送的確認之前不允許傳送其他資訊，但這種方式也會嚴重降低吞吐量。

另一個問題是kafka預設的分割區器使用雜湊演演算法將訊息的key值對映到對映的分割區上，如果增加了分割區，key值對映的分割區可能會與之前的不一致。在kafka中，一個分割區只能被一個消費者消費，保證了訊息消費的區域性有序性。

2.rocketMQ

rocketMQ的佇列（Message Queue）與kafka的分割區在概念上相似，所以rocketMQ在訊息有序性的保證上自然也是基於佇列（Message Queue）的，同kafka一樣，如果要讓某一主題內的訊息有序，必須將此主題內的獨寫佇列數量設為1，但和kafka一樣，這種操作會大量降低該主題的吞吐量。

rocketMQ中在傳送訊息時傳入自定義的MessageQueueSelector保證訊息生產的區域性有序性，在消費訊息時push模式下通過MessageListenerOrderly保證順序消費。