当前位置:首页 > 服务端 > kafka理论详解(超详细)

kafka理论详解(超详细)

2022年11月09日 15:56:32服务端6

一、介绍

        kafka,A distributed publish-subscribe messaging system,消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程间的通信。

       它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类,发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

二、特点

        MQ生来就是解决生产者和消费者速度不匹配的问题而诞生的,那么MQ系统一个最最基本的要求就是写入速度必须要快,哪怕出队速度慢点也无所谓,因为业务高峰期持续时间是有限的,高峰结束之后有的是时间让消费者慢慢消化,更别说简单粗暴多加几台消费者就好了。

  • 1.同时为发布和订阅提供高吞吐量。据了解,Kafka每秒可以生产约25万消息(50 MB),每秒处理55万消息(110 MB)。
  • 2.可进行持久化操作。将消息持久化到磁盘,因此可用于批量消费,例如ETL,以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。
  • 3.分布式系统,易于向外扩展。所有的producer、broker和consumer都会有多个,均为分布式的。无需停机即可扩展机器。
  • 4.消息被处理的状态是在consumer端维护,而不是由server端维护。当失败时能自动平衡。
  • 5.支持online和offline的场景。

三、何时需要消息队列

        MQ消息队列是应运松偶合的概念而产生的,主要以队列和发布订阅为消息传输机制,以异步的方式将消息可靠的传输到消费端的一种基础产品。它被广泛的应用与跨平台、跨系统的分布式系统之间,为它们提供高效可靠的异步传输机制。可以使用mq的场景有很多,最常用的几种,是做业务解耦/最终一致性/广播/错峰流控等。反之,如果需要强一致性,关注业务逻辑的处理结果,则RPC显得更为合适。

Kafka 中的术语设计:

1、Broker

      中间的kafka cluster,存储消息,是由多个server组成的集群。一个Topic,有三个partition。

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

2、topic与消息

       kafka将所有消息组织成多个topic的形式存储,而每个topic又可以拆分成多个partition,每个partition又由一个一个消息组成。每个消息都被标识了一个递增序列号代表其进来的先后顺序,并按顺序存储在partition中。

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

这样,消息就以一个个id的方式,组织起来。

  • producer选择一个topic,生产消息,消息会通过分配策略append到某个partition末尾。
  • consumer选择一个topic,通过id指定从哪个位置开始消费消息。消费完成之后保留id,下次可以从这个位置开始继续消费,也可以从其他任意位置开始消费。

上面的id在kafka中称为offset,这种组织和处理策略提供了如下好处:

  • 消费者可以根据需求,灵活指定offset消费。
  •  保证了消息不变性,为并发消费提供了线程安全的保证。每个consumer都保留自己的offset,互相之间不干扰,不存在线程安全问题。
  •  消息访问的并行高效性。每个topic中的消息被组织成多个partition,partition均匀分配到集群server中。生产、消费消息的时候,会被路由到指定partition,减少竞争,增加了程序的并行能力。
  •  增加消息系统的可伸缩性。每个topic中保留的消息可能非常庞大,通过partition将消息切分成多个子消息,并通过负责均衡策略将partition分配到不同server。这样当机器负载满的时候,通过扩容可以将消息重新均匀分配。
  •  保证消息可靠性。消息消费完成之后不会删除,可以通过重置offset重新消费,保证了消息不会丢失。
  •  灵活的持久化策略。可以通过指定时间段(如最近一天)来保存消息,节省broker存储空间。
  •  备份高可用性。消息以partition为单位分配到多个server,并以partition为单位进行备份。备份策略为:1个leader和N个followers,leader接受读写请求,followers被动复制leader。leader和followers会在集群中打散,保证partition高可用。

3、Partitions

       每个Topics划分为一个或者多个Partition,并且Partition中的每条消息都被标记了一个sequential id ,也就是offset,并且存储的数据是可配置存储时间的 

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

4、producer

producer生产消息需要如下参数:

  •  topic:往哪个topic生产消息。
  •  partition:往哪个partition生产消息。
  •  key:根据该key将消息分区到不同partition。
  •  message:消息。

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

5、consumer

       每个consumer将自己标记consumer group名称,之后系统会将consumer group按名称分组,将消息复制并分发给所有分组,每个分组只有一个consumer能消费这条消息。

传统消息系统有两种模式:

  • 队列
  • 发布订阅

       kafka通过consumer group将两种模式统一处理:每个consumer将自己标记consumer group名称,之后系统会将consumer group按名称分组,将消息复制并分发给所有分组,每个分组只有一个consumer能消费这条消息。如下图:

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

于是推理出两个极端情况:

  •  当所有consumer的consumer group相同时,系统变成队列模式
  •  当每个consumer的consumer group都不相同时,系统变成发布订阅

注意:

        1、Consumer Groups 提供了topics和partitions的隔离, 如上图Consumer Group A中的consumer-C2挂掉,consumer-C1会接收P1,P2,即一个consumer Group中有其他consumer挂掉后能够重新平衡。如下图:

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

        2、多consumer并发消费消息时,容易导致消息乱序,通过限制消费者为同步,可以保证消息有序,但是这大大降低了程序的并发性。

        kafka通过partition的概念,保证了partition内消息有序性,缓解了上面的问题。partition内消息会复制分发给所有分组,每个分组只有一个consumer能消费这条消息。这个语义保证了某个分组消费某个分区的消息,是同步而非并发的。如果一个topic只有一个partition,那么这个topic并发消费有序,否则只是单个partition有序。

一般消息系统,consumer存在两种消费模型:

  • push(推送):优势在于消息实时性高。劣势在于没有考虑consumer消费能力和饱和情况,容易导致producer压垮consumer。
  • pull(拉取):优势在可以控制消费速度和消费数量,保证consumer不会出现饱和。劣势在于当没有数据,会出现空轮询,消耗cpu。

        kafka采用pull,并采用可配置化参数保证当存在数据并且数据量达到一定量的时候,consumer端才进行pull操作,否则一直处于block状态。kakfa采用整数值consumer position来记录单个分区的消费状态,并且单个分区单个消息只能被consumer group内的一个consumer消费,维护简单开销小。消费完成,broker收到确认,position指向下次消费的offset。由于消息不会删除,在完成消费,position更新之后,consumer依然可以重置offset重新消费历史消息。

        Kafka中有一个叫做_consumer_offset的特殊主题用来保存在每个分区的偏移量,消费者每次消费时都会往这个主题中发送消息,消息包含每个分区的偏移量。用来进行rebalance。

6、消息发送语义

producer视角

  • 消息最多发送一次:producer异步发送消息,或者同步发消息但重试次数为0。
  • 消息至少发送一次:producer同步发送消息,失败、超时都会重试。
  • 消息发且仅发一次:后续版本支持。

consumer视角

  • 消息最多消费一次:consumer先读取消息,再确认position,最后处理消息。
  • 消息至少消费一次:consumer先读取消息,再处理消息,最后确认position。
  • 消息消费且仅消费一次。

注意:

  • 如果消息处理后的输出端(如db)能保证消息更新幂等性,则多次消费也能保证exactly once语义。
  • 如果输出端能支持两阶段提交协议,则能保证确认position和处理输出消息同时成功或者同时失败。
  • 在消息处理的输出端存储更新后的position,保证了确认position和处理输出消息的原子性(简单、通用)。

7、可用性

    在kafka中,正常情况下所有node处于同步中状态,当某个node处于非同步中状态,也就意味着整个系统出问题,需要做容错处理。

同步中代表了:

  • 该node与zookeeper能连通。
  • 该node如果是follower,那么consumer position与leader不能差距太大(差额可配置)。

某个分区内同步中的node组成一个集合,即该分区的ISR。

kafka通过两个手段容错:

  • 数据备份:以partition为单位备份,副本数可设置。当副本数为N时,代表1个leader,N-1个followers,followers可以视为leader的consumer,拉取leader的消息,append到自己的系统中
  • failover:

    1. 当leader处于非同步中时,系统从followers中选举新leader

    2. 当某个follower状态变为非同步中时,leader会将此follower剔除ISR,当此follower恢复并完成数据同步之后再次进入 ISR。

另外,kafka有个保障:当producer生产消息时,只有当消息被所有ISR确认时,才表示该消息提交成功。只有提交成功的消息,才能被consumer消费。

因此,当有N个副本时,N个副本都在ISR中,N-1个副本都出现异常时,系统依然能提供服务。

        假设N副本全挂了,node恢复后会面临同步数据的过程,这期间ISR中没有node,会导致该分区服务不可用。kafka采用一种降级措施来处理:选举第一个恢复的node作为leader提供服务,以它的数据为基准,这个措施被称为脏leader选举。由于leader是主要提供服务的,kafka broker将多个partition的leader均分在不同的server上以均摊风险。每个parition都有leader,如果在每个partition内运行选主进程,那么会导致产生非常多选主进程。kakfa采用一种轻量级的方式:从broker集群中选出一个作为controller,这个controller监控挂掉的broker,为上面的分区批量选主。

8、一致性

上面的方案保证了数据高可用,有时高可用是体现在对一致性的牺牲上。如果希望达到强一致性,可以采取如下措施:

  • 禁用脏leader选举,ISR没有node时,宁可不提供服务也不要未完全同步的node。
  • 设置最小ISR数量min_isr,保证消息至少要被min_isr个node确认才能提交。

9、持久化

基于以下几点事实,kafka重度依赖磁盘而非内存来存储消息

  • 硬盘便宜,内存贵
  • 顺序读+预读取操作,能提高缓存命中率
  • 操作系统利用富余的内存作为pagecache,配合预读取(read-ahead)+写回(write-back)技术,从cache读数据,写到cache就返回(操作系统后台flush),提高用户进程响应速度
  • java对象实际大小比理想大小要大,使得将消息存到内存成本很高
  • 当堆内存占用不断增加时,gc抖动较大
  • 基于文件顺序读写的设计思路,代码编写简单
  • 在持久化数据结构的选择上,kafka采用了queue而不是Btree
  • kafka只有简单的根据offset读和append操作,所以基于queue操作的时间复杂度为O(1),而基于Btree操作的时间复杂度为O(logN)
  • 在大量文件读写的时候,基于queue的read和append只需要一次磁盘寻址,而Btree则会涉及多次。磁盘寻址过程极大降低了读写性能

10、消息投递可靠性

一个消息如何算投递成功,Kafka提供了三种模式:

  • - 第一种是啥都不管,发送出去就当作成功,这种情况当然不能保证消息成功投递到broker;
  • - 第二种是Master-Slave模型,只有当Master和所有Slave都接收到消息时,才算投递成功,这种模型提供了最高的投递可靠性,但是损伤了性能;
  • - 第三种模型,即只要Master确认收到消息就算投递成功;实际使用时,根据应用特性选择,绝大多数情况下都会中和可靠性和性能选择第三种模型

11、负载均衡

        producer将会和Topic下所有partition leader保持socket连接;消息由producer直接通过socket发送到broker,中间不会经过任何"路由层".事实上,消息被路由到哪个partition上,有producer客户端决定.比如可以采用"random""key-hash""轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的.

       其中partition leader的位置(host:port)注册在zookeeper中,producer作为zookeeper client,已经注册了watch用来监听partition leader的变更事件.

       异步发送:将多条消息暂且在客户端buffer起来,并将他们批量的发送到broker,小数据IO太多,会拖慢整体的网络延迟,批量延迟发送事实上提升了网络效率。不过这也有一定的隐患,比如说当producer失效时,那些尚未发送的消息将会丢失。

集群式的结构图:

kafka理论详解(超详细) _ JavaClub全栈架构师技术笔记

kafka通过zookeeper管理集群配置、leader选举,以及当消费者组发生变化时进行Rebalabce(再均衡)。

相关补充

        kafka和JMS(Java Message Service)实现(activeMQ)不同的是:即使消息被消费,消息仍然不会被立即删除.日志文件将会根据broker中的配置要求,保留一定的时间之后删除;比如log文件保留2天,那么两天后,文件会被清除,无论其中的消息是否被消费。kafka通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘IO开支.

        对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,有consumer来控制;当consumer正常消费消息时,offset将会"线性"的向前驱动,即消息将依次顺序被消费.事实上consumer可以使用任意顺序消费消息,它只需要将offset重置为任意值。

        kafka集群几乎不需要维护任何consumer和producer状态信息,这些信息有zookeeper保存;因此producer和consumer的客户端实现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响.

        partitions的设计目的有多个.最根本原因是kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以将一个topic切分多任意多个partitions,来消息保存/消费的效率.此外越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.

Distribution

        一个Topic的多个partitions,被分布在kafka集群中的多个server上;每个server(kafka实例)负责partitions中消息的读写操作;此外kafka还可以配置partitions需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性.

        基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个server为"leader";leader负责所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follower只是单调的和leader跟进,同步消息即可。由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个"leader",kafka会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定.

 Producers

        Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等.

Consumers

        本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.

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也会通知zookeeper,zookeeper就会通知其他的kafka broker。
  • Consumergroup:各个consumer(consumer 线程)可以组成一个组(Consumer group ),partition中的每个message只能被组(Consumer group )中的一个consumer(consumer 线程)消费,如果一个message可以被多个consumer(consumer 线程)消费的话,那么这些consumer必须在不同的组。Kafka不支持一个partition中的message由两个或两个以上的同一个consumer group下的consumer thread来处理,除非再启动一个新的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就好了,大家都是顺序的读取message,offsite的值互不影响。这样没有锁竞争,充分发挥了横向的扩展性,吞吐量极高。这也就形成了分布式消费的概念。

  • 当启动一个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数量,这样效率是最高的。
  • Delivery Mode : Kafka producer 发送message不用维护message的offsite信息,因为这个时候,offsite就相当于一个自增id,producer就尽管发送message就好了。而且Kafka与AMQ不同,AMQ大都用在处理业务逻辑上,而Kafka大都是日志,所以Kafka的producer一般都是大批量的batch发送message,向这个topic一次性发送一大批message,load balance到一个partition上,一起插进去,offsite作为自增id自己增加就好。但是Consumer端是需要维护这个partition当前消费到哪个message的offsite信息的,这个offsite信息,high level api是维护在Zookeeper上,low level api是自己的程序维护。(Kafka管理界面上只能显示high level api的consumer部分,因为low level api的partition offsite信息是程序自己维护,kafka是不知道的,无法在管理界面上展示 )当使用high level api的时候,先拿message处理,再定时自动commit offsite+1(也可以改成手动), 并且kakfa处理message是没有锁操作的。因此如果处理message失败,此时还没有commit offsite+1,当consumer thread重启后会重复消费这个message。但是作为高吞吐量高并发的实时处理系统,at least once的情况下,至少一次会被处理到,是可以容忍的。如果无法容忍,就得使用low level api来自己程序维护这个offsite信息,那么想什么时候commit offsite+1就自己搞定了。
  • Topic & Partition:Topic相当于传统消息系统MQ中的一个队列queue,producer端发送的message必须指定是发送到哪个topic,但是不需要指定topic下的哪个partition,因为kafka会把收到的message进行load balance,均匀的分布在这个topic下的不同的partition上( hash(message) % [broker数量]  )。物理上存储上,这个topic会分成一个或多个partition,每个partiton相当于是一个子queue。在物理结构上,每个partition对应一个物理的目录(文件夹),文件夹命名是[topicname]_[partition]_[序号],一个topic可以有无数多的partition,根据业务需求和数据量来设置。在kafka配置文件中可随时更高num.partitions参数来配置更改topic的partition数量,在创建Topic时通过参数指定parittion数量。Topic创建之后通过Kafka提供的工具也可以修改partiton数量。一般来说,(1)一个Topic的Partition数量大于等于Broker的数量,可以提高吞吐率。(2)同一个Partition的Replica尽量分散到不同的机器,高可用。当add a new partition的时候,partition里面的message不会重新进行分配,原来的partition里面的message数据不会变,新加的这个partition刚开始是空的,随后进入这个topic的message就会重新参与所有partition的load balance。
  • Partition Replica:每个partition可以在其他的kafka broker节点上存副本,以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。例如有5个kafka broker节点,某个topic有3个partition,每个partition存2个副本,那么partition1存broker1,broker2,partition2存broker2,broker3。。。以此类推(replica副本数目不能大于kafka broker节点的数目,否则报错。这里的replica数其实就是partition的副本总数,其中包括一个leader,其他的就是copy副本)。这样如果某个broker宕机,其实整个kafka内数据依然是完整的。但是,replica副本数越高,系统虽然越稳定,但是回来带资源和性能上的下降;replica副本少的话,也会造成系统丢数据的风险。

参考文章:

https://blog.csdn.net/lingbo229/article/details/80761778

https://blog.csdn.net/qq_29186199/article/details/80827085

作者:安小岩说他很忙
来源链接:https://blog.csdn.net/JinXYan/article/details/89741071

版权声明:
1、JavaClub(https://www.javaclub.cn)以学习交流为目的,由作者投稿、网友推荐和小编整理收藏优秀的IT技术及相关内容,包括但不限于文字、图片、音频、视频、软件、程序等,其均来自互联网,本站不享有版权,版权归原作者所有。

2、本站提供的内容仅用于个人学习、研究或欣赏,以及其他非商业性或非盈利性用途,但同时应遵守著作权法及其他相关法律的规定,不得侵犯相关权利人及本网站的合法权利。
3、本网站内容原作者如不愿意在本网站刊登内容,请及时通知本站(javaclubcn@163.com),我们将第一时间核实后及时予以删除。


本文链接:https://www.javaclub.cn/server/68921.html

标签: Kafka
分享给朋友:

“kafka理论详解(超详细)” 的相关文章

Windows环境中Kafka的安装及使用

Windows环境中Kafka的安装及使用

Kafka安装及使用 1. 简介 2.环境搭建 2.1安装JDK(例如JDK1.8等) 2.2 安装Zookeeper 2.3 安装Kafka...

kafka Java客户端之 consumer API 多线程消费消息

kafka Java客户端之 consumer API 多线程消费消息

kafka consumer 线程设计 Kafka Java Consumer采用的是单线程的设计。其入口类KafkaConsumer是一个双线程的设计,即用户主线程和心跳线程。 用户主线程,指的是启动Consumer应用程序main方法的线程,心...

kafka 安装 测试 could not be established. Broker may not be available

liulux服务器,安装启动kafka服务 kafka_2.12-2.2.0.tgz 解压安装包,修改config目录中zookeeper.properties和server.properties配置文件,一般只需要修改日志和数据保存的路径,端口使用默认...

Ubuntu20.04安装kafka

Ubuntu20.04安装kafka

文章目录 简介 为什么需要消息中间件 Kafka一代 - 消息队列 Kafka二代 - Partition Kafka三代 - Broker集群...

kafka在windows下的安装与配置

kafka在windows下的安装与配置

kafka在windows下的安装与配置 1.配置JDK (1)配置环境变量 (2)打开Dos界面,检查 2.配置Zookeeper (1)下载稳定版。 下载地址:http://mirrors.hust.e...

Kafka 环境安装与使用

Kafka 环境安装与使用

Kafka 环境安装 1.上传及解压 tar zxvf /opt/software/kafka_2.11-0.11.0.2.gz -C /opt/install/ 2.创建软连接和环境变量[可选] cd /opt/install...

kafkaManager 安装

kafkaManager 安装

个人博客地址:http://blogxinxiucan.sh1.newtouch.com/2017/07/11/kafkaManager安装/ Kafka Manager 安装 Kafka Manager是用于管理Apache Kafka的工...

Kafka系列:Kafka安装完整步骤

Kafka系列:Kafka安装完整步骤

目录 下载 修改配置 启动 #启动ZK #启动Kafka 验证 #查看分片情况   前提:安装JDK1.8   下载 http://kafka.apache.org/downloa...

Windows安装配置Kafka

Windows安装配置Kafka

kafka是一个分布式消息队列。具有高性能、持久化、多副本备份、横向扩展能力。 下载地址: Zookeeper下载地址: https://archive.apache.org/dist/zookeeper/zo...

Kafka的安装与入门基础

Kafka的安装与入门基础

0 Java消息服务(Java Message Service,JMS) Java消息服务(Java Message Service,JMS)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。