無意中看到2012華東架構師大會主頁（http://atcc.mysqlops.com/#video_show），PS：現在架構師大會好多！
在里面看了mysql異步延遲解決方案的PPT，對於提出的解決方案有些共鳴，分享下
mysql 主從同步的目的應該有很多，有的是為了備份，有的是為了讀寫分離，看具體需求。
但主從機制是一樣的：
mysql主從的實現是，mysql master被使用后，其中master后台IO線程會寫Binlog;slave有一個Relay Log線程同步binlog日志，同時有另一個Extractor線程會讀取相應的Binlog，在Slave進行相應的同樣的操作。
對於主從正常執行，相應的延遲幾乎是不存在的。但是在高QPS下，主從同步卻出現了比較明顯的延遲情況。在PPT介紹中，當master QPS達到1萬左右時，Slave重做的QPS卻只有2000左右，因此所謂的瓶頸其實是在Binlog日志在slave重做這塊。而此處實現是單線程的，因此改進的方法此處用多線程實現。
PPT中介紹淘寶實現，修改了源碼，對應的機制是Transfer機制：此處通過對Binlog日志重做采用多線程實現，從而提高slave的QPPS，PPT給出的實驗數據按此機制實現后，QPS能達到1萬多。從而解決mysql主從之間高QPS下的數據同步問題。
當然使用此機制對應的mysql相關配制也有一定的要求：
1.Binlog日志格式必須是基於ROW級別的，
2.對應的SQL語句必須對應PK或者uni key。
對於以上兩點，作者解析是基於多線程必須是知道PK或者uni key才能完成相應的多線程重做slave，這樣才能保證SQL語句的執行順序。相對來說，對於第二點很多應用需求還是能滿足。但是對ROW日志格式，對於一些批量修改等應用，采用此日志格式所帶來的DB的IO壓力等應該也是需要考慮的。
畢竟一種新的方案的提出有它的優點也有它的缺點，合適才是最合理的。總的來說此PPT是圍繞此方案的實現在講解，很易懂。
有需要了解的可以去上面網址下載PPT學習！