面試題
如何保證消息的可靠性傳輸蔗草？或者說(shuō)，如何處理消息丟失的問(wèn)題疆柔？
面試官心理分析
這個(gè)是肯定的咒精，用 MQ 有個(gè)基本原則，就是數(shù)據(jù)不能多一條旷档，也不能少一條模叙，不能多，就是前面說(shuō)的重復(fù)消費(fèi)和冪等性問(wèn)題鞋屈。不能少范咨，就是說(shuō)這數(shù)據(jù)別搞丟了。那這個(gè)問(wèn)題你必須得考慮一下厂庇。
如果說(shuō)你這個(gè)是用 MQ 來(lái)傳遞非常核心的消息渠啊，比如說(shuō)計(jì)費(fèi)、扣費(fèi)的一些消息权旷，那必須確保這個(gè) MQ 傳遞過(guò)程中絕對(duì)不會(huì)把計(jì)費(fèi)消息給弄丟替蛉。
面試題剖析
數(shù)據(jù)的丟失問(wèn)題，可能出現(xiàn)在生產(chǎn)者拄氯、MQ躲查、消費(fèi)者中，咱們從 RabbitMQ 和 Kafka 分別來(lái)分析一下吧坤邪。
RabbitMQ
生產(chǎn)者弄丟了數(shù)據(jù)
生產(chǎn)者將數(shù)據(jù)發(fā)送到 RabbitMQ 的時(shí)候熙含，可能數(shù)據(jù)就在半路給搞丟了，因?yàn)榫W(wǎng)絡(luò)問(wèn)題啥的艇纺，都有可能怎静。
此時(shí)可以選擇用 RabbitMQ 提供的事務(wù)功能，就是生產(chǎn)者發(fā)送數(shù)據(jù)之前開(kāi)啟 RabbitMQ 事務(wù)channel.txSelect黔衡，然后發(fā)送消息蚓聘，如果消息沒(méi)有成功被 RabbitMQ 接收到，那么生產(chǎn)者會(huì)收到異常報(bào)錯(cuò)盟劫，此時(shí)就可以回滾事務(wù)channel.txRollback夜牡，然后重試發(fā)送消息；如果收到了消息，那么可以提交事務(wù)channel.txCommit塘装。
// 開(kāi)啟事務(wù)
channel.txSelect
try {
// 這里發(fā)送消息
} catch (Exception e) {
channel.txRollback
// 這里再次重發(fā)這條消息
}
// 提交事務(wù)
channel.txCommit
但是問(wèn)題是急迂，RabbitMQ 事務(wù)機(jī)制（同步）一搞，基本上吞吐量會(huì)下來(lái)蹦肴，因?yàn)樘男阅?/strong>僚碎。
所以一般來(lái)說(shuō)，如果你要確保說(shuō)寫(xiě) RabbitMQ 的消息別丟阴幌，可以開(kāi)啟confirm模式勺阐，在生產(chǎn)者那里設(shè)置開(kāi)啟confirm模式之后，你每次寫(xiě)的消息都會(huì)分配一個(gè)唯一的 id矛双，然后如果寫(xiě)入了 RabbitMQ 中渊抽，RabbitMQ 會(huì)給你回傳一個(gè)ack消息，告訴你說(shuō)這個(gè)消息 ok 了议忽。如果 RabbitMQ 沒(méi)能處理這個(gè)消息懒闷，會(huì)回調(diào)你一個(gè)nack接口，告訴你這個(gè)消息接收失敗徙瓶，你可以重試毛雇。而且你可以結(jié)合這個(gè)機(jī)制自己在內(nèi)存里維護(hù)每個(gè)消息 id 的狀態(tài)，如果超過(guò)一定時(shí)間還沒(méi)接收到這個(gè)消息的回調(diào)侦镇，那么你可以重發(fā)灵疮。
事務(wù)機(jī)制和cnofirm機(jī)制最大的不同在于，事務(wù)機(jī)制是同步的壳繁，你提交一個(gè)事務(wù)之后會(huì)阻塞在那兒震捣，但是confirm機(jī)制是異步的，你發(fā)送個(gè)消息之后就可以發(fā)送下一個(gè)消息闹炉，然后那個(gè)消息RabbitMQ 接收了之后會(huì)異步回調(diào)你一個(gè)接口通知你這個(gè)消息接收到了蒿赢。
所以一般在生產(chǎn)者這塊避免數(shù)據(jù)丟失，都是用confirm機(jī)制的渣触。
RabbitMQ 弄丟了數(shù)據(jù)
就是 RabbitMQ 自己弄丟了數(shù)據(jù)羡棵，這個(gè)你必須開(kāi)啟 RabbitMQ 的持久化，就是消息寫(xiě)入之后會(huì)持久化到磁盤(pán)嗅钻，哪怕是 RabbitMQ 自己掛了皂冰，恢復(fù)之后會(huì)自動(dòng)讀取之前存儲(chǔ)的數(shù)據(jù)，一般數(shù)據(jù)不會(huì)丟养篓。除非極其罕見(jiàn)的是秃流，RabbitMQ 還沒(méi)持久化，自己就掛了柳弄，可能導(dǎo)致少量數(shù)據(jù)丟失舶胀，但是這個(gè)概率較小。
設(shè)置持久化有兩個(gè)步驟：
- 創(chuàng)建 queue 的時(shí)候?qū)⑵湓O(shè)置為持久化
這樣就可以保證 RabbitMQ 持久化 queue 的元數(shù)據(jù)，但是不會(huì)持久化 queue 里的數(shù)據(jù)嚣伐。 - 第二個(gè)是發(fā)送消息的時(shí)候?qū)⑾⒌?
deliveryMode設(shè)置為 2
就是將消息設(shè)置為持久化的糖赔，此時(shí) RabbitMQ 就會(huì)將消息持久化到磁盤(pán)上去。
必須要同時(shí)設(shè)置這兩個(gè)持久化才行纤控，RabbitMQ 哪怕是掛了挂捻，再次重啟，也會(huì)從磁盤(pán)上重啟恢復(fù) queue船万，恢復(fù)這個(gè) queue 里的數(shù)據(jù)。
持久化可以跟生產(chǎn)者那邊的confirm機(jī)制配合起來(lái)骨田，只有消息被持久化到磁盤(pán)之后耿导，才會(huì)通知生產(chǎn)者ack了，所以哪怕是在持久化到磁盤(pán)之前态贤，RabbitMQ 掛了舱呻，數(shù)據(jù)丟了，生產(chǎn)者收不到ack悠汽，你也是可以自己重發(fā)的箱吕。
注意，哪怕是你給 RabbitMQ 開(kāi)啟了持久化機(jī)制柿冲，也有一種可能茬高，就是這個(gè)消息寫(xiě)到了 RabbitMQ 中，但是還沒(méi)來(lái)得及持久化到磁盤(pán)上假抄，結(jié)果不巧怎栽，此時(shí) RabbitMQ 掛了，就會(huì)導(dǎo)致內(nèi)存里的一點(diǎn)點(diǎn)數(shù)據(jù)丟失宿饱。
消費(fèi)端弄丟了數(shù)據(jù)
RabbitMQ 如果丟失了數(shù)據(jù)熏瞄，主要是因?yàn)槟阆M(fèi)的時(shí)候，剛消費(fèi)到谬以，還沒(méi)處理强饮，結(jié)果進(jìn)程掛了，比如重啟了为黎，那么就尷尬了邮丰，RabbitMQ 認(rèn)為你都消費(fèi)了，這數(shù)據(jù)就丟了碍舍。
這個(gè)時(shí)候得用 RabbitMQ 提供的ack機(jī)制柠座，簡(jiǎn)單來(lái)說(shuō)，就是你關(guān)閉 RabbitMQ 的自動(dòng)ack片橡，可以通過(guò)一個(gè) api 來(lái)調(diào)用就行妈经，然后每次你自己代碼里確保處理完的時(shí)候，再在程序里ack一把。這樣的話(huà)吹泡，如果你還沒(méi)處理完骤星，不就沒(méi)有ack？那 RabbitMQ 就認(rèn)為你還沒(méi)處理完爆哑，這個(gè)時(shí)候 RabbitMQ 會(huì)把這個(gè)消費(fèi)分配給別的 consumer 去處理洞难，消息是不會(huì)丟的。
Kafka
消費(fèi)端弄丟了數(shù)據(jù)
唯一可能導(dǎo)致消費(fèi)者弄丟數(shù)據(jù)的情況揭朝，就是說(shuō)队贱，你消費(fèi)到了這個(gè)消息，然后消費(fèi)者那邊自動(dòng)提交了 offset潭袱，讓 Kafka 以為你已經(jīng)消費(fèi)好了這個(gè)消息柱嫌，但其實(shí)你才剛準(zhǔn)備處理這個(gè)消息，你還沒(méi)處理屯换，你自己就掛了编丘，此時(shí)這條消息就丟咯。
這不是跟 RabbitMQ 差不多嗎彤悔，大家都知道 Kafka 會(huì)自動(dòng)提交 offset嘉抓，那么只要關(guān)閉自動(dòng)提交 offset，在處理完之后自己手動(dòng)提交 offset晕窑，就可以保證數(shù)據(jù)不會(huì)丟抑片。但是此時(shí)確實(shí)還是可能會(huì)有重復(fù)消費(fèi)，比如你剛處理完幕屹，還沒(méi)提交offset蓝丙，結(jié)果自己掛了，此時(shí)肯定會(huì)重復(fù)消費(fèi)一次望拖，自己保證冪等性就好了渺尘。
生產(chǎn)環(huán)境碰到的一個(gè)問(wèn)題，就是說(shuō)我們的 Kafka 消費(fèi)者消費(fèi)到了數(shù)據(jù)之后是寫(xiě)到一個(gè)內(nèi)存的 queue 里先緩沖一下说敏，結(jié)果有的時(shí)候鸥跟，你剛把消息寫(xiě)入內(nèi)存 queue，然后消費(fèi)者會(huì)自動(dòng)提交 offset盔沫。然后此時(shí)我們重啟了系統(tǒng)医咨，就會(huì)導(dǎo)致內(nèi)存 queue 里還沒(méi)來(lái)得及處理的數(shù)據(jù)就丟失了。
Kafka 弄丟了數(shù)據(jù)
這塊比較常見(jiàn)的一個(gè)場(chǎng)景架诞，就是 Kafka 某個(gè) broker 宕機(jī)拟淮，然后重新選舉 partition 的 leader。大家想想谴忧，要是此時(shí)其他的 follower 剛好還有些數(shù)據(jù)沒(méi)有同步很泊，結(jié)果此時(shí) leader 掛了角虫，然后選舉某個(gè) follower 成 leader 之后，不就少了一些數(shù)據(jù)委造？這就丟了一些數(shù)據(jù)啊戳鹅。
生產(chǎn)環(huán)境也遇到過(guò)，我們也是昏兆，之前 Kafka 的 leader 機(jī)器宕機(jī)了枫虏，將 follower 切換為 leader 之后，就會(huì)發(fā)現(xiàn)說(shuō)這個(gè)數(shù)據(jù)就丟了爬虱。
所以此時(shí)一般是要求起碼設(shè)置如下 4 個(gè)參數(shù)：
- 給 topic 設(shè)置
replication.factor參數(shù)：這個(gè)值必須大于 1隶债，要求每個(gè) partition 必須有至少 2 個(gè)副本。 - 在 Kafka 服務(wù)端設(shè)置
min.insync.replicas參數(shù)：這個(gè)值必須大于 1饮潦，這個(gè)是要求一個(gè) leader 至少感知到有至少一個(gè) follower 還跟自己保持聯(lián)系燃异，沒(méi)掉隊(duì)，這樣才能確保 leader 掛了還有一個(gè) follower 吧继蜡。 - 在 producer 端設(shè)置
acks=all：這個(gè)是要求每條數(shù)據(jù)，必須是寫(xiě)入所有 replica 之后逛腿，才能認(rèn)為是寫(xiě)成功了稀并。 - 在 producer 端設(shè)置
retries=MAX（很大很大很大的一個(gè)值，無(wú)限次重試的意思）：這個(gè)是要求一旦寫(xiě)入失敗单默，就無(wú)限重試碘举，卡在這里了。
我們生產(chǎn)環(huán)境就是按照上述要求配置的搁廓，這樣配置之后引颈，至少在 Kafka broker 端就可以保證在 leader 所在 broker 發(fā)生故障，進(jìn)行 leader 切換時(shí)境蜕，數(shù)據(jù)不會(huì)丟失蝙场。
生產(chǎn)者會(huì)不會(huì)弄丟數(shù)據(jù)？
如果按照上述的思路設(shè)置了 acks=all粱年，一定不會(huì)丟售滤，要求是，你的 leader 接收到消息台诗，所有的 follower 都同步到了消息之后完箩，才認(rèn)為本次寫(xiě)成功了。如果沒(méi)滿(mǎn)足這個(gè)條件拉队，生產(chǎn)者會(huì)自動(dòng)不斷的重試弊知，重試無(wú)限次。
