昨天讲了《数据库与缓存一致性问题》，今天讲的是主库和从库的一致性。Q：常见的数据库集群架构是怎样的？一主多从，主从同步，读写分离。如上图所示：(1)一个主库提供写服务；（2）多个从库提供读服务，可以增加从库的读性能；(3)主从之间同步数据；心，加入从库的初衷是为了提高读取性能。问：为什么会出现不一致？主从同步存在延迟。在这个延迟期间，读取从库可能会读取到不一致的数据。如上图所示：(1)服务发起写请求；(2)服务发起读请求，此时同步未完成，读到不一致的脏数据；(3)最后完成数据库主从同步；画外音：任何数据冗余都不可避免地会导致一致性问题。问题：如何避免这种主从延迟造成的不一致？有几种常用的方法。选项一：忽略。任何倒闭的建筑设计都是流氓。百度搜索、淘宝订单、QQ新闻、58贴等大部分业务都允许短期不一致。画外音：如果业务可以接受，最推荐这种方式。如果业务可以接受，就不要把系统架构搞得太复杂。方案二：必读硕士。如上图所示：（1）使用高可用主库提供数据库服务；(2)读写都落在主库上；（3）使用缓存提高系统读取性能；这是一种很常见的微服务架构，可以避免数据库主从一致性问题。选项3：有选择地阅读母版。逼着大师读书，太粗暴了。毕竟写请求的数量很少，短时间内可能会读到脏数据。是不是可以意识到只有这段时间，可能从从库读取脏数据的读请求是从master读取的，但通常是从slave读取的？您可以使用缓存来记录必须从master读取的数据。如上图所示，当发生写请求时：(1)写入主库；(2)将哪个库，哪个表，哪个主键三个信息组装成一个key设置在缓存中，这条记录的超时时间设置为“主从同步延时”；画外音：key的格式为“db:table:PK”，假设主从延迟为1s，则此key的缓存超时时间也为1s。如上图所示，当一个读请求发生时：要读取哪个库，哪个表，哪个主键数据，这三个信息组合成一个键，在缓存中进行查询。如果，(1)缓存key中有这个，说明1s内刚刚发生了写请求，数据库主从同步可能还没有完成，此时应该去主库查询;(2)缓存中没有这个key，说明最近没有发生写请求，现在可以去库中查询；这样就保证读到的一定不是不一致的脏数据。总结一下数据库的主从库不一致，常见的优化方案有几种：（1）业务尚可，系统未优化；（2）master强制读，主库高可用，通过缓存提高读性能；(3)在缓存记录中有哪些记录有写请求，路由master或者slave；文字很短，希望能给你一些启发。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
