從RabbitMQ系列（三）：work queue我們學(xué)習(xí)到了使用ack來確保message消息從queue到consumer階段的不會(huì)被丟失寿烟，學(xué)習(xí)到使用durable=true來設(shè)置消息持久化掌呜，以保證消息在queue中還未被消費(fèi)時(shí)稽莉，RabbitMQ Server重啟消息不會(huì)丟失沐序，但這并不是完美的解決方案，因?yàn)閙essage在存儲(chǔ)至disk的這個(gè)過程中仍然需要一小段時(shí)間來完成這個(gè)任務(wù)，倘若在這段時(shí)間內(nèi)Server宕機(jī)矿微，那么消息也會(huì)丟失。
在使用RabbitMQ的時(shí)候，我們可以通過消息持久化操作來解決因?yàn)榉?wù)器的異常奔潰導(dǎo)致的消息丟失坝疼，除此之外我們還會(huì)遇到一個(gè)問題，當(dāng)消息的發(fā)布者在將消息發(fā)送出去之后谆沃，消息到底有沒有正確到達(dá)broker代理服務(wù)器呢钝凶？如果不進(jìn)行特殊配置的話，默認(rèn)情況下發(fā)布操作是不會(huì)返回任何信息給生產(chǎn)者的唁影，也就是默認(rèn)情況下我們的生產(chǎn)者是不知道消息有沒有正確到達(dá)broker的耕陷，如果在消息到達(dá)broker之前已經(jīng)丟失的話，持久化操作也解決不了這個(gè)問題据沈，因?yàn)橄⒏揪蜎]到達(dá)代理服務(wù)器哟沫，怎么進(jìn)行持久化，要解決這個(gè)問題
RabbitMQ為我們提供了兩種方式：
通過AMQP事務(wù)機(jī)制實(shí)現(xiàn)锌介，這也是AMQP協(xié)議層面提供的解決方案嗜诀；
通過將channel設(shè)置成confirm模式來實(shí)現(xiàn)；
TX
對(duì)于一個(gè)channel孔祸，我們?nèi)绻檬聞?wù)機(jī)制保證數(shù)據(jù)的一致性隆敢，則需要將channel設(shè)置成transaction模式，函數(shù)Channel.Tx()崔慧，Channel.TxCommit()用于提交事務(wù)拂蝎，Channel.TxRollback()用于回滾事務(wù)。在事務(wù)開啟時(shí)候惶室，我們便可以發(fā)布消息給broker代理服務(wù)器温自，如果TxCommit()提交成功，則message一定到達(dá)了broker拇涤；如果TxCommit()執(zhí)行時(shí)返回一個(gè)錯(cuò)誤捣作，即broker有異常。這時(shí)候就可以用TxRollback()回滾事務(wù)鹅士。
在接下里的例子中券躁，我們會(huì)將本節(jié)內(nèi)容與RabbitMQ系列（三）：work queue中的消息持久化和消息ack確認(rèn)機(jī)制共同使用，以保證消息在通過RabbitMQ的過程中不會(huì)丟失。
sender.go
聲明一個(gè)queue
將channel置為transaction模式也拜，發(fā)布消息并提交tx
函數(shù)bodyFrom()
receiver.go
聲明同樣的queue（略）
接收消息
由于事務(wù)機(jī)制比沒有事務(wù)多了四個(gè)步驟：
（1）client發(fā)送Tx.Select
（2）broker發(fā)送Tx.Select-Ok(之后publish)
（3）client發(fā)送Tx.Commit
（4）broker發(fā)送Tx.Commit-Ok
所以這里是有性能損耗的以舒，那么有沒有更好的方法既能保障producer知道消息已經(jīng)正確送到，又能基本上不帶來性能上的損失呢慢哈？從AMQP協(xié)議的層面看是沒有更好的方法蔓钟，但是RabbitMQ提供了一個(gè)更好的方案，即將channel信道設(shè)置成confirm模式卵贱。
confirm
producer端與confirm的實(shí)現(xiàn)原理
生產(chǎn)者將信道設(shè)置成confirm模式滥沫，一旦信道進(jìn)入confirm模式，所有在該信道上面發(fā)布的消息都會(huì)被指派一個(gè)唯一的ID(從1開始)键俱，一旦消息被投遞到所有匹配的隊(duì)列之后兰绣，broker就會(huì)發(fā)送一個(gè)確認(rèn)給生產(chǎn)者（包含消息的唯一ID）,這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊(duì)列了，如果消息和隊(duì)列是可持久化的编振，那么確認(rèn)消息會(huì)將消息寫入磁盤之后發(fā)出缀辩，broker回傳給生產(chǎn)者的確認(rèn)消息中deliver-tag域包含了確認(rèn)消息的序列號(hào)，此外broker也可以設(shè)置basic.ack的multiple域踪央，表示到這個(gè)序列號(hào)之前的所有消息都已經(jīng)得到了處理臀玄。
confirm模式最大的好處在于他是異步的，一旦發(fā)布一條消息畅蹂，生產(chǎn)者應(yīng)用程序就可以在等信道返回確認(rèn)的同時(shí)繼續(xù)發(fā)送下一條消息健无，當(dāng)消息最終得到確認(rèn)之后，生產(chǎn)者應(yīng)用便可以通過回調(diào)方法來處理該確認(rèn)消息魁莉，如果RabbitMQ因?yàn)樽陨韮?nèi)部錯(cuò)誤導(dǎo)致消息丟失睬涧，就會(huì)發(fā)送一條nack消息，生產(chǎn)者應(yīng)用程序同樣可以在回調(diào)方法中處理該nack消息旗唁。
在channel 被設(shè)置成 confirm 模式之后畦浓，所有被 publish 的后續(xù)消息都將被 confirm（即 ack） 或者被nack一次。但是沒有對(duì)消息被 confirm 的快慢做任何保證检疫，并且同一條消息不會(huì)既被 confirm又被nack讶请。
開啟confirm模式
以confirm模式發(fā)送消息
其他輔助函數(shù)confirmOne()
當(dāng)Channel.Confirm(noWait bool)參數(shù)設(shè)置為false時(shí)，broker會(huì)返回一個(gè)confirm.ok表示同意發(fā)送者將當(dāng)前channel信道設(shè)置為confirm模式屎媳。
其他代碼和transaction模式類似夺溢，只是沒有Channel.TxCommit()和Channel.TxRollback()。
編程模式
對(duì)于固定消息體大小和線程數(shù)烛谊，如果消息持久化风响，生產(chǎn)者confirm(或者采用事務(wù)機(jī)制)，消費(fèi)者ack那么對(duì)性能有很大的影響.
消息持久化的優(yōu)化沒有太好方法丹禀，用更好的物理存儲(chǔ)（SAS, SSD, RAID卡）總會(huì)帶來改善状勤。生產(chǎn)者confirm這一環(huán)節(jié)的優(yōu)化則主要在于客戶端程序的優(yōu)化之上鞋怀。歸納起來，客戶端實(shí)現(xiàn)生產(chǎn)者confirm有三種編程方式：
普通confirm模式：每發(fā)送一條消息后持搜，調(diào)用waitForConfirms()方法密似，等待服務(wù)器端confirm。實(shí)際上是一種串行confirm了葫盼。
批量confirm模式：每發(fā)送一批消息后残腌，調(diào)用waitForConfirms()方法，等待服務(wù)器端confirm贫导。
異步confirm模式：提供一個(gè)回調(diào)方法抛猫，服務(wù)端confirm了一條或者多條消息后Client端會(huì)回調(diào)這個(gè)方法。
從編程實(shí)現(xiàn)的復(fù)雜度上來看：
第1種
普通confirm模式最簡(jiǎn)單脱盲，publish一條消息后邑滨，等待服務(wù)器端confirm,如果服務(wù)端返回false或者超時(shí)時(shí)間內(nèi)未返回，客戶端進(jìn)行消息重傳钱反。
第二種
批量confirm模式稍微復(fù)雜一點(diǎn)，客戶端程序需要定期（每隔多少秒）或者定量（達(dá)到多少條）或者兩則結(jié)合起來publish消息匣距，然后等待服務(wù)器端confirm, 相比普通confirm模式面哥，批量極大提升confirm效率，但是問題在于一旦出現(xiàn)confirm返回false或者超時(shí)的情況時(shí)毅待，客戶端需要將這一批次的消息全部重發(fā)尚卫，這會(huì)帶來明顯的重復(fù)消息數(shù)量，并且尸红，當(dāng)消息經(jīng)常丟失時(shí)吱涉，批量confirm性能應(yīng)該是不升反降的。
第三種
異步confirm模式的編程實(shí)現(xiàn)最復(fù)雜外里，Channel對(duì)象提供的ConfirmListener()回調(diào)方法只包含deliveryTag（當(dāng)前Chanel發(fā)出的消息序號(hào)）怎爵，我們需要自己為每一個(gè)Channel維護(hù)一個(gè)unconfirm的消息序號(hào)集合，每publish一條數(shù)據(jù)盅蝗，集合中元素加1鳖链，每回調(diào)一次handleAck方法，unconfirm集合刪掉相應(yīng)的一條（multiple=false）或多條（multiple=true）記錄墩莫。從程序運(yùn)行效率上看芙委，這個(gè)unconfirm集合最好采用有序集合SortedSet存儲(chǔ)結(jié)構(gòu)。實(shí)際上狂秦，SDK中的waitForConfirms()方法也是通過SortedSet維護(hù)消息序號(hào)的灌侣。
