您好,登錄后才能下訂單哦!
本篇內容主要講解“ShardingJdbc讀寫分離的BUG坑怎么解決”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“ShardingJdbc讀寫分離的BUG坑怎么解決”吧!
我本地使用了兩個庫來做實驗,寫庫(ds_0_master)和讀庫(ds_0_salve),兩個庫并沒有配置主從,但也不影響實驗操作。
庫里有一個city 表。主庫的 city 表沒有數據,而從庫的 city 表就一條數據。數據內容如下:
我們討論 4 種業務場景:
常規寫完讀
在一個 service 里面調用另一個 service2 進行讀
在一個 service 里面新開一個線程去調用 service2
在一個 service 里面調用 service2,但 service2 是新開的事務
先直接上實驗結果:
@Service public class CityService { @Autowired private CityRepository cityRepository; @Autowired private CityService2 cityService2; @Transactional(rollbackFor = Exception.class) public void test(){ City city=new City(); city.setName("眉山"); city.setProvince("四川"); cityRepository.save(city); List<City> all = cityRepository.findAll(); all.forEach(x->{ System.out.println("cityService:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); } }
打印結果:
實驗分析: 我們對 city 表進行插入后,緊接著對 city 表進行了查詢,查出的內容是我們剛剛插入的內容。說明查詢操作沒有走讀庫,而是走了主庫。
代碼如下:
@Transactional(rollbackFor = Exception.class) public void test(){ City city=new City(); city.setName("眉山"); city.setProvince("四川"); cityRepository.save(city); //調用其他service cityService2.test(); List<City> all = cityRepository.findAll(); all.forEach(x->{ System.out.println("cityService:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); } }
service2 的代碼:
public void test(){ List<City> all = cityRepository.findAll(); all.forEach(x->{ System.err.println("cityService2:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); }
打印結果:
實驗分析:在 service 方法里調用了其他 service,其他 service 也會受到影響。service2 也是走的主庫。
代碼如下:
@Service public class CityService { @Autowired private CityRepository cityRepository; @Autowired private CityService2 cityService2; @Transactional(rollbackFor = Exception.class) public void test(){ City city=new City(); city.setName("眉山"); city.setProvince("四川"); cityRepository.save(city); new Thread(()->{cityService2.test();}).start(); List<City> all = cityRepository.findAll(); all.forEach(x->{ System.out.println("cityService:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); } }
@Service public class CityService2 { @Autowired private CityRepository cityRepository; public void test(){ List<City> all = cityRepository.findAll(); all.forEach(x->{ System.err.println("cityService2:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); } }
打印結果:
實驗分析: 我們新開了線程對 city 表進行查詢,此次查詢讀的是從庫。新開的線程會走從庫,我猜想是新開的線程它認為是沒有寫入/修改操作,所以走了從庫。
我又改動了 service2,加了一段寫入操作。代碼如下:
public void test(){ City city=new City(); city.setName("成都"); city.setProvince("四川"); cityRepository.save(city); List<City> all = cityRepository.findAll(); all.forEach(x->{ System.err.println("cityService2:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); }
再次執行,結果如下:
和預想的不一樣,依舊是走的從庫。
我們調整 service2 的事務傳播行為級別。代碼如下:
@Transactional(propagation = Propagation.REQUIRES_NEW) public void test(){ List<City> all = cityRepository.findAll(); all.forEach(x->{ System.err.println("cityService2:"+((x.getProvince().equals("四川"))?"主庫":"從庫")+":"+x); }); }
REQUIRES_NEW 的含義是:
強制自己開啟一個新的事務,如果一個事務已經存在,那么將這個事務掛起.如 ServiceA.methodA()調用 ServiceB.methodB(),methodB()上的傳播級別是 PROPAGATION_REQUIRES_NEW 的話,那么如果 methodA 報錯,不影響 methodB 的事務,如果 methodB 報錯,那么 methodA 是可以選擇是回滾或者提交的,就看你是否將 methodB 報的錯誤拋出還是 try catch 了.
打印結果:
實驗分析: 這個結果確實是沒想到,service2 新開了個事務走的是主庫,而 service 里面的同一個事務里的寫后讀,反而走了從庫。
實驗總結:
場景 | service | service2 |
---|---|---|
同一個 service 里寫完讀 | 主庫 | 主庫 |
service 里寫完調用另一個 servcie 進行讀操作 | 主庫 | 主庫 |
service 里寫完新開線程調用另一個 servcie 進行讀操作 | 主庫 | 從庫 |
service 里寫完新開一個事務調用另一個 servcie 進行讀操作 | 從庫 | 主庫 |
常規的寫完讀操作和寫完在另一個 service 里進行讀操作,都能夠走到主庫,保證了常規業務的正確性,也滿足了我們一般的使用場景了。而新開線程進行讀操作的情況其實比較少,如果非要使用,我們可以用強制指定主庫的方式進行處理。
最后一種情況,service中調用另一個service2(新開事務),原本 service 里同一個事務的寫完讀操作走到了從庫,一不注意容易引起實際業務bug,需要使用者謹慎使用。
到此,相信大家對“ShardingJdbc讀寫分離的BUG坑怎么解決”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。