从JMS到KafKa

从JMS到KafKa

JMS

（1）JMS概念

JMS（Java Message Service,java消息服务）API是一个消息服务的标准或者说是规范，容许应用程序组件基于JavaEE平台建立、发送、接收和读取消息。它使分布式通讯耦合度更低，消息服务更加可靠以及异步性。

（2）消息模型

P2P：发送端将消息发送到消息队列（使用什么样的消息队列最优？），不用管接收端的行为，接受端只须要去消息队列中取消息，若是有消息就取出来进行消费，没有就进行等待。

图1：P2P模型

Publish-Subscribe：发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须建立一个订阅者以后，才能消费发布者的消息，并且为了消费消息，订阅者必须保持运行的状态

图2：发布者-订阅者

 

 

KafKa

（1）   KafKa的概念

Kafka是Linkedin于2010年12月份开源的消息系统，是一个高性能，高可用，可持久化的，为分布式设计的消息中间件。

Kafka的集群算法作的很先进，大大强于ActiveMQ。ActiveMQ只有主从互备的HA，负载均衡作的很差，没有消息分片。而Kafka在HA，负载均衡和消息分片上作的很完美。

（2）   目标

一、消息数据保存在磁盘，存取代价为O(1)。通常数据在磁盘上是使用BTree存储的，存取代价为O（lgn）

二、高吞吐率。在普通的节点上，单机每秒10W消息读写

三、支持分布式，全部的producer、broker和consumer都会有多个，均为分布式的。

四、支持数据并行加载到Hadoop中。

（3）   相关概念

一、Topics/logs  

一个Topic能够认为是一类消息，每一个topic将被分红多个partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是惟一的标记一条消息。kafka没有提供索引机制来存储offset，由于kafka中不对消息进行“随机读写”。

kafka和ActiveMQ不一样的是：即便消息被消费，消息仍然不会被当即删除，日志文件将会根据broker中的配置要求，保留必定的时间以后删除；好比log文件保留2天，以后无论消息是否被消费，文件都会被删除。能够达到减小磁盘IO开支的效果。

二、Partitions   

每一个server（kafka实例）负责partitions中消息的读写操做；此外kafka还能够配置partitions须要备份的个数（replicas），每一个partition将会被备份到多台机器上，以提升可用性。每一个partition都有一个server为“leader”；leader负责全部的读写操做，若是leader失效，那么将会有其余follower来接管（成为新的leader）；follower只是简单的跟进与leader，同步消息便可。leader server承载了所有的请求压力，所以从集群总体考虑，有多少个partitions就有多少个leader，kafka将leader均衡分散在每一个实例上，确保总体的性能稳定。

三、Producers

将消息发布到指定的Topic中，同时Producer也能决定将消息归属到哪一个partitions，好比基于“round-robin”方式，或者经过其余的一些算法等。

四、Consumers

每一个consumer属于一个consumer group。发送到Topic的消息，只会被订阅此Topic的每一个group中的一个consumer消费。
若是全部的consumer都具备相同的group（属于queue模式），消息将会在consumer之间负载均衡。
若是全部的consumer都具备不一样的group（属于“发布-订阅”模式），消息将会广播给全部的消费者。
一个partition中的消息只会被group中的一个consumer消费，一个consumer能够消费多个partitions中的消息。kafka只能保证一个partitions中的消息被某个consumer消费是顺序的。
kafka的设计原理决定，对于一个topic，同一个group中不能有多余partitions个数的consumer同时消费，不然将某些consumer没法获得消息。

（4）   KafKa的部署结构

图3：KafKa集群结构图

一、message（消息）是通讯的基本单位，每一个producer能够向一个topic（主题）发布一些消息。若是consumer订阅了这个主题，那么新发布的消息就会广播给这些consumer。

二、Kafka是显式分布式的，多个producer、consumer和broker能够运行在一个大的集群上，做为一个逻辑总体对外提供服 务。对于consumer，多个consumer能够组成一个group，这个message只能传输给某个group中的某一个consumer. 

（5）   大数据架构：flume-ng+Kafka+Storm+HDFS 实时系统组合

1）数据采集：负责从各节点上实时采集数据，选用cloudera的flume来实现

2）数据接入：因为采集数据的速度和数据处理的速度不必定同步，所以添加一个消息中间件来做为缓冲，选用apache的kafka

3）流式计算：对采集到的数据进行实时分析，选用apache的storm

4）数据输出：对分析后的结果持久化，暂定用mysql

图4：大数据消息处理解决方案