1、缓存双写一致性
如果redis中有数据，需要和数据库中的值相同
如果redis中无数据，数据库中的值要是最新值，且准备回写redis
缓存细分
1、只读缓存
2、读写缓存
2.1、同步直写策略
写数据库后也同步写redis缓存，缓存和数据库中的数据一致
对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用同步直写策略
2.2、异步缓写策略
正常业务运行中，mysql数据变动了，但是可以在业务上容许出现一定时间后才作用于redis，必须仓库、物流系统
异常情况出现了，不得不将失败的动作重新修补，有可能需要借助kafka或者RabbitMQ等消息中间件，实现重试重写2、更新策略
给缓存设置过期时间，定期清理缓存并回写，是保证最终一致性的解决方案。
我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。
也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性
切记，要以mysql的数据库写入库为准。
上述方案和后续落地案例是调研后的主流+成熟的做法，但是考虑到各个公司业务系统的差距，
不是100%绝对正确，不保证绝对适配全部情况，请同学们自行酌情选择打法，合适自己的最好。2.1、更新数据库,更新缓存
异常问题：
1 先更新mysql的某商品的库存，当前商品的库存是100，更新为99个。
2 先更新mysql修改为99成功，然后更新redis。
3 此时假设异常出现，更新redis失败了，这导致mysql里面的库存是99而redis里面的还是100 。
4 上述发生，会让数据库里面和缓存redis里面数据不一致，读到redis脏数据
【先更新数据库，再更新缓存】，A、B两个线程发起调用
【正常逻辑】
1 A update mysql 100
2 A update redis 100
3 B update mysql 80
4 B update redis 80
=============================
【异常逻辑】多线程环境下，A、B两个线程有快有慢，有前有后有并行
1 A update mysql 100
3 B update mysql 80
4 B update redis 80
2 A update redis 100
=============================
最终结果，mysql和redis数据不一致
mysql80,redis1002.2、更新缓存,更新数据库
业务上一般把mysql作为底单数据库，保证最后解释
异常问题：
【先更新缓存，再更新数据库】，A、B两个线程发起调用
【正常逻辑】
1 A update redis 100
2 A update mysql 100
3 B update redis 80
4 B update mysql 80
====================================
【异常逻辑】多线程环境下，A、B两个线程有快有慢有并行
A update redis 100
B update redis 80
B update mysql 80
A update mysql 100
最终结果，mysql和redis数据不一致
----mysql100,redis802.3、删除缓存,更新数据库
（1）请求A进行写操作，删除redis缓存后，工作正在进行中，更新mysql......A还么有彻底更新完mysql，还没commit
（2）请求B开工查询，查询redis发现缓存不存在(被A从redis中删除了)
（3）请求B继续，去数据库查询得到了mysql中的旧值(A还没有更新完)
（4）请求B将旧值写回redis缓存
（5）请求A将新值写入mysql数据库
上述情况就会导致不一致的情形出现。
2.4、更新数据库,删除缓存
异常问题
解决方案
2.5、总结
优先使用先更新数据库，再删除缓存的方案(先更库→后删存)。理由如下：
1 先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力导致打满mysql。
2 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。
多补充一句：如果使用先更新数据库，再删除缓存的方案
如果业务层要求必须读取一致性的数据，那么我们就需要在更新数据库时，先在Redis缓存客户端暂停并发读请求，
等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性，这是理论可以达到的效果
但实际，不推荐，因为真实生产环境中，分布式下很难做到实时一致性，一般都是最终一致性，请大家参考。
3、数据双写一致性落到
3.1、mysql主从复制工作原理
MySQL的主从复制将经过如下步骤：
1、当 master 主服务器上的数据发生改变时，则将其改变写入二进制事件日志文件中；
2、salve 从服务器会在一定时间间隔内对 master 主服务器上的二进制日志进行探测，探测其是否发生过改变，
如果探测到 master 主服务器的二进制事件日志发生了改变，则开始一个 I/O Thread 请求 master 二进制事件日志；
3、同时 master 主服务器为每个 I/O Thread 启动一个dump Thread，用于向其发送二进制事件日志；
4、slave 从服务器将接收到的二进制事件日志保存至自己本地的中继日志文件中；
5、salve 从服务器将启动 SQL Thread 从中继日志中读取二进制日志，在本地重放，使得其数据和主服务器保持一致；
6、最后 I/O Thread 和 SQL Thread 将进入睡眠状态，等待下一次被唤醒；3,2、canal工作原理
3.3、mysql-canal
3.3.1、mysql开启binlog
log-bin=mysql-bin #开启 binlog
binlog-format=ROW #选择 ROW 模式
server_id=1 #配置MySQL replaction需要定义，不要和canal的 slaveId重复
ROW模式 除了记录sql语句之外，还会记录每个字段的变化情况，能够清楚的记录每行数据的变化历史，但会占用较多的空间。
STATEMENT模式只记录了sql语句，但是没有记录上下文信息，在进行数据恢复的时候可能会导致数据的丢失情况；
MIX模式比较灵活的记录，理论上说当遇到了表结构变更的时候，就会记录为statement模式。当遇到了数据更新或者删除情况下就会变为row模式；
新建授权用户
DROP USER IF EXISTS 'canal'@'%';
CREATE USER 'canal'@'%' IDENTIFIED BY 'canal';
GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' IDENTIFIED BY 'canal';
FLUSH PRIVILEGES;
SELECT * FROM mysql.user;3.3.2、canal服务端
1、下载地址
https://github.com/alibaba/canal/releases
2、解压
tar -xf canal.deployer-1.1.7.tar.gz -C /mycanal
3、配置
修改/mycanal/conf/example路径下的instance.propertiesmysql主机地址配置
账号和密码配置
启动
cd /mycanal/bin路径下执行
./startup.sh查看server日志
查看样例example的日志
