深入浅出Kafka，系统的阿里架构师Kafka分布式学习文档
简介
Apache Kafka是分布式发布-订阅消息系统。它初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。
Kafka架构
它的架构包括以下组件：
- 话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。
- 生产者（Producer）：是能够发布消息到话题的任何对象。
- 服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。
- 消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。
我们为啥会需要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的这些特性， 我们下一次详细讲吧。
深入浅出Kafka
鉴于很多同学咨询我问有没有卡夫卡的文档资料，我这边也给大家准备了一份kafka的文档资料【深入浅出kafka】 这一份文档，会带着大家从基础出发，在到原理，在到实战，力争让大家都能弄明白其中的底层原理！
完整文档获取方式：
Java学习、面试；文档、视频资源免费获取限于头条篇幅的原因，这边我只是暂且把文档的目录截取出来了，有需要这一份文档的可以私信我获取到！
每一章底下都是有完整源码讲解的，就如我先前说的一样，力争从原理出发让大家系统的学习kafka
点击下方链接即可查看获取方式：
相关文章