1.Redis 缓存和 MySQL 数据如何实现一致性
需求起因
缓存和数据库一致性解决方案
举一个例子：
因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。
如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。
缓存和数据库一致性解决方案
1.第一种方案：采用延时双删策略
在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。
伪代码如下
2.具体的步骤就是：
3.设置缓存过期时间
4.该方案的弊端
第二种方案：异步更新缓存(基于订阅binlog的同步机制)
1.技术整体思路：
MySQL binlog增量订阅消费+消息队列+增量数据更新到redis
2.Redis更新
1）数据操作主要分为两大块：
这里说的是增量,指的是mysql的update、insert、delate变更数据。
2）读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。
这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。
其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。
当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis。
总结
第一种
- 读的时候，先读缓存，缓存没有的话，读数据库，取出数据后放入缓存，同时返回响应。
- 更新的时候，先删除缓存，在更新数据库。
第二种
- 读的时候，先读缓存，缓存没有的话，读数据库，取出数据后放入缓存，同时返回响应。
- 更新的时候，先更新数据库，再删除缓存。
第二种是Cache Aside Pattern的原本思路，用的比较多，第一种也有在用。为什么会造成这两种分歧勒？原因在于：
facebook公司用的是第二种方案，因为在高并发的情况下，第一种方案带来的影响肯定比第二种方案要大。因为：
- 第一：导致更新缓存失败的情况概率是很小的，就算发生了，那么问题就大了，比起解决缓存和数据库不一致，更应该加强Redis架构的可用性。
- 第二，高并发情况下第一种情况发生的概率是很高的。、
其实个人觉得在没有读写分离的情况下就用第二种方案就够了，引入redis主从架构解决redis可用性就完了，另外，我们可以为缓存设置过期时间，减小第二种方案极端情况下数据库缓存不同步造成的影响。
这是不是说第一种方案完全不可以用勒，也不是，在保证双写串行化的情况下，我们也能够使用第一种方案，但这种方式会牺牲一定的性能，如通过内存队列的形式。比如：
读请求没读到缓存就往内存队列丢一个消息，去更新缓存，同时自己开始轮询缓存。针对写请求，也把数据库更新的操作发送到队列里面去。然后后台线程轮询获取内存队列元素，消费信息。用内存队列的方式将更新缓存和删除缓存的操作给串行化起来。这里可以优化的是
- 第一: 后台内存队列可以多个，通过业务IdHash分发到不同的内存队列当中，只需要保证同一业务id的双写是串行化的就行。
- 第二：为了避免无意义的缓存更新消息连续，可以维护一个map，键为产品id，值为一个Boolean值，boolean值标记的是否需要将更新缓存操作推到对队列中（当消费删缓存消息置为ture，当消费写缓存消息置为false）。但这里需要慎重，根据业务量来，如果有100万条数据，这个map的大小会占用到15MB。
另外也可以粗暴的加锁，对读和写加锁串行化，方案实现起来较简单一点。