1. 大key
如果一个值的size过大，写入时开辟内存以及发送时的数据 copy 开销都会很大。
建议从业务上对大key做拆分。
2. 复杂命令
对于一些数据结构的操作，时间复杂度为 O(N) ，如果不加控制，可能会引起阻塞。
例如 Keys 命令，由于没有limit参数，会全表扫描，耗时大。可以考虑用Scan替代。
3. 高并发下的网络IO
尽管使用了IO多路复用技术，读写 copy 以及 User Mode 和 Kernel Mode 的切换会比较耗时。
4. RDB模式下的fork开销
尽管 RDB 是fork后独立进程中完成落盘工作，fork 这个 System Call 本身耗时大概在700ms级别。
建议尽量避免在高峰时期执行 Save 或 Bgsave 命令。
5. AOF模式下的 Fsync 开销
由于AOF需要修改磁盘中的日志文件，修改文件及其iNode需要两次随机读写IO，大约耗时在20ms级别，因此业务中几乎不会开启 always 模式。
一般都用 Everysecond模式。
6. 大量同时expire的key
由于 Redis 的删除过期键策略中有一条是主动删除：会随机抽出100个设置了过期的key，对已过期的进行删除，如果发现过期的key超过25个，就会重复这个过程。因此，如果有大量同一时间过期的key，会在主动删除触发时，不停地取key删key，造成阻塞。
建议在设置过期时间时使用 Expire 而非 Expireat，或者使用 Expireat 时自己给入一个随机量，让过期时间离散开。
7. 内存逐出
当 Redis 可支配的内存空间不足时，会进行内存逐出操作。尽管可以配置策略，但是逐出时CPU会hang住。
建议对内存使用情况做监控，及时扩容或进行其他人为介入操作。
