标签：broker 分片 server 方案 接收 分布式 group message 不同
（1）JMS概念
JMS（Java Message Service,java消息服务）API是一个消息服务的标准或者说是规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。
（2）消息模型
P2P：发送端将消息发送到消息队列（使用什么样的消息队列最优？），不用管接收端的行为，接受端只需要去消息队列中取消息，如果有消息就取出来进行消费，没有就进行等待。
图1：P2P模型
Publish-Subscribe：发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态
图2：发布者-订阅者
（1） KafKa的概念
Kafka是Linkedin于2010年12月份开源的消息系统，是一个高性能，高可用，可持久化的，为分布式设计的消息中间件。
Kafka的集群算法做的很先进，大大强于ActiveMQ。ActiveMQ只有主从互备的HA，负载均衡做的不好，没有消息分片。而Kafka在HA，负载均衡和消息分片上做的很完美。
（2） 目标
1、消息数据保存在磁盘，存取代价为O(1)。一般数据在磁盘上是使用BTree存储的，存取代价为O（lgn）
2、高吞吐率。在普通的节点上，单机每秒10W消息读写
3、支持分布式，所有的producer、broker和consumer都会有多个，均为分布式的。
4、支持数据并行加载到Hadoop中。
（3） 相关概念
1、Topics/logs
一个Topic可以认为是一类消息，每个topic将被分成多个partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一的标记一条消息。kafka没有提供索引机制来存储offset，因为kafka中不对消息进行“随机读写”。
kafka和ActiveMQ不同的是：即使消息被消费，消息仍然不会被立即删除，日志文件将会根据broker中的配置要求，保留一定的时间之后删除；比如log文件保留2天，之后不管消息是否被消费，文件都会被删除。可以达到减少磁盘IO开支的效果。
2、Partitions
每个server（kafka实例）负责partitions中消息的读写操作；此外kafka还可以配置partitions需要备份的个数（replicas），每个partition将会被备份到多台机器上，以提高可用性。每个partition都有一个server为“leader”；leader负责所有的读写操作，如果leader失效，那么将会有其他follower来接管（成为新的leader）；follower只是简单的跟进与leader，同步消息即可。leader server承载了全部的请求压力，因此从集群整体考虑，有多少个partitions就有多少个leader，kafka将leader均衡分散在每个实例上，确保整体的性能稳定。
3、Producers
将消息发布到指定的Topic中，同时Producer也能决定将消息归属到哪个partitions，比如基于“round-robin”方式，或者通过其他的一些算法等。
4、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集群结构图
1、message（消息）是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。如果consumer订阅了这个主题，那么新发布的消息就会广播给这些consumer。
2、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：大数据消息处理解决方案
标签：broker 分片 server 方案 接收 分布式 group message 不同
原文地址：http://www.cnblogs.com/zhehuaxuan/p/7402404.html
