| 指标项 | Codis | Twemproxy | Redis Cluster |
| 集群实现语言 | GO语言、C语言 | C语言 | ruby、C语言 |
| 接入成本 | 低 | 低 | 低 |
| 运维成本 | 低（有管控台） | 高 | 中 |
| 稳定版本 | 3.2.2 | 0.5.0 | 7.0.5(redis) |
| 社区维护 | 活跃 | 不活跃 | 非常活跃(官方) |
| CAP(一致性、可用性、分区容错性) | CA | AP | AP |
| HA 方案 | 1、 proxy 部署（多 proxy+zookeeper 集群方案，并且结合 keepalived+haporxy ） 2. 存储层codis-ha | 1、 proxy 部署高可用（多 proxy 结合 keepalived+haporxy ） 2、 redis 层设计多主多从部署 | 自主监控自动切换 |
| 海量并发 | 支持 | 支持 | 支持 |
| 是否支持pipeline | YES | YES | NO |
| 是否使用proxy | YES | YES | NO |
| 是否支持水平扩容 | YES | NO | YES |
| 水平扩容是否重启 | NO | YES | NO |
| 是否支持fail-over | YES | YES | YES |
| 是否支持安全预警 | YES | YES | 否 |
| 性能损失 | 存在 | 存在 | 基本不存在 |
| 是否可以解决数据倾斜 | 是 | 否 | 是 |
| 分片算法 | 通过presharding采用 solt槽位的形式，整个集群分为1024 个哈希槽，分片算法位SlotId = crc32(key) % 1024，增减节点不需要重启服务 | Redis 一致 hash ，当初设计好如后续变更修改（增减节点）需要配置 proxy 通知新的算法，重启服务 | 采用 solt 槽位的形式，整个集群分为 16384 个哈希槽，分片算法位 SlotId = crc16(key) % 16384，增减节点不需要重启服务 |
| 依赖组件 | Codis 、 zk | Redis 、 twemproxy | redis |
| 客户端工具支持 | 主流的都支持 | 主流的都支持 | 主流的都支持 |
| 概括 | 1、 基于 zookeeper 的 proxy 高可用 ，zookeeper 会记录整个集群的生存状态，则需要维护好 zookeeper 2、 优势为动态水平扩容，平衡数据，在迁移的时候不影响业务访问和响应时间，这点很炫，也是它主打的方向 3、 Dashboard 操作降低人失误率，图形直观查看信息 4、 强一致数据（也是设计的重点） | 1、 轻量级 2、 在 proxy 层实现一致性哈希 3、 快速的故障转移 4、 可借助 sentinel 实现底层 HA 5、 不支持平滑扩容每次变更必须重启生效 | 1、 性能好（也是设计的原则） 2、 去中心化 3、 故障转移响应时间长 4、 有写丢失，比较频繁 |
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
