读写分离技术架构图
由上图来做的情况下:
Sharding-JDBC
核心功能:
提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用。
独立使用读写分离支持SQL透传。
同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库读取，用于保证数据一致性。
基于Hint的强制主库路由。
不支持项:
主库和从库的数据同步。
主库和从库的数据同步延迟导致的数据不一致。
主库双写或多写。
跨主库和从库之间的事务的数据不一致。主从模型中，事务中读写均用主库。
读写分离采用 Sharding-JDBC 来实现; 对于强制读主库采用自定义注解方式实现；
Sharding-JDBC 来实现：
只需要配置数据源，引入jar包
强制读主库 直接写入bop-common 中，直接应用；需要各业务系统开发人员去是被那些地方需要强制读主库；
场景1：写后立即读。在一个请求中，写入数据后，立即数据库中读取数据。
这种读的场景，写入和读取的时间间隔小于1ms，比正常的主从延迟时间更短，解决方案就是强制读主库。
场景2：读后写。这种典型场景就是insertOrUpdate，不存在插入，存在就更新。
如果两个请求的时间间隔小于主从延迟的时间间隔，第二次的请求因为读不到，就会执行insert。当然可以用强制读主库的方式解决问题;
上面2个场景需要找出来：解决方案就是强制读主库。需要各业务系统相关人员识别出来(查询实时性要求高的地方)