一、写在前面的话
Redis作为如今托管平台最重要的服务之一，几乎OMG所有的线上业务多多少都在使用Redis，那么其稳定性和维护的高效性必然成为我们所关注的一个重要的问题，在【Redis经典案例分析】这一专题中，我将与大家一起学习关于Redis维护的相关内容，把真是业务环境中遇到的维护问题与大家分享，共同积累Redis维护的经验，提高托管平台Redis服务的高效和可靠性。
二、案例分析
1、案例的由来
A是最早接入托管Redis平台的业务，其使用的旧的Redis服务机制（下图左），故存在无法多IDC自动同步数据和监控项不完善的一系列痛点，其数据只能依靠多地复写的方式，保证各个IDC内数据的一致性，各IDC间数据不要进行严格的一致性校验，容易造成数据一致性出错的现象。
在新的Redis服务机制中（上图右），通过改造同步机制，实现了多IDC自动同步的机制（理论上支持任何一地写入，自动多IDC同步），使得业务在写入数据时只需要单点写，多地自动通过内置的同步自己进行同步和校验，严格的保证了数据一致性。
2、出现的问题
正常来说当我们迁移一地以后，会先确定数据的一致性，接着进行其他两地的自动同步，但是在进行A业务从旧架构到新架构改造过程中，当我们迁移完成一地之后，进行验证时，业务反馈其数据出现了不一致的现象，即写入的部分数据，无法获取的情况。
三、思路和方法
简单来说，问题就是在迁移完之后的架构中数据的同步出现了问题。下面来我们一起来一步一步的排查下这个问题：
1、自查---迁移操作出错？
可以检查下再执行搬迁操作时候的操作流程是否出错，其中特别注意在手动slaveof数据的时候各“”格子“的一一对应关系是否有错。
2、同步机制---机制有BUG？
检查一下是否迁移后的业务可以正常的进行多地IDC同步。方法如下：
①首先分别在深圳、上海、天津的proxy中get一个key，确认其不存在（value值为nil）;
②接着在深圳的proxys上set这个key value；
③分别在上海和天津两地的proxy上get刚刚写入的key，如果均可以得到正确的value值，即说明其同步机制并没有问题。
3、中间件---名字服务配置和解析？
①配置问题
在ons.webdev.com中查看名字服务（读名字、写名字）的关联IP是否已经修改，删除旧IP（或是权重为0），添加新IP。【IP数量较多时需要仔细更改和核对，避免重蹈我的覆辙，一眼花，漏改了一个，结果就悲剧了，现在心情极度低落】
②解析问题
关于解析名字服务的问题，这里就介绍两种常见的方式：
a. 第一种（只能检查名字服务本身在IP的配置同步上出现问题）：
zkname 名字
由于名字下IP过多，这个命令时随机返回IP，应该大量多次的执行该命令，查看解析出的IP地址是否是配置过的IP，是否会出现已经删除或者不属于该业务的IP。
b. 第二种（可以同时检查业务使用的解析逻辑）
在旧业务上添加扩几个新的proxy（为了减小对业务的影响，数量应与原先的proxy一致），通过调整原先所有的proxy的权重（调整为0），观察业务此时的数据是否能保证一致性。
4、业务源头---使用不规范？
①是否有长链接【这一步应该最排查】
在旧业务机器上（为了保险起见，防止原先业务直接连接redis的IP，在proxy和redis上均检查），通过netstat -anp | grep 端口 ，查看一下是否还有长链接，如果有，那么很有可能不同步的问题是由于业务此时还是用其链接将数据写在旧的机器上，造成新机器中没有此数据。
②业务写入不规范
当你排查完操作流程、同步机制的问题以后，如果还是无法解决，那么此时就不要太难为自己了，很可能问题压根就出现在业务的写入逻辑或者代码逻辑上。
正常来说当我们迁移一地以后，会先确定数据的一致性，的业务逻辑如下：
此时正常情况，当业务向已经迁移的”深圳“写入数据时，是不存在数据不一致的现象，但如果业务的写入流程是下图这样，就会出现问题了。此时业务写入的数据由一部分将写到“上海“和“天津”中，这样就造成了数据的不一致。
四、经验分享
由于开发使用读写名字的不定性，为了防止这一种虽然看似简单，但却隐藏的十分好的原因，同时又因为在没确定数据一致性的情况下，不能轻易配置自动多IDC同步，那么在验证一地数据一致性的时候切记，可以先将原先的读名字中其他地方的IP权重调为0，然后进行数据一致性校验。
