Foreword
Redis chatted most of the back-end apes should not unfamiliar, more or less used. Even most of the front end apes know.
Data structures: string, hash, list, set (unordered set), setsorted (ordered set),
Operation and maintenance: the persistence, the Lord's recovery from replication, clustering, fault,
The garden has been a science by the chiefs, official documents can be found, will not elaborate here redis "development started history."
Today we will talk redis caching scenarios (redis do not recommend using a distributed lock), redis common operations (breakdown, avalanche, cached data is too large, etc.), common problems and treatment. How we use the project to enhance the product experience. Combined with the actual project I was there to explain the idea. (Saas, enterprise applications)
Types of
Public cache
Changes very little data : using the native memory cache, singleton. (Such as pre-classification, city, configuration, home layout, etc.)
Data subject to change : slow to load, but users often click on the data, you can use the distributed cache. (Such as hot data, comments, discussion of project work)
User-related cache
With login accounts associated cluster deployment requires the use of a distributed cache
user data after landing the first screen, such as common statistical classification authority menu, to-do, table, etc.
Loading
Preloading : system initialization data that is loaded into the cache (for example, related to static data)
Lazy loading : there is a request before doing the cache, the cache no request (dynamic data) is not performed
time setting
But on
Fixed expiration time (hours, day)
Non-fixed expiration time (time synchronization update the cache did update time period, the data acquisition redis, a schematic flowchart of the following)
Failures caused by
穿透
大量无效的Key访问，数据并不存在
解决：Key做验证过滤；无数据也进行缓存（空对象，非null）
击穿
1个Key失效，但这个Key有大量并发请求，特别是公共缓存
解决：失效时间点设置在非高峰时间段；主动做缓存更新（过期之前操作），而不是清理在重建
雪崩
大量key设置了相似过期时间（前后几分钟），导致数据库请求瞬间增加。或者缓存服务器挂了
解决：大量Key不要设置相同时间点过期或者过期时间比较接近，可以进行相对时间设置
项目使用思考
下面结合我自己项目，各位看官可酌情参考，骚操作开始
反向操作
缓存部分数据
有些数据太多，如果一直都是全部缓存，可能会带来一些问题，内存会爆掉，我们可以缓存部分数据， 比如id（id和权限有关，通过权限去取链路太长，而权限的变更不频繁）
让实体无数据被缓存。数据可被缓存，但引起该缓存失效点众多难以全部覆盖
让数据持续有效，提升缓存命中率
当Get数据有缓存之时，重置缓存有效时间
利用队列、事件总线、发布订阅、任务管理等进行异步缓存预处理
设置缓存版本时间，进行对比（适用于主从关系的数据）
什么意思呢，清理缓存的地方太多，无法覆盖，我们可以设置版本缓存时间。让相关缓存和这个缓存版本时间进行对比 属性缓存时间> 缓存版本时间=有效
（举个例子）一个项目下由多个工单, 工单设置了缓存，如果项目的基础信息修改，没法及时清理所有工单的缓存（其实这样也不科学,可能导致连接数过高）可以为这个项目设置缓存的时间，获取工单信息的时候如果工单的缓存的时间大于项目缓存的时间。有 效直接返回数据，如果无效，则获取DB更新相关缓存即可
这反手一波波操作很骚，咱们说下正常操作（其实也不算骚，反过来思考）
正常操作
常用数据加入缓存
请求数量庞大的请求加入缓存
查询较慢（通常是数据量基数庞大）的请求加入缓存
举个例子，像下列基本都可以做缓存(根据自己的业务来，也可不做，一种方案)
首页列表（或常用列表）
置顶内容标题
未读计数(也可用消息队列）
常用协作目标联系人搜索
常用统计周视图日程
首屏数据
统计
整体操作
数据完整的置入缓存
用户信息
权限信息
缓存组
让具备缓存失效关联关系的可将关键置入缓存组，失效则同时进行失效，关系可存放于内存或者Redis支持结构里面
善用redis,合理利用二级缓存，合理利用Redis所支持的结构，以提升项目整体性能，redis虽好，不可”贪杯“，否则影响稳定性就得不偿失了（redis只是一个方面，还可以分表，分库，数据库拆分，kafka，ElasticSearch，Solr等，技术都是手段，提供给用户好的体验,解决问题才是最重要的）
谢谢！
如果您觉得阅读本文对您有帮助，请点一下“推荐”按钮，您的“推荐”将是我最大的写作动力！
本文版权归作者和博客园共有，来源网址：https://www.cnblogs.com/DanielYao/欢迎各位转载，但是未经作者本人同意，转载文章之后必须在文章页面明显位置给出作者和原文连接，否则保留追究法律责任的权利。