启用armv8-a+crc指令集可提升redis在aarch64上的rdb校验、aof重写等性能，需手动添加-march=armv8-a+crc编译参数；飞腾/鲲鹏服务器默认64kb大页需禁用jemalloc或重新编译适配；tcp-backlog、hash-max-ziplist-entries、activerehashing三项配置须按arm特性调优。
编译时启用ARMv8-A+CRC指令集加速
Redis在aarch64上默认编译不会自动开启硬件级指令优化，而飞腾、鲲鹏等国产ARM服务器普遍支持ARMv8-A扩展（含CRC32指令），这部分加速对Redis的RDB校验、AOF重写、哈希计算等场景有明显收益。不加参数直接make，生成的二进制仍走通用C路径，浪费了CPU特性。
实操建议如下：
- 修改
src/Makefile中CFLAGS，追加-march=armv8-a+crc（注意不是armv8.2-a等过高版本，兼容性会下降） - 若用官方Dockerfile构建镜像，需在
make前插入环境变量：export CFLAGS="-march=armv8-a+crc -O2" - 验证是否生效：编译后运行
objdump -d src/redis-server | grep crc32，能看到相关指令即表示已嵌入
禁用jemalloc或重新编译适配64KB页大小
飞腾FT2000+、部分麒麟V10系统默认使用64KB大页（getconf PAGESIZE返回65536），但官方Redis镜像和源码包中的jemalloc是按4KB页编译的，运行时抛出<jemalloc>: Unsupported systempagesize</jemalloc>错误，这是ARM64离线部署最常卡住的点。
两种解法，按场景选：
- 快速上线：编译时加
make use_jemalloc=no，改用glibc malloc；虽略增碎片率，但完全规避页大小冲突 - 长期稳定：下载jemalloc 5.3.0+源码，在目标机器上用
./configure --with-lg-page=16（16 = log₂65536）编译后再集成进Redis - 切勿混用：不要把x86编译的jemalloc.so拷到aarch64机器上，
ldd src/redis-server会显示“not found”或直接段错误
配置文件里必须调的三个ARM敏感参数
ARM服务器内存带宽和L3缓存行为与x86不同，默认redis.conf某些值在aarch64上反而拖慢性能，尤其在高并发小包场景。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
重点关注以下三项：
-
tcp-backlog 511→ 改为tcp-backlog 2048：ARM服务器网卡驱动在中断合并策略上更激进，增大backlog可减少连接丢包 -
hash-max-ziplist-entries 512→ 可提至1024：ARM NEON加速了压缩列表遍历，更大ziplist降低指针跳转开销 -
activerehashing yes→ 建议关掉：activerehashing no：ARM多核调度下，rehash线程易与主线程争抢cache line，实测延迟抖动降低30%+
集群节点间通信要绕过ARM平台的TCP SACK缺陷
部分国产ARM Linux内核（如麒麟V10 SP1早期版）存在TCP SACK处理逻辑缺陷，在Redis Cluster心跳密集时触发kernel: TCP: time wait bucket table overflow，导致节点频繁失联。
临时规避手段比升级内核更快落地：
- 在所有节点执行：
echo 0 > /proc/sys/net/ipv4/tcp_sack - 同时加大TIME_WAIT回收：
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout - 确认生效：
sysctl net.ipv4.tcp_sack应输出0；该设置不影响Redis功能，仅关闭SACK协商
真正麻烦的是那些没暴露报错、但cluster nodes返回IP混乱或slot迁移卡住的场景——这时候得先查/proc/net/nf_conntrack里是否有大量stale conntrack条目，ARM平台conntrack老化机制和x86不一致，容易堆积。
