本篇文章討論在資料庫讀寫分離時使用事務的那些坑：
1. 在讀寫分離時會不會造成事務主從切換錯誤
一個執行緒在Serivcie時Select時選擇的是從庫，DynamicDataSourceHolder中ThreadLocal對應執行緒儲存的是slave，然後呼叫Manager時進入事務，事務使用預設的transacatinManager關聯的dataSource，而此時會不會獲取到的是slave？
2. 事務隔離級別和傳播特性會不會影響資料連線池死鎖
一個執行緒在Service層Select資料會從資料庫獲取一個Connection，通常來講，後續DB的操作在同一線執行緒會複用這個DB Connection，但是從Service進入Manager的事務後，Get Seq獲取全域性唯一標識，所以Get Seq一般都會開啟新的事物從DB Pool裡重新獲取一個新連線進行操作，但是問題是如果兩個事務關聯的datasource是同一個，即DB Pool是同一個，那麼如果DB Pool已經為空，是否會造成死鎖？
為了減輕資料庫的壓力，一般會進行資料庫的讀寫分離，實現方法一是通過分析sql語句是insert/select/update/delete中的哪一種，從而對應選擇主從，二是通過攔截方法名稱的方式來決定主從的，如：save*()、insert*() 形式的方法使用master庫，select()開頭的使用slave庫。
通常在方法上標上自定義標籤來選擇主從。
或者通過攔截器動態選擇主從。
讀寫動態庫配置
DynamicDataSource：
定義動態資料來源，實現通過整合Spring提供的AbstractRoutingDataSource，只需要實現determineCurrentLookupKey方法即可，由於DynamicDataSource是單例的，執行緒不安全的，所以採用ThreadLocal保證執行緒安全，由DynamicDataSourceHolder完成。
DynamicDataSourceHolder類：
動態設定資料來源可以通過Spring AOP來實現，而AOP切面的方式也有很多種。
Spring AOP的原理：Spring AOP採用動態代理實現，在Spring容器中的bean會被代理物件代替，代理物件里加入了增強邏輯，當呼叫代理物件的方法時，目標物件的方法就會被攔截。
事務切面和讀/寫庫選擇切面
Java邏輯：
使用BeanNameAutoProxyCreator建立代理
Java邏輯：
Spring的事務處理為了與資料訪問解耦，它提供了一套處理資料資源的機制，而這個機制採用ThreadLocal的方式。
事務管理器
Spring中通常通過@Transactional來宣告使用事務。如果@Transactional不指定事務管理器，使用預設。注意如果Spring容器中定義了兩個事務管理器，@Transactional標註是不支援區分使用哪個事務管理器的，Spring 3.0之後的版本Transactional增加了個string型別的value屬性來特殊指定加以區分。
同時進行XML配置
其中dataSource是在Spring配置檔案中定義的資料來源的物件例項。transaction-manager屬性儲存一個對在Spring配置檔案中定義的事務管理器bean的引用，如果沒有它，就會忽略@Transactional註釋，導致程式碼不會使用任何事務。proxy-target-class控制是基於介面的還是基於類的代理被建立，如果屬性值被設定為true，那麼基於類的代理將起作用，如果屬性值為false或者被省略，那麼標準的JDK基於介面的代理將起作用。
注意@Transactional建議在具體的類（或類的方法）上使用，不要使用在類所要實現的任何介面上。
SQL四類隔離級別
事務的實現是基於資料庫的儲存引擎。不同的儲存引擎對事務的支援程度不一樣。Mysql中支援事務的儲存引擎有InnoDB和NDB。InnoDB是mysql預設的儲存引擎，預設的隔離級別是RR（Repeatable Read）。
事務的隔離性是通過鎖實現，而事務的原子性、一致性和永續性則是通過事務日誌實現。
（推薦閱讀：資料庫事務與MySQL事務總結 https://zhuanlan.zhihu.com/p/29166694）
Q1 在讀寫分離時會不會造成事務主從切換錯誤
一個執行緒在Serivcie時Select時選擇的是從庫，DynamicDataSourceHolder中ThreadLocal對應執行緒儲存的是slave，然後呼叫Manager時進入事務，事務使用預設的transacatinManager關聯的dataSource，而此時會不會獲取到的是slave？
經驗證不會，但這是因為在AOP設定動態織出的時候，都要清空DynamicDataSourceHolder的ThreadLocal，如此避免了資料庫事務傳播行為影響的主從切換錯誤。如果Selelct DB從庫完成之後不清空ThreadLocal，那麼ThreadLocal跟執行緒繫結就會傳播到Transaction，造成事務操作從庫異常。而清空ThreadLocal之後，Spring的事務攔截先於動態資料來源的判斷，所以事務會切換成主庫，即使事務中再有查詢從庫的操作，也不會造成主庫事務異常。
Q2 事務隔離級別和傳播特性會不會影響資料連線池死鎖
一個執行緒在Service層Select資料會從資料庫獲取一個Connection，通常來講，後續DB的操作在同一線執行緒會複用這個DB Connection，但是從Service進入Manager的事務後，Get Seq獲取全域性唯一標識，所以Get Seq一般都會開啟新的事物從DB Pool裡重新獲取一個新連線進行操作，但是問題是如果兩個事務關聯的datasource是同一個，即DB Pool是同一個，那麼如果DB Pool已經為空，是否會造成死鎖？
經驗證會死鎖，所以在實踐過程中，如果有此實現，建議Get Seq不要使用與事務同一個連線池。或者採用事務隔離級別設定PROPAGATION_REQUIRES_NEW進行處理。最優的實踐是宎把Get SeqId放到事務裡處理。
總結
分析的不是很深，有很多地方還不是特別瞭解，歡迎吐槽相互學習，尤其是說錯了的地方，一定請幫忙指正，以免誤人子弟。
針對上面的技術我特意整理了一下，有很多技術不是靠幾句話能講清楚，所以乾脆找朋友錄製了一些視訊，很多問題其實答案很簡單，但是背後的思考和邏輯不簡單，要做到知其然還要知其所以然。如果想學習Java工程化、高效能及分散式、深入淺出。微服務、Spring，MyBatis，Netty原始碼分析的朋友可以加我的Java進階群：744642380，群裡有阿里大牛直播講解技術，以及Java大型網際網路技術的視訊免費分享給大家