Redis查找大KeyTiny发布中...
redis-cli --bigkeys
不是一种好方法，会产生阻塞，可以用其他的工具对rdb文件进行分析产生大key的报告
RedLock争论的点：RedLock是否是安全的？
对于RedLock的实现，也是存在很多开发者和研究人员对其的争论，争论的便是RedLock是否是安全的。
这里我们先假设一种情况，如果此时有五个Redis节点，客户端A和客户端B获取同一个共享资源：
1、客户端A锁住了1、2、3号Redis节点，超过一半获得锁成功。
2、此时1号节点因为崩溃重新启动，由于RDB或者AOF的恢复，在1号节点上加锁信息没有恢复过来。
3、客户端B锁住了1、4、5号节点，获取锁成功。
那么此时客户端A和客户端B都可以对共享资源进行操作。
当然Redis的作者antirez也考虑到了这一种情况，antirez采用了延迟加载来去解决这个问题：
延迟重启也就是一个Redis节点挂了，先不重启，等到大于锁的有效时间的时候才重启这个节点，这样就不会影响现有锁了。
为什么Redis要用跳表来实现有序集合，而不是红黑树?
redis是内存数据库啊，能省还是要省的。
比如，ziplist在redis中是一个非常省内存的链表（代价是性能略低）
1、 skiplist的复杂度和红黑树一样，而且实现起来更简单。
2、区间查找
3、 红黑树在并发情况下的平衡需要锁第一个是比较复杂，调整涉及到多个节点的并发修改
4、 对于越接近根节点的地方越容易产生竞争，即使是不同叶子节点的操作由于平衡操作也可能逐级向上涉及到接近根的节点
而对于skiplist类的链表可以用cas来并发操作节点，比较容易实现，且更加局部化。
删除机制
redis使用的过期键值删除策略是：惰性删除加上定期删除，两者配合使用。
也就是
定时删除是：每隔一段时间执行一次删除操作，并通过限制删除操作执行的时长和频率，来减少删除操作对cpu的影响。另一方面定时删除也有效的减少了因惰性删除带来的内存浪费。
定时扫描策略
Redis 默认会每秒进行十次过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。
- 从过期字典中随机 20 个 key；
- 删除这 20 个 key 中已经过期的 key；
- 如果过期的 key 比率超过 1/4，那就重复步骤 1；
同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过 25ms。
Redis4.0的新特性
更好的复制（PSYNC2），线程DEL / FLUSH，混合RDB + AOF格式，活动内存碎片整理，内存使用和性能改进。
一、主从数据同步机制
psync1在重启从节点需要重新全量同步数据。psync2只部分同步增量数据。
二、命令优化
线程DEL / FLUSH 优化
Redis现在可以在不同的线程中删除后台的key而不会阻塞服务器。
三、混合RDB + AOF格式
混合RDB + AOF格式: 混合的RDB-AOF格式。 如果启用，则在重写AOF文件时使用新格式：重写使用更紧凑和更快的方式来生成RDB格式，并将AOF流附加到文件。 这允许在使用AOF持久性时更快地重写和重新加载
redis问题（暂时放在这）
1、说下redis的rehash过程中scan怎么处理的
rehash期间scan会扫描旧表和新表，合并结果返回。redis在扫描期间做了优化，利用高位加1来遍历数组，可以防止扩容时重复遍历，但无法防止缩容时重复
2、讲讲redis的双机房三机房部署细节，如何做config center
3、redis采用了哪些压缩算法？
lzf 压缩算法
压缩列表是一种数据结构，这种数据结构的功能是将一系列数据与其编码信息存储在一块连续的内存区域，这块内存物理上是连续的，逻辑上被分为多个组成部分，其目的是在一定可控的时间复杂读条件下尽可能的减少不必要的内存开销，从而达到节省内存的效果
4、说下RESP3新特性
- 希望能为客户端提供更多的语义化回复（semantical replies），以开发使用旧协议难以实现的功能；
- 是实现 客户端缓存。
5、Redis 扩容怎么扩？机器存不下了，不加机器怎么解决？不让删缓
6、讲讲redis的gossip协议
社区版redis cluster是一个P2P无中心节点的集群架构，依靠gossip协议传播协同自动化修复集群的状态。
通过gossip协议，cluster可以提供集群间状态同步更新、选举自助failover等重要的集群功能。
