先定几个原则/目标：
原则：
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操作中读取不出来 这种场景，当然可以通过显示标明调用者为 |
1.对事务的状态判断，并不能单方面很好的决定是否选择主从，所以一般会选择主库；（TODO:看是否能更好优化） 2.为了程序运行逻辑不出异常的情况下，而大多选择了@Master，那么接下来的级别都会是@Master，@Slave 的场景会非常少，从库利用率会很低 |
项目地址：
https://github.com/leochowcomtop/db-proxy