MySQL並行複製已經是老生常談，筆者從2010年開始就著手處理線上這個問題，剛開始兩三年也樂此不疲分享，現在再提這個話題本來是難免“炒冷飯”嫌疑。
最近觸發再談這個話題，是因為有些同學覺得“5.7的並行複製終於徹底解決了複製併發性問題”, 感覺還是有必要分析一下。大家都說沒有銀彈，但是又期待銀彈。。
既然要說5.7的並行複製，乾脆順手把各個版本的並行複製都說明一下，也好有個對比。便是本次分享的初衷。
【背景】
一句話說完，因為這幾年太多這樣文章了， 就是MySQL一直以來的備庫複製都是單執行緒apply。
【解決基本思路】
改成多執行緒複製。
備庫有兩個執行緒與複製相關：io_thread 負責從主庫拿binlog並寫到relaylog， sql_thread 負責讀relaylog並執行。
多執行緒的思路就是把sql_thread 變成分發執行緒，然後由一組worker_thread來負責執行。
幾乎所有的並行複製都是這個思路，有不同的，便是sql_thread 的分發策略。
而這些策略裡面又分成兩類：利用傳統binlog格式、修改binlog。
使用傳統的binlog格式的幾類，由於binlog裡面的資訊就那些，因此只能按照粒度來分，也就是：按庫、按表、按行
另外有兩個策略是修改了binlog格式的，在binlog裡面增加了別的資訊，用於體現提交分組。
下面我們分別介紹幾個並行複製的實現。
【5.5】
MySQL官方5.5是不支援並行複製的。但是在阿里的業務需要並行複製的年份，還沒有官方版本支援，只好自己實現。而且從相容性角度說，不修改binlog格式，所以採用的是利用傳統binlog格式的改造。
阿里的版本支援兩種分發策略：按表和按行。
前情說明，由於MySQLbinlog日誌還有用於別的系統的要求，因此阿里的binlog格式都是row----這也給並行複製的實現減少了難度。
按表分發策略：row格式的binlog，每個DML前面都是有Table_map event的。因此很容易拿到庫名/表名。一個簡單的思路是，不同表的更新之間是不需要嚴格按照順序的。
因此按照表名hash，hash key是 庫名+表名，相同的表的更新放到同一個worker上。這樣就保證同一個表的更新順序，跟主庫上是一樣的。
應用場景：對於多表更新的場景效果特別好。缺點是反之的，若是熱點表更新，則本策略無效。而且由於hash表的維護，效能反而下降。
按行分發策略：row格式的binlog中，也不難拿到主鍵ID. 有同學說如果沒有主鍵怎麼辦，答案是"起開，現在誰還沒主鍵:)"。好吧，正經答案是沒有主鍵就不支援這個策略。
同樣的，我們認為不同行的更新，可以無序併發的。只要保證同一行的資料更新，在備庫上的順序與主庫上的相同即可。
因此按照主鍵id hash，所以這個hash key更長，必須是 庫名+表名+主鍵id。相同行的更新放到同一個worker上。
需要注意的是，上面的描述看上去都是對單個event的操作，實際上並不能！因為備庫可能接受讀，因此事務的原子性是要保證的，也就是說，對於涉及多個更新操作的事務，每次用於決策的不是一個hash key，而是一組。
應用場景：熱點表更新。缺點，hash key計算衝突的代價大。尤其是大事務，計算hash key的cpu消耗大，而且耗記憶體。這需要業務DBA做判斷得失。
【5.6】
官方的5.6支援的是按庫分發。有了上面的背景，大家就知道，這個feature出來以後，在中國並沒有什麼反響。
但是這個策略也要說也是有優點的：
1、對於可以按表分發的場景，可以通過將表遷到不同的庫，來應用此策略，有可操作性
2、速度更快，因為hash key就一個庫名
3、不要求binlog格式，大家知道不論是row還是statement格式，都是能夠輕鬆獲取庫名的。
所以並不是完全沒有用的。還是習慣問題。
【MariaDB】
MariaDB的並行複製策略看上去有好幾個選項，然而生產上可用的也就是預設值的 CONSERVATIVE。
由於maraiaDB支援多主複製，一個domain_id欄位是用來標示事務來源的。如果來自於不同的主，自然可以並行（這個其實也是通用概念，還得業務DBA自己判斷）。
對於同一個主庫來的binlog，用commit_id 來決定分組。
想法是這樣的：在主庫上同時提交的事務設定成相同的commit_id。在備庫上apply時，相同的commit_id可以並行執行，因為這意味著這些事務之間是沒有行衝突的（否則不可能同時提交）。
這個思路跟最初從單執行緒改成多執行緒一樣，個人認為是劃時代的。
但是也並沒有解決了所有的問題。這個策略最怕的是，拖後腿事務。
設想一下這個場景，假設某個DB裡面正在作大量小更新事務（比如每個事務更新一行），這樣在備庫就並行得很歡樂。
然後突然，在同一個例項，另外一個庫下，或者同一個庫的另外一個跟目前的更新無關的表，突然有一個delte操作刪除了10w行。
delete事務在提交的時候，跟當時一起提交的事務都算同一個commit_id。假設為N.
之後的小事務更新提交組commit_id為N+1。
到備庫apply時，就會發現N這個組裡面，其他小事務都執行完了，執行緒進入空閒狀態，但是不能繼續執行N+1這個commit_id的事務，因為N裡面還有一個大事務沒有執行完成，這個我們認為是拖後腿的。
而基於傳統binlog格式的上面三個策略，反而沒有這個問題。只要是策略上能夠判斷不衝突，大事務自己有個執行緒跑，其他事務繼續並行。
【5.7】
MySQL官方5.7版本也是及時跟進，先引入了上述MariaDB的策略。當然從版權安全上，oracle是不會允許直接port程式碼的。
實際上按組直接分段這個策略略顯粗暴。實際上事務提交併不是一個點，而是一個階段。至少我們可以分成：準備提交、提交中、提交完成。
這三個階段都是在事務已經完成了主要操作邏輯，進入commit狀態了。
同時進入“提交中”狀態的算同一個commit_id. 但是實際上，在任意時刻，處於”準備提交”的事務，與“提交中”的事務，也是可以並行的。但是明顯他們會被分成兩個不同的commit_id。
這意味著這個策略還有提升併發度的空間。
我們來看一下兩種策略的對比差別。
假設主庫有如下面示意圖的事務序列。每個事務提交過程看成兩個階段，prepare ... commit. 分別給不同的編號。其中commit對應的數字是自然數遞增，sequence_no。而prepare是對應的數字是X+1，這個X表示的是當前已經提交完成的sequence_no。
trx1 1…..2
trx2 1………….3
trx3 1…………………….4
trx4 2………………………….5
trx5 3………………………………..6
trx6 3………………………………………………7
trx7 6……………………..8
分析：
在MariaDB的策略裡面，併發執行序列如下：
trx1, trx2, trx3 ----group 1
trx4 -----group 2
trx 5, trx6 ----group 3
trx 7 ----group 4
每個group 執行完成後，下一個group 才可以開始。
完全執行完成的時間是每個group的最大事務時間之和，即 trx3 + trx4+trx6+trx7。
因此，如果某個group裡面有一個很大的事務，則整個序列的執行時間就會被拖久。
再來看5.7的改進策略：
雖然也是group1先啟動，但是在trx1完成後， trx4就可以開始執行；
同樣的，trx7可以在trx4執行完成後就開始執行，與trx5和trx6併發。
因此可以說上面這個例子中，備庫apply過程完全達到了主庫執行的併發度。
但是對於大事務，比如trx2 commit 非常久的情況，仍然存在拖後腿的問題。
【小結】
按粒度區分的三個策略，粒度從粗到細是按庫、按表、按行。
這三個的對比中，並行度越來越大，額外損耗也是。無關大事務不會影響併發度。
按照commit_id 的兩個策略，適用範圍更廣，額外消耗也低。
5.7的改進策略併發性更優。但出現大事務會拖後腿。
另外，很重要的一點，5.7的策略目的是“模擬主庫併發”，所以對於主庫單執行緒更新是無加速作用的。而基於衝突的前三個策略，若滿足併發條件，會出現備庫比主庫執行速度快的情況。這種需求在搭備庫或者延遲複製的場景中可能觸發。
實際上策略的選擇取決於應用場景，這是架構師的工作之一。
PS：具體5.7的實現原理可參考我們團隊的@印風 同學的部落格 http://mysqllover.com/?p=1370 (最後一個例子的case也從此摘錄）