前陣子從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統挂掉怎麼辦，這時餘額寶賬戶并沒有增加1萬，資料就會出現不一緻狀況了。
上述場景在各個類型的系統中都能找到相似影子，比如在電商系統中，當有使用者下單後，除了在訂單表插入一條記錄外，對應商品表的這個商品數量必須減1吧，怎麼保證？！在搜尋廣告系統中，當使用者點選某廣告後，除了在點選事件表中增加一條記錄外，還得去商家賬戶表中找到這個商家并扣除廣告費吧，怎麼保證？！等等，相信大家或多或多少都能碰到相似情景。
本質上問題可以抽象為：當一個表資料更新後，怎麼保證另一個表的資料也必須要更新成功。
1、 本地事務
還是以支付寶轉賬餘額寶為例，假設有
支付寶賬戶表：a（id，userid，amount）
餘額寶賬戶表：b（id，userid，amount）
使用者的userid=1；
從支付寶轉賬1萬塊錢到餘額寶的動作分為兩步：
支付寶表扣除1萬：update a set amount=amount-10000 where userid=1;
餘額寶表增加1萬：update b set amount=amount+10000 where userid=1;
如何確定支付寶餘額寶收支平衡呢？
有人說這個很簡單嘛，可以用事務解決。
begin transaction update a set amount=amount-10000 where userid=1; update b set amount=amount+10000 where userid=1; end transaction commit;
非常正确，如果你使用spring的話一個注解就能搞定上述事務功能。
@transactional(rollbackfor=exception.class) public void update() { updateatable(); //更新a表 updatebtable(); //更新b表 }
如果系統規模較小，資料表都在一個資料庫執行個體上，上述本地事務方式可以很好地運作，但是如果系統規模較大，比如支付寶賬戶表和餘額寶賬戶表顯然不會在同一個資料庫執行個體上，他們往往分布在不同的實體節點上，這時本地事務已經失去用武之地。
既然本地事務失效，分布式事務自然就登上舞台。
兩階段送出協定（two-phase commit，2pc）經常被用來實作分布式事務。一般分為協調器c和若幹事務執行者si兩種角色，這裡的事務執行者就是具體的資料庫，協調器可以和事務執行器在一台機器上。
我們的應用程式（client）發起一個開始請求到tc；
tc先将<prepare>消息寫到本地日志，之後向所有的si發起<prepare>消息。以支付寶轉賬到餘額寶為例，tc給a的prepare消息是通知支付寶資料庫相應賬目扣款1萬，tc給b的prepare消息是通知餘額寶資料庫相應賬目增加1w。為什麼在執行任務前需要先寫本地日志，主要是為了故障後恢複用，本地日志起到現實生活中憑證 的效果，如果沒有本地日志（憑證），出問題容易死無對證；
si收到<prepare>消息後，執行具體本機事務，但不會進行commit，如果成功傳回<yes>，不成功傳回<no>。同理，傳回前都應把要傳回的消息寫到日志裡，當作憑證。
tc收集所有執行器傳回的消息，如果所有執行器都傳回yes，那麼給所有執行器發生送commit消息，執行器收到commit後執行本地事務的commit操作；如果有任一個執行器傳回no，那麼給所有執行器發送abort消息，執行器收到abort消息後執行事務abort操作。
注：tc或si把發送或接收到的消息先寫到日志裡，主要是為了故障後恢複用。如某一si從故障中恢複後，先檢查本機的日志，如果已收到<commit >，則送出，如果<abort >則復原。如果是<yes>，則再向tc詢問一下，确定下一步。如果什麼都沒有，則很可能在<prepare>階段si就崩潰了，是以需要復原。
現如今實作基于兩階段送出的分布式事務也沒那麼困難了，如果使用java，那麼可以使用開源軟體atomikos來快速實作。
不過但凡使用過的上述兩階段送出的同學都可以發現性能實在是太差，根本不适合高并發的系統。為什麼？
兩階段送出涉及多次節點間的網絡通信，通信時間太長！
事務時間相對于變長了，鎖定的資源的時間也變長了，造成資源等待時間也增加好多！
正是由于分布式事務存在很嚴重的性能問題，大部分高并發服務都在避免使用，往往通過其他途徑來解決資料一緻性問題。
如果仔細觀察生活的話，生活的很多場景已經給了我們提示。
比如在北京很有名的姚記炒肝點了炒肝并付了錢後，他們并不會直接把你點的炒肝給你，而是給你一張發票，然後讓你拿着發票到出貨區排隊去取。為什麼他們要将付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強（并發量更高）。
還是回到我們的問題，隻要這張發票在，你最終是能拿到炒肝的。同理轉賬服務也是如此，當支付寶賬戶扣除1萬後，我們隻要生成一個憑證（消息）即可，這個憑證（消息）上寫着“讓餘額寶賬戶增加 1萬”，隻要這個憑證（消息）能可靠儲存，我們最終是可以拿着這個憑證（消息）讓餘額寶賬戶增加1萬的，即我們能依靠這個憑證（消息）完成最終一緻性。
有兩種方法：
支付寶在完成扣款的同時，同時記錄消息資料，這個消息資料與業務資料儲存在同一資料庫執行個體裡（消息記錄表表名為message）。
insert into message(userid, amount,status) values(1, 10000, 1);
上述事務能保證隻要支付寶賬戶裡被扣了錢，消息一定能儲存下來。
當上述事務送出成功後，我們通過實時消息服務将此消息通知餘額寶，餘額寶處理成功後發送回複成功消息，支付寶收到回複後删除該條消息資料。
上述儲存消息的方式使得消息資料和業務資料緊耦合在一起，從架構上看不夠優雅，而且容易誘發其他問題。為了解耦，可以采用以下方式。
支付寶在扣款事務送出之前，向實時消息服務請求發送消息，實時消息服務隻記錄消息資料，而不真正發送，隻有消息發送成功後才會送出事務；
當支付寶扣款事務被送出成功後，向實時消息服務确認發送。隻有在得到确認發送指令後，實時消息服務才真正發送該消息；
當支付寶扣款事務送出失敗復原後，向實時消息服務取消發送。在得到取消發送指令後，該消息将不會被發送；
對于那些未确認的消息或者取消的消息，需要有一個消息狀态确認系統定時去支付寶系統查詢這個消息的狀态并進行更新。為什麼需要這一步驟，舉個例子：假設在第2步支付寶扣款事務被成功送出後，系統挂了，此時消息狀态并未被更新為“确認發送”，進而導緻消息不能被發送。
優點：消息資料獨立存儲，降低業務系統與消息系統間的耦合；
缺點：一次消息發送需要兩次請求；業務處理服務需要實作消息狀态回查接口。
還有一個很嚴重的問題就是消息重複投遞，以我們支付寶轉賬到餘額寶為例，如果相同的消息被重複投遞兩次，那麼我們餘額寶賬戶将會增加2萬而不是1萬了。
為什麼相同的消息會被重複投遞？比如餘額寶處理完消息msg後，發送了處理成功的消息給支付寶，正常情況下支付寶應該要删除消息msg，但如果支付寶這時候悲劇的挂了，重新開機後一看消息msg還在，就會繼續發送消息msg。
解決方法很簡單，在餘額寶這邊增加消息應用狀态表（message_apply），通俗來說就是個賬本，用于記錄消息的消費情況，每次來一個消息，在真正執行之前，先去消息應用狀态表中查詢一遍，如果找到說明是重複消息，丢棄即可，如果沒找到才執行，同時插入到消息應用狀态表（同一事務）。
for each msg in queue select count(*) as cnt from message_apply where msg_id=msg.msg_id; if cnt==0 then insert into message_apply(msg_id) values(msg.msg_id);
ebay的研發人員其實在2008年就提出了應用消息狀态确認表來解決消息重複投遞的問題。
阿裡雲的消息服務正好完美解決這類問題
典型适用場景：
隊列類型：紅包活動，高并發訂單，郵件短信發送等，及其各種多業務場景順序（或先後）執行的組合場景 。
訂閱類型：多個應用系統中異步消息1對多通知。
産品技術特點：
基于阿裡雲飛天分布式雲平台。
大規模、高可靠性（10個9）、高并發應用系統支撐。
标準的http restful api接口和豐富的多語言sdk版本。
提供完善的權限控制，安全防護，全鍊路實時監控和報警通知等支援。
7*24小時技術支援服務。
提供vip客戶提供專職服務經理。
支援事務。
主題模式：
<b>隊列模式</b>