从这个角度，我终于理解为什么需要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的这些高级特性， 我们下一次详细讲吧。