本文摘自《深入分布式缓存》，此文中提到的同程在使用Redis过程中踩过的坑，非常真实也很有借鉴性，读文有感Mark如下：
1、Redis主从+Keepalived方案，存在的问题！
这本来是个很好的方案，但是忽略了主数据节点挂掉的情况。Redis的单进程、单线程设计是其简单和稳定的基石，只要不是服务器发生了故障，在一般情况下是不会挂的。但同时，单进程、单线程的设计会导致Redis接收到复杂指令时会忙于计算而停止响应，可能就因为一个zset或者keys之类的指令，Redis计算时间稍长，Keepalived就认为其停止了响应，直接更改虚IP的指向，然后做一次主从切换。过不了多久，zset和keys之类的指令又会从客户端发送过来，于是从机上又开始堵塞，Keepalived就一直在主从机之间不断地切换IP。终于主节点和从节点都堵了，Keepalived发现后，居然直接将虚IP释放了，然后所有的客户端都无法连接Redis了，只能等运维到线上手工绑定才行。
2、RDB数据落盘，存在的问题！
数据落盘也引起了很大的问题，RDB属于非阻塞式的持久化，它会创建一个子进程来专门把内存中的数据写入RDB文件里，同时主进程可以处理来自客户端的命令请求。但子进程内的数据相当于是父进程的一个拷贝，这相当于两个相同大小的Redis进程在系统上运行（？），会造成内存使用率的大幅增加。如果在服务器内存本身就比较紧张的情况下再进行RDB配置，内存占用率就会很容易达到100%，继而开启虚拟内存和进行磁盘交换，然后整个Redis的服务性能就直线下降了。
3、主从Redis之间网络动荡，存在的问题！
主从Redis之间的网络出现了一点小动荡，想想这么大的一个东西在主从同步，一旦网络动荡了一下下，会怎么样呢？主从同步失败，同步失败，就直接开启全同步，于是200GB的Redis瞬间开始全同步，网卡瞬间打满。为了保证Redis能够继续提供服务，运维同学，直接关掉从机，主从同步不存在了，流量也恢复正常。不过，主从的备份架构变成了单机Redis，心还是悬着的。俗话说，福无双至，祸不单行。这Redis由于下层降级的原因并发操作量每秒增加到四万多，AOF和RDB库明显扛不住。同样为了保证能持续地提供服务，运维同学也关掉了AOF和RDB的数据持久化。连最后的保护也没有了（其实这个保护本来也没用，200GB的Redis恢复太大了）。
4、滥用Redis命令，带来的问题！
Redis上挂载数千个客户端，每秒的并发量数万，系统的单核CPU使用率接近90%，此时Redis已经开始不堪重负。有程序向这个日志组件写入了一条7MB的日志，于是Redis堵死了，一旦堵死，数千个客户端就全部无法连接，所有日志记录的操作全部失败。
所以，对运维来说实践经验、规范操作、要踩的坑必不可少，对开发人员来说对中间件原理的理解和良好的服务/接口架构设计也必须要做到位！
同程凤凰缓存系统基于Redis的设计与实践”
http://www.sohu.com/a/212424883_494947