如果直接把本地调好的 Redis 参数搬到 Linode 云主机上，高并发场景下很可能出现吞吐量上不去、延迟周期性飙升的问题。云主机和物理机在 CPU 调度、磁盘 IO 以及网络虚拟化上的差异，会放大 Redis 单线程命令处理模型的瓶颈。因此这次评测不只看 Redis 本身能跑多快，更关注 Linode 不同实例类型下，持久化、连接数和系统参数对高并发表现的干扰。
一、测试环境与Linode实例差异
测试使用两台 Linode 主机：一台是 4GB 共享 vCPU 实例，另一台是 8GB 专用 vCPU 实例。操作系统均为 Ubuntu 22.04，Redis 版本为 7.0.12，默认绑定 127.0.0.1，未设置密码。为了保证数据落盘行为一致，两台实例都关闭了透明大页，并将 overcommit_memory 设置为 1，避免 fork 子进程时因内存分配失败导致 RDB 持久化异常。
共享实例和专用实例的核心差异在于 CPU steal。共享实例的 vCPU 与其他租户共享物理核，当同一物理机上的邻居负载升高时，Redis 进程可获得的 CPU 时间会被压缩，表现为明明 QPS 不高，但延迟突然增加。专用实例则没有这个问题，评测中 8GB 专用实例的 CPU steal 长期保持在 0%，更适合对延迟敏感的业务。内存带宽方面，专用实例也有更稳定的表现，特别是大对象读写时会拉开差距。
安装 Redis 7 可以直接使用官方源，也可以从源码编译。这里用 apt 安装，省去编译时间。安装完成后先确认版本，再检查默认配置中的关键项。
apt-get update apt-get install -y redis-server redis-server --version redis-cli ping
默认配置里 bind 127.0.0.1 只允许本机访问，评测阶段够用；但 protected-mode yes 和 daemonize yes 要提前确认，避免压测时被拒绝连接。还需关注 maxmemory，如果不设置上限，Redis 可能把整机内存占满，触发 OOM。测试前将 4GB 实例的 maxmemory 设置为 3GB，8GB 实例设为 6GB，并采用 allkeys-lru 策略。
二、高并发压测方法与关键数据
压测工具选择 redis-benchmark，它是 Redis 自带的基准测试命令，支持指定并发连接数、请求总数和数据大小。为了避免单个测试进程自身成为瓶颈，压测在另一台同机房的 Linode 主机上执行，网络延迟控制在 1 毫秒以内。先跑一组 500 并发、200 万请求的 SET 和 GET 基准测试。
redis-benchmark -h TARGET_IP -p 6379 -c 500 -n 2000000 -t set,get -q
该命令会依次执行 SET 和 GET 测试，-c 表示 500 个并发客户端，-n 表示每个测试的请求总数，-q 只输出简要结果。测试结果里需要重点看两个指标：一是 requests per second，也就是 QPS；二是平均延迟。注意 redis-benchmark 默认使用随机 key，写入后会覆盖，不会因为 key 过多导致内存膨胀。
第一次数据：4GB 共享实例 SET 约为 7.8 万 QPS，GET 约为 8.1 万 QPS；8GB 专用实例 SET 约为 11.6 万 QPS，GET 约为 12.4 万 QPS。仅看平均数字，专用实例领先约 40%，但真正的差距在长尾延迟。用 2000 并发连接重跑后，共享实例 P99 延迟从 1.8 毫秒上升到 12 毫秒以上，而专用实例仍控制在 3 毫秒以内。这说明高连接数下共享实例的 CPU 调度和网络中断处理开始出现拥塞。
为了更接近真实业务，再用自研的多线程脚本模拟 10 个线程、每个线程维护 300 个连接，随机执行 80% GET 和 20% SET，Value 大小为 512 字节。这个场景下共享实例在测试开始 60 秒后延迟曲线明显上翘，最大延迟超过 80 毫秒；专用实例延迟曲线平稳，P99 保持在 2 毫秒附近。该差异与 Linode 文档中提到的共享实例网络突发额度有关，长时间高吞吐会触发网络限速。
三、瓶颈定位与调优建议
从压测数据看，高并发 Redis 的瓶颈通常不是 Redis 单线程命令处理，而是系统层和持久化层。先检查 fork 耗时。开启 RDB 快照时，Redis 需要 fork 子进程保存内存快照，如果内存较大，fork 会造成数百毫秒甚至秒级的阻塞。评测中开启 save 900 1 后，8GB 实例在 fork 时 P99 延迟会瞬间跳到 40 毫秒以上。对高并发业务，建议关闭自动 RDB，改用 AOF everysec 或混合持久化。
# redis.conf 关键调整 appendonly yes appendfsync everysec save "" maxclients 20000 tcp-backlog 65535 io-threads 4 io-threads-do-reads yes
这里 save "" 表示禁用自动 RDB，如果需要定期快照，可以在业务低峰手动执行 BGSAVE。AOF everysec 每秒同步一次，最多丢失一秒数据，对性能影响远小于 RDB fork。开启 io-threads 后，Redis 的网络读写和命令解析可以并行处理，但命令执行仍然是单线程，因此不要盲目把线程数调得超过物理核数。8GB 专用实例设 4 个 IO 线程效果最好，再增加反而会因为线程切换增加 CPU 开销。
连接数也需要从系统层配合调整。tcp-backlog 决定内核监听队列长度，默认值 511 在高并发新建连接时容易溢出。除了修改 redis.conf，还要调整系统参数 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog。另外检查文件描述符限制，ulimit -n 至少设置为 65535，否则连接数超过 1024 就会报错。
如果使用的是共享实例，压力测试中建议限制并发连接数在 2000 以内，并为 Redis 预留至少一个完整 CPU 核的余量，避免 CPU steal 影响延迟。监控时可以用 top 观察 %steal 字段，如果持续高于 5%，说明宿主机负载较高，应该考虑迁移到专用实例或调整可用区。对于核心业务的高并发缓存，推荐直接选择 Linode 专用实例，成本增加有限，但延迟和吞吐稳定性会好很多。