1、redis oom问题
OOM问题引发的根本原因是系统内存不足，oom检测程序杀死score较高的程序（通常是占用内存较多的用户程序）。
redis出现oom的状况一般是在做rdb save/bgsave（slave全量复制）或者aof rewrite的时候。执行这些动作的时候需要占用大量的物理内存。
rdb bgsave fork子进程使用copy-on-write机制，在繁忙的系统中save几乎需要占用redis实例同等大小的物理内存。
如果系统的物理内存不足，那么很容易引发oom。
2、redis bgsave很慢问题
1）系统的物理内存不足，导致大量的swap操作，bgsave数据写出的速度很慢。
通过iostat工具可以发现，rdb文件每秒的写入速度甚至不到1M（两块sas盘做raid1）。
2）磁盘io压力比较大
3、redis内存碎片和内存回收问题
1）redis使用jemalloc作为内存分配器，优点是内存的分配效率高，而jemalloc的缺点就是内存碎片比较明显。
redis的mem_fragmentation_ratio = used_memory_rss / used_memory的比值较高，说明内存碎片率较高。
2）redis删除数据后，进程的并没有立即释放这部分内存，rss和virt的值仍然很大。
目前还没很好的的解决方法，只有bgsave保存数据，在重启redis。
4、redis物理机free -g显示的空闲内存很少，而实际redis占用的内存没有这么多，甚至不到used的一半。
仔细观察发现fee -g显示的结果中，cache部分的数值很大。
引起的原因：redis做bgsave，特备是复制的时候，需要大量的内存作为文件cache（read）。
因而不用担心机器内存不足，因为cache部分的内存可以有系统释放。
5、twemproxy oom现象
这个是在是用big pipeline时候出发的twemproxy引起的，pipeline数据太多,因而这个现象很难碰到。
详细见：
6、redis建立主从复制失败。
vm.overcommit_memory=0(默认值)导致fork子进程的时候内存分配请求失败。
同样，手动执行rdb bgsave也会失败。
redis admin manual推荐把这个值设置为1，我们系统基础运都是是用默认值。
7、redis cpu使用率高，而qps很低
这个现象毫无疑问是slwo query引起的，20%的慢查询可以导致其他的80%的query执行速度也很慢。
通过分析redis monitor的日志可以发现，一些简单的set、get命令也执行的很慢。
比如常见的慢查询操作有：
lrane long_list 0 -1
smembers large_set
hget large_hase
8、twemproxy日志打印一些奇怪的client error错误
redis本身支持telnet操作，而twemproxy不支持，是用telnet连接twemproxy端口会自动关闭连接。
lvs+twemprox模式下，twemproxy日志打印一些奇怪的client error错误，错误显示的ip来自lvs机器。
lvs会探测后端的redis的状态，而twemproxy不能解析这些数据包。
9、redis（2.8.8）的小bug（个人认为，未证实）
1）type命令查询kye的类型，会更显key的object idle time。
2）redis2.8复制2.6的数据，会丢失key。
3）slaveof可以是自己，出现循环复制，出现redis cpu使用率高，甚至卡死的现象。