福永网站建设公司有没有,无代码网站建设,站长网ppt模板下载,重庆网站建设技术支持文章目录1、Kafka是什么#xff1f;2、partition的数据文件#xff08;offffset#xff0c;MessageSize#xff0c;data#xff09;3、数据文件分段 segment#xff08;顺序读写、分段命令、二分查找#xff09;4、负载均衡#xff08;partition会均衡分布到不同broker…
文章目录1、Kafka是什么2、partition的数据文件offffsetMessageSizedata3、数据文件分段 segment顺序读写、分段命令、二分查找4、负载均衡partition会均衡分布到不同broker上5、批量发送6、压缩GZIP或Snappy7、消费者设计8、Consumer Group9、如何获取topic主题的列表10、生产者和消费者的命令行是什么11、consumer是推还是拉12、讲讲kafka维护消费状态跟踪的方法13、讲一下主从同步。14、为什么需要消息系统mysql 不能满足需求吗15、Zookeeper对于Kafka的作用是什么16、Kafka判断一个节点是否还活着有那两个条件17、Kafka与传统MQ消息系统之间有三个关键区别18、讲一讲kafka的ack的三种机制19、消费者如何不自动提交偏移量由应用提交20、消费者故障出现活锁问题如何解决21、如何控制消费的位置22、kafka分布式不是单机的情况下如何保证消息的顺序消费23、kafka的高可用机制是什么24、kafka如何减少数据丢失25、kafka如何不消费重复数据比如扣款我们不能重复的扣1、Kafka是什么
答
Kafka是一种高吞吐量、分布式、基于发布/订阅的消息系统最初由LinkedIn公司开发使用Scala语言编写目前是Apache的开源项目。 broker Kafka服务器负责消息存储和转发 topic消息类别Kafka按照topic来分类消息 partition topic的分区一个topic可以包含多个partition topic 消息保存在各个partition上4. offset消息在日志中的位置可以理解是消息在partition上的偏移量也是代表该消息的唯一序号 Producer消息生产者 Consumer消息消费者 Consumer Group消费者分组每个Consumer必须属于一个group Zookeeper保存着集群 broker、 topic、 partition等meta 数据另外还负责broker故障发现 partition leader选举负载均衡等功能 2、partition的数据文件offffsetMessageSizedata
答
partition中的每条Message包含了以下三个属性 offsetMessageSizedata其中offset表示Message在这个partition中的偏移量offset不是该Message在partition数据文件中的实际存储位置而是逻辑上一个值它唯一确定了partition中的一条Message可以认为offset是partition中Message的 id MessageSize表示消息内容data的大小data为Message的具体内容。
3、数据文件分段 segment顺序读写、分段命令、二分查找
答
Kafka为每个分段后的数据文件建立了索引文件文件名与数据文件的名字是一样的只是文件扩展名为index。 index文件中并没有为数据文件中的每条Message建立索引而是采用了稀疏存储的方式每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间从而可以将索引文件保留在内存中。 4、负载均衡partition会均衡分布到不同broker上
答
由于消息topic由多个partition组成且partition会均衡分布到不同broker上。因此为了有效利用broker集群的性能提高消息的吞吐量producer可以通过随机或者hash等方式将消息平均发送到多个partition上以实现负载均衡。 5、批量发送
答
是提高消息吞吐量重要的方式 Producer端可以在内存中合并多条消息后以一次请求的方式发送了批量的消息给broker从而大大减少broker存储消息的IO操作次数。但也一定程度上影响了消息的实时性相当于以时延代价换取更好的吞吐量。
6、压缩GZIP或Snappy
答
Producer端可以通过GZIP或Snappy格式对消息集合进行压缩。 Producer端进行压缩之后在Consumer端需进行解压。压缩的好处就是减少传输的数据量减轻对网络传输的压力在对大数据处理上瓶颈往往体现在网络上而不是CPU压缩和解压会耗掉部分CPU资源。
7、消费者设计
答
Kafka架构图8、Consumer Group
答
同一Consumer Group中的多个Consumer实例不同时消费同一个partition等效于队列模式。 partition内消息是有序的 Consumer通过pull方式消费消息。 Kafka不删除已消费的消息对于partition顺序读写磁盘数据以时间复杂度O(1)方式提供消息持久化能力。
9、如何获取topic主题的列表
答
bin/kafka-topics.sh --list --zookeeper localhost:2181
10、生产者和消费者的命令行是什么
答
生产者在主题上发布消息
bin/kafka-console-producer.sh --broker-list 192.168.43.49:9092 --topic Hello-Kafa注意这里的 IP 是 server.properties 中的 listeners 的配置。接下来每个新行就是输入一条新消息。 消费者接受消息
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic Hello-Kafka --from-beginning11、consumer是推还是拉
答
Kafka最初考虑的问题是customer应该从brokes拉取消息还是brokers将消息推送到consumer也就是pull还push。在这方面Kafka遵循了一种大部分消息系统共同的传统的设计producer将消息推送到brokerconsumer从broker拉取消息。
一些消息系统比如Scribe和Apache Flume采用了push模式将消息推送到下游的consumer。这样做有好处也有坏处由 broker决定消息推送的速率对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息但不幸的是push模式下当 broker推送的速率远大于consumer消费的速率时consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。
Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker 拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率将可能导致一次只推送较少的消息而造成浪费。Pull模式下consumer就可以根据自己的消费能力去决定这些策略。
Pull有个缺点是如果broker没有可供消费的消息将导致consumer不断在循环中轮询直到新消息到t达。为了避免这点Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
12、讲讲kafka维护消费状态跟踪的方法
答
大部分消息系统在broker端的维护消息被消费的记录
一个消息被分发到consumer后broker就马上进行标记或者等待customer的通知后进行标记。这样也可以在消息在消费后立马就删除以减少空间占用。
但是这样会不会有什么问题呢如果一条消息发送出去之后就立即被标记为消费过的一旦consumer处理消息时失败了比如程序崩溃消息就丢失了。
为了解决这个问题很多消息系统提供了另外一个个功能当消息被发送出去之后仅仅被标记为已发送状态当接到consumer已经消费成功的通知后才标记为已被消费的状态。
这虽然解决了消息丢失的问题但产生了新问题首先如果consumer处理消息成功了但是向broker发送响应时失败了这条消息将被消费两次。第二个问题时broker必须维护每条消息的状态并且每次都要先锁住消息然后更改状态然后释放锁。这样麻烦又来了且不说要维护大量的状态数据比如如果消息发送出去但没有收到消费成功的通知这条消息将一直处于被锁定的状态Kafka采用了不同的策略。Topic被分成了若干分区每个分区在同一时间只被一个consumer消费。
这意味着每个分区被消费的消息在日志中的位置仅仅是一个简单的整数offset。
这样就很容易标记每个分区消费状态就很容易了仅仅需要一个整数而已。这样消费状态的跟踪就很简单了。这带来了另外一个好处consumer可以把offset调成一个较老的值去重新消费老的消息。这对传统的消息系统来说看起来有些不可思议但确实是非常有用的谁规定了一条消息只能被消费一次呢
13、讲一下主从同步。
答 Kafka允许topic的分区拥有若干副本这个数量是可以配置的你可以为每个topci配置副本的数量。Kafka会自动在每个个副本上备份数据,所以当一个节点down掉时数据依然是可用的. Kafka的副本功能不是必须的你可以配置只有一个副本这样其实就相当于只有一份数据。 创建副本的单位是topic的分区,每个分区都有一个leader和零或多个followers。所有的读写操作都由leader处理一般分区的数量都比broker的数量多的多各分区的leader均匀的分布在brokers中。
14、为什么需要消息系统mysql 不能满足需求吗
答
1.解耦
允许你独立的扩展或修改两边的处理过程只要确保它们遵守同样的接口约束。
2.冗余
消息队列把数据进行持久化直到它们已经被完全处理通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中在把一个消息从队列中删除之前需要你的处理系统明确的指出该消息已经被处理完毕从而确保你的数据被安全的保存直到你使用完毕。
3.扩展性
因为消息队列解耦了你的处理过程所以增大消息入队和处理的频率是很容易的只要另外增加处理过程即可。
4.灵活性 峰值处理能力
在访问量剧增的情况下应用仍然需要继续发挥作用但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力而不会因为突发的超负荷的请求而完全崩溃。
5.可恢复性
系统的一部分组件失效时不会影响到整个系统。消息队列降低了进程间的耦合度所以即使一个处理消息的进程挂掉加入队列中的消息仍然可以在系统恢复后被处理。
6.顺序保证
在大多使用场景下数据处理的顺序都很重要。大部分消息队列本来就是排序的并且能保证数据会按照特定的顺序来处理。Kafka 保证一个 Partition 内的消息的有序性
7.缓冲
有助于控制和优化数据流经过系统的速度解决生产消息和消费消息的处理速度不一致的情况。
8.异步通信
很多时候用户不想也不需要立即处理消息。消息队列提供了异步处理机制允许用户把一个消息放入队列但并不立即处理它。想向队列中放入多少消息就放多少然后在需要的时候再去处理它们。
15、Zookeeper对于Kafka的作用是什么
答
Zookeeper是一个开放源码的、高性能的协调服务它用于Kafka的分布式应用。Zookeeper主要用于在集群中不同节点之间进行通信在Kafka中它被用于提交偏移量因此如果节点在任何情况下都失败了它都可以从之前提交的偏移量中获取除此之外它还执行其他活动如leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
16、Kafka判断一个节点是否还活着有那两个条件
答
1节点必须可以维护和ZooKeeper 的连接Zookeeper通过心跳机制检查每个节点的连接
2如果节点是个follower,他必须能及时的同步leader的写操作延时不能太久
17、Kafka与传统MQ消息系统之间有三个关键区别
答
(1).Kafka持久化日志这些日志可以被重复读取和无限期保留
(2).Kafka是一个分布式系统它以集群的方式运行可以灵活伸缩在内部通过复制数据提升容错能力和高可用性
(3).Kafka支持实时的流式处理
18、讲一讲kafka的ack的三种机制
答
request.required.acks有三个值0 1 -1(all)
0:生产者不会等待broker的ack这个延迟最低但是存储的保证最弱当server挂掉的时候就会丢数据。
1服务端会等待ack值leader副本确认接收到消息后发送ack但是如果leader挂掉后他不确保是否复制完成新leader也会导致数据丢失。
-1(all)服务端会等所有的follower的副本受到数据后才会受到leader发出的ack这样数据不会丢失。
19、消费者如何不自动提交偏移量由应用提交
答
将auto.commit.offset设为false然后在处理一批消息后commitSync() 或者异步提交commitAsync() 即 20、消费者故障出现活锁问题如何解决
答
出现 “活锁 ” 的情况 是它持续的发送心跳 但是没有处理 。为了预防消费者在这种情况 下一 直持有分区我们使用max.poll.interval.ms活跃检测 机制 。 在此基础上如果你调用的poll的频率大于最大间隔则客户端将主动地离开组以便其 他消费者接管该分区。发生这种情况时你会看到offset提交失败调用commitSync引发的CommitFailedException。 这是一种安全机制保障只有活动成员能够提交offset。所以要留在组中你必须持续调用poll。
消费者提供两个配置设置来控制poll循环
max.poll.interval.ms增大poll的间隔可以为消费者提供更多的时间去处理返回的消息调用poll(long)返回的消 息通常返回的消息都是一 批。缺点是此值越大将会延迟组重新平衡。
max.poll.records此设置限制每次调用poll返回的消息数这样可以更容易的预测每次poll间隔要处理的最大值。通过调整此值可以减少poll间隔减少重新平衡分组的对于消息处理时间不可预测地的情况这些选项是不够的。
处理这种情况的推荐方法是将消息处理移到另一个线程中让消费者继续调用poll。 但是必须注意确保已提交的offset不超过实际位置。另外你必须禁用自动提交并只有在线程完成处理后才为记录手动提交偏移量取决于你 。还要注意 你需要pause暂停分区不会从poll接收到新消息让线程处理完之前返回的消息如果你的处理能力比拉取消息的慢那创建新线 程将导致你机器内存溢出 。
21、如何控制消费的位置
答
kafka 使用 seek(TopicPartition, long)指定新的消费位置。用于查找服务器保留的最早和最新的offset的特殊的方法也可用seekToBeginning(Collection) 和seekToEnd(Collection)
22、kafka分布式不是单机的情况下如何保证消息的顺序消费
答
Kafka分布式的单位是partition同一个partition用一个write ahead log组织所以可以保证FIFO的顺序。不同partition之间不能保证顺序。但是绝大多数用户都可以通过message key来定义因为同一个key的Message可以保证只发送到同一个partition。
Kafka中发送1条消息的时候可以指定(topic, partition, key) 3个参数。partiton和key是可选的。如果你指定了partition那就是所有消息发往同1个partition就是有序的。
并且在消费端Kafka保证1个partition只能被1个consumer消费。或者你指定key比如order id具有同1个key的所有消息会发往同1个partition。
23、kafka的高可用机制是什么
答
这个问题比较系统回答出kafka的系统特点leader和follower的关系消息读写的顺序即可。
24、kafka如何减少数据丢失
25、kafka如何不消费重复数据比如扣款我们不能重复的扣
答
其实还是得结合业务来思考我这里给几个思路
比如你拿个数据要写库你先根据主键查一下如果这数据都有了你就别插入了update一下好吧。
比如你是写Redis那没问题了反正每次都是set天然幂等性。
比如你不是上面两个场景那做的稍微复杂一点你需要让生产者发送每条数据的时候里面加一个全局唯一的id类似订单 id之类的东西然后你这里消费到了之后先根据这个id去比如Redis里查一下之前消费过吗如果没有消费过你就处理然后这个id写Redis。如果消费过了那你就别处理了保证别重复处理相同的消息即可。
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了重复数据插入只会报错不会导致数据库中出现脏数据。
总结 篇幅有限其他内容就不在这里一 一展示了整理不易欢迎大家一起交流喜欢小编分享的文章记得关注我点赞哟感谢支持重要的事情说三遍转发转发转发一定要记得转发哦
