哈尔滨专业做网站推广,怎么推广公众号,成都微信网站建设报价单,建筑模板规格尺寸本文来源公众号“五角钱的程序员”#xff0c;仅用于学术分享#xff0c;侵权删#xff0c;干货满满。
原文链接#xff1a;Kafka 是什么#xff1f;
你是一个程序员#xff0c;假设你维护了两个服务 A 和 B。B 服务每秒只能处理 100 个消息#xff0c;但 A 服务却每秒…本文来源公众号“五角钱的程序员”仅用于学术分享侵权删干货满满。
原文链接Kafka 是什么
你是一个程序员假设你维护了两个服务 A 和 B。B 服务每秒只能处理 100 个消息但 A 服务却每秒发出 200 个消息B 服务哪里顶得住分分钟被压垮。那么问题就来了有没有办法让 B 在不被压垮的同时还能处理掉 A 的消息当然有没有什么是加一层中间层不能解决的如果有那就再加一层。这次我们要加的中间层是 消息队列 Kafka。 Kafka
1 什么是消息队列
为了保护 B 服务我们很容易想到可以在 B 服务的内存中加入一个队列。 消息队列在B进程里
说白了它其实是个链表链表的每个节点就是一个消息。每个节点有一个序号我们叫它 Offset记录消息的位置。B 服务依据自己的处理能力消费链表里的消息。能处理多少是多少不断更新已处理 Offset 的值。 Offset是什么
但这有个问题来不及处理的消息会堆积在内存里如果 B 服务更新重启这些消息就都丢了。这个好解决将队列挪出来变成一个单独的进程。就算 B 服务重启也不会影响到了队列里的消息。 消息队列单独一个进程
这样一个简陋的队列进程其实就是所谓的消息队列。而像 A 服务这样负责发数据到消息队列的角色就是生产者像 B 服务这样处理消息的角色就是消费者。 生产者和消费者
但这个消息队列属实过于简陋像什么高性能高扩展性高可用它是一个都不沾。我们来看下怎么优化它。
2 高性能
B 服务由于性能较差消息队列里会不断堆积数据为了提升性能我们可以扩展更多的消费者, 这样消费速度就上去了相对的我们就可以增加更多生产者提升消息队列的吞吐量。 增加生产者和消费者
随着生产者和消费者都变多我们会发现它们会同时争抢同一个消息队列抢不到的一方就得等待这不纯纯浪费时间吗有解决方案吗有首先是对消息进行分类每一类是一个 topic然后根据 topic 新增队列的数量生产者将数据按 topic 投递到不同的队列中消费者则根据需要订阅不同的 topic。这就大大降低了 topic 队列的压力。 多个topic
但单个 topic 的消息还是可能过多我们可以将单个队列拆成好几段每段就是一个 partition分区每个消费者负责一个 partition。这就大大降低了争抢提升了消息队列的性能。 partition
3 高扩展性
随着 partition 变多如果 partition 都在同一台机器上的话就会导致单机 cpu 和内存过高影响整体系统性能。 于是我们可以申请更多的机器将 partition 分散部署在多台机器上这每一台机器就代表一个 broker。我们可以通过增加 broker 缓解机器 cpu 过高带来的性能问题。 broker
4 高可用
到这里其实还有个问题如果其中一个 partition 所在的 broker 挂了那 broker 里所有 partition 的消息就都没了。这高可用还从何谈起有解决方案吗有连你喜欢的女生都知道手机里多聊几个沸羊羊你却不知道要给 partition 加备胎吗我们可以给 partition 多加几个副本也就是 replicas将它们分为 Leader 和 Follower。Leader 负责应付生产者和消费者的读写请求而 Follower 只管同步 Leader 的消息。 replicas
将 Leader 和 Follower 分散到不同的 broker 上这样 Leader 所在的 broker 挂了也不会影响到 Follower 所在的 broker, 并且还能从 Follower 中选举出一个新的 Leader partition 顶上。这样就保证了消息队列的高可用。 高可用
5 持久化和过期策略
刚刚提到的是几个 broker 挂掉的情况那搞大点假设所有 broker 都挂了那岂不是数据全丢了为了解决这个问题我们不能光把数据放内存里还要持久化到磁盘中这样哪怕全部 broker 都挂了数据也不会全丢重启服务后也能从磁盘里读出数据继续工作。 持久化
但问题又来了磁盘总是有限的这一直往里写数据迟早有一天得炸。所以我们还可以给数据加上保留策略也就是所谓的 retention policy比如磁盘数据超过一定大小或消息放置超过一定时间就会被清理掉。
6 consumer group
到这里这个消息队列好像就挺完美了。但其实还有个问题按现在的消费方式每次新增的消费者只能跟着最新的消费 Offset 接着消费。如果我想让新增的消费者从某个 Offset 开始消费呢听起来这个需求很刁钻我举个例子你就明白了。
哪怕 B 服务有多个实例但本质上它只有一个消费业务方新增实例一般也是接着之前的 offset 继续消费。假设现在来了个新的业务方C 服务它想从头开始消费消息队列里的数据这时候就不能跟在 B 服务的 offset 后边继续消费了。
所以我们还可以给消息队列加入消费者组consumer group的概念B 和 C 服务各自是一个独立的消费者组不同消费者组维护自己的消费进度互不打搅。 消费者组互相独立
7 ZooKeeper
相信你也发现了组件太多了而且每个组件都有自己的数据和状态所以还需要有个组件去统一维护这些组件的状态信息于是我们引入 ZooKeeper 组件。它会定期和 broker 通信获取 整个 kafka 集群的状态以此判断 某些 broker 是不是跪了某些消费组消费到哪了。 加入ZooKeeper
Kafka 是什么
好了到这里当初那个简陋的消息队列就成了一个高性能高扩展性高可用支持持久化的超强消息队列没错它就是我们常说的消息队列 Kafka上面涉及到各种概念比如 partition 和 broker 什么的都出自它。 Kafka是什么
kafka 的应用场景
消息队列是架构中最常见的中间件之一使用场景之多堪称万金油比如上游流量忽高忽低想要削峰填谷提升 cpu/gpu 利用率用它。又比如系统过大消息流向盘根错节想要拆解组件降低系统耦合还是用它。再比如秒杀活动请求激增想要保护服务的同时又尽量不影响用户还得用它。当然凡事无绝对方案还得根据实际情况来定做架构做到最后都是在做折中。 Kafka的应用场景
总结 kafka 是消息队列像消息队列投递消息的是生产者消费消息的是消费者。增加生产者和消费者的实例个数可以提升系统吞吐。多个消费者可以组成一个消费者组不同消费者组维护自己的消费进度互不打搅。 kafka 将消息分为多个 topic每个 topic 内部拆分为多个 partition每个 partition 又有自己的副本不同的 partition 会分布在不同的 broker 上提升性能的同时还增加了系统可用性和可扩展性。
THE END !
文章结束感谢阅读。您的点赞收藏评论是我继续更新的动力。大家有推荐的公众号可以评论区留言共同学习一起进步。
