前些天遇到乙個切換資料來源的問題，分析了下給大家分享下
l 【問題】
1. 問題背景
提單資料是分庫儲存的，分庫意味著資料需要根據特定的路由規則路由到不同的庫，
切換資料來源不可避免；
2. 問題描述
優化版本單品單結，使用者訂單不能按照路由規則，儲存到特定的資料庫，而是儲存在預設的資料庫中，持久層**如圖
l 【分析】
1. 提單採用的路由規則很簡單，路由key為使用者pin，根據使用者pin雜湊取模決定資料儲存到特定的資料庫，若不能取得路由key，則儲存到預設的資料庫中。從結果看資料儲存到了預設的資料庫，說明路由策略中沒有取到對應的路由
key。
2. 為了service層與dao層的分離解耦，路由key，是通過theadlocal的方式儲存到執行緒中，實現兩個層的資料傳遞，執行緒內部為序列執行，只需要在dao層呼叫之前確定路由key，dao層便可以根據路由規則，將資料儲存到特定的庫。**也確實是這麼處理的，將使用者
pin設定到了執行緒變數，並且之後呼叫了
dao層的方法，如下圖標識。
3. 問題變的難以琢磨，一切貌似都很正常，但只有優化版本的單品單結業務出現了這樣的問題，商超，外賣，秒殺等平行業務沒有這樣的問題，使用的路由規則和dao層方法也是一樣一樣的，在測試環境下，加入列印日誌驗證
通過日誌對比看出在路由策略執行的時，單品單結沒有取到路由
key，其他業務可以取到路由
key，進一步將問題鎖定在單品單結業務的**上，但然而仍然沒有什麼頭緒……
4. 再次對比**，尋找差異（很反覆的過程），抱著寧可錯殺一千也不放過乙個的態度，最終發現設定路由
key的位置，有所不同，其他業務設定路由key為拿到使用者pin就立即設定，而單品單結是在呼叫dao之前設定路由key，將單品單結的設定路由key的**，盡可能的前置，部署測試，驚奇的發現正確執行，訂單資料可以順利路由到使用者pin對應的資料庫了，改動設定路由key的**位置生效了，距離問題的真正原因又近了一步；繼續變換該段**的位置，不斷測試，最終問題慢慢凸顯出來，在事務內部設定路由
key就會有問題，在事務外部設定路由key則正確執行。事務註解@transactional都做了些什麼呢？
5. 進一步的分析，我們知道無論是註解式的事務，還是宣告式的事務，最終都是事務管理器處理事務，我們這裡使用的是spring預設的datasourcetransactionmanager，
spring註解事務的傳播級別為預設的propagation_required，如果當前沒有事務，就新建乙個事務，如果已經存在乙個事務中，加入到這個事務中，所以一旦開啟就會在同一事務中。
在事務開啟時datasourcetransactionmanager會呼叫dobegin方法，這個方法會獲得該事務使用的資料庫連線，結合場景，由於是第乙個事務標籤所以是新建的事務，所以會通過圖中的this.datasource.getconnection()來獲取資料庫連線。
我們使用的資料來源為下圖動態路由資料來源，該資料來源依賴自定義路由策略
datasource.getconnection()，分為兩步，第一步確定資料來源，第二步獲取已定資料來源的資料庫連線；第一步確定資料來源的過程依賴我們自定義的路由策略。如下圖
我們自定義的資料來源實現了父類的方法，並依賴自定義的路由策略，如圖
大致流程如下圖
也就是說在事務開啟階段，我們已經使用路由規則，選定了資料來源並且獲取了
myibatis
事務也是
spring
管理，也會直接使用該連線）。在開啟事務之前設定路由
key是有效的，而在事務內部設定路由
key已經為時已晚，因為後續的操作會一直使用在事務開啟階段繫結的資料庫連線。
【總結】
1. 資料來源的切換需要在獲取資料庫連線之前，獲取資料庫連線以後，切換資料來源不能起作用。
2. 開啟資料庫事務會提前鎖定資料庫連線，對於確定資料來源的路由key等資料，應該在事務開始之前設定。
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
一次快取效能問題排查
以下分享的都跳過了很多坑，包括redis tomcat環境配置 機器硬體配置等等問題 與線上保持一致，或者硬體效能減配係數，例如線上 8c16g，壓測 4c8g，係數簡單相差2倍 直接把挖掘瓶頸的主要思路搬出檯面。全域性圖預覽 通過對某直播 頁面進行高併發壓測，在apm pinpoint 監控中發現...
一次快取效能問題排查
以下分享的都跳過了很多坑，包括redis tomcat環境配置 機器硬體配置等等問題 與線上保持一致，或者硬體效能減配係數，例如線上 8c16g，壓測 4c8g，係數簡單相差2倍 直接把挖掘瓶頸的主要思路搬出檯面。全域性圖預覽 通過對某直播 頁面進行高併發壓測，在apm pinpoint 監控中發現...