Kafka-1 基础知识与应用场景、基本结构
1、Kafka是什么
一个分布式消息中间件，支持分区、多副本、多订阅者的，基于zookeeper协调的分布式消息系统。
kafka支持的两种消息引擎模型：用什么方法把消息传输出去：
- 点对点模型：也叫消息队列模型，系统A发送的消息只能被系统B接收，其他任何系统都不能读取A发送的消息
- 发布/订阅模型：一个主题(Topic)，可以理解为消息容器。多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息
往消息系统里面发送数据的就是生产者，kafka里面的我们处理的数据叫做消息，从kafka里读取数据的就是消费者
常见术语：
| 名词 | 解释 |
| Producers | 消息和数据发布者/生成者，向Kafka的一个topic发布消息的 过程叫做producers |
| Consumers | 消息和数据的订阅者/消费者，订阅topic并处理其发布的消费过程叫做consumers消息：Record。这里的消息就是指kafka处理的主要对象。 |
| ConsumerGroup： | 消费者组，可以并行消费Topic中的partition的消息，实现高吞吐 |
| Broker | 缓存代理，Kafka集群中的一台或多台服务器统称broker. |
| Topic | 主题，Kafka处理资源的消息源(feeds of messages)的不同分类，用来区分具体的业务 |
| Partition | 分区，Topic物理上的分组，一个topic可以分为多个partion,每个partion是一个有序的队列。partion中每条消息都会被分 配一个 有序的Id(offset) |
| Message | 消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息 |
| Offset | 消息位移，表示分区中每条消息的位置信息 |
| Consumer Offset | 消费者位移，表示消费者消费进度，每个消费者有自己的消费者位移 |
| Repilca | 副本，一条消息能被拷贝到多个地方。副本分为Leader副本和follower副本，如上图一个producer会将消息存储为多个副本(leader/follower)在不同分区 ，副本是在分区层级下的 |
| Rebalance | 重平衡，消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。这也是kafka消费者端实现高可用的重要手段。 |
2、使用场景：在线秒杀、高并发访问、用户行为日志缓冲
例如，马上即将开始的春节火车票抢购，大量的用户需要同一时间去抢购；以及大家熟知的阿里双11秒杀， 短时间上亿的用户涌入，瞬间流量巨大（高并发），比如：200万人准备在凌晨12:00准备抢购一件商品，但是商品的数量缺是有限的100-500件左右。
这样真实能购买到该件商品的用户也只有几百人左右， 但是从业务上来说，秒杀活动是希望更多的人来参与，也就是抢购之前希望有越来越多的人来看购买商品。
但是，在抢购时间达到后，用户开始真正下单时，秒杀的服务器后端缺不希望同时有几百万人同时发起抢购请求。
我们都知道服务器的处理资源是有限的，所以出现峰值的时候，很容易导致服务器宕机，用户无法访问的情况出现。
这就好比出行的时候存在早高峰和晚高峰的问题，为了解决这个问题，出行就有了错峰限行的解决方案。
同理，在线上的秒杀等业务场景，也需要类似的解决方案，需要平安度过同时抢购带来的流量峰值的问题，这就是流量削峰的由来。
- 怎样来实现流量削峰方案
削峰从本质上来说就是更多地延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则。
- 消息队列解决削峰
要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把同步的直接调用转换成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。
- 缓冲作用
消息队列就像“水库”一样，拦蓄上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害的目的。
它的主要作用类似于蓄水池，起到一个缓冲作用：异步、削峰、解耦
-
异步：多线程同时处理复杂并发请求
你可以去干其他的事情，过段时间来拿处理结果
pay(info);
new Thead(new Runnable(info){
优惠券
积分
短信
}
-
解耦：利用消息，将发送消息与消息接收分离
-
削峰：缓冲上下游瞬时突发流量，使其平滑。一旦有了消息引擎系统，它能够有效地对抗上游的流量冲击，真正做到将上游的“峰”填满到“谷”中，避免了流量的震荡
- 对于秒杀这样的高并发场景业务，最基本的原则就是将请求拦截在系统上游，降低下游压力。如果不在前端拦截很可能造成数据库(mysql、oracle等)读写锁冲突，甚至导致死锁，最终还有可能出现雪崩等场景。
- 划分好动静资源，静态资源使用CDN进行服务分发。
- 充分利用缓存(redis等)：增加QPS，从而加大整个集群的吞吐量。
- 高峰值流量是压垮系统很重要的原因，所以需要Kafka等消息队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。
3、基础架构
一个典型的Kafka体系架构包括若干Producer（可以是服务器日志，业务数据，页面前端产生的page view等等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer (Group)，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。Producer使用push(推)模式将消息发布到broker，Consumer使用pull(拉)模式从broker订阅并消费消息
4、分区：Topic & Partition：实现 topic数据的负载均衡
Topic和partition像是HBASE里的table和region的概念，table只是一个逻辑上的概念，真正存储数据的是region，这些region会分布式地存储在各个服务器上面，对应于kafka，也是一样，Topic也是逻辑概念 ，而partition就是分布式存储单元。这个设计是保证了海量数据处理的基础。我们可以对比一下，如果HDFS没有block的设计，一个100T的文件也只能单独放在一个服务器上面，那就直接占满整个服务器了，引入block后，大文件可以分散存储在不同的服务器上。
注意：
1.分区会有单点故障问题，所以我们会为每个分区设置副本数
2.分区的编号是从0开始的
一个topic可以认为一个一类消息，每个topic将被分成多个partition，每个partition在存储层面是append log文件。任何发布到此partition的消息都会被追加到log文件的尾部，每条消息在文件中的位置称为offset(偏移量)，offset为一个long型的数字，它唯一标记一条消息。每条消息都被append到partition中，是顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）。
每一条消息被发送到broker中，会根据partition规则选择被存储到哪一个partition。如果partition规则设置的合理，所有消息可以均匀分布到不同的partition里，这样就实现了水平扩展。（如果一个topic对应一个文件，那这个文件所在的机器I/O将会成为这个topic的性能瓶颈，而partition解决了这个问题）。在创建topic时可以在$KAFKA_HOME/config/server.properties中指定这个partition的数量，当然可以在topic创建之后去修改partition的数量。
在发送一条消息时，可以指定这个消息的key，producer根据这个key和partition机制来判断这个消息发送到哪个partition。partition机制可以通过指定producer的partition.class这一参数来指定，该class必须实现kafka.producer.Partitioner接口
5、消息Message
6、Kafka数据物理存储结构
kafka消息文件存储：由系统自动创建并维护
consumer_offsets-*: 各消费者的偏移量记录
.log消息主体，.index索引：日志段
其它机器上的副本：