
DragonflyDB 部署与运维实战从单实例跑通到高可用集群【免费下载链接】dragonflyA modern replacement for Redis and Memcached项目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly业务要用 Redis但数据量涨上去之后单节点内存上限和成本都扛不住。DragonflyDB 是一个兼容 Redis 和 Memcached 协议的内存数据库现有客户端代码基本不用改可以直接替换上线。下面按上线任务线走一遍拉镜像、配生产参数、扩集群、盯指标、兜底备份。一、五分钟快速上手从拉镜像到 ping 通最短路径就是docker run两条命令镜像默认同时开 6379Redis和 11211Memcached端口# 官方镜像启动memlock-1 必须加否则大内存下性能明显下降 docker run -d --name dragonfly --networkhost \ --ulimit memlock-1 docker.dragonflydb.io/dragonflydb/dragonfly # 验证连通性返回 PONG 即可用 redis-cli -p 6379 ping生产上一般用 Compose 管理仓库里有一份现成配置可参考contrib/docker/docker-compose.yml。二、上线前清单生产环境必做的 4 件事 上线前把这四件事过一遍每项对应下面这张参数表按「参数 / 默认值 / 建议值 / 不这样配会怎样」来核对认证与 TLS没密码的实例等于裸奔内网也建议开启内存与资源给进程一个明确的内存上限别让它把宿主机吃光数据持久化快照目录必须落在宿主机可挂载的位置健康检查官方镜像自带检查脚本用 nc 发 PING 探测端口见 tools/docker/healthcheck.sh在 Compose 里启用即可不用自己写参数默认值生产建议值不这样配会怎样requirepass空强密码无认证网络内任何人可读写tls_cert_file / tls_key_file空挂载有效证书流量明文可被中间链路嗅探maxmemory自适应系统内存 70%~80%无驱逐上限进程被 OOM Killproactor_threads全部核心对齐物理核数超分导致上下文切换开销变大dir / dbfilename空 / 带时间戳文件名独立磁盘目录快照落在容器层重建即丢admin_port与业务同端口独立端口并绑定 127.0.0.1管理接口暴露给业务流量证书可以不用手搓仓库提供了生成脚本 tools/generate-tls-files.sh。三、规模上来之后集群模式与高可用先划清边界两种模式选错后面全白做emulated 模式cluster_modeemulated每个节点保存全量数据客户端按单节点方式连接适合用多节点横向扩吞吐、但单节点放得下全部数据的场景real cluster 模式cluster_modeyes数据按 16384 个槽位分片到各节点客户端必须用集群感知连接适合总量超过单节点内存的场景关键参数参数默认值建议值说明cluster_modenoemulated 或 yes先定模式再扩节点cluster_node_id自动生成固定标识重启后节点身份不漂移cluster_announce_ip本地回环 IP内网可达 IP配错则其他节点无法连回announce_port与 port 一致实际对外端口NAT 或端口映射环境必须显式设置组集群用官方脚本 tools/cluster_mgr.py# 本地建 3 主 每主 1 副本的集群 python3 tools/cluster_mgr.py --actioncreate_locally --num_masters3 --replicas_per_master1复制与故障转移副本端执行REPLICAOF跟上主节点异步复制、秒级追平主节点挂掉后把最健康的副本执行REPLICAOF NO ONE提升为新主再把业务连接切过去。集群细节可进一步看 docs/cluster-mode.md。四、日常运维真正需要盯的监控指标指标从管理端口的/metrics拉取Prometheus 格式。全量指标不用看下面 7 个是半夜会叫醒你的指标建议阈值含义dfly_used_memory超过 maxmemory 90%内存逼近上限驱逐即将开始dfly_evicted_keys持续 0热 key 正在被逐出缓存实际失效dfly_client_connections超过 maxclients 80%连接泄漏或流量洪峰前兆dfly_rejected_connections任何增长新连接已在被拒绝复制偏移差 / 复制积压落后数秒或积压超 10MB副本追不上故障切换会丢数据进程 uptime 归零出现即告警进程重启过先查 OOM 与日志快照写入耗时超过 5 分钟备份窗口撑不住恢复点会漂移五、数据兜底备份与恢复怎么做定时快照一行命令就够# 每天 03:00 自动快照文件带时间戳落在 dir 指定目录 dragonfly --snapshot_cron0 3 * * * --dir/data/dump恢复流程起一个新实例--dir指向存有快照的目录启动时会自动加载最新一份快照无需手动 restore恢复完成后让副本重新REPLICAOF跟上即可。⚠️ 高频踩坑点快照只和它落盘的位置一样可靠。如果 dir 指向容器匿名卷重建容器快照就没了务必挂载命名卷或宿主机目录并定期验证一次「从快照起新实例」的恢复演练。六、常见坑 FAQQdocker run报端口被占用先用ss -ltnp查 6379 是否已被 Redis、11211 是否被 Memcached 占用用--port/--memcached_port换端口即可客户端同步改连接串。Q重启后数据少了内存库本来就只保内存中的数据崩溃或重建会丢未落盘部分。配置snapshot_cron并挂载数据卷后丢失窗口可压缩到最近一次快照之内。Q副本读明显滞后看复制偏移与主节点写入速率写压力大时副本必然有延迟。读多写少的工作负载放副本对实时性敏感的业务仍走主节点。【免费下载链接】dragonflyA modern replacement for Redis and Memcached项目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考