随着云产品的完善，大多数公司已经开始使用云产品，云产品的确能够解决很多基础架构上的便利，提高业务架构的稳定性，如何将Redis数据在线迁移到云上，并且保证业务的无损，从迁移方案和工具选择必须要考虑如下几点：

兼容性：Redis社区版向下是兼容的，在上云的过程中，尽量保持大版本一致，以免版本不一致导致客户端不兼容的问题

迁移工具：充分考虑工具的功能性的同时，也要重点考虑便利和可运维性，工具需要有完整的日志和监控系统

数据完成性：数据大于一切，不能保证数据完整的情况下，切勿做相关的动作，Redis作为缓存数据变化较快，需实时进行数据较对相关工作

资源有效评估： 云上资源资源规格已标准化，在评估云上资源时，要充分参考自建机房实例，尽量高于自建资源

• 充分考虑自建机房Redis实例的架构，从监控系统中提取实例QPS，内存大小，，连接数，带宽等三个指标，云上实例规格性能需与自建Redis对齐，云上实例对带宽有限制，这点需要注意
• 尽量采用自建实例的从库作为数据同步的数据源，以减少对业务访问主库的压力

兼容性评估

云上实例尽量与自建实例保持大版本一致，目前比较主流的大版本是4.0

命令兼容性确认

云厂商为了支持一些特性，将一些命令进行了阉割，命令兼容性支持请查看云厂商文档

是否使用密码

某些老业务可能不支持密码，在上云的过程中，尽量保持免密，就算部分应用带有密码，也可以兼容

是否使用lua脚本

检查原因：社区版4.0.2版本及以下版本都不会同步二级从库的lua脚本到三级从库，可对Redis进行monitor抓包查看
解决方法：同步主库

是否使用lua客户端

检查原因：部分应用应用lua客户端可能使用内置的域名解析，导致无法解析Redis域名

解决方法：修改内置域名解析或者使用系统域名解析

读写请求是否可拆

检查原因：主库读写无法拆开，无法保证应用一次读写请求请求迁移彻底，从而导致数据不一致性问题

解决方法：对主库使用代理，一般使用Haproxy

确认业务访问方

检查原因：防止业务漏迁，导致数据不一致

解决方法：定期开启redis monitor或tcpdump对主从实例进行抓包，了解业务访问方

确认业务是否有重连机制

检查原因：有研发确认

解决方法：应用端尽量保持重连机制，无重连机制，更改配置后，需重启业务应用

制定了初步的迁移方案后，需跟业务研发负责人一起对接方案，避免有业务上有没有考虑到的问题，做好方案回滚预案

• 搭建的数据同步工具，需要有完成的监控系统，源端实例和目标实例需要有完整的日志，并对实例进行定期实时抓包
• 迁移过程中，研发负责人和运维人员全程参入，避免不可预见问题
• 迁移时间，应当选择业务低峰期

迁移完成后，确认业务无异常后，尽量将源端实例进行关闭，及时发现问题，并实时对代理抓包，避免漏迁移导致的数据不一致

总结迁移过程中出现的问题，并形成文档，方便后续迁移和总结

本方案采用开源Redis-shake作为数据同步工具，haroxy作为代理。架构如下图：

可采用开源Redis数据同步工具，redis-shake的基本原理就是模拟一个从节点加入源redis集群，首先进行全量拉取并回放，然后进行增量的拉取（通过psync命令），具体配置请参考​ ​文档​​

可采用开源数据对比工具，通过全量对比源端和目的端的redis中的数据的方式来进行数据校验，其比较方式通过多轮次比较：每次都会抓取源和目的端的数据进行差异化比较，记录不一致的数据进入下轮对比（记录在sqlite3 db中）。然后通过多伦比较不断收敛，减少因数据增量同步导致的源库和目的库的数据不一致。最后sqlite中存在的数据就是最终的差异结果。具体配置请参考​ ​文档​​

对于业务而已，只提供了redis地址和haproxy的地址，业务配置需要修改配置到haproxy地址，haproxy的配置如下：

• 迁移前一定要做好方案调研、资源评估，兼容性评估
• 监控是运维人员的眼睛，方案选型后，监控是必不可少的
• 业务迁移，尽量选择业务低峰期，并做好相关测试

​ ​redis数据同步​​

​ ​redis 数据比对​​