如何做网站首页图,电商发展趋势和未来,专门做各种产品测评的网站,django做视频网站文章目录 Apache Kafka综述什么是消息系统#xff1f;点对点消息类型发布-订阅消息类型 什么是Kafka?优点关键术语Kafka基本原理用例 Apache Kafka综述
在大数据中#xff0c;会使用到大量的数据。面对这些海量的数据#xff0c;我们一是需要做到能够收集这些数据#xf… 文章目录 Apache Kafka综述什么是消息系统点对点消息类型发布-订阅消息类型 什么是Kafka?优点关键术语Kafka基本原理用例 Apache Kafka综述
在大数据中会使用到大量的数据。面对这些海量的数据我们一是需要做到能够收集这些数据其次是要能够分析和处理这些海量数据。在此过程中需要一套消息系统。 Kafka专门为分布式高吞吐量系统设计。作为一个消息代理的替代品Kafka往往做的比其他消息中间件做的更好。 与其他消息队列产品相比它主要有以下优点
吞吐量高内置分区复制能力固有的容错能力
因此Kafka非常适合大规模的消息处理应用。
什么是消息系统
消息系统负责将数据从一个应用传递到另一个应用应用就可以专注于数据而不用担心数据如何共享。分布式消息传递基于可靠消息队列的概念。消息在客户端应用程序和消息传递系统之间异步排队。 有两种类型的消息模式可用
点对点模式订阅-发布模式pub-sub也是最常用的一种消息模式
点对点消息类型
在点对点的消息传递类型中所有的消息都保留在消息队列中。一个或多个消费者可以消耗队列中的消息但特定的消息只能有最多一个消费者消费。一旦消费者消费了队列中的消息该消息将会在消息队列中消失。 点对点消息系统最典型的例子是订单处理系统其中每个订单将有由订单处理器处理但多个订单处理器也可以同时工作。
发布-订阅消息类型
在发布-订阅系统中消息被保留在各个主题中。 与点对点系统不同的是一个订阅者可以订阅一个或多个不同主题中的消息并使用这些主题中的所有消息。 在发布-订阅系统中消息的生产者称为发布者消息的使用者称为订阅者。 一个现实的例子是dish天线电视它发布不同的渠道和主题如运动、音乐、电影等任何人都可以订阅自己需要的主题集并接收到订阅主题的消息。
什么是Kafka? Kafka is a distributed,partitioned,replicated commit logservice. Apache Kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列可以处理大量的数据并使你能够将消息从一个端点传递到另一个端点。Kafka 适合离线和在线消息消费。Kafka 消息保留在磁盘上并在群集内复制以防止数据丢失。Kafka 构建在 ZooKeeper 同步服务之上。 它与 Apache Storm 和 Spark 非常好地集成用于实时流式数据分析。
优点
可靠性 Kafka是分布式、分区复制、可容错的可扩展性 消息传递系统可以轻松扩缩容不用关机耐用性 Kafka使用“分布式提交日志”这意味着消息会尽可能快地保留在磁盘上因此它是持久的。高性能 Kafka无论是发布还是订阅消息的吞吐量都是很高的。即使存储了很多TB的消息还是能够保证高性能。
Kafka非常快并且能保证零停机和零数据丢失
关键术语
生产者和消费者Productor Customer 在Kafka中消息的发布者称为生产者Productor消息的接受和使用者称为消费者Customerbroker Kafka消息队列集群中有很多台server每一台server都可以存储消息这每一台server都可以称做是Kafka的一个实例也称为broker主题topic 一个topic中会保存同一类的消息相当于对消息进行分类。productor在向Custom发送消息的时候需要指定topic也就是制定了该消息属于哪一分类。分区partition 每个topic都划分为多个partition每个partition在存储层面都是一个append log文件。任何写进某partition的消息都会被追加在一个log文件的尾部。 分区的意义Kafka基于文件进行存储当文件内容过大的时候很容易达到单个磁盘的上限。使用分区进行存储一个分区存储一个文件保证单个文件不会过大的情况下还能将数据存在不同的broker Kafka server上从而实现了负载均衡能够承载更多的消费者偏移量offset 一个分区存储一个文件而消息在文件中的位置就称为是偏移量offsetoffset的字符类型为long长字符类型它可以唯一标记一条消息。由于Kafka并没有提供额外的消息索引机制因此文件只能顺序读写所以Kafka基本不允许对消息进行“随机读写”。
小结Kafka
是基于发布-订阅的分布式消息队列面向大数据消息存储在topic中而每个topic会分为多个patition分区消息存储在磁盘中每个partition分区对应一个磁盘上的一个文件来存储消息消息的写入就是在log文件后追加内容文件可以在集群内复制防止丢失即使消息被消费消息也不会立刻消失可以通过配置以实现自动删除来释放空间Kafka依赖分布式协调服务zookeeper适合离线/在线消息的消费与storm/spark等实时流式数据处理工具常常结合使用。
Kafka基本原理 分布式和分区distributed、partitioned Kafka是一个分布式的发布-订阅消息队列主要体现在哪些方面 体现在大量的数据被保存在磁盘上但单个磁盘的容量是有限的于是消息被生产者生产的时候分为不同的topic主题来保存每个topic又被分为多个partition分区而每个partition分区对应一个文件以文件的方式来保存消息数据每个文件又可以被保存在不同的broker上这样就实现了Kafka集群来分布式存储消息队列。 另外每个partition都有一定的副本可以备份到不同的borker上从而提高可用性。 总的来说就是一个topic对应的多个partition上的文件分散保存在集群的多个不同broker上存储的方式是一个partition对应一个文件每个broker负责存储在自己机器上的每个文件的读写。 副本replicated Kafka可以通过配置指定partition的备份个数replicas每个partition将会被备份到多台机器上提高了可用性备份数量通过配置文件可以指定。 实质上冗余备份在分布式系统中很常见。 有副本的存在就会涉及到同一个文件的多个副本如何管理和调度。 Kafka设置了“leader机制”每个partition选举一个broker作为leader用来负责对该分区的读写其余broker则作为follower只需简单地和leader同步即可。如果原来的leader失效partition则会选举新的broker成为leader。 至于如何选取 leader实际上如果我们了解 ZooKeeper就会发现其实这正是 Zookeeper 所擅长的Kafka 使用 ZK 在 Broker 中选出一个 Controller用于 Partition 分配和 Leader 选举。 实际上作为leader的server承担了整个分区的所有读写请求负担是比较大的。从整体考虑有多少个partition就有多少个leaderKafka将leader分摊到不同的broker上也算是整体上的一种负载均衡。 Kafka数据流处理 1数据产生方式produce
生产者写入消息数据可以指定4个参数分别为topic,partition,key,value。其中topic和value要写入的数据必须指定而key和partition是可选的。 对于一条记录要先对其进行序列化再按照topic和partition发送到对应的队列中去。如果没有指定partition有两种情况 指定key按照key进行哈希同一个key的消息进一个partition 未指定key round-robin进行partition的选择 producer将会和topic下的每个partiton leader保持socket连接消息由producer直接发送给broker。 其中partition leader的身份在zookeeper中已经注册producer作为zookeeper client已经注册了watch用来监听partition leader的变更事件因此可以准确知道leader是谁。 producer端采用异步发送先将一部分的消息存在客户端的buffer里并将其分批发送给broker小数据io很多会增加整体网络的延迟批量延迟发送实际上是提供了网络效率。 2数据消费过程custome 对于消费者不是以单独形式存在的每个消费者都属于一个消费群租customer group,一个group包含多个consumer。需要注意的是消费者的订阅topic行为都是以customer group的形式来订阅的发送到topic的消息只会被订阅该topic的每个group中的每个customer消费。 如果说所有的customer都有共同的group那么就像是一个点对点的消息系统如果每个消费者都属于不同的group那么消息会广播给所有的消费者。 实际上消息是根据partition来分的一个partition只能被消费组里的一个消费者消费但是可以多个不同的消费组消费消费组里的每个消费者是关联到一个partition的因此有一个说法对同一个topic同一个group中不能有多于partitions个数的customer同时消费否则某些customer将无法得到消息。 同一个消费组的两个customer不能同时消费一个partition partition 中的消息只有一个 consumer 在消费且不存在消息状态的控制也没有复杂的消息确认机制可见katka broker 端是相当轻量级的。当消息被 consumer 接收之后需要保存 Offset 记录消费到哪以前保存在ZK中由于 ZK 的写性能不好以前的解决方法都是Consumer 每隔一分钟上报一次在0.10 版本后Kafka 把这个Offset 的保存从ZK 中剥离保存在一个名叫 consumeroffsets topic 的Topic 中由此可见consumer 客户端也很轻量级
用例
Kafka可以在很多场景中使用以下列出一些用例
指标 Kafka通常用于操作监控数据。这涉及到聚合来自分布式应用程序的统计信息以产生操作数据的集中馈送。日志聚合解决方案 可用于跨组织收集多个服务的日志且以标准格式提供给多个服务器。流处理 流行的框架(如Storm和Spark Streaming)从主题中读取数据对其进行处理并将处理后的数据写入新主题供用户和应用程序使用。 Kafka的强耐久性在流处理的上下文中也非常有用。
