sharding-jdbc

由于生產(chǎn)或者QA環(huán)境下的數(shù)據(jù)庫(kù)是按主從進(jìn)行部署，在業(yè)務(wù)上默認(rèn)讀操作會(huì)使用從庫(kù)查詢來實(shí)現(xiàn)與主庫(kù)的讀寫分離，提高性能。但是不可避免的是 主從延遲 的存在，此時(shí)就需要我們切換到主庫(kù)進(jìn)行查詢操作，來保證業(yè)務(wù)的正常執(zhí)行。在現(xiàn)有技術(shù)棧背景下，是通過使用sharding-jdbc的主庫(kù)路由切換到主庫(kù)上的。主庫(kù)路由在使用上需要注意下面幾個(gè)點(diǎn):

在進(jìn)行數(shù)據(jù)庫(kù)路由的時(shí)候會(huì)使用到HintManager.getInstance() ，它會(huì)將HintManager實(shí)例放入ThreadLocal中，該ThreadLocal清除的方式有兩種:

• 調(diào)用HintManager.close()手動(dòng)清除
• 由sharding-jdbc自動(dòng)支持，當(dāng)數(shù)據(jù)庫(kù)連接被歸還到連接池后自動(dòng)清除

自動(dòng)清除的方式又可以分為兩種:

• 有事務(wù)，當(dāng)前事務(wù)執(zhí)行結(jié)束之后，會(huì)釋放連接，同時(shí)清除該ThreadLocal
• 沒有事務(wù)，spring-data-jpa的方法 findone等，或者native sql 執(zhí)行完成之后也會(huì)釋放連接，同時(shí)清除ThreadLocal

如果不清除該ThreadLocal會(huì)導(dǎo)致什么后果？

• 當(dāng)下次請(qǐng)求到同一線程的時(shí)候，調(diào)用HintManager.getInstance()發(fā)現(xiàn)ThreadLocal中已經(jīng)有值了，拋出異常
• 等待GC清除ThreadLocal，由于ThreadLocal中在存儲(chǔ)結(jié)構(gòu)實(shí)際上是一個(gè)weakReference，gc發(fā)生會(huì)清除弱引用，但是實(shí)際上存儲(chǔ)的實(shí)例還在，與此同時(shí)這就導(dǎo)致了造成了內(nèi)存泄漏(實(shí)際上不會(huì)有這種情況，因?yàn)镠intManager使用的ThreadLocal是靜態(tài)成員變量)

需要避免下面這種錯(cuò)誤寫法:

void test() {
    HintManager hintManager = HintManager.getInstance();
    hintManager.setMasterRouteOnly();
    // 1.做了一些其它非數(shù)據(jù)庫(kù)的操作，可能會(huì)出現(xiàn)異常(比如查詢r(jià)edis, 數(shù)據(jù)校驗(yàn)等)
    pupuRedissonHash.getMulti();
    // 2.查詢數(shù)據(jù)庫(kù)
    repository.findOne();
}

• 上面這段代碼如果在1中出現(xiàn)了異常，會(huì)導(dǎo)致ThreadLocal沒有被清除，再下次請(qǐng)求用到了同一個(gè)線程(比如dubbo線程)就出現(xiàn)異常
• 上面這段代碼如果能正常的執(zhí)行到2的話，一旦2執(zhí)行結(jié)束后就會(huì)清除ThreadLocal，保證了下次請(qǐng)求使用到相同線程的正常執(zhí)行

在討論過了ThreadLocal清除方式的情況下，可以發(fā)現(xiàn)下述代碼產(chǎn)生的兩種不同情況了:

// 沒有事務(wù)先主庫(kù)路由，再多次查詢
void testNoTransaction() {
    HintManger hintManager = HintManger.getInstance();
    hintManager.setMasterRouteOnly();
    repository.findOne(); // 1. 查詢的是主庫(kù)，同時(shí)清除ThreadLocal
    repository.findOne(); // 2. 查詢的是從庫(kù)，因?yàn)門hreadLocal被清除了
}

// 有事務(wù)先主庫(kù)路由，再多次查詢
@Transactional
void testHasTransaction() {
    HintManger hintManager = HintManger.getInstance();
    hintManager.setMasterRouteOnly();
    repository.findOne(); // 1. 查詢的是主庫(kù)，事務(wù)還沒結(jié)束，不清除ThreadLocal
    repository.findOne(); // 2. 查詢的是主庫(kù)，因?yàn)門hreadLocal還沒被清除
} // 事務(wù)結(jié)束，歸還數(shù)據(jù)庫(kù)連接，清除ThreadLocal

在討論完了自動(dòng)清除的場(chǎng)景，下述代碼表述了手動(dòng)清除ThreadLocal:

// 使用try finally進(jìn)行清除
void testManualClearByTryFinally(DTO dto) {
    HintManger hintManager = HintManger.getInstance();
    hintManager.setMasterRouteOnly();
    try {
      checkDTO(dto);
      redissonHash.getMulti();
      repository.findOne();  
    } finally {
      hintManager.close();
    }
}

// 使用try-with-resource進(jìn)行清除
void testManualClearByTryWithResource(DTO dto) {
    try (HintManager ignored = routeToMaster()) {
      checkDTO(dto);
      redissonHash.getMulti();
      repository.findOne();  
    }
}

HintManager routeToMaster() {
    HintManger hintManager = HintManger.getInstance();
    hintManager.setMasterRouteOnly();
    return hintManager;
}

建議：在使用HintManager.getInstance()后，不確定在此之后執(zhí)行的代碼是否會(huì)出現(xiàn)異常的情況下，使用try finally或者try-with-resource手動(dòng)清除ThreadLocal