小编点评

**日常Bug排查系列中遇到原子性问题的原因：** 1. **主从延迟变种**：当请求B的两条select不在事务内，它们可能会路由到不同的从库。由于两个从库的主从延迟可能不同，这会导致落到不同的库时，导致原子性失效。 2. **多从库不同延迟**：即使请求在同一事务中，多个从库也可能拥有不同的延迟。这也会导致部分请求路由到不同的库，从而导致原子性失效。 3. **线程局部变量**：在第一次请求之后，在threadLocal中打上相关粘性标签（SlaveA）后，后续从库select都走SlaveA即可。由于 threadLocal是单线程的，这会导致某些请求被路由到不同的库，从而导致原子性失效。 4. **数据源选择**：在重载数据源DataSource的getConnection逻辑中，设置了多个数据源，这会导致多个连接同时打开。由于每个连接对应一个从库，这会导致原子性失效。 5. **多数据库连接**：如果数据库配置了多个数据库连接，这也会导致原子性问题。因为每个连接对应一个从库，当多个连接访问同一个表时，可能会出现多个请求在同一时刻路由到不同的库，导致原子性失效。

正文

日常Bug排查系列都是一些简单Bug排查。问题虽小，但经常遇到，了解这些问题，会让我们少走点弯路，提升效率。说不定有些问题你遇到过哦:)

Bug现场

业务开发同学突然问了笔者一个问题，从库读会不会没有原子性？我下意识的反应怎么可能，只要是遵守MySQL主从Replication协议的原子性至少是能够保证的。但他们遇到了一个比较诡异的现象。如下图所示:

 

 

这么一看确实像从库没有保证原子性。但这个明显有违背笔者的常识，这个问题背后肯定还有其它的因素没有挖掘到。

数据库拓扑

于是笔者看了看这个库的拓扑，是一主两从的结构。如下图所示：

 

 

真相大白

看到这个拓扑的那一刻笔者立马反应过来，是踩了一个主从延迟变种的坑。由于请求B的两条select是不在事务内的，而且都是select。这两很有可能路由到两个不同的从库，而这两个从库的主从延迟是不一样的。例如一个100ms，一个200ms。那么落到100ms从库的那条sql就会查到请求A的提交，而200ms从库的那条sql查不到。以致与错误的认为从库不保证原子性！

 

 

应该怎么做

遇到这种情况，其实我们所需要做的只是在某次请求中稳定的路由到某个特定的从库上面，这样就能保证原子性(要么能查到，要么都查不到)。

 

 

如上图所示，一般在第一次请求之后，在threadLocal中打上相关粘性标签(SlaveA)，那么在这次线程请求中。后来的从库select都走SlaveA即可。这个选择逻辑可以通过重载数据源DataSource的getConnection逻辑来实现。

总结

主从延迟是个非常常见的问题。最常见的是主库写入后读从库没有相应的数据，当然也有本文描述的这种看上去”不符合原子性”的变种。看似违背常识的背后可能有其它的隐变量(多从库不同延迟)。多挖掘一点问题现场的上下文信息就很容易揪出问题的根因。