Stepping on the pit, I found a BUG of ShardingJdbc read and write separation

Work together to create and grow together! This is the 33rd day of my participation in the "Nuggets Daily New Plan·August Update Challenge", click to view the details of the event

foreword

Recently, the company is preparing to access ShardingJdbc to separate read and write. The boss asked us to consider whether there is a scenario where data is read immediately after writing, because there is a delay in master-slave synchronization. The library happened to be delayed and the data was not read. Could it not have caused a production accident.

Today, let's take a look at how ShardingJdbc, as a mature framework, handles the scenario of reading data immediately after writing.

Database introduction

I use two libraries locally for experiments, the writing library (ds_0_master) and the reading library (ds_0_salve). The two libraries are not configured with master and slave, but they do not affect the experimental operation.

The library has a city table. The city table of the master library has no data, while the city table of the slave library has one piece of data. The data content is as follows:

We discuss 4 business scenarios:

1. Regular write and read
2. Call another service2 in one service to read
3. Create a new thread in a service to call service2
4. Call service2 in a service, but service2 is a newly opened transaction

First go directly to the experimental results:

1. Regular write and read

@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);
        });
    }
}
复制代码

print result:

Experimental analysis: After inserting the city table, we then query the city table, and the content found is the content we just inserted. It means that the query operation does not go to the walking library, but to the main library.

2. Calling another service in one service

code show as below:

 @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);
        });
    }
}
复制代码

Code for service2:

public void test(){
    List<City> all = cityRepository.findAll();
    all.forEach(x->{
        System.err.println("cityService2:"+((x.getProvince().equals("四川"))?"主库":"从库")+":"+x);
    });
}
复制代码

print result:

Experimental analysis: When other services are called in the service method, other services will also be affected. service2 is also the main library to go.

3. Open a new thread to call service2

code show as below:

@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);
        });
    }
}
复制代码

print result:

实验分析： 我们新开了线程对 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);
        });
    }
复制代码

再次执行，结果如下：

和预想的不一样，依旧是走的从库。

4. service2 新开一个事务执行

我们调整 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 里进行读操作，都能够走到主库，保证了常规业务的正确性，也满足了我们一般的使用场景了。而新开线程进行读操作的情况其实比较少，如果非要使用，我们可以用强制指定主库的方式进行处理。

In the last case, another service2 (newly opened transaction) is called in the service, and the write and read operations of the same transaction in the original service go to the slave library, which can easily lead to actual business bugs and requires users to use it with caution. Do you think this is a bug of ShardingJdbc?