服装设计找图网站,wordpress页面教程,帮忙做网站,哪个网站可以做免费商业推广导语
Pulsar Meetup 2024 北京站已经成功落下帷幕。在本次盛会中#xff0c;腾讯云的高级工程师韩明泽和王震江为与会者带来了精彩的演讲。他们围绕多网接入、集群迁移以及高可用最佳实践这三大核心议题#xff0c;深入剖析了《腾讯云上基于 Apache Pulsar 的大规模生产实践…导语
Pulsar Meetup 2024 北京站已经成功落下帷幕。在本次盛会中腾讯云的高级工程师韩明泽和王震江为与会者带来了精彩的演讲。他们围绕多网接入、集群迁移以及高可用最佳实践这三大核心议题深入剖析了《腾讯云上基于 Apache Pulsar 的大规模生产实践》为听众呈现了一场知识与经验交织的盛宴。
作者介绍
王震江
腾讯研发工程师负责腾讯云 TDMQ for Apache Pulsar 商业化开发开源社区爱好者
韩明泽
腾讯高级工程师负责腾讯云 TDMQ for Apache Pulsar 商业化开发
拥有7年消息队列开发经验熟练掌握 Pulsar、 Kafka、RocketMQ 等主流消息队列
Apache Pulsar/BookKeeper/Zookeeper contributorRoP maintainer
多网络接入
网络介绍
云环境中我们常遇到三种网络类型内网、VPC虚拟私有云以及公网。若 VPC 和公网需要访问集群则必须通过网络寻址功能实现 IP 映射从而打通这些网络。在以往的方案中这一步骤是通过 AdvertisedListenersListenerName 来完成的它负责将每个 IP 映射文件存放在 Broker 集群里。 然而这种方法带来了三个显著的问题。
首先配置过程变得相当复杂。由于每个接入点都对应一个 IP 映射随着接入点的不断增加这些映射文件会变得异常庞大管理起来极为不便。同时每个 Broker 所对应的文件可能并不一致这进一步加剧了配置的复杂性。
其次这种架构导致了职责的混淆。Broker 本应专注于消息的收发过程但在此架构下它还需承担网络寻址的职责这使得其职责变得模糊不清。
最后这种方法的维护成本也相对较高。配置文件频繁变动修改起来既麻烦又容易出错。而且如果不同节点之间的数据不一致导致整体维护难度很大。
路由寻址
针对上述挑战我们创新性地提出了路由寻址方案。这一改进方案的核心在于引入 LookupService 来执行路由寻址任务通过数据库集中管理和维护网络映射和寻址信息。
路由寻址方案带来了四大显著优势
● 架构简化从下图可以看出整个系统结构更加简洁明了避免了不必要的复杂性。
● 职责明确在此方案下Broker 得以专注于其核心任务——消息的收发而无需再承担网络寻址的职责实现了有效的解耦。
● 运维便捷运维团队只需专注于管理工作无需与 Broker 进行繁琐的交互从而大大降低了运维成本和复杂性。
● 扩展性强这一优势在多集群管理或集群迁移时尤为明显它确保了业务的稳定性和连续性为系统的未来发展奠定了坚实基础。
综上所述路由寻址方案的提出不仅有效解决了原有方案中的问题还带来了诸多优势为系统的优化和升级提供了有力支持。
集群迁移
产品形态
TDMQ Pulsar 主要有三种典型的产品形态。
第一种是 Broker 共享Bookie 共享这种的产品形态成本比较低但是存在一些问题主要面临隔离性问题和稳定性问题。
第二种是 Broker 独占Bookie 独占这种形态下计算层、存储层资源独占。这种形态优点是隔离性好缺点是成本相对较高
第三种是 Broker 独占Bookie 共享。这种形态综合考虑了稳定性和成本算是一种折中的方案。
三种形态并无明显的优劣之分更多的是要结合实际的应用场景做出选择。
整体架构
我们最初采用的都是共享的产品形态。但是随着用户规模增加对产品的稳定性提出更高的要求共享形态并不能很好的满足业务的诉求。他们需要从共享模式迁移到更为适合的后两种模式。这时集群迁移问题便随之而来。为了应对这一挑战我们精心设计了集群迁移方案该方案主要包含以下四个关键步骤
● 元数据同步
● 数据同步GEO
● 订阅进度同步GEO补偿
● 切换集群Unload寻址调整
订阅进度说明
整体的集群迁移实现逻辑比较简单。主要的难点在于订阅进度的同步上。
在使用社区 GEO 方案进行订阅进度同步时我们发现存在一些问题。GEO 中的订阅进度只会同步 MarkDeletePosition这样会导致订阅进度并不完整。因为 Pulsar 中订阅进度是由两部分组成的。这意味着在实际迁移的过程中用户可能会遇到消息大量重复处理的情况。
进度同步
为了解决集群迁移过程中可能出现的消息重复消费问题我们创新性地提出了一个补偿方案。
1、 我们会在同步消息到目标集群的时候在消息的元数据中携带原集群的消息 ID。
2、 我们会将原集群中的订阅进度MarkDeletePosition和IndividuallyDeleteMessages同步到目标集群。
3、 当消费者迁移到目标集群后。在目标集群中读取消息之后如果消息是来自原集群那我们将原集群中的消息 ID 和原集群的订阅集群进行比对如果判断消息已经在原集群中消费完成我们就将消息过滤掉不再投递给消费者。
通过上面的机制我们有效解决了消费进度同步不完整的问题。
高可用最佳实践
如今公司对 TDMQ Pulsar 集群的基本要求已经远远超越了单点故障的防范而是至少需要具备可用区级别的容错能力。更进一步对集群能力乃至跨地域能力的需求也日益增长。
在此我们将重点聚焦于可用区维度的探讨。特别是在存储层面副本的分布策略显得尤为重要。
可用区容灾
在高可用存储系统中副本分布是确保数据可靠性和系统稳定性的关键环节。其中机架感知和跨可用区分布是副本分布策略的重要方面。
机架感知
机架感知是指系统能够识别并感知到不同服务器所在的机架从而在分配副本时尽量将副本分散到不同的机架上。这样做的好处是当某个机架出现故障时其他机架上的副本仍然可用保证了数据的可靠性和系统的稳定性。
跨可用区分布
跨可用区分布是指将副本分散到不同的可用区如不同的地理区域或数据中心。这样做可以进一步提高数据的可靠性和系统的容错性。当某个可用区出现故障时其他可用区上的副本可以接管并提供服务确保系统的持续运行。
在实现跨可用区分布时通常需要配置相关的参数来开启机架感知和跨可用区分布功能。这些配置通常包括指定副本的数量、分布方式以及可用区的选择等。
注意事项
尽管副本分布策略可以显著提高系统的可靠性和稳定性但在实际执行过程中仍需注意以下几点
● 副本恢复过程的数据保证
在副本恢复过程中需要保证剩余的副本数量大于等于w-a1w是写副本数a是确认副本数。这是为了确保在恢复过程中即使出现部分副本丢失或不可用的情况仍然有足够的副本可以恢复数据保证数据的不丢失和高可靠性。
● 处理数据堆积和读取策略
在某些情况下可能会出现数据堆积和读取策略不当的问题。例如当某个副本节点出现故障时如果是读堆积消息可能会导致读取速度变慢。因为读取的时候默认是轮询读取每个副本节点当读取到故障节点的时候会出现超时的情况造成读取性能明显下降。为了解决这个问题可以优化读取策略或开启粘性读开关使系统在选择读取节点时更加智能和高效。
最佳实践
在3可用区和2可用区下既能满足数据高可靠又能满足服务可用性的部署形态。
地域容灾
除了副本分布策略外容灾能力也是确保系统高可用性的重要方面。容灾能力是指系统在出现故障或灾难时能够快速恢复并提供服务的能力。
在实现容灾能力时通常需要建立异地备份集群并定期同步数据。当主集群出现故障时可以切换到备份集群提供服务。同时还需要建立相应的运营切换机制和消息堆积处理机制以确保系统的持续运行和数据的一致性。
综上所述高可用存储层的副本分布策略及注意事项是确保系统可靠性和稳定性的重要环节。在实际应用中需要根据具体的业务场景和需求来选择合适的策略并注意相关的注意事项以确保系统的正常运行和数据的安全性。
总结
展望未来我们将继续致力于优化 Apache Pulsar 在腾讯云上的应用不断提升系统的性能、稳定性和可用性。我们将持续关注用户需求不断推出更多创新性的解决方案以满足用户在不同场景下的需求。同时我们也将积极参与开源社区的建设与更多开发者共同推动 Apache Pulsar 的发展为消息队列技术的进步贡献我们的力量。
