Apache

原文作者 Sanjeev Kulkarni，翻译 Sijia@StreamNative，如需转载，请后盾留言。英文链接：https://streamnative.io/blog/... 对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ Pulsar Functions 是开源数据技术框架 Apache Pulsar 为轻量级计算提供的内置流处理器。在 2020 年 Pulsar Summit 会议上，我发表了一次对于 Pulsar Functions 的演讲。本文将深刻探讨 Functions 的架构和实现细节。 Pulsar Functions 简介Pulsar Functions 是 Pulsar 音讯零碎的外围计算根底构造。应用 Pulsar Functions，无需部署独自的零碎（如 Apache Storm、Apache Heron），即可基于单条音讯创立简单的解决逻辑，简化事件流并引入无服务架构。 轻量级计算 function 从一个或多个 Pulsar topic 生产音讯，将用户提供的解决逻辑利用于每条音讯，并公布计算结果到其余 topic。因为不须要内部解决零碎，Pulsar Functions 不仅使利用程序开发更便捷，还简化了故障排除操作，加重了运维累赘。 另外，开发人员能够间接应用 Pulsar Functions 的 API。理解 Java 语言的程序员能够间接应用 Java SDK 编写 function。示例如下： import java.util.function.Function; public class ExclamationFunction implements Function<String, String> @Override public String apply(String input) { return input + "!"; }}Pulsar Functions 旨在借助简略的 API 和执行框架解决常见的流应用场景（如过滤、路由、裁减），而不是替换重量级流解决引擎（如 Spark、Flink）。 ...

导读：在 3 月 6 日 TGIP-CN 直播流动上，咱们邀请到 StreamNative 高级工程师吕能，他为大家分享了 Pulsar Function Mesh 的性能与个性。上面是吕能分享视频的简洁文字整顿版本，供大家参考。很快乐明天能跟大家分享 StreamNative 基于 Pulsar Function 做的新工作：Function Mesh，它整个外围的想法是把一些简单的、拆散的、独自治理的 Function 进行统一化治理，基于原生地整合到 Kubernetes 中，并能充分利用其多方面的性能和调度算法。 Pulsar 中的数据处理 首先看一下 Pulsar 中所反对的各种数据处理的模块和形式，次要分为三个方面。第一，是基于 Presto 的交互式查问，Pulsar 中有本人的 Pulsar SQL，基于 Presto 对 Pulsar 整个集群查问；有和 Presto 相干的 Connector，能够间接通过 Presto 集群来查问 topic。 第二，作为音讯队列、音讯解决数据的外围，Pulsar 能够对接各种不同的流数据或者批数据处理的框架，比方 Flink、Spark、Hive。后续咱们会公布 Pulsar 和 Flink SQL 整合的残缺解决方案。 最初是 Pulsar 内建了 Pulsar Function，核心思想在于提供一个最简略的 API，让用户可能不便地解决在 Pulsar 中流动的数据。总结来说，Pulsar Function 是一个轻量级数据处理的过程，次要进行如下操作： 生产来自一个或多个 Pulsar topic 的音讯；将用户提供的解决逻辑利用于每个音讯；将后果公布到一个 Pulsar topic。Pulsar Function何为 Pulsar Function ...

本文作者是 Axel Sirota，译者为 StreamNative 的刘昱、Jennifer、Sijia。 原文链接 https://streamnative.io/en/bl...。 对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/ Pulsar 2.0 版本引入 Pulsar Functions。Pulsar Functions 反对用户轻松地平滑迁徙到无服务应用程序。本文次要介绍 Pulsar Functions 的根本信息以及如何开发 Pulsar Functions。此外，本文还列举了将应用程序迁徙到 Pulsar Functions 时的一些注意事项。 简略场景假如有这样一个应用场景：咱们经营一家电子商务公司，公司次要业务是解决领取发票。在 Pulsar 中，这一业务蕴含以下三步： 将发票导入到订单 topic；执行代码，以逗号分隔发票值；将发票值写入 PostgreSQL。本文次要介绍第二步。一般来说，咱们执行的代码可能是在 AWS Lambda 中创立的无服务 function，也可能是成熟的微服务。这种办法有很多毛病。 首先，咱们为一段简短代码开发全面服务。因为开发工作比较复杂，所以齐全实现可能须要两周工夫。 其次，因为源数据 schema 始终在变，保护工作也会越来越难。咱们须要对服务和根底 PostgreSQL 表进行残缺的版本控制和重新部署，而这一项工作可能须要至多一天工夫。 此外，在连贯或断开 Pulsar 时，AWS Lambda function 须要进行身份验证。Pulsar 先调用 Lambda function，而后由 Lambda function 本身向 Pulsar 验证身份。因为 Lambda function 引入了非必要的音讯双向传递，因而会影响性能。 引入 Pulsar FunctionsPulsar Functions 是轻量级计算框架，用于解决 topic 之间的数据。Pulsar Functions 在 Pulsar 中运行，因而无需独自部署微服务，节省时间，简化排错。 ...

简介：基于RocketMQ和Hudi零代码构建Lakehouse架构，以及RocketMQ Connector & RocketMQ Stream助力ETL数据分析，为大家提供疾速构建Lakehouse的技术计划和低运维老本实现实时计算的解决方案。 本文目录背景常识大数据时代的构架演进RocketMQ Connector&StreamApache Hudi构建Lakehouse实操本文题目蕴含三个关键词：Lakehouse、RocketMQ、Hudi。咱们先从整体Lakehouse架构动手，随后逐渐剖析架构产生的起因、架构组件特点以及构建Lakehouse架构的实操局部。 背景常识1、Lakehouse架构Lakehouse最后由Databrick提出，并对Lakehouse架构特色有如下要求： （1）事务反对 企业外部许多数据管道通常会并发读写数据。对ACID事务的反对确保了多方并发读写数据时的一致性问题； （2）Schema enforcement and governance Lakehouse应该有一种形式能够反对模式执行和演进、反对DW schema的范式（如星星或雪花模型），可能对数据完整性进行推理，并且具备强壮的治理和审计机制； （3）开放性 应用的存储格局是开放式和标准化的（如parquet），并且为各类工具和引擎，包含机器学习和Python/R库，提供API，以便它们能够间接无效地拜访数据； （4）BI反对 Lakehouse能够间接在源数据上应用BI工具。这样能够进步数据新鲜度、缩小提早，并且升高了在数据池和数据仓库中操作两个数据正本的老本； （5）存储与计算拆散 在实践中，这意味着存储和计算应用独自的集群，因而这些零碎可能扩大到反对更大的用户并发和数据量。一些古代数仓也具备此属性； （6）反对从非结构化数据到结构化数据的多种数据类型 Lakehouse可用于存储、优化、剖析和拜访许多数据利用所需的包含image、video、audio、text以及半结构化数据； （7）反对各种工作负载 包含数据迷信、机器学习以及SQL和剖析。可能须要多种工具来反对这些工作负载，但它们底层都依赖同一数据存储库； （8）端到端流 实时报表是许多企业中的规范利用。对流的反对打消了须要构建独自零碎来专门用于服务实时数据利用的需要。 从上述对Lakehouse架构的特点形容咱们能够看出，针对繁多性能，咱们能够利用某些开源产品组合构建出一套解决方案。但对于全副性能的反对，目前如同没有一个通用的解决方案。接下来，咱们先理解大数据时代支流的数据处理架构是怎么的。 大数据时代的架构演进1、大数据时代的开源产品大数据时代的开源产品种类繁多，音讯畛域的RocketMQ、Kafka；计算畛域的flink、spark、storm；存储畛域的HDFS、Hbase、Redis、ElasticSearch、Hudi、DeltaLake等等。 为什么会产生这么多开源产品呢？首先在大数据时代数据量越来越大，而且每个业务的需要也各不相同，因而就产生出各种类型的产品供架构师抉择，用于反对各类场景。然而泛滥的品类产品也给架构师们带来一些困扰，比方选型艰难、试错老本高、学习老本高、架构简单等等。 2、以后支流的多层架构大数据畛域的解决解决场景蕴含数据分析、BI、科学计算、机器学习、指标监控等场景，针对不同场景，业务方会依据业务特点抉择不同的计算引擎和存储引擎；例如交易指标能够采纳binlog + CDC+ RocketMQ + Flink + Hbase + ELK组合，用于BI和Metric可视化。 （1）多层架构的长处：反对宽泛的业务场景； （2）多层架构的毛病： 解决链路长，提早高；数据正本多，老本翻倍；学习老本高；造成多层架构毛病次要起因是存储链路和计算链路太长。 咱们真的须要如此多的解决方案来反对宽泛的业务场景吗？Lakehouse架构是否能够对立解决方案？多层架构的存储层是否能够合并？Hudi产品是否可能反对多种存储需要？多层架构的计算层是否能够合并？RocketMQ stream是否可能交融音讯层和计算层？以后支流的多层架构 3、Lakehouse架构产生Lakehouse架构是多层架构的降级版本，将存储层复杂度持续升高到一层。再进一步压缩计算层，将音讯层和计算层交融，RocketMQ stream充当计算的角色。咱们失去如下图所示的新架构。新架构中，音讯出入口通过RocketMQ connector实现，音讯计算层由RocketMQ stream实现，在RocketMQ外部实现音讯计算两头态的流转；计算结果通过RocketMQ-Hudi-connector收口落库Hudi，Hudi反对多种索引，并提供对立的API输入给不同产品。 Lakehouse架构 上面咱们剖析下该架构的特点。 （1）Lakehouse架构的长处： 链路更短，更适宜实时场景，数据新鲜感高；老本可控，升高了存储老本；学习成本低，对程序员敌对；运维复杂度大幅升高；（2）Lakehouse架构的毛病 对音讯产品和数据湖产品的稳定性、易用性等要求高，同时音讯产品须要反对计算场景，数据湖产品须要提供弱小的索引性能。 （3）抉择 在Lakehouse架构中咱们抉择音讯产品RocketMQ和数据湖产品Hudi。 同时，能够利用RocketMQ stream在RocketMQ集群上将计算层放在其中集成，这样就将计算层升高到一层，可能满足绝大部分中小型大数据处理场景。 接下来咱们逐渐剖析RocketMQ和Hudi两款产品的特点。 RocketMQ Connector & StreamRocketMQ 倒退历程图 RocketMQ从2017年开始进入Apache孵化，2018年RocketMQ 4.0公布实现云原生化，2021年RocketMQ 5.0公布全面交融音讯、事件、流。 ...

作者：Matteo Merli，StreamNative CTO，Apache Pulsar PMC 主席；Addison Higham，StreamNative 主管工程师，Apache Pulsar Committer。 本文译自 StreamNative 英文博客，原文链接：https://streamnative.io/blog/...，更多详情请参考 StreamNative 公众号。 此文于本周二更新，具体增加了最新的 Log4j 破绽如何影响其余 Pulsar 生态系统工具的详细信息。 上周末，Apache 开源我的项目 Log4j 2.16.0 被曝出新的破绽，Log4j 紧急公布 2.17.0 版本。本文为大家提供最新版 Apache Pulsar 无关 Log4Shell 要害破绽（即 log4j）的更新。以下列举了开源版本 Apache Pulsar 中破绽的状态，以及须要解决安全漏洞所需采取的措施。  破绽影响与我的项目状态更新目前总共发现了三个影响 log4j 的 CVE。在这三个破绽中，默认状况下只有两个影响 Apache Pulsar。Pulsar 社区始终在致力修补所有三个 CVE 造成的破绽影响。截至目前，Pulsar 版本 2.9.1 和 2.8.2 已更新 log4j 版本并解决所有已知破绽造成的影响。Pulsar 2.7 和 2.6 的新版本公布正在进行中。下表总结了 log4j 破绽的影响和解决破绽影响的操作。 解决方案非标准 log4j / Pulsar Functions 和过程运行时用户解决方案如上所示，如果用户配置了 customer log4j 模板字符串或通过过程运行时（Process Runtime）应用 Pulsar Functions，即便配置了 no message lookup 解决措施，内部也能够利用 log4j 进行破绽攻打。总而言之，如果用户已将 log4j 模板字符串配置为蕴含对上下文对象（$${ctx:}、%x、%mdc 等）的援用，或者通过过程运行时应用 Pulsar Functions，那么你的零碎可能面临危险。咱们倡议用户删除自定义设置，如果必须通过过程运行时应用 Pulsar Functions 的话则降级到 Pulsar 2.8.2 或 2.9.1 版本。 ...

作者：Matteo Merli，Apache Pulsar PMC 主席，StreamNative CTO近日，因为Apache Log4j2 某些性能存在递归解析性能，攻击者可间接结构歹意申请，触发近程代码执行破绽。该破绽的细节和修复停顿能够参考 CVE-2021-44228. Apache Pulsar 的以后版本捆绑受此破绽影响的 Log4j2 版本。咱们强烈建议您遵循 Apache Log4j 社区的倡议并尽快修补您的零碎。 针对 Apache Pulsar 零碎而言，有两种解决办法能够修补 Pulsar 部署。您能够设置以下任一项： Java属性： -Dlog4j2.formatMsgNoLookups=true 环境变量： LOG4J_FORMAT_MSG_NO_LOOKUPS=true 以上两种办法都能够无效缓解 Pulsar 服务的破绽。 此外，当应用 Kubernetes 运行时运行 Pulsar Functions 时，您应该依照以下示例更新 Docker 镜像。 如果您应用 Pulsar Helm Chart 在 Kubernetes 中进行 Pulsar 部署，该 Helm Chart 的新版本已可用，并且已利用了上述解决办法。如果你的生产环境不适宜将其降级，还能够通过将 -Dlog4j2.formatMsgNoLookups=true 增加到 configData 中的 PULSAR_EXTRA_OPTS，用于 proxy、broker、BookKeeper、ZooKeeper、主动复原和 helm 值文件中的相干组件来缓解该破绽。 社区正在减速新的补丁公布，以及 2.7.4、2.8.2 与 2.9.1 版本的公布，这些版本将在将来几天内准备就绪，并将捆绑蕴含破绽修复的 Log4j2 2.15.0 版本。 技术支持如果您对该破绽中 Apache Pulsar 相干事项有任何问题或疑虑，欢送在 Apache Pulsar GitHub 仓库提 issue，或者在 Pulsar 技术交换群中与社区交换。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/ 近期，Apache Pulsar 社区公布了 Pulsar 2.7.4 版本！新版本涵盖 32 位贡献者提供的改良和谬误修复，并提交了 98 次变更。 版本亮点 将 Log4j 降级至 2.17.0 版本 - CVE-2021-45105[1]。 PR-13392[2]回收 OpAddEntry 时能够正确援用 ManagedLedger。PR-12103[3]当 ManagedLedger 敞开时，在 OpAddEntry 上不会产生 NPE。PR-12364[4]本博客按我的项目性能更新状况分组，介绍了 2.7.4 版本最值得关注的停顿，如需理解所有性能降级和 bug 修复的残缺列表，请查阅 Pulsar 2.7.4 公布注记[5] 。 Bug 修复和性能加强PR-13392[6]：将 log4j 降级至2.17.0 版本 - CVE-2021-45105[7] 问题： 对于 Log4j 的重大破绽容许攻击者近程执行。该破绽问题在 CVE-2021-44228[8] 形容和跟踪。 解决方案： 将 log4j 降级至 2.17.0 版本。详情参考博客。 PR-12103[9]：回收 OpAddEntry 时能够正确援用 ManagerLedger 。 问题： 此版本之前，在写入失败后，会在后盾安顿一个工作来强制敞开 ledger 并触发新 ledger 的创立。如果 OpAddEntry 实例已被回收，则可能导致 NPE 或未定义的行为。 解决方案： ManagedLedgerImpl 对象援用被复制到最终变量，后台任务将不依赖于 OpAddEntry 实例的生命周期。 PR-12123[10]： BlobStoreBackedReadHandler 中没有潜在的竞态条件。 问题： 此版本之前，BlobStoreBackedReadHandler 在读取 offload ledger 时进入有限循环。在读取 entry 和敞开 BlobStoreBackedReadHandler 的操作之间存在竞态条件。 ...

编者荐语： 本文转载自腾讯云中间件公众号。作者林琳，Apache Pulsar PMC，腾讯云中间件专家工程师，《深刻解析Apache Pulsar》作者。本系列第一篇文章为大家解读 Pulsar 中音讯确认的模式。 导语在 Apache Pulsar 中，为了防止音讯的反复投递，消费者进行音讯确认是十分重要的一步。当一条音讯被消费者生产后，须要消费者发送一个 Ack 申请给 Broker，Broker 才会认为这条音讯被真正生产掉。被标记为曾经生产的音讯，后续不会再次反复投递给消费者。在这篇文章中，咱们会介绍 Pulsar 中音讯确认的模式，以及失常音讯确认在 Broker 侧是如何实现的。 确认音讯的模式在理解 Pulsar 音讯确认模式之前，咱们须要先理解一些前置常识 —— Pulsar 中的订阅以及游标（Cursor）。Pulsar 中有多种生产模式，如：Shared（共享）、Key_shared（键共享）、Failover（灾备） 等等，无论用户应用哪种生产模式都会创立一个订阅。订阅分为长久订阅和非长久订阅，对于长久订阅，Broker 上会有一个长久化的 Cursor，即 Cursor 的元数据被记录在 ZooKeeper。Cursor 以订阅（或称为生产组）为单位，保留了以后订阅曾经生产到哪个地位了。因为不同消费者应用的订阅模式不同，能够进行的 Ack 行为也不一样。总体来说能够分为以下几种 Ack 场景： 1. 单条音讯确认（Acknowledge）和其余的一些音讯零碎不同，Pulsar 反对一个 Partition 被多个消费者生产。假如音讯 1、2、3 发送给了 Consumer-A，音讯 4、5、6 发送给了 Consumer-B，而 Consumer-B 又生产的比拟快，先 Ack 了音讯 4，此时 Cursor 中会独自记录音讯 4 为已 Ack 状态。如果其余音讯都被生产，但没有被 Ack，并且两个消费者都下线或 Ack 超时，则 Broker 会只推送音讯 1、2、3、5、6，曾经被 Ack 的音讯 4 不会被再次推送。 ...

本文翻译自《Distributed Locks with Apache Pulsar》。原文链接：https://theboreddev.com/distr...译者简介魏伟 kivenwei，7 年研发工作经验， 次要经验了 SOA、微服务架构。相熟云计算畛域的开源软件倒退和 CNCF、云原生生态，目前就任于中广核智能科技有限责任公司。 有时，软件工程师常常面临最具挑战性的工作就是如何确保咱们的分布式应用程序中每次只有一个组件在执行相应的计算。 例如，应用程序中三个运行节点，并且咱们须要每天运行一个打算工作，如何保障仅其中一个节点能够触发运行工作呢？如果咱们在此工作中向客户发送电子邮件并在三个节点上运行工作，则咱们的客户可能会收到 3 次此电子邮件。大失所望， 那么如何解决此问题呢？ 有人可能会说：“简略，只运行一个节点！”。 其实，没那么容易。在大多数状况下，咱们必须确保服务具备足够的可用性级别，而仅运行一个节点意味着如果呈现问题，服务将不可用。 咱们真正须要的计划是抉择某个“主节点”来负责此工作。另一个须要思考的因素是如果咱们的主节点呈现故障，则必须立刻将此工作委托给其中一个备用节点执行工作以防止中断。 让咱们来看看，咱们想要实现的成果。如下图： 在操作上，须要找出一种简略的办法来“选举”负责执行工作的主节点，其它节点将急躁期待轮到它执行的状况。因而这些备用节点将处于所谓的“休眠”状态；只有在主节点故障或无响应时，备用节点才会被唤醒。 如何解决这个问题在一些场景中，会偏向于用一些相当简单的实现去确保只有其中一个节点执行工作。 当初一些数据库引擎反对的“CAS”原子操作，可能是疾速解决这个问题的正当办法。咱们利用数据库中一项个性即可解决问题，而无需本人从新实现。然而如果数据库不反对这样的原子操作呢？ 问题会变得更简单，因为每个节点都会尝试竞争以取得锁，然而两个节点能够同时取得锁的值为“free”且都胜利设置了值，而不会留神到另一个节点也“取得锁”。这意味着不仅有一个节点，而是两个节点都将执行此工作，例如向客户发送电子邮件， 然而，即便在数据库中反对 CAS 操作，也须要提供一些机制来确保如果咱们的主节点故障后备用节点来接管：一个相似于心跳的过程，一直查看状态并在节点呈现故障时采取相应措施。然而，这种计划较为耗时耗精力，现实状况下，咱们心愿利用欠缺的并通过全面测试的产品。 如果你曾经部署了 Pulsar，那么这正是咱们应用 Apache Pulsar 这类产品来解决这一问题的起因。Kafka 也能够实现相似的解决方案，但这篇文章次要聚焦于 Apache Pulsar。 应用 Apache Pulsar 实现分布式锁那么如何去利用 Apache Pulsar 的劣势呢？Pulsar 提供了一种叫做 failover（灾备）的订阅机制，它次要实现了一个 leader 选举机制。 如何充分利用这种选举机制来保障打算工作只执行一次呢？ 无需深刻理解实现的具体细节，因为这在很大水平上取决于应用场景，能够想出一个简略的办法来实现这一点。具体如下： 基于心跳事件的主动启动调度器一个实现办法是启动一个消费者并开始监听心跳事件，而后立刻开始发送心跳事件。消费者将应用 failover（灾备）订阅来订阅主题。因而，只有一个节点可能启动调度程序。如果主节点故障，那么其余备用节点将接管并立刻启动工作。下图是实现的思路： 在这个例子中，咱们有一个主题来治理分布式锁，每个消费者定期向这个主题发送心跳，同时应用 failover（灾备）订阅主题。只有其中一个节点会成为主节点并解决心跳事件。如果主节点还没有启动邮件调度器，它会在收到第一个心跳后立刻启动；对于其余的心跳，只有调度程序在运行，它们就会被疏忽。 如果主节点故障后将会产生什么？具体看下图： 在主节点故障的状况下，Pulsar 的灾备（failover）订阅会检测到该节点曾经故障，备用节点将接管。在图中，左侧的备用节点将收到心跳，触发工作执行的开始。一旦以前的主节点复原，它将作为备用节点再次“休眠”。 论断咱们个别不倡议只为了实现分布式锁就采纳任何新技术，通常寻找并利用以后产品的劣势能够节省时间、升高操作的复杂性。 当然，用户也能够在其余零碎上构建本人的分布式锁，但这须要工夫，而且也容易出错。然而在 Pulsar 的实现过程中，该个性通过其余工程师的彻底测试后可用且牢靠，可为用户节俭贵重的工夫，缩小操作上的问题。 关注公众号「Apache Pulsar」，获取干货与动静 退出 Apache Pulsar 中文交换群 ...

作为 Pulsar 社区的一员，想为社区做奉献却没有脉络吗？最详尽文档翻译指南来啦！Pulsar 中文社区贡献者并不局限于奉献代码，撰写、翻译文档也能够成为另一种意义上的 Pulsar Contributor！ 本次为不相熟文档翻译意愿工作的小伙伴们带来文档翻译奉献指南，手把手带你相熟如何进行社区意愿奉献！ 社区翻译工作类型以后，社区文档翻译工作分为三种： Apache Pulsar 官网文档翻译：次要工作是将 Apache Pulsar 网站上的英文文档翻译为中文，让更多中文用户更加容易浏览。翻译平台应用 Crowdin 进行翻译提交、治理和审核；Apache Pulsar 英文博客翻译：内容范畴较广，次要聚焦技术原理、案例等方向，英文文章翻译在开释给社区成员翻译之前，咱们均已获得原文作者受权；Apache Pulsar Weekly（周报）翻译：内容次要聚焦 Apache Pulsar 社区当周的亮点、重要个性、重要 bug 修复、流动和新闻、技术博文举荐几个板块。术语库为了保障英文术语翻译的对立，不便大家了解，咱们长期以来都在保护与 Apache Pulsar 相干的术语库，目前术语库词条已达 500 余条。倡议在进行官网文档和英文博客翻译前，仔细阅读术语库，升高后续翻译审阅工作量。 术语表地址：https://shimo.im/sheets/5jozG...翻译流程参加文档、博客翻译工作，简要步骤如下： 扫描文末二维码增加 Pulsar Bot 好友，回复「志愿者」退出 Pulsar 中文社区志愿者微信群，在 Translation Library 翻译内容看板认领（在认领的Issue 上评论留言，并在群内@管理员 Tango 留言 Issue 序号进行认领）点击认领的 Issue 工作，依据不同翻译工作类型进入 Crowdin 平台或 Google Docs注册/登录本人的 Crowdin 账号或 Google 账户（倡议应用谷歌邮箱登陆）开始进行 Issue 工作工作实现后分割管理员进行审核工作应用 Crowdin 翻译技术文档请留神，把 Crowdin 圈红处须设置成如图所示（突出显示未翻译、已翻译和 Review 后的字符串，以及是否显示中文预览），不便具体的分辨需翻译的内容。 此处的 ID、Lable 咱们个别不翻译，保留英文。 Crowdin 的翻译是分段的，所以咱们须要提前选定点击所想要翻译的英文段（如图左侧红色区域），零碎会在右上角（圈红区域）主动生成默认文本，在蓝色区域内输出咱们翻译的内容。 文本中黄色内容为默认链接，翻译时保持原状即可（能够点击上方黄色区域主动复制或点击左下角红框内的按钮进行全文本复制后替换其中的英文）。 ...

踩着 11 月的尾巴，Apache Pulsar 迎来了一位新 committer——郭吉伟。郭吉伟目前在 StreamNative 做 Pulsar 主我的项目与其周边生态的开发工作，也是 MoP（MQTT-on-Pulsar）的 maintainer。同时，他也是 Apache DolphinScheduler 的 PMC 成员。咱们采访了这位领有多重身份的开源人，与他聊一聊在 Apache Pulsar 社区的经验和感想。（以下内容采纳第一人称。） 个人简介大家好，我是郭吉伟，很荣幸成为 Apache Pulsar committer 并通过采访与大家见面。我目前在 StreamNative 做 Pulsar messaging 相干的开发工作，主攻 MoP（MQTT-on-Pulsar），也是 MoP 我的项目的 maintainer。 “古早” Pulsar 我的项目爱好者我应该是国内很晚期理解到 Pulsar 的那批人了。Pulsar 中文社区在 2019 年成立，然而我和 Pulsar 的缘分能够追溯到 2016 年。过后公司的基础架构应用的是 RocketMQ，我通过开源理解到更多的 MQ 产品，于是早在 2016 年就入门理解了 Pulsar 这个我的项目。 起初我退出陌陌的基础架构组。过后陌陌用 Kafka 呈现了很多运维艰难，比方扩缩容、异步报错等。咱们调研了 Pulsar 并开始部署应用 Pulsar。在此期间我参加了屡次社区 meetup，接触到了许多资深的 Pulsar 开发者与用户，让我加深了对我的项目、社区的理解，也奠定了后续成为“全职开源人”的根底。 全职做开源—— Pulsar 开发者有人问我为什么退出 StreamNative 去全身心地围绕 Pulsar 投入开源。首先因为我看好 Pulsar 技术的前沿性，在云原生的潮流下，Pulsar 存储计算拆散的分布式架构最合乎当下企业数字化需要。 ...

本文翻译自《Apache Pulsar: A Unified Queueing and Streaming Platform》，作者 Addison Higham。原文链接：https://thenewstack.io/apache...译者简介Addison 是 StreamNative 主管工程师。本文译者为刘梓霖 。当初咱们能够大胆宣言：种种迹象表明，Apache Pulsar 这个开源分布式音讯零碎正站在古代利用架构和开发的风口浪尖。 为什么咱们敢于这样讲呢？ 随着工程师团队面对越来越简单的挑战，解决层出不穷的问题所需的技术和工具也在一直倒退。这其中罕用的一种工具是消息传递。 消息传递基于音讯队列。音讯在客户端应用程序之间进行异步排列，由一个“broker” 充当各应用程序之间的媒介。 在晚期的技术中，broker 是绝对简略的。但随着理论需要的变动音讯零碎也随之产生了变动。分布式音讯零碎便是建设在这个概念的根底上，不仅具备可靠性、可扩展性和持久性的长处，且多个 “broker” 能够帮忙分担负载。 大多数的分布式音讯零碎反对一种类型的语义：流或队列。从以往教训看，每一种都有其最适宜的特定类型的场景。Apache Pulsar 的独特之处在于它同时反对流和队列这两种语义。 在探讨应用对立的音讯流零碎带来的劣势之前，让咱们先退一步，别离钻研一下音讯队列和流技术。 流零碎是行业中绝对较新的翻新技术，它能够以有序、低提早的形式挪动大量数据。流零碎非常适合于挪动数据（比方：日志、指标或者点击事件的数据等）并将其集中到一个地位，同时实现高并发和高吞吐。 举个例子，比方从大型云部署中的 10,000 台机器中获取点击或者指标数据。流零碎为这一操作过程提供了便当。 某种程度上，音讯队列与流零碎有些相似，行将多个零碎链接在一起。然而，音讯队列历史较久，而且更多地是对于点对点的通信，帮忙宽泛的应用程序替换信息。 这两种零碎的拜访模式也是不同的：流零碎专一于依照程序达到的音讯和解决同一批的多个音讯组，可能也用于聚合或转换数据。 相比之下，在音讯队列中，事件通常是一次解决一个。就像在工作队列中一样，每个音讯可能就代表某个特定的“工作”。换句话说，流用于挪动和解决大量的数据组，而队列往往是对于单个音讯的精细化解决，以促成零碎中的某些工作。 最常见的流平台是 Apache Kafka 和 AWS 的 Kinesis。最常见的队列零碎包含 RabbitMQ 和 ActiveMQ。在云上，还有 Google 的 Pub/Sub、AWS SQS 和 SNS。 Apache Pulsar：对立音讯队列和流首先，简略回顾一下历史。 因为须要对十分大规模的工作负载进行队列化，Yahoo 外部最后是在 2010 年左右开发了 Pulsar 。Yahoo 服务规模宏大，散布在许多不同的团队和数据中心。 过后，他们正在应用 风行的 Java 社区规范Java 音讯服务（JMS），这，就须要一个新零碎既能够满足 JMS 规范要求，又能具备分布式和可扩展性。 只管 Pulsar 晚期原型零碎 API 最后专一于消息传递这一场景，但该零碎的架构设计也使其成为流零碎工作解决的现实计划，这使得 Yahoo 团队可能在更宽泛的场景下灵便应用该零碎。 ...

本文翻译自《Apache BookKeeper Internals — Part 1 — High Level》，作者 Jack Vanlightly。译者简介王嘉凌@中国移动云能力核心，挪动云Pulsar产品负责人，Apache Pulsar Contributor，沉闷于 Apache Pulsar 等开源我的项目和社区 本系列对于 BookKeeper 的博客心愿帮忙大家了解和把握 BookKeeper 原理和外部逻辑。了解零碎外部运行逻辑是疾速定位并解决生产问题以及开发和批改新性能的基石。在本系列后续文章中，我会将BookKeeper各项指标与运行机制相结合，为大家展示高效进行性能问题定位的办法。 BookKeeper 中蕴含很多不同的插件，咱们次要关注 BookKeeper 作为 Apache Pulsar 的存储层应用的场景，不会波及其余一些不相干的插件。同时，咱们次要关注单个 bookie 节点外部的逻辑，对于 BookKeeper 在集群模式下多个节点之间的正本备份和通信协议相干的内容能够参考咱们之前的博客。 咱们次要先关注数据的读写流程，后续咱们也会波及数据回收、数据压缩和CLI工具等内容。 如果你看过 BookKeeper 的代码你会发现有些模块具备多个形象实现，咱们不去关注具体每个形象实现的区别（这些区别只和一些 BookKeeper Contributor 无关），而是重点关注解决申请的线程、数据的流向以及线程、数据结构和长久化存储之间的关联。 架构原理视图咱们能够简略的把一个 BookKeeper 服务端节点（即 bookie）分为三层：顶层是网络通信层（应用Netty），底层是磁盘IO层，中间层蕴含大量的缓存。咱们能够把 Bookie 了解为一个纯正的存储节点，负责尽可能快地写入和读取 ledger entry 数据，以及保障这些数据的平安。 这个视图外部蕴含了多个模块和线程模型，在本篇博客中咱们会逐层剖析和解释它们之间的关系。 组成模块每个 ledger entry 都会被写入 journal 和 ledger 两个存储模块，Ledger 存储模块是长久化的存储，它有多种实现，在 Pulsar 集群中咱们应用的是 DbLedgerStorage。 Journal 模块保障落盘的数据不会丢并提供低提早的写性能。Entry 数据胜利写入 journal 后会立刻触发同步的写申请的响应告诉客户端 entry 曾经被胜利写入磁盘。DbLedgerStorage 模块则以异步的形式将数据批量刷盘，并在刷盘时对批量数据进行优化，将雷同 ledger 的数据按 entry 进行排序，以便后续可能程序读取。稍后咱们会进行更具体的形容。 ...

平时在 Pulsar 交换群中，咱们发现大家在接触和应用 Pulsar 的过程中，会重复遇到相相似的问题。为了更高效地解决大家这些“高频疑难”，同时也对提出优质问题的敌人表示感谢，咱们特地建设了 FAQ 知识库，以便于收集及解答大家的疑难。 咱们将定期收集筛选社群内提出的高频问题，由社区专家甄别筛选出其中优质的发问进行答复，整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考，心愿能够帮忙大家解决应用 Pulsar 过程中的问题。 上面来看看本次收集的问题吧： 音讯保留问题 1： 在 Pulsar 的音讯保留机制里，Pulsar 的音讯被一个消费者 Ack 后就会进入保留策略。那么在多个消费者订阅了一个 Topic、某条音讯的局部消费者 Ack 的状况下，这条音讯是否会进入保留策略？ 解答：只有音讯在所有订阅里都被 ACK，才会进一步由保留策略解决。对于同一个订阅，由哪个消费者进行 ACK 不重要，只有被 ACK 一次，在这个订阅里音讯就是曾经被 ACK 的状态。具体可参考：https://pulsar.apache.org/doc... 重试次数问题 2： Pulsar 反对参数配置重试次数吗？ 解答：不反对。Pulsar 依照工夫来进行退却重试策略，和重试次数机制相似。客户端外部的重试策略是用的退却（backoff）机制，能够配置 ClientBuilder 的 backoff 参数来管制。 /** * Set the duration of time for a backoff interval. * * @param duration the duration of the interval * @param unit the time unit in which the duration is defined * @return the client builder instance */ ClientBuilder startingBackoffInterval(long duration, TimeUnit unit); /** * Set the maximum duration of time for a backoff interval. * * @param duration the duration of the interval * @param unit the time unit in which the duration is defined * @return the client builder instance */从生产者的角度，能够在 ProducerBuilder 中配置总的 send timeout。 ...

平时在 Pulsar 交换群中，咱们发现大家在接触和应用 Pulsar 的过程中，会重复遇到相相似的问题。为了更高效地解决大家这些“高频疑难”，同时也对提出优质问题的敌人表示感谢，咱们特地建设了 FAQ 知识库，以便于收集及解答大家的疑难。 咱们将定期收集筛选社群内提出的高频问题，由社区专家甄别筛选出其中优质的发问进行答复，整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考，心愿能够帮忙大家解决应用 Pulsar 过程中的问题。 上面来看看本次收集的问题吧： Node.js 客户端 Broker 配置问题 1： Pulsar Node.js 客户端配置多个 Broker，只有第一个 Broker 挂掉了，生产者和消费者就无奈建设连贯。客户端为什么只连配置里的第一个 Broker？ 解答：如果 Pulsar Node.js 客户端配置多个 Broker，只有第一个 Broker 挂掉了，生产者和消费者就无奈建设连贯。客户端为什么只连配置里的第一个 Broker？ 不反对配置多个 Service URL，能够通过 DNS 或者 L4 proxy 代理 Broker 的形式来解决，Client 连贯域名或者 L4 proxy。Java Client/Go Client 等曾经都有多个 Service URL 的反对。Node.js Client 能够在后续的版本中减少在多个 Service URL 的反对。 Topic 数量及其影响问题 2： 在几千个生产者的前提下，设计 Pulsar topic 时应抉择都发到一个 topic，还是别离发送对应数量的 topic？ 解答：在 Pulsar 中每个 Partition 只能由一个 Broker 负责，也就是说如果只有一个 Partition 的 Topic 流量超过 Broker 的负载极限时就无奈扩大了，能够将一个 Topic 的多个 Partition 调配到多个 Broker 上，因而能够利用多个 Broker 的资源。所以不应该依照客户端的数量来决定主题的数量或者是主题的 Partition 的数量，应该依照具体的业务场景，对 Topic 的性能要求来决定。 ...

对于 FAQ 知识库 平时在 Pulsar 交换群中，咱们发现大家在接触和应用 Pulsar 的过程中，会重复遇到相相似的问题。为了更高效地解决大家这些“高频疑难”，同时也对提出优质问题的敌人表示感谢，咱们特地建设了 FAQ 知识库，以便于收集及解答大家的疑难。 咱们将定期收集筛选社群内提出的高频问题，由社区专家甄别筛选出其中优质的发问进行答复，整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考，心愿能够帮忙大家解决应用 Pulsar 过程中的问题。 上面来看看本期收集的问题吧： 统计 Topic 下音讯条数问题 1： 如何应用统计 Topic 下所有的音讯条数（非 Entry 条数 ）？ 解答：目前还没有这个个性，能够依据以后 Message Index 的个性来反对 Message Level 的 Backlog。相对来说，对于 Exclusive （独占）和 Failover （灾备）模式的解决会简略一些，对于反对单条音讯不间断签收的订阅来说会比较复杂一些。 百万量级 Topic 配置问题 2： 百万量级 Topic 下如何配置 Bookies、Broker 以及硬件？ 解答：容量评估须要联合音讯的大小/业务中理论能够接管的 Batch 大小等因素。如果一个音讯 100 Bytes，一个客户端发送，客户端每 2ms 打包发送，数据写两个正本，那根本 2 台机器就够了，然而这显著不符合实际的利用场景。对于 Pulsar 来讲容量评估次要思考几个方面的因素: 音讯吞吐量：间接决定对网卡和磁盘的需要，硬件反对的最大吞吐必须要 >= 冀望的吞吐；理论 Batch 的影响：决定了对 CPU 的需要，这个要依据具体的测试数据来，通过设置不同 Batch 大小做一些 Benchmark，再依据理论业务的状况来做评估；Topic 数量：决定对 Metadata Service 的需要，如果有几千个/几万个 Topic，那不必太思考这个方面的影响；如果几十万及以上的 Topic，那要给 ZooKeeper 一些比拟好的资源，尤其是在磁盘上，比方 Log Data 和 Data 离开，尽量应用 Nvme SSD 等。相干配置： ...

近日，Apache PLC4X 的创建者 Christofer Dutz 在 GitHub 上公布申明称，因为不足任何模式的回报，他将进行向 PLC4X 的企业用户提供收费社区反对。 这是继 Faker.js 作者清空我的项目存储库代码后，又一位软件作者对其余公司应用其开源我的项目却未有任何回报而感到悲观。 如果没有公司违心为该我的项目提供资金，他将进行对PLC4X的保护和任何模式的反对。 对于 Apache PLC4XApache PLC4X 是一个用于集成 PLC（可编程逻辑控制器）的库。因为大多数工业可编程逻辑控制器（PLC）应用大量不兼容的通信协议，因而与内部世界（IT/Internet）的交互变得艰难。PLC4X 我的项目的呈现，旨在提供一套对立的 API，通过这些 API 能够实现与大多数 PLC 通信的驱动程序（通过各种 PLC 本机通信协议）。 PLC4X 我的项目：开源软件只管收费 但也须要业界反对与纯软件我的项目不同，PLC4X 波及物联网和简单的自动化硬件，Christofer 不得不购买一些低廉的硬件和软件来测试和保护 PLC4X 我的项目，这让他陷入了可怕的财务状况。因而，Christofer 注册了一家名为 c-ware 的独立 IT 征询公司，以帮忙其余公司设计和施行 PLC4X 软件相干业务。 然而，这家公司做得并不好。Christofer 常常会收到这样的电子邮件： “感谢您提供的这款杰出的 PLC4X，它让咱们的生存变得轻松多了，我在外国最大的钢厂/航空航天公司/汽车制造商工作，当初公司遇到了……这样的问题，我心愿您能帮点忙。” “你是开源软件，对吗？你能帮我吗？” ...... 据报道显示，这家 c-ware 征询公司在 2020 年的财务状况良好，一些机构资金以及 PLC4X 的开发和保护仍在失常轨道上。但到了 2021 年，因为寰球疫情影响，惟一的资助也被撤回了，而去年 Christofer 也只承受了一次付费演讲。到了2022 年，Christofer 开始厌倦这种无奈维持收支平衡的日子：“我不想把贵重的工夫节约在耗费我却无奈给我任何回报的货色上。” 因而，他为 PLC4X 制订了一个新的开发计划：不再公费购买硬件来开发新的驱动程序或集成模块，不再将 PLC4X/驱动程序移植到新的语言上，也相对不再为公司提供收费征询、培训和反对。如果公司须要，他将仅提供商业技术支持和培训。 此外，Christofer 曾经为公司用户常常询问的每一项新的 PLC4X 性能建设了一个众筹我的项目“when they will be available”，并且只有在筹集到足够的资金后才会开始开发相应的性能。 ...

对于 Pulsar SummitPulsar Summit 是由 StreamNative 组织的 Apache Pulsar 社区年度盛会。于此盛会，大家分享 Apache Pulsar 实践经验、用户案例、技术探索和运维故事，交换探讨 Pulsar 我的项目最新进展和动静，彼此切磋。Pulsar Summit Asia 旨在汇集亚洲地区 Pulsar 开发者、贡献者和用户，促成 Apache Pulsar 在亚洲地区的倒退。 Pulsar Summit Aisa 2021 将于2022年1月15-16日以线上直播的模式举办。大会将分为主论坛和分论坛，汇聚技术大咖和行业先行者分享 Apache Pulsar 实践经验、用户案例、技术探索和运维故事，交换探讨 Pulsar 我的项目最新进展和动静，彼此切磋。 在本次大会中，腾讯云中间件团队三位高级研发工程师为大家带来两个演讲议题。 议题介绍讲师介绍冉小龙：腾讯云中间件团队研发工程师，Apache Pulsar committer，RoP 作者及 Maintainer，Apache BookKeeper contributor，Apache Pulsar Go client 作者，Apache Pulsar Go Functions作者，StreamNative/pulsarctl 作者 韩明泽：腾讯云中间件高级研发工程师、Apache Pulsar committer、RoP Maintainer 议题主题RocketMQ-on-Pulsar 架构设计与演进 议题简介2021年初，腾讯云 MQ 团队联结StreamNative 开源RoP (RocketMQ-on-Pulsar) ，并向Apache Pulsar 社区奉献了 0.1.0 版本的 RoP。近期，咱们在 RoP 0.2.0 中进行优化，晋升了以后 RoP 版本的整体性能和稳定性。本期咱们将介绍 RoP MessageID 重构、RoP 提早音讯和路由协定的设计与实现、RoP ACL 设计与实现、RoP 性能优化以及 RoP 在腾讯云中的利用。 议题纲要音讯队列中常见的提早音讯的设计和实现思路Apache Pulsar Broker Entry Metadata的实现思路及理论利用Apache RocketMQ 和 Apache Pulsar 实现音讯路由的不同思路Apache Pulsar 和 Apache RocketMQ 认证实现计划的异同讲师介绍林宇强：腾讯云中间件高级研发工程师，曾任微店中间件研发工程师，主导多款微店自研中间件从0到1的设计研发工作，包含微服务网关、服务治理平台、数据同步平台等，目前负责腾讯云TDMQ研发工作。 议题主题RabbitMQ on Pulsar 的实际和架构演进之路 议题简介RabbitMQ on Pulsar是腾讯云开发的协定处理器，可能在Pulsar上齐全兼容开源RabbitMQ协定。性能上能够反对RabbitMQ的鉴权、动静拓扑、金融级别、动静路由等性能个性。该架构反对多租户、资源隔离和主动负载平衡等云原生个性，让RabbitMQ用户无需批改代码即可登上云原生音讯队列列车，享受云原生带来的红利。本期咱们将分享腾讯云在Pulsar构建RabbitMQ协定适配的实际。 议题纲要版本1: 基于社区版本版本2：Compact Topic版本3：反对Declare版本4：Gateway模型会议议程概览 ...

昨天在百度云服务器上安装了gitea，应用起来还不错，还有我的项目看板性能。gitea默认通过3000端口拜访，而我的服务器上安装的是apache，所以就思考应用apache来做反向代理。 首先筹备好域名，git.example.cn 我的服务器上装的是ubuntu 20.04，开启apache的代理模块 cd /etc/apache2sudo a2enmod proxy proxy_balancer proxy_http这里用到了a2enmod，这个工具能够给apache减少失效模块，成果其实就是在mods-enabled目录建设软链接，指向mods-available目录下的模块。如果要让模块生效，则应用a2dismod。 好了，回归正题，前边开启了apache的代理相干模块，下边就来配置域名了。 在sites-available目录下新建一个配置文件，如下： cd ./sites-availablesudo cp 000-default.conf git.example.cn.conf编辑配置文件 sudo vim git.example.cn.conf<VirtualHost *:80>　ProxyPreserveHost On　ServerName git.example.cn　ProxyPass / http://127.0.0.1:3000/　ProxyPassReverse / http://127.0.0.1:3000/　<Proxy *>　Order Deny,AllowAllow from all　</Proxy></VirtualHost>配置文件编辑完之后，建设软链接 cd ../sites-enabledsudo ln -s ../sites-available/git.example.cn.conf而后重启apache服务 sudo systemctl restart apache2.service至此，咱们就能够应用git.example.cn这个域名来拜访gitea了。

python——append用法例如： 123a=[1,2,3] a.append(5)此时，运行后果为 [1, 2, 3, 5] 123a=[1,2,3] a.append([5])此时，运行后果为 [1, 2, 3, [5]] 后果不再为一个数组，而是list 用append生成多维数组： 1234567891011import numpy as np a=[] for i in range(5): a.append([]) for j in range(5): a[i].append(i)　后果如下： 123456789[[0, 0, 0, 0, 0], [1, 1, 1, 1, 1], [2, 2, 2, 2, 2], [3, 3, 3, 3, 3], [4, 4, 4, 4, 4]]　append（）在python的列表中是一个很好用的函数 3 examples to append list in python

码上送祝福，带云小宝回家做工作收费抽iphone13，还可得阿里云新春限量手办日期：2021.12.27-2022.1.16云小宝地址：https://developer.aliyun.com/special/luckycode 体验简介本场景将提供一台配置了CentOS 7.7操作系统的ECS实例（云服务器）。通过本教程的操作，您能够在一台CentOS 7.7操作系统的ECS实例上装置和部署LAMP环境，而后装置 WordPress，帮忙您疾速搭建本人的博客。场景地址：https://developer.aliyun.com/... 背景常识(次要波及以下几块内容，。理解更多能够至阿里云场景页 ) 云服务器ECSLAMPWordPress‘’进入体验点击开始体验/再次体验按钮 进入 装置并配置Apache服务Apache是Web服务器软件。本步骤将领导您如何在ECS实例上装置并配置Apache服务。 在实验室页面右侧，切换至Web Terminal。1，装置Apache。1）执行如下命令，装置Apache服务及其扩大包。 yum -y install httpd mod_ssl mod_perl mod_auth_mysql2）执行如下命令，查看Apache是否装置胜利。 httpd -v返回后果如下所示，示意您已胜利装置Apache。 3，执行如下命令，启动Apache服务。 systemctl start httpd.service4，在实验室页面右侧，，切换至远程桌面。 5，在远程桌面，双击关上Firefox ESR浏览器。 6，在Firefox ESR浏览器的址栏中，拜访http://<ECS公网地址>。 阐明 ：您须要将<ECS公网地址>替换为云产品资源列表中的ECS公网地址。 若返回页面如下图所示，阐明Apache服务启动胜利。 装置MariaDB数据库因为应用WordPress搭建云上博客，须要应用MySQL数据库存储数据。本步骤将领导您如何在ECS实例上装置MySQL的开源替代品MariaDB（MariaDB兼容MySQL），并创立博客数据库。1.在实验室页面右侧，切换至Web Terminal。2.执行如下命令，装置MariaDB Server。 yum install -y mariadb-server返回如下命令，示意您已装置实现MariaDB Server。 3.执行如下命令，启动MariaDB Server。 systemctl start mariadb4.执行如下命令，查看MariaDB Server运行状态。 systemctl status mariadb返回后果如下，您能够看到active (running)时，示意MariaDB Server启动胜利。 5.执行如下命令，设置数据库root用户的初始密码。 mysqladmin -u root -p password返回如下后果，因为您是第一次设置数据库明码，因而在呈现Enter Password提示符的时，间接回车即可。 返回如下后果，输出新密码为123456789，回车后再次输出123456789即可。 6.执行如下命令，连贯数据库。 mysql -uroot -p返回如下后果，呈现Enter password提示符的时，输出root用户的明码123456789，即可登录数据库。 ...

ssl证书是个很让人纠结的货色，业余证书要么贵要么不给力，本人制作一个吧目前网上又没有特地给力靠谱的教程，明天在公司纠结了一下，搞定了。 首先要感激这篇文章的作者，本文次要是参考这篇文章。 闲话休题，咱们言归正传。 首先找个linux，装个openssl（网上很多靠谱的教程，具体步骤略过）。 而后便开始一堆命令 openssl genrsa -des3 -out ssl.key 2048 这一步须要输出一个明码，轻易输一个就行了，前面貌似只须要用一次。。 mv ssl.key xxx.key openssl rsa -in xxx.key -out ssl.key rm xxx.key 下面第二步的时候须要输出后面那个明码 openssl req -new -key ssl.key -out ssl.csr 这一步须要填写很多信息，重点是Common Name，就是你须要应用这个证书的域名，貌似能够应用通配符。最初的challenge password不填 openssl x509 -req -days 3650 -in ssl.csr -signkey ssl.key -out ssl.crt 而后 cat ssl.key ssl.crt > ssl.pem 到此为止咱们失去了四个文件 ssl.csr ssl.crt ssl.key ssl.pem 上面开始纠结服务器配置吧！ nginx: 在server外面写一段： ssl on; ssl_certificate ssl.pem; ssl_certificate_key ssl.key; lighttpd: ssl.engine = "enable" ...

国内优良公共 DNS 服务腾讯https://www.dnspod.cn/Product...119.29.29.29182.254.118.118 阿里http://alidns.com/223.5.5.5223.6.6.6what is dns dns meaning 百度http://dudns.baidu.com/intro/...180.76.76.76 114DNShttp://www.114dns.com/114.114.114.114114.114.115.115 CNNIChttp://www.sdns.cn/1.2.4.8210.2.4.8 国外优良的 DNS 服务器Cloudflare DNSDNS： 1.1.1.1 谷歌主 DNS：8.8.8.8辅 DNS：8.8.4.4 Norton ConnectSafe主 DNS： 199.85.126.10辅 DNS： 199.85.127.10 诺顿以其杰出的防病毒，互联网安全服务和产品而闻名。他们的 DNS 服务器也不会令人悲观。 OpenDNS主 DNS： 208.67.222.222辅 DNS： 208.67.220.220 DNS Watch主 DNS： 84.200.69.80辅 DNS： 84.200.70.40 Comodo 平安 DNS主 DNS： 8.26.56.26辅 DNS： 8.20.247.20 威瑞信主 DNS： 64.6.64.6辅 DNS： 64.6.65.6 Verisign 的服务基于两个主题：作为匿名 DNS 服务器，并提供恶意软件和歹意网站的爱护。他们不会向第三方发售他们的信息，也不会向用户提供任何广告。 OpenNIC主 DNS： 192.95.54.3辅 DNS： 192.95.54.1 GreenTeamDNS主 DNS： 81.218.119.11辅 DNS： 209.88.198.133 best dns servers for gamingbest dns server for ps4 ps5free dns servers in 2021 ...

罕用的DNS记录CNAME 可能须要先大略介绍一下什么是CNAME：一个域名能够有两种类型的指向，如果一个 域名指向 称为一个 记录 （Record）的话，那么就有两种 记录类型 （Record Type），别离是： A记录 ：指向一个IP地址 CNAME ：指向一个其余的域名 DNS records CNAME设置这里有两条A记录，一条CNAME。两条A记录指向的就是我的博客所在的VPS：第二条容易了解，就是将 www.zhouliang.pro 指向了VPS的IP地址，这样你应用 http://www.zhouliang.pro 就能够拜访我的博客了；第一条有点奇怪，这里是一个泛域名，也就是将 zhouliang.pro 也指向了这个IP地址，也就是说你用 http://zhouliang.pro 也能够间接拜访我的博客。 彩蛋：买域名的时候特地留神服务商是不是提供收费的泛域名解析服务，不提供的都是耍流氓，据我所知，万网就是在耍流氓。 第三条记录就是一个CNAME指向，兴许你曾经在浏览器中关上了 http://i.zhouliang.pro ，我将 i.zhouliang.pro 转向了网易轻博客服务，放了几张照片，你们感受一下，小清爽有木有。 dig 命令学习Linux命令只有一条路，那就是： man dig ，到控制台敲一下这个命令，输入略长。本文的目标是先大抵介绍一下，深刻理解还是得细读 man dig 。 在控制台输出，输入后果如下： $ dig i.zhouliang.pro ; <<>> DiG 9.8.3-P1 <<>> i.zhouliang.pro ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45515 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ...

自 12 月 10 日起，Apache Log4j2 已接连曝出多个破绽，并在寰球范畴内造成了影响。刚刚过来的 12 月 18 日，Apache Log4j 又被曝出第三个破绽： CVE-2021-45105 —— Apache Log4j 2.0-alpha1 到 2.16.0 的版本无奈避免自援用查找的不受控递归（Apache 官网已公布 2.17.0 版本修复）。 （相干浏览： 高危 Bug ！Apache Log4j2 近程代码执行破绽：官网正加急修复中！https://segmentfault.com/a/11...Log4j 高危 Bug 已被连夜修复！维护者：“为了实现向后兼容性未删除旧性能而导致破绽”https://segmentfault.com/a/11...）破绽详情破绽形容： Apache 官网示意，对于 Apache Log4j 2.17.0 之前的版本而言，当日志记录配置应用具备上下文查找的非默认模式布局时（PatternLayout 与 Context Lookup：例如，$${ctx:loginId}）就很容易受到破绽的影响。胜利利用此破绽后，具备线程上下文映射（MDC）输出数据控制权的攻击者就可能会伪造蕴含递归查找的歹意输出数据，导致 StackOverflower 谬误，从而终止过程，也被称为DOS（拒绝服务）攻打。 据悉，最新破绽是由 Akamai Technologies 的 Hideki Okamoto 和一名匿名破绽钻研人员发现的。Apache 留神到，只有 Log4j 外围 JAR 文件受到 此次CVE-2021-45105 破绽的影响。 破绽影响： 攻击者胜利利用此破绽或导致拒绝服务（DoS）。 破绽评分详细信息： CVE：CVE-2021-45105 评分：7.5（高）向量：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Apache 官网已公布 2.17 版本修复好在，12 月 19 日，该破绽 CVE-2021-45105 Apache Log4j 已在官网最新公布的 Log4j 2.17.0 (Java 8)版本中失去了修复。 ...

2021年12月10日，国家信息安全破绽共享平台（CNVD）收录了Apache Log4j2近程代码执行破绽，编号CVE-2021-44228。 【破绽形容】Apache Log4j2是一款开源的Java日志记录工具，该工具重写了Log4j框架，并引入了大量丰盛个性，可管制日志信息输送的目的地为控制台、文件、GUI组件等，在国内外利用十分宽泛。 12月10日凌晨，Apache开源我的项目Apache Log4j 2被曝出近程代码执行破绽，其存在JNDI注入破绽，攻击者利用该破绽，通过结构歹意申请在指标服务器上执行任意代码，导致服务器被攻击者管制，从而进行页面篡改、盗取数据等行为，危害性极高，简直所有行业都受到该破绽影响。 【验证等级】CNVD综合评级为“高危” 【影响范畴】Java类产品：Apache Log4j 2.x < 2.15.0-rc2 【修复倡议】目前破绽POC已被公开，官网已公布平安版本，若是应用Java开发语言的零碎须要尽快确认是否应用Apache Log4j 2插件，并尽快降级到最新版本。 工夫点：2021年12月7日，Apache官网公布log4j-2.15.0-rc12021年12月10日，Apache官网公布log4j-2.15.0-rc22021年12月11日，Apache官网公布log4j-2.15.0（同log4j-2.15.0-rc2）2021年12月13日，Apache官网公布log4j-2.16.0-rc1 地址：https://github.com/apache/log... 蚂蚁切面平安RASP应急止血计划【RASP详细分析】蚂蚁切面平安RASP人造具备对Log4j破绽的防护能力，因为RASP是在应用程序外部hook要害函数，只关注执行动作，只有部署了RASP的利用可不依赖外界而具备自我爱护能力，即：RASP自身对攻击者执行敏感门路下文件的读取/批改、发外链等动作已具备拦挡能力，攻击者无奈对利用造成太多高危破坏性攻打。 蚂蚁切面平安RASP针对Log4j破绽在高维水平仍做了应急措施，分为3个阶段：第1阶段：无攻打poc时，基于猜想的计划都未采纳 从网络相干的注入点动手，通过查看是否蕴含log4j相干的堆栈来进行拦挡。毛病：惯例网络申请都会通过此注入点，需获取堆栈匹配，性能影响十分大。从 JNDI 要害底层办法，通过查看是否蕴含log4j相干的堆栈来进行拦挡。毛病：需获取堆栈匹配，影响利用失常应用 JNDI 能力，有肯定性能影响。第2阶段：拿到poc后，迅速制订和验证止血策略，确定RASP参战因为JNDI对log4j来说是以插件模式存在，所以有对立的执行入口，由堆栈图可知RASP能够从几处进行拦挡解决，其中“InitialContext.java:417”为原生底层办法，毛病上文曾经提到，所以可用的点为“JndiManager.java:85” 和 “JndiManager.java:61” 。其中注入点“JndiManager.java:85” 为 2.1.x 后引入，注入点 “JndiManager.java:85” 可笼罩 2.x 所有版本，然而为防止通过其余破绽绕过执行，最终两个注入点都进行了拦挡包含获取 jdbc 连贯地址时应用 jndi 的状况也进行了拦挡，因为此种状况是通过 log4j2 配置而非内部输出触发。 毛病：无 长处： 因为不须要匹配任何参数，无需放心性能问题；只有解析后的内容应用了JNDI才会触发，无需放心各种变种payload，无反抗老本；只针对log4j2本身应用JNDI的场景，不影响利用失常应用JNDI能力。第3阶段：RASP部署上线 + 止血策略公布，继续至今蚂蚁平安团队依据危害水平开始紧急分批进行部署上线和止血策略公布工作。 第一天：被动外联的高危利用灰度预发环境止血实现。第二天：被动外联的高危利用线上 93%实现止血。【RASP应急止血成果】 拿到poc后20分钟即实现进攻策略并验证胜利。2小时内实现log4j 2.x所有版本包含对应sec版兼容性测试。24小时内实现高危利用预发和灰度环境的止血，并在生产环境小范畴验证。48小时实现93%高危利用生产环境止血。【RASP应急止血劣势】劣势1： 以数据为载体的破绽在业界很少见，导致WAF适用范围无限。攻击者一旦跨过边界在公司技术体系外部横向挪动根本无法管制，因而应用切面平安RASP技术从外部阻断拦挡更精准，成果更好。 劣势2： 相比传统平安产品、官网版本修复形式，RASP具备： 不用等官网计划，只有分明了破绽利用细节，RASP即可开开始发挥作用。应用切面RASP参战止血，使研发工程师防止了在短时间内以狗急跳墙形式应急，RASP在争取了两周缓冲工夫的同时也不会打乱研发降级节奏，晋升了研发工程师幸福感。RASP适配各种环境，无需思考降级版本兼容问题。劣势3： 蚂蚁平安团队已输入针对于Log4j破绽的专治小工具 minirasp，给生态搭档和外部一些非标技术栈的利用应急应用。定制的minirasp成果超出预期，在规范RASP不能笼罩的海量数据处理工作job、海量udf中施展了关键作用，能止本次Log4j破绽隔山打牛之痛。 蚂蚁切面平安RASP为利用运行时平安提供疫苗级防护当下网络安全局势愈发严厉，传统的基于流量检测的边界进攻产品极易被绕过，基于规定库更新的平安产品更是时效性低，此类后知后觉的平安产品已无奈满足平安市场需求。 2012年Gartner首次提出一种新型web防护技术 —— RASP（Runtime Application self-Protection）。区别于传统平安产品，RASP是一种基于行为和上下文语义剖析的新型平安技术，在应用程序外部hook要害函数，只关注执行动作，在不更新策略和不降级利用代码的状况下检测/拦挡未知破绽，RASP像疫苗一样注入进利用实体外部，让利用不依赖外界而具备自我爱护能力。 一句话概括：装载RASP的利用对Log4j2破绽具备人造防护能力，此外，对于所有因JNDI注入导致的近程命令执行、文件目录列出、任意文件上传、敏感文件下载等行为均可实现拦挡。 另外，蚂蚁RASP也反对检测/拦挡内存马攻打、反序列化破绽、命令注入、任意文件上传、近程执行命令等，全笼罩2021版OWASP TOP 10 中的Web应用程序平安危险类别。蚂蚁RASP为企业应用提供函数级实时防护，具备较强的启发式检测能力，秒级拦挡、应急止血，晋升平安水位，尤其适宜大量应用开源组件的互联网利用或应用第三方集成商开发的利用。 ...

导语12 月 9 日晚间，Apache Log4j 2 发现了近程代码执行破绽，歹意使用者能够通过该破绽在指标服务器上执行任意代码，危害极大。 腾讯平安第一工夫将该破绽收录至腾讯安全漏洞特色库中，CODING 制品扫描基于该破绽特色库，对援用了受影响版本的 Log4j 2 制品进行了精准定位，并给出修复倡议，同时可禁止下载含有该安全漏洞的制品，最大限度的缩小破绽蔓延。 Apache Log4j 2 破绽详情Apache Log4j 2 是一个基于 Java 的日志记录工具。该工具重写了 Log4j 框架，并且引入了丰盛的个性，作为日志记录根底第三方库，被大量 Java 框架及利用应用。 此次破绽是因为 Log4j 2 提供的 lookup 性能造成的，该性能容许开发者通过一些协定去读取相应环境中的配置。但在实现的过程中，并未对输出进行严格的判断，从而造成破绽的产生，当程序将用户输出的数据进行日志记录时，即可触发此破绽。 破绽详情： 破绽名称Apache Log4j 2 任意代码执行破绽威逼等级高危破绽详情已公开POC已知EXP已知破绽威逼Apache Log4j 2影响范畴Apache Log4j 2 2.0 - 2.14.1破绽编号暂无在朝利用已发现平安版本Log4j-2.15.0-rc2Log4j 2 的应用极为宽泛，可能受影响的利用及组件（包含但不限于）：Apache Solr、Apache Flink、Apache Druid、Apache Struts2、Srping-boot-strater-log4j2、ElasticSearch、Flume、Dubbo、Redis、Logstash、Kafka。 应用 CODING 制品扫描，疾速辨认受影响制品CODING 制品扫描曾经辨认到该破绽，能够在制品治理 - 制品扫描模块创立「安全漏洞扫描计划」，对相干 Maven 包进行平安扫描。在 CODING DevOps 线上版本中可间接对该破绽进行排查，私有化的 CODING DevOps 及 WePack 客户请分割客户经理征询降级。 扫描完结后，能够看到最新的中文破绽信息。该破绽的危险等级被腾讯平安定义为「危急」，同时该破绽应用宽泛，利用门槛低，被标记为「优先关注破绽」，在破绽详情中，咱们倡议用户尽快修复至「2.15.0-rc2」版本，将此依赖降级后，即可躲避破绽影响。 ...

几个小时前，互联网上曝出了 Apache Log4j2 中的近程代码执行破绽。攻击者可利用此破绽结构非凡的数据申请包，最终触发近程代码执行。据“白帽”剖析确认，简直所有技术巨头如百度等都是该 Log4j 近程代码执行破绽的受害者。 自从 11 月 24 日阿里巴巴云平安团队正式报告了该 Apache Log4J2 近程代码执行破绽以来，其危破绽危害已在互联网上继续蔓延。因为 Apache Log4j2 的某些函数具备递归剖析函数，因而攻击者能够间接结构歹意申请来触发近程代码执行破绽。 Apache Log4j2Apache Log4j2 最后是由 Ceki Gülcü 编写，是 Apache 软件基金会 Apache 日志服务项目的一部分。Log4j 是几种 Java 日志框架之一。而 Apache Log4j2 是对 Log4j 的降级，相比其前身 Log4j1 有了更显著的改良，同时修复了 Logback 架构中的一些固有问题。 通过 Apache Log4j2 框架，开发者可通过定义每一条日志信息的级别，来管制日志生成过程。 目前该日志框架已被宽泛用于业务零碎开发，用来记录日志信息。大多数状况下，开发者可能会将用户输出导致的错误信息写入日志中。 破绽形容Apache Log4j2 近程代码执行破绽的详细信息已被披露，而通过剖析，本次 Apache Log4j 近程代码执行破绽，正是因为组件存在 Java JNDI 注入破绽：当程序将用户输出的数据记入日志时，攻击者通过结构非凡申请，来触发 Apache Log4j2 中的近程代码执行破绽，从而利用此破绽在指标服务器上执行任意代码。 受影响版本： Apache Log4j 2.x <= 2.14.1 已知受影响的应用程序和组件： srping-boot-strater-log4j2Apache SolrApache FlinkApache Druid据悉，此次 Apache Log4j2 近程代码执行破绽危险已被业内评级为“高危”，且破绽危害微小，利用门槛极低。有报道称，目前 Apache Solr、Apache Struts2、Apache Druid、Apache Flink 等泛滥组件及大型利用均曾经受到了影响，需尽快采取计划阻止。 ...

本文策动：StreamNative，设计：cunjie@StreamNative对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 获取 PDF 文件获取上图 PDF 文件，请在 公众号【ApachePulsar】 后盾留言回复：“手册”，获取下载链接。 点击链接 ，获取 Apache Pulsar 硬核干货材料！

编者荐语： 文章作者为中国移动云能力核心，文章转载已受权。本文将具体解析基于 Apache Pulsar 的云原生音讯队列 AMQP 背景与整体设计等深度内容。 以下文章来源于苏研大云人，作者云原生中间件团队 情谊提醒：全文5000多文字，预计浏览工夫3分钟 一、自研音讯队列中间件AMQP的背景随着公司私有云业务继续倒退和用户数量的一直增长，数据量和申请量也在急剧增长，音讯队列作为必不可少的通信组件，面临的压力也在日益增长。在对音讯队列的组件保护中咱们发现：OpenStack应用的音讯队列RabbitMQ存在一些问题，比方音讯易失落，集群稳定性差，问题排查艰难等。诸多难以解决的问题使咱们萌发了寻求代替开源RabbitMQ音讯队列的想法；另一方面，支流云服务厂商，如阿里云、华为云、天翼云等均已提供AMQP协定反对的音讯队列产品，而咱们短少自研对标产品。基于以上两点，团队开始自研一款高性能、高牢靠、高稳固，反对AMQP协定的音讯队列产品。 咱们的需要综合云上产品和挪动云组件的需要，整顿了音讯队列AMQP的几大外围需要如下： 具备高吞吐量，低提早，高牢靠的能力；能依据需要进行无限度的扩容，缩容；对于上云产品来说，须要具备多租户隔离的能力；具备海量音讯沉积能力，并且音讯的沉积不会影响性能和稳定性；反对AMQP协定，兼容AMQP协定的客户端（比方，开源RabbitMQ SDK）；具备运维部署能力，数据迁徙的便利性，具备高效的集群部署、迁徙效率。开源产品调研在产品设计之初，研发团队次要调研了两款实现了AMQP协定的开源产品：RabbitMQ和Qpid。因为Qpid在性能方面体现不佳被排除在外，RabbitMQ性能高、应用范围广，然而不合乎咱们的需要应用场景，有如下几个起因： 长久化音讯性能较差。为了保障音讯不失落且音讯可回溯，须要将音讯长久化存储，通过测试RabbitMQ的长久化音讯性能较差，不满足咱们的需要，详见第四章节的性能测试比照。为了保障音讯不失落，能够应用RabbitMQ的镜像队列，镜像队列的机制就是音讯多正本保留在多节点的内存中，通过测试发现，在开启镜像队列的场景下，会呈现两方面的问题：首先是集群稳定性较差，其次是音讯沉积会导致内存溢出。问题排查的困难性，RabbitMQ的编程语言是Erlang，这种编程语言较为小众。RabbitMQ的源码艰涩难懂，导致呈现问题时，排查艰难，且RabbitMQ没有实时音讯追踪的能力，须要开启音讯追踪的插件，无奈及时回溯呈现问题的音讯。基于以上起因，咱们开始音讯队列AMQP的自研。 二、音讯队列AMQP整体设计计算存储拆散的架构思考到高稳定性、高可靠性和高吞吐量等诸多设计指标，研发团队最终决定采纳合乎云原生设计理念的计算存储拆散架构。 计算存储耦合和计算存储拆散有如下几个方面的比照： 当存储和计算耦合在一个集群中时，存在如下的一些问题： 在不同的利用或者倒退期间，须要不同的存储空间和计算能力配比，使得机器的选型会比较复杂；当存储空间或计算资源有余时，只能同时对两者进行扩容，导致扩容的经济效率比拟低（另一种扩容的资源被节约了）；在云计算场景下，不能实现真正的弹性计算，因为计算集群中也有数据，敞开闲置的计算集群会失落数据。针对计算存储耦合带来的一些问题，研发团队也调研了具备计算存储拆散能力的开源音讯队列Apache Pulsar。 在Pulsar的架构中，计算和数据存储是独自的两个组件： 计算层也就是Broker，Pulsar的Broker不间接存储音讯实体数据，次要负责解决Consumer和Producer相干的连贯申请解决等，如果业务上Consumer和Producer特地的多，能够独自扩大这一层。 数据存储也就是Bookie，Pulsar应用了Apache BookKeeper作为存储反对，BookKeeper是一个提供日志条目流存储长久化的服务框架，计算层应用时不用过多的关怀存储细节。 联合音讯队列AMQP的利用场景以及剖析面向的客户群体，咱们抉择Pulsar这种计算存储拆散的音讯队列作为原型进行音讯队列AMQP的定制化开发。在调研Pulsar以及与Puslar社区深刻沟通之后发现Pulsar现有的Protocol Handler机制十分合乎咱们这种定制化开发的需要，Protocol Handler协定解决插件能够利用Pulsar 现有的一些组件（例如 服务发现组件-Topic LookUp、分布式日志库-ManagedLedger、生产进度治理组件-Cursor 等）来帮忙咱们实现一些逻辑解决。 因而Pulsar的Protocol Handler就成为了咱们音讯队列AMQP定制化开发的根底。更多Protocol Handler的介绍可参考Pulsar PIP-41。 (https://github.com/apache/pul...） 音讯队列AMQP整体架构如上图所示，开发的重点就在于AMQP Protocol Handler的通信层协定的解析解决、AMQP 0-9-1协定模型与Pulsar模型之间的映射、多租户的反对以及最外围的发送生产流程的解决。 外围性能点设计音讯的存储音讯队列AMQP的存储设计借鉴了RabbitMQ，最终实现利用Pulsar的PersistentTopic来实现具体的实体数据以及索引数据的存储。 1、RabbitMQ的音讯存储模型 RabbitMQ的音讯长久化理论包含两局部：队列索引(rabbit_queue_index)和音讯存储(rabbit_msg_store)。 rabbit_queue_index负责保护队列中落盘音讯的信息，包含音讯的存储位点、是否曾经提交给消费者、是否已被消费者ACK等，每个队列都有一个与之对应的rabbit_queue_index。 rabbit_msg_store以键值对的模式存储音讯，每个节点有且只有一个，该节点上的所有队列共享该文件。从技术层面讲rabbit_msg_store又能够分为msg_store_persistent和msg_store_transient，其中msg_store_persistent负责长久化音讯的存储，不会失落；而msg_store_transient负责非长久化音讯的存储，重启后音讯会失落。 2、BookKeeper提供存储反对 Pulsar broker中的ManagedLedger实现了对BookKeeper存储层的封装，利用ManagedLedger能够实现音讯的长久化、读取以及生产进度治理。 3、如何利用Pulsar现有的模型实现exchange以及queue的对应 AMQP 0-9-1引入了一些根底概念，例如 Exchagne， Queue 和 Router。这些与 Pulsar 的模型有着较大的区别。因而，咱们须要采纳一种建模映射形式，将现有Pulsar中对于Topic的公布/订阅模型与AMQP通信协议中的业务模型映射到一起。 AmqpExchange AmqpExchange 蕴含一个原始音讯 Topic，用来保留 AMQP Producer 发送的音讯。AmqpExchange 的 Replicator 会将音讯解决到 AMQP 队列中。Replicator 是基于 Pulsar 的长久化游标，能够确保胜利将音讯发送到队列，而不会失落音讯。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 当新生事物呈现时，人们总是有两种角度去察看它，要么把它看小，要么把它放大。 对于 Apache Pulsar 来说，把它看小的角度通常是“Apache Pulsar 只是一个新的音讯队列而已“，或者“Apache Pulsar 只是一个新的数据管道而已”，又或者是“队列零碎早就有了，只是 Apache Pulsar 更具扩展性也能解决某些场景问题而已，根本没啥本质区别”。 那么，事实果真如此吗？ 带着这些问题，InfoQ 记者张浩在 QCon 2021 寰球软件开发大会（https://qcon.infoq.cn/2021/be...）上采访了 StreamNative 联结创始人、Apache Pulsar 和 Apache BookKeeper PMC 成员翟佳，和他聊了聊 Apache Pulsar 的历史、特点以及将来的趋势。 点击链接 ，查看公众号视频采访的全部内容，为不便读者查看，视频下方也附上了文字内容。 InfoQ：翟老师，你好，欢送来到 QCon 大会并承受咱们的采访，请您先自我介绍一下吧。 翟佳：主持人好，我叫翟佳，来自 StreamNative，当初次要是做 Apache Pulsar、Apache BookKeeper 相干的设计和开发，也是这两个开源我的项目的项目管理委员会成员。更早之前，我还在 EMC 做过分布式文件系统的设计和开发。 InfoQ：我在 Pulsar 官网上看到它是这么定义的，它说 Pulsar 是一个云原生的分布式音讯和流平台。在中文媒体的很多宣传里，对于 Pulsar 的定义怎么说的都有，我权且就把它了解为是一个新一代的 Kafka。那么很多公司其实是把 Kafka 当成音讯零碎应用的，所以我想请你来聊一聊，这些年来开源音讯零碎都经验过怎么的迭代？ 翟佳：你刚刚提到的音讯零碎的确是 Pulsar 诞生的一个初衷，因为在 2011 年、2012 年的时候，在雅虎外部须要解决的就是一个音讯零碎对立的问题。过后比拟风行的 ActiveMQ、RabbitMQ 在雅虎外部也都有应用，所以 Pulsar 诞生的一个场景也是做外部的一个对立，要替换 ActiveMQ、RabbitMQ 这样的音讯零碎。也就是你方才提到的 MQ 的场景需要。 ...

对于 Apache Pulsar Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/在进行 Schema 治理前需保障 Pulsar 失常收发的应用没有问题。首先明确一下什么是 Schema ？ 在数据库中 Schema 是数据的组织和构造，如果把 Pulsar 比做关系型数据库，那么 Topic 就存储着关系型数据库磁盘文件中的字节，而 Schema 就起着将关系型数据库磁盘文件里的字节转成有具体的类型数据库表一样的作用，属于数据表的元信息。那在音讯队列中咱们为什么须要 Schema 治理呢？上面咱们带着疑难来看 Pulsar Schema 的应用。 问题背景以后音讯队列整体零碎可用性趋于稳定，然而在应用过程中，上下游数据的安全性还没有失去无效保障，举个栗子： type TestCodeGenMsg struct {- Orderid int64 `json:"orderid"`+ Orderid string `json:"orderid"` Uid int64 `json:"uid"` Flowid string `json:"flowid"`}这种“不兼容”的格局将毁坏大多数上游服务，因为他们冀望数字类型但当初失去一个字符串。咱们不可能提前晓得会造成多少侵害。例子中，人们很容易将责任归咎于“沟通不畅”或“不足适当的流程”。 首先在开发中 API 被视为微服务架构中的一等公民，因为 API 是一种契约，有较强的约束性，任何协定改变都能提前很快感知，然而音讯队列的事件生产往往并不能疾速做出响应和测试，当大规模修模型时，尤其是波及到写数据库时，很可能造成和 API 失败一样的负面后果。这里我举荐 Gwen Shapira 之前写了一篇文章，介绍了数据契约和schema治理，咱们冀望基于简略的兼容策略管理 Schema 的变动，让数据安全地演进，解耦团队并容许他们独立疾速口头开发。这就是咱们为什么须要 Schema 治理。 冀望达到的指标基于兼容策略，治理起 schema，让数据安全地演进，如： type TestCodeGenMsg struct { Orderid int64 `json:"orderid"` Uid int64 `json:"uid"` Flowid string `json:"flowid"`+ Username string `json:"username"`}如下则不通过： ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是集音讯、存储、轻量化函数式计算为一体的下一代云原生分布式音讯流平台，采纳了计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/ 转载与作者信息：本文翻译自 StreamNative 博客，原作者 Matteo Merli、郭斯杰，译者 Jipei@StreamNative。原文地址：https://streamnative.io/en/bl...Apache Pulsar 自诞生并从 Apache 软件基金会毕业以来，已倒退为残缺的我的项目并造成了寰球上万人的社区。往年，值此 Pulsar 北美峰会收官和 Pulsar 2.8.0 版本公布之际，Pulsar 在我的项目和社区上都迎来了新的里程碑。借此机会，咱们独特回顾 Pulsar 的技术及生态倒退。 Apache Pulsar 的诞生Apache Pulsar 在寰球有数百家公司宽泛采纳，包含 Splunk、腾讯、Verizon 和 Yahoo! JAPAN 等。Apache Pulsar 从一开始的只是一款云原生分布式音讯零碎，现已倒退成为一个残缺的音讯和流的平台，可用于公布和订阅、实时存储和解决大规模数据流。 Pulsar 诞生于 2012 年，最后的目标是为在 Yahoo 外部，整合其余音讯零碎，构建对立逻辑、撑持大集群和跨区域的音讯平台。过后的其余音讯零碎（包含 Kafka），都不能满足 Yahoo 的需要，比方大集群多租户、稳固牢靠的 IO 服务质量、百万级 Topic、跨地区复制等，因而 Pulsar 应运而生。 过后，通常有两种类型的零碎来解决动态数据：实时处理要害业务事件的音讯队列，以及大规模解决可扩大数据管道的流零碎。许多公司不得不将他们的性能限度在其中一种，或者不得不采纳多种不同的技术。如果抉择多种技术通常会导致数据隔离和数据孤岛：一个用于音讯队列的孤岛来构建应用服务，另一个用于构建数据服务的流零碎。公司的基础设施通常极其简单，下图阐明该架构。 然而，随着公司须要解决的数据类型增多，经营数据（如日志数据、点击事件等），以及须要拜访组合业务数据和经营数据的上游零碎数量的减少，零碎须要反对音讯队列和流两种场景。 除此之外，公司须要一个基础设施平台，容许他们在其上构建所有应用程序，而后让这些应用程序默认解决动态数据（音讯和流数据）。通过这种形式，能够显著简化实时数据基础设施，如下图。 在这样的愿景下，Yahoo! 团队开始致力于为动态数据构建对立的音讯流平台。以下是 Pulsar 成立至今的要害里程碑。 里程碑 1：数据流的可扩大存储Pulsar 的诞生始于 Apache BookKeeper。Apache BookKeeper 为连续流实现了相似日志的形象，并提供了在互联网规模上应用简略的写-读日志 API 运行它的能力。日志为构建分布式系统提供了很好的形象，如分布式数据库和公布-订阅音讯。写入 API 以附加到日志的模式呈现。读取 API 是从 reader 定义的起始偏移量间断读取。BookKeeper 的实现奠定了根底——可扩大的基于日志的音讯和流零碎。 ...

作者简介冉小龙-腾讯云中间件团队研发工程师，Apache Pulsar committer、RoP 作者及 Maintainer、Apache BookKeeper contributor，Apache Pulsar Go client、Apache Pulsar Go Functions、StreamNative/pulsarctl 作者。 摘要日前，腾讯云中间件团队联结 StreamNative 团队正式公布了 RoP 0.2.0 版本，该版本在架构上全新降级，用户在应用中能够完全避免音讯失落、音讯反复生产、只能生产一部分 Partition 的数据等问题。 RoP 的定义与 KoP、MoP 和 AoP 类似，RoP 是一种可插拔的协定解决插件。 将 RoP 协定解决插件增加到现有 Pulsar 集群后，用户无需批改代码，便能将现有的 RocketMQ 应用程序和服务迁徙到 Pulsar，同时还能应用 Pulsar 的弱小性能，例如： 计算与存储拆散多租户跨地区复制分层分片轻量化计算框架 -- Pulsar Functions......公布 RoP 0.2.02021 年 5 月 17 日，腾讯云中间件团队向社区奉献了 RoP 0.1.0 的 beta 版本，RoP(RocketMQ on Pulsar) 是 将 RocketMQ 协定解决插件引入 Pulsar Broker，这样 Pulsar 即可反对原生的 RocketMQ 协定，RocketMQ 用户能够无缝迁徙到 Apache Pulsar。 明天，咱们重磅公布 RoP 0.2.0，该版本在架构上全新降级，在性能和稳定性上失去了更大的晋升。提供了 ACL 鉴权和验证的性能，能够更好的确保用户数据的安全性，同时容许用户对 Partitioned Topic 进行扩容，能够取得更好的并发写入能力， 并且欠缺了 RocketMQ 原生的管控端接口，能够更好的对服务进行解决和监控。 ...

近日，福布斯中国首度公布了「中国企业科技50强」榜单，Kyligence 凭借本身继续翻新的技术实力、业余的企业服务能力以及行业影响力荣登榜单。由专家学者、企业高管和信息技术负责人等形成的业余评委阵容，通过估值、利润、增长率、人文及市场领导力等多个维度构建评估体系，评比出了中国企业科技中的50家后劲初创企业及非上市公司。 福布斯示意，无论是企业科技，还是产业互联网，基本目标都是聚焦包含传统行业在内的各行各业实现数字化转型，为企业和行业发明价值。企业数字化转型，是时机也是挑战，对于初创企业来说，不仅须要把握行业时机和时代脉搏，更应聚焦如何以科技翻新赋能各行各业，推动传统企业的转型降级，从而真正发明出价值。 自成立以来，Kyligence 专一于提供企业级数据服务与治理产品及解决方案，致力于打造下一代智能数据云平台，服务了金融、批发、制作等行业寰球头部企业客户，为数字化转型提供了无力的撑持，推动了大数据畛域的翻新倒退。此次入选「福布斯中国企业科技50强」是对 Kyligence 在科技领域影响力的再次必定。 此前福布斯官网也曾公布 Kyligence 编写的 How To Manage Your Data Intelligently In The Cloud Era《云原生时代，企业如何智能治理数据》一文，为福布斯寰球读者分享了云原生时代企业数字化转型的独特见解；此外，在福布斯编写的 16 Essential Protocols Every Company Should Consider To Protect Digital Assets《企业爱护数字资产的16条准则》中也收录了来自 Kyligence 的实际与总结：“从第一天开始就要对员工进行网络安全培训，并强调网络安全重要性，这种以网络安全为重的文化对于企业来说是至关重要的。” 将来，Kyligence 将持续以当先技术为驱动，依靠自主研发劣势，一直晋升本人在数据服务和治理畛域的市场领导力，继续助力寰球企业智能治理最有价值数据，实现数字化转型。 对于 福布斯中国 福布斯于1917年在纽约创建，以“创业精神，创富工具”为口号，以其企业家精力和翻新意识成为行业翘楚。福布斯制作的榜单被称为“经济的晴雨表”和“财产的风向标”。自 2003 年起，福布斯来到中国，秉承为中国企业决策精英提倡创业精神的理念，制作了蕴含“福布斯中国富豪榜”在内的一系列榜单、调研、流动及其他平台。福布斯中国致力于为高端客户打造具备进取心的互动社区，提供前瞻、共享的环境，构建守业、翻新的信息生态链。 对于 Kyligence Kyligence 由 Apache Kylin 开创团队创立，致力于打造下一代智能数据云平台，为企业实现自动化的数据服务和治理。基于机器学习和 AI 技术，Kyligence 从多云的数据存储中辨认和治理最有价值数据，并提供高性能、高并发的数据服务以撑持各种数据分析与利用，同时一直升高 TCO。Kyligence 已服务中国、美国及亚太的多个银行、保险、制作、批发等客户，包含建设银行、浦发银行、招商银行、安全银行、宁波银行、太平洋保险、中国银联、上汽、一汽、安踏、YUMC、Costa、UBS、Metlife、AppZen 等寰球知名企业和行业领导者。公司已通过 ISO9001，ISO27001 及 SOC2 Type1 等各项认证及审计，并在寰球范畴内领有泛滥生态合作伙伴。

平时在 Pulsar 交换群中，咱们发现大家在接触和应用 Pulsar 的过程中，会重复遇到相相似的问题。为了更高效地解决大家这些“高频疑难”，同时也对提出优质问题的敌人表示感谢，咱们特地建设了 FAQ 知识库，以便于收集及解答大家的疑难。 咱们将定期收集筛选社群内提出的高频问题，由社区专家甄别筛选出其中优质的发问进行答复，整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考，心愿能够帮忙大家解决应用 Pulsar 过程中的问题。 上面来看看本次大家遇到了哪些问题吧： Ledger 地位查问问题 1：如何查问 Ledger 数据？ 解答：默认状况下，Ledgers 的所有数据都存在在 data/bookkkeeper/ledgers 的目录下。能够通过 bin/bookkeeper shell ledgermetadata -ledgerid <lid>来查看 Ledger 在哪几个 BookKeeper 上。 问题 2：如何查问 Ledger 在哪个磁盘？ 解答：能够加一个 API 命令，通过 ledgerId % numberOfDirectories 计算出某个 Ledger 所在磁盘。 AutoRecovery 限速问题 3：Pulsar 的 AutoRecovery 如何限速？ 解答：目前不能限速，然而 BookKeeper 社区有 PR-2778 进行中，将通过增加 throttleWriteRateByBytes throttleReadRateByEntries来实现 Auto Recovery 的限速性能。 Broker 无奈启动 - ZooKeeper 报错问题 4：Broker 无奈启动，报错 ZooKeeper Session 0x0 closed，Failed to create ZooKeeper Client。 解答：通常状况下 Broker 无奈启动、ZooKeeper 报错，就须要查看 Broker 节点是否能正确连贯上 ZooKeeper。本状况下因为 Bookie 连贯 ZooKeeper 集群呈现 Session 超时，须要查看 ZooKeeper 集群是否失常启动。 ...

作者简介  盛宇帆，StreamNative 开发工程师，Apache Pulsar 与 Apache Flink 贡献者。退出 StreamNative 之前，他曾就任于阿里大数据平台和腾讯云负责 Flink 开发工作。盛宇帆是腾讯云我的项目 Barad 的外围 committer 与我的项目落地负责人。他目前在 StreamNative 负责 Pulsar-Flink 和 Pulsar-Spark 相干的开发工作，他和他的团队曾经将 Pulsar Source Connector 奉献给 Flink 社区，并于 Apache Flink 1.14.0 公布，并将在后续的公布中残缺地将 Pulsar Connector 奉献给社区。 编辑：Jipei@StreamNative，Apache Pulsar 贡献者。 本文摘要批流一体是数据计算的将来趋势，Pulsar Flink Connector 为基于 Apache Pulsar 在 Apache Flink 上以批流一体的形式解决数据提供了现实的解决方案。StreamNative 已将 Pulsar Source Connector 奉献至 Flink 1.14.0 版本。用户能够应用它从 Pulsar 读取数据，并保障每条数据只被解决一次。最新 Pulsar Flink Connector 基于 Pulsar 2.8.0 和 Flink 1.14 版本，反对 Pulsar 的事务处理，进一步交融了两者的个性。背景随着数据日益收缩，采纳事件流解决数据至关重要。Apache Flink 将批流解决对立到计算引擎中，提供了统一化的编程接口。Apache Pulsar（与 Apache BookKeeper 一起）以 "流 "的形式对立数据。在 Pulsar 中，数据存储成一个正本，以流（streaming）（通过 pub-sub 接口）和 segment（用于批处理）的形式进行拜访。Pulsar 解决了企业在应用不同的存储和音讯技术解决方案时遇到的数据孤岛问题。 ...

本文翻译自 StreamNative 博客。博客原作者：Ioannis Polyzos，StreamNative 解决方案工程师。原文链接：https://streamnative.io/blog/...背景构建古代数据基础设施始终是当今企业的难题。当今的企业须要治理全天候生成和交付的大量异构数据。然而，因为企业对数据的数量和速度等等有多种要求，没有“一刀切”的解决方案。相同，企业需在不同零碎之间挪动数据，以便存储、解决和提供数据。 粗看搭建基础设施的历史，企业应用了许多不同的工具来尝试挪动数据，例如用于流式工作负载的 Apache Kafka 和用于音讯工作负载的 RabbitMQ。当初，Apache Pulsar 的诞生为企业简化了这个过程。 Apache Pulsar 是一个云原生的分布式音讯流平台。Pulsar 旨在满足古代数据需要，反对灵便的消息传递语义、分层存储、多租户和异地复制（跨区域数据复制）。自 2018 年毕业成为 Apache 软件基金会顶级我的项目以来，Pulsar 我的项目经验了疾速的社区增长、周边生态的倒退和寰球用户的增长。将 Pulsar 用作数据基础设施的支柱，公司可能以疾速且可扩大的形式挪动数据。在这篇博文中，咱们将介绍如何应用 Pulsar IO 在 Pulsar 和内部零碎之间轻松导入和导出数据。 1. Pulsar IO 简介Pulsar IO 是一个残缺的工具包，用于创立、部署和治理与内部零碎（如键/值存储、分布式文件系统、搜寻索引、数据库、数据仓库、其余消息传递零碎等）集成的 Pulsar 连接器。因为 Pulsar IO 构建在 Pulsar 的无服务器计算层（称为 Pulsar Function）之上，因而编写 Pulsar IO 连接器就像编写 Pulsar Function 一样简略。 借助 Pulsar IO，用户能够应用现有的 Pulsar 连接器或编写本人的自定义连接器，轻松地将数据移入和移出 Pulsar。Pulsar IO 领有以下劣势： 多样的连接器：以后 Pulsar 生态中有许多现有的 Pulsar IO 连接器用于内部零碎，例如 Apache Kafka、Cassandra 和 Aerospike。应用这些连接器有助于缩短生产工夫，因为创立集成所需的所有部件都已就位。开发人员只须要提供配置（如连贯 url 和凭据）来运行连接器。托管运行时：Pulsar IO 带有托管运行时，负责执行、调度、扩大和容错。开发人员能够专一于配置和业务逻辑。多接口：通过 Pulsar IO 提供的接口，用户能够缩小用于生成和应用应用程序的样板代码。高扩展性：在须要更多实例来解决传入流量的场景下，用户能够通过更改一个简略的配置值轻松横向扩大；如果用户应用 Kubernetes 运行时，可依据流量需要进行弹性扩大。充分利用 schema：Pulsar IO 通过在数据模型上指定 schema 类型来帮忙用户充分运用 schema，Pulsar IO 反对 JSON、Avro 和 Protobufs 等 schema 类型。2. Pulsar IO 运行时因为 Pulsar IO 建设在 Pulsar Function 之上，因而 Pulsar IO 和 Pulsar Function 具备雷同的运行时选项。部署 Pulsar IO 连接器时，用户有以下抉择： ...

各位社区成员小伙伴们： 大家好！鉴于以后疫情情况，为了最大化保障参会社区成员身体健康、升高危险，原定于 2021 年 11 月 20-21 日举办的 Pulsar Summit Asia 2021 将延期至 2022 年 1 月 15-16 日举办。咱们依然会以线上+线下的混合模式组织本次流动，具体地点仍在确认之中。因而带来的不便，敬请体谅。 也请大家随时关注 Apache Pulsar 社区公众号，获取流动最新动静。

舒适提醒：本文是「Pulsar 傻瓜手册」，手把手为零教训小白排坑避雷。只有依照指引操作，成功率 100% 喔！ 本文是「Pulsar 隔离策略系列」的第 2 篇，该系列的第 1 篇博客 — 「深度解析如何在 Pulsar 中实现隔离」— 重点介绍了 Pulsar 隔离策略以及如何通过以下 3 种形式实现资源隔离： 多个 Pulsar 集群共享 BookKeeper 集群单个 Pulsar 集群本文将具体解说第 1 种形式，即如何在「多个 Pulsar 集群」的环境中，玩转 Pulsar 隔离策略，并为以下操作提供具体步骤： 验证数据隔离。同步并迁徙集群数据。扩缩容节点。筹备环境本文以在 macOS（版本 11.2.3， 内存 8G）上操作为示例。 如下图所示，本文部署 2 个 Pulsar 集群，每个集群提供以下服务： 1 个 ZooKeeper 节点1 个 bookie 节点1 个 broker 节点 软件要求Java 8 环境详情下文行将部署 2 个 Pulsar 集群，组件详情如下表所示。 部署筹备下载 Pulsar 并解压。本文以装置 Pulsar 2.7.0 为例。在本地任意地位，依照以下目录构造，创立相应的空文件夹。|-separate-clusters |-configuration-store |-zk1 |-cluster1 |-zk1 |-bk1 |-broker1 |-cluster2 |-zk1 |-bk1 |-broker1复制解压后 Pulsar 文件夹中的内容至上一步创立的每个文件夹中。启动 configuration store。Configuration store 为 Pulsar 实例提供跨集群配置管理和工作协调。Pulsar 集群 1 和 Pulsar 集群 2 共享 configuration store。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 导语：本文是 StreamNative 开发工程师、Apache Pulsar Committer 丛搏在 Pulsar Summit Asia 2020 大会上的演讲《技术探索：Apache Pulsar 的事务型事件流》文字整顿版本，本演讲次要对 Apache Pulsar 事务原理及布局进行了分享，请大家参考。我叫丛搏，是来自 StreamNative 的开发工程师。明天我所带来的主题是《技术探索：Apache Pulsar 的事务型事件流》。 音讯语义大家都晓得在所有的音讯零碎流数据平台对于音讯都有不同的语义。个别语义分为三种：At-most once、At-least once、Exactly once。 At-most once：至少一次，不关怀音讯是否发送胜利、不须要音讯发送的返回值。At-least once：至多一次，容许音讯反复但必须保障音讯必达。Exactly once：精准一次，保障音讯不丢且不会反复。At Most Once（最多一次）Pulsar 在 1.2.0 版本之前，曾经实现 At Most Once 语义。 At Least Once（至多一次）Pulsar 在设计之初就遵循 At Least Once 语义。发送音讯失败后重试是保障 At Least Once 语义的根本形式。发送重试会导致音讯反复，在某些应用场景下要求 Producer 不能发送反复音讯且 Consumer 不能反复生产，因而产生了 Exactly Once 语义。 Exactly Once（准确一次）实现 Exactly once 须要实现对生产/生产的去重。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。  GitHub 地址：http://github.com/apache/pulsar/ 原文转载于 StreamNative，原作者李鹏辉，地址：https://streamnative.io/en/bl...。本文译者是资飞。 本系列上一篇文章《基于 Pulsar 事务实现的 Exactly-Once（准确一次）语义》介绍了在 Apache Pulsar 中，能够通过启用 Transaction API 保障准确一次语义。本文将具体介绍多种消息传递语义，包含： 通过幂等 producer 反对单个 topic 准确一次语义事务 APIPulsar 与 Flink 集成时端对端仅且只解决一次语义本文将深刻解析 Apache Pulsar 中的事务，帮忙读者相熟 Pulsar 事务 API 的次要概念，以便后续应用。 为什么须要事务？事务加强了消息传递语义和流处理过程中解决保障（例如：应用 Pulsar Functions 或与其余流解决引擎集成）。流解决通常体现为“生产-解决-生产”，在一个数据流中生产和生产（例如：Pulsar Topic）。 随着流解决的衰亡，对具备更强解决保障的流解决利用的需要也在一直增长。例如，金融机构应用流解决引擎来解决用户的借贷业务。这种场景要求每条音讯都只解决一次且无异样。 换句话说，如果流解决利用生产 A 音讯 并将生成的后果当作音讯 B(B = f(A)) ，那么准确一次解决保障意味着，只有在胜利生成音讯 B 时，A 才会被标记为已生产，反之亦然。  在 Pulsar 2.8.0 之前，应用 Apache Pulsar 构建流解决利用时，实现准确一次解决保障的操作都不简略。将 Pulsar 与流解决引擎（如 Flink）集成可能能够实现准确一次保障。例如，你能够应用 Flink 准确一次读取从 Pulsar topic 中的音讯，但不能准确一次将后果写入到 Pulsar topic。 ...

译者简介原文由李鹏辉公布于 StreamNative 英文站点：https://streamnative.io/en/bl... 译者：王嘉凌@中国移动云能力核心，挪动云 Pulsar 产品负责人，Apache Pulsar Contributor，沉闷于 Apache Pulsar 等开源我的项目和社区Apache Pulsar 社区在刚刚公布的 Pulsar 2.8.0 版本中实现了一个里程碑式性能：Exactly-once（准确一次）语义。在这之前，咱们只能通过在 Broker 端开启音讯去重来保障单个 Topic 上的 Exactly-once 语义。随着 Pulsar 2.8.0 的公布，利用事务 API 能够在跨 Topic 的场景下保障音讯生产和确认的原子性操作。接下来，我会解释一下这两种形式的含意和实现办法，以及在实时数据音讯和流计算零碎中如何应用 Pulsar 事务个性来实现 Exactly-once 语义。 在深刻了解 Pulsar 事务个性之前，咱们先来回顾一下音讯语义的概念。 什么是 Exactly-once (准确一次)语义?在分布式系统中，任何节点都有可能出现异常甚至宕机。在 Apache Pulsar 中也一样，当 Producer 在生产音讯时，可能会产生 Broker 或 Bookie 宕机不可用，或者网络忽然中断的异常情况。依据在产生异样时 Producer 解决音讯的形式，零碎能够具备以下三种音讯语义。 At-least-once (至多一次)语义Producer 通过接管 Broker 的 ACK （音讯确认）告诉来确保音讯胜利写入 Pulsar Topic。然而，当 Producer 接管 ACK 告诉超时，或者收到 Broker 出错信息时，会尝试从新发送音讯。如果 Broker 正好在胜利把音讯写入到 Topic，但还没有给 Producer 发送 ACK 时宕机，Producer 从新发送的音讯会被再次写入到 Topic，最终导致音讯被反复散发至 Consumer。 ...

原文作者 Jack Vanlightly，翻译 Sijia@StreamNative，如需转载，请后盾留言。英文链接：https://jack-vanlightly.com/b...对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/浏览本文须要大概 15 分钟。 音讯零碎Apache Pulsar 的工作原理介绍了 Pulsar 的协定和存储模型，次要强调了（1）Pulsar 计算与存储拆散；（2）Pulsar 将 topic 分成 ledger 与分片，无需重均衡，即可向 bookie 主动写入新数据的个性。本文将会应用 Blockade 工具敞开节点、升高网速，并失落网络数据包进行测试。在音讯如何在 RabbitMQ 集群中失落和音讯如何在 Kafka 集群中失落文中，我应用了雷同的自动化测试工具，本文的测试不仅蕴含数据失落，还包含音讯排序和音讯反复。 我曾经将测试应用的代码上传到 GitHub，你能够在 ChaosTesingCode 仓库中的 Pulsar 文件夹里查看。 在每个测试场景中，咱们都创立了新的 blockade 集群，并且进行了雷同的配置： Apache Pulsar broker 数量Apache BookKeeper 节点（Bookie）数量Ensemble size (E)Write quorum size (Qw)Ack quorum size (Qa)客户端通过 proxy 与 broker 进行通信。 在每个测试中，咱们都发送音讯并增加烦扰操作，比方敞开 topic 所属的 Pulsar broker，敞开以后 ledger ensemble 中的 1 个 bookie，从 ZooKeeper 中隔离节点等。 ...

本文作者为 StreamNative 工程师李鹏辉、刘昱。对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/Apache Pulsar 的一大长处是 Pulsar 的多层分片架构和分层资源管理为隔离（isolation）提供了坚实基础，用户能够以所需形式隔离资源，防止资源竞争，保证系统稳定性。 本系列博客将深刻探讨 Pulsar isolation。本文为本系列文章的第一篇，次要介绍如何在 Pulsar 中通过以下形式实现隔离： 独自 Pulsar 集群共享 BookKeeper 集群繁多 Pulsar 集群独自 Pulsar 集群在这种环境中，你须要为隔离单元创立各自的 Pulsar 集群。 工作原理图 1 展现了如何通过部署独自的 Pulsar 集群实现隔离。 工作原理要点： 每个 Pulsar 集群 通过 DNS entry point 接入服务，并确保客户端能够通过 DNS entry point 拜访集群。客户端能够应用一个或多个 Pulsar URL，该 URL 是 Pulsar 集群的连贯地址。每个 Pulsar 集群有一个或多个 broker和 bookie。每个 Pulsar 集群有一个元数据存储区。元数据存储区能够分为 Pulsar 元数据存储区 和 BookKeeper 元数据存储区。本文不辨别上述两种元数据存储区，元数据存储区同时蕴含二者。多个 Pulsar 集群共享一个配置存储。Pulsar 分层的资源管理为隔离提供了坚实基础。如需隔离命名空间，则须要为命名空间指定集群。集群必须属于租户容许的集群列表。属于该命名空间的 topic 也会调配至该集群。对于如何为命名空间设置集群，参阅 为命名空间设置集群。对于如何治理 Pulsar 集群，参阅治理 Pulsar 集群。迁徙命名空间如需在不同集群之间迁徙命名空间，你须要启用跨地区复制性能，并在数据全副复制到指标集群后敞开跨地区复制性能。对于如何为命名空间设置跨地区复制，参阅为命名空间设置跨地区复制。 ...

编者荐语： 原文作者冉小龙，首发于公众号“腾讯云中间件”，公布已取得原帐号受权。如需转载，请返回联系。本文次要为大家介绍 Apache Pulsar 在不同场景下的跨地区复制解决方案。 以下文章来源于腾讯云中间件 ，作者冉小龙对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/Apache Pulsar 是一个多租户、高性能的服务间音讯传输解决方案，反对多租户、低延时、读写拆散、跨地区复制、疾速扩容、灵便容错等个性。其原生反对了跨洲际级别的跨地区复制的解决方案，并联合其本身的 tenant 和 namespace 级别的形象，能够灵便的反对不多品种，不同场景下的跨地区复制解决方案。 需要意义在 Geo-Replication 的设计撑持下，其一，咱们能够比拟容易的将服务扩散到多个机房；其二，能够应答机房级别的故障，即在一个机房不可用的状况下，服务能够转接到其它的机房来持续对外提供服务。 摘要Apache Pulsar 内置了多集群跨地区复制的性能，GEO-Repliaaction 是指把扩散在不同物理地区的集群通过肯定的配置形式让其能在集群之间进行数据的互相复制。 依据音讯是否为异步读写的维度，跨地区复制能够分为如下两种计划： 同步模式：如果对数据的容灾级别要求十分高，能够采纳同步跨城部署模式，数据正本会存在不同城市之间，有余是跨城之间网络的稳定会对性能有较大的影响，因为须要期待多个城市都写胜利才会返回客户端胜利。异步模式：如果对数据的容灾级别不是那么高，能够采纳异步跨城部署模式，例如有两个独立的数据中心上海和多伦多，写入上海的音讯会异步再写一份到多伦多，长处不影响主流程性能，有余多一份存储开销。上面咱们探讨的是异步模式下，Pulsar 的跨地区复制计划。 Pulsar 目前反对以下三种异步跨地区复制的计划： 全连通单向复制Failover 模式从是否具备 configurationStoreServers （global zookeeper）的角度能够分为以下两种异步跨地区复制计划： 有 configurationStoreServers全连通没有 configurationStoreServers单向复制Failover 模式在整个跨地区复制中的一个核心理念在于，各个集群之间的数据是否可能互通，它们之间的交互次要依附如下配置信息： cluster （cluster name）zookeeper （local cluster zk servers）configuration-store （global zk servers）web-service-urlweb-service-url-tlsbroker-service-urlbroker-service-url-tls在初始化 Pulsar cluster 时，用户能够指定上述对应的信息，示例如下： bin/pulsar initialize-cluster-metadata \ --cluster pulsar-cluster-1 \ --zookeeper zk1.us-west.example.com:2181 \ --configuration-store zk1.us-west.example.com:2181 \ --web-service-url http://pulsar.us-west.example.com:8080 \ --web-service-url-tls https://pulsar.us-west.example.com:8443 \ --broker-service-url pulsar://pulsar.us-west.example.com:6650 \ --broker-service-url-tls pulsar+ssl://pulsar.us-west.example.com:6651Full-mesh(全连通)Full-mesh 的模式容许数据在多个集群中共享，如下图： ...

编者荐语： 腾讯数据平台部 MQ 团队对 Pulsar 做了深刻调研以及大量的性能和稳定性方面优化，目前曾经在腾讯云音讯队列 TDMQ 落地上线。本文次要简略梳理了 Pulsar 反对的一些传统音讯队列利用场景，以及 Pulsar 新个性对更多场景的反对。 以下文章来源于腾讯云中间件 ，作者张超本文转自腾讯云中间件，作者张超，腾讯数据平台部 MQ 团队高级工程师，Apache TubeMQ(incubating) PMC，Kafka-on-Pulsar Maintainer，Apache Pulsar Contributor。排版：Tango@StreamNative。对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 音讯队列概述什么是音讯队列音讯队列（Message Queue，简称MQ），是指在音讯的传输中保留音讯的容器或服务，是一种异步的服务间通信形式，实用于无服务器和微服务架构，是分布式系统实现高性能、高可用、可伸缩等高级特效的重要组件。 常见的支流音讯队列有 ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ、Pulsar 等。而在公司内有 TubeMQ、Ckafka、TDMQ、CMQ、CDMQ、Hippo 等。 音讯队列特点分布式音讯队列都是分布式的，因而才能够提供异步、解耦等性能。 可靠性基于音讯的通信是牢靠的，音讯不会失落。大多数音讯队列都提供将音讯长久化到磁盘的性能。 异步通过音讯队列，可将近程同步调用拆解成为异步调用。对于不须要获取近程调用后果的利用场景来说，性能晋升显著。 松耦合音讯间接由中间件存储和散发。音讯生产者只需关注如何将音讯发送给音讯中介服务器；消费者只需关注如何从中介服务器订阅。生产者和消费者之间是齐全解耦的，不须要晓得彼此的存在。 事件驱动能够将简单的利用零碎重构成为事件驱动的零碎。事件溯源（Event Sourcing），示意一个对象从创立到沦亡，会通过的多种状态。如果把对象的状态变动都存储下来，岂但能够依据状态变动记录获取对象的以后状态，也能够回溯对象的变动过程。音讯队列能很好地反对这样的零碎设计形式，将触发对象状态变动的事件放入音讯队列。 音讯队列分类在 JMS（JAVA Message Service）规范中，有P2P（Point to Point）和 Publish/Subscribe(Pub/Sub) 两种音讯模型。 P2PP2P的特点是每个音讯只有一个消费者。音讯生产者将音讯发送到音讯队列（Queue）中，只有一个消费者可能生产此音讯，生产实现之后音讯即删除。任意一个消费者都能够生产这个音讯，但音讯相对不会被两个消费者反复生产。 Pub/SubPub/Sub 的特点是公布到 Topic 的音讯会被所有订阅者生产。音讯生产者将音讯发送到音讯主题（Topic）中，所有订阅这个主题的消费者都能够生产此音讯，当所有订阅者都生产实现之后能力删除音讯。 音讯的生产者和消费者之间有工夫依赖，只有当时订阅这个主题的消费者才可生产。如果先发送音讯，后订阅主题，那么订阅之前的音讯将不能被这个订阅者生产。 传统企业型音讯队列 ActiveMQ 遵循了 JMS 标准，实现了点对点和公布订阅模型，但其余风行的音讯队列 RabbitMQ、Kafka 并没有遵循 JMS 标准。 而在实时流式架构中，音讯队列的消息传递能够分为队列（Queue） 和流（Stream） 两类。 队列（Queue）模型队列模型次要是采纳无序或者共享的形式来生产音讯。通过队列模型，用户能够创立多个消费者从单个管道中接管音讯；当一条音讯从队列发送进去后，多个消费者中的只有一个（任何一个都有可能）接管和生产这条音讯。音讯零碎的具体实现决定了最终哪个消费者理论接管到音讯。 队列模型通常与无状态应用程序一起联合应用。无状态应用程序不关怀排序，但它们的确须要可能确认（ACK）或删除单条音讯，以及尽可能地扩大生产并行性的能力。典型的基于队列模型的音讯零碎包含 RabbitMQ 和 RocketMQ。 ...

导语 Pulsar Functions 是 Apache Pulsar 推出的轻量级、函数式计算架构，借助 Pulsar Functions 无需部署独自零碎，即可基于单条音讯创立简单的解决逻辑，简化事件流并引入 Serverless，加重运维累赘。本文由StreamNative 联结创始人、腾讯云TVP 翟佳在 Techo TVP 开发者峰会 ServerlessDays China 2021上的演讲《Function Mesh：Serverless 在音讯与流数据场景的翻新实际》整顿而成，向大家分享。 点击链接，可观看精彩演讲视频：Techo TVP 开发者峰会 ServerlessDays China 2021 「无服务器，大有将来 Serverless，Empower More」翟佳 一、Apache Pulsar 是什么？Function Mesh是StreamNative最新开源的一个我的项目。Serverless 和K8s联合得十分严密，Function Mesh 也是同样的初衷。之前咱们做的Pulsar Functions 是将 Pulsar 跟 Serverless 做更好的整合。Function Mesh 则不便大家利用云上的资源，更好地治理Functions。 明天的分享次要从四个方向开展。Pulsar的简介、Pulsar Functions和Function Mesh，Pulsar社区。 Pulsar社区为什么诞生，想做什么样的事件？Pulsar最开始是一个音讯零碎，在雅虎外部诞生，过后是为了解决什么样的问题？在音讯这个场景里，可能做基础设施的小伙伴都会明确，因为架构技术的起因，依据不同的场景，需要人造分成两个方向。一个是削峰填谷，外部的互相交互的MQ；另外一个场景，须要做大数据数据引擎，做数据传输的管道。这两个场景的应用场景、数据一致性、技术架构齐全不同。2012年，雅虎过后次要面临的问题是各个部门之间也会保护多套零碎，在外部就有三四套，相当于整个外部曾经发现运维的瓶颈特地厉害，各个部门之间，数据的孤岛变得特地厉害。所以，雅虎过后做Pulsar的最次要的初衷是：对于用户来说，心愿做一个对立的数据平台，提供对立的运维和治理，加重运维压力，进步资源利用率；对于业务部门来说，2012年也是流计算刚刚衰亡的时候，大家心愿让更多的数据可能买通，让实时计算抓取更多的数据源，失去更准确的计算结果，更好地施展数据的价值。从这两方面登程，Pulsar的诞生次要提供两个场景的对立，利用同一个平台，解决之前两套在音讯相干场景外面的利用。 有了这样一个需要，看Pulsar为什么可能做到这样一件事件？与以下两个方面无关： 第一，云原生架构。背地有几个点，首先是服务层-计算层和存储层是齐全隔离的状态。在服务层，不会保留任何数据，所有的数据都交给底层的存储层。同时，在对用户裸露的还是逻辑上的分区的概念。这个分区不像其余的零碎间接绑定文件系统——绑定单节点文件夹，而是把分区又依照用户指定的大小或者工夫划分成了一系列的分片，通过分片模式保障一个分区的数据能够在多个存储节点上做平衡的搁置。通过这种策略，它对于每个分区都实现了分布式的存储、更加分布式的逻辑。扩容、缩容的时候也不会带来任何的数据搬迁，这是云原生架构的劣势。 在架构上第二点是，节点对等的架构。这和雅虎做大集群、多租户的需要密不可分。只有节点之间状态足够简略，状态保护足够简略，能力保护比拟大的集群。在推特外部，底层的存储层有两个机房，每个机房有1500个节点。对这种节点对等来说，下层Broker很好了解，不存储任何数据，所以是leaderless的概念，没有主从之分。在多个备份落到底层存储节点的时候，每个存储节点之间也是对等的状态，要写一个数据，会并发地写多个节点，单节点外部通过CRC放弃一致性，然而对多节点的多份数据是并发写入的，所以多个存储节点也是对等的架构。通过这样一套机制，通过自身的cap设计，放弃一致性，就有了下面提到存储计算拆散的架构，又有节点对等的根底，所以会给扩大、运维、容错带来更好的体验。 Pulsar另一个特点是有专门为音讯流做的存储引擎Apache BookKeeper，BookKeeper是一个更老的零碎，是2008、2009年诞生的产品，也是雅虎开源的零碎，BookKeeper的诞生次要是为了解决HDFS这一层的HA，它的诞生就是为了保留namenode每一次更改，诞生之初就是为了保留元数据的元数据。所以，对一致性、低提早、吞吐，可靠性都有特地高的要求。然而，它的模型很简略，就是一个write-ahead-log的形象。这跟咱们的音讯很匹配，因为音讯次要的模式也是append only 追尾写，随着工夫流逝，之前老的数据价值可能会越来越低，再整体删除。 有了这样一个BookKeeper能够提供比较稳定的服务质量，一致性又特地高的反对，Pulsar就有能力撑持刚刚提到的MQ的场景；同时因为log这种简略形象，基于数据追加写的模式进步数据的带宽，反对了流的模式。MQ、Kafka 两种场景，都通过底层的存储层提供很好的反对，通过底层的存储层失去保障。 有了后面的根底，要构建Pulsar底层对于用户特地实用的企业级feature也会特地容易。Pulsar诞生的起因，是须要有一个大集群，多租户。在这一层对于用户来说，每一个topic不再是单级的概念，而是相似于文件系统外面文件夹，是一级目录，二级目录层级的治理。第一级目录就是咱们的租户，次要给用户提供更多的隔离策略，能够给每个租户分不同的权限，每个租户的管理员治理跟其余的租户、外部各个用户之间权限的治理，比方让不让第一个租户拜访第二个租户的信息？相似这种鉴权的信息。 再往下，namespace这层存的是各种策略，能够不便做很多企业级的管制，比方流控；最底层就是咱们说的topic。通过层级的概念、大集群的反对，能够更不便地买通用户外部各个组织、各个部门之间的数据。 另外，Pulsar因为有很好的数据一致性，也有很多用户把它用在跨集群复制的场景里。Pulsar的跨区域复制，是broker自带的内嵌的性能，用户如果须要这个性能，简略地调Pulsar的命令，就能够实现跨级群的搭建。外部内嵌的producer能够把本地刚刚落盘的数据间接同步到远端机房，时效性特地高。用户的体验是配置起来特地简略，用起来效率特地高，提早特地低，同时又可能提供很好的数据一致性的保障。所以，在很多的场景里有很丰盛的利用，包含腾讯外部、苏宁外部，很多用户都是因为繁多的场景而抉择了Pulsar。 因为有了这些根底，Pulsar在社区里的增长也是特地显著的。当初社区里有403 contributors，github star数靠近9000。非常感激腾讯云有很多小伙伴对Pulsar做了很多很有用，很丰盛的场景测验。 ...

本文会首先介绍Pulsar的分级存储。而后通过一个示例，演示在分级存储中怎么应用Amazon S3作为二级存储。 介绍Pulsar中的每个Topic由一列有序的的段（Segment）列表组成。Pulsar只会写入其中的最初一段。 除最初一段之外，之前的所有段都曾经被密封了，不能再往其中追加数据，这就是Pulsar的基于段（Segment）的存储构造。 Pulsar的基于Segment的存储架构，反对一个Topic的空间大小存储满整个存储集群。然而随着要保留的Partition的数据的逐步增多，会让存储变的低廉。解决这个问题的一种策略就是应用分级存储（Tiered Storage）。 应用分级存储的一个场景是用户心愿对一个比拟大的Topic的数据保留比拟长的工夫。比方一个Topic中蕴含所有客户的点击记录，咱们能够用这个topic中的数据来训练举荐零碎。如果这个Topic的数据被始终保留着，当训练的算法扭转后，咱们就能够从新利用这些历史数据来训练新的举荐零碎。 Pulsar的分级存储性能容许将较旧的积压数据卸载到二级存储中做长期存储，从而开释BookKeeper中的空间，进而升高存储老本。应用分级存储，咱们能够将一个Topic中的老的数据段（Segment）主动从BookKeeper搬出到更便宜的二级存储。对Client来说，整个过程是通明无缝的。 当Offload被手动或者主动触发之后，Broker会一个接一个地将一级存储中的段，搬移到二级存储中。 Pulsar目前反对应用S3，Google-Cloud-Storage作为二级存储。用户能够灵便配置Topic想要保留在BookKeeper（一级存储）中的大小，和数据在搬移到二级存储后多久（默认4小时）从BookKeeper中删除。 咱们在这篇文章中会应用S3作为一个例子，来演示怎么应用Pulsar的这个个性。 Operations With S3在这个示例中应用的是Pulsar-2.1.1版本，次要蕴含3个步骤： 在Amazon S3(https://s3.console.aws.amazon...)中创立一个bucket；下载Pulsar包，为Pulsar的Broker配置Offload，用Standalone模式启动Pulsar；用Pulsar的producer并产生数据，触发Offload，并验证。一, 在S3中创立Bucket登陆AWS console，抉择S3服务： 创立一个bucket，点击“Create bucket”， 填上Bucket的名字，而后点击next并始终点击确认。 通过下面的操作，能够看到一个新的Bucket曾经被创立了。 确认在本机上配置好了aws的access 二, 下载Pulsar包，并配置从Pulsar的官网（http://pulsar.apache.org/en/d...）下载最新的Pulsar Binary文件(apache-pulsar-x.x.x-bin.tar.gz) ，解压，筹备批改配置文件conf/standalone.conf。 批改配置文件conf/standalone.conf中对于Offload的选项，设置第一步中创立的bucket： managedLedgerOffloadDriver=S3 s3ManagedLedgerOffloadBucket=offload-test-aws s3ManagedLedgerOffloadRegion=us-east-1 批改配置文件conf/standalone.conf中每个segment的大小配置，这使得每个Segment更小，更容易产生新的segment。 在终端用standalone模式启动Pulsar:运行命令 bin/pulsar standalone 三, 在Pulsar中产生数据，触发Offload，并验证在终端中启动一个消费者，保障将要产生数据不会因为没有消费者被抛弃掉：bin/pulsar-client consume -s “my-sub-name“ my-topic-for-offload 开一个新的终端窗口，运行上面命令2次，产生2000条message，保障在topic中有两个Segment，这样第一个segment能够被搬移到S3上。bin/pulsar-client produce my-topic-for-offload --messages "hello pulsar this is the content for each message" -n 1000 用命令行手动触发Offload：bin/pulsar-admin topics offload --size-threshold 10K public/default/my-topic-for-offload 应用命令期待offload胜利：bin/pulsar-admin topics offload-status public/default/my-topic-for-offload ...

本文作者：刘德志腾讯专家工程师、TEG 技术工程事业群和计费零碎开发者背景Apache Pulsar 是下一代分布式音讯流平台，采纳计算存储分层架构，具备多租户、高统一、高性能、百万 topic、数据平滑迁徙等诸多劣势。越来越多的企业正在应用 Pulsar 或者尝试将 Pulsar 利用到生产环境中。 腾讯把 Pulsar 作为计费零碎的音讯总线来撑持千亿级在线交易。腾讯计费体量宏大，要解决的外围问题就是必须确保钱货统一。首先，保障每一笔领取交易不呈现错账，做到高统一、高牢靠。其次，保障计费承载的所有业务 7*24 可用，做到高可用、高性能。计费音讯总线必须具备这些能力。 Pulsar 架构解析在一致性方面，Pulsar 采纳 Quorum 算法，通过 write quorum 和 ack quorum 来保障分布式音讯队列的正本数和强统一写入的应答数(A>W/2)。在性能方面，Pulsar 采纳 Pipeline 形式生产音讯，通过程序写和条带化写入升高磁盘 IO 压力，多种缓存缩小网络申请放慢生产效率。 Pulsar 性能高次要体现在网络模型、通信协议、队列模型、磁盘 IO 和条带化写入。上面我会一一具体解说。 网络模型Pulsar Broker 是一个典型的 Reactor 模型，次要蕴含一个网络线程池，负责解决网络申请，进行网络的收发以及编解码，接着把申请通过申请队列推送给外围线程池进行解决。首先，Pulsar 采纳多线程形式，充分利用古代零碎的多核优势，把同一工作申请调配给同一个线程解决，尽量避免线程之间切换带来的开销。其次，Pulsar 采纳队列形式实现了网络解决模块及外围解决模块的异步解耦，实现了网络解决和文件 I/O 并行处理，极大地提高了整个零碎的效率。 通信协议 信息（message）采纳二进制编码，格局简略；客户端生成二进制数据间接发送给 Pulsar 后端 broker，broker 端不解码间接发送给 bookie 存储，存储格局也是二进制，所以音讯生产生产过程没有任何编解码操作。音讯的压缩以及批量发送都是在客户端实现，这能进一步晋升 broker 解决音讯的能力。 队列模型Pulsar 对主题（topic）进行分区（partition），并尽量将不同的分区调配到不同的 Broker，实现程度扩大。Pulsar 反对在线调整分区数量，实践上反对有限吞吐量。尽管  ZooKeeper 的容量和性能会影响 broker 个数和分区数量，但该限度下限十分大，能够认为没有下限。 磁盘 IO音讯队列属于磁盘 IO 密集型零碎，所以优化磁盘 IO 至关重要。Pulsar 中的磁盘相干操作次要分为操作日志和数据日志两类。操作日志用于数据恢复，采纳齐全程序写的模式，写入胜利即可认为生产胜利，因而 Pulsar 能够反对百万主题，不会因为随机写而导致性能急剧下降。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。以后已有泛滥国内外大型互联网和传统行业公司采纳 Apache Pulsar，案例散布在人工智能、金融、电信运营商、直播与短视频、物联网、批发与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。 Confluent 最近发展了一次基准测试，比照 Kafka、Pulsar 和 RabbitMQ 的吞吐量和提早差别。Confluent 博客显示，Kakfa 可能以“低提早”实现“最佳吞吐量”，而 RabbitMQ 可能以“较低的吞吐量” 达到 “低提早”。总体而言，基准测试结果显示 Kafka 在“速度”方面无疑更胜一筹。 Kafka 技术成熟欠缺，但当今泛滥公司（从跨国公司到创新型初创公司）还是首先抉择了 Pulsar。在近期举办的 Splunk 峰会 conf20 上，Splunk 公司首席产品官 Sendur Sellakumar 对外发表，他们决定用 Pulsar 取代 Kafka： “... 咱们已把 Apache Pulsar 作为根底流。咱们把公司的前途压在了企业级多租户流的长期架构上。” --Splunk 首席产品官 Sendur Sellakumar 很多公司都在应用 Pulsar，Splunk 只是其中一例。这些公司之所以抉择 Pulsar，是因为在古代弹性云环境（如 Kubernetes）中，Pulsar 可能以经济无效的形式横向扩大解决海量数据，不存在单点生效的问题。同时，Pulsar 具备诸多内置个性，诸如数据主动重均衡、多租户、跨地区复制和长久化分层存储等，不仅简化了运维，同时还让团队更容易专一于业务指标。 开发者们最终抉择 Pulsar 是因为 Pulsar 这些独特的性能和性能，让 Pulsar 成了流数据的基石。 理解了这些状况后，还需认真钻研 Confluent 的基准测试设置和论断。咱们发现有两个问题存在高度争议。其一，Confluent 对 Pulsar 的理解无限，这正是造成论断不精确的最大本源。如不理解 Pulsar，就不能用正确的衡量标准来测试 Pulsar 性能。 ...

原创：Sijie Guo 翻译：翟佳 在上一篇文章中，咱们深入探讨了Apache Pulsar的音讯模型，该零碎对立了高性能的流 和 灵便的队列。比照展现了Apache Pulsar和Apache Kafka实现消息传递模型中音讯生产，确认和保留的工作形式。 在这篇文章中，咱们将介绍Apache Pulsar背地的一些零碎架构和设计理念，并最初与Apache Kafka的架构进行一些比拟。 Pulsar的分层架构Apache Pulsar和其余音讯零碎最基本的不同是采纳分层架构。 Apache Pulsar集群由两层组成：无状态服务层，由一组接管和传递音讯的Broker组成；以及一个有状态长久层，由一组名为bookies的Apache BookKeeper存储节点组成，可长久化地存储音讯。 下图显示了Apache Pulsar的典型部署。 在Pulsar客户端中提供生产者和消费者（Producer & Consumer）接口，应用程序应用Pulsar客户端连贯到Broker来公布和生产音讯。 Pulsar客户端不间接与存储层Apache BookKeeper交互。 客户端也没有间接的Zookeeper拜访权限。这种隔离，为Pulsar实现平安的多租户对立身份验证模型提供了根底。 Apache Pulsar为客户端提供多种语言的反对，包含Java，C ++，Python，Go和Websockets。 Apache Pulsar还提供了一组兼容Kafka的API，用户能够通过简略地更新依赖关系并将客户端指向Pulsar集群来迁徙现有的Kafka应用程序，这样现有的Kafka应用程序能够立刻与Apache Pulsar一起应用，无需更改任何代码。 Broker层--无状态服务层Broker集群在Apache Pulsar中造成无状态服务层。服务层是“无状态的”，因为Broker实际上并不在本地存储任何音讯数据。无关Pulsar主题的音讯，都被存储在分布式日志存储系统（Apache BookKeeper）中。咱们将在下一节中更多地探讨BookKeeper。 每个主题分区（Topic Partition）由Pulsar调配给某个Broker，该Broker称为该主题分区的所有者。 Pulsar生产者和消费者连贯到主题分区的所有者Broker，以向所有者代理发送音讯并生产音讯。 如果一个Broker失败，Pulsar会主动将其领有的主题分区挪动到群集中残余的某一个可用Broker中。这里要说的一件事是：因为Broker是无状态的，当产生Topic的迁徙时，Pulsar只是将所有权从一个Broker转移到另一个Broker，在这个过程中，不会有任何数据复制产生。 下图显示了一个领有4个Broker的Pulsar集群，其中4个主题分区散布在4个Broker中。每个Broker领有并为一个主题分区提供音讯服务。 BookKeeper层--长久化存储层Apache BookKeeper是Apache Pulsar的长久化存储层。 Apache Pulsar中的每个主题分区实质上都是存储在Apache BookKeeper中的分布式日志。 每个分布式日志又被分为Segment分段。 每个Segment分段作为Apache BookKeeper中的一个Ledger，均匀分布并存储在BookKeeper群集中的多个Bookie（Apache BookKeeper的存储节点）中。Segment的创立机会包含以下几种：基于配置的Segment大小；基于配置的滚动工夫；或者当Segment的所有者被切换。 通过Segment分段的形式，主题分区中的音讯能够平均和均衡地散布在群集中的所有Bookie中。 这意味着主题分区的大小不仅受一个节点容量的限度； 相同，它能够扩大到整个BookKeeper集群的总容量。 上面的图阐明了一个分为x个Segment段的主题分区。 每个Segment段存储3个正本。 所有Segment都散布并存储在4个Bookie中。 Segment为核心的存储存储服务的分层的架构 和 以Segment为核心的存储 是Apache Pulsar（应用Apache BookKeeper）的两个要害设计理念。 这两个根底为Pulsar提供了许多重要的益处： 无限度的主题分区存储即时扩大，无需数据迁徙无缝Broker故障复原无缝集群扩大无缝的存储（Bookie）故障复原独立的可扩展性上面咱们别离开展来看着几个益处。 无限度的主题分区存储因为主题分区被宰割成Segment并在Apache BookKeeper中以分布式形式存储，因而主题分区的容量不受任何繁多节点容量的限度。 相同，主题分区能够扩大到整个BookKeeper集群的总容量，只需增加Bookie节点即可扩大集群容量。 这是Apache Pulsar反对存储有限大小的流数据，并可能以高效，分布式形式解决数据的要害。 应用Apache BookKeeper的分布式日志存储，对于对立音讯服务和存储至关重要。 ...

原创：Sijie Guo 翻译：翟佳之前的文章，咱们形容了 Apache Pulsar 可能成为企业级流和音讯零碎的起因。Pulsar 的企业个性包含音讯的长久化存储，多租户，多机房互联互备，加密和安全性等。咱们常常被问到的一个问题是 Apache Pulsar 和 Apache Kafka 有什么不同。 在本系列的Pulsar和Kafka比拟文章中，咱们将疏导您意识和理解音讯零碎中一些重要关注点，比方健壮性，高可用性和高带宽低提早等。 在用户抉择一个音讯零碎时，音讯模型是用户首先思考的事件。音讯模型应涵盖以下3个方面： 音讯生产 - 如何发送和生产音讯；音讯确认（ack） - 如何确认音讯；音讯保留 - 音讯保留多长时间，触发音讯删除的起因以及怎么删除；音讯生产模型在实时流式架构中，消息传递能够分为两类：队列（Queue）和流（Stream）。 队列（Queue）模型队列模型次要是采纳无序或者共享的形式来生产音讯。通过队列模型，用户能够创立多个消费者从单个管道中接管音讯；当一条音讯从队列发送进去后，多个消费者中的只有一个（任何一个都有可能）接管和生产这条音讯。音讯零碎的具体实现决定了最终哪个消费者理论接管到音讯。 队列模型通常与无状态应用程序一起联合应用。无状态应用程序不关怀排序，但它们的确须要可能确认（ack）或删除单条音讯，以及尽可能地扩大生产并行性的能力。典型的基于队列模型的音讯零碎包含 RabbitMQ 和 RocketMQ。 流式（Stream）模型相比之下，流模型要求音讯的生产严格排序或独占音讯生产。对于一个管道，应用流式模型，始终只会有一个消费者应用和生产音讯。消费者依照音讯写入管道的确切程序接管从管道发送的音讯。 流模型通常与有状态应用程序相关联。有状态的应用程序更加关注音讯的程序及其状态。音讯的生产程序决定了有状态应用程序的状态。音讯的程序将影响利用程序处理逻辑的正确性。 在面向微服务或事件驱动的体系结构中，队列模型和流模型都是必须的。 Pulsar 的音讯生产模型Apache Pulsar 通过“订阅”，形象出了对立的: producer-topic-subscription-consumer 生产模型。Pulsar 的音讯模型既反对队列模型，也反对流模型。 在 Pulsar 的音讯生产模型中，Topic 是用于发送音讯的通道。每一个 Topic 对应着 Apache BookKeeper 中的一个分布式日志。发布者公布的每条音讯只在Topic中存储一次；存储的过程中，BookKeeper 会将音讯复制存储在多个存储节点上；Topic 中的每条音讯，能够依据消费者的订阅需要，屡次被应用，每个订阅对应一个消费者组（Consumer Group）。 主题（Topic）是生产音讯的实在起源。只管音讯仅在主题（Topic）上存储一次，然而用户能够有不同的订阅形式来生产这些音讯： 消费者被组合在一起以生产音讯，每个生产组是一个订阅。每个 Topic 能够有不同的生产组。每组消费者都是对主题的一个订阅。每组消费者能够领有本人不同的生产形式： 独占（Exclusive），故障切换（Failover）或共享（Share）。Pulsar通过这种模型，将队列模型和流模型这两种模型联合在了一起，提供了对立的API接口。 这种模型，既不会影响音讯零碎的性能，也不会带来额定的开销，同时还为用户提供了更多灵活性，不便用户程序以最匹配模式来应用音讯零碎。 独占订阅（Stream流模型）顾名思义，独占订阅中，在任何工夫，一个消费者组（订阅）中有且只有一个消费者来生产 Topic 中的音讯。下图是独占订阅的示例。在这个示例中有一个有订阅A的沉闷消费者A-0，音讯 m0 到 m4 按程序传送并由 A-0 生产。如果另一个消费者 A-1 想要附加到订阅A，则是不被容许的。 故障切换（Stream流模型）应用故障切换订阅，多个消费者（Consumer）能够附加到同一订阅。 然而，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。 其余消费者将被指定为故障转移消费者。 ...

Apache Kafka 的高性能始终广受青睐，它能在高速解决音讯的同时维持低提早。Apache Pulsar 在同类产品中倒退迅速，竞争力突出。 总有文章说 Pulsar 比 Kafka 性能更好，然而想找到测试的原始数据并不容易。另外，很多报告的测试数据并非来自最新版本的 Pulsar 和 Kafka，这两个我的项目都倒退得太快了，因而测试后果对新版本不具备代表性，所以咱们决定应用Kafka（2.3.0）和 Pulsar（2.4.0），进行一系列性能测试，并将测试后果陆续公布进去。 本系列文章将重点探讨提早性，后续文章中会探讨吞吐量等。 音讯零碎性能测试Kafka 和 Pulsar 软件包都蕴含性能测试工具。咱们能够批改任何一个性能测试工具，让它们彼此兼容。咱们将应用 OpenMessaging Project 的第三方基准框架。 可参考：http://openmessaging.cloud/OpenMessaging Project 是一个 Linux Foundation Collaborative Project。OpenMessaging Project 的指标是为音讯和流技术提供厂商中立且实用于所有编程语言的规范。这一我的项目采纳了反对多种音讯技术的性能测试框架。 测试应用的代码都在 OpenMessaging GitHub 仓库中。 可参考：https://github.com/openmessag...测试最后被设计为在私有云产品上运行，但咱们将在 Amazon Web Services（AWS）中应用规范 EC2 实例进行测试。 咱们将在 GitHub 上公布每个测试的残缺输入后果。欢送你剖析数据并提出见解，当然，你也能够本人测试，获取新数据。咱们发现，应用不同系列的 EC2 实例集进行测试，后果相近，因而你的测试后果也不会与咱们相差很多。 尽管应用 OpenMessaging 基准工具来运行的测试曾经蕴含了大量工作负载，然而为了让比照测试更乏味，咱们决定再加一些负载，这一想法来自 LinkedIn Engineering 网站上一篇名为「Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines）」的文章。 可参考：https://engineering.linkedin....这是一篇很久以前的博客了，当初，硬件广泛更好，然而咱们并未应用顶配的测试设施。提前剧透：Kafka 和 Pulsar 都能够毫不费力地解决每秒 200 万次的写入，会在后续文章中详述。 ...

作者介绍： 腾讯云中间件专家工程师 Apache Pulsar PMC，《深刻解析Apache Pulsar》作者。 目前专一于中间件畛域，在音讯队列和微服务方向具备丰盛的教训。 负责 CKafka、TDMQ的设计与开发工作，目前致力于打造稳固、高效和可扩大的根底组件与服务。 导语在 Apache Pulsar 中，为了防止音讯的反复投递，消费者进行音讯确认是十分重要的一步。当一条音讯被消费者生产后，须要消费者发送一个Ack申请给Broker，Broker才会认为这条音讯被真正生产掉。被标记为曾经生产的音讯，后续不会再次反复投递给消费者。在这篇文章中，咱们会介绍Pulsar中音讯确认的模式，以及失常音讯确认在Broker侧是如何实现的。 1 确认音讯的模式在理解Pulsar音讯确认模式之前，咱们须要先理解一些前置常识 —— Pulsar中的订阅以及游标（Cursor）。Pulsar中有多种生产模式，如：Share、Key_share、Failover等等，无论用户应用哪种生产模式都会创立一个订阅。订阅分为长久订阅和非长久订阅，对于长久订阅，Broker上会有一个长久化的Cursor，即Cursor的元数据被记录在ZooKeeper。Cursor以订阅（或称为生产组）为单位，保留了以后订阅曾经生产到哪个地位了。因为不同消费者应用的订阅模式不同，能够进行的ack行为也不一样。总体来说能够分为以下几种Ack场景： （1）单条音讯确认（Acknowledge）和其余的一些音讯零碎不同，Pulsar反对一个Partition被多个消费者生产。假如音讯1、2、3发送给了Consumer-A，音讯4、5、6发送给了Consumer-B，而Consumer-B又生产的比拟快，先Ack了音讯4，此时Cursor中会独自记录音讯4为已Ack状态。如果其余音讯都被生产，但没有被Ack，并且两个消费者都下线或Ack超时，则Broker会只推送音讯1、2、3、5、6，曾经被Ack的音讯4不会被再次推送。 （2）累积音讯确认（AcknowledgeCumulative）假如Consumer承受到了音讯1、2、3、4、5，为了晋升Ack的性能，Consumer能够不别离Ack 5条音讯，只须要调用AcknowledgeCumulative，而后把音讯5传入，Broker会把音讯5以及之前的音讯全副标记为已Ack。 （3）批音讯中的单个音讯确认（Acknowledge）这种音讯确认模式，调用的接口和单条音讯的确认一样，然而这个能力须要Broker开启配置项AcknowledgmentAtBatchIndexLevelEnabled。当开启后，Pulsar能够反对只Ack一个Batch外面的某些音讯。假如Consumer拿到了一个批音讯，外面有音讯1、2、3，如果不开启这个选项，咱们只能生产整个Batch再Ack，否则Broker会以批为单位从新全副投递一次。后面介绍的选项开启之后，咱们能够通过Acknowledge办法来确认批音讯中的单条音讯。 （4）否定应答（NegativeAcknowledge）客户端发送一个RedeliverUnacknowledgedMessages命令给Broker，明确告知Broker，以后Consumer无奈生产这条音讯，音讯将会被从新投递。 并不是所有的订阅模式下都能用上述这些ack行为，例如：Shared或者Key_shared模式下就不反对累积音讯确认（AcknowledgeCumulative）。因为在Shared或者Key_Shared模式下，后面的音讯不肯定是被以后Consumer生产的，如果应用AcknowledgeCumulative，会把他人的音讯也一起确认掉。订阅模式与音讯确认之间的关系如下所示： 订阅模式单条Ack累积Ack批量音讯中单个Ack否定AckExclusive反对反对反对不反对Shared反对不反对反对反对Failover反对反对反对不反对Key_Shared反对不反对反对反对2 Acknowledge与AcknowledgeCumulative的实现Acknowledge与AcknowledgeCumulative接口不会间接发送音讯确认申请给Broker，而是把申请转交给AcknowledgmentsGroupingTracker解决。这是咱们要介绍的Consumer里的第一个Tracker，它只是一个接口，接口下有两个实现，一个是长久化订阅的实现，另一个是非长久化订阅的实现。因为非长久化订阅的Tracker实现都是空，即不做任何操作，因而咱们只介绍长久化订阅的实现——PersistentAcknowledgmentsGroupingTracker。 在Pulsar中，为了保障音讯确认的性能，并防止Broker接管到十分高并发的Ack申请，Tracker中默认反对批量确认，即便是单条音讯的确认，也会先进入队列，而后再一零售往Broker。咱们在创立Consumer时能够设置参数AcknowledgementGroupTimeMicros，如果设置为0，则Consumer每次都会立刻发送确认申请。所有的单条确认(individualAck)申请会先放入一个名为PendingIndividualAcks的Set，默认是每100ms或者沉积的确认申请超过1000，则发送一批确认申请。 音讯确认的申请最终都是异步发送进来，如果Consumer设置了须要回执（Receipt），则会返回一个CompletableFuture，胜利或失败都能通过Future感知到。默认都是不须要回执的，此时间接返回一个曾经实现的CompletableFuture。 对于Batch音讯中的单条确认（IndividualBatchAck），用一个名为PendingIndividualBatchIndexAcks的Map进行保留，而不是一般单条音讯的Set。这个Map的Key是Batch音讯的MessageId，Value是一个BitSet，记录这批音讯里哪些须要Ack。应用BitSet能大幅升高保留音讯Id的能存占用，1KB能记录8192个音讯是否被确认。因为BitSet保留的内容都是0和1，因而能够很不便地保留在堆外，BitSet对象也做了池化，能够循环应用，不须要每次都创立新的，对内存十分敌对。 如下图所示，只用了8位，就示意了Batch外面8条音讯的Ack状况，下图示意EntryId为0、2、5、6、7的Entry都被确认了，确认的地位会被置为1： 对于累计确认（CumulativeAck）实现形式就更简略了，Tracker中只保留最新的确认地位点即可。例如，当初Tracker中保留的CumulativeAck地位为5:10，代表该订阅曾经生产到LedgerId=5，EntryId=10的这条音讯上了。后续又ack了一个5:20，则间接替换后面的5:10为5:20即可。 最初就是Tracker的Flush，所有的确认最终都须要通过触发flush办法发送到Broker，无论是哪种确认，Flush时创立的都是同一个命令并发送给Broker，不过传参中带的AckType会不一样。 3 NegativeAcknowledge的实现否定应答和其余音讯确认一样，不会立刻申请Broker，而是把申请转交给NegativeAcksTracker进行解决。Tracker中记录着每条音讯以及须要提早的工夫。Tracker复用了PulsarClient的工夫轮，默认是33ms左右一个工夫刻度进行查看，默认延迟时间是1分钟，抽取出曾经到期的音讯并触发从新投递。Tracker次要存在的意义是为了合并申请。另外如果延迟时间还没到，音讯会暂存在内存，如果业务侧有大量的音讯须要提早生产，还是倡议应用ReconsumeLater接口。NegativeAck惟一的益处是，不须要每条音讯都指定工夫，能够全局设置延迟时间。 4 未确认音讯的解决如果消费者获取到音讯后始终不Ack会怎么样？这要分两种状况，第一种是业务侧曾经调用了Receive办法，或者曾经回调了正在异步期待的消费者，此时音讯的援用会被保留进UnAckedMessageTracker，这是Consumer里的第三个Tracker。UnAckedMessageTracker中保护了一个工夫轮，工夫轮的刻度依据AckTimeout、TickDurationInMs这两个参数生成，每个刻度工夫=AckTimeout / TickDurationInMs。新追踪的音讯会放入最初一个刻度，每次调度都会移除队列头第一个刻度，并新增一个刻度放入队列尾，保障刻度总数不变。每次调度，队列头刻度里的音讯将会被清理，UnAckedMessageTracker会主动把这些音讯做重投递。 重投递就是客户端发送一个RedeliverUnacknowledgedMessages命令给Broker。每一条推送给消费者然而未Ack的音讯，在Broker侧都会有一个汇合来记录（PengdingAck），这是用来防止反复投递的。触发重投递后，Broker会把对应的音讯从这个汇合里移除，而后这些音讯就能够再次被生产了。留神，当重投递时，如果消费者不是Share模式是无奈重投递单条音讯的，只能把这个消费者所有曾经接管然而未Ack的音讯全副从新投递。下图是一个工夫轮的简略示例： 另外一种状况就是消费者做了预拉取，然而还没调用过任何Receive办法，此时音讯会始终沉积在本地队列。预拉取是客户端SDK的默认行为，会事后拉取音讯到本地，咱们能够在创立消费者时通过ReceiveQueueSize参数来管制预拉取音讯的数量。Broker侧会把这些曾经推送到Consumer本地的音讯记录为PendingAck，并且这些音讯也不会再投递给别的消费者，且不会Ack超时，除非以后Consumer被敞开，音讯才会被从新投递。Broker侧有一个RedeliveryTracker接口，临时的实现是内存追踪（InMemoryRedeliveryTracker）。这个Tracker会记录音讯到底被从新投递了多少次，每条音讯推送给消费者时，会先从Tracker的哈希表中查问一下重投递的次数，和音讯一并推送给消费者。 由下面的逻辑咱们能够晓得，创立消费者时设置的ReceiveQueueSize真的要谨慎，防止大量的音讯沉积在某一个Consumer的本地预拉取队列，而其余Consumer又没有音讯可生产。PulsarClient上能够设置启用ConsumerStatsRecorder，启用后，消费者会在固定距离会打印出以后消费者的metrics信息，例如：本地音讯沉积量、承受的音讯数等，不便业务排查性能问题。 序幕Pulsar中的设计细节十分多，因为篇幅无限，作者会整顿一系列的文章进行技术分享，敬请期待。如果各位心愿系统性地学习Pulsar，能够购买作者出版的新书《深刻解析Apache Pulsar》。

️浏览本文需 4 分钟本系列文章将重点探讨 Pulsar 与 Kafka 的提早性，后续文章中会探讨吞吐量等。 本文将介绍测试细节（下图蓝色局部），下一篇文章将具体介绍测试方法（下图绿色局部），而测试后果在上一篇文章中详述（下图红色局部）。 测试细节介绍： 设定基准To set up the benchmark tests, we followed the steps documented on the OpenMessaging site. After applying the Terraform configuration, you get the following set of EC2 instances: 咱们依据 OpenMessaging 网站上提供的步骤进行了基准测试。利用 Terraform 配置能够失去以下 EC2 实例集： 用于 Pulsar/BookKeeper 和 Kafka broker 的 i3.4xlarge 实例蕴含两个 NVMe SSD，以进步性能。这两个功能强大的虚拟机都有 16 个 vCPU、122 GiB 内存和高性能磁盘。 两个 SSD 对 Pulsar 而言是现实设定，因为不仅能够写入两个数据流，数据流还能在磁盘上并行。Kafka 还能够通过调配两个驱动器的分区来应用这两个 SDD。 用于 Pulsar 和 Kafka 的 Ansible playbook 应用 tuned-adm 命令（提早性能配置文件）调优低提早性能。 ...

️浏览本文需 7 分钟本系列文章将重点探讨 Pulsar 与 Kafka 的提早性，之前的两篇文章曾经介绍了测试方法（下图绿色局部）与测试细节（下图蓝色内容），能够点击下列题目间接查看： Apache Pulsar 与 Kafka 性能比拟：提早性（测试方法）Apache Pulsar 与 Kafka 性能比拟：提早性（测试过程）本文将具体介绍 Pulsar 与 Kafka 的测试后果（下图红色内容）。Fsync 状态是试验中的一个变量，此外，为了更好地比照二者，测试者还调整了分区的数量。 Apache Pulsar 的测试后果本文将具体介绍 Apache Pulsar 提早性的测试后果。咱们会先介绍开启 fsync 的测试后果（Pulsar 默认的工作形式），再介绍敞开音讯 flush 的测试后果。 对于每个工作负载，有两张图可供参考：一张图是测试期间公布提早的 p99，另一张图是均匀端到端提早。另外，这两张图后附有在测试期间汇总提早测量值并整顿成的表格，提供提早散布数据。 公布提早的百分比计算比端到端提早更精确，因为端到端提早应用的是主动设置在音讯头中的工夫戳，并且该工夫戳的精度为毫秒，而公布提早的精度为纳秒。 所有测试均应用 100 字节的音讯。在 15 分钟测试期间，仅应用两个客户端（生产与生产）服务器，且生产速率和生产速率恒定为每秒 5 万条音讯。测试应用的 Apache Pulsar 版本为 2.4.0。 开启 fsync 时的提早测试测试 1：1 个 topic，1 个分区 测试 2：1 个 topic，6 个分区 测试 3：1 个 topic，16 个分区 探讨因为在 Pulsar 和 Kafka 中，分区都是并行单位，咱们期待在分区数量减少时，提早减小，理论测试后果也的确如此。总体而言，分区数量减少，公布提早和端到端提早都减小了。 ...

原创：Jesse Anderson 翻译：Sijie Guo 应用Kafka或Pulsar的一个常见用例是创立工作队列。这两种技术为实现此用例提供了不同的实现。我将探讨在Kafka和Pulsar中实现工作队列的办法以及它们的绝对劣势。 什么是工作队列工作队列（Work Queue）通过应用消息中间件零碎公布音讯来增加工作工作。一个工作音讯通常将由一个过程（最好是一组过程）生产，而后对其进行某种解决。 工作队列在音讯解决工夫上通常与其余解决形式略有不同。大多数惯例数据处理（如ETL或简略解决）在毫秒到秒级之间实现。然而工作队列用例下的音讯解决工夫通常绝对更长，从几秒到几分钟，甚至几个小时。 工作队列也被称为分布式工作队列（distributed work queue）。因为单台机器或者单个过程不足以满足相应的解决需要。咱们必须通过在许多不同的过程和计算机之间散发工作工作来满足相应的解决需要。因为引入了分布式的技术，所以工作解决零碎的复杂性也减少了10-15倍。 工作队列的示例为了帮忙您了解工作队列，让我举几个我在事实世界中看到的简略示例。所有示例的共同点是：工作的解决须要更长的工夫，同时必须尽快取得后果。 视频转码在视频网站，用户须要上传视频。此视频将保留到对象存储中。实现视频上传后，Web服务将公布一条对于该视频的音讯，蕴含要转码的视频的存储地址。这条音讯将由一组消费者生产，这些消费者将对此视频进行转码，以便以网络敌对的格局应用。转码可能须要几分钟到几小时能力实现。一旦视频转码实现，解决转码的消费者将公布一条新的音讯告知此视频曾经能够应用。 语音辨认与场景剖析通常主动客服零碎须要解决来自于呼叫核心的电话呼叫数据。当一个电话呼叫实现后，有多个步骤会产生。首先，语音辨认的程序须要解决呼叫的语音对话，将音频转化为文本。接下来，应用各种NLP和场景剖析工具将对文本进行剖析。整个处理过程须要1-60分钟。当整条电话呼叫数据被解决后，零碎还须要公布一条音讯来告知该呼叫数据已被解决实现。 工作队列的挑战工作队列的最基本的挑战是如何散发和平衡工作工作。你须要确保一个长时间运行的过程不会导致队列中的其余工作工作大量累积；其余的工作过程可能继续的拿到工作工作进行解决。同时，你还须要可能随着流量的变动主动地扩大工作解决能力。 工作队列的最大挑战在于如何处理错误： 你如何晓得一个工作过程是否挂掉或者何时挂掉？你如何从新开始解决？你如何检测一个工作过程是否挂掉？这些问题的答案都是针对特定技术的。当你的利用场景中须要应用工作队列的时候，这些答案对你抉择何种技术至关重要。 为什么不批量解决一个常见问题是为什么要应用实时零碎而不是批处理零碎？批处理零碎具备固有的启动工夫。对于30秒的解决工夫，你可能须要破费5-10秒期待分布式系统调配和启动资源。实时工作队列的要害之一是失去处理结果的速度。批处理零碎解决此类数据的效率太低。 应用Kafka实现工作队列既然您曾经理解了工作队列以及与它们相应的挑战，那么接下来，咱们来讨论一下如何应用Apache Kafka创立工作队列。 High Watermark 和工作队列在理解如何应用Kafka创立工作队列之前，你须要理解Kafka消费者如何标记他们曾经生产了音讯。Kafka消费者通过提交偏移量来执行此工作。Kafka消费者能够应用 commitSync 或 commitAsync 来提交生产偏移量。 Kafka消费者应用High Watermark来代表偏移量。这也就意味着消费者只能说“我曾经解决到这个偏移量”，而不是“我曾经解决过这个音讯”。这是Kafka跟其余消息中间件的一个重要区别。Kafka没有内置的形式来确认单条音讯。 这种以High Watermark记录消费者偏移量的形式意味着应用程序无奈单条地记录和发现错误。例如，如果消费者正在解决来自同一分区的两条工作工作而其中一件失败，那么Kafka不足内置的形式来通知应用程序这一条音讯失败了但另外一件音讯胜利了。Kafka的客户端能够告知应用程序曾经确认解决到了这一个偏移量，然而没法告知哪条音讯胜利和哪条音讯失败。 要绕过这个限度，你须要让每个消费者将每个分区视为它本人的工作“线程”。每个分区将被限度为一次解决一件事。当消费者实现这项工作时，它将调用commitSync标记解决实现。 因为您要在分区中放弃长时间运行，因而您必须创立更多分区来无效地解决数据。尽管您可能曾经开始应用20-30个分区，但您最终须要100个分区。这个分区数量是受限于Kafka的生产形式，因为整个消费者群须要足够的分区来无效地调配负载。 可能显而易见，您须要依据您要解决的工作量来调配失当的分区数量来相应地扩大您的生产组。 治理本人的提交你会留神到我屡次应用“内置”这个词。这是因为还有另一种抉择，它不是Kafka内置的。你必须编写本人的代码来实现单条确认。 如您所见，Kafka消费者的问题是受限于High Watermark的生产形式。您能够通过编程的形式来本人解决消费者的偏移量。最简略的办法是应用数据库：你必须敞开Kafka的主动偏移提交；而后你能够在数据库而不是Kafka中记录你解决过音讯的偏移量。 当消费者重新启动时，消费者须要晓得它相应的分区调配，而后进行数据库查找以查找最初一个偏移量及其状态。如果最初一个偏移量出错，则消费者将重新处理该音讯。 尽管这会减少更多的开销，但这是我向应用Kafka的团队举荐的一种办法。 应用Pulsar实现工作队列既然您曾经理解了如何应用Kafka创立工作队列，那么让咱们来看看如何应用Apache Pulsar来实现，并进行比照。 选择性确认咱们在上一节理解过Kafka的High Watermark。Pulsar在反对这种类型的确认的同时，还反对另外一种类型的确认，叫做选择性确认。选择性确认容许消费者仅确认单条音讯。您能够拜访Pulsar的官网文档中对于Ack的局部，理解更多无关选择性确认的细节。 当谈到工作队列时，选择性确认让工作队列变得简略。在一个工作队列中，咱们能够通过应用选择性acknowledge仅仅确认咱们曾经确认解决过的音讯。 如果要获取那些解决失败了的音讯，你能够通过调用 redeliverUnacknowledgedMessages 办法来获取。这将使Pulsar从新投递那些未经确认的音讯。你也能够通过设置另外一个参数 ackTimeout，让Pulsar 主动从新传递那些超时未确认的音讯。 Pulsar在解决分布式工作队列上还有另外一个劣势。在一个领有很多散布的分布式工作队列中，一些分区依然有可能成为热点，或者接管大量的工作音讯。Pulsar通过应用共享订阅更好地解决了这个问题。共享订阅容许跨消费者进行循环散发。这样能够比Kafka更平均地调配工作。 在Pulsar中，你会将工作音讯公布到工作队列中。此音讯将一个共享订阅中的许多不同消费者过程中进行生产，而后消费者开始理论的数据处理。一旦实现该解决，消费者将选择性地确认该音讯。接着，它会产生一条新的音讯，阐明改音讯曾经实现解决。 留神： Pulsar在开始设计之初就把工作队列的利用场景思考在内，并针对它进行优化，因为Yahoo在外部有大量的工作队列利用场景。这也是咱们看到Pulsar和Kafka之间有如此微小差别的重要起因。 创立分布式工作队列抉择不同的消息中间件零碎将的确扭转你实现分布式工作队列的形式。尽管你能够抉择任何一种解决方案创立分布式工作队列，然而Kafka和Pulsar有不同的创立办法。应用Pulsar创立分布式工作队列要容易得多。 如果你有工作队列的应用场景，请多多比照确保应用最合适的技术来实现。 点击 链接 ，查看英文原文

浏览本文须要约 10 分钟。自 LinkedIn 2011 年创立了 Apache Kafka 后，这款音讯零碎一度成为大规模音讯零碎的惟一抉择。为什么呢？因为这些音讯零碎每天须要传递数百万条音讯，音讯规模的确很宏大（2018 年 Twitter 推文均匀每天 500 万条，用户数均匀每天为 1 亿）。那时，咱们没有 MOM 零碎来解决基于大量订阅的流数据能力。所以，很多大牌公司，像 LinkedIn、Yahoo、Twitter、Netflix 和 Uber，只能抉择 Kafka。 现在到了 2019 年，世界产生了巨变，每天的音讯增量高达数十亿，反对平台也须要相应扩大，以满足持续增长的须要。因而，音讯零碎须要在不影响客户的状况下继续地无缝扩大。Kafka 在扩大方面存在诸多问题，零碎也难以治理。Kafka 的粉丝对此说法可能颇有微词，然而这并非集体偏见，我自身也是 Kafka 的粉丝。主观的说，随着世界的倒退和翻新，新工具比旧工具更加不便易用，咱们天然会感觉原来的工具漏洞百出，很难应用。天然倒退，始终如此。 这时，一款新的产品应运而生——它就是“Apache Pulsar”！ 2013 年雅虎创立了 Pulsar，并于 2016 年把 Pulsar 捐给了 Apache 基金会。Pulsar 现已成为 Apache 的顶级我的项目，取得举世瞩目的认可。雅虎和 Twitter 都在应用 Pulsar，雅虎每天发送 1000 亿条音讯，两百多万个主题。这样的音讯量，听起来很不堪设想吧，但的确是真的！ 接下来咱们理解下 Kafka 痛点以及 Pulsar 对应的解决方案。 Kafka 很难进行扩大，因为 Kafka 把音讯长久化在 broker 中，迁徙主题分区时，须要把分区的数据齐全复制到其余 broker 中，这个操作十分耗时。当须要通过更改分区大小以取得更多的存储空间时，会与音讯索引产生抵触，打乱音讯程序。因而，如果用户须要保障音讯的程序，Kafka 就变得十分辣手了。如果分区正本不处于 ISR（同步）状态，那么 leader 选取可能会错乱。个别地，当原始主分区呈现故障时，应该有一个 ISR 正本被征用，然而这点并不能齐全保障。若在设置中并未规定只有 ISR 正本可被选为 leader 时，选出一个处于非同步状态的正本做 leader，这比没有 broker 服务该 partition 的状况更蹩脚。应用 Kafka 时，你须要依据现有的状况并充分考虑将来的增量打算，布局 broker、主题、分区和正本的数量，能力防止 Kafka 扩大导致的问题。这是现实情况，理论状况很难布局，不可避免会呈现扩大需要。Kafka 集群的分区再平衡会影响相干生产者和消费者的性能。产生故障时，Kafka 主题无奈保障音讯的完整性（特地是遇到第 3 点中的状况，须要扩大时极有可能失落音讯）。应用 Kafka 须要和 offset 打交道，这点让人很头痛，因为 broker 并不保护 consumer 的生产状态。如果使用率很高，则必须尽快删除旧音讯，否则就会呈现磁盘空间不够用的问题。家喻户晓，Kafka 原生的跨地区复制机制（MirrorMaker）有问题，即便只在两个数据中心也无奈失常应用跨地区复制。因而，甚至 Uber 都不得不创立另一套解决方案来解决这个问题，并将其称为 uReplicator (https://eng.uber.com/ureplica...)。要想进行实时数据分析，就不得不选用第三方工具，如 Apache Storm、Apache Heron 或 Apache Spark。同时，你须要确保这些第三方工具足以撑持传入的流量。Kafka 没有原生的多租户性能来实现租户的齐全隔离，它是通过应用主题受权等平安性能来实现的。当然，在生产环境中，架构师和工程师有方法解决上述问题；然而在平台/解决方案或站点可靠性上，这是个让人头疼的问题，这并不像在代码中修复逻辑，而后将打包的二进制文件部署到生产环境中那么简略。 ...

以下文章来源于AI火线，作者AI火线小组 译本文由微信公众号 「AI 火线」原创（ID：ai-front），未经受权不得转载。 作者 | Chris Bartholomew 译者 | 无明 编辑 | Natalie AI 火线导读： 对于云原生分布式应用程序的开发人员来说，为把更多精力放在应用程序和微服务开发上，而不是浪费时间解决简单的音讯基础架构，他们须要一个解决方案帮忙治理好这些基础架构。 构建音讯基础架构的第一步是抉择适合的消息中间件技术。可选计划有很多，从各种开源框架（如 RabbitMQ、ActiveMQ、NATS）到一些商用产品（如 IBM MQ 或者 RedHat AMQ），除此之外，咱们还有 Kafka。不过，咱们最初没有应用 Kafka，而是抉择了 Pulsar。 为什么最终抉择了 Pulsar？上面列出了抉择 Pulsar 而不是 Kafka 的 7 大理由。 1. 流式解决和队列的合体Pulsar 就像一个合二为一的产品，不仅能够像 Kafka 那样解决高速率的实时场景，还反对规范的音讯队列模式，比方多消费者、生效备援订阅和音讯扇出等等。Pulsar 会主动跟踪客户端的读取地位，并把这些信息保留在高性能的分布式 ledger（BookKeeper）当中。 与 Kafka 不同，Pulsar 具备传统音讯队列（如 RabbitMQ）的性能，因而，只须要运行一个 Pulsar 零碎就能够同时解决实时流和音讯队列。 2. 反对分区，但不是必须的如果你用过 Kafka，就肯定晓得分区是怎么回事。Kafka 中的所有主题都是分区的，这样能够减少吞吐量。通过分区进而划分到不同的 broker，单个主题的解决速率能够失去大幅晋升。但如果某些主题不须要太高的解决速率，又该怎么办呢？对于这类状况，如果能不思考分区，防止随之而来的 API 和管理工作，不是更好吗？ Pulsar 就能够做到。如果只须要一个主题，能够应用一个主题而无需应用分区。如果须要放弃多个消费者实例的解决速率，也不须要应用分区，Pulsar 的共享订阅能够达到这一目标。 如果的确须要分区来进一步晋升性能，Pulsar 也能够反对分区的应用。 3. 日志诚然不错，但 ledger 更胜一筹Kafka 开发团队预感了日志对于一个实时数据交换零碎的重要性。日志通过追加的形式写入零碎，写入速度很快。日志中的数据是串行的，能够依照写入的程序疾速读取数据。相比随机读取和写入，串行读取和写入速度更快。对于任何一个提供数据保障的零碎来说，长久化存储方面的交互都是一个瓶颈，而日志形象最大限度地晋升了这方面的效率。 日志诚然好，但当数据量过大时，也会给咱们带来一些麻烦，单台服务器上保留所有日志曾经成为一个挑战。在日志占满服务器存储之后该怎么办？如何进行扩容？或者保留日志的服务器宕机，须要从新从正本创立新的服务器时，该怎么办？将日志从一台服务器拷贝到另一台服务器耗时很长，特地是想要同时放弃零碎实时数据时，实现这个操作就更难了。 Pulsar 对日志进行分段，从而防止了拷贝大块的日志。通过 BookKeeper， Pulsar 将日志分段扩散到多台不同的服务器上。也就是说，日志不会保留在单台服务器上，任何一台服务器都不会成为整个零碎的瓶颈。这使故障解决和扩容更加简略，只须要退出新的服务器，而无需进行再平衡解决。 ...

浏览本文须要 5 分钟 作者：Chris Bartholomew 前段时间，我在一篇博客中提到了 《抉择 Pulsar 而不是 Kafka 的 7 大理由 》 。之后我始终在筹备一份比拟 Kafka 和 Pulsar 的具体报告，并始终与 Pulsar 开源我的项目的用户交谈，同时也与咱们托管的 Pulsar 服务 —— Kafkaesque (https://kafkaesque.io/) 的用户交谈。 我发现上一篇文章中我脱漏了一些起因。所以，我顺便写了本篇后续，进行补充。 在补充之前，咱们先来疾速回顾一下上一篇文章中提到的 7 个起因： 流式解决和队列的合体。Kafka 或 RabbitMQ 在单个平台上都只能解决其中一种形式。而 Pulsar 就像一个合二为一的产品，能够同时解决实时流和音讯队列。反对分区，但不是必须的。如果只须要一个主题，能够应用一个主题而无需应用分区。如果须要放弃多个消费者实例的解决速率，也不须要应用分区。分布式的日志。Pulsar 日志是分布式的，能够程度扩大。因而不会保留在单台服务器上，任何一台服务器都不会成为整个零碎的瓶颈。无状态的 broker。云原生利用程序开发的现实场景，数据的散发和保留互相独立。原生反对跨地区复制，而且配置简略。无论是全局分布式应用程序还是灾备计划，任何人都能够通过 Pulsar 搞定。稳固的体现。基准测试表明，Pulsar 能够在提供较高吞吐量的同时放弃较低的提早。齐全开源。不论是与 Kafka 类似的个性，还是 Kafka 没有的个性都是开源的。以上便是之前提到的 7 个起因。如果你想理解对于以上几点的具体内容，能够查看结尾提到的文章。这些起因仿佛曾经很多了，然而我发现了更多。 多租户解决上一篇文章中，我应该多谈谈多租户。Pulsar 对多租户的反对是一个很重要的个性。在企业中，音讯基础架构会被多团队、多我的项目应用。为每个团队（我的项目）别离保护一个独立的音讯零碎集群代价过高且难以保护。 Pulsar 能够有多个租户，这些租户能够有多个命名空间，以放弃内容程序。再加上每个命名空间的访问控制、配额、速率限度等，能够设想，未来咱们能够只应用一个集群就能解决多租户问题。其实不仅咱们思考到这个问题，Kafka 也会思考。在 Kafka 改良倡议（KIP）KIP-37 中能够看到与此相关的内容。这个问题曾经探讨了一段时间了。 Quorum 复制接下来，我会讲到很多细节。要想确保音讯不失落，消息传递零碎会配置每条音讯生成 2 或 3 个正本，以防出错。Kafka 应用 follow-the-leader 模型来实现这一点。Leader 存储音讯，而 follower 复制 leader 上的音讯。 ...

本文作者张超，原载于公众号『腾讯云中间件』，已取得转载受权，较原文有微调。对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ Apache Pulsar 是一个多租户、高性能的服务间音讯传输解决方案，反对多租户、低延时、读写拆散、跨地区复制、疾速扩容、灵便容错等个性。腾讯数据平台部 MQ 团队对 Pulsar 做了深刻调研以及大量的性能和稳定性方面优化，目前曾经在腾讯云音讯队列 TDMQ 落地上线。本文次要介绍 Pulsar 提早音讯投递的实现，心愿与大家一起交换。 什么是提早音讯投递提早音讯投递在 MQ 利用场景中非常广泛，它是指音讯在发送到 MQ 服务端后并不会立马投递，而是依据音讯中的属性提早固定工夫后才投递给消费者，个别分为定时音讯和提早音讯两种： 定时音讯：Producer 将音讯发送到 MQ 服务端，但并不冀望这条音讯立马投递，而是推延到在以后工夫点之后的某一个工夫投递到 Consumer 进行生产。提早音讯：Producer 将音讯发送到 MQ 服务端，但并不冀望这条音讯立马投递，而是提早肯定工夫后才投递到 Consumer 进行生产。目前在业界，腾讯云的 CMQ 和阿里云的 RocketMQ 也都反对提早音讯投递： CMQ：将音讯提早期间定义为”航行状态“，可通过设置 DelaySeconds 配置提早范畴，取值范畴为 0 - 3600 秒，即音讯最长不可见时长为 1 小时。RocketMQ：开源版本提早音讯长期存储在一个外部主题中，反对特定的 level，例如定时 5s，10s，1m 等，商业版本反对任意工夫精度。开源的 NSQ、RabbitMQ、ActiveMQ 和 Pulsar 也都内置了提早音讯的解决能力。尽管每个 MQ 我的项目的应用和实现形式不同，但外围实现思路都一样：Producer 将一个提早音讯发送到某个 Topic 中，Broker 将提早音讯放到长期存储进行暂存，提早跟踪服务（Delayed Tracker Service）会查看音讯是否到期，将到期的音讯进行投递。 提早音讯投递的应用场景提早音讯投递是要暂缓对以后音讯的解决，在将来的某个工夫点再触发投递，理论的利用场景十分多，比方异样检测重试、订单超时勾销、预约揭示等。 服务申请异样，须要将异样申请放到独自的队列，隔 5 分钟后进行重试；用户购买商品，但始终处于未领取状态，须要定期揭示用户领取，超时则敞开订单；面试或者会议预约，在面试或者会议开始前半小时，发送告诉再次揭示；最近所在业务产品有个应用 Pulsar 提早音讯的 Case：业务要对两套零碎的日志音讯进行关联，其中一套零碎因为查问 Hbase 可能会超时或失败，须要将失败的关联工作在集群闲暇的时候再次调度。 ...

编者荐语：原文作者冉小龙，首发于公众号“腾讯云中间件”，公布已取得原帐号受权。如需转载，请返回联系。本文次要为大家介绍 Apache Pulsar 的音讯和存储模型，供大家参考。对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 背景第一篇 Apache Pulsar 系列文章为读者们具体解释了 Pulsar 的音讯保留和过期策略，本文是系列第二篇，次要从 Pulsar 设计的原理以及在 BookKeeper 中如何存储做一个梳理。 在社区中，咱们常常能够看到用户无关 Backlog，storage size 和 retention 等策略的困惑，比拟常见的一些问题，诸如： 我没有设置 Retention 策略，为什么通过 topics stats 能够查看到 storage size 远大于 backlog size？我的 msg backlog size 很小，然而 storage size 确始终在增长？…Pulsar 的音讯模型首先，咱们先来看一下 Pulsar 的音讯模型 如上图所示，Pulsar 提供了最根本的 pub-sub 的解决模型。 Producer 首先 Producer 端生产音讯，将音讯以 append 的模式追加到 Topic 中，这里具体散发到哪一个 Topic 中，依据音讯是否设置了 msg key 会有所不同。 设置了 msg key，音讯会基于 key 做 hash，将音讯散发到不同的 partitions 中未设置 msg key，音讯会以 round robin 的模式，散发到不同的 partitions在音讯散发的模型中，Pulsar 与 Kafka 相似。 ...

编者荐语： 原文作者冉小龙，首发于公众号“腾讯云中间件”，公布已取得原帐号受权。如需转载，请返回联系。本文次要为大家介绍 Apache Pulsar 的音讯保留和过期策略，供大家参考。 对于 Apache Pulsar Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 默认状况下，Pulsar Broker 会对音讯做如下解决： 当音讯被 Consumer 确认之后，会立刻执行删除操作。对于未被确认的音讯会存储到 backlog 中。然而，很多线上的生产环境下，这种默认行为并不能满足咱们的生产需要，所以，Pulsar 提供了如下配置策略来笼罩这些行为： Retention 策略：用户能够将 Consumer 曾经确认的音讯保留下来。TTL 策略：对于未确认的音讯，用户能够通过设置 TTL 来使未确认的音讯达到曾经确认的状态。上述两种策略的设置都是在 NameSpace 的级别进行设置。 Retention 策略Retention 策略的设置提供了两种形式： 音讯的大小，默认值：defaultRetentionSizeInMB=0音讯被保留的工夫，默认值：defaultRetentionTimeInMinutes=0咱们能够在 broker.conf 中对这两项内容进行配置也能够通过命令行的模式。上文提到过，这两种策略的设置，都是在 NameSpace 的级别进行设置，所以当咱们应用命令行配置时，应用 NameSpaces 来进行配置，具体如下： root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-retentionThe following options are required: --size, -s --time, -tSet the retention policy for a namespaceUsage: set-retention [options] tenant/namespace Options: * --size, -s Retention size limit (eg: 10M, 16G, 3T). 0 or less than 1MB means no retention and -1 means infinite size retention * --time, -t Retention time in minutes (or minutes, hours, days, weeks eg: 100m, 3h, 2d, 5w). 0 means no retention and -1 means infinite time retention如上所示：咱们能够通过 -s 或者 -t 来指定咱们须要配置的大小或者工夫。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。\GitHub 地址：http://github.com/apache/pulsar/ 多年来，DataStax 始终关注音讯畛域。一个十分重要的起因是基于微服务的架构日益遍及。简略来说，微服务架构应用音讯总线来解耦服务之间的通信，并简化重放、错误处理和负载峰值。 有了 Cassandra 和 Astra，开发者和架构师就有了这样一个数据库生态系统： 以开源为根底非常适合混合云和多云部署云原生，按生产计价目前还没有满足这些需要的音讯解决方案，因而咱们打算打造一个。从评估最风行的 Apache Kafka 开始，咱们发现它在四个方面存在有余： 跨地区复制扩大多租户队列然而，针对 Kafka 的不足之处，Apache Pulsar 却解决了所有这些问题。 让咱们逐项看下 Pulsar 在这四方面的劣势。 Pulsar 反对跨地区复制Kafka 被设计为在单个区域内运行，不反对跨数据中心的复制。Kafka 部署区域之外的客户端只能忍耐提早减少。有几个我的项目试图在客户端层面向 Kafka 增加跨数据中心的复制，但操作都很艰难，而且容易失败。 Pulsar 在外围服务器上构建了跨地区复制性能，你能够在部署时抉择同步或异步配置，并且能够按主题配置复制机制。生产者能够从任何地区写入共享主题，Pulsar 负责确保这些信息对各地的消费者均可见。 Pulsar 具备高可扩展性在 Kafka 中，存储单元是一个段文件，然而复制单元是一个分区中的所有段文件。每个分区都归一个 leader 代理所有，它会复制给多个 follower。所以，当你须要给 Kafka 集群减少容量时，在新节点分担现有节点的负载之前，有些分区须要复制到新节点上。 这意味着，减少 Kafka 集群的容量会使其变慢，而不是变快。如果你的容量布局恰到好处，这很好，但如果业务需要的变动比你预期的要快，那么这可能会是一个重大的问题。 Pulsar 减少了一个间接层。（Pulsar 也将计算和存储离开，别离由 broker 和 bookie 治理，但这里，最重要的局部是 Pulsar 如何通过 BookKeeper 减少复制的粒度。）在 Pulsar 中，分区被宰割成 ledger，但和 Kafka 段不同，ledger 能够独自复制，互不影响。Pulsar 在 ZooKeeper 中保护着一个 ledger 到分区的映射。因而，当咱们向集群增加一个新的存储节点时，咱们所要做的就是在该节点上启动一个新的 ledger。现有的数据能够保留在原来的地位，不须要集群做额定的工作。 ...

本文作者是 David Kjerrumgaard，目前任职于 Splunk，Apache Pulsar 和 Apache NiFi 我的项目贡献者。译者为 Sijia@StreamNative。原文链接：https://searchdatamanagement.... ，翻译已获受权。对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 相比于 Kafka 等数据处理中间件，分布式音讯平台 Apache Pulsar 如何存储数据？本文基于架构，比照了 Apache Kafka 等传统数据处理中间件和分布式音讯平台 Apache Pulsar 的优劣势，供大家参考。 存储可扩大Apache Pulsar 的多层架构将音讯服务层与存储层齐全解耦，从而使各层能够独立扩大。传统的分布式数据处理中间件（如 Hadoop、Spark）则在同一集群节点/实例上解决和存储数据。这种设计能够升高通过网络进行传输的数据量，使得架构更简洁，性能也有所晋升，但同时扩展性、弹性、运维受到了影响。 Pulsar 的分层架构在云原生解决方案中自成一家。现在，大幅晋升的网络带宽为此架构提供了坚实基础，有利于计算和存储的拆散。Pulsar 的架构将服务层与存储层解耦：无状态 broker 节点负责数据服务；bookie 节点负责数据存储（如图 1）。 服务层与存储层解耦的架构有很多劣势。首先，各层都能够弹性扩大，彼此之间互不影响。借助云和容器等环境的弹性能力，各层能够主动扩缩容，动静适应流量顶峰。其次，通过显著升高集群扩大和降级复杂性，进步了零碎可用性和可管理性。再次，这种设计还属于容器敌对型设计，使 Pulsar 成为托管云原生流零碎的最佳计划。Apache Pulsar 应用高可扩大的 BookKeeper 作为存储层，实现了弱小的长久保障与分布式数据存储和复制，并原生反对跨地区复制。 多层设计能够轻松实现分层存储，从而能够将拜访频率较低的数据卸载到低成本的长久化存储（如 AWS S3、Azure 云）中。Pulsar 反对配置预约义的存储大小或时间段，主动将存储在本地磁盘的数据卸载至云存储平台，开释本地磁盘，同时平安备份事件数据。 Pulsar vs. KafkaApache Pulsar 和 Apache Kafka 都具备相似的消息传递概念。客户端通过 topic（逻辑上分为多个分区）与二者进行交互。通常而言，写入 topic 的有限数据流会被分为分区（特定数量、大小相等的分组），从而使数据均匀分布在零碎中，并被多个客户端同时应用。 Apache Pulsar 和 Apache Kafka 之间的本质区别在于存储分区的基础架构。Apache Kafka 是基于分区的公布/订阅零碎，旨在作为整体架构运行，服务层和存储层位于同一节点上。 ...

本文形容了一些 Pulsar 客户端编码相干的最佳实际，并提供了可商用的样例代码，供大家研发的时候参考，晋升大家接入 Pulsar 的效率。在生产环境上，Pulsar 的地址信息往往都通过配置核心或者是 K8s 域名发现的形式取得，这块不是这篇文章形容的重点，以 PulsarConstant.SERVICE_HTTP_URL 代替。本文中的例子均已上传到 Github 。 后期 Client 初始化和配置初始化 Client--demo 级别import lombok.extern.slf4j.Slf4j;import org.apache.pulsar.client.api.PulsarClient;/*** @author hezhangjian*/@Slf4jpublic class DemoPulsarClientInit { private static final DemoPulsarClientInit INSTANCE = new DemoPulsarClientInit(); private PulsarClient pulsarClient; public static DemoPulsarClientInit getInstance() { return INSTANCE; } public void init() throws Exception { pulsarClient = PulsarClient.builder() .serviceUrl(PulsarConstant.SERVICE_HTTP_URL) .build(); } public PulsarClient getPulsarClient() { return pulsarClient; }}Demo 级别的 Pulsar client 初始化的时候没有配置任何自定义参数，并且初始化的时候没有思考异样，init 的时候会间接抛出异样。 初始化 Client--可上线级别import io.netty.util.concurrent.DefaultThreadFactory;import lombok.extern.slf4j.Slf4j;import org.apache.pulsar.client.api.PulsarClient;import java.util.concurrent.Executors;import java.util.concurrent.ScheduledExecutorService;import java.util.concurrent.TimeUnit;/*** @author hezhangjian*/@Slf4jpublic class DemoPulsarClientInitRetry { private static final DemoPulsarClientInitRetry INSTANCE = new DemoPulsarClientInitRetry(); private volatile PulsarClient pulsarClient; private final ScheduledExecutorService executorService = Executors.newScheduledThreadPool(1, new DefaultThreadFactory("pulsar-cli-init")); public static DemoPulsarClientInitRetry getInstance() { return INSTANCE; } public void init() { executorService.scheduleWithFixedDelay(this::initWithRetry, 0, 10, TimeUnit.SECONDS); } private void initWithRetry() { try { pulsarClient = PulsarClient.builder() .serviceUrl(PulsarConstant.SERVICE_HTTP_URL) .build(); log.info("pulsar client init success"); this.executorService.shutdown(); } catch (Exception e) { log.error("init pulsar error, exception is ", e); } } public PulsarClient getPulsarClient() { return pulsarClient; }}在理论的环境中，咱们往往要做到 pulsar client 初始化失败后不影响微服务的启动，即待微服务启动后，再始终重试创立 pulsar client。下面的代码示例通过 volatile 加一直循环重建实现了这一指标，并且在客户端胜利创立后，销毁了定时器线程。 ...

为推动国内开源生态产业倒退，中国开源云联盟（China Open Source Cloud League，简称“COSCL”）于近期组织发展了 2021 卓越开源贡献者、优良开源我的项目、最佳开源实际案例、优良开源翻新企业评选活动。 通过投票、问难、专家评审，Apache Pulsar 我的项目荣获中国开源云联盟「2021 优良开源我的项目」名称！ Apache Pulsar 是 Apache 软件基金会顶级我的项目，集音讯、存储和轻量计算为一体，是云原生时代的音讯和流数据系统，采纳存储计算拆散的云原生架构，人造反对大集群、多租户、百万级 Topic、跨地区数据复制和长久化存储、分层存储等企业级个性，并提供了对立的生产模型，反对音讯队列和流两种场景，既能为队列场景提供企业级读写服务质量和严格一致性保障，又能为流场景提供极高带宽。 企业可借助 Apache Pulsar 打造对立的实时数据基础设施平台，突破数据隔离和数据孤岛，简化架构并升高运维复杂度，目前已落地国内外数百家企业。 同时，Apache Pulsar 社区始终保持疾速成长和沉闷，主仓库寰球贡献者已超过 450 名，月度沉闷贡献者已比肩或超过 Apache Kafka。本次荣获「2021 优良开源我的项目」名称，也是整体社区成员的荣誉！让咱们再接再厉，一直促成 Apache Pulsar 我的项目和社区的倒退。 退出 Apache Pulsar 中文交换群

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 明天，咱们很骄傲地发表 StreamNative 公布并开源首版 AWS Simple Queue Service (SQS) connector！通过 SQS connector，你能轻松地在 Pulsar 与 SQS 之间挪动数据，并充分利用这两种音讯零碎的劣势。这标记着 StreamNative 在晋升 Pulsar 生态系统的多样性、完整性和生产力方面又向前逾越了一大步。 SQS connector 是什么？家喻户晓，测验音讯零碎的重要指标之一是与周边生态的集成情况。与其它 Pulsar connector 一样，SQS connector 是构建 Apache Pulsar 周边生态的重要组成部分。SQS connector 可能帮忙你疾速高效地在 Pulsar 和 SQS 之间挪动数据，具备以下两类 connector： SQS source connector – 将 SQS 的数据导入至 Pulsar。 SQS sink connector – 将 Pulsar 的数据导出至 SQS。 为什么开发 SQS connector？在当今云原生时代，Apache Pulsar 与 AWS SQS 是构建分布式架构的重要组件和根底软件。 ...

导读：在 4 月 11 日 TGIP-CN 直播流动上，咱们邀请到 StreamNative 工程师徐昀泽，他为大家分享了 KoP 2.8.0 新个性前瞻。上面是徐昀泽分享视频的简洁文字整顿版本，供大家参考。在 4 月 11 日 TGIP-CN 直播中，来自 StreamNative 的软件工程师徐昀泽为大家带来了《KoP 2.8.0 性能个性预览》的分享。上面是其分享视频的简洁文字整顿版本，敬请参考。　明天分享的内容是《KoP（Kafka on Pulsar）2.8.0 新个性前瞻》，首先我简略自我介绍下：我就任于 StreamNative ，是 Apache Pulsar 的 Contributor，也是 KoP 的次要维护者。 对于 KoP 版本号标准首先，咱们先聊一聊 KoP 版本号的问题。 Apache Pulsar 领有 Major release。因为 KoP 后期版本治理比拟凌乱，所以从 2.6.2.0 开始，KoP 的版本号跟 Pulsar 根本保持一致。KoP Master 分支会不定期的更新依赖的 Pulsar 版本。这样的话，如果想要有一些新的性能能够在 Pulsar 中提一个 PR，而后 KoP 去依赖这个办法就行了。KoP 2.8.0 是一个能够实用于生产的一个版本。 明天我次要从如下次要四点为大家开展本次的直播： 为什么须要 KoPKoP 的根本实现KoP 2.8.0-SNAPSHOT 版本的近期停顿近期打算及将来瞻望Kafka Vs Pulsar首先说一下我对 Kafka 和 Pulsar 这两个零碎的认识，抛开一些杂七杂八的 feature 的话，这两个零碎还是很类似的，但最大的区别是它们的存储模型。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/本文作者为江谋晶，谊品生鲜高级研发工程师。主导数据管道零碎的设计与研发，借助 Apache Pulsar 作为数据同步工具，并落地实现增量数据同步的各种利用场景需要。他打算进一步实现数据管道的平台化及可视化，并接入更丰盛的数据库类型反对。背景数据管道，就是让数据通过肯定的传输介质，从一个地点达到另一个地点，从而实现数据的同步或复制，来满足利用需要。随着业务量及数据量的的大幅增长，咱们现有的微服务须要再度细化（拆分）。 零碎拆分如何做到让用户无感知呢？上线时，通过分流策略将局部用户引流到新的服务中，要求新老零碎并行运行一段时间来撑持新服务的试运行到齐全落地，从而最大水平上缩小生产故障。为了让新服务数据可能与旧零碎服务中的数据实时统一，就须要同步数据。随着数据量大幅增长，要放慢查问速度，能够将数据复制到 ElasticSearch 中，进步查问速率。 市场上有相干的开源数据同步产品和商业版数据通道工具，不须要人工染指即可实现双边的数据同步复制。但零碎重构可能会产生一些表构造或表对象的变动，无奈兼容商业的数据同步，须要开发人员染指进行相干解决。咱们采纳了 Maxwell + Pulsar 的自研解决方案：应用 Maxwell 读取 binlog，Pulsar 进行数据传输。Maxwell + Pulsar 实现下层的数据读取，上游业务方实现对应的数据同步逻辑。比方，针对零碎重构拆分的数据同步业务场景以及读写拆散，将数据复制同步到相似 ElasticSearch 搜索引擎中的业务场景。 为何抉择 Pulsar?在数据管道的零碎重构中，咱们抉择 Apache Pulsar 的起因如下： 无状态。微服务架构体系中，中间件最好是无状态的。这样启动快，能够随时替换并且能够实现无缝伸缩，弹性扩大。Kafka 不是无状态的，每个 Broker 都蕴含了分区所有的日志，如果一个 Broker 宕机，并非任意一个 Broker 能够来接管，也不能随便增加 Broker 来分担负载，Broker 之间必须进行状态同步。在 Pulsar 架构中，数据从 Broker 剥离，存储在共享贮存外部；下层是下层是无状态的计算层（Broker），复制音讯散发和服务（计算），上层则是长久化的存储层（ Bookie ）。所以数据计算和存储互相独立，能够实现数据的独立扩大和疾速复原。Pulsar 反对流解决和传统的音讯队列，大大晋升了订阅灵便度。Pulsar 云原生的架构不便程度弹性扩大，且反对跨地区复制。Pulsar 反对分区，吞吐高，提早低。开源社区沉闷，技术支持响应快、服务好。Pulsar 如何保障分布式生产过程中的程序首先，咱们理解一下 Pulsar 的订阅模式。Pulsar 有四种订阅模式：exclusive 模式（独占模式）、failover 模式 （故障转移模式）、Shared 模式 （共享模式）以及 Key_Shared 模式。Exclusive 模式只有一个消费者（consumer），接管一个 Topic 所有的音讯。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 传智教育介绍传智教育（原传智播客）是致力于高素质软件开发人才培养的 IT 培训公司，旗下涵盖黑马程序员、博学谷、传智汇、酷丁鱼少儿编程、传智专修学院、院校邦等子品牌。 传智教育是第一个实现 A 股 IPO 的教育企业，公司致力于造就高精尖数字化人才，次要造就人工智能、大数据、智能制作、软件、互联网、区块链等数字化专业人才及数据分析、网络营销、新媒体等数字化利用人才。 为了将更优质的教育资源惠及更多学子，传智教育在全国开设了 19 所分校，造就了 30+ 万 IT 从业者；出版书籍 111 本，覆盖全国 200+ 万高校生；公布视频教程 12+ 万节，年均下载及播放量 4000+ 万次；发展收费直播公开课 1500+ 场，年均听课人数近百万。 博学谷于 2016 年 7 月正式成立。依靠传智教育 15 年 IT 教育积淀，以待业课为外围，采纳个性化、随到随学的自适应学习模式，为学员提供零根底入门、技能晋升及职业生涯规划为一体的 IT 在线学习服务。专一整合劣势 IT 教学资源，打造更适宜在线学习的优质教学产品和服务。 面临的问题2020 年，疫情为咱们的生存和工作带来了巨大变化，因疫情防控须要，很多线下课程无奈失常发展，更多用户抉择通过线上学习来晋升常识储备、拓展业余能力。博学谷提供线上教学服务，成为了更多用户的最佳抉择。随着用户征询和学习行为的大幅上涨，博学谷在线零碎的压力有所增加，对原有零碎提出了新的挑战： 原有零碎只反对离线同步，响应较慢。须要对原有零碎收集的旧数据进行同步，对新数据进行离线收集和实时收集，并且基于所有数据进行链路式的数据荡涤和聚合剖析。目前采纳阿里云 DTS（Data Transmission Service，数据传输服务）同步形式对业务表进行同步，老本较大且无奈在同步过程中对数据进行荡涤、转换等操作。面对规模的增长和模式的调整，博学谷须要一套更加灵便、高效的零碎，以解决规模化增长的业务数据，确保业务零碎的失常运行，撑持业务模式的调整，同时将数据更多地用于决策分析。 为什么抉择 Pulsar?咱们心愿借助消息中间件来解决遇到的这些挑战。咱们团队成员有应用 RabbitMQ 和 Kafka 的教训：RabbitMQ 比拟适宜轻量化场景，Apache Kafka 实用于日志量大的场景。咱们须要一套利用场景和源码浏览都更全面的解决方案。在调研的过程中，咱们晓得市场上还有另一个深受欢送的音讯零碎 Apache Pulsar。对于运维团队来说，学习这三种消息中间件的都有肯定的学习老本问题，而且基础设施一旦落地再扭转并不容易，所以在传智教育的中间件选型上咱们进行了充沛调研。调研角度次要包含： 反对音讯流式解决，确保音讯解决程序反对“仅一次”语义音讯解决反对音讯永恒长久化，存储规模易于扩大云原生部署敌对，运维老本较低源代码品质好，社区活跃度高咱们发现 Pulsar 是一款云原生的音讯和事件流平台，内置的很多个性正好满足咱们的需要。例如：Pulsar 采纳计算与存储拆散的架构设计，在 Apache BookKeeper 上存储数据，在 broker 上进行 Pub/Sub 相干的计算，具备 IO 隔离的个性。和传统的音讯平台（如 Kafka）相比，Pulsar 的架构有显著的劣势： ...

* 撑持了80%的离线作业，日作业量在1W+* 大多数场景比 Hive 性能晋升了3-6倍* 多租户、并发的场景更加高效稳固T3出行是一家基于车联网驱动的智慧出行平台，领有海量且丰盛的数据源。因为车联网数据的多样性，T3出行构建了以 Apache Hudi 为根底的企业级数据湖，提供强有力的业务撑持。而对于负责数据价值开掘的终端用户而言，平台的技术门槛是另一种挑战。如果能将平台的能力统合，并一直地优化和迭代，让用户可能通过 JDBC 和 SQL 这种最广泛最通用的技术来应用，数据生产力将能够失去进一步的晋升。 T3出行抉择了基于网易数帆主导开源的 Apache Kyuubi（以下简称Kyuubi）来搭建这样的能力。在2021 中国开源年会(COSCon'21)上，T3出行高级大数据工程师李心恺具体解读了抉择 Kyuubi 的起因，以及基于 Kyuubi 的深度实际和实现的价值。 引入 Kyuubi 前的技术架构T3出行整个数据湖体系，由数据存储与计算、数据查问与剖析和应用服务层组成。其中数据计算分为离线和实时。 数据存储OBS 对象存储，格式化数据存储格局以 Hudi 格局为主。 数据计算离线数据处理：利用 Hive on Spark 批处理能力，在 Apache Dolphin Scheduler 上定时调度，承当所有的离线数仓的 ETL 和数据模型加工的工作。 实时数据处理：建设了以 Apache Flink 引擎为根底的开发平台，开发部署实时作业。 数据查问与剖析OLAP 层次要为面向治理和经营人员的报表，对接报表平台，查问要求低时延响应，需要多变疾速响应。面向数据分析师的即席查问，更是要求 OLAP 引擎能反对简单 SQL 解决、从海量数据中疾速甄选数据的能力。 应用服务层数据应用层次要对接各个业务零碎。离线 ETL 后的数据写入不同业务不同数据库中，面向上游提供服务。 现有架构痛点跨存储数据分布在 Hudi、ClickHouse、MongoDB 等不同存储，须要写代码关联剖析减少数据处理门槛和老本。 SQL不对立Hive 不反对通过 upsert、update、delete 等语法操作 Hudi 表，同时 MongoDB、ClickHouse 等语法又各不相同，开发转换老本较高。 资源管控乏力Hive on Spark、Spark ThriftServer 没有较好的资源隔离计划，无奈依据租户权限做并发管制。 选型 Apache KyuubiApache Kyuubi 是一个 Thrift JDBC/ODBC 服务，对接了 Spark 引擎，反对多租户和分布式的个性，能够满足企业内诸如 ETL、BI 报表等多种大数据场景的利用。Kyuubi 能够为企业级数据湖摸索提供标准化的接口，赋予用户调动整个数据湖生态的数据的能力，使得用户可能像解决一般数据一样解决大数据。我的项目已于2021年 6 月 21 号正式进入 Apache 孵化器。于T3出行而言，Kyuubi 的角色是一个面向 Serverless SQL on Lakehouse 的服务。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ BIGO 于 2014 年成立，是一家高速倒退的科技公司。基于弱小的音视频解决技术、寰球音视频实时传输技术、人工智能技术、CDN 技术，BIGO 推出了一系列音视频类社交及内容产品，包含 Bigo Live（直播）和 Likee（短视频）等，在寰球已领有近 1 亿用户，产品及服务已笼罩超过 150 个国家和地区。 挑战最后，BIGO 的音讯流平台次要采纳开源 Kafka 作为数据撑持。随着数据规模日益增长，产品一直迭代，BIGO 音讯流平台承载的数据规模呈现了成倍增长，上游的在线模型训练、在线举荐、实时数据分析、实时数仓等业务对音讯流平台的实时性和稳定性提出了更高的要求。开源的 Kafka 集群难以撑持海量数据处理场景，咱们须要投入更多的人力去保护多个 Kafka 集群，这样老本会越来越高，次要体现在以下几个方面： 数据存储和音讯队列服务绑定，集群扩缩容/分区平衡须要大量拷贝数据，造成集群性能降落。当分区正本不处于 ISR（同步）状态时，一旦有 broker 产生故障，可能会造成数据失落或该分区无奈提供读写服务。当 Kafka broker 磁盘故障/空间占用率过高时，须要进行人工干预。集群跨区域同步应用 KMM（Kafka Mirror Maker），性能和稳定性难以达到预期。在 catch-up 读场景下，容易呈现 PageCache 净化，造成读写性能降落。Kafka broker 上存储的 topic 分区数量无限，分区数越多，磁盘读写程序性越差，读写性能越低。Kafka 集群规模增长导致运维老本急剧增长，须要投入大量的人力进行日常运维；在 BIGO，扩容一台机器到 Kafka 集群并进行分区平衡，须要 0.5 人/天；缩容一台机器须要 1 人/天。如果持续应用 Kafka，老本会一直回升：扩缩容机器、减少运维人力。同时，随着业务规模增长，咱们对音讯零碎有了更高的要求：零碎要更稳固牢靠、便于程度扩大、提早低。为了进步音讯队列的实时性、稳定性和可靠性，升高运维老本，咱们开始思考是否要基于开源 Kafka 做本地化二次开发，或者看看社区中有没有更好的解决方案，来解决咱们在保护 Kafka 集群时遇到的问题。 为什么抉择 Pulsar2019 年 11 月，咱们开始调研音讯队列，比照以后支流音讯流平台的优缺点，并跟咱们的需要对接。在调研过程中，咱们发现 Apache Pulsar 是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体。Pulsar 可能无缝扩容、提早低、吞吐高，反对多租户和跨地区复制。最重要的是，Pulsar 存储、计算拆散的架构可能完满解决 Kafka 扩缩容的问题。Pulsar producer 把音讯发送给 broker，broker 通过 bookie client 写到第二层的存储 BookKeeper 上。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/ 放弃业务的连续性始终是技术团队工作的重点，进步可用性、缩小利用的宕机工夫、升高宕机老本必不可漠视。 如何在音讯零碎上升高宕机危险、进步服务高可用？Pulsar 具备高可用的个性，采纳云原生架构，可实现主动容错机制和故障隔离，可能在服务呈现故障时疾速迁徙或回滚。底层 broker 无状态，能够实现平滑迁徙。同时针对灾备计划，Pulsar 反对多机房跨区域复制和异地灾备计划，提供了基于云原生的高可用计划。 咱们为大家整顿了一些 Pulsar 跨城实际与高可用的博文与案例，期待为大家提供灾备计划的解决思路。 带你理解 Pulsar 里的跨机房复制 举荐理由：本文从根底入门，具体介绍了Pulsar 的 Geo Replication 跨机房复制的概念以及如何运行。 博文举荐 | Apache Pulsar 三大跨地区复制解决方案 举荐理由：Apache Pulsar 原生反对跨洲际级别的跨地区复制解决方案，本文介绍了全连通、单向复制、Failover 模式三种异步跨地区复制的计划。 跨地区复制系列(一)Apache Pulsar Pulsar的跨地区复制机制介绍 举荐理由：在大型的分布式系统中，都会波及到跨多个数据中心的需要，通常会应用跨地区复制机制提供额定的冗余避免服务无奈失常运作。本文将介绍 Apache Pulsar 中的跨地区复制的原理及其简略的设置应用办法。 跨地区复制系列(二)Apache Pulsar 的跨地区复制实际 举荐理由：本文将通过 docker-compose 的形式搭建一个跨三个集群的 Pulsar 环境，并在三个集群中演示 Pulsar 的跨地区复制。在本篇文章中，咱们用 step-by-step 的形式，详解在三个数据中心中搭建全联通的数据复制。 订阅状态的复制？跨机房同步下如何利用 举荐理由：在 Pulsar 里，能够基于 geo-replication 将数据在多个机房进行复制，这个个性次要是复制的音讯数据，而此篇文章着重分享的是订阅状态的跨机房同步。 跨城实际中，腾讯如何利用 Apache Pulsar 举荐理由：本文介绍腾讯计费场景下的跨城挑战与腾讯米巨匠抉择 Pulsar 的理由，并具体介绍了 Pulsar 的跨城能力及腾讯计费在跨城上的优化。 最佳实际｜放弃 Ceph，Salesforce 应用 Apache BookKeeper 在云中实现最强存储 举荐理由：应用私有云时，在节点、区域或地区层面都可能呈现不可用的状况。底层基础设施不可用。起因可能是某些机器、区域或地区呈现故障，也可能是由硬件故障引起的网络提早减少。所以最终当在私有云基础设施上运行应用程序时，开发人员在设计时须要思考由故障引发的问题。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 本文要点使存储系统感知云的传统形式是间接迁徙，这种形式体现良好，但从咱们的教训来看，重构云感知架构成果更好。目前，在跨区域环境中部署 Apache BookKeeper 时须要手动将存储节点映射到特定区域 / 可用性区域，但在区域中断时，持久性和可用性会受到影响。Salesforce 独有的使 Apache BookKeeper 感知云的办法是通过智能化存储节点，让其在云中部署能够无效运行，并保障持久性和可用性。这些办法简化了集群的改良、降级和重启操作，对生产服务的影响最低。在 Salesforce，咱们须要能够同时解决两种流的存储系统：一种流用来预写日志，另一种流用来解决数据。但对这两种流，咱们的要求互相矛盾：预写日志流的写入提早低，而读取吞吐量高；数据流的写入吞吐量高，但随机读取提早低。作为云计算的领军企业，咱们的存储系统必须具备云感知能力（可用性和持久性要求越来越高）。为了在商用硬件上运行并不便扩容，咱们无奈更改部署模型设计。 开源计划在对存储系统进行初步钻研后，咱们思考是本人搭建一套还是购买一套。 思考到整体规划和上市工夫、资源、老本等次要的业务驱动因素，咱们决定应用开源存储系统。 在查看了开源代码后，咱们有两个备选计划：Ceph 和 Apache BookKeeper。因为这套零碎须要对客户凋谢，可扩展性和一致性都很重要，零碎必须齐全满足用例的 CAP（Consistency：一致性；Availability：可用性；Partition Tolerance：分区容错性）要求以及咱们本人的非凡需要。首先，咱们来看一下 BookKeeper 和 Ceph 在 CAP 和其余方面的体现。 Ceph 能够保障一致性和分区容错，读取门路能够借助不牢靠读取提供可用性和分区容错；但要使写入门路保障可用性和分区容错性并不容易。并且，咱们不能更改部署数据。 咱们决定抉择 Apache BookKeeper。BookKeeper 反对仅追加 / 不可变数据存储，采纳高可复制的分布式日志，满足咱们对系统 CAP 的要求。BookKeeper 还具备以下特点： 已 Ack 的写入始终可读。已读 Entry 始终可读。无 Master 服务器，客户端应用 Apache ZooKeeper 实现共识（consensus）算法，获取元数据。数据布局无需简单的哈希 / 计算。Salesforce 也始终反对开源产品，Apache BookKeeper 社区踊跃沉闷，充满活力。 Apache BookKeeper——近乎完满，但还有改善空间Apache BookKeeper 简直实现了咱们对存储系统的全副要求，但仍需做一些工作。首先来看一下 Apache BookKeeper 能够实现咱们的哪些要求。 存储节点称为 Bookie；一组 Bookie 称为 Ensemble。写入的最小单元为 Entry，Entry 不可更改。一组 Entry 称为 Ledger，Ledger 仅可追加，不可更改。写入或复制 Bookie 的数量称为 Write Quorum——Entry 的最大正本数。确认写入前 Bookie 的数量称为 Ack quorum——Entry 的最小正本数。从持久性来看，Ledger 跨 Bookie Ensemble 复制，Ledger 内的 Entry 能够跨 Ensemble。 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/本文始发于 InfoQ，原文链接：https://www.infoq.cn/article/...金山云日志服务介绍金山云创建于 2012 年，是中国前三的互联网云服务商，2020 年 5 月在美国纳斯达克上市，业务范围遍布寰球多个国家和地区。成立 8 年以来，金山云始终保持以客户为核心的服务理念，提供平安、牢靠、稳固、高品质的云计算服务。 金山云曾经在北京、上海、广州、杭州、扬州、天津等国内地区，以及美国、俄罗斯、新加坡等国内区域设有绿色节能数据中心及经营机构。将来，金山云将继续立足外乡、放眼国内，通过构建寰球云计算网络，连通更多设施和人群，让云计算的价值惠及寰球。 金山云日志服务是针对日志类数据处理的一站式服务零碎，提供从日志采集、日志存储到日志检索剖析、实时生产、日志投递等多项服务，撑持着多个业务线的日志查问和监控业务，晋升金山云各个产品线的运维、经营效率，目前每天数据量级在 200 TB。 日志服务的性能个性作为针对日志类数据处理的一站式服务零碎，金山云日志服务须要具备以下个性： 数据采集：基于 Logstash 和 Filebeat 进行定制开发，反对更多数据采集状态。数据查问：反对 SQL 和 ElasticSearch Query String 语法。数据生产：基于 Pulsar 对外部 socket 进行封装，有些产品线（想在控制台展现日志滚动的场景）能够通过整个日志服务的 websocket 协定实现；也能够通过裸露的 REST API 查问全副日志数据（即作为队列来应用）。异样告警：在控制台检索数据后，把数据以及检索语法保留为告警项，反对配置整体的告警策略及告警形式。检索到异样后，后盾会通过启动相应的工作实现实时告警。图表展现：将在控制台检索的语句和查问后果保留为图表（柱状图、折线图等），再次进入控制台时，点击仪表盘即可看到以后或之前保留过的所有查问语句和后果数据。数据异构：能够自定义是否把日志投递到其余云端产品线中，比方将某几个日志的数据投递到对象存储中，从而实现一些其余操作（如把数据投递到 Hive 数仓，再进行剖析）。为什么抉择 Pulsar在调研过程中，咱们从根底性能和可靠性两方面比照了 RocketMQ、Kafka 和 Pulsar，并总结了三者的优缺点（比照后果见下表）。 咱们发现 Pulsar 非常适合利用于日志流解决。从 BookKeeper 层面来讲，Pulsar 就是日志流存储的组件。Pulsar 采纳云原生架构，日志流服务同样采纳云原生、无服务模式，所有服务都在云上实现。Pulsar 领有诸多灵便的企业级个性，比方反对多租户、反对租户存储配额、数据 ETL、整体数据负载平衡策略等；反对传输大量数据；针对音讯队列的监控比较完善等。上面我来具体介绍下咱们抉择 Pulsar 的一些个性。 计算与存储拆散Pulsar 的 producer 和 consumer 都与 broker 相连接，broker 作为无状态服务，能够横向扩缩容，扩缩容时不会影响数据的整体生产和生产；broker 不存储数据，数据存储在 broker 的下一层（即 bookie ）中，实现了计算与存储的拆散。 ...

对于 Apache Pulsar Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 GitHub 地址：http://github.com/apache/pulsar/我的项目背景介绍拉卡拉领取成立于 2005 年，是国内当先的第三方领取企业，致力于整合信息科技，服务线下实体，从领取切入，全维度为中小微商户的经营赋能。2011 年成为首批取得《领取业务许可证》企业的一员，2019 年上半年服务商户超过 2100 万家。2019 年 4 月 25 日，登陆创业板。 性能需要因为拉卡拉的项目组数量较多，各个我的项目在建设时，别离依据须要抉择了本人的音讯零碎。这就导致一方面很多零碎的业务逻辑和具体的音讯零碎之间存在耦合，为后续系统维护和降级带来麻烦；另一方面业务团队成员对音讯零碎的治理和应用程度存在差别，从而使得整体零碎服务质量和性能不稳固；此外，同时保护多套零碎，物理资源利用率和治理老本都比拟高。 因而，咱们打算建设一套分布式根底音讯平台，同时为各个团队提供服务。该平台须要具备以下个性：高牢靠、低耦合、租户隔离、易于程度扩大、易于经营保护、对立治理、按需申请应用，同时反对传统的音讯队列和流式队列。表 1 展现了这两类服务应该具备的个性。 为什么抉择 Apache Pulsar大厂开源背书当初可供用户抉择的大厂开源音讯平台有很多，架构设计大多相似，比方 Kafka 和 RocketMQ 都采纳存储与计算一体的架构，只有 Pulsar 采纳存储与计算拆散的多层架构。咱们比拟选型的音讯零碎有三个：Kafka、RocketMQ 和 Pulsar。测试之前，咱们通过网上的公开数据，对三者的性能和性能进行了简略的比照，表 2 为比照后果。从中能够看出 Pulsar 更合乎咱们的需要。 Pulsar 的架构劣势Pulsar 是云原生的分布式音讯流平台，源于 Yahoo!，反对 Yahoo! 利用，服务 140 万个 topic，日解决超过 1000 亿条音讯。2016 年 Yahoo! 开源 Pulsar 并将其捐献给 Apache 软件基金会，2018 年 Pulsar 成为 Apache 软件基金会的顶级我的项目。 作为一种高性能解决方案，Pulsar 具备以下个性：反对多租户，通过多租户可为每个租户独自设置认证机制、存储配额、隔离策略等；高吞吐、低提早、高容错；原生反对多集群部署，集群间反对无缝数据复制；高可扩大，可能撑持上百万个 topic；反对多语言客户端，如 Java、Go、Python、C++ 等；反对多种音讯订阅模式（独占、共享、灾备、Key_Shared）。 ...

北京工夫 10 月 12 日，云原生批流交融数据平台 StreamNative 发表取得 2300 万美元 A 轮融资，本轮融资由沙特阿美旗下多元化风投基金 Prosperity7 Ventures 与华泰证券旗下另类投资子公司华泰翻新联结领投，老股东红杉中国、源码资本持续加码。StreamNative 于 2020 年 8 月实现数百万美元 Pre-A 轮融资，源码资本领投、红杉中国种子基金跟投；2019 年团队创建初期取得红杉中国种子基金天使轮投资。 StreamNative 联结创始人兼 CEO 郭斯杰示意，本轮融资次要用于产品研发和团队人才招聘，加强 StreamNative 在音讯、流存储和流解决技术方向的投入，放慢产品服务迭代优化和客户增长。 云原生音讯流零碎 - Apache PulsarApache Pulsar 作为 Apache 软件基金会顶级我的项目，集音讯、存储和轻量计算为一体，是云原生时代的音讯流零碎。Apache Pulsar 始终保持疾速成长和沉闷，主仓库寰球贡献者已达 450 名，同比增长超过 45%，月度沉闷贡献者已比肩或超过 Apache Kafka，并上榜 ASF 2021 年度财报最沉闷 Commit 和 Clone 我的项目榜单。 Apache Pulsar 采纳存储计算拆散的云原生架构，人造反对大集群、多租户、百万级 Topic、跨地区数据复制和长久化存储、分层存储等企业级个性，并提供了对立的生产模型，反对音讯队列和流两种场景，既能为队列场景提供企业级读写服务质量和严格一致性保障，又能为流场景提供极高带宽。企业可借助 Apache Pulsar 打造对立的实时数据基础设施平台，突破数据隔离和数据孤岛，简化架构并升高运维复杂度。 目前 Apache Pulsar 已落地国内外数百家企业，如腾讯、百度、中国移动、中国电信、中国银联、安全证券、翼领取、拉卡拉、华为云、金山云、知乎、BIGO、达达团体、涂鸦智能等泛滥企业，笼罩金融证券、交易领取、直播与短视频、电商、物联网等泛滥行业。 勇担社区领导者，构建丰盛生态圈StreamNative 由 Apache Pulsar 开创团队组建而成，联结创始人郭斯杰、翟佳和 Matteo Merli 都是沉闷的 Pulsar PMC 成员和开源布道者，其中 Matteo 目前负责 Pulsar PMC 主席一职。团队已吸引泛滥 Pulsar 沉闷开发者退出，进一步加强了 StreamNative 作为社区领导者的角色和影响力。 ...

本文首发自 InfoQ 《辞别传统金融音讯架构：Apache Pulsar 在安全证券的实际》。作者：王东松，陈翔在金融场景中，随同着业务的扩大，利用零碎也相应地减少更多的场景，这些新场景对音讯零碎提出更多样的需要，导致原有架构面临一系列挑战。在尝试应用 Apache Pulsar 后，安全证券决定在生产环境中进行实际。本文介绍了安全证券抉择 Apache Pulsar 的起因，应用 Apache Pulsar 的场景，Apache Pulsar 实际利用中遇到的问题，以及应用 Apache Pulsar 的将来布局。 背景介绍传统金融公司或券商个别会应用对立接入服务或组件来解决对外业务。接管到用户申请后，依据相应的业务规定将申请转到对应业务零碎 / 模块。有些申请会转发给音讯队列，申请写入后，上游业务零碎从音讯队列中获取申请，并在解决后通过音讯队列原路返回给客户，整个申请过程关闭运行，性能无限。 音讯队列下传统架构带来的挑战安全证券采纳的就是上述的传统架构，目前只反对音讯队列。尽管咱们有肯定的开发能力，但也难以获取到该音讯队列的细节信息。同时，因为是定制开发的零碎，反对的语言比拟无限。现有的音讯队列对业务倒退和业务翻新等有以下有余： 黑盒零碎，难以观测：音讯队列是一个黑盒零碎，咱们难以观测到架构的细节；间接替换（Direct Exchange），无奈路由：因为架构目前只反对音讯队列，无奈反对须要路由的场景；弱校验接入，平安危险高：现有零碎的明码认证、校验等测验较弱，平安危险较高；定制零碎，无限语言反对：定制零碎接入语言的反对无限，导致咱们抉择范畴少，难以在原有零碎根底上进行改革。随着业务扩大和架构改良，公司现有的音讯队列零碎 / 组件面临着一系列挑战，而零碎存在的许多问题如安全性等在金融场景中迫不及待。 金融场景的业务需要咱们的业务需要次要分为三类：身份辨认 & 安全控制、路由散发、审计。 身份辨认 & 安全控制身份辨认次要用于确定接入音讯队列的客户端和接入者的身份信息，指定相应的平安规定，回绝不非法接入者，进而实现预期的平安要求。从最根底的层面看，须要辨认管制接入的零碎、IP，依据业务场景及特定需要，进行权限限度。 路由散发路由散发指音讯依据相应的规定由写入队列路由至对应的队列。现有的音讯队列反对的场景无限，若想要反对更多场景，须要投入大量的工夫和精力来进行开发（波及上下游零碎的革新），同时会引入其余问题。较好的解决方案是音讯队列零碎原生反对更多模式及个性，比方 TOPIC 模式、流式音讯解决。如果音讯队列零碎能够反对路由，那么零碎的接入复杂度就会大大降低，能够通过更优的形式对接入层进行操作，每个零碎只须要对接一组 topic，路由负责散发；也能够更有针对性地优化性能（路由、转发、协定转化都是耗费性能的操作）。 原有零碎架构通信机制是点对点，关闭运行，申请音讯无奈共享，只能间接采纳适配器或日志采集形式实现散发，此类做法难以无效满足实时性要求。 审计音讯的发布者 / 接收者都属于整个零碎的参与者，并且是重中之重。零碎安全性的次要影响因素就是零碎的所有参与者；因而，从平安角度登程，对音讯的审计要求绝对较高。另一项比拟急切的需要是对音讯流向进行管制。如果能够进行身份辨认和安全控制，则能够在审计时欠缺和优化平安信息，进而保障在业务入口处回绝有效、非法申请，保障外部零碎强壮。此外，记录接入的音讯发布者 / 接收者的信息还能够用于异常情况监控、稽核审计。 新增业务的零碎需要新增业务对音讯零碎提出了更高要求，次要包含可用性、音讯发送提早、扩缩容、音讯回溯等。 需要一：高可用、低提早对于互联网行业而言，高可用低提早是零碎的根本要求。从单点到灾备，到同城跨机房，再到异城跨多核心，或者是先跨城、灾备，再跨城多核心（两地三核心）的模式都曾经越来越常态化，很多公司的业务零碎正在或将会往这方向倒退。这样的系统对高可用、低提早的要求比拟高。因而须要思考当零碎复杂度减少（如灾备、跨城等场景）时，如何将提早降到最低。 需要二：疾速扩容与复原对于金融业而言，业务的次要个性之一是申请可能会在某个时间段或某个周期激增，过了这个工夫窗口后，流量逐步恢复正常。这一个性要求零碎能够疾速横向扩缩容，出于老本思考，依照最高流量部署整个零碎架构显然不合理。最好的解决方案是零碎能够依据单层流量合理安排零碎架构或零碎部署形式，在流量忽然减少时，零碎能够疾速扩容，撑持业务。最现实的状况是零碎的所有组件都有疾速扩缩容、恢复能力。 需要三：音讯有序、音讯防重在一些非凡业务场景中，须要保障音讯有序或防重。咱们常常对一些接口进行幂等操作，如果能够保障上游音讯不反复，就能够减小上游的压力。 需要四：可回溯、序列化如果业务零碎呈现问题，但在测试环境中难以复现这一问题，就须要引入音讯回溯。音讯回溯指重放一遍呈现问题的工夫窗口中的所有申请，验证是否能复现问题，并排查问题，这样能够大大加重排查问题的工作量。此外，咱们还能够借助这一性能进行灰度验证和并行验证。 抉择 Apache Pulsar基于上述业务需要和零碎需要，发现 Apache Pulsar 的诸多个性完满符合了咱们的需要。 集群模式，反对跨集群同步。建设零碎双活，跨集群的地区复制在客户端无感的状况下实现音讯同步。计算存储拆散。依据应用状况横向扩大存储 / 计算，客户端对此操作无感知。基于二级存储的性能，扩大音讯的应用场景，为数据分析、音讯审计提供可能。客户端接入认证模块插件化，反对自定义开发。因业务需要，在客户端接入时，要求鉴权、认证，无效保障音讯的起源牢靠、可控。欠缺的 Rest API，可查看队列状况。之前应用的音讯零碎有很好的性能，但在可观测性方面有所欠缺，给零碎排障造成艰难，同时音讯零碎的治理形式较为原始，难以适配大规模系统管理的要求。而 Apache Pulsar 欠缺的 Rest API 不仅能够获取零碎运行指标，且有助于集群的高效治理。基于 Functions 可实现音讯的路由开发、过滤和统计等。可设置音讯的长久化模式和过期工夫，容许音讯重放。多语言反对，疾速便捷接入。Apache Pulsar 在安全证券的业务场景安全证券应用 Apache Pulsar 构建对立音讯平台，冀望整合客户、交易、行情、资金四大数据流，利用于行情散发、实时风控等。本文次要介绍如何将 Apache Pulsar 利用于三个业务场景：申请路由、数据播送和音讯告诉，新架构的劣势和有余，以及其对开发、运维团队的影响。 ...

为推动国内开源生态产业倒退，中国开源云联盟（China Open Source Cloud League,简称“COSCL”）组织发展了 2021 卓越开源贡献者、优良开源我的项目、最佳开源实际案例、优良开源翻新企业评选活动。 Apache RocketMQ 胜利入选 2021 中国开源云联盟根底软件优良开源我的项目。 Apache RocketMQ 是由阿里巴巴开源的音讯产品，历经多年双十一流量洪峰严苛考验。2016 年 RocketMQ 进入 Apache 孵化器，并于 2017 年毕业成为 Apache 基金会顶级开源我的项目。同一年，RocketMQ 商业版上线阿里云并对外提供商业化产品服务，开始了开源、商业、阿里团体三位一体协同并进、对立内核的演进过程。 RocketMQ 始终致力于打造金融级高牢靠、高性能、低提早的消息中间件服务。RocketMQ 4.0 在金融级可用的极简架构、多正本能力、丰盛的音讯类型等方面有了长足的倒退和提高。目前，RocketMQ 寰球 Contributor 靠近 500 人，成立了包含内核、批、connect、streaming、多语言客户端、rocketmq-flink、operator、exporter等一系列兴趣小组；汇集了包含北京、深圳、苏州等多个城市的社区开发者，大量的翻新从社区中产生并且落地。从最近的几个版本来看，阿里以外的公司奉献的代码曾经超过 60%，越来越多的公司及开发者参加到 RocketMQ 奉献中来。 目前，寰球超过数万家企业都在应用 RocketMQ，不仅包含字节跳动、快手、小米、滴滴、同城艺龙等互联网头部企业，也有头部银行、券商、保险、基金公司等一系列对中间件要求极为严苛的金融公司。RocketMQ 经验过来几年的疾速倒退，曾经成长为微服务畛域业务音讯的首选。 随同着云原生时代的到来以及实时计算的衰亡， 生于云、长于云的 RocketMQ 5.0 应运而生，阿里云音讯队列 RocketMQ 全新降级为云原生音讯、事件、流交融解决平台 RocketMQ 5.0，帮忙用户更轻松地构建下一代事件驱动和流解决利用。

一、业务演进和规模 业务演进 京东在 2014 年基于 storm 打造了第一代流式解决平台，能够较好的满足业务对于数据处理实时性的要求。不过它有一些局限性，对于那些数据量特地大，然而对提早却不那么敏感的业务场景，显得有些力不从心。于是咱们在 2017 年引入了 Spark streaming，利用它的微批处理来应答这种业务场景。 随着业务的倒退和业务规模的扩充，咱们迫切需要一种兼具低提早和高吞吐能力，同时反对窗口计算、状态和恰好一次语义的计算引擎。 于是在 2018 年，咱们引入了 Flink，同时开始基于 K8s 进行实时计算容器化的降级革新； 到了 2019 年，咱们所有的实时计算工作都跑在 K8s 上了。同年咱们基于 Flink 1.8 打造了全新的 SQL 平台，不便业务开发实时计算利用； 到了 2020 年，基于 Flink 和 K8s 打造的全新实时计算平台曾经比较完善了，咱们进行了计算引擎的对立，同时反对智能诊断，来升高用户开发和运维利用的老本和难度。在过来，流解决是咱们关注的一个重点。同年，咱们也开始反对批处理，于是整个实时计算平台开始朝着批流一体的方向演进。 业务场景 京东 Flink 服务于京东外部十分多的业务线，次要利用场景包含实时数仓、实时大屏、实时举荐、实时报表、实时风控和实时监控，当然还有其余一些利用场景。总之，实时计算的业务需要，个别都会用 Flink 进行开发。 业务规模 目前咱们的 K8s 集群由 5000 多台机器组成，服务了京东外部 20 多个一级部门。目前在线的流计算工作数有 3000 多，流计算的解决峰值达到 5亿条每秒。 二、容器化实际 在 2017 年，京东外部的大多数工作还是 storm 工作，它们都是跑在物理机上的，同时还有一小部分的 Spark streaming 跑在 Yarn 上。不同的运行环境导致部署和运维的老本特地高，并且在资源利用上有肯定的节约，所以咱们迫切需要一个对立集群资源管理和调度零碎，来解决这个问题。 通过一系列的尝试、比照和优化，咱们抉择了 K8s。它不仅能够解决部署运维、资源利用的一些问题，还具备云原生弹性自愈、人造容器残缺隔离、更易扩大迁徙等长处。于是在 2018 年初，咱们开始进行容器化的降级革新。 在 2018 年的 6.18，咱们只有 20% 的工作跑在 K8s 上；到了 2019 年 2 月份，曾经实现了实时计算的所有工作都跑在 K8s 上。容器化后的实时计算平台经验了 6.18，双 11 屡次大促，扛住了洪峰压力，运行的十分稳固。 ...

10 月 23 日，Apache APISIX 社区联结 Apache SkyWalking 社区为大家带来线上分享，快来看看有哪些精彩的议题吧。 分享议题Apache APISIX 可观测性介绍分享嘉宾庄浩潮，Apache APISIX Contributor，Apache SkyWalking Committer & PMC 成员。 议题详情Apache APISIX 绝对原生 Nginx 有比较完善可观测性能力，将介绍 Apache APISIX 已有的监控伎俩和能力。以及与 Apache SkyWalking 集成之后，有哪些性能的加强，未来还会带哪些新个性。一起期待红蓝（APISIX X SkyWalking）组合能带来哪些火花。 利用 Apache SkyWalking Infra E2E 进行端到端测试分享嘉宾刘晗，Apache SkyWalking Committer & PMC 成员 议题详情当初越来越多的我的项目开始利用端到端测试来实现自动化性能检测，本次分享着重解说 SkyWalking-Infra-E2E 框架与其在 Apache SkyWalking 中的落地。 Apache APISIX Ingress Controller 如何在社区中成长分享嘉宾金卫，Apache APISIX PMC，Apache SkyWalking Committer 议题详情介绍 Apache APISIX Ingress Controller 我的项目退出 Apache 社区后带来新的生机Apache APISIX Ingress Controller 在社区中的运作形式欢送退出 Apache APISIX 社区License Eye - 开源软件协定利器分享嘉宾柯振旭，Apache SkyWalking PMC 成员，Apache 孵化器 PMC 成员和导师 ...

find命令是一个不便的工具，能够在零碎上查找文件。能够找到最近几天更改过的文件。这将是本教程的重点。文件的工夫戳类型Linux中文件带有以下工夫戳： atime: 显示上一次读取或拜访文件的工夫。amin: 显示上一次读取或拜访文件是多少分钟之前mtime: 显示文件或程序上一次批改文件的工夫。更改或批改文件内容时，mtime也会更改。“批改”是指将某些数据附加到文件中，局部或全副从新组织或删除。mmin: 显示几分钟内最初一次批改文件的工夫。ctime: 显示文件属性何时批改的应用-mtime选项在本节中，将重点介绍如何应用mtime选项搜寻工夫戳在肯定范畴内的文件。这列出了几天前拜访的文件。 例一：查找/var/log文件夹中，批改工夫大于90天被批改过的文件。 [root@localhost ~]# find /var/log -mtime +90 -print其中-mtime +90 加号示意大于前面的天数Find命令查找最近几天批改的文件Find命令查找最近几天批改的文件例二：查找/etc文件夹中，批改工夫小于10天的配置文件 [root@localhost ~]# find /etc -iname "conf" -mtime -10 -printFind命令查找最近几天批改的文件Find命令查找最近几天批改的文件其中-mtime -10 减号示意小于前面的天数例三：查找/etc文件夹中，前一天批改过的文件. [root@localhost ~]# find /etc -mtime 1 -print其中-mtime 1 示意昨天的这个工夫。Find命令查找最近几天批改的文件Find命令查找最近几天批改的文件以下几个罕用的工夫戳： -1 最近24小时-0.5 最近12小时-0.25 最近6小时+2 两天前应用-atime选项如前所述，atime是用于显示用户或应用程序最初一次拜访文件的工夫。让咱们看一些例子： 查找10天内拜访root根目录的文件： [root@localhost ~]# find /root -atime -10 -type f要查看20天前这个工夫点拜访的docx文件，请运行以下命令： [root@localhost ~]# find /root -iname "*.docx" -atime 20 -type -f应用-daystart选项-daystart 选项测量从当天开始而不是24小时之前开始的工夫。例如，要查找昨天编辑的所有pdf文件，请运行： [root@localhost ~]# find /root/data/ -mtime 1 -daystart -iname "*.pdf"要列出3-5天之前编辑的文件，请运行以下命令： ...

通常利用会通过身份认证辨认用户身份，并依据用户身份 ID 从身份提供方（Identity Provider）获取具体的用户元数据，并以此判断用户是否领有拜访指定资源的权限。身份认证模式分为两大类：传统认证模式和集中认证模式。 在传统认证模式下，各个应用服务须要独自反对身份认证，例如当用户未登录时拜访登录接口，接口返回 301 跳转页面。利用须要开发保护 Session 以及和身份提供商的认证交互等逻辑。传统认证模式的流程如下图所示：首先由用户发动申请（request），而后由网关接管申请并将其转发至对应的应用服务，最初由应用服务与身份提供方对接，实现身份认证（authorization）。与传统认证模式不同，集中身份认证模式把用户认证从应用服务中抽离了进去，以 Apache APISIX 为例，集中认证的流程如下图所示：首先由用户发动申请（request），而后由前置的网关负责用户认证流程，与身份提供方对接，向身份提供方发送身份认证（authorization）申请。身份提供方返回用户身份信息（user info）。网关实现用户身份辨认后，将用户身份信息通过申请头的模式转发至后端利用。相比拟传统认证模式，集中认证模式下有如下长处： 简化利用开发流程，升高开发利用工作量和保护老本，防止各个利用反复开发身份认证代码。进步业务的安全性，集中身份认证模式在网关层面可能及时拦挡未经身份认证的申请，爱护后端的利用。应用 Apache APISIX 配置 Okta 集中身份认证应用 Apache APISIX 配置 Okta 认证的过程非常简单，从传统身份认证模式切换到集中身份认证模式，只需四步即可实现。 前提条件已有 Okta 账号。 步骤一：配置 Okta登录你的 Okta 账号，并创立一个 Okta 利用，抉择 OIDC 登录模式以及 Web Application 利用类型。 设置登录和登出的跳转 URL。其中 “Sign-in redirect URIs” 为登录胜利容许跳转的链接地址，“Sign-out redirect URIs” 示意登出之后跳转的链接地址。在这个示例中，咱们将登录胜利跳转和登出之后跳转的链接地址都设置为 http://127.0.0.1:9080/。 实现设置当前，单击“Save”保留批改。拜访利用的 General 页面，获取以下配置，配置 Apache APISIX OpenID Connect 时须要提供这些信息：Client ID：OAuth client ID，即利用的 ID，与下文的 client_id 和 {YOUR_CLIENT_ID} 对应。Client secret：OAuth client secret，即利用密钥，与下文的 client_secret  和{YOUR_CLIENT_SECRET} 对应。Okta domain：利用应用的域名，与下文的 discovery  中的 {YOUR_ISSUER} 对应。步骤二：装置 Apache APISIX你能够通过源码包、Docker、Helm Chart 等多种形式来装置 Apache APISIX。 ...

此文档是笔记形式，没有具体整顿，仅供参考,目前社区版本是0.14.0，百度预编译公布版本是0.14.13doris装置部署及各种load形式 装置部署1.下载Doris的源码包及编译编译倡议应用官网提供的docker镜像进行编译 docker pull apache/incubator-doris:build-env-1.3.1具体能够参考官网：doris编译 cd /optwget https://dist.apache.org/repos/dist/dev/incubator/doris/0.12.0-rc03/apache-doris-0.12.0-incubating-src.tar.gz解压装置tar -zxvf apache-doris-0.12.0-incubating-src.tar.gzcd apache-doris-0.12.0-incubating-srcsh build.sh在 2.配置该节点的FE（Leader）cd output/femkdir doris-metamkdir logsh bin/start_fe.sh --daemon运行之后检查一下，是否有doris的进行，监听的端口，日志信息等等vi log/fe.log3.配置BE cd output/bemkdir storagemkdir log4.散发到所有须要装置的BE节点 scp -r output/be root@主机名：/ 5.装置mysql客户端1，从官网下载安装包（在Centos7上要下载 RH Linux 7 的安装包）https://dev.mysql.com/downloa...mysql-8.0.17-1.el7.x86_64.rpm-bundle.tar2，清理环境2.1 查看零碎是否曾经装置了mysql数据库rpm -qa | grep mysql2.2 将查问出的文件一一删除，如yum remove mysql-community-common-5.7.20-1.el6.x86_642.3 删除mysql的配置文件find / -name mysql2.4 删除配置文件rm -rf /var/lib/mysql2.5删除MariaDB文件rpm -pa | grep mariadb删除查找出的相干文件和目录，如yum -y remove mariadb-libs.x86_643，装置3.1解压tar -xf mysql-8.0.17-1.el7.x86_64.rpm-bundle.tar3.2装置yum install mysql-community-{client,common,devel,embedded,libs,server}-*期待装置胜利！4，配置4.1 启动mysqld服务，并设为开机主动启动。命令：systemctl start mysqld.service //这是centos7的命令systemctl enable mysqld.service4.2 通过如下命令能够在日志文件中找出明码：grep "password" /var/log/mysqld.log4.3依照日志文件中的明码，进入数据库mysql -uroot -p4.4设置明码（留神Mysql8明码设置规定必须是大小写字母+特殊符号+数字的类型）ALTER USER 'root'@'localhost' IDENTIFIED BY 'new password'; ...

在近日举办的 ApacheCon Asia 大会主题演讲上，Kyligence 联结创始人兼 CEO，Apache Kylin PMC 韩卿给大家带来了「From Open Source to Product，开源我的项目产品化的思考与实际」的演讲，分享了 Apache Kylin 的最新进展及将来布局，技术和产品思维的比照，以及如何通过产品思维去经营开源社区/我的项目等话题分享，想理解更多快往下看吧~ 以下为韩卿在大会的演讲实录 大家好！我是韩卿，非常高兴明天可能在 ApacheCon Asia 给大家分享。我记得上次加入 ApacheCon 是在 2016年的温哥华，过后 Apache Kylin 作为首个来自中国的顶级我的项目刚刚毕业，咱们在 ApacheCon 上进行了分享，也参加到了国内社区中。在过来的五年中，咱们看到很多来自中国的我的项目，一直进入孵化器，而后毕业成为顶级我的项目，整个社区咱们的声音也越来越多，我很快乐看到，来自华人的力量、技术及内容越来越多地在寰球开源社区里进行发声。 我置信明天有十分多的同学会带来开源文化、社区经营、技术等话题分享，我想从另外一个角度，也就是产品的角度，给大家分享一些咱们的教训和认识，即如何用产品思维去经营一个开源我的项目。明天的分享次要是以下三局部： Apache Kylin 的简介及将来布局开源我的项目中的技术 VS 产品如何通过产品思维经营开源社区/我的项目Apache Kylin 的简介及将来布局 Apache Kylin 是在 2014 年从 eBay 中国研发核心奉献到了 ASF，成为了孵化器我的项目，在2015年的12月，Apache Kylin 毕业成为了顶级我的项目，这也是第一个来自中国的顶级我的项目。IPMC 的 VP Ted Dunning 也过后给了咱们十分高的评估，他说 Apache Kylin 代表了中国以及亚洲国家在国内开源社区里的奉献和参加。 Apache Kylin 诞生几年来，曾经播种了超过 1500 多家客户，寰球客户从咱们的老东家 eBay，包含 Cisco、Walmart、Apple、Amazon、Microsoft，以及欧洲的 OLX Group 等；同时也有十分多的国内客户，规模以上的互联网公司很多都将 Apache Kylin 作为他们在整个大数据分析外面不可或缺的一个组件，咱们也非常高兴看到越来越多社区敌人为 Apache Kylin 的演进与迭代继续做出了奉献。 ...

前言笔者近日在做一个基于 Calcite 的自定义 SQL 解析框架，须要理解 Calcite，但因为当初网上Calcite 材料极少，有价值的更是寥寥无几，因而只能本人 debug 源码。Calcite 是一个比较复杂的框架，因而本篇内容集中在当中的一个小但重要的阶段：SQL 优化。限于篇幅，本篇只谈 HepPlanner 的优化流程，有任何问题欢送评论交换。 HepPlannerHepPlanner 是一个启发式的优化器，基于非常简单的思维：即遍历匹配 RelOptRule 和 RelNode ，匹配胜利则进行优化。HepPlanner 的优化流程大体能够分为两步： 初始化 HepPlanner；调用 HepPlanner 的 findBestExp() 执行真正的优化流程，而优化流程也是一个非常复杂的逻辑，能够细分为以下三步： 遍历：启动一个双层的 for 循环去遍历 RelOptRule 和 RelNode ；匹配：在遍历过程中对 RelOptRule 和 RelNode 尝试进行匹配；优化：当匹配胜利后执行 RelOptRule 的 onMatch 进行优化。初始化初始化 HepPlanner 有两步十分重要：注入优化规定（RelOptRule）以及注入需优化的 RelNode root。 注入优化规定（RelOptRule）：HepPlanner 会将注入的 RelOptRule 包装成 HepInstruction，具体的类型为 HepInstruction.RuleInstance，在 HepPlanner 中，HepInstruction 才是执行单位。 注入需优化的 RelNode root：RelNode 是关系代数表达式的一种形象构造，因而与关系表达式类似是一种相似树的构造（组合模式的利用），HepPlanner 会依据这个特点将其转换成一个有向无环图 DirectedGraph，图上的每个节点都是一个 RelNode，但这个 RelNode 不是原来的 RelNode，而是 RelNode 的另一个实现类 HepRelVertex，HepRelVertex 有一个成员变量 currentRel 指向它包装的 RelNode。 ...

The Apache Way对于我而言，就是利他主义 ———栾小凡 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会已于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对 Zilliz 合伙人栾小凡的访谈。 以下为 SegmentFault 思否对栾小凡的访谈内容： 对于栾小凡栾小凡，Zilliz 合伙人、工程总监，LF AI & Data基金会技术咨询委员成员。他先后任职于 Oracle 美国总部、软件定义存储守业公司 Hedvig 、阿里云数据库团队，曾负责阿里云开源 HBase 和自研 NoSQL 数据库 Lindorm 的研发工作。栾小凡领有康奈尔大学计算机工程硕士学位。 ...

我认为开源在很大水平上扭转了传统的软件生态，为均衡生态中各种不同参与者的利益带来了可能性。 ———顾钧 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对 Zilliz 合伙人顾钧的访谈。 以下为 SegmentFault 思否对顾钧的访谈内容： 对于顾钧顾钧，Zilliz 合伙人、开源布道师，LF AI & Data 基金会技术咨询委员会成员。从业 17 年以来，他专一于数据库和大数据技术，先后任职于工商银行、IBM、摩根士丹利、华为等企业。顾钧领有北京大学计算机系学士学位。 ...

社区始于连贯，也成就于连贯 ———陈焱山 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对中国移动云能力核心 Iaas 产品部软件开发工程师陈焱山的访谈。 以下为 SegmentFault 思否对陈焱山的访谈内容： 对于陈焱山陈焱山，以后就任于中国移动云能力核心IaaS产品部。始终从事分布式存储软件架构设计及开发工作，深度参加了挪动云的建设倒退过程。在分布式存储畛域领有丰盛的开发实战经验，目前挪动云曾经为全网用户提供EB级规模存储。集体以后次要关注于对象存储交付编排及流量治理建设，正在思考基于 Apache APISIX 七层网关实现对象存储流量治理工作，实现架构进一步降级。 陈焱山首次接触开源的故事说来也偶合，本人跟Apache也是有缘，第一次接触开源也是Apache下的我的项目Hadoop和HBase我的项目，过后也是采纳HBase作为咱们对象存储产品的元数据存储引擎。 过后咱们的对象存储EOS还处在第一代自研中，其中就采纳了基于NoSQL数据库HBase来实现元数据的列式KV存储，在计算服务方面则采纳MapReduce。期间我次要负责元数据存储引擎的开发及优化工作。与此同时，咱们还保护着一个300多节点的线上集群。随着用户业务量的减少，零碎也呈现了一些问题，其中对我来说印象最为粗浅的就是频繁写删场景下HBase元数据逐步成为零碎拜访瓶颈的问题。因为Hbase默认采纳字典序，因此当向同一个对象存储桶中频繁写入或删除时对象时，后盾承载的这个Region所在的HRegionServer节点就会呈现读写访问热点问题，频繁执行Major Compact或者Region Split操作，然而这些后盾动作不仅要耗费大量的主机资源，同时还会阻塞IO申请，间接影响到用户服务。最显著的感触就是均匀时延飙升，甚至呈现申请响应超时。为了解决这个性能瓶颈，咱们通过对元数据Key的Hash化革新和HRegion数量的预布局调配，最终解决了HRegionServer的热点问题，零碎读写性能晋升了80%。尽管说起初随着工夫的推移，咱们产品技术栈进行了切换，然而钻研HDFS和HBase这段教训，至今都让我受害，同时也让我对开源文化有了一个新的意识。 ...

器重社区建设，器重每一位贡献者和参与者，社区永远大于代码，好的社区能够使得我的项目更加优质。 ———张超 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对 Apache APISIX PMC 张超的访谈。 以下为 SegmentFault 思否对张超的访谈内容： 对于张超大家好，我是张超，当初就任于深圳干流科技有限公司，次要负责公司的服务网格和 Cloud 产品；我是 Apache APISIX 的 PMC，也是开源爱好者，为 OpenResty 和 ingress-nginx 等我的项目做过奉献。 ...

Open, collaboration and Win-win. ———程力 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对腾讯云高级工程师程力的访谈。 以下为 SegmentFault 思否对程力的访谈内容： 对于程力我是Apache Ozone社区PMC，Hadoop社区Committer，目前在腾讯云对象存储团队工作。已经在AWS S3，华为存储等团队工作过。 程力首次接触开源的故事第一次大规模的投入开源是2019年，hadoop孵化对象存储我的项目Ozone，作为一个开源新人，投入Ozone我的项目中，追随我的项目一起成长，主导设计交付了MultiRaft，SCM HA等重大个性后，在社区中负责了更重要的角色，同时也随同了Ozone成为了Apache顶级我的项目。 在参加开源并且为 Apache 社区做奉献的时候，集体及公司有哪些播种？首先从加入Apache开源社区开始，我集体自身的代码标准，代码品质，到与社区成员单干沟通，独特合作的能力都有了显著的增长。更了解了开源社区，单干凋谢共赢的意义，同时随同着Ozone我的项目成为Apache顶级我的项目和腾讯公司的在Hadoop和Ozone我的项目上的继续投入，在公司内外部的大数据我的项目中，也交付了一些内外部的客户应用场景，利用Ozone这个存储我的项目，帮忙腾讯公司在私有化高密度存储设备的应用上找到了解决方案，实现了内部客户的理论价值。 ...

简略概括一下我所了解的“ The Apache Way”就是社区、凋谢、酷爱和继续。 ———孟浩然 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对 Apache ShardingSphere Committer 孟浩然的访谈。 以下为 SegmentFault 思否对孟浩然的访谈内容： 对于孟浩然大家好，我是孟浩然，SphereEx 高级 java 工程师，Apache ShardingSphere Committer。曾就任京东科技，负责数据库产品研发，酷爱开源，关注数据库生态，目前负责 Apache ShardingSphere 分布式数据库中间件的研发以及开源社区建设。 ...

在社区这个海量的宝库中，咱们首先享受到了开源我的项目的成绩，极大地晋升了开发效率，使咱们不用再走弯路、不用再反复造轮子，可能更快地后退。 ———李磊 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对 Apache brpc committer 李磊的访谈。 以下为 SegmentFault 思否对李磊的访谈内容： 对于李磊大家好，我是李磊，毕业于西安交通大学，目前在字节跳动任职基础架构工程师，从事图数据库、分布式KV的研发工作，是Apache brpc(Incubating) 的committer。 李磊首次接触开源的故事首次接触开源是刚工作的时候，那时应用Apache Hadoop中的MapReduce实现离线作业。过后为了优化作业运行工夫，我将一个MapReduce作业优化为了MapOnly的工作，但也是此时遇到了一些问题。当一台机器上的Mapper工作曾经执行实现后，可怜该机器宕机了，之前曾经实现的Mapper工作会被从新执行。而对于MapOnly的工作，其实是不须要再从新执行的，因而这里有很大的优化空间。在一位Hadoop contributor共事的领导下，我实现了对这个问题的修复，并奉献到了社区。 ...

DHCP（动静主机配置协定）用于主动为PC和其余网络设备调配IP地址，以便它们进行通信。它应用UDP协定的67端口，对客户端应用UDP端口68。DHCP操作分为四个阶段：服务器发现，IP租约报价，IP租约申请和IP租约确认。这些阶段通常缩写为DORA，用于发现，提供，申请和确认。零碎环境Centos8 装置DHCPDHCP服务器的地址为：192.168.43.254/24,默认网关为：192.168.43.2/24,DHCP服务器将主动为网络192.168.43.0/24中的其余设施调配IP地址。 上面是DHCP服务器的地址信息： [root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens160 Centos8 如何配置DHCP服务器Centos8 如何配置DHCP服务器上面装置DHCP服务： [root@localhost ~]# dnf -y install dhcp-serverCentos8 如何配置DHCP服务器Centos8 如何配置DHCP服务器 配置DHCP服务DHCP服务器的次要配置文件是/etc/dhcp/dhcpd.conf。默认状况下，文件外面只有正文，提醒能够参考/usr/share/doc/dhcp-server/dhcpd.conf.example文件来批改配置。Centos8 如何配置DHCP服务器Centos8 如何配置DHCP服务器上面间接提供配置信息，将配置信息粘贴到dhcpd.conf文件外面，批改地址等信息即可： [root@localhost ~]# cat /etc/dhcp/dhcpd.conf DHCP Server Configuration file.see /usr/share/doc/dhcp-server/dhcpd.conf.examplesee dhcpd.conf(5) man pagedefault-lease-time 600;max-lease-time 7200;ddns-update-style none;authoritative;subnet 192.168.43.0 netmask 255.255.255.0 { range 192.168.43.101 192.168.43.200; option routers 192.168.43.2; option subnet-mask 255.255.255.0; option domain-name-servers 192.168.43.2; }Centos8 如何配置DHCP服务器Centos8 如何配置DHCP服务器 default-lease-time为特定设施保留10分钟（600秒）的IP地址 max-lease-time 最多保留2小时（7200秒）的IP地址。 subnet局部定义了192.168.43.0/24网络的DHCP配置。 range局部定义了可调配的IP地址，范畴为192.168.43.101-192.168.43.200。 routers局部定义默认网关的地址。 subnet-mask局部定义将调配给每个主机的子网掩码。 domain-name-servers局部定义将调配给每个主机的DNS服务器地址。配置实现之后能够应用上面命令启动dhcp服务： [root@localhost ~]# systemctl enable dhcpd && systemctl start dhcpdCreated symlink /etc/systemd/system/multi-user.target.wants/dhcpd.service → /usr/lib/systemd/system/dhcpd.service.Centos8 如何配置DHCP服务器Centos8 如何配置DHCP服务器上面查看服务是否运行： ...

我认为 The Apache Way 是一种生存和工作的形式。一群气味相投的人，依照大家都认可的形式去经营项目和社区，实现独特的指标。 ———吴伟杰 ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否将采访局部 Track Chair 或大会讲师，让你理解大会筹备的背地，和这些专家大牛们的故事。 明天，咱们为大家带来的是，咱们对Apache ShardingSphere committer，Apache ShardingSphere ElasticJob 外围开发者吴伟杰的访谈。 以下为 SegmentFault 思否对吴伟杰的访谈内容： 对于吴伟杰大家好，我是吴伟杰，Apache ShardingSphere committer，Apache ShardingSphere ElasticJob 外围开发者。目前为 SphereEx 中间件研发工程师，次要参加 Apache ShardingSphere 及 ElasticJob 的研发。 ...

The Apache Way 是一种参照，但咱们还是要走出本人的不同凡响的 My Way。———潘娟ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 为了让大家进一步理解开源、理解 ApacheCon Asia，SegmentFault 思否特地采访了中国惟一的一位女性 Apache Member ——潘娟。 以下为 SegmentFault 思否对潘娟的访谈内容： 请您依据您在开源社区的身份、您工作的单位还有其余一些方面来做个简略的自我介绍。 我在开源的身份是中国惟一的一位女性 Apache member ，是ShardingSphere 我的项目的 PMC，也是 Apache brpc 的 mentor。工作方面的话是 SphereEx 的 co-founder ， SphereEx作为开源 infra 商业科技型公司，欢送酷爱开源，关注分布式数据库/中间件/治理的同学退出! ...

引言随着越来越多的企业开启数字化转型，大数据行业失去了前所未有的疾速倒退，大数据的凋敝给大数据生态的各技术也带来了前所未有的时机与挑战。谈到大数据技术，我置信大家肯定对 Apache 不会生疏，大数据开源技术绝大多数是来自 Apache 基金会, 明天我先给大家介绍 Apache 年度盛会 - ApacheCon  ApacheCon @ 官网寰球系列大会      ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会，每年举办一次。作为久负盛名的开源盛宴，是开源界最具期待的大会之一。 自 1998 年停办以来，ApacheCon 曾经吸引了超过 350 个技术我的项目和不同社区参加其中，汇聚海内外的业内专家与老师，分享寰球最新的技术动静与实际，独特探讨 "今天的技术"，让宽广的技术爱好者们看到各技术前沿，有哪些最新趋势和停顿，更好的降级本人的技术栈。 但，但 ApacheCon 以往十多年都在海内举办，往年是组委会首次针对亚太地区举办 ApacheCon 在线大会：ApacheCon Asia。Asia 大会将来自中国、日本、印度、美国等海内外的 140+ 议题分为大数据、Incubator、API / 微服务、中间件、工作流和数据治理、数据可视化、可观测性、流解决、音讯零碎、物联网和工业物联网、集成、开源社区/文化、Web Server/Tomcat 等 14 个论坛。 参加 2021 年 8 月 6 日 - 8 日的 Asia 大会，您将取得： ·寰球最新的技术动静与实际分享 ·与海内外 200+ 名顶级专家交换机会 ·3 天盛会，140+ 场议题，全程收费加入 流动官网： https://www.apachecon.com/aca... 大会议程详情： https://apachecon.com/acasia2... 对于 Big Data 论坛Big Data 是 Apache 最重要的主题之一。往年大数据场也异样冷落，涵盖我的项目包含 Arrow、Atlas、Bigtop、CarbonData、Cassandra、DolphinScheduler、Doris(孵化中)、Druid、Flink、Hadoop、HBase、Hive、HUDI、Impla、Kylin、Kyuubi(孵化中)、Liminal(孵化中)、Nemo、Pinot、Pulsar、Spark、YuniKorn(孵化中)等顶级我的项目或正在孵化中的我的项目，以及现下较为炽热的 Milvus、openLooKeng 等开源我的项目。在本次 3 天盛会中，大家均能理解这些技术的前沿趋势和来自一线用户的实践经验、原理、架构剖析等精彩内容。 出品人 因为大数据技术太过火热，排满 3 天议程，明天咱们将为您具体解读第一天的海内外的各位技术大咖们。 ...

ApacheCon 是 Apache 软件基金会（ASF）的官网寰球系列大会。作为久负盛名的开源盛宴，ApacheCon 在开源界备受关注，也是开源静止晚期的出名流动之一。 早在 1998 年，在 ASF 成立之前，ApacheCon 曾经吸引了各个档次的参与者，在 300 多个 Apache 我的项目及其不同的社区中摸索 "今天的技术"。也是在这一届上，开发 HTTPD 服务的开发者们欢聚一堂，并决定成立 Apache 软件基金会。 First event was held in San Francisco, CA, October 1998 (the ASF incorporated ~6 months later). ApacheCon 每年举办一次，个别在欧洲或北美举办，是 Apache 开发者们线下交换、探讨、见面的绝佳机会，也是分享想法、思维激荡的难得的场合。通过入手实作、主题演讲、理论案例钻研、培训、黑客松流动等形式，展现 Apache 我的项目的最新倒退和新兴翻新。 往年，为了更好地服务于亚太快速增长的 Apache 用户和贡献者，ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，首次针对亚太地区时区的 ApacheCon 在线会议 ApacheCon Asia 大会将于 2021 年 8 月 6 日至 8 日在线举办。 当初就请大家追随我，一起来看看在往年的主题演讲环节，将会有哪些精彩出现！ Sharan Foga - Apache 基金会董事 Sharan Foga 从 2008 年起就退出到 Apache 基金会中，并曾在多个大会上讲演“The Apache Way”来流传 Apache 的理念和精力。她十分喜爱积极参与开源社区治理我的项目。她是 Apache Kibble 我的项目的 VP，也是多个 Apache 我的项目的 PMC 成员，包含 Apache Community Development，Apache OfBiz 和 Apache Training（Incubating）。她讲演的题目是“Welcome Diversity”（拥抱多样性）。 ...