redis缓存同步

以前自己在学校学习redis的时候还真没想到这么多，上班后看公司的项目代码，发现都是先更新DB，然后删除缓存，而且更新DB后不会立马将DB数据放入缓存，然而我以前不管是查询还是update都是操作完DB后立马放入缓存。。。

扯远了，回到重点，为什么先更新DB后删除缓存呢？听我慢慢道来~

提出问题
问题场景：当数据出现变化的时候，DB和redis的一致性就显得非常重要！并发的情况下，主要是看场景，和代价，进行选择。
目前主要有两种策略：

先删除缓存后更新DB（用的少，容易产生大量的脏数据）

结论：容易产生脏数据（以为着在以后不产生更新的情况下，脏数据一直会持续下去）
举例：如上图所示，有两个并发操作分别是更新和查询，第一步更新操作先将redis中的缓存进行删除，接着第二步查询操作并发进来首先寻找redis中有没有缓存，此时因为redis中的数据已经被删除了，第三步只能走DB进行查询，第四步将查询的数据保存到redis当中，此时第五步更新操作属于写操作比较慢才将数据在DB中更新成功。这个时候缓存中的数据就成了旧数据，如果后续不再更新的话，那么这个数据将一直在缓存中存在。(除非设置过期时间）

先更新DB然后删除缓存 （使用场景多）

结论：产生脏数据的概率较小，但是会出现一致性的问题；若更新操作的时候，同时进行查询操作，若hit，则查询得到的数据是旧的数据。但是不会影响后面的查询。（代价较小）
举例：有两个并发操作更新和查询，第一步更新操作进来后先更新DB，第二步查询操作先从缓存中查询，查询的是redis中更新DB后未同步缓存的数据（脏数据）返回，第三步更新操作在DB中操作完之后将redis中的缓存删除，下一轮查询操作就直接走的是DB然后将数据放入缓存，所以脏数据只产生了一次，不会像上面那种情况一直产生脏数据。

该设计模式产生脏数据的可能情况：

一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。

该情况出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

再优化
（1）先淘汰缓存

（2）再写数据库（这两步和原来一样）

（3）休眠1秒，再次淘汰缓存.时长不定1s,根据情况，具体设定。要再提高性能，也可以自己起一个线程，异步删除.

如果怕第二步删除失败，可采用下面方案:
提供一个保障的重试机制即可，这里给出两套方案。
方案一如下图

流程如下所示

（1）更新数据库数据；

（2）缓存因为种种问题删除失败

（3）将需要删除的key发送至消息队列

（4）自己消费消息，获得需要删除的key

（5）继续重试删除操作，直到成功

然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
方案二如下图

流程如下图所示：

（1）更新数据库数据

（2）数据库会将操作信息写入binlog日志当中

（3）订阅程序提取出所需要的数据以及key

（4）另起一段非业务代码，获得该信息

（5）尝试删除缓存操作，发现删除失败

（6）将这些信息发送至消息队列

（7）重新从消息队列中获得该数据，重试操作。

备注说明：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。至于oracle中，博主目前不知道有没有现成中间件可以使用。另外，重试机制，博主是采用的是消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路。