• 什么需要Kafka这样的消息队列插件?
  • 发布于 2个月前
  • 206 热度
    0 评论
  • 康康
  • 1 粉丝 40 篇博客
  •   
先从数据库说起。

我们都知道,数据库中的数据,只要应用程序员不主动删除,就可以任意次读写,多少次都行。 数据库还对外提供了很漂亮的接口——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的这些高级特性, 我们下一次详细讲吧。

用户评论