RabbitMQ的transaction、confirm、ack三個概念的解釋，kafka ack

在使用RabbitMQ的過程當中，確定會遇到這樣的幾個概念：transaction、confirm、ack。本文介紹一下這幾個概念，以及他們之間的關係。

RabbitMQ是採用的AMQP協議，AMQP協議定義了」確認」（acknowledgement）,它是從consumer到RabbitMQ的確認，表示一條消息已經被客戶端正確處理。RabbitMQ擴展了AMQP協議，定義了從broker到publisher的」確認」，但將其稱之爲confirm。因此RabbitMQ的確認有2種，叫不一樣的名字，一個consumer acknowledgement，一個叫publisher confirm。

根據AMQP協議規定，consumer acknowledgemenet是經過basic.ack方法實現的，consumer在收到一條消息後，能夠向broker發送basic.ack方法，確認一條消息已經收到。在默認的狀況下，consumer acknowledgement模式是開啓的，若是不想發送basic.ack，能夠在發送basic.consume方法時指定no-ack參數，關閉consumer acknowledgement模式。

Publisher confirm並無在AMQ協議的基礎上添加新的確認方法，而是複用了basic.ack方法。可是publisher confirm模式並非默認打開的，須要調用confirm.select方法將channel設置成confirm模式。當開啓了confirm模式以後，只有當一條消息被全部的mirrors接受以後，publisher纔會收到這條消息的confirm，也就是一個basic.ack方法。

RabbitMQ支持事務(transaction)。事務模式也不是默認開啓的，須要調用tx.select方法開啓事務模式。當開啓了事務模式後，只有當一個事務被全部的mirrors接受以後，tx.commit-ok纔會返回給客戶端。confirm模式和開啓事務模式均可以保證」被全部的mirrors接受」，那麼，開啓confirm模式和開啓事務模式有什麼區別嗎？不一樣點在於confirm是針對一條消息的，而事務是能夠針對多條消息的（固然是針對同一個queue的多條消息）。另外就是，confirm模式只是針對publisher的設置，而事務模式便可以針對publisher，也能夠針對consumer。若是針對publisher設置事務模式，則咱們能夠將多個basic.publish方法放在一個事務中，當全部的publish的消息被全部的mirrors接受後，publisher client會收到tx.commit-ok的方法。若是針對consumer設置事務模式，則咱們能夠將多個basic.ack方法放在一個事務中，收到tx.commit-ok時表示這些消息都被確認了。

kafka 生產者 ack 機制

Producer端配置
一、acks設置爲-1

設置爲0表示producer不須要等待任何確認收到的信息,副本將當即加到socket buffer並認爲已經發送。沒有任何保障能夠保證此種狀況下server已經成功接收數據，同時重試配置不會發生做用（由於客戶端不知道是否失敗）
設置爲1意味着至少要等待leader已經成功將數據寫入本地log，可是並無等待全部follower是否成功寫入。這種狀況下，若是follower沒有成功備份數據，而此時leader又掛掉，則消息會丟失
設置爲-1意味着leader須要等待全部備份都成功寫入日誌，這種策略會保證只要有一個備份存活就不會丟失數據。這是最強的保證。

rabbitmq 生產者 ack 機制
 

 

參考：

http://www.rabbitmq.com/confirms.html

http://www.rabbitmq.com/amqp-0-9-1-reference.html#class.tx

http://www.rabbitmq.com/amqp-0-9-1-reference.html#class.confirm