如果你的 Redis 内存已经涨到几百 GB单靠扩容硬件成本开始不划算的时候就会特别在意能不能把冷数据从内存里挪走。我是在一次订单缓存集群内存告警的时候开始接触腾讯开源的 tendis在 Linux 服务器上把它编译安装起来用来替代一部分 redis 的纯内存存储。这篇文章就是那次落地的完整记录。tendis 是什么一句话它是兼容 redis 协议、底层用 RocksDB 做持久化存储的 KV 服务。redis 把数据放在内存里tendis 把数据放在磁盘上但客户端不需要改协议连接方式还是 redis 那套。适合读多写多、单个 value 不大、总量很大的数据场景。这篇内容适合谁正在被 redis 内存成本和容量上限困扰的开发和 DBA想在大数据量场景里做冷热分离但不想换整套缓存架构的团队以及和我一样拿到一个新存储引擎就习惯从源码编译开始折腾的 Linux 运维。我会把编译安装、配置项、主从验证、命令差异和上线前的注意事项完整过一遍。1. 为什么大容量缓存场景盯上了 tendis1.1 Redis 内存瓶颈是真实存在的先说一个反直觉的现象Redis 在大多数团队里跑得好好的问题不是出在读写性能上而是出在容量上。一台 64 GB 内存的服务器去掉系统占用和必要的缓冲能分配给 Redis 的上限大概在 50 GB 左右。数据量一旦超过这个数常规操作就变成两条路要么换更大内存的机器要么上集群分片。集群分片本身不复杂但会让业务层开始考虑 key 分布、批量操作、事务边界、pipeline 拆分这些事。换更大内存的机器更直接但成本曲线非常陡内存价格下不来而且单机内存堆到 256 GB 之后RDB 持久化时的 fork 阻塞时间和主从全量同步时的网络压力都会变成一个隐形炸弹。我当时遇到的场景是整个集群的 value 以 JSON 字符串和计数型字段为主80% 的 key 在 7 天之后就不会再被读取但业务规则要求保留 30 天。这意味着集群里躺着大量该留但不能占内存的数据Redis 完全没有办法区分热冷只能一视同仁地放在内存里。1.2 tendis 做的事情协议兼容加存储引擎替换tendis 的思路很直接把 Redis 的一切数据驻留内存改成内存做热层磁盘做主要存储。它对外保持 Redis 协议兼容包括 RESP 协议、常用命令、主从复制流程但在数据落地层面把内存里的全量数据结构换成了 RocksDB 存储引擎。RocksDB 是 Facebook 开源的高性能嵌入式 KV 存储基于 LSM-Tree写入路径是顺序写内存表memtable再异步落盘所以写性能在机械硬盘或 SSD 上都能维持一个不错的水位。tendis 利用这个特性把每个 Redis key 映射成 RocksDB 里的记录value 序列化后存盘。这样做的好处非常明显内存不再存放全量数据只承担热数据和 RocksDB 的块缓存一台 32 GB 内存的机器就可以承载原本需要 200 GB 内存的数据量。缺点是读路径比纯内存多了一次磁盘 IO所以命中率高的热数据性能会有下降冷数据反而无所谓。1.3 替代不等于简单换包很多第一次接触 tendis 的人会有个错觉既然协议兼容那我把 redis-server 进程换成 tendis 进程端口和密码一配业务代码不用动这不就行了吗实际没有那么简单。tendis 的命令集合、过期机制、持久化过程和主从同步细节和原生 redis 有差异尤其是涉及阻塞命令、事务、Lua 脚本这类特性的功能需要提前在测试环境过一遍。我后面会单独用一节把差异列清楚这里先记住一个结论tendis 适合作为大容量 KV 存储来用不适合作为远古 Redis 特性全家桶来用。2. Linux 环境准备与源码编译安装2.1 编译环境和依赖确认tendis 的开源代码托管在 GitHub 的 Tencent/Tendis 仓库里我以存储版standalone 模式为准来说明。整个项目用 C 编写编译依赖包括 cmake、gcc、g、make另外还需要安装一些系统基础库比如 libtool、autoconf、jemalloc 相关的开发包。我第一次编译时踩了个坑使用的 CentOS 7 自带的 gcc 版本是 4.8.5在编译 RocksDB 相关模块时直接报错提示需要支持 C17 的编译器。tendis 的源码对编译器版本是有要求的尤其是 RocksDB 的新版本代码会用到较新的 C 标准特性。建议在编译前先确认一下系统版本和工具链版本。cat /etc/os-release gcc --version g --version cmake --version如果你的环境是 Ubuntu 20.04 或 CentOS 8 以上gcc 默认版本在 9.x基本够用。如果还是 CentOS 7 这类老环境建议先安装 devtoolset 或者直接换一台较新的系统避免在编译中间环节被编译器版本卡住浪费大量时间。2.2 拉取代码与编译操作代码克隆建议使用 --recursive 参数因为 tendis 依赖了 RocksDB 等第三方组件这些组件是以 submodule 形式挂进来的。如果漏掉这个参数编译时会因为缺少 thirdparty 目录下的代码而直接失败。git clone --recursive https://github.com/Tencent/Tendis.git cd Tendis进入目录后项目的 README 里有明确的编译说明。存储版核心是执行编译脚本./build.sh这个脚本会依次完成依赖检查和 RocksDB 编译然后再编译 tendis 主程序。整个过程比较耗时我在一台 8 核 16 GB 的机器上编译了差不多 40 分钟其中 RocksDB 的部分占了大部分时间。如果机器的 CPU 核数较多可以手动修改脚本增加并行任务数但要注意内存也别压得太满否则 GCC 在编译大文件时可能被 OOM killer 干掉。编译完成后可执行文件通常会生成在项目的 build 目录下。需要关注的产物至少有两个tendis 主程序和 tendis-cli 客户端工具。find . -type f -name tendis* -executable2.3 初始化目录与基础配置准备拿到可执行文件之后建议按照标准 Linux 服务方式组织目录结构不要直接把数据写在源码目录里后续升级维护会方便很多。mkdir -p /data/tendis/bin mkdir -p /data/tendis/conf mkdir -p /data/tendis/data mkdir -p /data/tendis/log将编译好的 tendis 可执行文件复制到 bin 目录把源码里的示例配置复制到 conf 目录。接下来要做的就是修改配置文件这也是我第一次接触 tendis 时最容易迷惑的地方。3. 配置文件里不能照抄 Redis 的那几处3.1 绑定地址、端口与密码tendis 的配置项命名和 redis.conf 有很大相似性比如 port、bind、requirepass 这些一眼就能看懂。如果只是单机测试可以把 bind 设为 127.0.0.1避免服务直接暴露到公网。生产环境如果必须开放到内网务必设置好 requirepass 和防火墙策略。port 6380 bind 127.0.0.1 requirepass your-strong-password需要特别注意的是tendis 的配置文件格式是 key-value 式的文本每行一个配置项和 redis.conf 风格一致。修改完配置后建议先做一次语法检查似的启动测试确认没有因配置项名称拼写错误导致的启动失败。3.2 RocksDB 存储路径与块缓存参数这是 tendis 配置里和 redis 差异最大的一块。Redis 只需要关心 dir 一个目录参数tendis 则需要关注多个 RocksDB 实例相关的路径和缓存参数。默认配置里会有一组以 rocks 开头或包含 rocksdb 字样的参数比如rocksdb_dir /data/tendis/data/db rocksdb_wal_dir /data/tendis/data/wal rocksdb_cache_size 4GBrocksdb_dir 是最终数据落盘的目录rocksdb_wal_dir 是预写日志目录。生产建议把两者放在不同磁盘上这样 WAL 的写入不会和数据文件的 compaction 抢 IO遇到磁盘故障时恢复能力也会好一些。rocksdb_cache_size 这个参数决定块缓存大小直接影响热数据的读性能。建议把系统可用内存的 1/4 到 1/3 分配给它剩余内存留给操作系统页缓存因为 RocksDB 本身就依赖系统页缓存加速读操作并不是说 cache_size 设置得越大越好。3.3 复制与同步相关参数tendis 支持主从复制配置参数名称和 redis 基本一致replicaof master-ip master-port masterauth master-password repl-timeout 60但在同步机制上有一个重要区别Redis 的主从同步基于 RDB 文件而 tendis 的全量同步是基于 RocksDB 的文件快照机制本质上是对底层存储文件做拷贝/硬链接。这意味着全量同步时的磁盘空间占用、IO 压力和同步耗时都和你落盘的数据量直接相关而不仅是内存里有多少数据。配置 replication 相关参数时一定要给从节点的数据目录预留足额空间。我曾经因为从节点磁盘空间不够触发过全量同步中断后反复重试的情况最终解决方式是先扩容再从配置文件里去掉 replicaof 重启等手动全量拷贝完成后再挂主从关系。4. 启动、主从复制与基础读写验证4.1 单机启动与进程检查配置完成后先用前台方式启动一次观察日志输出是不是正常。这一步非常关键因为后台启动时很多报错只会写进日志文件不如前台启动看得直观。./tendis /data/tendis/conf/tendis.conf如果能看到类似 server started 或 ready to accept connections 的日志再按 CtrlC 停掉改用 systemd 或 nohup 方式后台启动。我习惯用 systemd 来管理这类服务进程守护、开机自启、崩溃拉起都能覆盖到。写一个最简单的 service 单元文件大概长这样[Unit] DescriptionTendis Server Afternetwork.target [Service] ExecStart/data/tendis/bin/tendis /data/tendis/conf/tendis.conf Usertendis Grouptendis Restarton-failure LimitNOFILE65535 [Install] WantedBymulti-user.target启动后用 redis-cli 做一次 pingredis-cli -p 6380 -a your-strong-password ping能返回 PONG说明服务进程和网络监听都没有问题。4.2 主从搭建与同步状态观察主从搭建的方式和 Redis 很像在从节点的配置文件里配置 replicaof 指向主节点即可。启动从节点之后通过在从节点上执行 redis-cli 命令可以看到复制状态redis-cli -p 6381 -a password info replication在输出中重点看 role、master_link_status 和从节点的同步进度字段。master_link_status 为 up 说明主从链路建立成功如果长时间处于 down需要检查网络、密码和 masterauth 配置同时查看从节点的日志确认是否有重复的全量同步失败记录。我实际观察下来tendis 的全量同步一旦触发从节点 log 目录会产生大量的文件拷贝日志。这时候要关注从节点机器的磁盘 IO 和网络吞吐建议全量同步安排在业务低峰期执行否则主节点的 IO 会被明显拉高影响正常请求。4.3 用 redis-cli 做基础读写验证主从都起来后用 redis-cli 分别对主节点和从节点执行简单的写入与读取redis-cli -p 6380 -a password set user:10001 hello tendis redis-cli -p 6380 -a password get user:10001 redis-cli -p 6381 -a password get user:10001从节点能读到主节点写入的数据说明基本链路是通的。这时候我建议多试几类数据结构不要只测 string。我在第一次验证时重点测了 hash、set、zset 这三类因为业务中使用频率最高。redis-cli -p 6380 -a password hset order:20001 field1 value1 field2 value2 redis-cli -p 6380 -a password hgetall order:20001 redis-cli -p 6380 -a password sadd tag:10001 tag-a tag-b redis-cli -p 6380 -a password smembers tag:10001 redis-cli -p 6380 -a password zadd score:30001 90 userA 85 userB redis-cli -p 6380 -a password zrange score:30001 0 -1 withscores如果这些命令都能正常返回说明基础数据结构的读写链路是可用的。接下来就要老老实实地看差异清单了。5. 和原生 Redis 的差异清单哪些命令能用哪些必须绕道5.1 命令支持矩阵的实测结果tendis 并没有实现 Redis 的所有命令这一点在官方文档里写得很清楚但实际测试之后感受更直接。我把业务里高频使用的命令列成了一个矩阵实测结果如下命令类别典型命令实测结果备注基础 KVSET、GET、DEL、EXISTS支持和 Redis 行为一致HashHSET、HGET、HGETALL、HDEL支持大 key 场景下 HGETALL 耗时偏长SetSADD、SMEMBERS、SISMEMBER支持数据量大时 SMEMBERS 注意阻塞ZSetZADD、ZRANGE、ZRANGEBYSCORE支持和 Redis 行为基本一致ListLPUSH、RPUSH、LRANGE支持阻塞版本 BLPOP 不支持Key 管理KEYS、SCAN部分支持KEYS 性能差尽量用 SCAN过期EXPIRE、TTL、PEXPIRE支持过期粒度有差异阻塞队列BLPOP、BRPOP不支持需要换方案事务MULTI、EXEC有限支持建议业务层规避LuaEVAL、EVALSHA不支持/受限需要改造这张表可能和你期望的有出入但这就是 tredis 替代 redis 时需要面对的现实越依赖 Redis 高级特性的代码迁移成本越高。5.2 持久化和淘汰机制的差异Redis 持久化有 RDB 和 AOF 两种tendis 的数据天然就是落盘的所以不存在开启持久化后 fork 阻塞的问题。这是它的优势但也带来一个新问题底层 RocksDB 在后台会做 compaction把多层 LSM-Tree 文件合并整理这个过程会消耗磁盘 IO 和 CPU。业务低峰期 compaction 影响不大但高峰期如果磁盘 IO 本身就很紧张就需要关注 compaction 对读写延迟的拖累。可以通过配置调整 RocksDB 的 compaction 线程数和触发阈值推荐参考官方参数说明先小步调整观察延迟曲线。过期机制上Redis 是惰性删除加周期性采样删除tendis 的过期处理也提供了类似能力但因为底层存储是磁盘过期 key 的清理频率和 Redis 不同。实测中发现如果短期内写入大量带过期时间的 keytendis 的已过期 key 可能不会像 Redis 那么快地物理消失从内存占用看问题不大但从 key 数量统计看会比较吓人。需要给监控系统做过滤别因为 expire 数量没立即降下来就误判为故障。5.3 客户端兼容性实际测试业务方最关心的问题通常是我换 tendis 之后现有 Java/Go 客户端还能不能用我测试了 Java 的 Jedis、Lettuce 和 Go 的 go-redis结论是只要不调 tendis 不支持的命令客户端完全不需要改配置连接方式、连接池参数、认证流程都和连 Redis 一样。问题集中在那些看起来有返回但行为不同的地方例如使用 Lua 脚本做原子性操作的场景在 tendis 上可能直接报错导致线上请求失败。所以强烈建议在迁移前做一个命令扫描把业务代码和慢日志里出现的所有 Redis 命令提取出来和 tendis 的命令支持列表比对一遍生成一个不兼容清单。这一步做扎实了后期踩坑会少很多。6. 替换上线前必须想清楚的五件事6.1 先想清楚冷热分层规划tendis 不是用来替代所有 Redis 场景的它的优势是容量劣势是单次读延迟比纯内存高。上线前一定要把业务数据按访问频率分层热点数据留在 Redis 里扛住大部分请求。温冷数据迁到 tendis降低内存成本。需要短 TTL 的数据优先留 Redis因为 tendis 的过期清理机制更适合长期存储。我这边最终的架构是 Redis 和 tendis 并存业务侧先读 Redismiss 后再读 tendistendis 的数据通过异步回填机制写回 Redis。这个分层方案既保住了热数据的性能又解决了容量问题。6.2 监控指标要重新定义Redis 监控里最核心的内存指标 used_memory 和 mem_fragmentation_ratio在 tendis 里仍然存在但含义已经变了tendis 的内存主要被 RocksDB 的块缓存和 memtable 占用不能简单地认为 used_memory 上涨就是异常。真正需要盯的是磁盘使用率、磁盘 IO 延迟、compaction 状态、读放大倍数、WAL 目录增长速度这些新指标。我们当时用 Prometheus 加了 node_exporter 层面的磁盘数据采集同时解析 tendis info 输出里的 rocksdb 相关字段用 Grafana 单独做了一块监控面板和原生 Redis 的内存监控面板并列。6.3 容量评估要按磁盘算不是按内存算迁移前一定要把数据体积估算清楚。Redis 里一个 1 KB 的 JSON value在内存里占用的实际空间可能是 2 KB 甚至更多因为有 SDS、dictEntry、内存碎片这些开销。tendis 落盘后同样一个 key 在 RocksDB 里的存储开销也不止 1 KB再加上 LSM-Tree 的写放大和空间放大磁盘空间通常需要按逻辑数据量的 1.5 到 2.5 倍来预留。我当时按照现有 Redis 内存使用量 * 0.6作为预估的磁盘数据量再乘 2 留出 compaction 余量最终给每个 tendis 节点挂载了充足的 SSD 空间。测了一个月之后发现这个估算基本靠谱略微富余了一些但多出的空间不算浪费。6.4 从 Redis 迁移到 tendis 的数据搬移方案存量数据迁移是绕不开的。tendis 没有官方的开箱即用迁移工具最稳妥的方式是走双写加历史数据扫描回填先在业务层做双写新写入数据同时写 Redis 和 tendis。用 redis-cli 的 SCAN 配合 MIGRATE或者写一个简单的解析 RDB 文件的小工具把历史核心数据回灌到 tendis。切换读流量从 Redis 切到 tendis。观察一段时间确认数据一致后逐步下线 Redis 集群中的冷数据分片。这个方法不需要业务停机但需要和业务团队提前对齐双写逻辑的改动范围。我们当时用一个轻量级 MQ 异步做双写避免双写逻辑拖慢主链路。6.5 回归测试要覆盖极端场景上线前一定要做故障演练至少覆盖三种场景主节点进程被杀观察从节点能否快速切换、手动提升后数据是否一致。磁盘写满观察 tendis 是拒绝写入还是直接崩溃。网络分区恢复观察主从重新同步是走增量还是全量。我们实测中发现tendis 在磁盘写满时进程不会自动退出但会有大量的写入报错如果不提前设置磁盘水位告警业务会先于监控发现问题这是非常危险的。所以磁盘容量告警的阈值一定要设得保守一些我建议 70% 就开始告警85% 就要强制介入处理。6.6 回归测试之外还要注意内核参数的微调tendis 属于 IO 密集型服务Linux 内核的文件句柄上限和网络 backlog 参数最好提前调大。Redis 默认连接数不高时不需要特别处理但 tendis 因为承载的数据量更大客户端连接数往往更多。在 /etc/sysctl.conf 里这几个参数是我调整过并且验证有效的net.core.somaxconn 1024 net.ipv4.tcp_max_syn_backlog 4096 vm.swappiness 10vm.swappiness 调整为 10 我主要用于避免内存页被过度换出因为 tendis 依赖内存做块缓存如果系统频繁 swap读性能会直线下降。调整后执行 sysctl -p 生效。整个替换过程做下来我的体会是tendis 不是 redis 的完美替代品但它确实解决了一个真实存在的成本问题。只要你愿意在命令兼容性上做一些适配在监控体系上做一些调整它完全可以在大容量存储场景里替 redis 扛下一大块压力。最后再分享一个小经验如果你只是单纯想省内存优先考虑给 redis 加冷热分层而不是直接把所有 redis 换成 tendis如果你明确知道自己的数据量会持续增长那几个月的迁移阵痛期是值得的。