优质博文：IT-BLOG-CN
一、挑战/注意事项
【1】框架组不允许在不同地区部署的独立Redis实例拥有相同的名称，因此不同地区需要使用不用的Redis集群名称。
【2】分布式锁问题： 该场景需要保证key与UCS灰度策略是可以同步的，即同一个key不会被路由到多个机房。【目前缓存不同步数据】
二、上云方案
Redis:不做双向同步，多数据源。
业务中用到Redis的场景比较多，但Redis不同于业务数据库场景所以不做双向同步，每个IDC对应同单元内的Redis集群，每个Redis集群只服务于当前单元内的业务，所以不是全量的。所以在多IDC的场景下就有很多业务场景需要调整，基于Redis覆盖业务要保证单元内闭环。
三、SDK封装
对Reids的Client工厂进行统一封装，通过约定大于配置的形式，根据区域约定统一的后缀名，向OPS申请部署独立集群。业务开发使用封装的Factory获取Redis Client时，只需要传入固定Cluster Name(不需要添加后缀)，由封装层事先约定，自动从该环境的QConfig配置文件中获取映射的Cluster Name。
【1】部署在国内的独立集群不添加后缀名；
【2】部署在新加坡地区的独立集群统一添加后缀名_sin；
【3】部署在法拉克福地区的独立集群统一添加后缀名_fra；
不足：即使封装了CacheFactory，业务开发扔需要扫描代码变更。同时，该约定为口头约定，没有框架介入，实际执行过程可能会因个人失误造成非预期的结果。
四、海外缓存使用方式
【1】本地访问本地模式（推荐）
【2】从上海同步到新加坡，在新加坡侧只读，海外缓存写入需要申请新集群；（问题：大部分系统上线之后，回先缓存写入数据，往往会写入失败，导致一些问题）；
【3】神盾缓存使用本地模式，数据目前不同步到海外，第一次使用神盾数据需要回源上海，如需预热，需要联系DBA；（问题：国内外数据加解密是不一样的，准备给数据库添加版本信息，新加坡加密的数据，回到上海之后也能够解密）；
五、Redis超大Key双向同步导致客户端链接超时
场景信息 ： 上云时Redis数据需做双向数据同步，开启后出现Redis连接超时异常，Redis版本为4.0.8。
分析问题： 发现其中有超大key，最大的key为7.2MB，超大key双向同步导致的资源占用。建议避免使用超大key。根据DBTrace中的Redis慢日志来进行分析。一个实际运行的参考数据是，当key大小为1.6MB时，Redis每日会有多次300-400ms的慢日志。
解决方案： 将Redis的String类型的数据转换为Hash存储，并对Hash中的Filed按照范围划分为多个Hash集合。改造后进行数据同步，没有再出现超时异常。
六、分布式锁问题
当前项目中的分布式锁是基于Redis实现的，因为不同IDC的Redis集群是相互隔离的，所以目前分布式锁的粒度只支持到了Region级别。目前业务都是围绕用户场景加的分布式锁，所以也可以满足目前的实际业务场景。如果后续有全局获取分布式锁的业务，则需要进一步设计，即保证同一时间所有Region有且只有一个地方能够获得该资源，并且其他Region必须等待，这有可能牺牲掉相当大的性能来实现此功能。
