从这个角度,我终于理解为什么需要Kafka这样的东西了!

先从数据库说起。

我们都知道,数据库中的数据,只要应用程序员不主动删除,就可以任意次读写,多少次都行。 数据库还对外提供了很漂亮的接口——SQL ——让程序员操作数据。

但是数据库不擅长做“通知”(人家也不是干这种事的): 例如,程序A向数据库插入了一条数据, 然后程序B想知道这次数据更新,然后做点事情。

这种"通知"的事情,一种办法是用轮询实现, 程序B不断地查数据库,看看有没有新数据的到来, 但是这种方法效率很低。

更直接的办法是让应用程序之间直接交互,例如程序A调用程序B的RESTful API。

但问题是程序B如果暂时不可用,程序A就会比较悲催,怎么办呢?等一会儿再试? 如果程序B还不行,那就循环再试。调用方的责任太大。

于是消息队列(MQ)就出现了,程序A把数据往消息队列中一扔,完事走人,程序B想什么时候读就什么时候读,极其灵活。

所以MQ的重要功能就是解耦,让两个系统可以独立运行,异步操作,互不影响。

MQ还有一个好处就是允许程序A疯狂地向其中放消息,程序B 可以慢悠悠地处理,这就起到了“消峰”的效果。

可是传统的MQ也有问题,通常情况下,一个消息确认被读取以后,就会被删除。 如果来了一个新的程序C,也想读之前的消息,或者说之前一段时间的消息,传统MQ表示无能无力。

能不能把数据库的特点和MQ的特点结合起来呢?

消息可以持久化,让多个程序都可以读取,并且还支持发布-订阅这种模式。

Kafka出现了,它也是一个消息队列,但是它能保存很长一段时间的消息(因为在硬盘上),队列中每个消息都有一个编号1,2,3,4.... ,这样就支持多个程序来读取。

只要记录下每个程序都读到了哪个编号, 这个程序可以断开和Kafka的连接,这个程序可以崩溃,下一次就可以接着读。

新的消费者程序可以随意加入读取,不影响其他消费者程序, 是不是很爽?

例如:程序B读到了编号为3的消息, 程序C读到了编号为5的消息, 这时候来了一个新的程序D,可以从头开始读。

这其实和数据库复制有点像:Kafka维护者“主数据库”, 每个消费者程序都是“从数据库”, 只要记住编号,消息都可以从“主数据库”复制到“从数据库”。

当然,Kafka做的远不止于此,它还充分利用硬盘顺序化读取速度快的特性,再加上分区,备份等高可用特性, 一个高吞吐量的分布式发布订阅消息系统就诞生了。

Kafka的这些高级特性, 我们下一次详细讲吧。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190617A04OM600?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券