看京東架構師如何解決，數據庫讀寫分離與事務糾纏的坑

本篇文章討論在數據庫讀寫分離時使用事務的那些坑：

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大型互聯網技術的視頻免費分享給你們