Rabbitmq durability

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

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

• transactional
• Publisher Confirm。

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

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

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