转自：http://mini.eastday.com/mobile/171206090712431.html#

 

互联网应用：流量削峰互联网应用经常会遇到要处理高峰问题，这也是我们所负责业务经常要面对的事情，比如遇到一个热点事件、或者策划一个活动（比如双十一秒杀活动），访问的骤增带来读写的流量的骤增，每个环节都买你对瞬间请求骤增的问题，那么有哪些方法可以做到流量削峰或者说流量削峰要从哪几个方面考虑呢？基于SOA的架构设计，弹性扩展瓶颈模块服务器资源；接入层以及各服务模块极大的用好cache，增加QPS,从而加大整个集群的吞吐量；模块间使用消息队列通信，进行模块异步解耦，访问量上来后，使用时间成本换取业务能够正常服务。各服务模块对自身负责的同时，要做好后端依赖有效调用的判断，做到向上游模块所做的调用都是必要的调用，无冗余或无效的调用。划分好动静资源，静态资源使用CDN进行服务分发。秒杀系统中的流量削锋用消息队列来做，原理如下：用户的请求，服务器接收后，首先写入消息队列，依次处理。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。消息队列概述：

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息， 流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不 可缺少的中间件。常用消息队列系统：目前在生产环境，使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等。那么今天我们就来了解一下Kafka这个消息队列系统：Kafka

背景历史 当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下几个挑战： 如何收集这些巨大的信息？ 如何分析它？ 如何及时做到如上两点？ 以上几个挑战形成了一个业务需求模型，即消息生产者生产（producer）各种信息，消息消费者消费（consumer）（处理分析）这些信息，而在生产者与消费者之间，需要一个沟通两者的桥梁---消息系统。从一个微观层面来说，这种需求也可理解为不同的系统之间如何传递消息，以下称系统为消息生产者和消息消费者。Flume+Kafka+Storm架构中Fulme就是相当于生产者(其实它不是真正的生产者，它只是收集了真正生产者(各大应用系统)的各种信息)，Storm等消息数据处理框架就相当于消费者。

Flume(充当生产者)+Kafka+Storm(消费者)架构设计

Kafka诞生

消息队列技术是分布式应用间交换信息的一种技术。

消息队列可驻留在内存或磁盘上, 队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收消息。

在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。常用的消息队列技术是 Message Queue。

kafka-即是解决上述这类问题的一个框架，它实现了生产者和消费者之间的无缝连接。

kafka-高产出的分布式消息系统(A high-throughput distributed messaging system)。

Kafaka介绍

Apache Kafka是一个分布式的基于发布-订阅(push-subscribe)的消息传递系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。

一个典型的kafka集群中包含若干producer（可以是web前端产生的page view，或者是服务器日志，系统CPU、memory等）；若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高）；若干consumer，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置。

Kafka架构组件

Kafka生态圈上图中可以看出，生产者将数据发送到Broker代理，Broker代理有多个话题topic，消费者从Broker获取数据。producer 到 broker 的过程是 push，也就是有数据就推送到 broker，而 consumer 到 broker 的过程是 pull，是通过 consumer 主动去拉数据的，而不是 broker 把数据主动发送到 consumer 端的。消息生产者producer和消费者consumer可以在多个Broker上生产/消费topic。每个类型的消息被定义为topic，同一topic内部的消息按照一定的key和算法被分区到不同的Broker。每个topic包含一个或多个partition(分区)，partition数量可以创建topic时指定，每个分区日志中记录了该分区的数据以及索引信息。每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。

生产者将数据生产出来，交给 broker 进行存储，消费者需要消费数据了，就从broker中去拿出数据来，然后完成一系列对数据的处理操作。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。kafka名词解释和工作方式：

Producer(消息生产者)：

能够发布消息到话题的任何对象。负责发布消息到Kafka broker，使用push(推送)模式将消息发布到broker。

Consumer(消息消费者)：

向kafka broker拉取消息的客户端，可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。consumer使用pull模式从broker订阅并消费消息。可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息

Consumer Group（CG）：

这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。

Broker(服务代理)：

Kafka集群包含一个或多个服务器，这种服务器被称为broker，一台kafka服务器就是一个broker。一个broker可以容纳多个topic。已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。

话题（Topic）：

是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。即一类消息，例如page view日志、click日志等都可以以topic的形式存在。咱们可以理解为一个队列。 每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）

Partition：

parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件，为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。

写的很累，你们看的累吗？Zookeeper在kafka的作用 那么Zookeeper在kafka的作用是什么？ Kafka是一个分布式消息队列，需要依赖Zookeeper。kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性，集群保存一些meta信息。Kafka使用zookeeper作为其分布式协调框架，很好的将消息生产、消息存储、消息消费的过程结合在一起。同时借助zookeeper，kafka能够将生产者、消费者和broker在内的所以组件在无状态的情况下，建立起生产者和消费者的订阅关系，并实现生产者与消费者的负载均衡。

Push vs. Pull

作为一个messaging system，Kafka遵循了传统的方式，选择由producer向broker push(推)消息并由consumer从broker pull(拉)消息。push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

Topic & Partition

Topic在逻辑上可以被认为是一个queue队列，每条消息都必须指定它的topic，可以简单理解为必须指明把这条消息放进哪个queue里。为 了使得Kafka的吞吐率可以水平扩展，物理上把topic分成一个或多个partition，每个partition在物理上对应一个文件夹，该文件夹 下存储这个partition的所有消息和索引文件。kafka 应用场景日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。消息系统：解耦和生产者和消费者、缓存消息等。用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。流式处理：比如spark streaming和stormKafka的特性高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒可扩展性：kafka集群支持热扩展持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）高并发：支持数千个客户端同时读写

休息片刻Kafka一些重要设计思Consumergroup：各个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，如果一个消息可以被多个consumer消费的话，那么这些consumer必须在不同的组。消息状态：在Kafka中，消息的状态被保存在consumer中，broker不会关心哪个消息被消费了被谁消费了，只记录一个offset值（指向partition中下一个要被消费的消息位置），这就意味着如果consumer处理不好的话，broker上的一个消息可能会被消费多次。消息持久化：Kafka中会把消息持久化到本地文件系统中，并且保持极高的效率。消息有效期：Kafka会长久保留其中的消息，以便consumer可以多次消费，当然其中很多细节是可配置的。批量发送：Kafka支持以消息集合为单位进行批量发送，以提高push效率。push-and-pull : Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer只管向broker push消息，consumer只管从broker pull消息，两者对消息的生产和消费是异步的。Kafka集群中broker之间的关系：不是主从关系，各个broker在集群中地位一样，我们可以随意的增加或删除任何一个broker节点。负载均衡方面： Kafka提供了一个 metadata API来管理broker之间的负载（对Kafka0.8.x而言，对于0.7.x主要靠zookeeper来实现负载均衡）。同步异步：Producer采用异步push方式，极大提高Kafka系统的吞吐率（可以通过参数控制是采用同步还是异步方式）。分区机制partition：Kafka的broker端支持消息分区，Producer可以决定把消息发到哪个分区，在一个分区中消息的顺序就是Producer发送消息的顺序，一个主题中可以有多个分区，具体分区的数量是可配置的。分区的意义很重大，后面的内容会逐渐体现。离线数据装载：Kafka由于对可拓展的数据持久化的支持，它也非常适合向Hadoop或者数据仓库中进行数据装载。插件支持：现在不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件

知识扩展：同步、异步消息 在Java中交互方式分为同步消息处理和异步消息处理两种：

同步交互：指发送一个请求,需要等待返回,然后才能够发送下一个请求，有个等待过程；

异步交互：指发送一个请求,不需要等待返回,随时可以再发送下一个请求，即不需要等待。

区别：一个需要等待，一个不需要等待，在部分情况下，我们的项目开发中都会优先选择不需要等待的异步交互方式。

同步交互比如银行的转账系统，对数据库的保存操作等等，都会使用同步交互操作，其余情况都优先使用异步交互。