redis端口号为什么是（redis配置端口与实际端口不一样）



在了解这个问题之前，我们有必要知道缓存+数据库读写数据的模式，也就是Cache Aside Pattern

（1）读的时候：先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应；

（2）写的时候：先更新数据库，然后再删除缓存。

写的时候模式分析为什么是删除缓存，而不是更新缓存？：

①假设我们有10次写，若是更新缓存的话需要更新10次缓存，10次数据库，我们优化为只需要删除一次缓存，更新10次数据库，当有一个读请求过来只是没有命中，去数据库读取一下，这样对性能的影响也不是很大；

②这是 一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像mybatis，hibernate，都有懒加载思想。

线程1在写数据库与更新缓存之间卡顿了一下，然后线程2在线程1卡顿的这个空隙去写了数据库并刷新了缓存，然后线程2都已经执行完了，线程1又把脏数据更新到了缓存，造成了数据库与缓存不一致。

先更新写操作的，由于中间网络问题或者什么问题造成更新数据推后，最后造成了脏数据的更新，导致数据库与缓存双写不一致。

（1）对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。

（2）就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。

（1）主要思路：在后台进程中我们可以创建多个队列，然后根据hash算法将写请求路由到不同的队列中，当来读请求的时候，就加入队列中，当写请求处理完毕后，再去处理读请求。

（2）分析：如果对于同一份数据有多个写请求同时在队列中，那么来一个读请求中加入队列中之后，一般写请求耗时比较久，那么读请求会需要很久才能返回，这样会特别影响性能，但能保证一致性（一般情况下建议不要用）

通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。

可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度

以上为个人经验，希望能给大家一个参考，也希望大家多多支持。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/23953.html