IT评测·应用市场-qidao123.com技术社区

标题: 4.17---实现商铺和缓存与数据库双写同等以及宕机处置惩罚 [打印本页]

作者: 风雨同行 时间: 5 天前
标题: 4.17---实现商铺和缓存与数据库双写同等以及宕机处置惩罚
实现商铺和缓存与数据库双写同等（以及强双写同等策略）

redis点评项目接纳的是延时双删策略
双删：

我们更新完数据库之后删除缓存，如许纵然有线程并发进来查询，会发现缓存中没有数据，从而会去mysql中查找最新的数据。
延时：

在高并发的情况下，如果一个哀求更新了数据库，另一个哀求在数据库更新完成后但缓存删除之前读取了旧数据并存入缓存，可能会导致短暂的数据不同等。
延时的作用：

添加过期时间保证缓存会定期失效，触发重新从数据库加载最新数据，从而淘汰脏数据问题。但是它也只能降低脏数据的风险，不能保证数据的强同等性。
在项目中具体操作是：

根据id查询店肆时，如果缓存未掷中，则查询数据库，将数据库效果写入缓存，并设置超时时间。
根据id修改店肆时，先修改数据库，再删除缓存。
除了延时其他保证数据强同等性的方案：

方案一：

给查询店肆，修改店肆这两步加分布式锁。
方案二：

可以接纳加读写锁（分布式锁的优化方案）
读锁（共享锁）：允很多个线程同时获取（进行读操作）
写锁（排他锁）：一次只答应一个线程获取（进行写操作）
简而言之就是在多线程同时读数据库大概缓存数据时，是可以并发处置惩罚的，不会壅闭，还可以提高系统吞吐量（分布式锁在一个线程读数据库时其他线程会被壅闭）；但是！当一个写成修改数据库数据，这时它获取了写锁，它成功实现修改数据库信息然后更新缓存。在这个过程中系统会保证其他线程不能获取读锁或写锁，不能进行任何操作，从而保证数据库缓存双写同等性。
方案三：

可以接纳消息队列
当目标要修改数据时，由service发布信息到消息对列中，然后缓存的service监听信息队列的信息，得到数据库信息要被修改的信息实行更新缓存操作。（缺点是具有肯定延时性）
缓存数据库此中一个宕机了怎么办

对于延时双删策略来说：

redis出现宕机	缓存完全不可用	数据哀求比力小	直接将哀求临时交给数据库处置惩罚
		数据哀求比力大	方案一：熔断和降级：返回静态默认值或缓存过的最后已知值方案二：启用当地缓存（Caffeine）作为二级缓存方案三：对数据库哀求限流，避免雪崩
	缓存部门节点宕机	方案一：如果是Redis集群，使用集群自动切换，故障转移的能力。方案二：数据分片和数据冗余：数据分片将数据分布在差别的服务器节点上，数据冗余会在多个节点上存储数据副本。所以纵然某节点宕机还是可以得到部门数据。
数据库出现宕机	主库宕机	方案一：进行主从切换：可以提前设置一个备用库，当主库宕机就自动切换为备用库。方案二：写入消息队列中（Kafka）,等数据库恢复后从队列中获取数据。
	从库宕机	负载平衡：将哀求分发到其他从库。

如果接纳消息队列：
redis宕机：因为消息队列中可能还存在未被消费的订单消息，所以等订单信息消费之后，将后续的订单哀求直接由mysql数据库完成，保证数据的同等性。

Kafka宕机：先将redis中未写入数据库的订单信息写入数据库中。消息队列的本质作用是异步削峰，假如消息队列宕机，后续新的哀求只能直接操作数据库而不是发送给消息队列，如许可能会造成数据库较大压力，这里可以做一些熔断和降级的处置惩罚逻辑。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)