redis 性能优化

客户端在向redis服务器发送多条写命令时， 使用批量命令或流水线（pipelined）的方式以减少宽带的来回传输的时间， 数据越大性能提升越明显。

一台主服务可以有多台从服务器， 一台从服务器也可以有多个从服务， 主服务器下的从服务器不是越多越好的， 因为主服务器如果有数据更新的话会同步到每个从服务器中， 如果从服务有10台， 客户端向主服务器发送100条写的命令， 那么主服务也会发送10 * 100条命令到从服务器。 而且服务器越多发生的宕机机率就越高， 从服务器宕机恢复后，主服务器还会跟这台从服务器进行全量数据同步， 这个过程非常损耗主服务器的性能。 在进行大量的redis集群部署时， 可以在主从服务器之间加上一层专门复制的从服务器， 如下图：

redis 持久化有两种， 一种是快照持久化， 一种是AOF持久化，不管是哪一种持久化都是对硬盘写入数据， 如果频繁IO会直接影响性能。 以AOF为例， 每次处理写命令或每秒处理写命令， redis会把写命令以追加的方式进行持久化，转盘式硬盘每次只能处理大概200个命令， 那么客户端1秒发送1000个命令，redis需要5秒进行处理。 如果换成固态硬盘的话每秒可以处理几万个命令， 但是固态硬盘成本太大， 加上频繁IO会大大降低固态硬盘的寿命，如果数据不是非常重要一般不使用AOF持久化， AOF持久化最坏的情况只会丢失一秒的数据或一个写命令。 如果数据丢失容许一定时间范围的话， 可以使用快照持久化， 数量在几个GB生成快照非常快在一般几十毫秒内， 生成快照时，redis会创建一个子进程进行持久化， 在创建子进程会造成服务器停顿， 一般每增加一个GB的数据量根据服务器硬件好坏会停顿10~400毫秒， 数据量达到几十G的时候会导致停顿5~10秒。持久化也可以发送BGSVAE命令手动触发， 关闭自动持久化， 在用户活跃较少的时间段进行手动触发

当redis 实例内存大于系统可用内存时， 系统会创建一个交换区， 把旧数据或不使用的数据写入交换区， 腾出空间给新数据， 每当redis增加新数据都对交换区进行IO操作，硬盘读取操作与内存读取操作不是一个数量级的， 一个毫秒级一个微秒级， 性能会瞬间急速下降。 可以适当调整短结构策略来压缩内存， 也可以根据业务场景设置key有效时间达到内存有效利用率, 还可以调整创建快照的策略， 因为创建快照时会启动一个子进程， 并且完全复制与实例一样的内存副本写入硬盘

redis 内存碎片率过高也会导致性能急速下降， 什么是内存碎片？ 可以把内存当做一个固定面积的大正方形， 数据当做一个不固定面积的小正方形， 在理想情况下， 大正方形非常整齐放置着无数个小正方形， 当进行无效的内存回收时， 会在大正方形某个位置挖走一个小正方形， 假设面积这1平方， 那么这个位置这空出1平方， 当新数据加入时， 这个数据占2平方，这时数据是填充不进去的， 当这种情景不断的发生时，空出1平方位置被视为碎片，大正方形也被挖得坑坑洼洼的， 严重影响内存读写和利用率。 这时可通过info memory查看mem_fragmentation_ratio指标， 当这个值大于1.5时， 重启redis实例会进行内存重新排序

redis 是一个单线程的程序， 客户端发送命令都是串行顺序执行的。 如果其中一个命令执行时间很长， 会阻塞后面的命令。 这时需要了解命令的时间复杂度， 排序、并集、交集命令尽量放到客户端进行， 遍历大数据集合时尽量避免全局遍历。