如图，架构上的差异一目了然，我们可以自顶向下分析：
1、非标 SDK vs 标准 SDK
公有云用户普遍讨厌 “搞特殊”，然而 Codis 偏要搞特殊。Codis 绑架用户必须使用非标 Jodis SDK 来解决代理层单点故障问题。但如果用户偏要使用标准 SDK（如大名鼎鼎的 Jedis）呢？Codis 表示：对不起，跟高可用说拜拜吧。
相反，GaussDB (for Redis) 在使用上则很友好，业务侧使用任何标准 SDK 都行，同时高可用、自动负载均衡能力也全都在。上云搬迁时，GaussDB (for Redis) 兼容方面做得也很成熟，不论客户原来代码用的是 StandAlone，还是 Cluster、Sentinel 等模式，都可以 0 改造上云，真正做到开箱即用，体验感极佳。
2、无负载均衡 vs 专业的 ELB
Codis 的代理层虽然提供了横向扩展能力，但并不好用：要么牺牲高可用来使用标准 SDK 连接单点；要么使用 Jodis SDK，但代价是业务走向非标化。
而 GaussDB (for Redis) 提供 ELB，方便用户统一接入，在简化客户端复杂度的同时，还带来了专业的负载均衡能力。有了这个统一接入 IP，用户相当于自己在使用一个超大容量的单机 Redis，而无需操心底层细节。
3、存算耦合 vs 存算分离
可以认为，Codis 是在多套 Redis 分片上做了一层封装，架构模型是传统的存算耦合。在大 key、数据一致性、分片故障、扩缩容等典型场景中，都延续了开源 Redis 的长期 “痛点”。
GaussDB (for Redis) 采用存算分离架构，计算层聚焦数据业务，存储层基于高性能分布式共享存储池，确保数据三副本存储强一致，超高可靠。同时大幅节省硬件成本，帮业务减负。
