配置Redisson客户端同时使用两种codec对接多Redis实例方案咨询

可行性结论 #

该需求完全可落地，不需要修改核心业务逻辑，仅通过Redisson多实例配置+操作层封装即可实现，能完美支持Snappy压缩上线阶段的灰度验证和故障秒级回滚。

具体落地方案 #

• 独立配置两个互相隔离的Redisson客户端实例
  不要复用单实例连接池，两个实例分别对接两台Redis服务器，单独配置对应的编解码器即可，原有JSON实例的配置保持不变，避免影响现有业务。示例配置参考：

  // 对接原有JSON codec Redis的Redisson实例
  Config jsonRedisConfig = new Config();
  jsonRedisConfig.useSingleServer().setAddress("redis://原Redis地址:6379");
  jsonRedisConfig.setCodec(new JsonJacksonCodec()); // 保持原有自定义JSON配置不变
  RedissonClient jsonRedisClient = Redisson.create(jsonRedisConfig);
  
  // 对接新Snappy codec Redis的Redisson实例
  Config snappyRedisConfig = new Config();
  snappyRedisConfig.useSingleServer().setAddress("redis://新Redis地址:6379");
  snappyRedisConfig.setCodec(new SnappyCodec());
  RedissonClient snappyRedisClient = Redisson.create(snappyRedisConfig);
  

• 封装统一操作门面屏蔽双写逻辑
  实现一个和原有Redis操作签名完全一致的工具类，内部对所有写操作同步调用两个客户端的对应方法，优先保障原有JSON实例的操作成功，Snappy实例的操作异常单独捕获打印日志，不抛出到业务主链路，避免测试阶段新实例故障影响线上业务。读请求初期全部走原有JSON实例即可。
• 灰度验证与流量切换
  双写运行一段时间确认数据一致、Snappy实例存储占用符合预期后，逐步把读流量按比例切到Snappy实例，全量切流稳定运行72小时以上即可下掉双写逻辑，直接只用Snappy实例。

关键注意事项 #

• 一致性适配：对数据一致性要求极高的场景，可以设置双写都成功再返回业务成功，会增加1~2ms的响应耗时；对一致性要求不高的场景，Snappy侧的写操作可以扔到异步线程池执行，完全不影响主链路性能。
• 序列化兼容性校验：上线前必须批量验证相同对象分别用两种Codec序列化后，反序列化得到的业务数据完全一致，避免出现字段缺失、类型转换错误等问题。
• 连接池资源评估：两个Redisson实例会各自维护独立的连接池，上线前要确认两台Redis服务器的最大连接数配置足够支撑客户端的连接需求，避免连接超限导致报错。

故障回滚方案 #

只要保留双写逻辑期间，原有JSON实例的数据是完整实时的，一旦Snappy侧出现任何问题，直接把读流量全部切回JSON实例、下掉Snappy侧的双写逻辑即可，不需要做任何数据迁移，秒级完成回滚。

内容的提问来源于stack exchange，提问作者Deepak