一：Redis 概述
- Redis 是内存级别的数据库，在一台普通电脑上，Redis 3.X 便可以读取 10 万个键值对(现在的Redis官方版本已经更新到了5.X，性能会更好)。
二：关于Redis 和 Memcached 的性能问题。
- 理论上 Memcached 为多线程模型，会比 Redis 性能好。
- 但是，Redis的性能已经足够好，在大部分场合下性能都不会成为它的瓶颈。
- 我们更应该关注的是 Redis 和 Memcached 的应用场景。
三：key 键名设计
- 可读性和可管理性
- 以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
- 简洁性
- 保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，如：( user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid} )
- 不要包含特殊字符
- 空格、换行、单双引号以及其他转义字符 等
四：value设计
- 不要使用特别大的键（bigkey）
- 虽然 Redis 官方说明了 key和string类型value限制均为512MB。
- 但是防止网卡流量、慢查询，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。
- 非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除
- 同时要注意防止bigkey过期自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞。
- 而且该操作不会不出现在慢查询中(latency可查))，查找方法和删除方法。
- 选择适合的数据类型
- 取代将数据存储为数千（或者数百万）独立的字符串，可以考虑使用哈希数据结构将相关数据进行分组。哈希表是非常有效率的，并且可以减少你的内存使用；
- 同时，哈希还更有益于细节抽象和代码可读。
- 合适时候，使用list代替set。如果你不需要使用set特性，List在使用更少内存的情况下可以提供比set更快的速度。
- Sorted sets是最昂贵的数据结构，不管是内存消耗还是基本操作的复杂性。
- 如果你只是需要一个查询记录的途径，并不在意排序这样的属性，那么建议使用哈希表
- 控制key的生命周期
- Redis不是垃圾桶，建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。
- 不过期的数据重点关注idletime。
五：命令使用
- O(N)命令关注N的数量
- hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。
- 在N值过大时候，有遍历的需求可以使用hscan、sscan、zscan代替。
- 禁用命令
- keys
- 客户端可查询出所有存在的键。(键太多导致Redis崩溃，缓存被穿透)
- flushdb
- 删除当前所选数据库的所有键。此命令永远不会失败。
- flushall
- 删除所有现有数据库的所有键，而不仅仅是当前选定的数据库。此命令永远不会失败。
- 禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。
- 使用批量操作提高效率
- 原生命令：例如mget、mset。
- 两者不同：
- 不建议过多使用Redis事务功能
- Redis的事务功能较弱(不支持回滚)，而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)。
- monitor命令
- 必要情况下使用monitor命令时，要注意不要长时间使用。
六：设置合理的淘汰策略
- 根据自身业务类型，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。
- 默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题(申请内存过大导致自杀)。
- 具体
- 
- allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
- allkeys-random：随机删除所有键，直到腾出足够空间为止。
- volatile-random:随机删除过期键，直到腾出足够空间为止。
- volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
- noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。