消息队列kafka部分原理总结

一、为什么要有消息系统。
1、解耦合。
一个事件需要不同的系统提供服务，不同的服务处理的能力不同。（可可豆制作成巧克力的例子）
2、异步控制。
秒杀活动中，可以将风险控制、库存锁定与减库存、生成订单异步处理。
3、流量控制
网关接收请求、请求放在队列中，后端从队列中依次处理请求。

二、kafka消息队列
broker是kafka的实例。
producer是生产者。
consumer为消息消费者。
topic：消息的主题，就如关系型数据库中的表。
partition：topic的分区，一个topic可以有多个分区，且分散在不同的服务器上，主要作用是用来提高负载和扩展，一个分区就相当于一个文件夹。
replication：副本，当leader故障则会选择一个follwer作为leader，
消费者组：指定group-id相同则为同一个组，同一个个组的消费者不能消费同一个分区，若要重复消费数据，则可以指定为不同的消费者组。
zookeeper：kafka集群注册在zookeeper上，用来保存监听集群节点，保证可用性。
2、工作流程

kafka发送数据的时候永远是找leader，将数据写入leader，然后follower会主动去leader中同步数据。

怎么保证消息不丢失呢？
那就是通过ACK应答机制！在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据，这个参数可设置的值为0、1、all。
kafka集群分为主从节点，节点通过在zookeeper中注册成为Controller，其他的Kafka broker叫Kafka Broker follower。
二、kafka高性能
1、顺序写的问题
简单来说就是将批量此的数据统一存储到磁盘。
2、零拷贝
数据要从硬盘或者网络中读取，需要从硬盘拷贝到OS缓存，再从OS缓存拷贝到应用缓存再次发送到socket缓存。
零拷贝是CPU直接操作读取数据发送到网络socket缓存中，减少拷贝占用的io资源和上下文切换。
PS：linux中的零拷贝技术
https://www.ibm.com/developerworks/cn/linux/l-cn-zerocopy1/index.html

三、kafka分段存储
1、每个topic都可以分为一个或多个partition，kafka是逻辑上的，那partition就是比较具体的东西了！Partition在服务器上的表现形式就是一个一个的文件夹，每个partition的文件夹下面会有多组segment文件，每组segment文件又包含.index文件、.log文件、.timeindex文件三个文件， log文件就实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息。
2、稀松索引
当kafka每写入4kb的数据的话会记录以下offset。
读取的时候通过二分查找找到离目标索引最近的前一个位置，然后顺序查找到目标数据。

kafka高可用之冗余设计
1、创建主题的时候会创建分区个数和多个副本。分区分为leader和follower之分。
当读写数据的时候会操作leader，写数据的时候会写进leader，然后follower会去leader同步数据。
2、ISR leader partition会维护一个ISR列表，作为备用列表。 PS：会根据一定的规则清楚差异化较大的brokerid号。

Kafka的架构思想总结：
1、高可用：多副本。
2、高并发：优秀的网络架构。
3、高性能：写数据：顺序写-》写OS-cache-》写磁盘。 读数据：a。根据稀松索引 b.零拷贝：减少了应用程序与OS的上下文切换。

集群的评估方式
1、容量评估、
举例一个10亿请求的需求。
0：00 --08：00 只占20%,其他16个小时有80%的请求：8亿请求。
1620%=3 小时。就是3个小时处理了80%的数据量6.4亿。
6.4亿除以3小时=5.5万/s。qps=5万
如果灭个请求的大小为50kb。
10亿请求50kb = 46T * 2个副本 = 92T * 保留三天数据 276T

1、服务器选择：mysql kafka一般选用物理机。
2、5.5万qps/s * 4倍 = 20万qps。一天物理机承受4万qps，需要5台物理机。
3、硬盘选择： SSD硬盘 SAS盘。SSD硬盘随机读写性能好，mysql合适。
顺序写性能和SAS硬盘的性能差不多。
276T / 5台服务器 每台50T，11个硬盘，没一个硬盘7T。
2、内存评估
10亿请求，约100个topic
100 topic * 5 partiton * 2 副本 = 1000 partition
储存文件的.log文件默认1G，内存最好1000 * 1G = 1000G
但是只需要25%的数据在内存即可，1000G*25% = 250G
250G / 5 = 50G内存
50G + 10G（JVM）= 60G内存，这样内存大约64G
3、cpu评估
需要多少cpu core，需要根据多少个线程。
a.一台kafka服务器需要多少个线程
1、aceptor 1个
2、processor 3 一般扩展到6-9
3、处理请求线程 8个 一般扩展至32
4、定时清理线程、同步数据线程、ISR清理线程
一个kafka服务启动会有一百多个线程。
b.cpu core 4个-----几十个线程打满
8 -------轻松带起几十个
16个--------（32 最好）
2cpu * 8 = 16 cpu core
4、网络评估
高峰期5.5万个请求 / 5台服务器 = 1万个请求
10000 * 50kb = 488M
每秒接收 488M数据 + 数据同步488 * 2 = 976M
但是千兆的网卡可使用约为700M ，所以选用万兆网卡

kafka的基本使用
1、基本配置
number.network.thread 网络连接线程数
num.io.thread 处理请求线程数
log.dir 生产环境中，一个磁盘对应一个目录 ，如log.dir = data0/usr/,data1/usr
log.retention.hours = 168 (7天) 数据保留时间
message.may.bytes: 最大接收消息977kb
2、kafka搭建完成后进行 压力测试
3、kafka运维
运维工具 kafka manage
场景一：topic数据量太大，要增加partition
场景二：核心业务需要增加副本。
场景三：负载不均衡，手动迁移
场景四：某个broker上的leader partition过多，kakfa会自动进行负载均衡。配置略
kafka生产者基本使用
基本案例
bootstrap.servers //拉取元数据进行缓存
发送消息，如果不指定key，会轮询发送到不同分区; 指定key会使用key计算出一个hash，发送到对应分区
生产者提高吞吐量：
buffer.memory 默认32MB 缓冲区大小
compression.type 是否压缩（lz4）
batch.size batch发送批次大小 默认16kb
实际环境中，如果一条消息大小比较大，则增大发送批次，一般调大
linger.ms 默认为0 一般设置100ms，每100ms内，无论batch是都满，都会发送。
Exception
1、leaderNotAvableException 某个broker挂掉，找不到leader partition
2、notControllerException
3、NetworkException
解决方案：a.重试。配置retries参数
重试几次不行会返回异常。收送处理发送到备用链路。
重试机制
重试默认间隔retry.backoff.ms 默认100ms， 重试会导致顺序错误。
设置max.in.flight.request.per.connettion为1，则会顺序发送。
生产者ACK参数
request.reqiured.ack = 0 不关心是否发送，效率最高
= 1，写入leader成功才算成功；
= -1，写入成功，并且ISR列表中所有follower已经同步完成才算成功。
kafka服务端：
min.insync.replicas 默认为1，至少副本数 如果为2，那么当ISR列表为1时会报错。
kafka数据不丢失方案：
副本数 >= 2;
ACK = -1;
min.insync.reolicas > =2
自定义分区写入规则
自定义分区实现Partitioner接口。

Kafka的基本使用
1、kafka消费者的基本使用
案例：用户购买商品会产生积分。生成订单、取消订单发送消息到kafka。这时候就需要设置key，设置id为key，这样生成订单和取消订单都会发送消息到同一个分区，避免先取消订单的消息先消费。
2、消费者组
一个分区只能被一个消费者组消费。
3、消费者使用基本步骤
1、指定bootstap.servers
2、指定group-id
3、指定消费的主题。
4、消费主题
2、偏移量管理
a、从娜儿开始消费—offset；最新版本提交到kafka的内部topic _consumer_offset中保存。
提交的时候group-id+topic+分区号，value就是offset数据。
3、如何得知消费者
1.消费者心跳的时间间隔
heartbeat.interval.ms=3000
2.消费时超时
session.timeout,ms=1000
3.两次poll之间的最大时间间隔
max.poll.interval.ms=5000
4、消费者核心参数
1.fetch.max.bytes 默认1M
消费者最大消费的消息字节
2.max.poll.record 默认500条
消费者一次poll拉取的最大消息数量
3.connection.max.idle.ms
consumer和broker连接中如果超过一定时间没有消费到消息,此时会回收连接,下次再去连接
为了保障消费者,建议设置为-1,即不断开连接,一致等待消息
4.enable.auto.commit:true
开启自动提交消费偏移量
5.auto.commit.interval.ms:
每隔多久提交一次,默认5000ms
6.auto.offset.reset:
a、earliest:如果各个分区已提交offset,从提交的offset消费;否则,从头开始消费
b、latest:如果各个分区已提交offset,从提交的offset消费;否则,消费该分区新产生的数据[推荐这个参数]
c、none:如果各个分区已提交offset,从提交的offset消费；
5、消费者如何实现rebanlance
1、什么是condiinator？ 每个消费组会选择一个broker最为cordinator,负责监听消费组内各个消费者的心跳,消费端端是否宕机,然后开启rebalance。
2、rebanlance算法
通过groupId计算hash值然后对_customer_offsets分区数量进行取模，对应的broker就是cordinator。
6、消费组消费topic的步骤
1、消费组下的每个消费者都会发送joingroup到cordinator的broker
2、leader consumer
3、cordinator把消费topic详情发送给leader consumer
4、leader consumer制定消费策略,发送给cordinator
5、下发消费策略
7、rebalanece策略
range：按照序号均分
round-robin：轮询
sticky策略:原本属于自己的还属于自己，多余的均匀分配过去。
二、broker管理
1、LEO和HW
LEO：最新的offset+1)
HW：高水位，leader LEO和follower LEO同步了,HW之前的数据对consumer可消费,。
LEO更新
HW更新：HW为所有follower的HW的最小值
2、controller broker
1、controlker broker通过向zookeeper创建目录，谁先创建完成，谁是controller。
2、controller会监听很多个目录，controller监听到目录变化值后会同步给其他broker。

3、broker管理=时间轮询机制
时间轮，时间轮其实就是一个数组，其时间复杂度为O（1）。
tickms:时间轮间隔{毫秒}
wheelSize:时间轮分区数量
interval:实践论的总时长跨度
currenttime:当前时间指针
就如同水表原理。时间轮的间隔单位每一个时间轮间隔是上一个时间轮的总值。