Rabbitmq durability

less than 1 minute read

最近從大神那邊看到一篇關於RabbitMQ的討論文,然後跟大神詢問一下,知道RabbitMQ並不是每個message做一次fsync,如果在兩次fsync之間機器掛了,message就丟了。

RabbitMQ提供兩種方式來解決這個問題:

第一種方式方式顧名思義就是模擬RMDB的transaction,只要commit成功就保證message不會丟,缺點是效能很差,所以官方推薦Publisher Confirm

還沒仔細看Publisher Confirm到底怎麼搞,但是看起來像是把確認邏輯做在publisher端, publisher如果沒收到ack就要retry。

做在Client端當然效能會比較好,但同時Client邏輯也變複雜,而且也要考慮如果Clientretry到一半掛掉要怎麼辦?這樣一想,好像可以理解大神說在這種狀況下,他們以前拿MySQL來確保durability的作法。

Updated: