Redis开发建议

Redis开发建议

最后附上Redis的一些开发规范和建议：

1.冷热数据分离，不要将全部数据所有都放到Redis中

虽然Redis支持持久化，可是Redis的数据存储所有都是在内存中的，成本昂贵。建议根据业务只将高频热数据存储到Redis中【QPS大于5000】，对于低频冷数据可使用MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式，不只节省内存成本，并且数据量小在操做时速度更快、效率更高！

2.不一样的业务数据要分开存储

不要将不相关的业务数据都放到一个Redis实例中，建议新业务申请新的单独实例。由于Redis为单线程处理，独立存储会减小不一样业务相互操做的影响，提升请求响应速度；同时也避免单个实例内存数据量膨胀过大，在出现异常状况时能够更快恢复服务！ 在实际的使用过程当中，redis最大的瓶颈通常是CPU，因为它是单线程做业因此很容易跑满一个逻辑CPU，可使用redis代理或者是分布式方案来提高redis的CPU使用率。

3.存储的Key必定要设置超时时间

若是应用将Redis定位为缓存Cache使用，对于存放的Key必定要设置超时时间！由于若不设置，这些Key会一直占用内存不释放，形成极大的浪费，并且随着时间的推移会致使内存占用愈来愈大，直到达到服务器内存上限！另外Key的超时长短要根据业务综合评估，而不是越长越好！

4.对于必需要存储的大文本数据必定要压缩后存储

对于大文本【+超过500字节】写入到Redis时，必定要压缩后存储！大文本数据存入Redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网卡流量占满，进而形成整个服务器上的全部服务不可用，并引起雪崩效应，形成各个系统瘫痪！

5.线上Redis禁止使用Keys正则匹配操做

Redis是单线程处理，在线上KEY数量较多时，操做效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，并且在高QPS状况下会直接形成Redis服务崩溃！若是有相似需求，请使用scan命令代替！

6.可靠的消息队列服务

Redis List常常被用于消息队列服务。假设消费者程序在从队列中取出消息后马上崩溃，但因为该消息已经被取出且没有被正常处理，那么能够认为该消息已经丢失，由此可能会致使业务数据丢失，或业务状态不一致等现象发生。

为了不这种状况，Redis提供了RPOPLPUSH命令，消费者程序会原子性的从主消息队列中取出消息并将其插入到备份队列中，直到消费者程序完成正常的处理逻辑后再将该消息从备份队列中删除。同时还能够提供一个守护进程，当发现备份队列中的消息过时时，能够从新将其再放回到主消息队列中，以便其它的消费者程序继续处理。

7.谨慎全量操做Hash、Set等集合结构

在使用HASH结构存储对象属性时，开始只有有限的十几个field，每每使用HGETALL获取全部成员，效率也很高，可是随着业务发展，会将field扩张到上百个甚至几百个，此时还使用HGETALL会出现效率急剧降低、网卡频繁打满等问题【时间复杂度O(N)】,此时建议根据业务拆分为多个Hash结构；或者若是大部分都是获取全部属性的操做,能够将全部属性序列化为一个STRING类型存储！一样在使用SMEMBERS操做SET结构类型时也是相同的状况！

8.根据业务场景合理使用不一样的数据结构类型

目前Redis支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空间索引（geospatial）等,须要根据业务场景选择合适的类型。

常见的如：String能够用做普通的K-V、计数类；Hash能够用做对象如商品、经纪人等，包含较多属性的信息；List能够用做消息队列、粉丝/关注列表等；Set能够用于推荐；Sorted Set能够用于排行榜等！

9.命名规范

虽说Redis支持多个数据库（默认32个，能够配置更多），可是除了默认的0号库之外，其它的都须要经过一个额外请求才能使用。因此用前缀做为命名空间可能会更明智一点。

另外，在使用前缀做为命名空间区隔不一样key的时候，最好在程序中使用全局配置来实现，直接在代码里写前缀的作法要严格避免，这样可维护性实在太差了。

如：系统名:业务名:业务数据:其余

可是注意，key的名称不要过长，尽可能清晰明了，容易理解，须要本身衡量

10.线上禁止使用monitor命令

禁止生产环境使用monitor命令，monitor命令在高并发条件下，会存在内存暴增和影响Redis性能的隐患

11.禁止大string

核心集群禁用1mb的string大key(虽然redis支持512MB大小的string)，若是1mb的key每秒重复写入10次，就会致使写入网络IO达10MB;

12.redis容量

单实例的内存大小不建议过大，建议在10~20GB之内。

redis实例包含的键个数建议控制在1kw内，单实例键个数过大，可能致使过时键的回收不及时。

13 可靠性

须要定时监控redis的健康状况：使用各类redis健康监控工具，实在不行能够定时返回redis 的 info信息。

客户端链接尽可能使用链接池（长连接和自动重连）