副本读最终一致性探究及其解决方案

副本一致性是指一个数据在不同地点(数据源)存在多份副本，并且各个数据源的数据一模一样。副本读一致性则是不要求任何时刻它们真的相同，而是在读取请求中表现出一模一样的样子，它是在分布式软件架构中最常见的一种一致性保障需求。

其常见的场景如下：缓存和db之间的副本读一致性，es和mysql之间的副本读一致性，主库和从库的副本读一致性。

其实，在读取请求中表现严格相同的样子也是很难的，基本上业务系统只要求在所有数据大部分时间内表现出副本读一致性，而少部分数据是可以在少部分时间内读不一致的，但这个读不一致必须是可随着时间推移无操作自然恢复，这样，我们目标的完整名称其实是【副本读最终一致性】

下面让我们来探讨【副本读最终一致性】可能的架构模式。

一、阻塞单点读写模式

在这种模式中，我们将读、写请求都打到其中一个数据源上面，这个数据源称为主数据源，而当主数据源中的数据不存在时，所有读写请求便来到了停止状态，直到通过辅数据源中的数据填充主数据源的数据为止，请求才能继续从主数据源进行。

数据同步方式：主数据源和辅数据源之间的数据同步可能是在写请求时同步进行的、读请求触发进行、或者异步批量进行的。

以redis和mysql为例，这种模式即是
读请求
若redis有数据，直接返回
若redis无数据，同步的请求mysql，填充redis后，返回数据
写请求
先写redis，后写mysql

接下来列举场景，验证这种架构模式能否在并发请求下保持【副本读最终一致性】，以及可能产生的问题

1. 不加锁且同步访问
   
   

以数据库主从为例，这种模式即是

1. 主库宕机，发起主库切换，某一从库成为新的主库，主库诞生(相当于数据恢复)，继续提供服务。