How We Learned to Stop Worrying and Read from Replicas

本文主旨

如何解决DB异步主从复制引发的写后读一致性问题

主要内容

异步复制引发的写后读一致性问题

写事务包含master和replicas的写
延迟用户的读直至副本追上master
- 从master节点拿到当前数据的复制位置(binlog position)，然后轮训所有的副本看看有没有追上master的副本。如果有，则成功返回，如果一直等到超时都没有的话，此次请求就会失败
这种方式可能引发的问题：
1. 在合理的主从复制中延迟更高（因为当前读的数据可能已经到了slave，但是未到master的复制位置）
2. 如果主从复制过慢，则会持续故障
- 不检测是否是master当前的数据复制位置，转而检测当前读操作所需要数据对应的复制位置是否已经同步到slave了
  - 感觉有两种方案：
    1. 当有特定的更新操作, 记录下 Map<特定数据的更新操作，position>，然后如果后面有读这个特定数据的操作，则根据这个判断position是否复制到了
    2. 每次读请求的时候，判断读取到的数据在Master节点最近的一次更新操作的position，然后判断
1. 在合理的主从复制中延迟降低
2. 在严重的复制延迟时，每次后续重试更有可能成功

总结

思路比较清晰，但是方案二貌似没有具体的实现方案，并且感觉这个实现有一定的复杂度