摘要：在2018数据库直播大讲堂峰会-Redis专场上，阿里云的仲肥对Redis4.0介绍。仲肥从何为Redis4.0着手，通过与以前Redis版本进行对比，全面详解了4.0无论是在计算速度还是进行删除操作时的计算量亦或者进行大数据树状复制结构时的可靠性方面所具有的优越性。
直播视频：https://yq.aliyun.com/video/play/1312
PDF下载：https://yq.aliyun.com/download/2455
以下为精彩视频整理：
何为Redis 4.0？
较传统的Redis在大Key删除时容易阻塞、热点Key、info信息不完善等问题，Redis4.0进行了相应的改进，提出了诸如lazy free、LFU&hotKeys、memory和PSYNC2等特性，很好的解决了传统上所面临的问题。
Lazyfree详解
在处理百万级别数据方面，传统领域主要有DEL和FLUSHALL两种方式，但是这两种方式都有耗时较长的缺点。而Lazyfree采用UNLINK的方式来代替DEL，采用FLUSHALL ASYNC的方式来代替FLUSHALL，从而使处理相同数据的耗时从传统的秒级、分钟级降低到目前的毫秒、微秒级别。
1.主动删除
Lazyfree主动删除主要有Unlink和FLUSHALL ASYNC两种方式。这两种方式都充分利用BIO线程，相应的删除工作也是在后台进行完成。Unlink的调用路径首先是经过Unlink Command入口，之后到异步删除（dbAsyncDelet）环节，最后在BIO任务中插入相应任务。FLUSHALL ASYNC的调用路径首先是经过（flushdbCommand），之后是emptyDbAsync环节，最后在BIO任务队列中插入相应任务。无论是Unlink还是FLUSHALL ASYNC，高耗时计算都是在BIO中进行，主线程主要负责创建任务。
2.被动删除
Redis的删除方式还包括过期删除（lazyfree-lazy-expire）、内存逐出删除（azyfree-lazy-eviction）隐式删除选项rename（lazyfree-lazy-server-del）和slave全量同步清空数据选项（slave-lazy-flush）被动删除机制，在进行相应删除操作只要进行对应的选择就会将删除工作交由BIO进行操作，降低了主线程消耗，避免阻塞。
如何分析热点Keys？
热点Keys是诸多行业都会遇到的问题，当某些数据访问量比较大时就会形成热点，在4.0之前Redis在热点Keys领域并没有提供一个很好分析方法，在提供的诸多方法中也是存在种种不足，目前Redis4.0提出了基于LFU（Least- Frequently- Used）的热点Keys的发现机制。
LFU用来记录单位时间内的访问频率，在实现上用高16位用来记录访问时间（单位为分钟），用低8位⽤用来记录访问频率。Redis在记录访问频率时并不是简单的通过线性增长方式，而是将counter做为一个基于概率的对数增长，8bits即可记录百万级的访问频率。此外，为了更加便于统计还在counter上设计了衰减机制，若在N分钟内Key没有进行访问就将其减N。
在经过counter的统计后，需要进一步对热点Key进行获取，在Redis4.0中通过OBJECT FREQ的命令进行获取工作。由于LFU是一个内存逐出策略，为保证热点Key获取的准确度，需要首先将maxmemory-policy设置为allkeys-lfu或者volatile-lfu，此外可以通过使用redis-cli的-hotkeys选项，分析哪些是热点key。
何为MEMORY命令？
在过去可以通过info memory命令获取Redis的内存使用情况，但是获取的信息具有局限性，不能全面掌握内存使用情况。4.0之后的MEMORY命令可以更好的了解Redis的运行情况，并通过对其输出数据的分析及早的发现Redis使用等方面存在的问题。
1.MEMORY USAGE命令
MEMORY USAGE命令是对一个Key内存使用情况的一个较精确评估，主要采用抽样的方式进行，随着采样值的增加，最终获取的结果也相对精确，但是所用时间也随之增加。
2.MEMORY STATS
MEMORY STATS输出含有多种形式，其中包括Redis的历史峰值、当前分配内存、启动后所用内存（Redis并不是一个预分配的架构，在内存使用方面其用多少内存就会进行多少内存的分配，为了在运行中节省内存，往往在启动时进行共享对象的分配）、主从同步、aof持久化以及db元信息的内存消耗。
3.MEMORY DOCTOR
在Redis使用过程中当内存碎片率高于1.4时就会显示出“Highfragmentation:....”的字段来提示使用者；当slave缓冲区的积压超过10M时，同样也会显示出“Big slave buffers:....”的字段；此外当normal客户端缓冲区积压超过200KB时，系统会显示出“Big client buffers:....”的提醒。在实际使用中当出现上述提醒时，往往需要使用者进行分析原因并及早的进行解决，以便于系统的稳定与运行的正常。在分析过程中要充分考虑是网络较差的原因导致传输较慢还是错误使用某一指令或者操作造成的积压。
4.0 在PSYNC2上与传统有何区别？
PSYNC2是4.0的一种全新的主从复制方式。在2.8版本时master与slave首先需要进行全量同步，在此基础上进行增量同步，如果在增量同步过程中出现断线的情况，只要能在master中找到偏移量还可以进行半同步的方式来避免全量同步的消耗。
在2.8版本中假若master后有两个slave分别为slave1和slave2，master主要包括server.run_id: master和server.master_repl_offset: master_offset两种字段。同样slave也存在相应的字段，其中slave1中的run_id是slave1的，而slave2中的run_id是slave2的，此外slave1和slave2的master->replrunid也不相同，slave1的是来自于master ，而slave2的来自与slave1。在构建复制链或者复制网时，假若中间slave1出现问题，需将slave2与master相连，由于slave2的replrunid(其为slave1的run_id)与master并不相同，所以不能进行相应的半同步。
4.0的PSYNC2解决了上述问题。
- 在建立主从复制关系时，master会将自己的replid传递给slave，slave会把自己的replid更新为master的，这样逐级传递下去，最终master、slave1、slave2的server.replid全部一样，都是master的replid。
- 主从复制建立完成之后，这条复制链上所有的数据都由master产生，也就是说master、slave1、slave2的offset也全都匹配得上。
通过前面2项可以看出，当有需要改变复制关系把slave2挂载到master上时，master和slave2具有相同的replid，并且offset也可以匹配得上，此时就可以直接进行增量同步，避免了全量同步的开销。此外在进行failover时或者主备切换时，PSYNC2也可以避免进行全量同步。
4.0目前已经更新改进到了4.0.6版本，与传统的Redis相比，Redis4.0在诸多方面都具有明显优势，无论是计算速度还是进行删除操作时的计算量亦或者进行大数据树状复制结构构建时的可靠性方面都有了明显的提升。Redis4.0在今后的使用过程中会应用到越来越多的领域，也会给使用者带去更多的使用体验。
本文由云栖志愿小组林一木整理，百见编辑。
