云原生消息流系统 Apache Pulsar 在腾讯云的大规模生产实践

导语

由 InfoQ 主办的 Qcon 全球软件开发者大会北京站上周已精彩落幕，腾讯云中间件团队的冉小龙参与了《云原生机构设计与音视频技术应用》专题，带来了以《云原生消息流系统 Apache Pulsar 在腾讯云的大规模生产实践》为主题的精彩演讲，在本篇内容中，将重点围绕腾讯云近期在 Apache Pulsar 稳定性和性能方面优化的工作展开介绍，为开发者提供参考。

作者简介

冉小龙

腾讯云高级研发工程师

Apache Pulsar committer

RoP maintainer

Apache Pulsar Go Client、Pulsarctl 与 Go Functions 作者与主要维护者

Apache Pulsar 作为云原生时代消息流系统，采用存储计算分离架构，支持大集群、多租户、百万级 Topic、跨地域数据复制、持久化存储、分层存储、高可扩展性等企业级和金融级功能。Apache Pulsar 提供了统一的消费模型，支持消息队列和流两种场景，既能为队列场景提供企业级读写服务质量和强一致性保障，又能为流场景提供高吞吐、低延迟。

Apache Pulsar 在腾讯云中已经得到大规模的生产实践，在过去一年中承接了诸多行业生态中不同的使用场景。在实际的生产实践中，腾讯云针对 Apache Pulsar 做了一系列的性能优化和稳定性功能方面的工作，来保障用户在不同的场景下系统的稳定高效的运行。本文围绕腾讯云近一年在 Pulsar 稳定性和性能方面优化最佳实践。

Pulsar 在腾讯云百万级 Topic 上的应用

为什么选择在生产环境中使用 Pulsar？

此前该用户使用 Kafka 集群来承载业务，由于业务的特定场景，集群的整体流量相对不大，但是需要使用的 Topic 较多。此前使用 Kafka 集群时，由于 Kafka 自身架构的限定，用户不能在一套集群中创建较多的 Topic，所以为了满足业务多 Topic 的使用场景，需要部署多套 Kafka 集群来满足业务的使用，导致业务使用的成本较大。

Pulsar 本身除了具备 Pub-Sub 的传统 MQ 功能外，其底层架构计算存储分离，在存储层分层分片，可以很容易地把 BookKeeper 中的数据 offload 到廉价存储上。Pulsar Functions 是 Serverless 的轻量化计算框架，为用户提供了 Topic 之间中转的能力。在开源之前，Pulsar 已在 Yahoo! 的生产环境中经历 5 年的打磨，并且可以轻松扩缩容，支撑多 Topic 场景。为了降低使用的成本，同时满足多 Topic 的业务场景，该用户切换到了 Pulsar 的集群上。

当前该用户的一套 Pulsar 集群可以承载 60W 左右的 Topic，在很好地满足了业务使用的场景的同时降低了使用成本。

Apache Pulsar 稳定性优化实践

实践 1：消息空洞的影响及规避措施

使用 Shared 订阅模式或单条 Ack 消息模型时，用户经常会遇到 Ack 空洞的情况。Pulsar 中单独抽象出了 individuallyDeletedMessages 集合来记录空洞消息的情况。该集合是开闭区间集合，开区间表明消息是空洞消息，闭区间表明消息已被处理。早期 Pulsar 支持单条 Ack 和批量 Ack 两种模型，后者对标 Kafka 的 Ack Offset。引入单条 Ack 模型主要针对在线业务场景，但也因此带来了 Ack 空洞问题。Ack 空洞即下图中 `individuallyDeletedMessage` 所展示的集合。

如何理解 individuallyDeletedMessage？以下图为例：

在这里插入图片描述

该记录中第一个 Ledger id 是 5:1280，该集合是闭区间，说明消息已经被 Ack；之后的 5:1281 是开区间，说明消息没有被 Ack。这里就用开闭区间的形式来区分消息是否被 Ack。

Ack 空洞的出现原因可能因为 Broker 处理失败，源于早期版本的设计缺陷，Ack 处理没有返回值。在 2.8.0 及以上版本中，对事务消息支持上引入了 AckResponse 概念，支持返回值。因此在早期版本中，调用 Ack 后无法确保 Broker 可以正确处理 Ack 请求。第二个原因可能因为客户端出于各种原因没有调用 Ack，在生产实践中出现较多。

为了规避 Ack 空洞，一种方法是精确计算 Backlog Size。因为在 Broker 上解析 Batch 消息会浪费性能，在 Pulsar 中对 Batch 消息的解析在消费者侧，因此一个 Entry 可能是单条消息也可能是 Batch 消息的。后者情况下 Batch 内的消息数量或形态是未知的。为此要精确计算 Backlog Size，但经过调研发现这种方法的复杂性和难度较大。

另一种方法是 Broker 的主动补偿策略。因为 individuallyDeletedMessage 存储在每一个 ManagedCursor，也就是每一个订阅对象到 Broker 实际类中的映射。每一个订阅都可以拿到对应的 individuallyDeletedMessage 集合，Broker 就可以主动把集合推送到客户端，也就是主动补偿。

接下来我们了解一下 Broker 主动补偿机制，即 Backlog 策略。在了解补偿机制之前，先要了解 Topic 可能的分布与构成。
在这里插入图片描述
正常来说，生产者向 Topic 发布消息，消费者从 Topic 接收消息。如上图，红、灰、蓝色代表消息在 Topic 中的三种形态。Pulsar 中引入了 Backlog 策略，用来描述生产者和消费者之间的 Gap。该策略提供了三种选项，包括 Producer Exception、Producer Request Hold 和 Consumer Backlog Eviction。

其中，Producer Exception 相对用户友好，在生产环境中更加常用。当消息堆积到一定程度，消费者处理消息的能力不足时，Producer Exception 会通知生产者出现了问题。Producer Request Hold 原理相同，但是 Producer Request Hold 只是会让生产者停止发送，而不会告知其原因（即不会向业务侧返回标识），用户感知为 Producer 停止发送消息但是无异常抛出。而 Consumer Backlog Eviction 则会自动丢弃最早的消息来保证消息持续处理，可能导致丢消息的情况出现。
在这里插入图片描述
此外，还需要注意的是 Pulsar 计算 Backlog Size 的方式。上图可以理解为一个事件流，生产者源源不断地 append message。Pulsar 计算 Backlog Size 时，是计算从当前 MarkedDeletedPosition 的位置，到 ReadPosition 的位置之前的 Backlog Size，而后结合 Producer Exception 策略暴露出来。如果 Ack 空洞，比如 Broker 侧请求失败，或者客户代码产生异常导致 Ack 永远不会被调用，Backlog Size 会到达一定速率，就相当于限制生产者。上图中，M4 和 M2 是两条空洞消息，出现这样的空洞消息时，生产者的发送流就迟早会被打断。
在这里插入图片描述
Broker 主动补偿机制的实现方式如上图。由于 individuallyDeletedMessage 记录了所有消息的 Ack 成功与否的状态，就可以从中获取 MarkedDeletedPosition 位置的消息，开启一个 Executor Service 定时任务，设置监听频率，间隔一段时间将消息重新推送到客户端侧，实现 Broker 的主动补偿，避免 Ack 空洞导致 Producer Exception 被频繁触发。

实践 2：再谈 TTL、Backlog 及 Retention 策略

我们先看下这三个概念：

  • TTL：表示消息在指定时间内没有被用户 Ack 时会在 Broker 主动 Ack。

  • Backlog ：表示生产者发送的消息与消费者接收消息之间的差距。

  • Retention：表示当消息被 Ack 之后，继续在 Bookie 侧保留多久的时间，以 Ledger 为最小操作单元。

如果 TTL 和 Retention 同时设置，那么一条消息的生命周期该如何计算？来看以下代码：

void updateCursor (ManagedCursor Impl cursor, PositionImpl newPosition) tPair<PositionImpl, PositionImpl> pair = cursors.cursorUpdated (cursor, newPosition);if (pair == nulL) {Cursor has been removed in the meantimetrimConsumedLedgersInBackground();return;}PositionImplpreviousSlowestReader = pair.getLeftO);PositionImpl currentSlowestReader = pair.getRightO);if (previousSlowestReader.compareTo(currentSlowestReader)==0){// The slowest consumer has not changed position. Nothing to do right nowreturn;}//Only trigger a trimming when switching to the next Ledgerif (previousSlowestReader.getLedgerId() != newPosition.getLedgerId0)) ftrimConsumedLedgersInBackground();}

  • TTL：根据设置的时间（默认五分钟）定期检查，根据触发的策略不断更新 cursor 位置，处理消息过期。

  • Retention：检查 Ledger 的创建时间（通过元数据时间戳可以了解 Ledger 的生命周期）以及 Entry 的大小两个阈值来决定是否删除某一个 Ledger。

在以上代码中的最后三行中，将之前最慢的 LedgerId 与 newPosition 的 LedgerId 对比，检查 ManagedLedger 是否发生过切换，一旦切换就调用 trimConsumedLedgersInBackground()。该函数方法的核心代码策略就是 Retention 的逻辑。

由此可知：

  • 当 TTL 时间小于 Retention 时间时，消息的完整生命周期就是 TTL 时间 + Retention 时间；

  • 当 TTL 时间大于等于 Retention 时间，消息的生命周期就是 TTL 时间。

这里又引出了一个新问题：TTL 策略为什么要选择在 Ledger 切换的时机来触发 Ledger 的删除操作呢？因为 Retention 删除 Ledger 时是以 Ledger 为最小操作单元。如果 Ledger 不切换，Retention 也不会触发删除。所以上述代码逻辑会选择切换时机来交给 Retention 执行删除动作。

实践 3：延迟消息与 TTL 的关系

在团队曾经遇到的场景中，某用户发送了数十万延迟消息，延迟设置为十天，但 TTL 过期时间设置为五天，五天后所有延迟消息都已被过期。我们可以从源码层面看一下 TTL 策略。

public boolean expireMessages(int messageTTLInSeconds) {if (expirationCheckInProgressUpdater.compareAndSet( obj: this, FALSE, TRUE)) {log.info("[{}][{}] Starting message expiry check, ttl= {} seconds", topicName, subName,messageTTLInSeconds);cursor.asyncFindNewestMatching(ManagedCursor.FindPositionConstraint.SearchActiveEntries, entry -> {try {long entryTimestamp = Commands.getEntryTimestamp(entry.getDataBuffer());return Messaqelmpl.isEntryExpired(messageTTLInSeconds. entryTimestamp);} catch (Exception e) {log.error("[{}][{}] Error deserializing message for expiry check", topicName, subName, e);} finally {entry<release();}return false;}, callback: this, ctx: null);return true;

public static boolean isEntryExpired(int messageTTLInSeconds, long entryTimestamp) {return messageTTLInSeconds != 0&& (System.currentTimeMillis() >entryTimestamp + TimeUnit.SECONDS.toMillis(messageTTLInSeconds));
}

TTL 的核心逻辑是通过 cursor 传入的值决定消息是否过期，即是否能找到 Entry。TTL 只获取了消息的发布时间，却没有理会消息的延迟设置。结合上面两段代码，isEntryExpired 只关心 PublishedTime 时间戳元数据属性，FindNewestMatchingEntry 对象时可以从元数据中获取 PublishedTime。所以当延迟设置小于 TTL 时间就会导致延迟消息被过期，在用户侧就会发现消息丢失。

针对这一问题，腾讯团队向社区提供了 PR，主要逻辑是分别检查消息的发布时间和延迟时间，到达发布时间后如果延迟时间大于 TTL 时间，则 TTL 时间到达后依然不能过期消息。IsEntryExpired 会判断并检查 TTL 时间与延迟时间。这里发布时间和延迟时间要一次性从 Entry 中获取，否则每次获取的 Entry 对象是不一样的。此外，延迟时间需要发送时间点的时间戳，根据具体计算出延迟的时间长度来做判断。

实践 4：Admin API Block 的优化处理

在 Pulsar 之前的代码逻辑中：

  • 如果在异步代码中频繁调用同步逻辑，那么其中的牵连关系很可能导致 Pulsar 外部的线程卡住，这时只能重启对应的 Broker 节点来恢复任务。

  • Pulsar 的 Http Lookup 服务调用的是外部端口，一旦异步调用同步导致阻塞，那么该服务外部端口的数据流也会出现阻塞。

  • Pulsar Web 服务的性能较差，主要是因为 CompletableFuture 的误用。当我们定义一个 CompletableFuture 对象后，经常调用 thenapply 或者 thencompose 来返回对象。这其实是 CompletableFuture 内对象的同步返回，是由当前线程栈执行的。如果异步任务没有返回，则由回调线程执行任务。

  • Pulsar 高版本加入了 Metadata Store 线程池的抽象。这个抽象会增大 ZooKeeper 的压力。当同一时间内的外部服务调用量增大，ZooKeeper 负载增大会导致消息延迟等指标出现退化。

腾讯团队针对上述问题，一方面剥离了 Metadata Store 线程池，另一方面通过服务监听来定位和发现 Web 服务的性能较弱的位置，去做进一步的优化处理。此外，团队还加入了超时处理逻辑，所有 Pulsar 外部线程如果在最后限定时间（30 秒）内无法处理完成就会抛出超时。虽然单个外部线程超时、重启影响不大，但这样避免了整个数据流阻塞的情况。

实践 5：zk-node 泄露

在这里插入图片描述
有时用户正在使用的 Topic 不多，但 zk-node 数量却很大，Pulsar 对 zk-node 的放大倍数较高。上图拐点是 zk-node 脏数据清理的时点，可以看到 zk-node 数据泄漏的情况非常严重，达到 5 倍之多。
在这里插入图片描述
在创建一个 Topic 时，首先要在 zk-path 的六级目录下涵盖所有 Topic 信息，在 ZooKeeper 上创建的资源量很大。此目录下涵盖了所有的 Topic，问题即出现在六个层级中。为此团队做了以下操作来处理 zk-node 脏数据：

  • 首先通过 ZooKeeper client 读取 zk-path，按照指定的格式拼接所有 Topic 名字，获取 Topic 列表；

  • 通过 pulsar-admin 检查集群中是否存在该 Topic；如果集群中不存在该 Topic，则相关数据一定是脏数据；（修复 zk-node 泄露问题的相关代码已 merge 进 2.8 + 的社区版本。）

  • 切记在清理 ZookKeeper 脏数据之前备份 ZookKeeper 数据。

实践 6：Bookie Ledger 泄漏

团队在实践中发现，虽然 Retention 策略设置的消息生命周期最长应不超过 30 天，但检测扫描到的一些消息已经有数百天历史，且难以从 BookKeeper 中删除。针对这一问题，团队分析如下：

  • 触发 Ledger 删除的唯一路径是 Retention 策略。这些消息产生的原因只能定位到一些 Bookie CLI 命令，这些命令生成了一些 Retention 策略管控不到的 Ledger。

  • 每一个 Ledger 都有对应的 LedgerInfo，记录了它的元数据信息，包括创建时间等。获取元数据后，就可以确定 Ledger 是多久前创建的，还可以确定 Ledger 具体是在哪些 Bookie 节点上。

  • 一个 Ledger 唯一归属于一个 Topic，所以可以获取 Topic 中存在 Ledger 的信息，进而确定某个 Ledger 是否存在于 Topic 的 Ledger 列表中，如果不在就是脏数据，可以清理。

  • 如果 Ledger 对应的元数据已经丢失，那么 Ledger 本身也可以直接删除。

  • 注意 Schema，如果忽略 Schema 可能会删除用户 Schema。恢复用户 Schema 时，Schema 的 Ledger 信息是存在 Bookie 中，Schema 自身的信息存在 Broker 归属的 ZK 中。恢复时需要先把 Broker 中存在的 Schema 信息删除，再让用户尝试使用生产端重建 Schema。

注意：执行以上操作前，切记提前备份数据。

实践 7：Apache Pulsar 多级缓存优化

在这里插入图片描述
如上图，Pulsar 现有缓存策略会导致明显的毛刺现象，出现服务周期性的剧烈性能波动和用户端的明显感知。

try {//We need to check all the segments, starting from the current//backward to minimize the//checks for recently inserted entriesint size = cacheSegments.size();for (int i = 0; i < size; i++)int segmentIdx = (currentSegmentIdx + (size - i)) % size;

try {int offset = currentSegmentOffset.getAndAdd(entrySize);if (offset + entrySize > segmentSize) {// Rollover to next segmentcurrentSegmentIdx = (currentSegmentIdx + 1) % cacheSegments.size();  currentSegment0ffset. set(alignedSize);cacheIndexes.get(currentSegmentIdx).clear();offset = 0;
}

这里腾讯团队主要做了读取缓存的优化。在读取缓存层面，可以看到 Pulsar 在读取缓存时迭代了缓存中的所有消息，如第一段代码倒数第二行所示。同时，一旦 offset + entrySize 大于 segmentSize，就会清除全部缓存，如第二段代码所示。这也就是为什么之前会出现明显的性能波动点的原因所在。

为此团队使用了 OHC + LRU 的策略，避免了缓存情况导致的剧烈波动，效果如下图：
在这里插入图片描述

总结与展望

本文分享了腾讯云团队在 Apache Pulsar 稳定性上的实践经验，重点介绍了消息空洞的影响及规避措施等最佳实践，为更多开发者提供参考。同时，腾讯云团队也在参与社区贡献中，和社区讨论以下重要问题并探索相关解决方案，如客户端超时时间内的重试策略，借鉴其他 MQ 的思路进行改进，尝试在客户端加入超时重试策略，通过多次重试机制来避免发送失败的情况发生；优化 Broker 和 Bookie OOM，针对 Ack 空洞对应集合无法缩容的问题进行改进；以及优化 Bookie Auto Recover，加入超时重试逻辑，避免 BookKeeper 和 ZooKeeper 之间发生 Session 超时的情况下服务重启。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/236323.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

进阶之路：高级Spring整合技术解析

进阶之路：高级Spring整合技术解析

Spring整合 1.1 Spring整合Mybatis思路分析1.1.1 环境准备步骤1:准备数据库表步骤2:创建项目导入jar包步骤3:根据表创建模型类步骤4:创建Dao接口步骤5:创建Service接口和实现类步骤6:添加jdbc.properties文件步骤7:添加Mybatis核心配置文件步骤8:编写应用程序步骤9:运行程序 1.…
阅读更多...
挑选知识付费平台不再迷茫：掌握这些技巧，轻松找到适合自己的平台！

挑选知识付费平台不再迷茫：掌握这些技巧，轻松找到适合自己的平台！

明理信息科技知识付费平台 在当今的知识付费市场中&#xff0c;用户面临的选择越来越多&#xff0c;如何从众多知识付费平台中正确选择属于自己的平台呢&#xff1f;下面&#xff0c;我们将为您介绍明理信息科技知识付费平台相比同行的优势&#xff0c;帮助您做出明智的选择。…
阅读更多...
Dubbo面试题及答案，持续更新

Dubbo面试题及答案，持续更新

在准备Dubbo相关的面试题时&#xff0c;我发现网络上的资源往往缺乏深度和全面性。为了帮助广大Java程序员更好地准备面试&#xff0c;我花费了大量时间进行研究和整理&#xff0c;形成了这套Dubbo面试题大全。 这套题库不仅包含了一系列经典的Dubbo面试题及其详尽答案&#x…
阅读更多...
雅思考试笔试还是机试，哪个更好，为什么？

雅思考试笔试还是机试，哪个更好，为什么？

想要参加或者即将参加雅思考试的同学们&#xff0c;你们知道雅思笔试和机试的有哪些相似点和不同点吗&#xff1f;下面由E趣少儿英语&#xff08;LUEnglish&#xff09;为您具体分析。 雅思纸笔考试与雅思机考&#xff1a;两者之间的相似之处 两个版本的雅思考试&#xff08;…
阅读更多...
concat_ws()和college_list()配合=＞实现多行转一行

concat_ws()和college_list()配合=＞实现多行转一行

concat_ws()&#xff1a; concat_ws()是“with separator”的缩写&#xff0c;它是一个用于连接字符串的函数。ws代表“with separator”&#xff0c;即带有分隔符。这个函数的作用是将多个字符串连接起来&#xff0c;并在它们之间插入指定的分隔符。语法&#xff1a;concat_ws…
阅读更多...
2023 英特尔On技术创新大会直播 | 边云协同加速 AI 解决方案商业化落地

2023 英特尔On技术创新大会直播 | 边云协同加速 AI 解决方案商业化落地

目录 前言边云协同时代背景边缘人工智能边缘挑战英特尔边云协同的创新成果最后 前言 最近观看了英特尔On技术创新大会直播&#xff0c;学到了挺多知识&#xff0c;其中对英特尔高级首席 AI 工程张宇博士讲解的边云协同加速 AI 解决方案商业化落地特别感兴趣。张宇博士讲解了英…
阅读更多...
开源堡垒机JumpServer结合内网穿透实现远程访问

开源堡垒机JumpServer结合内网穿透实现远程访问

开源堡垒机JumpServer结合内网穿透实现远程访问 前言1. 安装Jump server2. 本地访问jump server3. 安装 cpolar内网穿透软件4. 配置Jump server公网访问地址5. 公网远程访问Jump server6. 固定Jump server公网地址 前言 JumpServer 是广受欢迎的开源堡垒机&#xff0c;是符合 …
阅读更多...
网络安全：网络安全的技术趋势与发展

网络安全：网络安全的技术趋势与发展

1.背景介绍 网络安全是现代信息化时代的重要问题之一&#xff0c;它涉及到计算机网络的安全性、数据的完整性、隐私保护等方面。随着互联网的不断发展&#xff0c;网络安全问题也日益复杂化。本文将从多个方面进行探讨&#xff0c;以帮助读者更好地理解网络安全的技术趋势与发…
阅读更多...
spring依赖注入对象类型属性----外部bean的引入(bean和bean之间的引入)

spring依赖注入对象类型属性----外部bean的引入(bean和bean之间的引入)

文章目录 注入普通属性的方式1、set方法注入2、构造器&#xff08;构造方法&#xff09;注入 总结&#xff1a;注入对象类型属性 注入普通属性的方式 1、set方法注入 2、构造器&#xff08;构造方法&#xff09;注入 总结&#xff1a; set方法注入和构造器方法的注入&#…
阅读更多...
Ansible自动化工具之Playbook剧本编写

Ansible自动化工具之Playbook剧本编写

目录 Playbook的组成部分 实例模版 切换用户 指定声明用户 声明和引用变量&#xff0c;以及外部传参变量 playbook的条件判断 ​编辑 习题 ​编辑 ansible-playbook的循环 item的循环 ​编辑 list循环 ​编辑 together的循环&#xff08;列表对应的列&#xff0…
阅读更多...
【蓝桥杯一对一保奖辅导】国奖学姐蓝桥杯经验分享

【蓝桥杯一对一保奖辅导】国奖学姐蓝桥杯经验分享

目录 写在前面有关报名费如何准备&#xff1f;看书 /练习 /分类 /总结比赛技巧与指导 写在前面 蓝桥杯对于计算机专业相关的同学来说是非常值得参加的。 蓝桥杯相对于ACM比赛而言获奖难度较小&#xff0c;只要掌握技巧&#xff0c;拿到 省一甚至国奖是比较容易的&#xff0c;但…
阅读更多...
Qt前端技术：3.QSS字体样式

Qt前端技术：3.QSS字体样式

small-caps就是让这个文本中的小写字母用大写的形式写出来并且在用大写的形式表达出来后他本身的大小会变小 有绝对尺寸和相对尺寸的区别 绝对尺寸一般是cm&#xff0c;英寸之类的 相对尺寸如px之类的是由显示器的屏幕分辨率来决定的 如windows用户分辨率一般是96像素点每英…
阅读更多...
网络安全事件频发现状

网络安全事件频发现状

近日&#xff0c;腾讯视频、菜鸟、滴滴等App崩溃的消息登上热搜&#xff0c;引发不少网友热议。今年以来&#xff0c;已有多起App崩溃事件发生&#xff0c;甚至有企业因此业绩损失超亿元。互联网应用的系统安全和稳定性建设越来越被社会广泛关注。 12月3日晚&#xff0c;有网友…
阅读更多...
【力扣100】543.二叉树的直径

【力扣100】543.二叉树的直径

添加链接描述 # Definition for a binary tree node. # class TreeNode: # def __init__(self, val0, leftNone, rightNone): # self.val val # self.left left # self.right right class Solution:def __init__(self):self.max 0def diamete…
阅读更多...
uniapp整合echarts（目前性能最优、渲染最快方案）

uniapp整合echarts（目前性能最优、渲染最快方案）

本文echarts示例如上图，可扫码体验渲染速度及loading效果，下文附带本小程序uniapp相关代码 实现代码 <template><view class="source
阅读更多...
【python】在线代码混淆方案及注意事项

【python】在线代码混淆方案及注意事项

▒ 目录 ▒ &#x1f6eb; 导读开发环境 1️⃣ 在线网站pyob混淆操作步骤编写测试代码混淆转pyc缺点中文路径问题&#xff1a;python: Cant reopen .pyc file 2️⃣ 反编译python文件格式对比uncompyle6 3️⃣ 其它方案cpythonpython-obfuscatorPyInstaller【不推荐】pyminifie…
阅读更多...
数字人解决方案——ER-NeRF实时对话数字人模型推理部署带UI交互界面

数字人解决方案——ER-NeRF实时对话数字人模型推理部署带UI交互界面

简介 这个是一个使用ER-NeRF来实现实时对话数字人、口播数字人的整体架构&#xff0c;其中包括了大语言回答模型、语音合成、成生视频流、背景替换等功能&#xff0c;项目对显存的要求很高&#xff0c;想要达到实时推理的效果&#xff0c;建议显存在24G以上。 实时对话数字人 …
阅读更多...
众和策略：大盘涨手中的股票却大跌，到底怎么回事？

众和策略：大盘涨手中的股票却大跌，到底怎么回事？

大盘涨手中的股票却大跌&#xff0c;究竟怎么回事&#xff1a; 1、大盘上涨是权重股所造成的 大盘上涨可能是受一些权重比较大的工作所影响&#xff0c;比如证券工作、钢铁工作、银行工作等等&#xff0c;这些工作的大涨&#xff0c;可以拉升大盘的上涨&#xff0c;可是其它工…
阅读更多...
本地配置Java支付宝沙箱环境模拟支付并内网穿透远程调试

本地配置Java支付宝沙箱环境模拟支付并内网穿透远程调试

文章目录 前言1. 下载当面付demo2. 修改配置文件3. 打包成web服务4. 局域网测试5. 内网穿透6. 测试公网访问7. 配置二级子域名8. 测试使用固定二级子域名访问 前言 在沙箱环境调试支付SDK的时候&#xff0c;往往沙箱环境部署在本地&#xff0c;局限性大&#xff0c;在沙箱环境…
阅读更多...
Dynamic Coarse-to-Fine Learning for Oriented Tiny Object Detection（CVPR2023待补）

Dynamic Coarse-to-Fine Learning for Oriented Tiny Object Detection（CVPR2023待补）

文章目录 BeginningAbstract挑战方法成果 Introduction引出问题早期的work及存在的问题近期的work及存在的问题our workContribution Related Work&#xff08;paper for me&#xff09;Oriented Object DetectionPrior for Oriented ObjectsLabel Assignment Tiny Object Dete…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023