点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
- 原创 | Java 2021 超神之路，很肝~
- 中文详细注释的开源项目
- RPC 框架 Dubbo 源码解析
- 网络应用框架 Netty 源码解析
- 消息中间件 RocketMQ 源码解析
- 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析
- 作业调度中间件 Elastic-Job 源码解析
- 分布式事务中间件 TCC-Transaction 源码解析
- Eureka 和 Hystrix 源码解析
- Java 并发源码
来源：my.oschina.net/
kenblog/blog/3196207
- 一、键名设计
- 1、key名设计
- 2、value设计
- 二、命令使用
- 三、缓存设计
- 四、场景实战问题
- 1、项目redis使用问题
- 2、慎用laravel自带的cache功能
- 3、注意key的过期时间设置
- 4、小心缓存穿透
- 5、慎用缓存层层包裹
- 6、慎用将redis做为消息队列
- 五、查询使用问题
- 1、线上Redis禁止使用Keys正则匹配操作
- 六、其他
- 1、redis同步工具
- 2、大key查询
在公司项目中，redis属于高频使用，在使用中，我们遇到了各种各样的redis问题，于是针对自身情况梳理了一个redis使用规范。
一、键名设计
1、key名设计
1. 禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符)
2. 建议以业务名为前缀，以冒号分割来构造一定规则的key名(比如业务名:表名:id)
比如:teach:leeson_id:21
3. 控制key的长度
key太长量一大起来就会非常占用内存
2、value设计
1. 拒绝大key操作
禁用超过10K的string大key(虽然redis支持512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB。
错误示范：直接将laravel的整个模型或者对象当成value存储
2. 设计key时使用合适的数据类型(在资源利用和性能之间作平衡)
错误示范：一个普通字符串弄成hash类型进行存储
3. 一定要控制key的生命周期
错误示范：key设置为永不过期
4. 控制value长度
比如string类型，如果value为'8个字节的长整型'则内部使用int类型，如果value为'小于等于39个字节的字符串'则内部使用embstr类型，如果value为'大于39个字节的字符串'则内部使用raw类型。这样能很好的利用redis的性能。
5. 数据按需存储
不需要的数据千万不要存储在redis，只会浪费内存空间
基于 Spring Boot MyBatis Plus Vue & Element 实现的后台管理系统 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
二、命令使用
1.禁止使用keys、flushall、hmgetall等命令
为防止业务研发的误操作，通常可以在交付redis实例之前将默认命令rename掉；而真正需要删除或者遍历key时可以使用scan家族命令
2.慎用hgetall、lrange、smembers、zrange等命令
除非业务场景需要，尽量不要使用这些命令。如果没有控制好会导致操作量过大，形成阻塞。
基于微服务的思想，构建在 B2C 电商场景下的项目实战。核心技术栈，是 Spring Boot Dubbo 。未来，会重构成 Spring Cloud Alibaba 。 项目地址：https://github.com/YunaiV/onemall
三、缓存设计
1. 多个库的使用
如果应用中会涉及到各种不同的redis数据存储，应该分库存储，最好是一种业务使用一个库
比如：课程缓存:库1；订单队列:库2；日志处理:库3
2.避免多个应用公用一个redis实例
避免一个应用出现问题或者错误使用拖累其他应用
3.合理评估业务场景，并设置最大内存以及内存淘汰策略(maxmemory和maxmemory-policy)
目前我们用的阿里云redis，不太存在这个问题
4.使用带有连接池的数据库，可以有效控制连接，同时提高效率
5.给redis设置一个密码
目前我们用的阿里云redis，不太存在这个问题
6.冷热数据区分
虽然 Redis支持持久化，但将所有数据存储在redis中，成本非常昂贵。
建议将热数据 (如 QPS超过 5k) 的数据加载到redis中。
低频数据可存储在Mysql、ElasticSearch中。
7.缓存非特殊情况不做中间态 redis大多数时候都是做缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。
- 缓存的高可用会影响业务；
- 产生深耦合会发生无法预料的效果；
- 会对维护产生负效果。
四、场景实战问题
1、项目redis使用问题
当前的使用方式是，每个接入的应用要配置核心项目的redis配置。这样是不合理的，核心项目的redis应该只能在核心项目中使用，对外应该是提供api接口或者rpc进行访问。
2、慎用laravel自带的cache功能
laravel自带的cache功能最容易导致大key，经常由于简单使用至今将整个对象模型存储到redis，造成大key。
3、注意key的过期时间设置
在报名等高峰期的时候，key值设置过短容易造成缓存穿透，导致大量请求直接打到mysql数据库。
4、小心缓存穿透
经常使用会只给有数据的结果进行缓存，结果导致空数据无法缓存，相同查询直接每次都到达数据库，所以空值也应该被缓存。
5、慎用缓存层层包裹
缓存里面的数据还有一层缓存数据，会导致问题排查麻烦，出问题也不容易处理。
6、慎用将redis做为消息队列
如没有非常特殊的需求，严禁将 Redis 当作消息队列使用。redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。
如需要消息队列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ，nsq,(花园同步有时间前后要求，且量不大才使用的)。
五、查询使用问题
1、线上Redis禁止使用Keys正则匹配操作
redis是单线程处理，在线上Key数量较多时，操作效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成redis服务崩溃！如果有类似需求，请使用scan命令代替。
六、其他
1、redis同步工具
阿里云的redis-shake工具，方便快速
2、大key查询
阿里云有大key分析工具
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
代码语言：javascript复制文章有帮助的话，在看，转发吧。谢谢支持哟 (*^__^*）
