1.Redis 缓存和 MySQL 数据如何实现一致性
-
需求原由javascript
-
缓存和数据库一致性解决方案java
在高并发的业务场景下，数据库大多数状况都是用户并发访问最薄弱的环节。因此，就须要使用redis作一个缓冲操做，让请求先访问到redis，而不是直接访问MySQL等数据库。mysql
读取缓存步骤通常没有什么问题，可是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。redis
不论是先写MySQL数据库，再删除Redis缓存；仍是先删除缓存，再写库，都有可能出现数据不一致的状况。sql
举一个例子：数据库
1.若是删除了缓存Redis，尚未来得及写库MySQL，另外一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。缓存
2.若是先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致状况。架构
由于写和读是并发的，无法保证顺序,就会出现缓存和数据库的数据不一致的问题。并发
如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。框架
缓存和数据库一致性解决方案
1.第一种方案：采用延时双删策略
在写库先后都进行redis.del(key)操做，而且设定合理的超时时间。
伪代码以下
public void write(String key,Object data){ redis.delKey(key); db.updateData(data); Thread.sleep(500); redis.delKey(key); }
2.具体的步骤就是：
1）先删除缓存
2）再写数据库
3）休眠500毫秒
4）再次删除缓存
那么，这个500毫秒怎么肯定的，具体该休眠多久呢？
须要评估本身的项目的读数据业务逻辑的耗时。这么作的目的，就是确保读请求结束，写请求能够删除读请求形成的缓存脏数据。
固然这种策略还要考虑redis和数据库主从同步的耗时。最后的的写数据的休眠时间：则在读数据业务逻辑的耗时基础上，加几百ms。好比：休眠1秒。
3.设置缓存过时时间
从理论上来讲，给缓存设置过时时间，是保证最终一致性的解决方案。全部的写操做以数据库为准，只要到达缓存过时时间，则后面的读请求天然会从数据库中读取新值而后回填缓存。
4.该方案的弊端
结合双删策略+缓存超时设置，这样最差的状况就是在超时时间内数据存在不一致，并且又增长了写请求的耗时。
第二种方案：异步更新缓存(基于订阅binlog的同步机制)
1.技术总体思路：
MySQL binlog增量订阅消费+消息队列+增量数据更新到redis
1）读Redis：热数据基本都在Redis
2）写MySQL:增删改都是操做MySQL
3）更新Redis数据：MySQ的数据操做binlog，来更新到Redis
2.Redis更新
1）数据操做主要分为两大块：
一个是全量(将所有数据一次写入到redis)
一个是增量（实时更新）
这里说的是增量,指的是mysql的update、insert、delate变动数据。
2）读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。
这样一旦MySQL中产生了新的写入、更新、删除等操做，就能够把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。
其实这种机制，很相似MySQL的主从备份机制，由于MySQL的主备也是经过binlog来实现的数据一致性。
这里能够结合使用canal(阿里的一款开源框架)，经过该框架能够对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。
固然，这里的消息推送工具你也能够采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis。
总结
第一种
- 读的时候，先读缓存，缓存没有的话，读数据库，取出数据后放入缓存，同时返回响应。
- 更新的时候，先删除缓存，在更新数据库。
第二种
- 读的时候，先读缓存，缓存没有的话，读数据库，取出数据后放入缓存，同时返回响应。
- 更新的时候，先更新数据库，再删除缓存。
第二种是Cache Aside Pattern的本来思路，用的比较多，第一种也有在用。为何会形成这两种分歧勒？缘由在于：
第一种方案引入了缓存-数据库双写不一致的问题，即读数据（写缓存）与修改数据（写数据库）并发的状况下，若修改数据数据库事务还没提交，可是已经把缓存从redis中删除，此时来了个读请求，会把旧的数据刷到缓存里面，这样就致使了缓存中的数据直到下一次修改数据库以前确定是与数据库不一致的。
第二种方案引入了另一个问题，在提交事务以后，若更新缓存失败，也会致使缓存数据库不一致。
facebook公司用的是第二种方案，由于在高并发的状况下，第一种方案带来的影响确定比第二种方案要大。由于：
- 第一：致使更新缓存失败的状况几率是很小的，就算发生了，那么问题就大了，比起解决缓存和数据库不一致，更应该增强Redis架构的可用性。
- 第二，高并发状况下第一种状况发生的几率是很高的。、
其实我的以为在没有读写分离的状况下就用第二种方案就够了，引入redis主从架构解决redis可用性就完了，另外，咱们能够为缓存设置过时时间，减少第二种方案极端状况下数据库缓存不一样步形成的影响。
这是否是说第一种方案彻底不能够用勒，也不是，在保证双写串行化的状况下，咱们也可以使用第一种方案，但这种方式会牺牲必定的性能，如经过内存队列的形式。好比：
读请求没读到缓存就往内存队列丢一个消息，去更新缓存，同时本身开始轮询缓存。针对写请求，也把数据库更新的操做发送到队列里面去。而后后台线程轮询获取内存队列元素，消费信息。用内存队列的方式将更新缓存和删除缓存的操做给串行化起来。这里能够优化的是
- 第一: 后台内存队列能够多个，经过业务IdHash分发到不一样的内存队列当中，只须要保证同一业务id的双写是串行化的就行。
- 第二：为了不无心义的缓存更新消息连续，能够维护一个map，键为产品id，值为一个Boolean值，boolean值标记的是否须要将更新缓存操做推到对队列中（当消费删缓存消息置为ture，当消费写缓存消息置为false）。但这里须要慎重，根据业务量来，若是有100万条数据，这个map的大小会占用到15MB。
另外也能够粗暴的加锁，对读和写加锁串行化，方案实现起来较简单一点。
若是引入了读写分离
可是若是引入了读写分离怎么办勒，因为主从同步延迟，若是采起上面的两种方案，在极端状况下，有可能致使读请求写入缓存中的多是旧数据。这里根据网上的资料纸上谈兵分析一下，若是严格要求这种状况下也要保住缓存数据库一致性的话，只有经过引入阿里的canel组件，实现针对从库binlog日志的消费逻辑，等到从库更新以后再去删除缓存了。总结一下，在读写分离的状况下，直接使用上面的方案二就可。但若是引入了读写分离，能够采用上面所述的根据从库的Binlog日志来异步更新缓存，但没有具体实操，可能代价有点大，若是没有严格要求缓存数据库一致性，我的以为能够不采用，实在不行直接放弃