全栈工程师是做网站吗,微信公众号做的网站,做网站建设销售工资高吗,企业网络拓扑图及配置目录
一、基本概念
二、技术特性
三、设计思想
四、运维建议 一、基本概念 Apache kafka 是一个分布式的基于push-subscribe的消息系统#xff0c;它具备快速、可扩展、可持久化的特点。它的最大的特性就是可以实时的处理大量数据以满足各种需求场景#xff1a;比如基于h…目录
一、基本概念
二、技术特性
三、设计思想
四、运维建议 一、基本概念 Apache kafka 是一个分布式的基于push-subscribe的消息系统它具备快速、可扩展、可持久化的特点。它的最大的特性就是可以实时的处理大量数据以满足各种需求场景比如基于hadoop的批处理系统、低延迟的实时系统、storm/spark流式处理引擎。
ProducerProducer即生产者消息的产生者是消息的入口。kafka clusterBrokerBroker是kafka实例每个服务器上有一个或多个kafka的实例我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号如broker-0、broker-1等。Topic消息的主题可以理解为消息的分类kafka的数据就保存在topic。在每个broker上都可以创建多个topic。PartitionTopic的分区每个topic可以有多个分区分区的作用是做负载提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的partition的表现形式就是一个一个的文件夹Replication:每一个分区都有多个副本副本的作用是做备胎。当主分区Leader故障的时候会选择一个备胎Follower上位成为Leader。在kafka中默认副本的最大数量是10个且副本的数量不能大于Broker的数量follower和leader绝对是在不同的机器同一机器对同一个分区也只可能存放一个副本包括自己。Message每一条发送的消息主体。Consumer消费者即消息的消费方是消息的出口。Consumer Group我们可以将多个消费组组成一个消费者组在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据这也是为了提高kafka的吞吐量 二、技术特性
高吞吐量、低延迟kafka每秒可以处理几十万条消息它的延迟最低只有几毫秒
可扩展性kafka集群支持热扩展
持久性、可靠性消息被持久化到本地磁盘并且支持数据备份防止数据丢失
容错性允许集群中节点失败若副本数量为n,则允许n-1个节点失败
高并发支持数千个客户端同时读写
Consumergroup各个consumer可以组成一个组每个消息只能被组中的一个consumer消费如果一个消息可以被多个consumer消费的话那么这些consumer必须在不同的组。
消息状态在Kafka中消息的状态被保存在consumer中broker不会关心哪个消息被消费了被谁消费了只记录一个offset值指向partition中下一个要被消费的消息位置这就意味着如果consumer处理不好的话broker上的一个消息可能会被消费多次。
消息持久化Kafka中会把消息持久化到本地文件系统中并且保持极高的效率。
消息有效期Kafka会长久保留其中的消息以便consumer可以多次消费当然其中很多细节是可配置的。
批量发送Kafka支持以消息集合为单位进行批量发送以提高push效率。
push-and-pull : Kafka中的Producer和consumer采用的是push-and-pull模式即Producer只管向broker push消息consumer只管从broker pull消息两者对消息的生产和消费是异步的。
Kafka集群中broker之间的关系不是主从关系各个broker在集群中地位一样我们可以随意的增加或删除任何一个broker节点。
负载均衡方面 Kafka提供了一个 metadata API来管理broker之间的负载对Kafka0.8.x而言对于0.7.x主要靠zookeeper来实现负载均衡。
同步异步Producer采用异步push方式极大提高Kafka系统的吞吐率可以通过参数控制是采用同步还是异步方式。
分区机制partitionKafka的broker端支持消息分区Producer可以决定把消息发到哪个分区在一个分区中消息的顺序就是Producer发送消息的顺序一个主题中可以有多个分区具体分区的数量是可配置的。分区的意义很重大后面的内容会逐渐体现。
三、设计思想
整体架构如下 Kafka 集群包含多个 broker。一个 topic 下通常有多个 partitionpartition 分布在不同的 Broker 上用于存储 topic 的消息这使 Kafka 可以在多台机器上处理、存储消息给 kafka 提供给了并行的消息处理能力和横向扩容能力。
消费者架构如下 基本流程
Consumer Group中的Consumer向各自注册的分区上进行消费消息
Consumer消费消息后会将当前标注的消费位移信息以消息的方式提交到位移主题中记录一个Consumer Group中多个Consumer会做负载均衡如果一个Consumer宕机会自动切换到组内别的Consumer进行消费
关键的点
Consumer Group组内多个的Consumer可以公用一个Consumer Id组内所有的Consumer只能注册到一个分区上去消费一个Consumer Group只能到一个Topic上去消费
位移主题
位移主题的主要作用是保存Kafka消费者的位移信息 Kafka最新版本中位移主题的处理方式
Consumer的位移信息offset会当作一条条普通消息提交到位移主题_consumer_offsets中。
四、运维建议 第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。所以可以估算消费这条消息后处理的时间设置max.poll.interval.ms大于等于这个时长多1min。
如果这些都设置好还是出现rebalance可以排查一下Consumer 端的 GC 表现比如是否出现了频繁的 Full GC 导致的长时间停顿从而引发了 Rebalance。 将 session.timeout.ms 设置成 6s 主要是为了让 Coordinator 能够更快地定位已经挂掉的 Consumer。 当生产者往主题写入消息的速度超过了应用程序验证数据的速度或者消息的数量较大可采取横向伸缩的策略提高消费效率分为两种1.群组内增加消费者 2.增加消费者群组 消费者组订阅某一主题时需要注意建议该消费组内消费者数量不要超过该主题的分区数否则将可能产生闲置的消费者不会接收到任何消息。消费者组订阅一个主题主题下的每个分区只对应组中一个消费者不会出现对应多个消费者的情况。如果分区数大于或者等于组中的消费者实例数一个消费者会负责多个分区建议分区数和消费者数量相等一个消费者负责一个分区。避免重平衡 在 Rebalance 过程中所有 Consumer 实例都会停止消费等待 Rebalance 完成。 Rebalance 的弊端 1.Rebalance 影响 Consumer 端 TPS。因为rebalance过程中kafka会停止消费 2.Rebalance 要完成需要比较久的时间。 3.Rebalance 效率不高每次都要全部consumer参加。 Rebalance 的触发条件有 3 个。 组成员数发生变更。比如有新的 Consumer 实例加入组或者离开组抑或是有 Consumer 实例崩溃被“踢出”组。99% 都是这个原因订阅主题数发生变更。Consumer Group 可以使用正则表达式的方式订阅主题比如 consumer.subscribe(Pattern.compile(“t.*c”)) 就表明该 Group 订阅所有以字母 t 开头、字母 c 结尾的主题。在 Consumer Group 的运行过程中你新创建了一个满足这样条件的主题那么该 Group 就会发生 Rebalance。订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。当分区数增加时就会触发订阅该主题的所有 Group 开启 Rebalance。 如何避免这99%的情况发生的rebalance 可以从consumer组员变化的原因分析起 第一类非必要 Rebalance 是因为未能及时发送心跳导致 Consumer 被“踢出”Group 而引发的。 当 Consumer Group 完成 Rebalance 之后每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求表明它还存活着。如果某个 Consumer 实例不能及时地发送这些心跳请求Coordinator 就会认为该 Consumer 已经“死”了从而将其从 Group 中移除然后开启新一轮 Rebalance。 这个发送心跳的间隔在Consumer 端有个参数叫 session.timeout.ms默认值是 10 秒即如果 Coordinator 在 10 秒之内没有收到 Group 下某 Consumer 实例的心跳它就会认为这个 Consumer 实例已经挂了。session.timout.ms 决定了 Consumer 存活性的时间间隔。 除了这个参数Consumer 还提供了一个允许你控制发送心跳请求频率的参数就是 heartbeat.interval.ms。这个值设置得越小Consumer 实例发送心跳请求的频率就越高。频繁地发送心跳请求会额外消耗带宽资源但好处是能够更加快速地知晓当前是否开启 Rebalance因为目前 Coordinator 通知各个 Consumer 实例开启 Rebalance 的方法就是将 REBALANCE_NEEDED 标志封装进心跳请求的响应体中。 Consumer 端还有一个参数用于控制 Consumer 实际消费能力对 Rebalance 的影响即 max.poll.interval.ms 参数默认5minConsumer 端应用程序两次调用 poll 方法的最大时间间隔表示你的 Consumer 程序如果在 5 分钟之内无法消费完 poll 方法返回的消息那么 Consumer 会主动发起“离开组”的请求Coordinator 也会开启新一轮 Rebalance。 所以可以修改为以下经验推荐值 设置 session.timeout.ms 6s。设置 heartbeat.interval.ms 2s。要保证 Consumer 实例在被判定为“dead”之前能够发送至少 3 轮的心跳请求即 session.timeout.ms 3 * heartbeat.interval.ms。
