chapter2 键管理与数据结构
对大多数redis解决方案而言，键的命名设计至关重要。对于管理来说，内存消耗和redis性能都与数据结构设计相关。所以对开发者而言，最好有数据结构的命名文档规范。
chapter3 内存管理优化
rdbchecksum
默认yes，将65位循环冗余验证码放在RDB快照的末尾，作为防止文件损坏的一种手段。当redis产生一个子进程将快照保存到磁盘时，校验会增加10%的内存使用。
activerehashing
默认yes。hash就是找到一种数据内容和数据存放地址之间的映射关系。
哈希表（Hash table，也叫散列表），是根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。
redis中的主hash table将主键与对应的值进行关联。每隔100ms重新hash一次，就是释放删除了键占用的内存空间。
如果有非常高的高并发低延迟要求，可以设为no。
repl-disable-tcp-nodelay
tcp-nodelay：直接发送，关闭nagle算法（累积大的数据包，避免网络中有过多的小数据包）
默认是no，就是在主从复制中，master直接发送同步数据到slave，没有延迟。
设为yes，则会节省带宽，合并发送小包。但会有40ms以上的延迟。
前者关注一致性，后者关注性能。在高并发下，建议设置yes。
maxmemory
硬性设定最大内存。不设定的话，如果redis在增长中不断向系统申请内存而达到系统上线，系统可能会把redis杀掉，导致更大故障。
所以这个参数是要监控的，监控已用内存和最大内存的比例，达到阀值就报警，然后人为去考虑是不是改maxmemory。
maxmemory-policy
默认为noeviction ，就是达到硬性上限后，客户端无法再写入，这显然会引起问题。
还有多种键驱逐策略。如果redis中的数据比较重要不能被删除，那就不能设置这些驱逐策略，而要关注maxmemory不要被用光。如果业务认为可以驱逐，那就按场景设置键驱逐策略
- noeviction : 不会对键进行驱逐，当达到内存限制时，添加数据的命令将会返回错误。
- allkeys-lru : 当达到内存限制时，驱逐最近最少使用的数据（LRU）。
- volatile-lru : 只对设置了过期时间的键进行 LRU 驱逐。如果没有键设置了过期时间，将会返回错误。
- allkeys-random : 对所有键进行随机驱逐。
- volatile-random : 只对设置过期时间的键进行随机驱逐。如果没有键设置了过期时间，将会返回错误。
- volatile-ttl : 只对设置了过期时间的键进行驱逐，优先驱逐即将过期的键。同样如果没有键设置了过期时间，将会返回错误。