腾讯建设网站视频,专业网站建设哪家权威,四川九江龙钢结构网架公司,简单网站建设方案策划消息队列前世今生
1.1 案例一#xff1a; 系统崩溃
首先大家跟着我想象一下下面的这个的场景#xff0c;
看到新出的游戏机#xff0c;太贵了买不起#xff0c;这个时候你突然想到#xff0c;今天抖音直播搞活动#xff0c;打开抖音搜索#xff0c;找到直播间以后 系统崩溃
首先大家跟着我想象一下下面的这个的场景
看到新出的游戏机太贵了买不起这个时候你突然想到今天抖音直播搞活动打开抖音搜索找到直播间以后你点开了游戏机详情页看到价格只要500。
这个时候我们分析一下就我们上面这几步操作在我们的程序背后做了什么事情。 首先请求会先到搜索商品这个服务上并记录下你的搜索行为;
然后点击商品的时候又记录了我们的点击商品这些数据最终都会通过计算分析;
目的是为了下一次给你更准确的信息这个时候问题来了如果这个时候负责记录存储的数据库被一个小哥删库跑路了。我们的所有操作都动不了了这个时候我们应该怎么办带着这个问题我们继续往下看
1.2 案例二服务能力有限
看到这个价格你非常心动商品即将在3分钟后开抢这个价格必须要抢到啊但此时在无数台手机的后面藏着无数和你一样饥渴的同学再来看看后面的程序又做了哪些事情呢 一堆人都发起了订单请求可是公司给的预算不够服务器的配置太弱订单服务只能同时处理10个订单请求。这个时候我们又该怎么办呢。继续往下看
1.3案例三链路耗时长尾
在我们点击提交订单之后这个怎么一直转圈圈卡在这个页面啊等了半分钟后
啊终于抢到了不过这个app也太慢了下次不用了。我们进一步看一下这次问题出在哪里了 一通分析发现库存服务和订单服务都挺快的但是最后通知商家30s这一步咋这么慢是不是还可以进行优化呀
1.4 案例四日志存储
在字节跳动的会议室里传出了悲伤的声音因为刚刚有服务器坏掉了我们的本地日志都丢掉了没有了日志我们还怎么去修复那些刚刚出现的那些问题周围一片寂静突然小张站出来缓缓的说了一句话众人才露出了微笑准备下班离开大家能猜到小张到底说的什么吗
1.1.1 案例一 解决方案 1.2.1
既然 服务器等其他原因导致 处理能力有限 我们可以把大量请求放到消息队列每次拿10个处理 1.3.1
把“发起订单”请求放到《消息队列》异步做那三个事逻辑上在库存-1的时候就可以返回下单成功剩下的时候做商家通知不用等他完事了再return 成功 1.4.1 2.0 消息队列 2.1消息队列发展历程
消息中间件其实诞生的很早早在1983年互联网应用还是一片荒芜的年代有个在美国的印度小哥Vivek就设想了一种通用软件总线世界上第一个现代消息队列软件The Information Bus(TIB)TIB受到了企业的欢迎这家公司的业务发展引起了当时最牛气的IT公司IBM的注意于是他们一开始研发了自己消息队列软件于是才有了后来的wesphere mq再后来微软也加入了战斗。
接近2000年的时候互联网时代已经初见曙光全球的应用程序得到了极大地丰富对于程序之间互联互通的需求越来越强烈但是各大IT公司之间还是牢牢建立着各种技术壁垒以此来保证自己的商业利益所以消息中间件在那个时候是大型企业才能够用的起的高级玩意。
但是时代的洪流不可逆转有壁垒就有打破壁垒的后来者2001年sun发布了JMS技术试图在各大厂商的层面上再包装一层统一的java规范。java程序只需要针对jms api编程就可以了不需要再关注使用了什么样的消息中间件但是jms仅仅适用于java。
2004年AMQP高级消息队列协议诞生了才是真正促进了消息队列的繁荣发展任何人都可以针对AMQP的标准进行编码。有好的协议指导再加上互联网分布式应用的迅猛发展成为了消息中间件一飞冲天的最大动力程序应用的互联互通发布订阅最大契合了消息中间件的最初的设计初衷。
除了刚才介绍过的收费中间件后来开源消息中间件开始层出不穷常见比较流行的有ActiveMQ、RabbitMQ 、Kafak、阿里的RocketMQ以及目前存算分离的Pulsar在目前互联网应用中消息队列中间件基本上成为标配。 2.1.1 业界消息队列对比 3.0 Kafka
3.1使用场景
一般是 离线的消息处理、Metrics程序运行当中程序状态的采集数据、用户行为
3.2 如何使用
引入Kafka 的SDK 实现上游的生产逻辑消费者拉取 第一步首先创建一个Kafka集群但如果你在字节工作恭喜你这一步消息团队的小伙伴已经帮你完成了
第二步需要在这个集群中创建一个Topic并且设置好分片数量
第三步引入对应语言的SDK配置好集群和Topic等参数初始化一个生产者调用Send方法将你的Hello World发送出去
第四步引入对应语言的SDK配置好集群和Topic等参数初始化一个消费者调用Poll方法你将收到你刚刚发送的Hello World
3.3 基本概念 TopicKakfa中的逻辑队列可以理解成每一个不同的业务场景就是一个不同的topic对于这个业务来说所有的数据都存储在这个topic中
ClusterKafka的物理集群每个集群中可以新建多个不同的topic
Producer顾名思义也就是消息的生产端负责将业务消息发送到Topic当中
Consumer消息的消费端负责消费已经发送到topic中的消息
Partition通常topic会有多个分片不同分片直接消息是可以并发来处理的这样提高单个Topic的吞吐对于每一个Partition来说每一条消息都有一个唯一的Offset消息在partition内的相对位置信息并且严格递增
3.3.2 Offset 3.3.3 Replica分片的副本分布在不同的机器上可用来容灾
Leader对外服务Follower异步去拉取leader的数据进行一个同步尽量保持同步
如果leader挂掉了可以将ISR的Follower提升成leader再对外进行服务
ISRIn-Sync Replicas
意思是同步中的副本对于Follower来说始终和leader是有一定差距的但当这个差距比较小的时候我们就可以将这个follower副本加入到ISR中差距大就提出ISR不在ISR中的副本是不允许提升成Leader的 3.4 数据复制
下面这幅图代表着Kafka中副本的分布图。
图中Broker代表每一个Kafka的节点所有的Broker节点最终组成了一个集群。
整个图表示图中整个集群包含了4个Broker机器节点集群有两个Topic分别是Topic1和Topic2Topic1有两个分片Topic2有1个分片每个分片都是三副本的状态。
这里中间有一个Broker同时也扮演了Controller的角色
Controller是整个集群的大脑负责对副本和Broker进行分配再告诉各个Broker怎么去处理 3.5 Kafka架构
在集群的基础上还有一个模块是ZooKeeper这个模块其实是存储了集群的元数据信息和Controller配合
比如副本的分配信息等等Controller计算好的方案都会放到这个地方 3.6 一条消息的自述
从一条消息的视角来看看完整的处理流程了解一下Kafka为什么可以支撑如此高的吞吐 一秒几千万条数据 吞吐量达不到要求 不能等 3.7.1 Producer-批量发送 3.7.2 Producer-数据压缩
默认选择 Snappy压缩算法当前 经过测试 ZSTD算法在计算性能、压缩率等更加优秀 3.8 Broker-数据存储
如何写入到磁盘呢我们先来看一下Kafka最终存储的文件结构是什么样子的 在每一个Broker都分布着不同Topic的不同分片不同副本以Log形式 写入磁盘Log会切分成不同的有序的LogSegment.log存真实数据.index 日志具体位置的映射 只看一个盘面磁头-磁道-扇区 寻道成本高 3.8.2 顺序写
采用顺序写的方式进行写入以提高写入效率 3.8.3如何找到消息
此时我们的消息写入到Broker的磁盘上了那这些数据又该怎么被找到然后用来消费呢 3.8.4偏移量索引文件
介绍文件文件名是文件中第一条消息的offset
第一步通过二分找到小于目标文件的最大文件 通过二分找到小于目标offset最大的索引位置再遍历找到目标offset 3.8.5 时间戳文件索引
如果我们需要使用时间戳来寻找的时候和offset相比只是多加了以及索引也就是通过二分找到时间戳对应的offset再重复之前的步骤找到相应的文件数据 3.8.6 传统数据拷贝 零拷贝
从磁盘读到内核态 再拷贝到用户态的应用空间 然后 网卡发送到 消费者 零拷贝 直接从内核空间 传到NIC网卡 减少三次传统拷贝 3.9 Consumer—消息的接收端
对于一个Consumer Group来说多个分片可以并发的消费这样可以大大提高消费的效率
但需要解决的问题是Consumer和Partition的分配问题 也就是对于每一个Partition来讲该由哪一个Consumer来消费的问题。
对于这个问题我们一般有两种解决方法手动分配和自动分配 3.9.1 Consumer—Low Level
第一手动分配也就是Kafka中所说的Low Level消费方式进行消费
这种分配方式的一个好处就是启动比较快因为对于每一个Consumer来说启动的时候就已经知道了自己应该去消费哪个消费方式好比图中的Consumer Group1来说Consumer1去消费Partition 1,2,3 Consumer2去消费456 Consumer3去消费78。
这些Consumer在启动的时候就已经知道分配方案了但这样这种方式的缺点又是什么呢想象一下如果我们的Consumer3挂掉了我们的7,8分片是不是就停止消费了。
又或者如果我们新增了一台Consumer4那是不是又需要停掉整个集群重新修改配置再上线保证Consumer4也可以消费数据
其实上面两个问题有时候对于线上业务来说是致命的。 3.9.1 Consumer—High Level
所以Kafka也提供了自动分配的方式这里也叫做High Level的消费方式
简单的来说就是在我们的Broker集群中对于不同的Consumer Group来讲都会选取一台Broker当做Coordinator协调者
而Coordinator的作用就是帮助Consumer Group进行分片的自动分配也叫做分片的rebalance
使用这种方式如果ConsumerGroup中有发生宕机或者有新的Consumer加入整个partition和Consumer都会重新进行分配来达到一个稳定的消费状态 3.10 Consumer Rebalance 3.11 Kafka—数据复制问题
通过前面的介绍我们可以知道对于Kafka来说
每一个Broker上都有不同topic分区的不同副本而每一个副本会将其数据存储到该Kafka节点上面对于不同的节点之间通过副本直接的数据复制来保证数据的最终一致性与集群的高可用。
3.12 Kafka—重启操作 举个例子来说如果我们对一个机器进行重启
首先我们会关闭一个Broker此时如果该Broker上存在副本的Leader那么该副本将发生leader切换切换到其他节点上面并且在ISR中的Follower副本
可以看到图中是切换到了第二个Broker上面 而此时因为数据在不断的写入对于刚刚关闭重启的Broker来说和新Leader之间一定会存在数据的滞后此时这个Broker会追赶数据重新加入到ISR当中 当数据追赶完成之后我们需要回切leader
这一步叫做prefer leader目的是为了避免在一个集群长期运行后所有的leader都分布在少数节点上导致数据的不均衡
通过上面的一个流程分析我们可以发现对于一个Broker的重启来说需要进行数据复制所以时间成本会比较大比如一个节点重启需要10分钟一个集群有1000个节点如果该集群需要重启升级则需要10000分钟那差不多就是一个星期这样的时间成本是非常大的。
有同学可能会说老师可以不可以并发多台重启呀问的好不可以。
为什么呢在一个 两副本一个分片 有两个副本的集群中重启了两台机器对某一分片来讲可能两个分片都在这两台机器上面则会导致该集群处于不可用的状态影响整个Topic。这是更不能接受的。
3.13-替换扩容缩容操作 如果是替换和刚刚的重启有什么区别
其实替换本质上来讲就是一个需要 追 更多数据的重启操作因为正常重启只需要追一小部分而替换则是需要复制整个leader的数据时间会更长
扩容呢当分片分配到新的机器上以后也是相当于要从0开始复制一些新的副本
而缩容缩容节点上面的分片也会分片到集群中剩余节点上面分配过去的副本也会从0开始去复制数据
以上三个操作均有数据复制所带来的时间成本问题所以对于Kafka来说运维操作带来的时间成本是不容忽视的
3.14 负载不均衡 这个场景当中同一个Topic有4个分片两副本
可以看到对于分片1来说数据量是明显比其他分片要大的当我们机器IO达到瓶颈的时候可能就需要把第一台Broker上面的Partition3 迁移到其他负载小的Broker上面接着往下看 但我们的数据复制又会引起Broker1的IO升高所以问题就变成了我为了去解决IO升高但解决问题的过程又会带来更高的IO所以就需要权衡IO设计出一个极其复杂的负载均衡策略
问题总结 我们对以上两个问题进行总结
第一因为有数据复制的问题所以Kafka运维的时间成本和人力人本都不低
第二对于负载不均衡的场景我们需要有一个较为复杂的解决方案进行数据迁移从而来权衡IO升高的问题
除了以上两个问题以外Kafka自身还存在其他的问题
比如Kafka没有自己的缓存在进行数据读取的时候只有Page Cache可以用所以不是很灵活
另外在前面的介绍当中相信大家也了解到了Kafka的Controller(负责分片方案)和Coordinator都是和Broker部署在一起的Broker因为承载大量IO的原因会导致Controller和Coordinator的性能下降如果到一定程度可能会影响整个集群的可用性
4.0 BMQ
字节自研的消息队列ByteMQ简称BMQ
BMQ兼容Kafka协议存算分离云原生消息队列初期定位是承接高吞吐的离线业务场景逐步替换掉对应的Kafka集群我们来了解一下BMQ的架构特点 非常感谢您阅读到这里如果这篇文章对您有帮助希望能留下您的点赞 关注 收藏 评论感谢支持
