Kafka 温故(一)：Kafka背景及架构介绍

一.Kafka简介       

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，使用Scala语言编写，以后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，多订阅者，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据（实时性的计算）。

在大数据系统中，经常会碰到一个问题，整个大数据是由各个子系统组成，数据须要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并非很是适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka能够起到两个做用：

1.下降系统组网复杂度。
2.下降编程复杂度，各个子系统不在是相互协商接口，各个子系统相似插口插在插座上，Kafka承担高速数据总线的做用。

二.Kafka的主要特色

1.同时为发布和订阅提供高吞吐量。据了解，Kafka每秒能够生产约25万消息（50 MB），每秒处理55万消息（110 MB）。
2.可进行持久化操做。将消息持久化到磁盘，所以可用于批量消费，例如ETL，以及实时应用程序。经过将数据持久化到硬盘以及replication防止数据丢失。
3.分布式系统，易于向外扩展，能够和ZooKeeper结合。全部的producer、broker和consumer都会有多个，均为分布式的。无需停机便可扩展机器。
4.消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。
5.支持online和offline的场景。

三.为什么使用消息系统

能够经过消息队列作系统之间的通讯，即系统之间的相互协调和调用

注意：使用消息队列和SOA架构的区别？
          1.SOA是直接调用的（能够经过RPC和HTTPClient来直接调用）
          2.使用消息队列是经过消息的传递，来完成两个系统之间的整合和调用

带来的好处：
1.解耦合
      使用了消息队列后，两个系统之间没有直接的调用关系，只是经过消息的传递来交互，两个系统之间没有侵入性。

2.提升系统的响应速度

       例子：订单处理
      
        订单支付成功的方法(){
                一、修改订单状态
                二、计算会员积分
                三、通知物流进行配送
      }
    注： 
           1.原来系统中这个三个步骤要同时处理后再返回，这样比较耗时；
           2.如今能够先处理用户最关心的，最急需看到的修改订单状态成功信息，这样能够先处理"修改订单状态",而后马上返回给用户，
              后面的“计算会员积分”，“通知物流进行配送”，放入消息队列中交给后面的系统继续处理。
冗余
      有些状况下，处理数据的过程会失败。除非数据被持久化，不然将形成丢失。消息队列把数据进行持久化直到它们已经被彻底处理，经过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除以前，须要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

扩展性
     由于消息队列解耦了你的处理过程，因此增大消息入队和处理的频率是很容易的，只要另外增长处理过程便可。不须要改变代码、不须要调节参数。扩展就像调大电力按钮同样简单。

灵活性 & 峰值处理能力
      在访问量剧增的状况下，应用仍然须要继续发挥做用，可是这样的突发流量并不常见；若是为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列可以使关键组件顶住突发的访问压力，而不会由于突发的超负荷的请求而彻底崩溃。

可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列下降了进程间的耦合度，因此即便一个处理消息的进程挂掉，加入队列中的消息仍然能够在系统恢复后被处理。

顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列原本就是排序的，而且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。

缓冲
在任何重要的系统中，都会有须要不一样的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列经过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽量的快速。该缓冲有助于控制和优化数据流通过系统的速度。

异步通讯
不少时候，用户不想也不须要当即处理消息。消息队列提供了异步处理机制，容许用户把一个消息放入队列，但并不当即处理它。想向队列中放入多少消息就放多少，而后在须要的时候再去处理它们。

四.消息队列的分类

 消息队列的分类：点对点，发布/订阅

 1.点对点
       消息生产者生产消息发送到queue中，而后消息消费者从queue中取出而且消费消息

  注意（缺点）：

           1.消息被消费之后，queue中再也不有存储，因此消费者不可肯消费到已经被消费的消息。

           2.queue中支持存在多个消费者，可是对一个消息而言，只会有一个消费者能够消费。
 
          （当一个系统消费了该个消息后，其余的系统不能再消费了）

 2.发布/订阅（最经常使用的）
         消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不一样，发布到topic的消息会被全部订阅的消费者消费。

五.常见的消息队列对比    

   1.RabbitMQ：支持的协议多，很是重量级消息队列，对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。

    2.ZeroMQ：号称最快的消息队列系统，尤为针对大吞吐量的需求场景，擅长的高级/复杂的队列，可是技术也复杂，而且只提供非持久性的队列。

    3.ActiveMQ（JMS的实现）：Apache下的一个子项，相似ZeroMQ，可以以代理人和点对点的技术实现队列 。

    4.Redis：是一个key-Value的NOSql数据库，但也支持MQ功能，数据量较小，性能优于RabbitMQ，数据超过10K就慢的没法忍受。

        
    注：消息队列不多是单点的，也须要集群。这样就涉及到了，负载均衡和消息的持久化

 六.Kafka的测试效果

 

参考资料：

《百知教育》apache kafka