读写分离技术架构图

读写分离技术架构图

由上图来做的情况下:

 Sharding-JDBC

核心功能:

        提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用。

        独立使用读写分离支持SQL透传。

        同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库读取，用于保证数据一致性。

        基于Hint的强制主库路由。 

不支持项:

        主库和从库的数据同步。

        主库和从库的数据同步延迟导致的数据不一致。

        主库双写或多写。

        跨主库和从库之间的事务的数据不一致。主从模型中，事务中读写均用主库。

读写分离采用 Sharding-JDBC 来实现; 对于强制读主库采用自定义注解方式实现；

Sharding-JDBC 来实现：

     只需要配置数据源，引入jar包

     强制读主库 直接写入bop-common 中，直接应用；需要各业务系统开发人员去是被那些地方需要强制读主库；

场景1：写后立即读。在一个请求中，写入数据后，立即数据库中读取数据。

        这种读的场景，写入和读取的时间间隔小于1ms，比正常的主从延迟时间更短，解决方案就是强制读主库。

场景2：读后写。这种典型场景就是insertOrUpdate，不存在插入，存在就更新。

        如果两个请求的时间间隔小于主从延迟的时间间隔，第二次的请求因为读不到，就会执行insert。当然可以用强制读主库的方式解决问题;

        上面2个场景需要找出来：解决方案就是强制读主库。需要各业务系统相关人员识别出来(查询实时性要求高的地方)