從一個線上問題分析binlog與內(nèi)部XA事務(wù)提交過程

1. 問題
業(yè)務(wù)上新增一條訂單記錄，用戶接收到BinLake拉取的MySQL從庫數(shù)據(jù)消息后，馬上根據(jù)消息內(nèi)的訂單號去查詢同一個MySQL從庫，發(fā)現(xiàn)有些時候無法查到該條數(shù)據(jù)，等待大約500ms～1000ms后再去查詢數(shù)據(jù)庫，可以查詢到該條數(shù)據(jù)。
注: BinLake為京東商城數(shù)據(jù)庫技術(shù)部自研的一套訂閱和消費(fèi)MySQL數(shù)據(jù)庫binlog的組件，本例所描述的問題是業(yè)務(wù)方希望根據(jù)訂閱的binlog來獲取實(shí)時訂單等業(yè)務(wù)消息。
2. Binlog與內(nèi)部XA
2.1. XA的概念
XA(分布式事務(wù))規(guī)范主要定義了(全局)事務(wù)管理器(TM: Transaction Manager)和(局部)資源管理器(RM: Resource Manager)之間的接口。XA為了實(shí)現(xiàn)分布式事務(wù)，將事務(wù)的提交分成了兩個階段：也就是2PC (tow phase commit)，XA協(xié)議就是通過將事務(wù)的提交分為兩個階段來實(shí)現(xiàn)分布式事務(wù)。
兩階段
1）prepare 階段
事務(wù)管理器向所有涉及到的數(shù)據(jù)庫服務(wù)器發(fā)出prepare"準(zhǔn)備提交"請求，數(shù)據(jù)庫收到請求后執(zhí)行數(shù)據(jù)修改和日志記錄等處理，處理完成后只是把事務(wù)的狀態(tài)改成"可以提交",然后把結(jié)果返回給事務(wù)管理器。即：為prepare階段，TM向RM發(fā)出prepare指令，RM進(jìn)行操作，然后返回成功與否的信息給TM。
2）commit 階段
事務(wù)管理器收到回應(yīng)后進(jìn)入第二階段，如果在第一階段內(nèi)有任何一個數(shù)據(jù)庫的操作發(fā)生了錯誤，或者事務(wù)管理器收不到某個數(shù)據(jù)庫的回應(yīng)，則認(rèn)為事務(wù)失敗，回撤所有數(shù)據(jù)庫的事務(wù)。數(shù)據(jù)庫服務(wù)器收不到第二階段的確認(rèn)提交請求，也會把"可以提交"的事務(wù)回撤。如果第一階段中所有數(shù)據(jù)庫都提交成功，那么事務(wù)管理器向數(shù)據(jù)庫服務(wù)器發(fā)出"確認(rèn)提交"請求，數(shù)據(jù)庫服務(wù)器把事務(wù)的"可以提交"狀態(tài)改為"提交完成"狀態(tài)，然后返回應(yīng)答。即：為事務(wù)提交或者回滾階段，如果TM收到所有RM的成功消息，則TM向RM發(fā)出提交指令；不然則發(fā)出回滾指令。
外部與內(nèi)部XA
MySQL中的XA實(shí)現(xiàn)分為：外部XA和內(nèi)部XA。前者是指我們通常意義上的分布式事務(wù)實(shí)現(xiàn)；后者是指單臺MySQL服務(wù)器中，Server層作為TM(事務(wù)協(xié)調(diào)者，通常由binlog模塊擔(dān)當(dāng))，而服務(wù)器中的多個數(shù)據(jù)庫實(shí)例作為RM，而進(jìn)行的一種分布式事務(wù)，也就是MySQL跨庫事務(wù)；也就是一個事務(wù)涉及到同一條MySQL服務(wù)器中的兩個innodb數(shù)據(jù)庫(目前似乎只有innodb支持XA)。內(nèi)部XA也可以用來保證redo和binlog的一致性問題。
2.2. redo與binlog的一致性問題
我們MySQL為了兼容其它非事務(wù)引擎的復(fù)制，在server層面引入了 binlog, 它可以記錄所有引擎中的修改操作，因而可以對所有的引擎使用復(fù)制功能； 然而這種情況會導(dǎo)致redo log與binlog的一致性問題；MySQL通過內(nèi)部XA機(jī)制解決這種一致性的問題。
第一階段：InnoDB prepare， write/sync redo log；binlog不作任何操作；
第二階段：包含兩步，1> write/sync Binlog； 2> InnoDB commit (commit in memory)；
當(dāng)然在5.6之后引入了組提交的概念，可以在IO性能上進(jìn)行一些提升，但總體的執(zhí)行順序不會改變。
當(dāng)?shù)诙A段的第1步執(zhí)行完成之后，binlog已經(jīng)寫入，MySQL會認(rèn)為事務(wù)已經(jīng)提交并持久化了(在這一步binlog就已經(jīng)ready并且可以發(fā)送給訂閱者了)。在這個時刻，就算數(shù)據(jù)庫發(fā)生了崩潰，那么重啟MySQL之后依然能正確恢復(fù)該事務(wù)。在這一步之前包含這一步任何操作的失敗都會引起事務(wù)的rollback。
第二階段的第2大部分都是內(nèi)存操作，比如釋放鎖，釋放mvcc相關(guān)的read view等等。MySQL認(rèn)為這一步不會發(fā)生任何錯誤，一旦發(fā)生了錯誤那就是數(shù)據(jù)庫的崩潰，MySQL自身無法處理。這個階段沒有任何導(dǎo)致事務(wù)rollback的邏輯。在程序運(yùn)行層面，只有這一步完成之后，事務(wù)導(dǎo)致變更才能通過API或者客戶端查詢體現(xiàn)出來。
下面的一張圖，說明了MySQL在何時會將binlog發(fā)送給訂閱者。

理論上來說，也可以在commit階段完成之后再將binlog發(fā)送給訂閱者，但這樣會增大主從延遲的風(fēng)險(xiǎn)。
3. 相關(guān)代碼

4. int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit) {
5. .....
6. //進(jìn)入flush stage，
7. change_stage(thd, Stage_manager::FLUSH_STAGE, thd, NULL, &LOCK_log);
8. ....
9. //通知底層存儲引擎日志刷盤
10. process_flush_stage_queue(&total_bytes, &do_rotate, &wait_queue);
11. .....
12. //將各個線程的binlog從cache寫到文件中
13. flush_cache_to_file(&flush_end_pos);
14. ....
15. //進(jìn)入到Sync stage
16. change_stage(thd, Stage_manager::SYNC_STAGE, wait_queue, &LOCK_log,
17. &LOCK_sync));
18. //binlog fsync落盤
19. sync_binlog_file(false)
20. //通知binlog發(fā)送線程，有新的binlog落盤可以發(fā)送到訂閱者了
21. update_binlog_end_pos(tmp_thd->get_trans_pos());
22. //進(jìn)入commit state
23. change_stage(thd, Stage_manager::COMMIT_STAGE, final_queue,
24. leave_mutex_before_commit_stage, &LOCK_commit);
25. ....
26. //事務(wù)狀態(tài)提交
27. process_commit_stage_queue(thd, commit_queue);
28. ....
    }

其中，在update_binlog_end_pos之后，binlog發(fā)送線程就已經(jīng)可以讀取最新的binlog發(fā)送給訂閱者了。當(dāng)訂閱者收到這些binlog之后如果process_commit_stage_queue因?yàn)橄到y(tǒng)調(diào)度等原因還未執(zhí)行完成，那么訂閱者碰巧在此時發(fā)起問題中所描述的查詢，就會發(fā)生查詢不到的情況。
下面我們看一下process_commit_stage_queue都做了什么。
在process_commit_stage_queue會分別調(diào)用到binlog的commit方法binlog_commit和innodb的commit函數(shù)trx_commit_in_memory。

1. static int binlog_commit(handlerton , THD , bool) {
2. DBUG_ENTER("binlog_commit");
3. /*
4. Nothing to do (any more) on commit.
5. */
6. DBUG_RETURN(0);
7. }
   在binlog_commit中什么也不做，因?yàn)楦鷅inlog有關(guān)的操作前面都已經(jīng)做完了。
   最后看一下存儲引擎innodb的trx_commit_in_memory都干了什么。
8. static void trx_commit_in_memory(
9. trx_t trx, /!< in/out: transaction */
10. const mtr_t mtr, /!< in: mini-transaction of
11. trx_write_serialisation_history(), or NULL if
12. the transaction did not modify anything */
13. bool serialised)
14. /*!< in: true if serialisation log was
15. written */
16. {
17. ....
18. //釋放鎖
19. lock_trx_release_locks(trx);
21. ut_ad(trx_state_eq(trx, TRX_STATE_COMMITTED_IN_MEMORY));
23. .....
24. //釋放mvcc相關(guān)的read view
25. if (trx->read_only || trx->rsegs.m_redo.rseg == NULL) {
26. MONITOR_INC(MONITOR_TRX_RO_COMMIT);
27. if (trx->read_view != NULL) {
28. trx_sys->mvcc->view_close(trx->read_view, false);
29. }
31. } else {
32. ut_ad(trx->id > 0);
33. MONITOR_INC(MONITOR_TRX_RW_COMMIT);
34. }
35. }
36. ....
37. //清理insert操作相關(guān)的undo log(注意，此時只有insert的undo需要清理)
38. if (mtr != NULL) {
39. if (trx->rsegs.m_redo.insert_undo != NULL) {
40. trx_undo_insert_cleanup(&trx->rsegs.m_redo, false);
41. }
43. if (trx->rsegs.m_noredo.insert_undo != NULL) {
44. trx_undo_insert_cleanup(&trx->rsegs.m_noredo, true);
45. }
46. }

這一步完成之后，在運(yùn)行時刻事務(wù)的變更才能被查詢到。但需要記住，MySQL在binlog落盤成功后就認(rèn)為事務(wù)的持久化已經(jīng)完成。
30. 總結(jié)
在binlog落盤之后，MySQL就會認(rèn)為事務(wù)的持久化已經(jīng)完成(在這個時刻之后，就算數(shù)據(jù)庫發(fā)生了崩潰都可以在重啟后正確的恢復(fù)該事務(wù))。但是該事務(wù)產(chǎn)生的數(shù)據(jù)變更被別的客戶端查詢出來還需要在commit全部完成之后。MySQL會在binlog落盤之后會立即將新增的binlog發(fā)送給訂閱者以盡可能的降低主從延遲。但由于多線程時序等原因，當(dāng)訂閱者在收到該binlog之后立即發(fā)起一個查詢操作，可能不會查詢到任何該事務(wù)產(chǎn)生的數(shù)據(jù)變更(因?yàn)榇藭r該事務(wù)所處線程可能尚未完成最后的commit步驟)。
如果應(yīng)用需要根據(jù)binlog作為一些業(yè)務(wù)邏輯的觸發(fā)點(diǎn)，還是需要考慮引入一些延時重試機(jī)制或者重新考慮合適的實(shí)現(xiàn)架構(gòu)。

本文由京東商城數(shù)據(jù)庫技術(shù)部王治提供。