云原生消息流系统 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.rhkb.cn/news/221995.html

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

相关文章

Linux shell编程学习笔记37：readarray命令和mapfile命令

Linux shell编程学习笔记37：readarray命令和mapfile命令

目录 0 前言1 readarray命令的格式和功能 1.1 命令格式1.2 命令功能1.3 注意事项2 命令应用实例 2.1 从标准输入读取数据时不指定数组名&#xff0c;则数据会保存到MAPFILE数组中2.2 从标准输入读取数据并存储到指定的数组2.3 使用 -O 选项指定起始下标2.4 用-n指定有效行数…
阅读更多...
21.Servlet 技术

21.Servlet 技术

JavaWeb应用的概念 在Sun的Java Servlet规范中&#xff0c;对Java Web应用作了这样定义&#xff1a;“Java Web应用由一组Servlet、HTML页、类、以及其它可以被绑定的资源构成。它可以在各种供应商提供的实现Servlet规范的 Servlet容器 中运行。” Java Web应用中可以包含如下…
阅读更多...
人工智能的发展之路：时间节点、问题与解决办法的全景解析

人工智能的发展之路：时间节点、问题与解决办法的全景解析

导言 人工智能的发展历程充满了里程碑式的事件&#xff0c;从早期的概念到今天的广泛应用&#xff0c;每个时间节点都伴随着独特的挑战和创新。本文将详细描述每个关键时间节点的事件&#xff0c;探讨存在的问题、解决办法&#xff0c;以及不同阶段之间的联系。 1. 195…
阅读更多...
重温经典struts1之自定义转换器及注册的两种方式(Servlet,PlugIn)

重温经典struts1之自定义转换器及注册的两种方式(Servlet,PlugIn)

提示&#xff1a;文章写完后&#xff0c;目录可以自动生成&#xff0c;如何生成可参考右边的帮助文档 前言 Struts的ActionServlet接收用户在浏览器发送的请求&#xff0c;并将用户输入的数据&#xff0c;按照FormBean中定义的数据类型&#xff0c;赋值给FormBean中每个变量&a…
阅读更多...
Databend 源码阅读： Meta-service 数据结构

Databend 源码阅读： Meta-service 数据结构

作者&#xff1a;张炎泼&#xff08;XP&#xff09; Databend Labs 成员&#xff0c;Databend 分布式研发负责人 drmingdrmer (张炎泼) GitHub 引言 Databend 是一款开源的云原生数据库&#xff0c;采用 Rust 语言开发&#xff0c;专为云原生数据仓库的需求而设计。 面向云架…
阅读更多...
利用prometheus+grafana进行Linux主机监控

利用prometheus+grafana进行Linux主机监控

文章目录 一.架构说明与资源准备二.部署prometheus1.上传软件包2.解压软件包并移动到指定位置3.修改配置文件4.编写启动脚本5.启动prometheus服务 三.部署node-exporter1.上传和解压软件包2.设置systemctl启动3.启动服务 四.部署grafana1.安装和启动grafana2.设置prometheus数据…
阅读更多...
第二节TypeScript 基础语法

第二节TypeScript 基础语法

1、typescript程序由以下几个部分组成&#xff1a; 模块函数变量语句和表达式注释 2、开始第一个typescript程序 创建一个typescript程序&#xff0c;使之输出“hello typescript”&#xff1a; 代码&#xff1a; var message:string "hello typescript" cons…
阅读更多...
美颜SDK技术对比，深入了解视频美颜SDK的工作机制

美颜SDK技术对比，深入了解视频美颜SDK的工作机制

如何在实时视频中呈现更加自然、美丽的画面&#xff0c;而这正是美颜SDK技术发挥作用的领域之一。本文将对几种主流视频美颜SDK进行深入比较&#xff0c;以揭示它们的工作机制及各自的优劣之处。 随着科技的不断进步&#xff0c;美颜技术已经从简单的图片处理发展到了视频领域…
阅读更多...
Flink系列之：背压下的检查点

Flink系列之：背压下的检查点

Flink系列之&#xff1a;背压下的检查点 一、Checkpointing under backpressure二、缓冲区 Debloating三、非对齐 Checkpoints四、对齐 Checkpoint 的超时五、限制六、故障排除 一、Checkpointing under backpressure 通常情况下&#xff0c;对齐 Checkpoint 的时长主要受 Che…
阅读更多...
【运维面试100问】（十一）淡淡I/O过程

【运维面试100问】（十一）淡淡I/O过程

本站以分享各种运维经验和运维所需要的技能为主 《python零基础入门》&#xff1a;python零基础入门学习 《python运维脚本》&#xff1a; python运维脚本实践 《shell》&#xff1a;shell学习 《terraform》持续更新中&#xff1a;terraform_Aws学习零基础入门到最佳实战 《k8…
阅读更多...
关于“Python”的核心知识点整理大全32

关于“Python”的核心知识点整理大全32

目录 12.6.4 调整飞船的速度 settings.py ship.py alien_invasion.py 12.6.5 限制飞船的活动范围 ship.py 12.6.6 重构 check_events() game_functions.py 12.7 简单回顾 12.7.1 alien_invasion.py 12.7.2 settings.py 12.7.3 game_functions.py 12.7.4 ship.py …
阅读更多...
本地MinIO存储服务如何创建Buckets并实现公网访问上传文件

本地MinIO存储服务如何创建Buckets并实现公网访问上传文件

文章目录 前言1. 创建Buckets和Access Keys2. Linux 安装Cpolar3. 创建连接MinIO服务公网地址4. 远程调用MinIO服务小结5. 固定连接TCP公网地址6. 固定地址连接测试 前言 MinIO是一款高性能、分布式的对象存储系统&#xff0c;它可以100%的运行在标准硬件上&#xff0c;即X86等…
阅读更多...
管理类联考——数学——真题篇——按题型分类——充分性判断题——蒙猜E

管理类联考——数学——真题篇——按题型分类——充分性判断题——蒙猜E

老老规矩&#xff0c;看目录&#xff0c;平均每年2E&#xff0c;跟2D一样&#xff0c;D是全对&#xff0c;E是全错&#xff0c;侧面也看出10道题&#xff0c;大概是3A/B&#xff0c;3C&#xff0c;2D&#xff0c;2E&#xff0c;其实还是蛮平均的。但E为1道的情况居多。 第20题…
阅读更多...
Linux目录和文件管理

Linux目录和文件管理

一.Linux目录结构 Linux操作系统在定位文件或目录位置时&#xff0c;使用斜杠“ / ”进行分割&#xff08;区别于Windows操作系统中的反斜杠“ \ ”&#xff09;。整个树形目录结构中&#xff0c;使用独立的一个" / "表示根目录&#xff0c;根目录是Linux操作系统文…
阅读更多...
vue2 组件传递数据

vue2 组件传递数据

向子组件传递数据通过Props 1.创建子组件 详细步骤&#xff1a; 1.在components创建子组件 2.等父组件接受到参数后通过Props来接受父组件传递过来的数据 <template><div id"app"><h2>title:{{ title }}</h2><p>tips:{{ tips }}<…
阅读更多...
androidStudio版本下载链接记录

androidStudio版本下载链接记录

androidStudio 最新官网版本&#xff1a; 下载 Android Studio 和应用工具 - Android 开发者 | Android DevelopersAndroid Studio 提供了一些应用构建器以及一个已针对 Android 应用进行优化的集成式开发环境 (IDE)。立即下载 Android Studio。https://developer.android.g…
阅读更多...
数字化时代的智能支持：亚马逊云科技轻量应用服务器技术领先

数字化时代的智能支持：亚马逊云科技轻量应用服务器技术领先

轻量应用服务器是一种简化运维、门槛低的弹性服务器&#xff0c;它的"轻"主要体现在几个方面&#xff1a;开箱即用、应用优质、上手简洁、投入划算、运维简便以及稳定可靠。相较于普通的云服务器&#xff0c;轻量应用服务器简化了云服务的操作难度、使用和管理流程&a…
阅读更多...
MAC苹果笔记本电脑如何彻底清理垃圾文件软件？

MAC苹果笔记本电脑如何彻底清理垃圾文件软件？

苹果电脑以其流畅的操作系统和卓越的性能而备受用户喜爱。然而&#xff0c;随着时间的推移&#xff0c;系统可能会积累大量垃圾文件&#xff0c;影响性能。本文将介绍苹果电脑怎么清理垃圾文件的各种方法&#xff0c;以提升系统运行效率。 CleanMyMac X是一款专业的Mac清理软件…
阅读更多...
轻量级web开发框架Flask本地部署及无公网ip远程访问界面

轻量级web开发框架Flask本地部署及无公网ip远程访问界面

文章目录 前言1. 安装部署Flask2. 安装Cpolar内网穿透3. 配置Flask的web界面公网访问地址4. 公网远程访问Flask的web界面 前言 本篇文章讲解如何在本地安装Flask&#xff0c;以及如何将其web界面发布到公网上并进行远程访问。 Flask是目前十分流行的web框架&#xff0c;采用P…
阅读更多...
华为云之ECS云产品快速入门

华为云之ECS云产品快速入门

华为云之ECS云产品快速入门 一、ECS云服务器介绍二、本次实践目标三、创建虚拟私有云VPC1.虚拟私有云VPC介绍2.进入虚拟私有云VPC管理页面3.创建虚拟私有云4.查看创建的VPC 四、创建弹性云服务器ECS——Linux1.进入ECS购买界面2.创建弹性云服务器(Linux)——基础配置步骤3.创建…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023