周五晚上下班和同学吃椰子鸡(大深圳唯一拿得出手的菜了 T.T…)，一个朋友给我打电话，说线上业务出了问题，让帮忙看下。 问题要点如下：
- 由于业务量增大，往线上Redis集群增加了一个节点
- 新增的节点遇到性能问题，qps只有节点中原有机器的一半
- 新增的节点的机器比现有机器还要”好”，是新机器
诡异了，于是我依次问了以下问题：
- 用perf看看有没有某些函数调用特别耗时 ?
- 新的节点的数据量是不是更大？
- 新的节点的数据访问的命中率有何不同？
- 新的节点有无大量过期淘汰的数据？
- 使用info commandstats命令看新的几点上面命令执行的时间是否教老节点的长？
问完了第二个问题，我手机就没电了， 回到家之后，得到这些问题的答案都是否。这就蛋疼了，但是已经基本可以断定和Redis的 没关系，我让他去问问他们运维新旧机器的详细参数，主要是cpu和内存型号。
正准备睡觉了，电话响起了。 由于之前新节点的性能不给力，影响业务，就下线了新节点，结果又扛不住，就准备重新把这机器上线， 搞一小部分数据上去，缓解已有的一个负载较大的节点的压力。结果，使用redis-trib工具，中间有个slot的状态不对，死活没法继续 往下迁移了。 于是，
- 首先定位是哪个slot有问题
- 定位该slot存在于哪几个节点上面(存在于三个几点上面，正常情况下应该只存在于迁移的源节点和目标节点的)
- 确认改slot中有哪些key，将这些key备份出来(只有一个key)，据朋友反应这是个bug: https://github.com/antirez/redis/issues/1765
- 将该slot从不相关的第三个节点上删除(设置为migrating, asking, del, setslot stable)
- 恢复备份的key, 继续迁移
扯远了，想表达的问题是， redis-cluster还是不太稳定成熟，慎重使用，再做del之前一定要想办法备份key，不然会悲剧。 回到性能 下降问题，我让朋友去新旧机器上面把/proc/cpuinfo的信息弄出来看看， 得到如下结果：
- 旧服务器的Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz
- 新服务器的Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz
由于每个服务器上面只部署了一个Redis实例，那么新机器上面的性能差就很好解释了。建议：
- 做多实例部署， 每个实例的数据集不要太大
- Redis机器建议内存高配，cpu的核数 >= 实例数