當(dāng)MySQL數(shù)據(jù)庫數(shù)據(jù)達(dá)到一定量后，查詢SQL執(zhí)行會(huì)變慢起來，除了建索引、優(yōu)化程序代碼以及SQL語句等常規(guī)手段外，利用經(jīng)典MHA數(shù)據(jù)庫中間件做數(shù)據(jù)庫讀寫分離是一個(gè)不錯(cuò)的選擇。但是在讀寫分離架構(gòu)中會(huì)出現(xiàn)一個(gè)共性問題：SQL讀取延遲。
讀寫實(shí)時(shí)場景
比如在微服務(wù)應(yīng)用端新增一條業(yè)務(wù)數(shù)據(jù)，然后立即讀取，這個(gè)時(shí)候會(huì)遇到讀取不到情況！
為什么呢？
來源網(wǎng)絡(luò)
因?yàn)樵谧x寫分離架構(gòu)中，主節(jié)點(diǎn)負(fù)責(zé)寫入數(shù)據(jù)，同時(shí)mysql利用多線程技術(shù)把數(shù)據(jù)同步到從節(jié)點(diǎn)，從節(jié)點(diǎn)負(fù)責(zé)應(yīng)用端讀取請求。
而Mysql主從數(shù)據(jù)同步數(shù)據(jù)存在同步時(shí)間差，帶來的問題是從節(jié)點(diǎn)同步不到主節(jié)點(diǎn)（Master）數(shù)據(jù)，應(yīng)用端從從節(jié)點(diǎn)（Slave）讀取不到新增的數(shù)據(jù)情況。
解決方案
利用官方HintManager 分片鍵值管理器， 強(qiáng)制路由到主庫查詢
通過調(diào)用hintManager.setMasterRouteOnly() 強(qiáng)制路由到主庫查詢，偽代碼如下：
public ArticleEntity getWithMasterDB(Long id, String wid) {
HintManager hintManager = HintManager.getInstance() ;
hintManager.setMasterRouteOnly();
ArticleEntity article = baseMApper.queryObject(id, wid);
}
通過強(qiáng)制路由到主庫查詢有個(gè)風(fēng)險(xiǎn)，對于更新并實(shí)時(shí)查詢業(yè)務(wù)場景比較多，如果都切到主庫查詢，勢必會(huì)對主庫服務(wù)器性能造成影響，可能還影響主從數(shù)據(jù)同步，所以要根據(jù)實(shí)際業(yè)務(wù)場景評估采用這種方式帶來的服務(wù)器性能問題。
另外，如果業(yè)務(wù)層面可以做妥協(xié)的話，盡量減少這種更新并實(shí)時(shí)查詢方式，一種思路是實(shí)時(shí)更新庫，利用線程異步查詢（例如更新后，睡眠1-2秒再查詢），偽代碼如下：
public class ArticleCacheTask implements Runnable {
@Override
public void run() {
try {
// 控制讀寫分離不同步設(shè)置
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
ArticleEntity articleEntity = articleService.getWithMasterDB(Long.valueOf(id), wid);
}
}
