| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849 |
- = Redis开发规范
- == 冷热数据分离
- 虽然Redis支持持久化，但是Redis的数据存储全部都是在内存中的，成本昂贵，不要将所有数据全部都放到Redis中。
- 建议根据业务只将高频热数据存储到Redis中（如 `QPS` 大于 `1000`），对于低频冷数据可以使用 `MySQL`/`ElasticSearch`/`MongoDB` 等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时性能足够！
- == 不同的业务数据要分离
- 不要将不相关的业务数据都放到一个Redis实例中，建议新业务申请新的单独实例。
- 因为Redis为单线程处理，独立存储会减少不同业务相互操作的影响，提高请求响应速度；同时也避免单个实例内存数据量膨胀过大，在出现异常情况时可以更快恢复服务。
- == 必须设置超时时间
- 如果应用将Redis定位为缓存Cache使用，对于存放的Key一定要设置超时时间！
- 因为若不设置，这些Key会一直占用内存不释放，造成极大的浪费，而且随着时间的推移会导致内存占用越来越大，直到达到服务器内存上限！
- 另外Key的超时长短要根据业务综合评估，而不是越长越好！
- == 必须要存储的大文本数据一定要压缩后再存储
- 对于大文本（超 `500`字节）写入到Redis时，一定要压缩后存储！
- 大文本数据存入Redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用，并引发雪崩效应，造成各个系统瘫痪！
- == 线上Redis禁止使用 `Keys` 正则匹配操作
- Redis是单线程处理，在线上KEY数量较多时，操作效率极低（时间复杂度为 `O(N)`），该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成Redis服务崩溃！
- 如果有类似需求，请使用 `scan` 命令代替！
- == 可靠的消息队列服务
- 使用 redis 作为消息队列时，最好采用 `stream` 结构，其设计类似 Kafka。
- == 谨慎全量操作 `Hash`、`Set`等集合结构
- 在使用HASH结构存储对象属性时，开始只有有限的十几个field，往往使用 `HGETALL` 获取所有成员，效率也很高，但是随着业务发展，会将field扩张到上百个甚至几百个，此时还使用 `HGETALL` 会出现效率急剧下降、网卡频繁打满等问题【时间复杂度O(N)】。
- 此时建议根据业务拆分为多个Hash结构；或者如果大部分都是获取所有属性的操作,可以将所有属性序列化为一个STRING类型存储！同样在使用SMEMBERS操作SET结构类型时也是相同的情况！
- == 根据业务场景合理使用不同的数据结构类型
- 目前Redis支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, （比特映射）Bitmap, （大数据预测）HyperLogLog和地理空间索引（geospatial）等。
- 需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、计数类；Hash可以用作对象如商品、经纪人等，包含较多属性的信息；List可以用作消息队列、粉丝/关注列表等；Set可以用于推荐；Sorted Set可以用于排行榜等！
|
