redis缓存与数据库协调读写机制设计

1.读机制：

读机制没有太大的争议点，因为缓存机制的设计，就是为了更快的命中目标数据，所以读机制先天固定好了：先去读取缓存，缓存未命中再去读取数据库。

2.写机制：

写机制其实也没什么争议点，从宏观层面上来看我们设计缓存与外部数据库的协调读写的目的就是为了快速读，为了快速读所以我们需要写缓存，因为不写缓存缓存为空，那就失去了本身的意义。所以我们一切为了快速读数据服务，自然的就围绕读机制来进行写，也就是当且仅当读取缓存未命中才进行写。

3.更新机制：

为了保证当且仅当缓存未命中时才去写对应数据到缓存的原则，所以我们不会去单独的对某一个数据内容进行更新。

为了理解当且仅当读取缓存未命中才进行写的这个原理，我们可以举几个例子来说明：

案例一——写极端案例：

如果某个数据设计前并不知道（或者设计出现失误）这个数据内容只会被写，不会被读，那么此时出现一个极端情况：数据不会按照缓存设计的初衷来进行使用。

我们刚才讲了，缓存的设计初衷（大部分情况），就是为了读，而写是为读来服务的，所以我们理所应当的将设计重心放在读，刚才的极端案例也想表明一件事，我们很难在实际应用中判断一个数据到底是读多还是写多，如果这个数据写多读少，我们对该数据进行重复写就会占用大量的时间与空间，得不偿失。

所以，我们为了避免这样的情况，就设计一个当且仅当读取缓存未命中才进行写，也就是说不会主动去重复写缓存，缓存只会在空的时候被写入，而不会被新的数据覆盖。

为了配合上述原则，同时又不得不对缓存进行更新，所以选择一个更为保守的更新机制：当缓存中有数据需要更新的时候，我们不去更新缓存数据，而是直接修改数据库，并且删除所有的相关缓存。

4.先修改数据库，再删除缓存  还是  先删除缓存，再修改数据库？

先说结论，仅使用这两个方案，面对多线程情况都会出现问题，但是前者的健壮性稍强一些。但是如果使用锁，两者皆可。

4.1假设现在有两个线程分别需要进行读与写操作，初始操作数据为X=0，采用先删除缓存，再修改数据库：

A删除缓存->
B读取缓存,未命中->
B写入缓存，X=10->
A写入数据库，X=20

显然，此时数据库与缓存数据不一致，造成上述的原因为写入数据库的时间较长，未加锁，再写入数据的间隙，被其他线程卡了bug

4.2假设现在有两个线程分别需要进行读与写操作，初始操作数据为X=0，采用先修改数据库，再删除缓存：

我们看一看为什么这个方法健壮性更强一些，我们按照4.1的流程来继续套：

A修改数据库->
B读取缓存，缓存命中X=0->A删除缓存

这个逻辑看上去有问题，但实际上没有太大问题，从宏观层面来看逻辑是有问题的，因为业务A（线程A对应的业务）先执行，业务B后执行，这不符合宏观逻辑。但从微观来看，是没有问题的，因为线程B是在A修改结束前（A此时正在修改数据库，B读取了缓存，此时数据库的信息还未更新，可以看作是原来的数据库，所以可以简单的看作数据库与缓存的信息是吻合的）

所以我们只能说这个情况的健壮性稍强，至少比4.1完全错误强。

那么4.2也会有完全错误的机会：

假设此时的X为空，不管别的原因，反正现在X就是空的：

A查询查询缓存，未命中->
A查询数据库 x = 0->
B修改数据库，X=20->
B删除缓存->A添加缓存X = 0 

错误的原因还是写的速度慢，在B读取数据库

显然此时缓存与数据库的结果不一致，出现一致性原则错误。

显然4.2的条件更加苛刻。