springboot based 主从数据源中间件方案

先定几个原则/目标：

原则：

1.必须保证数据逻辑的一致性；

反例：刚写了数据，（因为主从延迟）查询不到；

2.对开发人员透明，对业务代码无侵入性；与单数据源的业务代码调用一致；

反例：对已有业务代码的侵入式改动，显示说明datasource；

3.根据调用场景自动选择主从数据源

场景：涉及写入，读写都在主库进行。只涉及查询，从库查询

反例：

3.1写事务调用从库

3.2非必要的从主库查询

4.给业务开发选择的权利，可以以最低成本的方式显示进行数据源（类别）选择（如annotation等）；

场景：只涉及查询，但是业务需要，必须从主库查询；

5.主从数据源共存，与单数据源方案，可以无缝切换

扩展目标：

6.低成本的数据源切换线程安全

反例：全局悲观锁,同步锁实现

7.支持多个从库/从库HA

8.主数据库不可用，从库自动顶上

9.代码级别上，采用spring boot starter方案

不考虑场景：

sharding 目前不考虑，如果需要，作单独专题展开。

备忘问题：

传播级别：

调用者上下文显示说明MASTER,被调用者显示说明SLAVE; 或反过来，需要一个合理的切换机制/或者不切换；

传播性可以做如下规则：

1.如果外层为master，则内层不管原先级别，都将提升至master级别；

2.级别只升不降

3. 同一个线程，如果不切换主从，同一分类的机器，（主要是指多个slave ）实例也不切换

4.更多的调用层级，直接递推即可（传播）；

case：

• master → slave        =>     master → master
• master → master      =>     master → master
• slave   → master       =>     slave → master
• slave  → slave           =>     slave → slave

Master/Slave 切换场景的几种设定：

	默认Slave（性能优先）	默认Master（开发效率优先）	如果调用者未显示说明@Master/Slave，根据事务状态自主选择主从； 不在传播链中生成@Master/Slave	如果调用者未显示说明@Master/Slave，根据事务状态自主选择主从； 在传播链中生成@Master/Slave
优点	1.分担主库负担 2.尽可能利用从库，从库只读，HA成本低	1.现有代码无任何改动可正常运行	1.用户完全控制，截断了隐性的@Master 2.更多的@Slave场景机会	1.整个传播链行为一致，使得整个数据行为更一致；
缺点	所有现有的服务，涉及到写或者必须连master的场景，必须显示标明@Master； 否则会有两种情况： 1.涉及写入的时候会默认连接到只读从库，程序会报错； 2. 非写入动作，但可能有数据读取的延时性问题	1.需要显示标明@Slave，才能连接从库 2.从库利用率会较低	1.有可能业务逻辑的不一致； 例子： a.不标明@Master/Slave 的调用上下文先执行了 写操作； b.然后调用了@Slave 的读操作服务； a步骤写入的数据，有可能在b操作中读取不出来 这种场景，当然可以通过显示标明调用者为 @Master 来规避；	1.对事务的状态判断，并不能单方面很好的决定是否选择主从，所以一般会选择主库；（TODO:看是否能更好优化） 2.为了程序运行逻辑不出异常的情况下，而大多选择了@Master，那么接下来的级别都会是@Master，@Slave 的场景会非常少，从库利用率会很低

项目地址：

https://github.com/leochowcomtop/db-proxy