有名的网站制作公司,如何给一个网站做压测,建设网站公司电话号码,百度有哪些产品一、Kafka简介
Kafka是什么
Kafka是一种高吞吐量的分布式发布订阅消息系统#xff08;消息引擎系统#xff09;#xff0c;它可以处理消费者在网站中的所有动作流数据。 这种动作#xff08;网页浏览#xff0c; 搜索和其他用户的行动#xff09;是在现代网络上的许多社…一、Kafka简介
Kafka是什么
Kafka是一种高吞吐量的分布式发布订阅消息系统消息引擎系统它可以处理消费者在网站中的所有动作流数据。 这种动作网页浏览 搜索和其他用户的行动是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来 解决。 对于像Hadoop一样的日志数据和离线分析系统但又要求实时处理的限制这是一个可行的解决方案。Kafka的目的是通过Hadoop 的并行加载机制来统一线上和离线的消息处理也是为了通过集群来提供实时的消息。
其实我们简单点理解就是系统A发送消息给kafka消息引擎系统系统B从kafka中读取A发送的消息。而kafka就是个中间商。
1.1 Kafka的特性: 高吞吐量、低延迟kafka每秒可以处理几十万条消息它的延迟最低只有几毫秒每个topic可以分多个partition, consumer group 对partition进行consume操作。 可扩展性kafka集群支持热扩展 持久性、可靠性消息被持久化到本地磁盘并且支持数据备份防止数据丢失 容错性允许集群中节点失败若副本数量为n,则允许n-1个节点失败 高并发支持数千个客户端同时读写
1.2 Kafka的使用场景
Kafaka经常用于削峰、解耦、异步。 日志收集一个公司可以用Kafka可以收集各种服务的log通过kafka以统一接口服务的方式开放给各种consumer例如hadoop、Hbase、Solr等。 消息系统解耦生产者和消费者、缓存消息等。 用户活动跟踪Kafka经常被用来记录web用户或者app用户的各种活动如浏览网页、搜索、点击等活动这些活动信息被各个服务器发布到kafka的topic中然后订阅者通过订阅这些topic来做实时的监控分析或者装载到hadoop、数据仓库中做离线分析和挖掘。 运营指标Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据生产各种操作的集中反馈比如报警和报告。 流式处理比如spark streaming和storm 事件源
1.3 Kakfa的设计思想
Kakfa Broker Leader的选举Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点因为只有一个Kafka Broker会注册成功其他的都会失败所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller其他的Kafka broker叫Kafka Broker follower。这个过程叫Controller在ZooKeeper注册Watch。这个Controller会监听其他的Kafka Broker的所有信息如果这个kafka broker controller宕机了在zookeeper上面的那个临时节点就会消失此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点因为只有一个Kafka Broker会注册成功其他的都会失败所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller其他的Kafka broker叫Kafka Broker follower。例如一旦有一个broker宕机了这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态并选取ISR列表中的一个replica作为partition leader如果ISR列表中的replica全挂选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了则将新的leader设置为-1等待恢复等待ISR中的任一个Replica“活”过来并且选它作为Leader或选择第一个“活”过来的Replica不一定是ISR中的作为Leader这个broker宕机的事情kafka controller也会通知zookeeperzookeeper就会通知其他的kafka broker。
二、Kafka架构 三、Kafka中的术语解释概述
Broker【服务器节点】
Kafka 集群包含一个或多个服务器服务器节点称为broker。broker存储topic的数据。 如果某topic有N个partition集群有N个broker那么每个broker存储该topic的一个partition。 如果某topic有N个partition集群有(NM)个broker那么其中有N个broker存储该topic的一个partition剩下的M个broker不存储该topic的partition数据。 如果某topic有N个partition集群中broker数目少于N个那么一个broker存储该topic的一个或多个partition。在实际生产环境中尽量避免这种情况的发生这种情况容易导致Kafka集群数据不均衡。
Topic【主题】
每条发布到Kafka集群的消息都有一个类别这个类别被称为Topic。物理上不同Topic的消息分开存储逻辑上一个Topic的消息虽然保存于 一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处。类似于数据库的表名。在每个broker上都 可以创建多个topic。
Partition【分区】 topic中的数据分割为一个或多个partition。每个topic至少有一个partition。topic的数据数据会写入到不同的partition。 每个Partition在物理上对应一个文件夹该文件夹下存储这个Partition的所有消息和索引文件。 partition中的数据是有序的不同partition间的数据丢失了数据的顺序。 如果topic有多个partition消费数据时就不能保证数据的顺序。 在需要严格保证消息的消费顺序的场景下需要将partition数目设为1。
上面说到数据会写入到不同的分区那kafka为什么要做分区呢相信大家应该也能猜到分区的主要目的是 方便扩展。因为一个topic可以有多个partition所以我们可以通过扩展机器去轻松的应对日益增长的数据量。 提高并发。以partition为读写单位可以多个消费者同时消费数据提高了消息的处理效率。
熟悉负载均衡的朋友应该知道当我们向某个服务器发送请求的时候服务端可能会对请求做一个负载将流量分发到不同的服务器那在kafka中如果某个topic有多个partitionproducer又怎么知道该将数据发往哪个partition呢
kafka中有几个原则 partition在写入的时候可以指定需要写入的partition如果有指定则写入对应的partition。 如果没有指定partition但是设置了数据的key则会根据key的值hash出一个partition。 如果既没指定partition又没有设置key则会轮询选出一个partition。
保证消息不丢失是一个消息队列中间件的基本保证那producer在向kafka写入消息的时候怎么保证消息不丢失呢
那就是通过ACK应答机制在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据这个参数可设置的值为0、1、all。 0代表producer往集群发送数据不需要等到集群的返回不确保消息发送成功。安全性最低但是效率最高。 1代表producer往集群发送数据只要leader应答就可以发送下一条只确保leader发送成功。 all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条确保leader发送成功和所有的副本都完成备份。安全性最高但是效率最低。
最后要注意的是如果往不存在的topic写数据能不能写入成功呢kafka会自动创建topic分区和副本的数量根据默认配置都是1。
Producer【生产者】
生产者即数据的发布者该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息存储到一个partition中生产者也可以指定数据存储的partition。
Consumer【消费者】
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
Consumer Group【消费者组】
每个Consumer属于一个特定的Consumer Group可为每个Consumer指定group name若不指定group name则属于默认的group。
同一个topic下的每个partition中message只能被组Consumer group 中的一个consumer消费如果想让一个message可以被多个consumer消费的话那么这些consumer必须在不同的Consumer group。所以如果想同时对一个topic做消费的话启动多个consumer group就可以了但是要注意的是这里的多个consumer的消费都必须是顺序读取partition里面的message新启动的consumer默认从partition队列最头端最新的地方开始阻塞的读message。它不能像AMQ那样可以多个BET作为consumer去互斥的for update悲观锁并发处理message这是因为多个BET去消费一个Queue中的数据的时候由于要保证不能多个线程拿同一条message所以就需要行级别悲观所for update,这就导致了consume的性能下降吞吐量不够。而kafka为了保证吞吐量只允许同一个consumer group下的一个consumer线程去访问一个partition。如果觉得效率不高的时候可以加partition的数量来横向扩展那么再加新的consumer thread去消费。如果想多个不同的业务都需要这个topic的数据起多个consumer group就好了大家都是顺序的读取messageoffsite的值互不影响。这样没有锁竞争充分发挥了横向的扩展性吞吐量极高。这也就形成了分布式消费的概念。
当启动一个consumer group去消费一个topic的时候无论topic里面有多少个partition无论我们consumer group里面配置了多少个consumer thread这个consumer group下面的所有consumer thread一定会消费全部的partition即便这个consumer group下只有一个consumer thread那么这个consumer thread也会去消费所有的partition。因此最优的设计就是consumer group下的consumer thread的数量等于partition数量这样效率是最高的。
当consumer group里面的consumer数量小于这个topic下的partition数量的时候就会出现一个conusmer thread消费多个partition的情况总之是这个topic下的partition都会被消费。如果consumer group里面的consumer数量等于这个topic下的partition数量的时候此时效率是最高的每个partition都有一个consumer thread去消费。当consumer group里面的consumer数量大于这个topic下的partition数量的时候就会有consumer thread空闲。
多个Consumer Group下的consumer可以消费同一条message但是这种消费也是以o1的方式顺序的读取message去消费,所以一定会重复消费这批message的不能向AMQ那样多个BET作为consumer消费对message加锁消费的时候不能重复消费message
Leader【领导者】
每个partition有多个副本其中有且仅有一个作为LeaderLeader是当前负责数据的读写的partition。
Follower【跟随者】
Follower跟随Leader所有写请求都通过Leader路由数据变更会广播给所有FollowerFollower与Leader保持数据同步。如果Leader失效则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢leader会把这个follower从“in sync replicas”ISR列表中删除重新创建一个Follower。
Replica【副本】
每个partition可以在其他的kafka broker节点上存副本以便某个kafka broker节点宕机不会影响这个kafka集群。 存replica副本的方式是按照kafka broker的顺序存。 例如有5个kafka broker节点某个topic有3个partition每个partition存2个副本那么partition1存broker1,broker2partition2存broker2,broker3。。。以此类推replica副本数目不能大于kafka broker节点的数目否则报错。这里的replica数其实就是partition的副本总数其中包括一个leader其他的就是copy副本。这样如果某个broker宕机其实整个kafka内数据依然是完整的。但是replica副本数越高系统虽然越稳定但是会带来资源和性能上的下降replica副本少的话也会造成系统丢数据的风险。 传送消息producer先把message发送到partition leader再由leader发送给其他partition follower如果让producer发送给每个replica那就太慢了。 再向Producer发送ACK前需要保证有多少个Replica已经收到该消息根据ack配的个数而定。 处理某个Replica不工作的情况如果这个部工作的partition replica不在ack列表中就是producer在发送消息到partition leader上partition leader向partition follower发送message没有响应而已这个不会影响整个系统也不会有什么问题。如果这个不工作的partition replica在ack列表中的话producer发送的message的时候会等待这个不工作的partition replca写message成功但是会等到time out然后返回失败因为某个ack列表中的partition replica没有响应此时kafka会自动的把这个部工作的partition replica从ack列表中移除以后的producer发送message的时候就不会有这个ack列表下的这个部工作的partition replica了。 处理Failed Replica恢复回来的情况如果这个partition replica之前不在ack列表中那么启动后重新受Zookeeper管理即可之后producer发送message的时候partition leader会继续发送message到这个partition follower上。如果这个partition replica之前在ack列表中此时重启后需要把这个partition replica再手动加到ack列表中。ack列表是手动添加的出现某个部工作的partition replica的时候自动从ack列表中移除的。
四、Kafka可视化管理工具
【Kafka可视化工具】kafka-manager kafka-manager安装及基本使用
【Kafka可视化工具】Offset Explorer Kafka-Offset Explorer安装及基本使用
