实现商铺和缓存与数据库双写一致 （以及强双写一致策略）
redis点评项目采用的是延时双删 策略
双删：
我们更新完数据库之后删除缓存，这样即使有线程并发进来查询，会发现缓存中没有数据，从而会去mysql中查找最新的数据。
延时：
在高并发的情况下，如果一个请求更新了数据库，另一个请求在数据库更新完成后但缓存删除之前读取了旧数据并存入缓存，可能会导致短暂的数据不一致。
延时的作用：
添加过期时间保证缓存会定期失效，触发重新从数据库加载最新数据，从而减少脏数据问题。但是它也只能降低脏数据的风险，不能保证数据的强一致性。
在项目中具体操作是：
根据id查询店铺时，如果缓存未命中，则查询数据库，将数据库结果写入缓存，并设置超时时间。
根据id修改店铺时，先修改数据库，再删除缓存。
除了延时其他保证数据强一致性的方案：
方案一：
给查询店铺，修改店铺这两步加分布式锁 。
方案二：
可以采用加读写锁 （分布式锁的优化方案）
读锁（共享锁）：允许多个线程同时获取（进行读操作）
写锁（排他锁）：一次只允许一个线程获取（进行写操作）
简而言之就是在多线程同时读数据库或者缓存数据时，是可以并发处理的，不会阻塞，还可以提高系统吞吐量（分布式锁在一个线程读数据库时其他线程会被阻塞）；但是！当一个写成修改数据库数据，这时它获取了写锁，它成功实现修改数据库信息然后更新缓存。在这个过程中系统会保证其他线程不能获取读锁或写锁，不能进行任何操作，从而保证数据库缓存双写一致性。
方案三：
可以采用消息队列
当目标要修改数据时，由service发布信息到消息对列中，然后缓存的service监听信息队列的信息，得到数据库信息要被修改的信息执行更新缓存操作。（缺点是具有一定延时性）
缓存数据库其中一个宕机了怎么办
对于延时双删策略来说：
|-----------|----------|---------|-----------------------------------------------------------------------------------------------------|
| redis出现宕机 | 缓存完全不可用 | 数据请求比较小 | 直接将请求暂时交给数据库处理 |
| redis出现宕机 | 缓存完全不可用 | 数据请求比较大 | 方案一： 熔断和降级：返回静态默认值或缓存过的最后已知值 方案二： 启用本地缓存（Caffeine）作为二级缓存 方案三： 对数据库请求限流，避免雪崩 |
| redis出现宕机 | 缓存部分节点宕机 | 方案一： 如果是Redis集群，利用集群自动切换，故障转移的能力。 方案二 ：数据分片和数据冗余：数据分片将数据分布在不同的服务器节点上，数据冗余会在多个节点上存储数据副本。所以即使某节点宕机还是可以获得部分数据。 ||
| 数据库出现宕机 | 主库宕机 | 方案一：进行主从切换：可以提前设置一个备用库，当主库宕机就自动切换为备用库。 方案二：写入消息队列中（Kafka）,等数据库恢复后从队列中获取数据。 ||
| 数据库出现宕机 | 从库宕机 | 负载均衡：将请求分发到其他从库。 ||
如果采用消息队列：
redis宕机：因为消息队列中可能还存在未被消费的订单消息，所以等订单信息消费之后，将后续的订单请求直接由mysql数据库完成，保证数据的一致性。
Kafka宕机：先将redis中未写入数据库的订单信息写入数据库中。消息队列的本质作用是异步削峰，假如消息队列宕机，后续新的请求只能直接操作数据库而不是发送给消息队列，这样可能会造成数据库较大压力，这里可以做一些熔断和降级的处理逻辑。