为何要抛弃Kafka,选择NSQ!

作者 bluse wang 日期 2019-07-14
为何要抛弃Kafka,选择NSQ!

自从抛PHP从Go。一直相安无事。近来遇到复杂业务时才想起旧爱Laravel Queue

替代品有两个:

一个是名声响彻东西半球的时代宠儿:Kafka

另一个是穷光蛋查理的首选:NSQ

Let’s Rock

架构

NSQ 进程架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 +-----------------+        +---------------+
| | | |
| nsqlookup +<-------+ nsqadmin |
| | | |
+-------+---------+ +---------------+
|
|
|
v
+-------------+
| +-------------+
| | +--------------+
| | | |
+---+ nsqd |
+-+ |
+--------------+

Kafka 进程架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
+----------------+
| |
| zookeeper |
| |
+--------+-------+
|
|
|
v
+-------------+
| +-------------+
| | +--------------+
| | | |
+---+ kafka |
+-+ |
+--------------+

资源消耗

  • 环境:FreeBSD12
  • 测量工具:htop RES

NSQ

进程 启动时占用
nsqd 9.2MB
nsqlookup 8.5MB

Kafka

进程 启动时占用
kafka 299MB
zookeeper 58MB

运行与维护

\ NSQ Kafka
依赖 Linux基础包、bash、jdk、java
耦合 无!能以nsqd单进程提供完整服务,只在多节点分布式模式下需要nsqlookup 依赖 zookeeper
日志 标准输出,自行重定向 zookeeper 1份日志,kafka 7份日志,其中两份日志按小时自动切割
配置 10项左右,默认即是最优 10多个独立配置文件,数百个配置项
性能优化 默认开启 pprof。支持web可视化实时观测内存、协程等动态
异常排查 错误日志中的栈,源码量小。不依赖网络问答也能在短时间内找出问题 错误日志中的栈,深度的栈,巨量源码,排查需要深入了解其原理,大量阅读源码。否则只能通过互联网、查阅前人经验或大师级人脉。

业务能力

\ NSQ Kafka
数据安全 单个nsqd实例内的数据,不支异地热备,实例在正常退出时,会做刷入磁盘操作,也有手动备份实例数据的工具。 数据全在磁盘。多个节点间自动互为备份。
消息顺序 不保证有序 支持有条件的有序
消息投递 至少一次,消费者需自行保持消息处理的幂等 支持准确的一次
  • 附加能力
\ NSQ Kafka
界面化管理 自带nsqadmin 无,需额外安装第三方包
基于http协议的pub nsqd自带 无,需额外安装第三方包

一个Goer视角的体验

kafka 的golang client 官方首推 sarama。一查就出糙点:golang 消费 kafka 的坑
这些库的版本,1.0都不到。

go-nsq截至当前已经历16次release至v1.0.7。适用度,亲测为上好!

NATS队列

by the way 顺便提一下NATS队列,也很有名。它的消息投递既支持至少一次,也支持最多一次,也无法准确的一次。

何时该选择Kafka

Kafka隶属于Apache基金会。是Apache“全家桶”的一员。

Apache家族拥有除了队列之外,在可靠计算和大数据方面有着可靠、开放的整体解决方案。就像ARM的公版。

Java开发者是个遍布全球的庞大工人群体。

因此,选择Apache下的产品具有工业化特征,是一个只要肯花钱,就一定能实现的高度可复制的生产机器。

身为Goer 自豪地采用NSQ

  • 在云服务成熟的今天,主机意外断电,且断电后硬盘也意外消失的可能几乎为0。再加上阿里云的定时自动快照。倘若是金融、保险类的业务,还可以通过其它手段,如:文件同步备份的方式做热备。
  • 成本。不论是运维成本,还是硬件成本,NSQ都吊打Kafka!相比之下保持幂等的成本,就不是事儿了。