redis3.2开始新增了GEO地理位置相关的命令，本文对Geo相关命令使用及实现原理进行介绍。Redis将地理位置的52位GeoHash值作为有序集合的score，将地理位置存放在有序集合中进行保存。阅读本文前可以先阅读《GeoHash算法详解及其实现》，了解GeoHash算法。

GeoHash是一种地址编码，通过切分地图区域为小方块（切分次数越多，精度越高），它能把二维的经纬度编码成一维的字符串。也就是说，理论上geohash字符串表示的并不是一个点，而是一个矩形区域，只要矩形区域足够小，达到所需精度即可。

由于redis中涉及到fread、fwrite、fflush、fsync这四个命令的使用，所以做一个总结笔记，方便查阅。

redis5.0增加了一个dynamic-hz参数，用于自适应调整server.hz的值，平衡空闲CPU的使用率和响应能力；另外在redis5.0中对info命令、clientsCron函数、大量的短连接情形进行了优化。

cluster forget用于节点下线时，将待下线节点从集群其他节点保存的节点列表中删除。由于redis cluster采用gossip协议交互节点信息及集群状态，所以只要集群中有一个节点知道待下线节点，随着gossip信息交换，集群中的其他节点最终也都知道该节点，正因为此，向集群添加一个节点时，只需要向集群任意一个节点执行cluster meet命令即可，也因此，为了将一个节点完全的从集群中删除，必须对集群中其他所有节点都发送cluster forget命令。

同时由于节点设置了一个黑名单，在收到cluster forget命令时，不仅将节点从集群节点列表中删除，同时将该节点加入黑名单，并且设置了60s的过期时间，在60s内，如果从gossip消息中收到该相同节点，不再允许将其加入集群中，所以其实必须在60s内完成对所有节点执行cluster forget命令。

redis3.2中，当节点正在执行aof文件重写时，如果此时调用config set aofrewrite no命令关闭节点aof持久化，会触发bug导致aof文件重写进入死循环，表现为节点不停的执行aof文件重写，严重影响节点性能和磁盘性能。

在 2.8 版本之前 redis 没有增量同步的功能，主从只要重连就必须全量同步数据。如果实例数据量比较大的情况下，网络轻轻一抖就会把主从的网卡跑满从而影响正常服务。2.8 为了解决这个问题引入了 psync (partial sync)功能，顾名思义就是增量同步。

在redis4.0版本中，作者对psync进行了优化，更改为psync2，主要解决Redis运维管理过程中，从实例重启和主实例故障切换等场景带来的全量重新同步(full resync)问题。

在redis中，如果在开启了maxmemory，且在内存使用量接近maxmemory时，刚好出现哈希表的rehash过程，会导致redis内存瞬间突增，内存使用量超过maxmemory，同时如果没有开启自动扩容且开启了淘汰策略的情况下，会导致redis中数据被淘汰。

在Redis中，键值对（Key-Value Pair）存储方式是由字典（Dict）保存的，而字典底层是通过哈希表来实现的。通过哈希表中的节点保存字典中的键值对。我们知道当HashMap中由于Hash冲突（负载因子）超过某个阈值时，出于链表性能的考虑，会进行Resize的操作。Redis也一样。

在redis的具体实现中，使用了一种叫做渐进式哈希(rehashing)的机制来提高字典的缩放效率，避免 rehash 对服务器性能造成影响，渐进式 rehash 的好处在于它采取分而治之的方式， 将 rehash 键值对所需的计算工作均摊到对字典的每个添加、删除、查找和更新操作上， 从而避免了集中式 rehash 而带来的庞大计算量。

Redis作为一个单线程模型的服务，当执行一些耗时的命令时，比如使用DEL删除一个大key（元素超大的集合类型key），或者使用FLUSHDB 和 FLUSHALL 清空数据库，会造成redis阻塞，影响redis性能，甚至导致集群发生故障转移。另外redis在删除过期数据或因内存超过容量淘汰内存数据时，也有可能因为大key导致redis阻塞。

为了解决以上问题，redis 4.0 引入了惰性删除lazyfree的机制，它可以将删除键或数据库的操作放在后台线程里执行，删除对象时只是进行逻辑删除，从而尽可能地避免服务器阻塞。