企业官网建设流程全解析

Valkey 集群从零到可用：create-cluster 一键部署与运维手册

【免费下载链接】placeholderkvA flexible distributed key-value database that is optimized for caching and other realtime workloads.项目地址: https://gitcode.com/GitHub_Trending/pl/placeholderkv

Valkey 是面向缓存优化的分布式键值数据库。本文用官方自带的 create-cluster 脚本演示 Valkey 集群部署全流程：拉起 6 节点、搭建 3 主 3 从、验证读写重定向。

为什么用 create-cluster 部署 Valkey 集群

手动搭建 3 主 3 从意味着写 6 份配置、起 6 个实例、人工规划 16384 个哈希槽的归属、再逐对绑定主从，动辄一小时起步，中途任何一步写错都要推倒重来。换成 create-cluster 脚本后，start把所有实例拉起来，create自动完成槽位划分和主从配对，整个过程可以用同样的命令反复执行，出错也能清掉重来。

开工前确认：编译产物、端口与参数覆盖

脚本头部 Settings 区定义了默认参数：

CLUSTER_HOST=127.0.0.1 # 集群节点间通信地址，容器或跨机部署时改成本机实际 IP PORT=30000 # 起始端口，节点实际监听 PORT+1 到 PORT+NODES NODES=6 # 节点总数，构成 3 主 3 从架构 REPLICAS=1 # 每个主节点绑定的从节点数 TIMEOUT=2000 # cluster-node-timeout，毫秒，故障判定的时间基准

开跑之前确认三件事：

• 编译产物：脚本通过BIN_PATH调用src/valkey-server和src/valkey-cli，先确认源码已编译、这两个文件存在。
• 端口占用：默认 6 个实例占用 30001–30006，任一端口被占都会导致对应实例起不来，提前用ss -lntp之类的手段扫一遍。
• 参数覆盖：不建议直接改脚本正文。把要改的变量写进脚本同目录的config.sh，脚本启动时会自动source它，PORT、CLUSTER_HOST这类改动放这里最干净。

把集群跑起来：从一键启动到读写验证

拉起 6 个节点并分配槽位

进入脚本目录执行 start，六个实例以守护进程方式全部拉起，每个实例在自己的工作目录里生成 nodes-{port}.conf、{port}.log、dump-{port}.rdb 和 appendonly 文件：

cd utils/create-cluster ./create-cluster start

节点拉起来之后，下一步是把它们组织成主从拓扑。这条命令包装了valkey-cli --cluster create，把 6 个地址交给 CLI，由它把 16384 个槽均匀切给 3 个主节点、每个主节点配 1 个从节点；-f参数跳过交互确认：

./create-cluster create -f

创建成功时，输出末尾会汇总每个节点的角色和槽位数量，全部槽位总和应为 16384。想看各节点实时状态，watch 会循环打印首个节点的cluster nodes前 30 行，每秒刷新一次：

./create-cluster watch

验证集群读写与 MOVED 重定向行为

拓扑就绪不等于链路通，还要用真实命令验证数据路径。-c参数让客户端以集群模式工作：key 所属槽位不在当前节点时，客户端收到 MOVED 后会自动跟随跳转，正常输出长这样：

$ src/valkey-cli -c -p 30001 127.0.0.1:30001> set testkey cluster-demo -> Redirected to slot [6918] located at 127.0.0.1:30005 OK 127.0.0.1:30005> get testkey "cluster-demo"

第一次set被 MOVED 转发到 30005，紧随其后的get直接在 30005 执行，不再二次跳转——这就是健康状态。如果看到裸露的 MOVED 报错而客户端没有跟随，先确认-c是否传了，再检查对应槽位节点的 connected 状态。

日常运维速查：启停、日志跟踪与常见故障

集群跑起来后，日常操作基本就是下面这张表里的命令循环，全部在utils/create-cluster/目录下执行：

完整命令清单见同目录 README。

哈希槽分配与故障切换机制的 30 秒版本

这套命令背后的机制并不复杂：Valkey 集群把键空间固定划分为 16384 个哈希槽，key 落在哪个槽由 CRC16(key) 对 16384 取模决定，{tag}形式的 hashtag 可以强制多个 key 同槽。create阶段把槽位均分给主节点并绑定从节点，所以建完拓扑后槽位总和必须回到 16384。节点之间通过 gossip 消息交换视图，超时窗口由cluster-node-timeout控制，失联节点被多数节点标记为故障后，其从节点接管槽位，这就是集群故障切换的全部。

走向生产还需要什么

这个脚本的定位是开发测试与小规模集群，往生产环境走至少要补齐三件事：

• 参数调优：把 maxmemory、淘汰策略、bind 地址等生产参数经config.sh的ADDITIONAL_OPTIONS注入，或干脆改用正式的 valkey.conf 管理实例，脱离脚本形态。
• 监控接入：周期采集各节点的INFO与cluster nodes，对故障判定、槽位迁移、内存水位设置告警，别依赖人肉盯 watch。
• 编排接管：跨机器部署交给 Ansible、Kubernetes Operator 或云厂商的集群服务，单机多实例形态覆盖不了多机网络拓扑。

在正式承接流量之前，值得在预发环境完整演练一次从节点接管和整库恢复，确认 failover 与数据恢复路径都是可用的。

【免费下载链接】placeholderkvA flexible distributed key-value database that is optimized for caching and other realtime workloads.项目地址: https://gitcode.com/GitHub_Trending/pl/placeholderkv