摘要：
RabbiMQ宕機會導致消息丟失！ 解決辦法：可以做消息持久化。 非持久化消息：只有非持久化消息在RabbitMQ宕機時會發(fā)生消息丟失。 持久化消息：持久化的消息會在接收后被保存到磁盤中，所以RabbitMQ宕機對持久化消息沒有影響，在重啟時候會重新加載消息到消息隊列中 非持久化消息的性能會高于持久 閱讀全文
posted @ 2021-03-07 23:59
冰紅茶灬
閱讀(1413)
評論(0)
推薦(0)
摘要：
可以采用單線程的消費保證消息的順序性。對消息進行編號，1，2，3，4……消費時按照編號的順序去消費消息。這樣就可以保證消息 按照一定順序執(zhí)行。 閱讀全文
posted @ 2021-03-07 23:57
冰紅茶灬
閱讀(803)
評論(0)
推薦(0)
摘要：
生產(chǎn)者： 原因： 由于網(wǎng)絡原因導致消息發(fā)送失敗，消息隊列沒有接收到生產(chǎn)者發(fā)送的消息，但生產(chǎn)者認為消息發(fā)送成功。 解決辦法： transaction模式：事務模式：開啟事務，發(fā)送消息，成功提交事務，失敗回滾事務。 confirm模式：確認模式，不管成功與否，消息隊列都給生產(chǎn)者一個成功或失敗的回執(zhí)，然后 閱讀全文
posted @ 2021-03-07 23:56
冰紅茶灬
閱讀(262)
評論(0)
推薦(0)
摘要：
為什么會有重復消費？ 做一個標志！ 在將生產(chǎn)者寫消息的時候，對數(shù)據(jù)做一個唯一標識。消費者在消費消息時，根據(jù)這個唯一標識做判斷，如果這個唯一標識被消費過了，那么就 不消費了，如果判斷結果是沒有被消費過，就進行消費。 閱讀全文
posted @ 2021-03-07 23:47
冰紅茶灬
閱讀(293)
評論(0)
推薦(0)
摘要：
網(wǎng)絡問題導致消息隊列沒有接收到確認消息回執(zhí)，消息沒有被刪除，所以存在重復消費! 解決？ 閱讀全文
posted @ 2021-03-07 23:44
冰紅茶灬
閱讀(117)
評論(0)
推薦(0)
摘要：
RabbitMQ有三種模式，其中集群模式有兩種： 單一模式： 單機版的，不做集群，單獨運行一個RabbitMQ。 普通模式集群 默認的集群方式 缺點： 可以帶來一定的效率，但在帶來效率的同時也增加了一些負擔？就是增加了MQ節(jié)點之間的通信，這部分通信也會占用資源，增加時間成本。 所有這種方式并沒有提供 閱讀全文
posted @ 2021-03-07 23:41
冰紅茶灬
閱讀(370)
評論(0)
推薦(0)
摘要：
通過搭建RabbitMQ的集群類提高高可用。 閱讀全文
posted @ 2021-03-07 23:35
冰紅茶灬
閱讀(34)
評論(0)
推薦(0)
摘要：
RabbitMQ的工作模式？（五種） 簡單模式 一個生產(chǎn)者，一個消費者。 生產(chǎn)者生產(chǎn)消息，將消息發(fā)送到消息隊列中，消費者從消息隊列中獲取消息并消費 work模式（資源競爭） 一個生產(chǎn)者，多個消費者 生產(chǎn)者生產(chǎn)消息，將消息發(fā)送到消息隊列中，多個消費者同時爭搶消息，只有搶到的 消費者才能消費消息 訂閱模 閱讀全文
posted @ 2021-03-07 23:33
冰紅茶灬
閱讀(79)
評論(0)
推薦(0)
摘要：
1.降低系統(tǒng)的穩(wěn)定性。 若是RabbitMQ宕機，就無法提供服務了，系統(tǒng)就沒法正常運行了。 2.增加系統(tǒng)的復雜性。 增加了RabbitMQ的代碼，還需要考慮使用RabbitMQ帶來的一些后果： 消息丟失，消息堆積等問題 閱讀全文
posted @ 2021-03-07 23:05
冰紅茶灬
閱讀(700)
評論(0)
推薦(0)
摘要：
原因有三： 1.解耦 2.異步 3.削峰 閱讀全文
posted @ 2021-03-07 17:26
冰紅茶灬
閱讀(582)
評論(0)
推薦(0)
摘要：
是一個開源的，由Erlang公司在1991年推出的消息中間件，底層是由Erlang編寫，基于AMQP協(xié)議 可以解決代碼的解耦，異步，削峰等問題 閱讀全文
posted @ 2021-03-07 17:24
冰紅茶灬
閱讀(67)
評論(0)
推薦(0)
浙公網(wǎng)安備 33010602011771號