键值设计
- key名设计
- value设计：拒绝 bigkey (防止网卡流量、慢查询)
- 字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey
- 非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多
- string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000
- 非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除
- bigkey的危害
- 导致redis阻塞
- 网络拥塞
- 过期删除：阻塞Redis
- 使用过期异步删除
lazyfree-lazy-expire yes
- bigkey的产生：程序设计不当&数据规模预料不清楚
- 社交类：粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey
- 统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey
- 缓存类：将数据从数据库load出来序列化放到Redis里，这个方式非常常用，但有两个地方需要注意
- 是不是有必要把所有字段都缓存
- 有没有相关关联的数据
- 如何优化bigkey
- 拆
- big list： list1、list2、…listN
- big hash：数据分段存储
- 如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出来，删除也是一样
- 选择适合的数据类型
- 控制key的生命周期，redis不是垃圾桶
命令使用
- O(N)命令关注N的数量：可以使用hscan、sscan、zscan代替
- 禁用命令（rename）：keys、flushall、flushdb，使用scan的方式渐进式处理
- 合理使用select：redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰
- 使用批量操作提高效率：控制一次批量操作的元素个数 (例如500以内，实际也和元素字节数有关)
- 原生命令：例如mget、mset
- 非原生命令：可以使用pipeline提高效率
- Redis事务功能较弱，不建议过多使用，可以用lua替代：只提供了弱事务，不提供回滚（能不用尽量不用）
- 命令本身有错，会回滚
- 命令没错，执行报错，不会回滚
- watch 实现乐观锁机制
- 事务和pipline的区别
- pipline是客户端行为，非原子，降低网络开销，某条命令失败后不影响后续命令的执行
- 事务是服务端行为
- 尽量使用pipline，尽量不用事务，可以用LUA保证事务原子性
EVAL script numkeys key [key ...] arg [arg ...]
客户端使用
- 避免多个应用使用一个Redis实例
- 使用带有连接池的客户端（JedisPool#getResource），可以有效控制连接，同时提高效率
- maxTotal：最大连接数
- 业务希望Redis并发量
- 客户端执行命令时间
- Redis资源：例如 nodes(例如应用个数) * maxTotal 是不能超过redis的最大连接数maxclients
- 资源开销：例如虽然希望控制空闲连接 (连接池此刻可马上使用的连接)，但是不希望因为连接池的频繁释放创建连接造成不必靠开销
- maxIdle：maxIdle实际上才是业务需要的最大连接数，maxTotal是为了给出余量，所以maxIdle不要设置过小，否则会有new Jedis(新连接)开销
- 连接池的最佳性能是maxTotal = maxIdle，这样就避免连接池伸缩带来的性能干扰
- 并发量不大或者maxTotal设置过高，会导致不必要的连接资源浪费
- maxIdle可以设置为业务期望QPS计算出来的理论连接数，maxTotal可以再放大一倍
- minIdle（最小空闲连接数），与其说是最小空闲连接数，不如说是"至少需要保持的空闲连接数"，在使用连接的过程中，如果连接数超过了minIdle，那么继续建立连接，如果超过了maxIdle，当超过的连接执行完业务后会慢慢被移出连接池释放掉
- 如果系统启动完马上就会有很多的请求过来，那么可以给redis连接池做预热，比如快速的创建一些redis连接，执行简单命令，类似ping()，快速的将连接池里的空闲连接提升到minIdle的数量
- 高并发下建议客户端添加熔断功能 (例如sentinel、hystrix)
- 设置合理的密码，如有必要可以使用SSL加密访问
- Redis对于过期键有三种清除策略
- 被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期 key
- 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
- 针对设置了过期时间的key做处理
- volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除
- volatile-random：就像它的名称一样，在设置了过期时间的键值对中，进行随机删除
- volatile-lru（推荐）：会使用 LRU 算法筛选设置了过期时间的键值对删除
- volatile-lfu：会使用 LFU 算法筛选设置了过期时间的键值对删除
- 针对所有的key做处理
- allkeys-random：从所有键值对中随机选择并删除数据
- allkeys-lru：使用 LRU 算法在所有数据中进行筛选删除
- allkeys-lfu：使用 LFU 算法在所有数据中进行筛选删除
- 不处理
- noeviction（默认）：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作
- 淘汰算法
- LRU 算法（Least Recently Used，最近最少使用）：淘汰很久没被访问过的数据，以最近一次访问时间作为参考
- LFU 算法（Least Frequently Used，最不经常使用）：淘汰最近一段时间被访问次数最少的数据，以次数作为参考
- 当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。这时使用LFU可能更好点
- 如果不设置最大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降
- 当Redis运行在主从模式时，只有主结点才会执行过期删除策略，然后把删除操作”del key”同步到从结点删除数据
- 当前已用内存超过maxmemory限定时，触发主动清理策略
系统内核参数优化
vm.swapiness
- 在Linux中，并不是要等到所有物理内存都使用完才会使用到swap，系统参数swppiness会决定操作系统使用swap的倾向程度
- swappiness的取值范围是0~100，swappiness的值越大，说明操作系统可能使用swap的概率越高
- 一般需要保证redis不会被kill掉
- linux内核版本<3.5，那么swapiness设置为0，这样系统宁愿swap也不会oom killer
- linux内核版本>=3.5，那么swapiness设置为1，这样系统宁愿swap也不会oom killer
- OOM killer 机制是指Linux操作系统发现可用内存不足时，强制杀死一些用户进程（非内核进程），来保证系统有足够的可用内存进行分配
- 配置
cat /proc/version #查看linux内核版本echo 1 > /proc/sys/vm/swappinessecho vm.swapiness=1 >> /etc/sysctl.conf
vm.overcommit_memory (默认0)
- 0：表示内核将检查是否有足够的可用物理内存 (实际不一定用满) 供应用进程使用
- 如果有足够的可用物理内存，内存申请允许
- 否则，内存申请失败，并把错误返回给应用进程
- 1：表示内核允许分配所有的物理内存，而不管当前的内存状态如何
- 如果是0的话，可能导致类似fork等操作执行失败，申请不到足够的内存空间
- Redis建议把这个值设置为1，就是为了让fork操作能够在低内存下也执行成功
- 合理设置文件句柄数
- 操作系统进程试图打开一个文件(或者叫句柄)，但是现在进程打开的句柄数已经达到了上限，继续打开会报错：“Too many open files”
ulimit ‐a 查看系统文件句柄数，看open files那项ulimit ‐n 65535 设置系统文件句柄数
- 慢查询日志：slowlog
config get slow*
config set slowlog‐log‐slower‐than 20000
config set slowlog‐max‐len 1024
config rewrite
slowlog len
slowlog get 5
slowlog reset
