redis性能调优

针对Redis的性能优化，主要从下面几个层面入手：

• 最初的也是最重要的，确保没有让Redis执行耗时长的命令

• 使用pipelining将连续执行的命令组合执行,

• 使用pipelining时，只需要从客户端一次向Redis发送多条命令（以\r\n）分隔，Redis就会依次执行这些命令，并且把每个命令的返回按顺序组装在一起一次返回，比如：

• $ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
  +PONG
  +PONG
  +PONG

• 操作系统的Transparent huge pages(大内存页)功能必须关闭，否则可能导致redis延迟和内存使用问题：

  echo never > /sys/kernel/mm/transparent_hugepage/enabled

• echo never > /sys/kernel/mm/transparent_hugepage/defrag

• 如果在虚拟机中运行Redis，可能天然就有虚拟机环境带来的固有延迟。可以通过./redis-cli --intrinsic-latency 100命令查看固有延迟。同时如果对Redis的性能有较高要求的话，应尽可能在物理机上直接部署Redis。

• 检查数据持久化策略

• 考虑引入读写分离机制

• 用scan代替keys,因为keys会阻塞redis的单线程

集群分片

为何要做集群分片：

• Redis中存储的数据量大，一台主机的物理内存已经无法容纳

• Redis的写请求并发量大，一个Redis实例以无法承载

当上述两个问题出现时，就必须要对Redis进行分片了。
Redis的分片方案有很多种，例如很多Redis的客户端都自行实现了分片功能，也有向Twemproxy这样的以代理方式实现的Redis分片方案。然而首选的方案还应该是Redis官方在3.0版本中推出的Redis Cluster分片方案。

本文不会对Redis Cluster的具体安装和部署细节进行介绍，重点介绍Redis Cluster带来的好处与弊端。

Redis Cluster的能力

• 能够自动将数据分散在多个节点上

• 当访问的key不在当前分片上时，能够自动将请求转发至正确的分片

• 当集群中部分节点失效时仍能提供服务

其中第三点是基于主从复制来实现的，Redis Cluster的每个数据分片都采用了主从复制的结构，原理和前文所述的主从复制完全一致，唯一的区别是省去了Redis Sentinel这一额外的组件，由Redis Cluster负责进行一个分片内部的节点监控和自动failover。

Redis Cluster分片原理

Redis Cluster中共有16384个hash slot，Redis会计算每个key的CRC16，将结果与16384取模，来决定该key存储在哪一个hash slot中，同时需要指定Redis Cluster中每个数据分片负责的Slot数。Slot的分配在任何时间点都可以进行重新分配。

客户端在对key进行读写操作时，可以连接Cluster中的任意一个分片，如果操作的key不在此分片负责的Slot范围内，Redis Cluster会自动将请求重定向到正确的分片上。

数据淘汰机制

Redis提供了5种数据淘汰策略：

• volatile-lru：使用LRU算法进行数据淘汰（淘汰上次使用时间最早的，且使用次数最少的key），只淘汰设定了有效期的key

• allkeys-lru：使用LRU算法进行数据淘汰，所有的key都可以被淘汰

• volatile-random：随机淘汰数据，只淘汰设定了有效期的key

• allkeys-random：随机淘汰数据，所有的key都可以被淘汰

• volatile-ttl：淘汰剩余有效期最短的key

最好为Redis指定一种有效的数据淘汰策略以配合maxmemory设置，避免在内存使用满后发生写入失败的情况。

一般来说，推荐使用的策略是volatile-lru，并辨识Redis中保存的数据的重要性。对于那些重要的，绝对不能丢弃的数据（如配置类数据等），应不设置有效期，这样Redis就永远不会淘汰这些数据。对于那些相对不是那么重要的，并且能够热加载的数据（比如缓存最近登录的用户信息，当在Redis中找不到时，程序会去DB中读取），可以设置上有效期，这样在内存不够时Redis就会淘汰这部分数据。

配置方法：

maxmemory-policy volatile-lru   #默认是noeviction，即不进行数据淘汰

本文参考资料https://www.cnblogs.com/276815076/p/7245333.html