1. Codis集群部署实战1.1 环境准备与依赖安装搭建Codis集群前需要准备至少3台Linux服务器物理机或虚拟机建议配置4核CPU/8GB内存以上。这里以Ubuntu 20.04为例演示基础环境配置# 安装基础工具链 sudo apt update sudo apt install -y git make gcc autoconf # 安装Go语言环境Codis 3.x要求Go 1.7 wget https://golang.org/dl/go1.17.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.17.linux-amd64.tar.gz echo export PATH$PATH:/usr/local/go/bin ~/.bashrc source ~/.bashrc # 验证Go安装 go version # 应输出 go1.17 linux/amd64Zookeeper是Codis的元数据存储依赖使用以下命令快速部署单节点Zookeeperwget https://archive.apache.org/dist/zookeeper/zookeeper-3.6.3/apache-zookeeper-3.6.3-bin.tar.gz tar -xzf apache-zookeeper-3.6.3-bin.tar.gz cd apache-zookeeper-3.6.3-bin cp conf/zoo_sample.cfg conf/zoo.cfg ./bin/zkServer.sh start1.2 源码编译与组件安装从GitHub获取Codis 3.2稳定版源码并编译mkdir -p $GOPATH/src/github.com/CodisLabs cd $GOPATH/src/github.com/CodisLabs git clone https://github.com/CodisLabs/codis.git -b release3.2 cd codis make编译成功后会在bin目录生成以下关键组件codis-dashboard集群管理控制台codis-proxyRedis协议代理服务codis-server定制化Redis实例codis-feWeb管理界面提示生产环境建议将编译好的二进制文件打包分发到各节点避免每台机器重复编译。1.3 集群初始化与启动首先启动核心管理组件dashboardnohup ./bin/codis-dashboard \ --ncpu4 \ --configdashboard.toml \ --logdashboard.log \ --log-levelWARN 配置文件dashboard.toml示例coordinator_name zookeeper coordinator_addr 192.168.1.100:2181 product_name codis-prod product_auth secure_password admin_addr 0.0.0.0:18080接着部署proxy节点建议至少2个实例做高可用nohup ./bin/codis-proxy \ --ncpu8 \ --configproxy.toml \ --logproxy.log \ --log-levelWARN proxy.toml关键配置product_name codis-prod product_auth secure_password proxy_addr 0.0.0.0:19000 admin_addr 0.0.0.0:11080通过FE界面完成集群初始化访问 http://dashboard_ip:9090创建New Group并添加Redis实例点击Rebalance Slots自动分配1024个slot2. 核心配置详解2.1 数据分片与路由配置Codis采用预分片设计默认将数据划分为1024个slot。通过crc32算法计算key的slot位置def slot(key): if { in key: # 支持hash tag beg key.find({) end key.find(}, beg1) if end beg: key key[beg1:end] return crc32(key) % 1024重要配置参数backend_ping_periodproxy与redis心跳间隔默认5秒session_max_timeout客户端连接超时默认1800秒session_max_pipeline单个连接最大pipeline数量默认10242.2 高可用配置方案推荐的高可用架构Client → HAProxy → [Proxy1, Proxy2] → [Group1-Master → Group1-Slave] [Group2-Master → Group2-Slave]通过哨兵实现自动故障转移./bin/codis-admin --dashboard127.0.0.1:18080 \ --sentinel-add --addr127.0.0.1:26379关键监控指标ProxyQPS、连接数、延迟百分位Redis内存使用、命中率、持久化状态Zookeeper节点健康状态3. 核心原理深度解析3.1 请求路由机制当客户端发送命令到Proxy时路由流程如下解析命令中的key支持MGET等多key命令对每个key计算slot编号查询路由表获取目标Group转发命令到对应Redis实例聚合多个key的结果返回客户端路由表结构示例{ slot_0: group_1, slot_1: group_2, ... }3.2 数据迁移原理Codis支持三种迁移模式同步迁移阻塞式适用于小数据量异步迁移非阻塞大数据量场景并发迁移多slot并行迁移迁移状态机流程PREPARE → START → SYNC → DEL → FINISH关键迁移指令# 迁移slot 0-511到group2 codis-admin --slot-migrate --from1 --to2 --slots0-5113.3 故障恢复流程当Master宕机时哨兵检测到节点不可用触发failover选举新Master更新Zookeeper路由信息所有Proxy同步新路由表客户端连接自动切换到新Master手动恢复节点步骤# 下线故障节点 codis-admin --server-remove --group1 --addr127.0.0.1:6379 # 添加修复后的节点 codis-admin --server-add --group1 --addr127.0.0.1:6379 --roleslave4. 生产环境最佳实践4.1 性能调优指南Proxy层优化调整--ncpu参数匹配物理核心数增大session_max_bufsize默认128KB启用jemalloc内存分配器Redis层优化# 修改codis-server配置 maxmemory 16gb maxmemory-policy allkeys-lru activerehashing yes4.2 常见问题排查数据不一致排查检查迁移过程中是否有写入验证CRC32算法计算结果对比slot映射关系性能瓶颈定位# 查看proxy延迟分布 curl http://proxy_ip:11080/api/debug/pprof/histogram # 监控redis慢查询 ./bin/codis-admin --slowlog --group14.3 版本升级策略从Codis 2.x升级到3.x的步骤导出旧集群配置使用转换工具迁移配置逐步替换proxy节点验证数据一致性下线旧版本组件我在实际运维中发现迁移过程中保持proxy版本一致非常重要曾经因为版本混用导致路由表同步失败。建议先在测试环境验证完整升级流程。