曲阜市政对过做网站的是那家,新网站怎么做优化,腾讯云服务器12元一年,注册网站刀具与钢材经营范围一、简介Apache Pulsar是Apache软件基金会顶级项目#xff0c;是下一代云原生分布式消息流平台#xff0c;集消息、存储、轻量化函数式计算为一体#xff0c;采用计算与存储分离架构设计#xff0c;支持多租户、持久化存储、多机房跨区域数据复制#xff0c;具有强一致性、…一、简介Apache Pulsar是Apache软件基金会顶级项目是下一代云原生分布式消息流平台集消息、存储、轻量化函数式计算为一体采用计算与存储分离架构设计支持多租户、持久化存储、多机房跨区域数据复制具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性被看作是云原生时代实时消息流传输、存储和计算最佳解决方案。二、架构介绍Pulsar由Producer、Consumer、多个Broker、一个BookKeeper集群、一个Zookeeper集群构成Producer数据生成者即发送消息的一方。生产者负责创建消息将其投递到Pulsar中。Consumer数据消费者即接收消息的一方。消费者连接到 Pulsar 并接收消息进行相应的业务处理。Broker无状态的服务层负责接收消息、传递消息、集群负载均衡等操作Broker不会持久化保存元数据。BookKeeper有状态的持久层包含多个Bookie负责持久化地存储消息。ZooKeeper存储Pulsar、BookKeeper的元数据集群配置等信息负责集群间的协调(例如Topic与Broker的关系)、服务发现等。Broker扩展在Pulsar中Broker是无状态的当需要支持更多的消费者或生产者时可以简单地添加更多的Broker节点来满足业务需求。Pulsar支持自动的分区负载均衡在Broker节点的资源使用率达到阈值时会将负载迁移到负载较低的Broker节点这个过程中分区也将在多个Broker节点中做平衡迁移一些分区的所有权会转移到新的Broker节点。Bookie扩展存储层的扩容通过增加Bookie节点来实现。在BooKie扩容的阶段由于分片机制整个过程不会涉及到不必要的数据搬迁即不需要将旧数据从现有存储节点重新复制到新存储节点。Topic分区TopicTopic-Partition Pulsar的Topic可以分为非分区Topic和分区Topic。普通的Topic仅仅被保存在单个Broker中这限制了Topic的最大吞吐量。分区Topic是一种特殊类型的主题支持被多个Broker处理从而实现更高的吞吐量。持久Topic、非持久Topic默认情况下Pulsar会保存所有没确认的消息到BookKeeper中。持久Topic的消息在Broker重启或者Consumer出现问题时保存下来。除了持久TopicPulsar也支持非持久Topic。这些Topic的消息只存在于内存中不会存储到磁盘。因为Broker不会对消息进行持久化存储当Producer将消息发送到Broker时Broker可以立即将ack返回给Producer所以非持久Topic的消息传递会比持久Topic的消息传递更快一些。相对的当Broker因为一些原因宕机、重启后非持久Topic的消息都会消失订阅者将无法收到这些消息重试Topic由于业务逻辑处理出现异常消息一般需要被重新消费。Pulsar支持生产者同时将消息发送到普通的Topic和重试Topic并指定允许延时和最大重试次数。当配置了允许消费者自动重试时如果消息没有被消费成功会被保存到重试Topic中并在指定延时时间后重新被消费。死信Topic当Consumer消费消息出错时可以通过配置重试Topic对消息进行重试但是如果当消息超过了最大的重试次数仍处理失败时该怎么办呢Pulsar提供了死信Topic通过配置deadLetterTopic当消息达到最大重试次数的时候Pulsar会将消息推送到死信Topic中进行保存。订阅subscription订阅类型Subscription typePulsar支持独占Exclusive、灾备Failover、共享Shared、Key_Shared这四种订阅类型。独占ExclusiveSinglePartitionExclusive下只允许Subscription存在一个消费者如果多个消费者使用同一个订阅名称去订阅同一个Topic则会报错。如下图只有Consumer A-0可以消费数据。灾备FailoverFailover下一个Subscription中可以有多个消费者但只有Master Consumer可以消费数据。当Master Consumer断开连接时消息会由下一个被选中的Consumer进行消费。分区TopicBroker会按照消费者的优先级和消费名的顺序对消费者进行排序将Topic均匀地分配给优先级最高的消费者。非分区TopicBroker会根据消费者订阅的非分区Topic的时间顺序选择消费者。共享Shared shared中多个消费者可以绑定到同一个Subscription上。消息通过 round robin即轮询机制分发给不同的消费者并且每个消息仅会被分发给一个消费者。当消费者断开连接所有被发送给消费者但没有被确认的消息将被重新处理分发给其它存活的消费者。Key_Shared Key_Shared中多个Consumer可以绑定到同一个Subscription。消息在传递给Consumer时具有相同键的消息只会传递给同一个Consumer。订阅模式Subscription modes订阅模式有持久化和非持久化两种。订阅模式取决于游标(cursor)的类型。创建订阅时将创建一个相关的游标来记录最后使用的位置。当订阅的consumer重新启动时它可以从它所消费的最后一条消息继续消费。Durable持久订阅游标是持久性的会保留消息并保持游标记录的位置。当Broker重新启动时可以从BookKeeper中恢复游标消息可以从游标上次记录的位置继续消费。默认情况下都是持久化订阅。NonDurable非持久订阅游标不是持久性的当Broker宕机时游标会丢失并无法恢复所以消息无法继续从上次消费的位置开始继续消费。多主题订阅当Consumer订阅Topic时默认指定订阅一个主题。从Pulsar的1.23.0-incubating的版本开始Pulsar消费者可以同时订阅多个Topic。可以通过两种方式进行订阅正则表达式例如persistent://public/default/finance-.*明确指定Topic列表。Pulsar生产者Producer访问模式消息生成者有多种模式访问Topic 可以使用以下几种方式将消息发送到Topic。Shared默认情况下多个生成者可以将消息发送到同一个Topic。Exclusive在这种模式下只有一个生产者可以将消息发送到Topic 当其他生产者尝试发送消息到这个Topic时会发生错误。只有独占Topic的生产者发生宕机时Network Partition该生产者会被驱逐新的生产者才能产生并向Topic发送消息。WaitForExclusive在这种模式下只有一个生产者可以将消息发送到Topic。当已有生成者和Topic建立连接时其他生产者的创建会被挂起而不会产生错误。如果想要采用领导者选举机制来选择消费者的话可以采用这种模式。2.路由模式当将消息发送到分区Topic时需要指定消息的路由模式这决定了消息将会被发送到哪个分区Topic。Pulsar有以下三种消息路由模式RoundRobinPartition为默认路由模式。RoundRobinPartition如果消息没有指定key为了达到最大吞吐量生产者会以round-robin 轮询方式将消息发布到所有分区。请注意round-robin并不是作用于每条单独的消息而是作用于延迟处理的批次边界以确保批处理有效。如果消息指定了key分区生产者会根据key的hash值将该消息分配到对应的分区。这是默认的模式。SinglePartition如果消息没有指定key生产者将会随机选择一个分区并发布所有消息到这个分区。如果消息指定了key分区生产者会根据key的hash值将该消息分配到对应的分区。CustomPartition自定义模式用户可以创建自定义路由模式通过实现MessageRouter接口实现自定义路由规则。批量处理Pulsar支持对消息进行批量处理。批量处理启用后Producer会在一次请求中累积并发送一批消息。批量处理时的消息数量取决于最大消息数单次批量处理请求可以发送的最大消息数和最大发布延迟单个请求的最大发布延迟时间决定。索引确认机制 启用批量索引确认机制Consumer将筛选出已被确认的批量索引并将批量索引确认请求发送给Broker。Broker维护批量索引的确认状态并跟踪每批索引的确认状态以避免向Consumer发送已确认的消息。当该批信息的所有索引都被确认后该批信息将被删除。key-based batchingkey_shared模式下Broker会根据消息的key来分发消息但默认的批量处理模式无法保证将所有的相同的key都打包到同一批中而且Consumer在接收到批数据时会默认把第一个消息的key当作这批消息的key这会导致消息的错乱。因此key_shared模式下不支持默认的批量处理。key-based batching能够确保Producer在打包消息时将相同key的消息打包到同一批中从而consumer在消费的时候也能够消费到指定key的批数据。没有指定key的消息在打包成批后这一批数据也是没有key的Broker在分发这批消息时会使用NON_KEY作为这批消息的key。Pulsar消费者ConsumerPulsar提供两种确认模式累积确认消费者只需要确认最后一条收到的消息在此之前的消息都不会被再次发送给消费者。单条确认消费者需要确认每条消息并发送ack给Broker。AcknowledgmentsGroupingTracker消息的单条确认和累积确认并不是直接发送确认请求给Broker而是把请求转交给AcknowledgmentsGroupingTracker处理。为了保证消息确认的性能并避免Broker接收到非常高并发的ack请求Tracker默认支持批量确认即使是单条消息的确认也会先进入队列然后再一批发往Broker。在创建consumer的时候可以设置acknowledgementGroupTimeMicros默认情况下每100ms或者堆积超过1000时AcknowledgmentsGroupingTracker会发送一批确认请求。如果设置为0则每次确认消息后Consumer都会立即发送确认请求。Pulsar服务端Broker是Pulsar的一个无状态组件主要负责运行以下两个组件http服务提供为生产者和消费者管理任务和Topic查找的REST API。Producer通过连接到Broker来发送消息Consumer通过连接到Broker来接收消息。调度器提供异步http服务用于二进制数据的传输。Pulsar Broker会默认删除已经被所有Consumer确认的消息并以backlog的方式持久化存储所有未被确认的内消息。Pulsar的message retention(消息留存) 和message expiry (消息过期)这两个特性可以调整Broker的默认设置。Message retention: 保留Consumer已确认的消息。 通过留存规则的设定可以保证已经被确认且符合留存规则的消息持久地保存在Pulsar中而没有被留存规则覆盖、已经被确认的消息会被删除。Message expire消息过期设置未确认消息的存活时长TTL。通过设置消息的TTL有些即使还没有被确认但已经超过TTL的消息也会被删除消息去重实现消息去重的一种方式是确保消息仅生成一次即生产者幂等。这种方式的缺点是把消息去重的工作交由应用去做。在Pulsar中Broker支持配置开启消息去重用户不需要为了消息去重去调整Producer的代码。启用消息去重后即使一条消息被多次发送到Topic上这条消息也只会被持久化到磁盘一次。去重原理Producer对每一个发送的消息都会采用递增的方式生成一个唯一的sequenceID这个消息会放在message的元数据中传递给Broker。同时Broker也会维护一个PendingMessage队列当Broker返回发送成功ack后Producer会将PendingMessage队列中的对于的sequence id删除表示Producer任务这个消息生产成功。Broker会记录针对每个Producer接收到的最大Sequence ID和已经处理完的最大Sequence ID。当Broker开启消息去重后Broker会对每个消息请求进行是否去重的判断。收到的最新的Sequence ID是否大于Broker端记录的两个维度的最大Sequence ID如果大于则不重复如果小于或等于则消息重复。消息重复时Broker端会直接返回ack不会继续走后续的存储处理流程。BundleTopic分区与Broker的关联是通过Bundle机制进行管理的。每个namespace存在一个Bundle列表在namesapce创建时可以指定Bundle的数量。Bundle其实是一个分片机制每个Bundle拥有 namespace 整个hash范围的一部分。每个Topic (分区) 通过hash运算落到相应的Bundle区间进而找到当前区间关联的Broker。每个Bundle绑定唯一的一个Broker但一个Broker可以有多个Bundle。Pulsar存储层Bookkeeper分片存储概念BookieBookKeeper的一部分处理需要持久化的数据。LedgerBookKeeper的存储逻辑单元可用于追加写数据。Entry写入BookKeeper的数据实体。当批量生产时Entry为多条消息当非批量生产时Entry为单条数据
