Apache Kafka

        它是Apache开发的一个开源流处理平台，由Scala和Java编写，是一个高吞吐量的分布式发布订阅消息系统，可以做系统解耦、异步通信、削峰填谷等来提升系统性能和用户体验；同时还提供了Streaming流处理插件，实现了实时在线流处理，运行在应用端，有着入门要求低，部署方便等优点。

• 系统解耦：例如在用户注册的业务场景中，我们需要在用户注册成功后发送注册成功的短信通知，如果在当前的系统架构设计中，用户注册成功后需立即调用短信发送服务，而此时短信服务出现异常，会导致用户无法成功注册；但我们在系统设计中，在用户注册和短信服务中间加入消息队列之后，短信服务的异常就不会影到用户注册；
• 异步通信：继续使用上述业务场景，在引入了消息队列之后，用户注册成功之后，可以直接将结果返回给用户，无需等到短信发送成功之后再给用户返回，减少客户端和应用服务器间的调用时间；
• 削峰填谷：在分布式架构下，针对短时间出现大量的请求，消息队列可以起到缓冲的作用，减小服务器的压力；

Kafka的日志和分区

        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（集群）中。

        每则消息的分发策略：

1. 利用Hash算法：key（hash值）%分区数，一个可以保证所有的消息均匀地分散在不同的分区中，以及同一条消息保持在同一个分区中，分区的副本因子是指每个分区在集群中存储多少个副本。
2. 轮询；
3. 指定发送到某个分区；

        在每个Topic的分区中，只能保证同一个分区内的消息是先进先出的原则，同一消息被发送到不同的分区，是没有办法保证当前所有相同消息的消费顺序，解决方案：

1. 不设立分区；
2. 将同一消息发送到相同的分区中；

        Kafka底层会定期检查日志文件，然后将过期的数据从log中移除，由于Kafka是使用硬盘存储，因为可以长时间缓存一些日志文件。

        由于实现了日志分区，所以Kafka允许日志扩展到超出单个服务器所能容纳的大小。而一个Topic可能有很多分区，因此它可以处理任意数量的数据。

Kafka的消费者

        消费者在消费Topic中数据的时候，每个消费者会维护本次消费对应分区的偏移量，消费者会在消费完一个批次的数据之后，会将本次消费的偏移量提交给Kafka集群，因此对于每个消费者可以随意控制自身的偏移量。因此在Kafka中，消费者可以从一个Topic分区中的任意位置读取队列数据，由于每个消费者控制了自己消费的偏移量，所以每个消费者彼此之间都相互独立。

        而通常Kafka进行消费的时候，是以一个消费组的形式进行消费。同一个消费组会均分分区内的消息。不同的消费组，会对应不同的业务功能模块，因此并不会出现同一个消息被重复消费两次。另外，一个消费组的消费者一般不会超过分区的数量。若有超过了分区的数量的消费者，就会出现空闲的消费者；不过可以利用这种机制做消费者的冗余，此时一旦有某一消费者出现宕机或者其他异常，则就会启用空闲的消费者。

        同一topic分区内的消息会广播到所有消费组去消费。

        因此提高分区的数量，也能提高消费者并发的能力。而由于采用了分区策略，因此Kafka仅能保证分区中记录的有序性。如果要想实现消费的有序，可以采用一个分区以及一个消费者来消费数据来达到消费的有序性。

Kafka的特性之高吞吐率

        Kafka的消息虽然是缓存或保存在磁盘上的，但是依然可支持每秒百万级的请求，这得益于他使用了顺序写入和MMFile（内存映射文件）。

        磁盘的读写效率低，是因为通常每次读写都需要先寻址，再写入数据，最耗时的就是寻址。而Kafka采用了顺序写入，省去了大量的内存开销以及节省了IO寻址的时间。另外Kafka的数据并不是实时写入到硬盘中，而是通过操作系统的分页存储来利用内存进一步提高I/O效率。

•  当应用出现宕机的时候，由于此时请求已经写入到了操作系统内存中的pageCahe，因此不会发生数据丢失；
• 当服务器断电导致操作系统停止工作，此时会发生数据丢失（解决方案：UPS电源）；

        消息在被消费的时候，也并不会到达用户空间，会直接在操作系统的内核空间消费完之后，将最后的结果返回到用户空间。