docker重启mysql数据丢失_mysql如何确保数据不丢失的？我们借鉴这种设计思想实现热点账户高并发
前言
本文篇幅較長，全是干貨，建議親們可以先收藏慢慢看哦
寫文不易，歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支持！
本篇文章我們先來看一下mysql是如何確保數據不丟失的，通過本文我們可以了解mysql內部確保數據不丟失的原理，學習里面優(yōu)秀的設計要點，然后我們再借鑒這些優(yōu)秀的設計要點進行實踐應用，加深理解。
預備知識
mysql確保數據不丟失原理分析
我們來思考一下，下面這條語句的執(zhí)行過程是什么樣的：
start transaction; update t_user set name = '路人甲Java' where user_id = 666; commit;按照正常的思路，通常過程如下：
上面過程可以確保數據被持久化到了磁盤中。
我們將需求改一下，如下：
start transaction; update t_user set name = '路人甲Java' where user_id = 666; update t_user set name = 'javacode2018' where user_id = 888; commit;來看一下處理過程：
上面過程我們看有什么問題
上面問題可以歸納為2點：無法確保數據可靠性、隨機寫導致耗時比較長。
關于上面問題，我們看一下mysql是如何優(yōu)化的，mysql內部引入了一個redo log，這是一個文件，對于上面2條更新操作，mysql實現如下：
mysql內部有個redo log buffer，是內存中一塊區(qū)域，我們將其理解為數組結構，向redo log文件中寫數據時，會先將內容寫入redo log buffer中，后續(xù)會將這個buffer中的內容寫入磁盤中的redo log文件，這個個redo log buffer是整個mysql中所有連接共享的內存區(qū)域，可以被重復使用。
1.start trx=10; 2.寫入rb1 3.寫入rb2 4.end trx=10;
上面過程執(zhí)行完畢之后，數據是這樣的：
認真看一下上面過程中第9步驟，一個成功的事務記錄在redo log中是有start和end的，redo log文件中如果一個trx_id對應start和end成對出現，說明這個事務執(zhí)行成功了，如果只有start沒有end說明是有問題的。
那么對p1、p2頁的修改什么時候會同步到磁盤中呢？
redo log是mysql中所有連接共享的文件，對mysql執(zhí)行insert、delete和上面update的過程類似，都是先在內存中修改頁數據，然后將修改過程持久化到redo log所在的磁盤文件中，然后返回成功。redo log文件是有大小的，需要重復利用的（redo log有多個，多個之間采用環(huán)形結構結合幾個變量來做到重復利用，這塊知識不做說明，有興趣的可以去網上找一下）， 當redo log滿了，或者系統(tǒng)比較閑的時候 ，會對redo log文件中的內容進行處理，處理過程如下：
上面的update之后，p1在內存中是存在的，并且p1是已經被修改過的，可以直接刷新到磁盤中。
如果上面的update之后，mysql宕機，然后重啟了，p1在內存中是不存在的，此時系統(tǒng)會讀取redo log文件中的內容進行恢復處理。
上面的過程做到了：數據最后一定會被持久化到磁盤中的頁中，不會丟失，做到了可靠性。
并且內部采用了先把頁的修改操作先在內存中進行操作，然后再寫入了redo log文件，此處redo log是按順序寫的，使用到了io的順序寫，效率會非常高，相對于用戶來說響應會更快。
對于將數據頁的變更持久化到磁盤中，此處又采用了異步的方式去讀取redo log的內容，然后將頁的變更刷到磁盤中，這塊的設計也非常好，異步刷盤操作！
但是有一種情況，當一個事務commit的時候，剛好發(fā)現redo log不夠了，此時會先停下來處理redo log中的內容，然后在進行后續(xù)的操作，遇到這種情況時，整個事物響應會稍微慢一些。
mysql中還有一個binlog，在事務操作過程中也會寫binlog，先說一下binlog的作用，binlog中詳細記錄了對數據庫做了什么操作，算是對數據庫操作的一個流水，這個流水也是相當重要的，主從同步就是使用binlog來實現的，從庫讀取主庫中binlog的信息，然后在從庫中執(zhí)行，最后，從庫就和主庫信息保持同步一致了。還有一些其他系統(tǒng)也可以使用binlog的功能，比如可以通過binlog來實現bi系統(tǒng)中etl的功能，將業(yè)務數據抽取到數據倉庫， 阿里提供了一個java版本的項目：canal ，這個項目可以模擬從庫從主庫讀取binlog的功能，也就是說可以通過java程序來監(jiān)控數據庫詳細變化的流水，這個大家可以腦洞大開一下，可以做很多事情的，有興趣的朋友可以去研究一下；所以binlog對mysql來說也是相當重要的，我們來看一下系統(tǒng)如何確保redo log 和binlog在一致性的，都寫入成功的。
還是以update為例：
start transaction; update t_user set name = '路人甲Java' where user_id = 666; update t_user set name = 'javacode2018' where user_id = 888; commit;一個事務中可能有很多操作，這些操作會寫很多binlog日志，為了加快寫的速度，mysql先把整個過程中產生的binlog日志先寫到內存中的binlog cache緩存中，后面再將binlog cache中內容一次性持久化到binlog文件中。一個事務的 binlog 是不能被拆開的，因此不論這個事務多大，也要確保一次性寫入。這就涉及到了 binlog cache 的保存問題。系統(tǒng)給 binlog cache 分配了一片內存，每個線程一個，參數 binlog_cache_size 用于控制單個線程內 binlog cache 所占內存的大小。如果超過了這個參數規(guī)定的大小，就要暫存到磁盤。
過程如下：
1.start trx=10;
2.寫入rb1
3.寫入rb2
4.prepare trx=10;注意上面是prepare了，不是之前說的end了。
我們來分析一下上面過程可能出現的一些情況：
步驟10操作完成后，mysql宕機了
宕機之前，所有修改都位于內存中，mysql重啟之后，內存修改還未同步到磁盤，對磁盤數據沒有影響，所以無影響。
步驟12執(zhí)行完畢之后，mysql宕機了
此時redo log prepare過程是寫入redo log文件了，但是binlog寫入失敗了，此時mysql重啟之后會讀取redo log進行恢復處理，查詢到trx_id=10的記錄是prepare狀態(tài)，會去binlog中查找trx_id=10的操作在binlog中是否存在，如果不存在，說明binlog寫入失敗了，此時可以將此操作回滾
步驟13執(zhí)行完畢之后，mysql宕機
此時redo log prepare過程是寫入redo log文件了，但是binlog寫入失敗了，此時mysql重啟之后會讀取redo log進行恢復處理，查詢到trx_id=10的記錄是prepare狀態(tài)，會去binlog中查找trx_id=10的操作在binlog是存在的，然后接著執(zhí)行上面的步驟14和15.
做一個總結
上面的過程設計比較好的地方，有2點
日志先行，io順序寫，異步操作，做到了高效操作
對數據頁，先在內存中修改，然后使用io順序寫的方式持久化到redo log文件；然后異步去處理redo log，將數據頁的修改持久化到磁盤中，效率非常高，整個過程，其實就是 MySQL 里經常說到的 WAL 技術，WAL 的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日志，再寫磁盤。
兩階段提交確保redo log和binlog一致性
為了確保redo log和binlog一致性，此處使用了二階段提交技術，redo log 和binlog的寫分了3步走：
上面3步驟，可以確保同一個trx_id關聯的redo log 和binlog的可靠性。
關于上面2點優(yōu)秀的設計，我們平時開發(fā)的過程中也可以借鑒，下面舉2個常見的案例來學習一下。
案例：電商中資金賬戶高頻變動解決方案
電商中有賬戶表和賬戶流水表，2個表結構如下：
drop table IF EXISTS t_acct; create table t_acct(acct_id int primary key NOT NULL COMMENT '賬戶id',balance decimal(12,2) NOT NULL COMMENT '賬戶余額',version INT NOT NULL DEFAULT 0 COMMENT '版本號，每次更新+1' )COMMENT '賬戶表';drop table IF EXISTS t_acct_data; create table t_acct_data(id int AUTO_INCREMENT PRIMARY KEY COMMENT '編號',acct_id int primary key NOT NULL COMMENT '賬戶id',price DECIMAL(12,2) NOT NULL COMMENT '交易額',open_balance decimal(12,2) NOT NULL COMMENT '期初余額',end_balance decimal(12,2) NOT NULL COMMENT '期末余額' ) COMMENT '賬戶流水表';INSERT INTO t_acct(acct_id, balance, version) VALUES (1,10000,0);上面向賬戶表t_acct插入了一條數據，余額為10000，當我們下單成功或者充值的時候，會對上面2個表進行操作，會修改t_acct的數據，順便向t_acct_data表寫一條流水，這個t_acct_data表有個期初和期末的流水，關系如下：
end_balance = open_balance + price; open_balance為操作業(yè)務時，t_acct表的balance的值。如給賬戶1充值100，過程如下：
t1：開啟事務：start transaction; t2：R1 = (select * from t_acct where acct_id = 1); t3：創(chuàng)建幾個變量v_balance = R1.balance; t4：update t_acct set balnce = v_balance+100,version = version + 1 where acct_id = 1; t5：insert into t_acct_data(acct_id,price,open_balnace,end_balance) values (1,100,#v_balance#,#v_balance+100#) t6：提交事務：commit;分析一下上面過程存在的問題：
我們開啟2個線程【thread1、thread2】模擬分別充值100，正常情況下數據應該是這樣的：
t_acct表記錄： (1,10200,1); t_acct_data表產生2條數據： (1,100,10000,10100); (2,100,10100,10200);但是當2個線程同時執(zhí)行到t2的時候獲取R1記錄信息是一樣的，變量v_balance的值也一樣的，最后執(zhí)行完成之后，數據變成了下面這樣：
t_acct表：1，10200 t_acct_data表產生2條數據： 1,100,10000,10100; 2,100,10100,10100;導致 t_acct_data 產生的2條數據是一樣的，這種情況是有問題的，這就是并發(fā)導致的問題。
上篇文章中有說道樂觀鎖可以解決這種并發(fā)問題，有興趣的可以去看一下，過程如下：
t1：打開事務start transaction t2：R1 = (select * from t_acct where acct_id = 1); t3：創(chuàng)建幾個變量v_version = R1.version;v_balance = R1.balance;v_open_balance = v_balance;v_balance = R1.balance + 100;v_open_balance = v_balance; t3：對R1進行編輯 t4：執(zhí)行更新操作int count = (update t_acct set balance = #v_balance#,version = version + 1 where acct_id = 1 and version = #v_version#); t5：if(count==1){//向t_acct_data表寫入數據insert into t_acct_data(acct_id,price,open_balnace,end_balance) values (1,100,#v_open_balance#,#v_open_balance#)//提交事務commit;}else{//回滾事務rollback;}上面的過程中，如果2個線程同時執(zhí)行到t2看到的R1數據是一樣的，但是最后走到t4的時候會被數據庫加鎖，2個線程的update在mysql中會排隊執(zhí)行，最后只有一個update的結果返回的影響行數是1，然后根據t5，會有一個會被回滾，另外一個被提交，避免了并發(fā)導致的問題。
我們分析一下上面過程會有什么問題？
剛才上面也提到了，并發(fā)量大的時候，只有部分會成功，比如10個線程同時執(zhí)行到t2的時候，其中只有1個會成功，其他9個都會失敗， 并發(fā)量大的情況下失敗的概率比較高 ，這個大家可以并發(fā)測試一下，失敗率很高，下面我們繼續(xù)優(yōu)化。
分析一下問題主要出現在寫t_acct_data上面，如果沒有這個表的操作，我們直接用一個update就完成了操作，速度是非常快的，上面我們學到的了mysql中先寫日志，然后異步刷盤的方式，此處我們也可以采用這種思路，先記錄一條交易日志，然后異步根據交易日志將交易流水寫到 t_acct_data 表中。
那我們繼續(xù)優(yōu)化，新增一個賬戶操作日志表：
drop table IF EXISTS t_acct_log; create table t_acct_log(id INT AUTO_INCREMENT PRIMARY KEY COMMENT '編號',acct_id int primary key NOT NULL COMMENT '賬戶id',price DECIMAL(12,2) NOT NULL COMMENT '交易額',status SMALLINT NOT NULL DEFAULT 0 COMMENT '狀態(tài),0:待處理，1：處理成功' ) COMMENT '賬戶操作日志表';順便對t_acct標做一下改造，新增一個字段 old_balance ，新結構如下：
drop table IF EXISTS t_acct; create table t_acct(acct_id int primary key NOT NULL COMMENT '賬戶id',balance decimal(12,2) NOT NULL COMMENT '賬戶余額',old_balance decimal(12,2) NOT NULL COMMENT '賬戶余額(老的值)',version INT NOT NULL DEFAULT 0 COMMENT '版本號，每次更新+1' )COMMENT '賬戶表';INSERT INTO t_acct(acct_id, balance,old_balance,version) VALUES (1,10000,10000,0);新增了一個old_balance字段，這個字段的值剛開始的時候和balance的值是一致的，后面會在job中進行改變，可以先向下看，后面有解釋
假設賬戶v_acct_id交易金額為v_price，過程如下：
t1.開啟事務：start transaction; t2.insert into t_acct_log(acct_id,price,status) values (#v_acct_id#,#v_price#,0) t3.int count = (update t_acct set balnce = v_balance+#v_price#,version = version+1 where acct_id = #v_acct_id# and v_balance+#v_price#>=0); t6.if(count==1){//提交事務commit;}else{//回滾事務rollback;}可以看到上面沒有記錄流水了，變成插入了一條日志 t_acct_log ，后面我們異步根據 t_acct_log 的數據來生成 t_acct_data 記錄。
上面這個操作支撐并發(fā)操作還是比較高的，測試了一下每秒500筆，并且都成功了，效率非常高。
新增一個job，查詢t_acct_log中狀態(tài)為0的記錄，然后遍歷進行一個個處理，處理過程如下：
假設t_acct_log中當前需要處理的記錄為L1 t1：打開事務start transaction t2：創(chuàng)建變量v_price = L1.price;v_acct_id = L1.acct_id; t3：R1 = (select * from t_acct where acct_id = #v_acct_id#); t4：創(chuàng)建幾個變量v_old_balance = R1.old_balance;v_open_balance = v_old_balance;v_old_balance = R1.old_balance + v_price;v_open_balance = v_old_balance; t5：int count = (update t_acct set old_balance = #v_old_balance#,version = version + 1 where acct_id = #v_acct_id# and version = #v_version#); t6：if(count==1){//更新t_acct_log的status置為1count = (update t_acct_log set status=1 where status=0 and id = #L1.id#);}if(count==1){//提交事務commit;}else{//回滾事務rollback;}上面t5中update條件中加了 version ，t6中的update條件中加了 status=0 的操作，主要是為了防止并發(fā)操作修改可能會出錯的問題。
上面t_acct_log中所有status=0的記錄被處理完畢之后，t_acct表中的balance和old_balance會變?yōu)橐恢隆?/p>
上面這種方式采用了先寫賬戶操作日志，然后異步對日志進行操作，在生成流水，借鑒了mysql中的設計，大家也可以學習學習。
案例2：跨庫轉賬問題
此處我們使用mysql上面介紹的二階段提交來解決。
如從A庫的T1表轉100到B庫的T1表。
我們創(chuàng)建一個C庫，在C庫新增一個轉賬訂單表，如：
drop table IF EXISTS t_transfer_order; create table t_transfer_order(id int NOT NULL AUTO_INCREMENT primary key COMMENT '賬戶id',from_acct_id int NOT NULL COMMENT '轉出方賬戶',to_acct_id int NOT NULL COMMENT '轉入方賬戶',price decimal(12,2) NOT NULL COMMENT '轉賬金額',addtime int COMMENT '入庫時間（秒）',status SMALLINT NOT NULL DEFAULT 0 COMMENT '狀態(tài)，0：待處理，1：轉賬成功，2：轉賬失敗',version INT NOT NULL DEFAULT 0 COMMENT '版本號，每次更新+1' ) COMMENT '轉賬訂單表';A、B庫加3張表，如：
drop table IF EXISTS t_acct; create table t_acct(acct_id int primary key NOT NULL COMMENT '賬戶id',balance decimal(12,2) NOT NULL COMMENT '賬戶余額',version INT NOT NULL DEFAULT 0 COMMENT '版本號，每次更新+1' )COMMENT '賬戶表';drop table IF EXISTS t_order; create table t_order(transfer_order_id int primary key NOT NULL COMMENT '轉賬訂單id',price decimal(12,2) NOT NULL COMMENT '轉賬金額',status SMALLINT NOT NULL DEFAULT 0 COMMENT '狀態(tài)，1：轉賬成功，2：轉賬失敗',version INT NOT NULL DEFAULT 0 COMMENT '版本號，每次更新+1' ) COMMENT '轉賬訂單表';drop table IF EXISTS t_transfer_step_log; create table t_transfer_step_log(id int primary key NOT NULL COMMENT '賬戶id',transfer_order_id int NOT NULL COMMENT '轉賬訂單id',step SMALLINT NOT NULL COMMENT '轉賬步驟，0：正向操作，1：回滾操作',UNIQUE KEY (transfer_order_id,step) ) COMMENT '轉賬步驟日志表';t_transfer_step_log 表用于記錄轉賬日志操作步驟的， transfer_order_id,step 上加了唯一約束，表示每個步驟只能執(zhí)行一次，可以確保步驟的冪等性。
定義幾個變量：
v_from_acct_id:轉出方賬戶 v_to_acct_id:轉入方賬戶 v_price:交易金額整個轉賬流程如下：
每個步驟都有返回值，返回值是數組類型的，含義是：0：處理中（結果未知），1：成功，2：失敗
step1:創(chuàng)建轉賬訂單,訂單狀態(tài)為0，表示處理中 C1：start transaction; C2：insert into t_transfer_order(from_acct_id,to_acct_id,price,addtime,status,version) values(#v_from_acct_id#,#v_to_acct_id#,#v_price#,0,unix_timestamp(now())); C3：獲取剛才insert成功的訂單id，放在變量v_transfer_order_id中 C4：commit;step2:A庫操作如下 A1：AR1 = (select * from t_order where transfer_order_id = #v_transfer_order_id#); A2：if(AR1!=null){return AR1.status==1?1:2;} A3：start transaction; A4：AR2 = (select 1 from t_acct where acct_id = #v_from_acct_id#); A5：if(AR2.balance<v_price){//表示余額不足，那轉賬肯定是失敗了，插入一個轉賬失敗訂單insert into t_order (transfer_order_id,price,status) values (#transfer_order_id#,#v_price#,2);commit;//返回失敗的狀態(tài)2return 2;}else{//通過樂觀鎖 & balance - #v_price# >= 0更新賬戶資金，防止并發(fā)操作int count = (update t_acct set balance = balance - #v_price#, version = version + 1 where acct_id = #v_from_acct_id# and balance - #v_price# >= 0 and version = #AR2.version#);//count為1表示上面的更新成功if(count==1){//插入轉賬成功訂單，狀態(tài)為1insert into t_order (transfer_order_id,price,status) values (#transfer_order_id#,#v_price#,1);//插入步驟日志insert into t_transfer_step_log (transfer_order_id,step) values (#v_transfer_order_id#,1);commit;return 1;}else{//插入轉賬失敗訂單，狀態(tài)為2insert into t_order (transfer_order_id,price,status) values (#transfer_order_id#,#v_price#,2);commit;return 2;}}step3:if(step2的結果==1){//表示A庫中扣款成功了執(zhí)行step4;}else if(step2的結果==2){//表示A庫中扣款失敗了執(zhí)行step6;}step4:對B庫進行操作，如下： B1：BR1 = (select * from t_order where transfer_order_id = #v_transfer_order_id#); B2：if(BR1!=null){return BR1.status==1?1:2; }else{執(zhí)行B3; } B3：start transaction; B4：BR2 = (select 1 from t_acct where acct_id = #v_to_acct_id#); B5：int count = (update t_acct set balance = balance + #v_price#, version = version + 1 where acct_id = #v_to_acct_id# and version = #BR2.version#); if(count==1){//插入訂單，狀態(tài)為1insert into t_order (transfer_order_id,price,status) values (#transfer_order_id#,#v_price#,1);//插入日志insert into t_transfer_step_log (transfer_order_id,step) values (#v_transfer_order_id#,1);commit;return 1; }else{//進入到此處說明有并發(fā)，返回0rollback;return 0; }step5:if(step4的結果==1){//表示B庫中加錢成功了執(zhí)行step7;}step6:對C庫操作（轉賬失敗，將訂單置為失敗） C1：AR1 = (select 1 from t_transfer_order where id = #v_transfer_order_id#); C2：if(AR1.status==1 || AR1.status=2){return AR1.status=1?"轉賬成功":"轉賬失敗";} C3：start transaction; C4：int count = (udpate t_transfer_order set status = 2,version = version+1 where id = #v_transfer_order_id# and version = version + #AR1.version#) C5：if(count==1){commit;return "轉賬失敗";}else{rollback;return "處理中";}step7:對C庫操作（轉賬成功，將訂單置為成功） C1：AR1 = (select 1 from t_transfer_order where id = #v_transfer_order_id#); C2：if(AR1.status==1 || AR1.status=2){return AR1.status=1?"轉賬成功":"轉賬失敗";} C3：start transaction; C4：int count = (udpate t_transfer_order set status = 1,version = version+1 where id = #v_transfer_order_id# and version = version + #AR1.version#) C5：if(count==1){commit;return "轉賬成功";}else{rollback;return "處理中";}還需要新增一個補償的job，處理C庫中狀態(tài)為0的超過10分鐘的轉賬訂單訂單，過程如下：
while(true){List list = select * from t_transfer_order where status = 0 and addtime+10*60<unix_timestamp(now());if(list為空){//插敘無記錄，退出循環(huán)break;}//循環(huán)遍歷list進行處理for(Object r:list){//調用上面的steap2進行處理，最終訂單狀態(tài)會變?yōu)?或者2} }總結
以上是生活随笔為你收集整理的docker重启mysql数据丢失_mysql如何确保数据不丢失的？我们借鉴这种设计思想实现热点账户高并发的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： gridcontrol值为0时设置为空_
- 下一篇： python向mysql中添加数据_通过