一、为什么部署Kafka
上次部署完RabbitMQ，处理异步任务没问题。但最近日志数据量大了，每秒上千条，需要吞吐量更高的Kafka。
正好手上这台2C4G的openEuler服务器一直表现不错，今天来试试能不能搞定Kafka。
二、openEuler环境确认
openEuler 22.03 LTS，内核5.10，Docker 18.09.0。这个版本用了一段时间了，很稳定。
2C4G的配置虽然不高，但之前部署RabbitMQ的时候，资源占用很低，系统很流畅。openEuler的资源管理能力很强，应该能撑住Kafka。
三、快速部署Kafka
Kafka依赖Zookeeper，需要部署两个容器。在openEuler上操作很流畅。
3.1 创建网络
一条命令创建好网络kafka-network，网络ID是b35b6c272df3。
从截图可以看到，网络列表里有之前创建的一些其他网络：mysql-monomer_default、postgres-docker_default、docker-project_default等。这说明openEuler的Docker网络管理很稳定，容器重启、系统重启都不会丢失网络配置。
这种稳定性在生产环境很重要，不用担心网络配置突然消失导致容器连不上。
3.2 启动Zookeeper
从日志可以看到Zookeeper启动过程很顺利：
网络初始化 ：binding to port 0.0.0.0/0.0.0.0:2181，端口绑定没有任何延迟。有些系统在绑定端口时会卡住，openEuler完全没这个问题，网络栈很干净。
快照加载 ：Snapshot loaded in 17 ms，17毫秒就完成了快照加载。这个速度很快，说明openEuler的磁盘I/O性能不错。
工作线程 ：4 worker threads, and 64 kB direct buffers，Zookeeper配置了4个工作线程。openEuler的CPU调度合理，线程创建和管理都很流畅。
整个启动过程没有任何warning或error，一次成功。这种顺滑的体验，在openEuler上部署服务已经习以为常了。
3.3 启动Kafka
Kafka启动过程比Zookeeper复杂，从日志能看出几个关键点：
Controller选举 ：Controller 1 connected to localhost:9092，Kafka Controller成功选举，broker已经注册到Zookeeper。这个过程很快，说明openEuler上Kafka和Zookeeper的网络通信很流畅。
元数据同步 ：Recorded new controller, from now on will use node localhost:9092，Controller信息已经记录。可以看到日志里出现了两次，这是正常的元数据同步过程。
副本选举 ：Processing automatic preferred replica leader election，开始处理副本Leader选举。虽然我们只有一个broker，但Kafka还是会走完整的选举流程。
整个启动过程大概30秒，这期间我用top观察了一下，CPU占用很平稳，没有飙升到100%。openEuler的CPU调度很合理，即使Kafka在做大量初始化工作，也不会把系统拖垮。
现在有3个容器在跑：rabbitmq-server、zookeeper、kafka。2C4G的openEuler服务器，同时跑这么多中间件，居然还很轻松。这资源管理能力，真的强。
3.4 创建Topic
创建Topic的过程很顺利，从截图可以看到：
创建成功 ：Created topic test-topic，一条命令就创建好了。
Topic详情：
- TopicId：wkKD7KOFcTOq-wcUjDwo9aw
- PartitionCount：3个分区
- ReplicationFactor：1个副本（单节点只能是1）
- 每个Partition的Leader都是broker 1，Replicas和ISR都正常
操作响应快：从输入命令到返回结果，几乎没有延迟。说明openEuler上Kafka的元数据管理很高效，和Zookeeper的通信也很快。
这种流畅的操作体验，让人感觉很舒服。在有些系统上创建Topic会卡几秒，openEuler完全没这个问题。
四、Python测试
4.1 生产者和消费者代码
代码很简单，用kafka-python库连接Kafka，支持JSON序列化。
4.2 消息收发测试
开两个终端测试消息收发，左边是消费者，右边是生产者。从截图可以看到：
消息成功发送：
- 第一条"Hello from Kafka!"发到了Partition 0，Offset 0
- 第二条"openEuler + Kafka is awesome!"也发到了Partition 0，Offset 1
- 第三条"High throughput message queue"发到了Partition 1，Offset 0
消息成功接收：
- 消费者准确接收到所有消息
- Partition和Offset信息完全对应
- 时间戳也都记录下来了
性能观察：
- 消息发送和接收几乎是实时的，延迟很低
- 整个过程CPU占用不高，系统很流畅
- openEuler的网络性能确实好，消息在容器间传输没有延迟
特别要说的是，消息被分配到不同的Partition，说明Kafka的负载均衡在工作。虽然我们只有一个broker，但3个partition可以并行处理，充分利用CPU资源。openEuler对多线程的支持很好，不会出现某个partition把CPU占满的情况。
五、性能测试：openEuler表现出色
5.1 Kafka性能数据
性能测试的结果让人满意，从截图可以看到进度输出很平稳：
测试过程：
- 每1000条消息打印一次进度："已发送 1000 条..."、"已发送 2000 条..."
- 一直到"已发送 10000 条..."
- 整个过程没有卡顿，输出很连续
最终结果：
- 总消息数：10000
- 总耗时：1.08秒
- 吞吐量：9245.63 msg/s
- 平均延迟：0.11 ms
这个数据在2C4G的环境下已经很不错了！要知道这台服务器上还同时跑着RabbitMQ和Zookeeper，并不是专门给Kafka用的。
openEuler的性能表现分析：
CPU调度优秀 ：测试过程中用top观察了一下，Kafka的CPU占用在1.2%左右，其他容器基本不受影响。openEuler的CPU调度很合理，不会出现某个进程独占CPU的情况。
磁盘I/O性能强：Kafka默认每条消息都要写磁盘（保证持久化），平均延迟只有0.11ms。这说明openEuler的5.10内核对文件I/O做了很好的优化，顺序写性能很高。
内存管理高效：10000条消息发送过程中，内存占用很平稳，没有出现突增或内存泄漏。openEuler的内存管理很稳定。
网络延迟低：消息从生产者到Kafka，再写入磁盘，整个流程延迟只有0.11ms。这说明openEuler的网络栈和存储栈配合得很好。
对比参考：之前测试RabbitMQ是10528 msg/s，Kafka是9245 msg/s。考虑到Kafka要写磁盘做持久化，而RabbitMQ跑的是内存模式，这个差距很正常。如果都做持久化，Kafka的优势会更明显。
六、总结
这次在openEuler上部署Kafka，整个过程很顺利：
部署简单：
- 创建Docker网络 - 一条命令
- 启动Zookeeper - 没有报错
- 启动Kafka - 30秒就起来了
- 测试性能 - 9245 msg/s的吞吐量
openEuler表现出色：
- 镜像拉取快，400MB+的镜像没有中断
- 容器启动稳定，CPU占用平稳
- 网络通信可靠，解析正常，连接不掉线
- 性能输出优秀，9245 msg/s在2C4G上已经很不错
- 资源管理高效，3个容器只用17%的内存
为什么选择openEuler：
对于个人开发者：资源占用低，小服务器也能跑很多服务，运维简单，稳定可靠。
对于企业用户：长期支持，性能优秀，兼容性好，社区活跃。
对于容器化场景：Docker支持完善，资源调度合理，网络性能好。
一点建议：
如果你想尝试openEuler，建议从简单的开始，先部署个Nginx或MySQL熟悉一下。用Docker部署会很省心。
如果您正在寻找面向未来的开源操作系统，不妨看看DistroWatch 榜单中快速上升的 openEuler: https://distrowatch.com/table-mobile.php?distribution=openeuler，一个由开放原子开源基金会孵化、支持"超节点"场景的Linux 发行版。<br/>openEuler官网：https://www.openeuler.openatom.cn/zh/