聊聊redis实际运用及骚操作

聊起 redis 咱们大部分后端猿应该都不陌生，或多或少都用过。甚至大部分前端猿都知道。

数据结构： string、 hash、 list、 set (无序集合)、 setsorted(有序集合)，

运维方面 ： 持久化，主从复制，集群，故障恢复 ，

园子里已经由大佬科普过了，官方文档也能查到， 这里就不细说 redis的“发展起家史”。

咱们今天就聊聊redis的缓存应用场景（不推荐用redis做分布式锁），redis常见操作(击穿，雪崩，缓存数据量过大等)，常见问题及处理方式。怎么用到咱们项目中，提升产品体验。结合我实际项目来解释这里面得思路。（saas,企业级应用）

 

 

 

　　　　数据极少变动：可使用本机内存缓存，单例模式。(如预制分类、城市、配置，首页布局等)

　　　　数据会有变动：加载慢，但是用户经常点击的数据，可使用分布式缓存。(如热点数据，评论，项目工作讨论)

　　用户相关缓存

　　　　跟登陆账户相关，集群化部署需要使用分布式缓存
　　　　用户登陆后的首屏数据，如，常用统计，分类权限菜单，待办事项，工作台等

        延迟加载：有请求才做缓存，无请求则不进行缓存（动态数据）

 　　下面结合我自己项目，各位看官可酌情参考，骚操作开始

　　　　有些数据太多，如果一直都是全部缓存，可能会带来一些问题，内存会爆掉，我们可以缓存部分数据， 比如id（id和权限有关，通过权限去取链路太长，而权限的变更不频繁）

 　　让实体无数据被缓存。数据可被缓存，但引起该缓存失效点众多难以全部覆盖 

　　　　让数据持续有效，提升缓存命中率

　　　　当Get数据有缓存之时，重置缓存有效时间

　　　　利用队列、事件总线、发布订阅、任务管理等进行异步缓存预处理

　　设置缓存版本时间，进行对比（适用于主从关系的数据）

　　　　什么意思呢，清理缓存的地方太多，无法覆盖，我们可以设置版本缓存时间。让相关缓存和这个缓存版本时间进行对比 属性缓存时间> 缓存版本时间=有效

　　　（举个例子）一个项目下由多个工单, 工单设置了缓存，如果项目的基础信息修改，没法及时清理所有工单的缓存（其实这样也不科学,可能导致连接数过高）可以为这个项目设置缓存的时间，获取工单信息的时候如果工单的缓存的时间大于项目缓存的时间。有　　             效直接返回数据，如果无效，则获取DB更新相关缓存即可

这反手一波波操作很骚，咱们说下正常操作（其实也不算骚，反过来思考）

 

　　举个例子，像下列基本都可以做缓存(根据自己的业务来，也可不做，一种方案)

　　　　首页列表（或常用列表）

　　　　置顶内容标题

　　　　未读计数(也可用消息队列）

　　　　常用协作目标联系人搜索

　　　　常用统计周视图日程

　　　　首屏数据

　　　　统计

 

 

善用redis,合理利用二级缓存，合理利用Redis所支持的结构，以提升项目整体性能，redis虽好，不可”贪杯“，否则影响稳定性就得不偿失了（redis只是一个方面，还可以分表，分库，数据库拆分，kafka，ElasticSearch，Solr等，技术都是手段，提供给用户好的体验,解决问题才是最重要的）

 

谢谢！

 

 

如果您觉得阅读本文对您有帮助，请点一下“推荐”按钮，您的“推荐”将是我最大的写作动力！

本文版权归作者和博客园共有，来源网址：https://www.cnblogs.com/DanielYao/欢迎各位转载，但是未经作者本人同意，转载文章之后必须在文章页面明显位置给出作者和原文连接，否则保留追究法律责任的权利。