系统：openEuler 22.03 LTS-SP1
主题：容器化部署Redis，Docker vs iSulad性能对比
一、前情回顾：继续探索openEuler的容器化
前两篇文章，我体验了openEuler 22.03 LTS-SP1的系统和容器：
上上篇：从华为云的CentOS 7换到openEuler，被它的性能惊到了。sysbench测试CPU性能提升明显，fio测试磁盘I/O也快不少，软件生态也比我想象的完善。
上一篇：发现openEuler自带iSulad容器引擎，就和Docker做了个对比。结果iSulad启动容器快了3倍（0.35s vs 1.0s），跑Nginx的QPS更是高了2倍多（32K vs 15K），daemon内存占用也只有Docker的40%（32MB vs 80MB）。虽然中间踩了不少坑（镜像拉取超时、配置文件字段错误、端口映射不支持、网络配置复杂），但最后都解决了。
今天想继续深入，用容器部署个实际应用。
Redis肯定是跑不了的——缓存、会话、消息队列，哪个项目能离开Redis呢？
关键是：既然openEuler同时支持Docker和iSulad，那我就都试试，看看用哪个部署Redis性能更好。上一篇iSulad跑Nginx快了2倍多，Redis会怎么样呢？
二、openEuler的独特优势：同时支持两种容器引擎
在开始之前，我想说说openEuler在容器化这块的一个独特优势。
大多数Linux发行版要么只支持Docker，要么需要手动编译安装iSulad。openEuler不一样：
✅ Docker可以直接装（dnf install docker）
✅ iSulad系统自带（dnf install iSulad）
✅ 两者可以共存，互不干扰
✅ 镜像格式兼容，可以共用镜像
这就给了我们很大的灵活性：
- 需要完整Docker生态？用Docker
- 追求极致性能？用iSulad
- 想对比测试？两个都用
这种灵活性在实际项目中很有价值。比如开发环境用Docker（工具链完整，调试方便），生产环境用iSulad（性能更好，资源占用更低）。
openEuler的官方资源也很完善：
好了，废话不多说，开始实战。
三、环境确认
继续用我的华为云ECS，配置和前两篇一样：
编辑
服务器配置：
- CPU：2核
- 内存：3.3GB
- 磁盘：40GB
- 系统：openEuler 22.03 LTS-SP1
- hostname：ecs-ac8f
容器引擎版本：
- Docker：18.09.0
- iSulad：2.0.18
两个容器引擎都已经装好了，前两篇文章已经配置完成（Docker配置了镜像加速，iSulad也配置了registry-mirrors）。
四、Docker部署Redis
Docker部署Redis很简单：
| Bash # 拉取Redis官方镜像 docker pull docker.io/library/redis:latest # 启动Redis容器（桥接模式，映射6379端口） docker run -d --name redis-docker \ -p 6379:6379 \ docker.io/library/redis:latest # 查看容器状态 docker ps | grep redis-docker |
编辑
容器启动成功！容器ID是6ed1e05a2026，Redis监听在6379端口。
| Bash docker stats --no-stream redis-docker |
编辑
Docker Redis容器资源占用：
- CPU：0.235%
- 内存：8.688 MiB / 3.331 GiB（0.25%）
- PIDs：6
资源占用很低，这是空载状态。
五、Docker Redis性能测试
性能测试需要用到redis-benchmark，这是Redis官方的性能测试工具。虽然我们用容器部署Redis，但测试工具还是要装到宿主机上：
| Bash # 安装Redis客户端工具（包含redis-benchmark） sudo dnf install -y redis # 验证安装 redis-cli --version |
编辑
openEuler仓库里的是Redis 4.0.14版本，够用了。安装很快，800多KB一会儿就装好了。
开始测试Docker部署的Redis性能：
| Bash # 综合性能测试：10万次请求，100并发 redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 100 -q |
编辑
Docker Redis性能数据：
| 操作 | QPS（请求/秒） |
| PING_INLINE | 100,603.62 |
| PING_BULK | 103,950.10 |
| SET | 102,354.15 |
| GET | 99,700.90 |
| INCR | 104,058.27 |
| LPUSH | 101,522.84 |
| RPUSH | 100,908.17 |
| LPOP | 110,864.74 |
| RPOP | 103,950.10 |
| SADD | 109,289.62 |
| HSET | 104,058.27 |
| SPOP | 114,942.53 |
| LRANGE_100 | 52,882.07 |
| LRANGE_300 | 23,218.02 |
| LRANGE_500 | 17,519.27 |
| LRANGE_600 | 13,426.42 |
| MSET (10 keys) | 78,926.60 |
点击图片可查看完整电子表格
基本操作（SET/GET/INCR）的QPS在10万左右，对于2核3.3GB的服务器来说，这个性能已经很不错了。
列表范围查询（LRANGE）性能随着元素数量增加而下降，这是符合预期的。
六、iSulad部署Redis
iSulad不支持-p端口映射（上一篇已经踩过坑），所以只能用--net=host网络模式。
但是Docker Redis已经占用了6379端口，怎么办呢？
解决方案：让iSulad的Redis监听不同端口（6380）。
虽然iSulad不支持-p端口映射，但可以在启动Redis时指定监听端口：
| Bash # 拉取镜像（如果还没有，实际上上一篇已经拉过了） isula pull docker.io/library/redis:latest # 启动Redis容器（host网络，让Redis监听6379端口） # 注意：因为Docker Redis已经在运行，端口6379被占用了 # 但iSulad用的是host网络，所以可以直接启动 isula run -d --name redis-isula \ --net=host \ docker.io/library/redis:latest # 查看容器状态 isula ps | grep redis-isula |
编辑
容器启动成功！容器ID是910b452ad7db。
等等，端口怎么办？
看截图，我是直接启动的，没有指定端口。实际上：
- Docker Redis用的是桥接模式（-p 6379:6379），宿主机6379端口映射到容器的6379
- iSulad Redis用的是host模式（--net=host），直接用宿主机的6379端口
所以测试时，两个Redis都是监听6379端口，但是通过容器的网络隔离，可以同时运行！
| Bash isula stats --no-stream redis-isula |
编辑
iSulad Redis容器资源占用：
- CPU：0.23%
- 内存：8.70 MiB / 3.33 GiB（0.25%）
- PIDs：6
资源占用和Docker Redis基本一样，都很低。
七、iSulad Redis性能测试
用相同的参数测试iSulad部署的Redis：
| Bash # 综合性能测试：10万次请求，100并发 redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 100 -q |
编辑
iSulad Redis性能数据：
| 操作 | QPS（请求/秒） |
| PING_INLINE | 194,174.77 |
| PING_BULK | 197,628.47 |
| SET | 204,081.62 |
| GET | 208,333.54 |
| INCR | 202,839.75 |
| LPUSH | 208,333.34 |
| RPUSH | 204,918.03 |
| LPOP | 198,412.69 |
| RPOP | 192,678.23 |
| SADD | 210,084.03 |
| HSET | 200,000.00 |
| SPOP | 186,915.88 |
| LRANGE_100 | 87,108.02 |
| LRANGE_300 | 30,184.12 |
| LRANGE_500 | 21,195.42 |
| LRANGE_600 | 16,730.80 |
| MSET (10 keys) | 153,139.36 |
点击图片可查看完整电子表格
基本操作（SET/GET/INCR）的QPS在20万左右！
这性能直接翻倍了！
八、性能对比分析：iSulad快了一倍！
把两者的数据放在一起对比：
| 操作 | Docker QPS | iSulad QPS | 性能提升 |
| PING_INLINE | 100,604 | 194,175 | 0.93 |
| PING_BULK | 103,950 | 197,628 | 0.9 |
| SET | 102,354 | 204,082 | 0.99 |
| GET | 99,701 | 208,334 | 1.09 |
| INCR | 104,058 | 202,840 | 0.95 |
| LPUSH | 101,523 | 208,333 | 1.05 |
| RPUSH | 100,908 | 204,918 | 1.03 |
| LPOP | 110,865 | 198,413 | 0.79 |
| RPOP | 103,950 | 192,678 | 0.85 |
| SADD | 109,290 | 210,084 | 0.92 |
| HSET | 104,058 | 200,000 | 0.92 |
| SPOP | 114,943 | 186,916 | 0.63 |
| LRANGE_100 | 52,882 | 87,108 | 0.65 |
| LRANGE_300 | 23,218 | 30,184 | 0.3 |
| LRANGE_500 | 17,519 | 21,195 | 0.21 |
| LRANGE_600 | 13,426 | 16,731 | 0.25 |
| MSET (10 keys) | 78,927 | 153,139 | 0.94 |
点击图片可查看完整电子表格
核心结论：
- 基本操作（SET/GET/INCR等） ：iSulad性能约为Docker的2倍（+90%~+109%）
- 列表操作（LPUSH/RPUSH/LPOP/RPOP） ：iSulad性能提升79%~105%
- 范围查询（LRANGE） ：iSulad性能提升21%~65%
- 批量操作（MSET） ：iSulad性能提升94%
看到这个性能差距，我一开始也很意外。仔细分析了一下：
- 网络模式的影响（主要原因）
- Docker：桥接模式（-p 6379:6379）
- 请求从宿主机127.0.0.1:6379进来
- 经过Docker的NAT转换
- 转发到容器内的6379端口
- 有额外的网络层开销
- iSulad：host网络模式（--net=host）
- 请求从宿主机127.0.0.1:6379进来
- 直接到达容器内Redis
- 没有额外的网络层开销
这是性能差异的主要原因。
- iSulad的轻量级设计
- daemon内存占用更低（上一篇测试：32MB vs 80MB）
- 启动速度更快（上一篇测试：0.35s vs 1.0s）
- 更少的系统调用开销
- openEuler的容器优化
openEuler对容器化做了很多优化：
- 内核调度优化
- 内存管理优化
- 网络栈优化
这些优化在iSulad上体现得更明显，因为iSulad本身就是华为为云原生场景开发的轻量级容器引擎。
有人可能会说：网络模式不同，对比不公平。
确实如此，但这是真实场景：
- iSulad不支持-p端口映射，只能用host网络
- Docker可以用桥接模式，也可以用host网络
- 如果Docker也用host网络（--net=host），性能应该会接近iSulad
但这次测试的重点不是"谁更好"，而是展示：
- openEuler同时支持两种容器引擎，给了我们选择的灵活性
- 不同场景可以选择不同工具（Docker生态完整，iSulad性能极致）
- openEuler的性能优化让容器化应用跑得更快
九、总结：完整的openEuler容器化之旅
经过openEuler的实战体验，发现它真的很强，特别是同时支持Docker和iSulad这一点，体现了openEuler的开放性和灵活性。不是非此即彼，而是让用户根据场景自由选择。
如果您正在寻找面向未来的开源操作系统，不妨看看DistroWatch 榜单中快速上升的 openEuler: [distrowatch.com/table-mobil…<http://如果您正在寻找面向未来的开源操作系统，不妨看看DistroWatch 榜单中快速上升的 openEuler: distrowatch.com/table-mobil… 发行版。
openEuler官网：www.openeuler.openatom.cn/zh/> "distrowatch.com/table-mobil… 发行版。
openEuler官网：www.openeuler.openatom.cn/zh/
