影音體驗是真的強 簡單聊聊iQOO Pad
大公司的好處就是產品線豐富，非常細分化的東西也能給你做出來，例如早先我們看到了新的vivo Pad2，之后我們又在iQOO Neo8 Pro的發布會上看到了iQOO的首款平板產品iQOO Pad。雖
大家好，我是君哥。
在使用消息隊列時，有兩個經常讓我們煩惱的問題，消息丟失和消息重復。那我們在做技術選型時，有沒有一個消息隊列能解決消息丟失和消息重復這兩個問題呢？
如上圖，從生產者發送消息，Broker 保存消息，消費者消費消息，每一個環節都有可能丟失消息。
生產者發送消息時，如果處理不當，很可能會造成消息丟失。
生產者發送消息，主流消息隊列都支持同步發送和異步發送。如果使用同步發送，生產者發送消息后，會同步等待 Broker 返回的 ACK，收到 ACK 消息，就認為消息發送成功。如果長時間沒有收到，則會認為消息發送失敗，需要進行重試。
同步發送可以保證消息不丟失，但是會有性能問題，所以多數情況會選擇異步發送。異步發送如何保證消息不丟失呢？主流消息隊列（比如 Kafka 和 RocketMQ）實現方法基本類似，使用回調函數來實現。下面看一下 Kafka 的異步發送代碼：
producer.send(record, new Callback() { public void onCompletion(RecordMetadata metadata, Exception exception) { if (exception != null) { logger.error("發送消息失敗：", exception); } if (metadata != null) { logger.info("消息發送成功"); } }});生產者發送消息成功，也不能保證消息絕對不丟失。因為即使消息發送到 Broker，如果在消費者拉取到消息之前，Broker 宕機了，消息還沒有落盤，也會導致消息丟失。
在存儲階段要保證消息不丟失，可以考慮幾個方面：
采用異步刷盤，如果在消息落盤之前 Broker 宕機了，就會造成消息丟失。而采用同步刷盤，等待消息落盤之后，再給 Sender 返回發送成功，可以從消息發送環節保證消息不丟失。
在 RocketMQ 中，把 flushDiskType 參數配置為 SYNC_FLUSH 就可以開啟同步刷盤。
如果 Broker 集群中只有一個節點，即使消息落盤成功了，Broker 發送故障，在 Broker 恢復以前消費者也會拉取不到消息。而且如果 Broker 磁盤故障不可恢復，消息也會丟失。
采用 Broker 集群可以很好地解決這個問題。見下圖：
在 Broker 集群時，可以等待 2 個以上的節點同步消息完成后再給 Producer 返回成功。這樣即使一個 Broker 掛了，也可以很容易找到替代的 Broker。
消費者保證不丟失消息，需要消費完成后再給 Broker 返回 ACK。在主流的消息隊列中，如果 Broker 收不到 ACK，都會給消費者再次發送這條消息。
有時候為了解決消息積壓的問題，消費者拉取到消息后會直接返回 ACK，然后再異步執行消息處理邏輯。這樣要保證消息不丟失，需要在返回 ACK 之前把消息保存到本地，比如持久化到數據庫，后面可以取數據庫保存的消息進行處理。
消息重復一般有兩個原因，一個是生產者發送消息后沒有收到 ACK，然后進行重復發送，另一個原因是消費者消費完成后 Broker 沒有收到 ACK，導致消息重復推送給消費者。
重復消息會對業務造成影響，比如電商場景中的重復支付、賬務場景中的重復記賬，對業務造成的影響都比較嚴重。
從目前主流的消息隊列來看，并沒有一個消息隊列能解決消息重復消費的問題，只能在消費端做冪等處理。下面提供幾個思路作為參考。
如果消息會落本地數據庫，可以采用消息 ID 作為唯一鍵。如果消息不落數據庫，可以將消息 ID 或者消息中其他唯一能標識消息的屬性作為唯一鍵落業務數據表。
我們也可以將消息 ID 保存 Redis，消費消息前判斷消息 ID 是否已存在。
ValueOperations<String, String> valueOperations = redisTemplate.opsForValue();Boolean result = valueOperations.setIfAbsent(messageId, messageId);if (result) { //消費邏輯;} else { logger.error("這條消息已經消費，跳過，消息ID:{}", messageId);}這里有一個注意點，如果消費失敗了，需要刪除 Redis 中保存的消息 ID。
消息不丟失、不重復是消息隊列的基本要求，但這個基本要求還是很難滿足的。
消息丟失這個要求，主流消息隊列通過消息重試和消息持久化的方式可以滿足。
但消息重試也同時帶來了消息重復的可能性，主流消息隊列在解決重復消息的問題上并沒有現成的方案，對不允許重復消費的場景，需要開發人員在消費端做冪等處理。
本文鏈接：http://m.www897cc.com/showinfo-26-62355-0.html阿里二面：要保證消息不丟失，又不重復，消息隊列怎么選型？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 部署過Vue項目嗎？遇到404如何解決？
下一篇： Android開發之漸變色，你學會了嗎？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號