它是Apache开发的一个开源流处理平台，由Scala和Java编写，是一个高吞吐量的分布式发布订阅消息系统，可以做系统解耦、异步通信、削峰填谷等来提升系统性能和用户体验；同时还提供了Streaming流处理插件，实现了实时在线流处理，运行在应用端，有着入门要求低，部署方便等优点。
- 系统解耦：例如在用户注册的业务场景中，我们需要在用户注册成功后发送注册成功的短信通知，如果在当前的系统架构设计中，用户注册成功后需立即调用短信发送服务，而此时短信服务出现异常，会导致用户无法成功注册；但我们在系统设计中，在用户注册和短信服务中间加入消息队列之后，短信服务的异常就不会影到用户注册；
- 异步通信：继续使用上述业务场景，在引入了消息队列之后，用户注册成功之后，可以直接将结果返回给用户，无需等到短信发送成功之后再给用户返回，减少客户端和应用服务器间的调用时间；
- 削峰填谷：在分布式架构下，针对短时间出现大量的请求，消息队列可以起到缓冲的作用，减小服务器的压力；
Kafka集群是以Topic形式负责分类集群中的Record（记录日志：key/value/timestamp），每一个Record属于一个Topic。每个Topic底层都会对应一组分区的日志用于持久化Topic中的Record，这些日志都是有序且不可变的，每一个Record都被分配了唯一的序列编号，称为是offset，而且每份分区的Record都会有自己对应的副本作备份（备份会放在其他分区存储）。另外，持久化时间是可以通过配置文件指定，默认是168小时。
log.retention.hours = 168
同时在Kafka集群中，Topic的每一个日志文件的分区都一定会有1个Borker（服务器）担当该分区的Leader，其他的Broker担当给分区的follower，所以每一个Borker都有可能既是Leader，也是 Follower。Leader负责分区数据的读写操作，follower负责同步该分区的数据。
如果分区的Leader宕机，该分区的其他follower会选取初新的Leader继续负责该分区数据的读写。所以一个Broker也有可能是两个Topic的Leader。其中集群中的Leader的监控和Topic的部分原数据是存储在Zookeeper Cluster（集群）中。
每则消息的分发策略：
- 利用Hash算法：key（hash值）%分区数，一个可以保证所有的消息均匀地分散在不同的分区中，以及同一条消息保持在同一个分区中，分区的副本因子是指每个分区在集群中存储多少个副本。
- 轮询；
- 指定发送到某个分区；
在每个Topic的分区中，只能保证同一个分区内的消息是先进先出的原则，同一消息被发送到不同的分区，是没有办法保证当前所有相同消息的消费顺序，解决方案：
- 不设立分区；
- 将同一消息发送到相同的分区中；
Kafka底层会定期检查日志文件，然后将过期的数据从log中移除，由于Kafka是使用硬盘存储，因为可以长时间缓存一些日志文件。
由于实现了日志分区，所以Kafka允许日志扩展到超出单个服务器所能容纳的大小。而一个Topic可能有很多分区，因此它可以处理任意数量的数据。
Kafka的消费者消费者在消费Topic中数据的时候，每个消费者会维护本次消费对应分区的偏移量，消费者会在消费完一个批次的数据之后，会将本次消费的偏移量提交给Kafka集群，因此对于每个消费者可以随意控制自身的偏移量。因此在Kafka中，消费者可以从一个Topic分区中的任意位置读取队列数据，由于每个消费者控制了自己消费的偏移量，所以每个消费者彼此之间都相互独立。
