Kafka
是由Scale语言开发的一个多分区, 多副本且基于ZooKeeper协调的分布式消息系统, 目前kafka已经定位为一个分布式流处理平台, 它以高吞吐, 可持久化, 可水平扩展, 支持流数据处理等多种特性而被广泛使用
kafka是一个分布式流处理平台
一个典型的kafka体系架构包括若干个Producer, 若干个Broker, 若干个Consumer, 以及一个Zookeeper集群, 其中Zookeeper是kafka用来负责集群元数据的管理, 控制器的选举等操作的
Producer将消息发送到Broker, Broker负责将收到的消息存储到磁盘中, 而Consumer负责从Broker订阅并消费消息
高吞吐、低延迟:kakfa 最大的特点就是收发消息非常快,kafka 每秒可以处理几十万条消息,它的最低延迟只有几毫秒
高伸缩性: 每个主题(topic) 包含多个分区(partition),主题中的分区可以分布在不同的主机(broker)中
持久性、可靠性: Kafka 能够允许数据的持久化存储,消息被持久化到磁盘,并支持数据备份防止数据丢失,Kafka 底层的数据存储是基于 Zookeeper 存储的,Zookeeper 我们知道它的数据能够持久存储
容错性: 允许集群中的节点失败,某个节点宕机,Kafka 集群能够正常工作
高并发: 支持数千个客户端同时读写
消息系统:kafka和传统的消息系统, 都具备系统解耦, 冗余存储, 流量削峰, 缓冲, 异步通信, 扩展性, 可恢复性等功能, 与此同时kafka还提供了消息顺序性保障及回溯消费的功能
存储系统: kafka把消息持久化到硬盘, 相比于其它内存存储系统而言, 有效的降低了数据丢失的风险, 得益于kafka的消息持久化和多副本机制, 我们可以把kafka作为长期的数据存储系统来用, 只需要把对应的数据保留策略设置为"永久"或启用主题日志压缩功能即可
流式处理平台:kafka不仅为每个流行的流式处理框架提供了可靠的数据来源, 还提供了一个完整的流式处理类库, 比如窗口, 连接, 变换和聚合等各类操作
消息:Kafka 中的数据单元被称为消息
,也被称为记录,可以把它看作数据库表中某一行的记录
批次:为了提高效率, 消息会分批次
写入 Kafka,批次就代指的是一组消息
主题:消息的种类称为 主题
(Topic),可以说一个主题代表了一类消息。相当于是对消息进行分类。主题就像是数据库中的表
分区:主题可以被分为若干个分区(partition),同一个主题中的分区可以不在一个机器上,有可能会部署在多个机器上,由此来实现 kafka 的伸缩性
,单一主题中的分区有序,但是无法保证主题中所有的分区有序
生产者: 向主题发布消息的客户端应用程序称为生产者
(Producer),生产者用于持续不断的向某个主题发送消息
消费者:订阅主题消息的客户端程序称为消费者
(Consumer),消费者用于处理生产者产生的消息
消费者群组:生产者与消费者的关系就如同餐厅中的厨师和顾客之间的关系一样,一个厨师对应多个顾客,也就是一个生产者对应多个消费者,消费者群组
(Consumer Group)指的就是由一个或多个消费者组成的群体
偏移量:偏移量
(Consumer Offset)是一种元数据,它是一个不断递增的整数值,用来记录消费者发生重平衡时的位置,以便用来恢复数据
偏移量:消息在被追加到分区的时候都会分配一个特定的偏移量(Offset), 偏移量是消息在分区中的唯一标识, kafka通过它来保证消息在分区内的顺序性, 不过Offset并不跨越分区, 也就是说kafka保证的是分区有序而不是主题有序
broker: 一个独立的 Kafka 服务器就被称为 broker
,broker 接收来自生产者的消息,为消息设置偏移量,并提交消息到磁盘保存
broker 集群:broker 是集群
的组成部分,broker 集群由一个或多个 broker 组成,每个集群都有一个 broker 同时充当了集群控制器
的角色(自动从集群的活跃成员中选举出来)
副本:Kafka 中消息的备份又叫做 副本
(Replica),副本的数量是可以配置的,Kafka 定义了两类副本:领导者副本(Leader Replica) 和 追随者副本(Follower Replica),前者对外提供服务,后者只是被动跟随
重平衡:Rebalance。消费者组内某个消费者实例挂掉后,其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段
kafka可以通过增加分区的数量来实现水平扩展(值得注意的是我们可以增加主题的分区, 但不能减少分区的个数)
kafka为分区引入了多副本机制, 通过增加副本数量可以提升容灾能力
kafka通过多副本机制实现了故障的自动转移, 当kafka集群中的某个broker失效时仍能保证服务可用
kafka的副本之间是"一主多从"关系, 其中leader副本负责处理读写请求, follower副本只负责与leader副本的消息同步, 副本处于不同的broker中, 当leader副本出现故障时, 从follower副本中重新选举新的leader副本对外提供服务, kafka通过多副本机制实现了故障的自动转移, 当kafka集群中的某个broker失效时仍能保证服务可用
kafka默认监听9092端口
顺序读写:Kafka 采取顺序写入磁盘的方式,避免了随机磁盘寻址的浪费
零拷贝:Kafka 实现了零拷贝
原理来快速移动数据,避免了内核之间的切换
消息压缩:批处理能够进行更有效的数据压缩并减少 I/O 延迟
分批发送:批处理能够进行更有效的数据压缩并减少 I/O 延迟
活动跟踪:Kafka 可以用来跟踪用户行为,比如我们经常去淘宝购物,你打开淘宝的那一刻,你的登陆信息,登陆次数都会作为消息传输到 Kafka ,当你浏览购物的时候,你的浏览信息,你的搜索指数,你的购物爱好都会作为一个个消息传递给 Kafka ,这样就可以生成报告,可以做智能推荐,购买喜好等
传递消息:Kafka 另外一个基本用途是传递消息,应用程序向用户发送通知就是通过传递消息来实现的,这些应用组件可以生成消息,而不需要关心消息的格式,也不需要关心消息是如何发送的
度量指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告
日志记录:Kafka 的基本概念来源于提交日志,比如我们可以把数据库的更新发送到 Kafka 上,用来记录数据库的更新时间,通过kafka以统一接口服务的方式开放给各种consumer,例如hadoop、Hbase、Solr等
流式处理:流式处理是有一个能够提供多种应用程序的领域
限流削峰:Kafka 多用于互联网领域某一时刻请求特别多的情况下,可以把请求写入Kafka 中,避免直接请求后端程序导致服务崩溃
解耦
当一个系统或者模块调用了多个系统或者模块,相互之间的调用很复杂,维护起来很麻烦,但是这个调用其实是不需要直接同步调用接口的, 在这个时候我们就可以使用消息队列来达到解耦的目的
异步
当一个功能有许多后置的关联操作,这些操作又比较耗时, 我们可以考虑使用消息队列来实现, 比如创建订单后的日志 库存 短信 发货等功能都可以使用异步的方式来实现,
使用异步可以节约请求耗时给用户一个好的使用体验
削峰
系统平时的并发是500,服务器能够支持的并发是1000, 当某些时候请求并发会暴涨(比如做活动的时候)到5K,导致服务器无法负载,这个时候可以将请求写入到消息队列,
然后从消息队列中慢慢拉取请求,每秒就拉取1000个请求,不要超过自己每秒能处理的最大请求数量就ok,这样下来,哪怕是高峰期的时候,系统也不会挂掉
系统可用性降低
系统引入的外部依赖越多,越容易挂掉。如果消息队列挂的话,可能导致整个系统崩溃
系统复杂度提高
加入消息队列后,会引入新的问题, 例如:如何保证消息没有重复消费? 怎么处理消息丢失的情况? 怎么保证消息的有序传递? 等,这会大大提高系统的复杂度
一致性问题
A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了
RabbitMQ 是比较有代表性的,因为是基于主从(非分布式)做高可用性的,RabbitMQ 有三种模式:单机模式、普通集群模式、镜像集群模式。
单机模式: 就是 Demo 级别的,一般就是你本地启动了玩玩儿的,没人生产用单机模式
普通集群模式: 就是在多台机器上启动多个RabbitMQ实例,你创建的queue只会存放在一个RabbitMQ 实例上, 但是每个实例都同步queue的元数据, 这方案主要是提高吞吐量的,
就是说让集群中多个节点来服务某个queue的读写操作
在队列中每条消息只能由一个消费者消费, 而发布订阅模式中消息被广播到所有的消费者,可以被多个消费者消费
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。