PyCharm 2022.3 日前正式发布，新版本带来了全新的 Settings Sync（设置同步）解决方案、管理 Conda 软件包的新方法针对 pandas DataFrames 的增强用户体验。

用户体验

新的 Settings Sync（设置同步）解决方案

新的 Settings Sync（设置同步）插件现在可用于 PyCharm。新解决方案能够同步来自平台、捆绑插件和一些第三方插件的大部分可共享设置。请注意，我们将停止支持旧的 IDE Settings Sync（IDE 设置同步）插件并取消捆绑 Settings Repository（设置仓库）。

管理 Conda 软件包的新方式

无需离开 Editor（编辑器）窗口即可搜索、安装和删除 Conda 软件包。 Python Packages（Python 软件包）工具窗口现在可与 Anaconda 软件包库配合使用，让您可以在编写代码期间直接自定义 Conda 解释器。

通过设置使用新 PyCharm UI

切换到新 UI，预览 PyCharm 完全重做的外观。勾选 Settings/Preferences | Appearance & Behavior（设置/偏好设置 | 外观与行为）中的 New UI preview（新 UI 预览）框，在项目中尝试一下。

为 GitHub 和 Space 重新设计了 Review list（审查列表）

我们重做了 Review list（审查列表）UI，帮助减少认知负担并清晰提供有关请求的最重要信息。在改进中，我们还确保在所有受支持的审查平台上保持一致的外观。

改进了 Tips of the Day（每日小技巧）

我们对 Tips of the Day（每日小技巧）的外观和行为做出了多项更改，使其更实用且更易理解。我们更新了对话框的设计，实现了技巧评分功能以收集反馈。我们还微调了确定显示哪些提示的算法，让您可以看到与 IDE 体验和正在处理的项目最相关的提示。

其他改进：

为了让您可以更轻松地在多个显示器上与 PyCharm 交互，我们实现了将工具窗口拖出主窗口并将其停靠到浮动编辑器选项卡的选项。
我们对 Bookmarks（书签）实现了一些 UI 改进：右键选项卡调用上下文菜单，然后选择 Bookmarks（书签）即可从编辑器选项卡中为文件添加书签。您还可以将所有打开的选项卡中的所有文件添加到 Bookmarks（书签）。
PyCharm 让您能够以偏好样式阅读代码，无需重新格式化实际代码。您可以在 Reader（阅读器）模式下应用新的视觉格式设置层。
我们微调了 Search Everywhere（随处搜索）结果列表背后的算法。 IDE 将冻结第一个搜索结果，并且不会在找到更多选项时对其重新排序。此外，ML 排名现在对 Files（文件）选项卡启用，可以提供更准确的查找结果。

编辑器

Quick Documentation（快速文档）中的 docstring 呈现改进

Quick Documentation（快速文档）弹出窗口现在会显示类 docstring 的 Attributes（特性）部分，帮助您快速查看类特性。这也适用于继承的类特性和数据类的特性。

类实例现在更容易阅读：将鼠标悬停在形参上，其描述就会从类 docstring 调用。

意图操作预览默认启用

当采取 IDE 的建议后，您可以立即查看代码将如何更改。打开可用意图操作列表并将鼠标悬停在不同选项上时会显示预览。

Python 3.11：类型的代码洞察 [PEP 673]

PyCharm 可以识别方法或特性注解的类型，并为类实例建议正确的类型。

如果特定位置的用法不正确，PyCharm 会发出警告。

其他改进：

在 YAML 文件（包括 Kubernetes 文件、OpenAPI 规范和 docker-compose.yml）中，新增的快速修复可以通过注释禁止检查。

针对 Python 控制台的 asyncio 支持

内置 Python 控制台现在支持在函数外使用关键字快速运行协同程序。 PyCharm 2022.3 还为调试器添加了 asyncio 支持。此功能虽然有助于调试异步代码，但目前还处于实验性阶段，可能并不完全稳定。要启用它，请遵循这里介绍的步骤。

集成式开发者工具

安全性

软件包的漏洞检查器

安装程序

适用于 Windows 和 Linux ARM64 机器的安装程序（测试版）

现在，可以在带有 ARM64 处理器的 Windows 和 Linux 机器上运行 PyCharm。 IDE 安装程序目前处于测试版阶段。对于 Windows 用户，可以从网站和 JetBrains Toolbox App 获取安装程序。 Linux 用户只能从网站下载安装程序。

更多详情可查看：https://blog.jetbrains.com/pycharm/2022/12/2022-3/

NixOS 作为围绕独特的 Nix 软件包管理器构建的 Linux 发行版，推出了今年的最后一个版本。

NixOS 在这个版本中为 nixpkgs 增加了 16678 个新的软件包和 14680 个更新软件包，该版本还删除了 2812 个软件包，以保持软件包集的可维护性和安全性。除了软件包之外，NixOS 22.11 版本还带来了 91 个新模块，并删除了 20 个旧模块。在这个过程中，增加了 1322 个选项，删除了 487 个。

除了许多新的和升级的软件包外，这个版本还包括以下亮点：

亮点

使用密码哈希 API 的软件现在使用提供的实现，而不是 glibc 的实现，这使得支持更安全的算法成为可能。
- 对 libxcrypt 认为不强的算法的支持从这个版本开始被废弃，并将在 NixOS 23.05 中删除。
- 这包括系统登录密码。鉴于此，强烈建议所有用户更新他们的系统密码，因为如果在取消对密码哈希的支持时没有进行迁移，你将无法登录。
  - 当使用来配置用户密码时，运行，并使用提供的 yescrypt 哈希值作为新值。
  - 另一方面，对于交互式配置的用户密码，只需用为所有用户重新设置密码。
  - 这个版本为这两种配置密码的方法引入了对使用已废弃的哈希算法的警告。为了确保你的迁移正确，请运行。
NixOS 文档现在是由 markdown 生成的，虽然 docbook 仍然是文档构建过程的一部分，但这是向全面迁移迈出的一大步。
现在包含在和频道中。这意味着当这些频道更新时，和都将可用。
的 ISO 现在可以在下载页面上找到。
现在可以作为的替代使用了，并计划在 NixOS 23.05 中默认使用。
新增了一个选项，即，可以用来启用 NVIDIA 开源内核驱动的使用。

值得注意的版本更新

Nix 已从 v2.8.1 升级到 v2.11.0
OpenSSL 从 1.1.1 更新至 OpenSSL 3。
GNOME 已升级到版本 43
KDE Plasma 已从 v5.24 升级到 v5.26
Cinnamon 已经更新到 5.4，现在 Cinnamon 模块默认使用 Blueman 作为蓝牙管理器
PHP 从 8.0 更新至 8.1
Perl 已更新至 5.36
Python 从 3.9 更新至 3.10

更多详情可查看：https://nixos.org/manual/nixos/stable/release-notes.html

PyTorch 团队在昨日举办的 2022 PyTorch Conference 大会上宣布了 PyTorch 2.0，提供了用于体验的早期版本，并表示稳定版将于 2023 年 3 月上旬发布。

团队介绍道，PyTorch 2.0 是他们向 PyTorch 下一代 2 系列迈出的第一步。在过去的几年里，从 PyTorch 1.0 到最新的 1.13，他们对 PyTorch 进行了创新和迭代，并将它迁移到新成立的 PyTorch 基金会，成为 Linux 基金会的一部分。

PyTorch 2.0 引入了 torch.compile，这是一种编译模式，可以在不更改模型代码的情况下加速模型。在 163 个涵盖视觉、NLP 和其他领域的开源模型中，该团队发现使用 2.0 可以将训练速度提高 38-76%。

其次，PyTorch 2.0 是 100% 向后兼容的：代码库一样，API 一样，写模型的方式也一样。团队之所以称它为 2.0，是因为它有一些标志性的新特性，包括：

TorchDynamo 可以从字节码分析生成 FX 图；
AOTAutograd 可以以 ahead-of-time 的方式生成反向图；
PrimTorch 引入了一个小型算子集，使后端更容易；
TorchInductor：一个由 OpenAI Triton 支持的 DL 编译器。

PyTorch 2.0 将延续 PyTorch 一贯的优势，包括 Python 集成、命令式风格、API 简单等等。此外，PyTorch 2.0 提供了相同的 eager-mode 开发和用户体验，同时从根本上改变和增强了 PyTorch 在编译器级别的运行方式。该版本能够为「Dynamic Shapes」和分布式运行提供更快的性能和更好的支持。

在官方博客中，PyTorch 团队介绍了他们对 2.0 系列的展望：

详情查看文档。

Module Version Issues Spring Cloud Task 3.0.0-RC3 (issues) Spring Cloud Bus 4.0.0-RC3 Spring Cloud Contract 4.0.0-RC3 (issues) Spring Cloud Circuitbreaker 3.0.0-RC3 Spring Cloud Function 4.0.0-RC3 Spring Cloud OpenFeign 4.0.0-RC3 (issues) Spring Cloud Zookeeper 4.0.0-RC3 Spring Cloud Commons 4.0.0-RC3 (issues) Spring Cloud Vault 4.0.0-RC3 (issues) Spring Cloud Kubernetes 3.0.0-RC3 (issues) Spring Cloud Stream 4.0.0-RC3 Spring Cloud Starter Build 2022.0.0-RC3 Spring Cloud Consul 4.0.0-RC3 Spring Cloud Config 4.0.0-RC3 (issues Spring Cloud Build 4.0.0-RC3 Spring Cloud Gateway 4.0.0-RC3 (issues) Spring Cloud Netflix 4.0.0-RC3

笔者是 RocketMQ 的忠实粉丝，在阅读源码的过程中，学习到了很多编程技巧。

这篇文章，笔者结合 RocketMQ 源码，分享并发编程三大神器的相关知识点。

1 CountDownLatch 实现网络同步请求

CountDownLatch 是一个同步工具类，用来协调多个线程之间的同步，它能够使一个线程在等待另外一些线程完成各自工作之后，再继续执行。

下图是 CountDownLatch 的核心方法：

我们可以认为它内置一个计数器，构造函数初始化计数值。每当线程执行 countDown 方法，计数器的值就会减一，当计数器的值为 0 时，表示所有的任务都执行完成，然后在 CountDownLatch 上等待的线程就可以恢复执行接下来的任务。

举例，数据库有100万条数据需要处理，单线程执行比较慢，我们可以将任务分为5个批次，线程池按照每个批次执行，当5个批次整体执行完成后，打印出任务执行的时间。

温习完 CountDownLatch 的知识点，回到 RocketMQ 源码。

笔者在没有接触网络编程之前，一直很疑惑，网络同步请求是如何实现的？

同步请求指：客户端线程发起调用后，需要在指定的超时时间内，等到响应结果，才能完成本次调用。如果超时时间内没有得到结果，那么会抛出超时异常。

RocketMQ 的同步发送消息接口见下图：

追踪源码，真正发送请求的方法是通讯模块的同步请求方法 invokeSyncImpl 。

整体流程：

发送消息线程 Netty channel 对象调用 writeAndFlush 方法后，它的本质是通过 Netty 的读写线程将数据包发送到内核 , 这个过程本身就是异步的；
ResponseFuture 类中内置一个 CountDownLatch 对象，responseFuture 对象调用 waitRepsone 方法，发送消息线程会阻塞；

客户端收到响应命令后，执行 processResponseCommand 方法，核心逻辑是执行 ResponseFuture 的 putResponse 方法。

该方法的本质就是填充响应对象，并调用 countDownLatch 的 countDown 方法 , 这样发送消息线程就不再阻塞。

CountDownLatch 实现网络同步请求是非常实用的技巧，在很多开源中间件里，比如 Metaq ，Xmemcached 都有类似的实现。

2 ReadWriteLock 名字服务路由管理

读写锁是一把锁分为两部分：读锁和写锁，其中读锁允许多个线程同时获得，而写锁则是互斥锁。

它的规则是：读读不互斥，读写互斥，写写互斥，适用于读多写少的业务场景。

我们一般都使用 ReentrantReadWriteLock ，该类实现了 ReadWriteLock 。ReadWriteLock 接口也很简单，其内部主要提供了两个方法，分别返回读锁和写锁。

读写锁的使用方式如下所示：

创建 ReentrantReadWriteLock 对象 , 当使用 ReadWriteLock 的时候，并不是直接使用，而是获得其内部的读锁和写锁，然后分别调用 lock / unlock 方法 ;

读取共享数据；

写入共享数据；

RocketMQ架构上主要分为四部分，如下图所示 :

Producer ：消息发布的角色，Producer 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
Consumer ：消息消费的角色，支持以 push 推，pull 拉两种模式对消息进行消费。
BrokerServer ：Broker主要负责消息的存储、投递和查询以及服务高可用保证。
NameServer ：名字服务是一个非常简单的 Topic 路由注册中心，其角色类似 Dubbo 中的zookeeper，支持Broker的动态注册与发现。

NameServer 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。Broker 启动之后会向所有 NameServer 定期（每 30s）发送心跳包(路由信息)，NameServer 会定期扫描 Broker 存活列表，如果超过 120s 没有心跳则移除此 Broker 相关信息，代表下线。

那么 NameServer 如何保存路由信息呢？

路由信息通过几个 HashMap 来保存，当 Broker 向 Nameserver 发送心跳包（路由信息），Nameserver 需要对 HashMap 进行数据更新，但我们都知道 HashMap 并不是线程安全的，高并发场景下，容易出现 CPU 100% 问题，所以更新 HashMap 时需要加锁，RocketMQ 使用了 JDK 的读写锁 ReentrantReadWriteLock 。

更新路由信息，操作写锁

查询主题信息，操作读锁

读写锁适用于读多写少的场景，比如名字服务，配置服务等。

3 CompletableFuture 异步消息处理

RocketMQ 主从架构中，主节点与从节点之间数据同步/复制的方式有同步双写和异步复制两种模式。

异步复制是指消息在主节点落盘成功后就告诉客户端消息发送成功，无需等待消息从主节点复制到从节点，消息的复制由其他线程完成。

同步双写是指主节点将消息成功落盘后，需要等待从节点复制成功，再告诉客户端消息发送成功。

同步双写模式是阻塞的，笔者按照 RocketMQ 4.6.1 源码，整理出主节点处理一个发送消息的请求的时序图。

整体流程：

生产者将消息发送到 Broker , Broker 接收到消息后，发送消息处理器 SendMessageProcessor 的执行线程池 SendMessageExecutor 线程池来处理发送消息命令；
执行 ComitLog 的 putMessage 方法；
ComitLog 内部先执行 appendMessage 方法；
然后提交一个 GroupCommitRequest 到同步复制服务 HAService ,等待 HAService 通知 GroupCommitRequest 完成；
返回写入结果并响应客户端。

我们可以看到：发送消息的执行线程需要等待消息复制从节点 , 并将消息返回给生产者才能开始处理下一个消息。

RocketMQ 4.6.1 源码中，执行线程池的线程数量是 1 ，假如线程处理主从同步速度慢了，系统在这一瞬间无法处理新的发送消息请求，造成 CPU 资源无法被充分利用 , 同时系统的吞吐量也会降低。

那么优化同步双写呢？

从 RocketMQ 4.7 开始，RocketMQ 引入了 CompletableFuture 实现了异步消息处理 。

发送消息的执行线程不再等待消息复制到从节点后再处理新的请求，而是提前生成 CompletableFuture 并返回 ;
HAService 中的线程在复制成功后，调用 CompletableFuture 的 complete 方法，通知 remoting 模块响应客户端（线程池：PutMessageExecutor ）。

我们分析下 RocketMQ 4.9.4 核心代码：

Broker 接收到消息后，发送消息处理器 SendMessageProcessor 的执行线程池 SendMessageExecutor 线程池来处理发送消息命令；
调用 SendMessageProcessor 的 asyncProcessRequest 方法；

调用 Commitlog 的 aysncPutMessage 方法写入消息；

这段代码中，当 commitLog 执行完 appendMessage 后，需要执行刷盘任务和同步复制两个任务。

但这两个任务并不是同步执行，而是异步的方式。
复制线程复制消息后，唤醒 future ；
组装响应命令，并将响应命令返回给客户端。

为了便于理解这一段消息发送处理过程的线程模型，笔者在 RocketMQ 源码中做了几处埋点，修改 Logback 的日志配置，发送一条普通的消息，观察服务端日志。

从日志中，我们可以观察到：

发送消息的执行线程（图中红色）在执行完创建刷盘 Future 和同步复制 future 之后，并没有等待这两个任务执行完成，而是在结束 asyncProcessRequest 方法后就可以处理发送消息请求了；
刷盘线程和复制线程执行完各自的任务后，唤醒 future，然后通过刷盘线程组装存储结果，最后通过 PutMessageExecutor 线程池（图中黄色）将响应命令返回给客户端。

笔者一直认为：异步是更细粒度的使用系统资源的一种方式，在异步消息处理的过程中，通过 CompletableFuture 这个神器，各个线程各司其职，优雅且高效的提升了 RocketMQ 的性能。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！

Drawing 是 Linux 平台的图像编辑器，支持 PNG、JPEG 和 BMP 文件，支持简体中文和繁体中文。

Drawing 具备一个图像编辑器所具备的基本功能，它可以调整、裁剪或旋转图像，也可以应用简单的滤镜、插入文本等。用户还可以使用铅笔、直线、曲线工具、及其各种颜色和选项等工具在 Drawing 中直接绘画。

安装

用户可以从 flathub.org 中安装它（这个页面）。

大家好，我是 Kagol，Vue DevUI 开源组件库和 EditorX 富文本编辑器创建者，专注于前端组件库建设和开源社区运营。

假如你是团队的前端负责人，现在老板要拓展新业务，需要开发一个 Web 应用，让你来做技术选型，你之前用 Vue 比较多，对 Vue 比较熟悉，希望能在团队内部推行 Vue 技术栈，你会怎么跟老板说呢？以下是我做的一些调研，也许能对你有帮助。

声明：Vue 和 React 都是我很喜欢的前端框架，如有说得不对的地方，欢迎一起讨论交流。

一、Vue 在国内的使用量远高于 React / Angular

业界主流前端框架：React、Vue、Angular，从近3年的使用趋势上看，React 稳定在第一，Angular 逐年下降，Vue 持续增长。
从受欢迎程度上看，以 Svelte、Solid 为代表的新兴前端框架很受开发者喜爱，不过它们的使用量和生态繁荣程度还远低于三大框架。
虽然 React 在国外的份额高于 Vue，但 Vue 在国内的使用量大幅领先于 React，并且呈现出持续增长的趋势，这意味着在国内能更容易招聘到使用过 Vue、熟悉 Vue 的开发者。

图1: Vue 和 React 在全球的使用情况和受欢迎程度对比(来自 StateOfJS 数据)

图2: Vue 和 React 在中国的使用情况对比（来自 CSDN 调查报告）

参考：

https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/
https://csdn.gitcode.host/Survey-Report-on-Developers-in-China/survey/

二、Vue 中文资料多，学习曲线平缓，上手快

国人开发，美观易读的官方中文文档，除了基本的使用指南和API文档之外，Vue 官网还提供了深色模式、互动教程、演练场和丰富的示例，降低了开发者的学习成本，提升了文档阅读体验。
在掘金、知乎、思否等国内技术社区，Vue 的关注者、文章数、讨论数都比 React 高，Vue 相关视频在B站的播放量和评论数总体上也比 React 高，Vue 中文书籍也比 React 的多，这意味着国内的 Vue 开发者拥有比 React 开发者更丰富的中文学习资料，并且在开发过程中遇到问题也能更容易找到解决方案。
从代码编写上，Vue 使用模板写法，从传统写法过渡的成本低，而 React 的 JSX 写法需要更多额外的学习成本。

图3: Vue 官方中文文档

图4: Vue 和 React 在国内各技术社区的关注者和内容数据对比

图5: Vue 和 React 在代码编写上的对比

参考：

https://cn.vuejs.org/
https://juejin.cn/live/xdc

三、Vue 是渐进式框架，更轻量，性能高

Vue 是一个渐进式框架，它的设计非常注重灵活性和“可以被逐步集成”这个特点，可以根据你的需求场景，用不同的方式使用 Vue，并轻易地集成到你的现有项目中，不管你的项目是 HTML 网页、Web Components、SPA、桌面端、移动端、WebGL，甚至是命令行终端界面。
Vue 的体积几乎只有 React 的一半（未压缩情况下），并且 Vue 3.0 的全局 API 和内置组件都支持摇树优化，这意味着用户只需要为他们实际使用到的功能“买单”，未使用的功能代码将不会出现在最终的打包产物中。
经过 Benchmark 工具的测试，包括创建数据行、替换所有行、部分更新、选择行、交换行、移除行、追加行在内的所有操作，Vue 都比 React 性能要好，特别是交换行操作，Vue 比 React 性能高出5倍以上。

图6: Vue 和 React 包体积对比

图7: Vue 和 React 性能测试数据

参考：

https://krausest.github.io/js-framework-benchmark/2022/table_chrome_102.0.5005.61.html

四、Vue 官方支持的 Web 应用开发工具全面，可持续性好

Vue 官方提供路由、状态管理、单测试、静态站点生成等常见 Web 应用开发工具，无需从众多第三方依赖库中做选择，并能获得更好的业务连续性支持；而 React 官方只提供了一个视图层工具，其他必要的 Web 应用开发配套工具都需要依赖于第三方库。
在 Awesome 资源大全中，awesome-vue 的资源数是 awesome-react 的6倍，这意味着 Vue 开发者不仅能获得更好的官方工具支持，而且能在社区找到更多配套的 Web 开发工具和学习资源。

图8: Vue 和 React 官方工具和生态对比

参考：

https://github.com/vuejs/awesome-vue
https://github.com/enaqx/awesome-react

再次声明：Vue 和 React 都是我很喜欢的前端框架，我们的 Vue DevUI 组件以及组件的单测试都是使用 TypeScript + JSX 语法写的，所以如有说得不对的地方，欢迎一起友好讨论交流。

Nate Graham 是 KDE 的主要开发者之一，前段时间他也入选了 KDE e.V. 董事会。跟以往一样，近日他又分享了一些与 KDE 相关的功能开发进度，让大家能够提前了解到 KDE 近期的开发任务，以及未来的路线规划。

而本次公开的 KDE 开发工作中，有一个功能特别值得关注 —— 那就是已完成 KWin 内置高级窗口分屏布局的初步工作，未来将允许用户创建自定义平铺布局。

KWin 是一个 X Window System 的窗口管理器和一个 Wayland 合成器。它作为 KDE Plasma 5 的一部分发布，它是该系统的默认窗口管理器。KWin 也可以单独使用或与其他桌面环境一起使用。

KWin 可由基于 ECMAScript 的脚本（如 QML、QtScript）来进行配置，能够让用户完全控制窗口，通过调整窗口的偏好设置，可以给用户带来更好的使用体验。其中包括的功能就有：

支持以特定的大小和位置启动应用程序
自定义标题栏按钮的位置
有多个显示器/桌面的情况下，支持在不同的桌面直接打开特定应用程序
可根据屏幕大小调整窗口装饰和字体等
……

从上图也能看出，目前 KWin 已经预设了多个平铺布局，用户可以快速调整多个窗口的布局方式，提升工作效率。

除了预设的方案，KWin 还提供了平铺配置选项，用户可以根据个人喜爱将水平平铺修改为垂直平铺（感觉将显示器竖直使用时更适合）。当然，通过直接拖动相邻的多个窗口之间的缝隙，手动调整它们的大小也是没有问题的。

这个功能仍然处于起步阶段，Nate Graham 希望它能随着时间的推移不断进步，同时，为它添加的新的 API 也能让那些想让 KWin 变成一个平铺窗口管理器的第三方平铺脚本受益。这个功能预计将在 Plasma 5.27 中发布。

除了会在 KWin 中内置高级窗口平铺系统，KDE 的改进还包括：

支持在 Dolphin 文件管理器和其他文件管理工具中使用原生 afc:// 协议浏览苹果 iOS 设备。

Konsole 将采用 KHamburgerMenu

Konsole 的标签栏现在默认位于窗口的顶部而不是底部
支持 Plasma 5.27 的 Global Shortcuts（全局快捷方式），允许 Flatpak 和其他沙盒应用程序使用 portal 系统，为设置/编辑全局快捷方式提供一个标准化的用户界面。
专注于移动 KDE 应用程序的 KDE Plasma Mobile Gear 现在将转移到正常的 “KDE Gear” 发布时间表，以统一它们。

Go 近日接受了名为「add support for wrapping multiple errors」的提案。

该项提案对错误处理进行了优化，与 Go 1.13 为错误处理提供的新功能有关：Error Wrapping。引入 Error Wrapping 后，Go 同时为包添加了 3 个工具函数，分别是、和。

对于「add support for wrapping multiple errors」提案，顾名思义就是一个错误可以包裹多个错误。

提出该提案的开发者表示，重用避免了与现有 Unwrap 方法产生歧义，从中返回一个长度为 0 的列表意味着错误没有包裹任何内容。调用方不得修改由返回的列表，返回的列表不得包含任何错误。

他还对和函数进行了更新，实现对 multiple errors 进行操作。

函数提供了 multierr 的简单实现：

目前该提案已被接受，作者表示将在 Go 1.20 中提供：

详情查看 https://github.com/golang/go/issues/53435。

更新内容

iot-modbus本次发布的V3.2.6版本支持设备上线、掉线、处理业务异常监听处理，请看下面的源码解读。

设备上线监听源码解读

主要是在MiiListenerHandler重写了channelActive方法

设备掉线监听源码解读

主要是在MiiListenerHandler重写了channelInactive方法。

处理业务异常监听源码解读

主要是增加了MiiExceptionHandler处理器，并在服务端MiiServer和客户端MiiClient初始化initChannel时添加进入。

连接监听器源码解读

主要通过spring的发布时间监听来处理，增加连接监听器ChannelConnectListener。

Acl 是一个跨平台网络通信库与服务器开发框架，支持 LINUX, WIN32, Solaris, FreeBSD, MacOS, AndroidOS, iOS，实现了常见的网络通信协议：HTTP/Websocket/SMTP/ICMP/MQTT/Redis/Memcached/Beanstalk/Handler Socket，实现了常见的编解码：XML/JSON/MIME/BASE64/UUCODE/QPCODE/RFC2047/RFC1035，另外，还封装了常见的数据库客户端 API，支持：Mysql, Postgresql, Sqlite。Acl 库不仅可以用在服务端开发高性能、高并发的服务器应用，而且还可以用在客户端（支持Win32, Android, iOS）开发网络通信模块。本次升级为年度大版本更新，主要包括如下重大更新：

1、feature：协程模块（lib_fiber）支持 Linux 中新增的 io_uring 引擎，在协程模式下统一了网络 IO 与文件 IO 过程，磁盘IO过程不会再阻塞协程调度器；

2、feature：协程模块（lib_fiber）中设计了新的可以用在协程之间、协程与线程之间同步的协程锁（fiber_mutex），相较于之前的 fiber_event 占用少量的文件句柄，同时具有更好的性能；

3、optimize：协程模块（lib_fiber）优化定时器模块，大幅降低调用gettimdofday API的次数，从而进一步提升协程调度器的性能；

4、optimize：协程模块（lib_fiber）优化网络IO超时模块，大幅提升大并发下网络模块的性能；

5、optimize：协程模块（lib_fiber）重新设计并实现了 DNS 协程模块，去掉对第三方 DNS 库的依赖；

6、feature：SSL 模块（lib_acl_cpp中）增加了针对 OpenSSL 的支持，从而使服务端开发 SSL 类服务应用的性能较之前（使用 MbedTLS）大幅提升；

7、optimize：Redis 模块（lib_acl_cpp中）中的 pipeline 接口进行优化，方便子类重载其中的消息管理模块，从而方便协程模式下使用 Redis pipeline 模式；

8、featue：acl_master 服务管理器与服务子进程之间更好地支持 SO_REUSEPORT 功能；

9、bugs fixed：包括一些已知问题的修复。

Acl 库下载：

gitee：https://gitee.com/acl-dev/acl

github: https://github.com/acl-dev/acl

漏洞描述

Apache Commons Net 是一个提供基本的互联网访问协议的客户端，支持的协议包括：Echo、Finger、FTP、NNTP、NTP、POP3(S)、SMTP(S)、Telnet、Whois 等。

Apache Commons Net 3.9.0之前版本中的 FTP 客户端默认信任来自 PASV （被动 FTP）响应的主机，当 Commons Net 的 FTP 客户端连接到攻击者可控的恶意主机时，攻击者可将 Commons Net 的 FTP 连接重定向到其它主机，进而获取 Commons Net FTP 客户端运行服务的敏感信息，补丁版本通过默认禁止来自 PASV 响应的主机（org.apache.commons.net.ftp.ipAddressFromPasvResponse = false）修复此漏洞。

漏洞名称 Apache Commons Net <3.9.0 存在输入验证不当漏洞漏洞类型输入验证不恰当发现时间 2022-12-04 漏洞影响广度小 MPS编号 MPS-2021-28440 CVE编号 CVE-2021-37533 CNVD编号 –

影响范围

commons-net:commons-net@(-∞, 3.9.0)

修复方案

升级commons-net:commons-net到 3.9.0 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2021-28440

https://nvd.nist.gov/vuln/detail/CVE-2021-37533

https://github.com/apache/commons-net/commit/b0bff89f70cfea70009e22fcc

https://issues.apache.org/jira/browse/NET-711.

https://github.com/advisories/GHSA-cgp8-4m63-fhh5

情报订阅

OSCS(开源软件供应链安全社区)通过最快、最全的方式，发布开源项目最新的安全风险动态，包括开源组件安全漏洞、事件等信息。同时提供漏洞、投毒情报的免费订阅服务，社区用户可通过配置飞书、钉钉、企业微信机器人，及时获得一手情报信息推送：

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

MyCms 是一款基于 Laravel 开发的开源免费的开源多语言商城 CMS 企业建站系统。

MyCms 基于 Apache2.0 开源协议发布，免费且可商业使用，欢迎持续关注我们。

V4.1 更新内容

新增：自媒体模块
新增：自媒体账号管理
新增：自媒体文章管理
新增：自媒体模板生成文章
新增：自媒体文章发布
新增：Neditor 编辑器
新增：编辑器切换开关
新增：接入秀米内容排版工具
新增：Neditor 编辑器远程抓取图片
新增：easywechat 开发包
优化：CURD快速生成

更新重点说明

1、新增 Neditor 编辑器

开启方法：系统模块 > 网站配置 > 富文本编辑器切换

2、对接秀米内容排版工具

3、新增自媒体模块

一、自媒体账号管理

二、自媒体文章管理

三、自媒体模板生成文章

通过模板生成文章，目前支持两种方式，一是通过 json 内容来进行生成，其次就是通过读取数据表来生成文章，以JSON 数据生成文章为例，简单说明一下使用方法。

四、自媒体文章预览发布

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

4MLinux 是一个轻量级的 Linux 发行版，适用于 32 位和 64 位架构。它被命名为 “4MLinux”，因为它有 4 个主要的操作系统组件。维护（它可以被用作救援的 Live CD）、多媒体（对几乎所有的多媒体格式都有内置的支持）、Miniserver（它包括一个 64 位的服务器），以及 Mystery（一个经典的 Linux 游戏集合）。当用该发行版安装程序时，该发行版会检索 Windows 版本，而不是 Linux 版本，因为它预装了 Wine（Windows 应用程序的兼容层），而且没有任何软件包管理器。

4MLinux 41.0 稳定版发布，更新内容如下：

新的功能：

开箱即用的新应用程序：
- FileZilla（FTP 客户端）
- XPaint 和 GNU Paint（简单的图像编辑工具）
- nvme（管理 NVM-Express 分区的命令行工具）
- 一系列小型 SDL 游戏。
作为可下载扩展的新应用程序：
- BlueGriffon（HTML 编辑器）
- ioquake3（Quake III 移植）
- The Legend of Edgar（平台游戏）
- BZFlag（坦克大战游戏）
4MLinux 中的默认视频播放器现在是 SMPlayer
默认音频播放器是Audacious

软件升级：

LibreOffice 7.4.3
GNOME Office（AbiWord 3.0.5、GIMP 2.10.32、Gnumeric 1.12.52）
DropBox 151.4.4304
Firefox 107.0
Chromium 106.0.5249
Thunderbird 102.5.0
Audacious 4.2
VLC 3.0.17.3
SMPlayer 22.2.0
Mesa 22.1.4
Wine 7.18
4MLinux LAMP Server（Linux 6.0.9、Apache 2.4.54、MariaDB 10.6.11、PHP 5.6.40 和 PHP 7.4.33）。
Perl 5.36.0
Python 2.7.18 和 Python 3.10.6
Ruby 3.1.2

更多详情可查看：https://4mlinux-releases.blogspot.com/2022/12/4mlinux-410-stable-released.html

最新版本的 Midori 浏览器正式发布，并开放下载。新版浏览器被命名为 Midori Next Generation，版本号为 10.0.2。

不知道还有多少人记得 Midori，它是一个轻量级的网络浏览器，最初使用 WebKitGTK 渲染引擎和 GTK UI 工具包。Midori 也曾是 Elementary OS 等 Linux 发行版中默认的网络浏览器。

由于这个项目已有 2 年多的时间没有更新了，各个 Linux 发行版也早已更换默认浏览器，Ubuntu 甚至从 Ubuntu 22.04 的系统资源库中将其彻底删除了。

就在几天前，Astian 基金会主动公开了最新的进展，表示 Midori 浏览器仍然活着，并会内置自家的开源搜索引擎。

只不过新版的 Midori 现在成为了基于 Chromium 的网络浏览器，并使用 Electron 构建，支持 Linux、macOS 和 Windows，以及 Android。

到目前为止，新的 Midori 浏览器的特点：

新的 Logo
集成 Adblock，开箱即可屏蔽广告
支持隐身模式
基于 Chromium，但没有 Google 服务和隐私跟踪，资源占用少
支持 Chrome 扩展
简单现代的用户界面
快速和高度可定制的用户界面
标签页分组
虽然承诺会使用自己的开源 AstianGo 搜索引擎，但到目前为止，浏览器还没内置 AstianGo（需要手动访问 https://astian.org/）。现在的默认搜索引擎为 DuckDuckGo，可选 Google、Bing 和 Ecosia。

下载链接：https://astian.org/midori-browser-desktop/download-midori-browser-desktop/

Genode OS 22.11 已正式发布。

Genode 操作系统框架是一个用于构建高度安全的专用操作系统的工具包。它可以从只有 4MB 内存的嵌入式系统扩展到高度动态的通用工作负载。

Genode 基于递归系统结构。每个程序都在专门的沙箱中运行，并且仅授予其特定用途所需的访问权限和资源。程序可以利用自己的资源创建和管理子沙箱，从而形成可以在每个级别应用策略的层次结构。该框架提供了让程序相互通信和交换资源的机制，但只能以严格定义的方式进行。由于这种严格的制度，与当代操作系统相比，安全关键功能的攻击面可以减少几个数量级。

该框架将 L4 的构建原则与 Unix 哲学保持一致。根据 Unix 哲学，Genode 是一组小型构建块的集合，从中可以组成复杂的系统。但与 Unix 不同的是，这些构建块不仅包括应用程序，还包括所有经典的操作系统功能，例如内核、设备驱动程序、文件系统和协议栈。

特性

CPU 架构：x86（32 和 64 位）、ARM（32 和 64 位）、RISC-V

内核：L4 家族的大多数成员（NOVA、 seL4、 Fiasco.OC、 OKL4 v2.1、 L4ka::Pistachio、 L4/Fiasco）、Linux 和自定义内核。

虚拟化：VirtualBox（基于 NOVA）、ARM 的自定义虚拟机监视器和 Unix 软件的自定义运行时

超过 100 个随时可用的组件

在从 Linux 移植最新的图形驱动程序代码，并更改其英特尔图形多路复用器设计后，他们现在通过 Genode OS 22.11 支持英特尔 Gen12 级图形。如果想在最新一代英特尔硬件上享受加速的图形效果，这对于 Genode 的 Sculpt OS 通用操作系统来说尤其是个好消息。

Genode OS 22.11 还在 PinePhone 支持、Arm 和 x86_64 的虚拟化改进、可配置的英特尔 HWP 模式、各种设备驱动改进、通过 HTTP 的启动加载以及其他补充方面带来了更多开发资源。

详情查看 Release Notes。

漏洞描述

Apache Commons Net 是一个提供基本的互联网访问协议的客户端，支持的协议包括：Echo、Finger、FTP、NNTP、NTP、POP3(S)、SMTP(S)、Telnet、Whois 等。

Apache Commons Net 3.9.0之前版本中的 FTP 客户端默认信任来自 PASV （被动 FTP）响应的主机，当 Commons Net 的 FTP 客户端连接到攻击者可控的恶意主机时，攻击者可将 Commons Net 的 FTP 连接重定向到其它主机，进而获取 Commons Net FTP 客户端服务通过 FTP 协议传输的文件信息，补丁版本通过默认禁止来自 PASV 响应的主机（org.apache.commons.net.ftp.ipAddressFromPasvResponse = false）修复此漏洞。

漏洞名称 Apache Commons Net <3.9.0 存在FTP跳转攻击漏洞漏洞类型输入验证不恰当发现时间 2022-12-04 漏洞影响广度小 MPS编号 MPS-2021-28440 CVE编号 CVE-2021-37533 CNVD编号 –

影响范围

commons-net:commons-net@(-∞, 3.9.0)

修复方案

升级commons-net:commons-net到 3.9.0 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2021-28440

https://nvd.nist.gov/vuln/detail/CVE-2021-37533

https://github.com/apache/commons-net/commit/b0bff89f70cfea70009e22fcc

https://issues.apache.org/jira/browse/NET-711.

https://github.com/advisories/GHSA-cgp8-4m63-fhh5

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

来自 Dedebiz 的消息：

2022年12月3日下午DedeCMS创始人林学先生（IT柏拉图）因罹患癌症逝世。

林学先生生于1979年10月10日，于2004年8月编写的DedeCMS至今仍有数十万企业、个人站长使用，在使用者中不免有一些互联网巨头，其中bilibili更是基于DedeCMS白手起家，而林学先生一直秉承着开源免费的理念，通过技术改变了中国，却从未因DedeCMS过上体面的生活。

在此我们缅怀林学先生为中国开源作出的贡献，其遗志必将传承下去，为社会创造更多价值。

从一个线上问题说起

最近在线上遇到了一些卡死

初步分析

观察了下主线程堆栈，用到的锁是读写锁随后又去翻了下持有着锁的子线程，有各种各样的情况，且基本都处于正常的执行状态，例如有的处于打开文件状态，有的处于状态，有的正在执行的方法…通过观察发现，出问题的线程都有标记。整体看起来持有锁的子线程仍然在执行，只是留给主线程的时间不够了。为什么这些子线程在持有锁的情况下，需要执行这么久，直到主线程的8s卡死？一种情况就是真的如此耗时，另一种则是出现了优先级反转。

解决办法

在这个案例里面，持有读写锁且优先级低的线程迟迟得不到调度（又或者得到调度的时候又被抢占了，或者得到调度的时候时间已然不够了），而具有高优先级的线程由于拿不到读写锁，一直被阻塞，所以互相死锁。之后引入了的概念，类似于线程的优先级，设置不同的的值后系统会分配不同的时间、网络资源和硬盘资源等，因此我们可以通过这个设置队列的优先级。

方案一：去除对的优先级设置

在 Threading Programming Guide 文档中，苹果给出了提示：

Important: It is generally a good idea to leave the priorities of your threads at their default values. Increasing the priorities of some threads also increases the likelihood of starvation among lower-priority threads. If your application contains high-priority and low-priority threads that must interact with each other, the starvation of lower-priority threads may block other threads and create performance bottlenecks.

苹果的建议是不要随意修改线程的优先级，尤其是这些高低优先级线程之间存在临界资源竞争的情况。所以删除相关优先级设置代码即可解决问题。

方案二：临时修改线程优先级

在 pthread_rwlock_rdlock(3pthread) 发现了如下提示：

Realtime applications may encounter priority inversion when using read-write locks. The problem occurs when a high priority thread “locks” a read-write lock that is about to be “unlocked” by a low priority thread, but the low priority thread is preempted by a medium priority thread. This scenario leads to priority inversion; a high priority thread is blocked by lower priority threads for an unlimited period of time. During system design, realtime programmers must take into account the possibility of this kind of priority inversion. They can deal with it in a number of ways, such as by having critical sections that are guarded by read-write locks execute at a high priority, so that a thread cannot be preempted while executing in its critical section.

尽管针对的是实时系统，但是还是有一些启示和帮助。按照提示，对有问题的代码进行了修改：在线程通过拿到的时候，临时提升其优先级，在释放之后，恢复其原先的优先级。

值得注意的是，这里只能使用的，提供的是不可行的

Demo 验证

为了验证上述的手动调整线程优先级是否有一定的效果，这里通过进行本地实验：定义了个（目的是为了繁忙），优先级设置，且对其中可以被整除的的优先级调整为，在每个执行相同的耗时任务，然后对这被选中的个进行耗时统计。

统计信息如下图所示

A B C （注释模块1和模块2代码）（只打开模块1代码）（同时打开模块1和模块2代码） 11. 94. 15.0

可以看到

正常情况下，每个任务的平均耗时为：11.；
当被设置为低优先级时，其耗时大幅度提升为：94.；
当被设置为低优先级时，又在中手动恢复其原有的优先级，其耗时已经大幅度降低：15.0（ 耗时比正常情况高，大家可以思考下为什么）

通过可以发现，通过手动调整其优先级，低优先级任务的整体耗时得到大幅度的降低，这样在持有锁的情况下，可以减少对主线程的阻塞时间。

上线效果

该问题的验证过程分为个阶段：

第一个阶段如第1个红框所示，从月号开始在版本上有较大幅度的下降，主要原因：堆栈中被等待的队列信息由变为了，队列的优先级从提升为，相当于实施了方案一，使用了默认优先级。
第二个阶段如第个红框所示，从月号在版本上开始验证。目前看起来效果暂时不明显，推测一个主要原因是：中是把优先级从提升为，而线上相当于把队列的优先级从默认的优先级提升为所以相对来说，线上的提升相对有限。
1. 的层级优先级数是4；
2. 的层级优先级数是31；
3. 的层级优先级数是37；

深刻理解优先级反转

那么是否所有锁都需要像上文一样，手动提升持有锁的线程优先级？系统是否会自动调整线程的优先级？如果有这样的机制，是否可以覆盖所有的锁？要理解这些问题，需要深刻认识优先级反转。

什么是优先级反转？

优先级反转，是指某同步资源被较低优先级的进程/线程所拥有，较高优先级的进程/线程竞争该同步资源未获得该资源，而使得较高优先级进程/线程反而推迟被调度执行的现象。根据阻塞类型的不同，优先级反转又被分为和。这里借助 Introduction to RTOS – Solution to Part 11 (Priority Inversion) 的图进行示意。

Bounded priority inversion

如图所示，高优先级任务（）被持有锁的低优先级任务（)阻塞，由于阻塞的时间取决于低优先级任务在临界区的时间（持有锁的时间），所以被称为。只要一直持有锁，就会一直被阻塞，低优先级的任务运行在高优先级任务的前面，优先级被反转。

这里的任务也可以理解为线程

Unbounded priority inversion

在持有锁的情况下，如果有一个中间优先级的任务（）打断了，前面的就会变为，因为只要抢占了的，就可能会阻塞任意多的时间（可能不止个）

优先级反转常规解决思路

目前解决有种方法：一种被称作优先权极限（），另一种被称作优先级继承（）。

Priority ceiling protocol

在优先权极限方案中，系统把每一个临界资源与1个极限优先权相关联。当1个任务进入临界区时，系统便把这个极限优先权传递给这个任务，使得这个任务的优先权最高；当这个任务退出临界区后，系统立即把它的优先权恢复正常，从而保证系统不会出现优先权反转的情况。该极限优先权的值是由所有需要该临界资源的任务的最大优先级来决定的。

如图所示，锁的极限优先权是3。当持有锁的时候，它的优先级将会被提升到3，和一样的优先级。这样就可以阻止(优先级是2）的运行，直到和不再需要该锁。

Priority inheritance

在优先级继承方案中，大致原理是：高优先级任务在尝试获取锁的时候，如果该锁正好被低优先级任务持有，此时会临时把高优先级线程的优先级转移给拥有锁的低优先级线程，使低优先级线程能更快的执行并释放同步资源，释放同步资源后再恢复其原来的优先级。

和都会在释放锁的时候，恢复低优先级任务的优先级。同时要注意，以上种方法只能阻止，而无法阻止（必须等待执行完毕才能执行，这个反转是无法避免的）。

可以通过以下几种发生来避免或者转移：

减少临界区的执行时间，减少的反转耗时；
避免使用会阻塞高优先级任务的临界区资源；
专门使用一个队列来管理资源，避免使用锁。

优先级继承必须是可传递的。举个栗子：当阻塞在被持有的资源上，而又阻塞在持有的一个资源上。如果的优先级高于和的优先级，必须通过继承的优先级。否则，如果另外一个优先级高于和，小于的线程，将抢占，引发相对于的优先级反转。因此，线程所继承的优先级必须是直接或者间接阻塞的线程的最高优先级。

如何避免优先级反转？

QoS 传递

iOS 系统主要使用以下两种机制来在不同线程（或）间传递：

机制1：
- automatically propagates the QoS from the calling thread, though it will translate User Interactive to User Initiated to avoid assigning that priority to non-main threads.
- Captured at time of block submission, translate user interactive to user initiated. Used if destination queue does not have a QoS and does not lower the QoS (ex dispatch_async back to the main thread)
机制2：基于 XPC 的进程间通信（）

系统的 QoS 传递规则比较复杂，主要参考以下信息：

当前线程的
如果是使用 () 方法生成的，则考虑生成时所调用的参数
或的目标或线程的

调度程序会根据这些信息决定以什么优先级运行。

如果没有其他线程同步地等待此，则就按上面所说的优先级来运行。

如何触发优先级反转避免机制？

如果当前线程因等待某线程（线程1）上正在进行的操作（如）而受阻，而系统知道所在的目标线程（），系统会通过提高相关线程的优先级来解决优先级反转的问题。反之如果系统不知道所在目标线程，则无法知道应该提高谁的优先级，也就无法解决反转问题；

记录了持有者信息（）的系统 API 如下：

、、以及基于这二者实现的上层 API
1. 的实现是基于的
2. 、、等的实现是基于
、

使用以上这些 能够在发生优先级反转时使系统启用优先级反转避免机制。

基础API验证

接下来对前文提到的各种「基础系统」进行验证

测试验证环境：模拟器 iOS15.2

pthread mutex

的数据结构其中有一个字段，专门来记录持有该锁的线程。

代码来验证一下：线程优先级是否会被提升？

先在子线程上锁并休眠，然后主线程请求该锁

可以看到，低优先级子线程先持有锁，当时的优先级为，而该锁被主线程请求的时候，子线程的优先级被提升为

os_unfair_lock

用来替换，解决优先级反转问题。等待锁的线程会处于休眠状态，从用户态切换到内核态，而并非忙等。将线程保存到了锁的内部，锁的等待者会把自己的优先级让出来，从而避免优先级反转。验证一下：

结果和一致

pthread_rwlock_t

在 pthread_rwlock_init 有如下提示：

Caveats: Beware of priority inversion when using read-write locks. A high-priority thread may be blocked waiting on a read-write lock locked by a low-priority thread. The microkernel has no knowledge of read-write locks, and therefore can’t boost the low-priority thread to prevent the priority inversion.

大意是内核不感知读写锁，无法提升低优先级线程的优先级，从而无法避免优先级反转。通过查询定义发现：包含了字段，专门来记录持有写锁的线程，这不由令人好奇：为什么有信息却仍然无法避免优先级反转？

https://news.ycombinator.com/item?id= 链接中提到：

xnu supports priority inheritance through “turnstiles“, a kernel-internal mechanism which is used by default by a number of locking primitives (list at [1]), including normal pthread mutexes (though not read-write locks [2]), as well as the os_unfair_lock API (via the ulock syscalls). With pthread mutexes, you can actually explicitly request priority inheritance by calling pthread_mutexattr_setprotocol [3] with PTHREAD_PRIO_INHERIT; the Apple implementation supports it, but currently ignores the protocol setting and just gives all mutexes priority inheritance.

大意是：使用内核机制进行优先级继承，这种机制被应用在和上。

顺藤摸瓜，在方法中找到了的调用，其中的注释对读写锁解释的比较委婉，添加了

pthread mutexes and rwlocks both (at least sometimes) know their owner and can use turnstiles. Otherwise, we pass NULL as the tstore to the shims so they wait on the global waitq.

再去查看的定义，代码还是很诚实的，只有在才会启用进行优先级反转保护，而读写锁的类型为，这说明读写锁不会使用，所以无法避免优先级反转。

另外在也可以看到，读写锁的是

把锁更换为读写锁，验证一下前面的理论是否正确：

可以看到读写锁不会发生优先级提升

dispatch_sync

这个都比较熟悉了，这里直接验证：

是一个低优先级队列（），可以看到调用压入队列的任务，以及在这之前压入的任务，都被提升到较高的优先级（和主线程一致），而最后一个的任务则以优先级来执行。

dispatch_wait

是一个低优先级队列（），当在当前主线程使用进行等待时，输出如下，低优先级的任务被提升到优先级

而如果将注释掉之后，输出如下：

值得注意的是，是一个宏（的泛型），或者是一个入口函数，它可以接受，，种类型的参数，但是这里的具体含义应该是指，只有会调整优先级，避免优先级反转。

神秘的信号量

之前对的认知非常浅薄，经常把二值信号量和互斥锁划等号。但是通过调研后发现：没有的概念，没有记录当前持有信号量的线程（），所以有高优先级的线程在等待锁时，内核无法知道该提高哪个线程的调试优先级（）。如果锁持有者优先级比其他线程低，高优先级的等待线程将一直等待。Mutex vs Semaphore: What’s the Difference? 一文详细比对了和之间的区别。

Semaphores are for signaling (sames a condition variables, events) while mutexes are for mutual exclusion. Technically, you can also use semaphores for mutual exclusion (a mutex can be thought as a binary semaphore) but you really shouldn’t.Right, but libdispatch doesn’t have a mutex. It has semaphores and queues. So if you’re trying to use libdispatch and you don’t want the closure-based aspect of queues, you might be tempted to use a semaphore instead. Don’t do that, use os_unfair_lock or pthread_mutex (or a higher-level construct like NSLock) instead.

这些是一些警示，可以看到十分危险，使用需要特别小心。

这里通过苹果官方提供的demo进行解释：

假设在主线程执行这段代码，那么当前线程的优先级是；
由于从主线程进行了异步，异步任务队列的将会被提升为；
主线程被信号量阻塞，而负责释放该信号量的异步任务的优先级低于主线程的优先级，因此可能会发生优先级反转。

值得一提的是，专门针对这种情况进行了静态检测：

https://github.com/llvm-mirror/clang/blob/master/lib/StaticAnalyzer/Checkers/GCDAntipatternChecker.cpp

如果想使用该功能，只需要打开设置即可：

另外，跟类似，在调用方法时，无法预知谁会调用，所以系统也无法知道其是谁，所以同样不会有优先级提升的问题。

信号量卡死现身说法

给笔者的印象非常深刻，之前写过一段这样的代码：使用信号量在主线程同步等待相机授权结果。

上线后长期占据卡死，当时百思不得其解，在深入了解到信号量无法避免优先级反转后，终于豁然开朗，一扫之前心中的阴霾。这类问题一般通过种方式来解决：

使用同步

异步回调，不要在当前线程等待

几个概念

turnstile

前文提到使用进行优先级继承，这里对机制进行简单的描述和理解。在内核中，存在着大量的同步对象（例如），为了解决优先级反转的问题，每个同步对象都必须对应一个分离的数据结构来维护大量的信息，例如阻塞在这个同步对象上的线程队列。可以想象一下，如果每个同步对象都要分配一个这样的数据结构，将造成极大的内存浪费。为了解决这个问题，采用了机制，一种空间利用率很高的解决方案。该方案的提出依据是同一个线程在同一时刻不能同时阻塞于多个同步对象上。这一事实允许所有同步对象只需要保留一个指向的指针，且在需要的时候去分配一个即可，而则包含了操作一个同步对象需要的所有信息，例如阻塞线程的队列、拥有这个同步对象的线程指针。是从池中动态分配的，这个池的大小会随着系统中已分配的线程数目增加而增加，所以总数将始终低于或等于线程数，这也决定了的数目是可控的。由阻塞在该同步对象上的第一个线程负责分配，当没有更多线程阻塞在该同步对象上，会被释放，回收到池中。的数据结构如下：

优先级数值

在验证环节有一些优先级数值，这里借助「Mac OS® X and iOS Internals 」解释一下：实验中涉及到的优先级数值都是相对于层而言的，且都是用户线程数值

用户线程的优先级是0~63；
1. 的层级优先级数是4；
2. 的层级优先级数是20；
3. 的层级优先级数是31；
4. 的层级优先级数是37；
5. 的层级优先级是47；
内核线程的优先级是80~95；
实时系统线程的优先级是96~127；
64~79被保留给系统使用；

总结

本文主要阐述了优先级反转的一些概念和解决思路，并结合平台的几种锁进行了详细的调研。通过深入的理解，可以去规避一些不必要的优先级反转，从而进一步避免卡死异常。字节跳动团队也针对线程的优先级做了监控处理，进而达到发现和预防优先级反转的目的。

加入我们

字节跳动 APM 中台致力于提升整个集团内全系产品的性能和稳定性表现，技术栈覆盖iOS/Android/Server/Web/Hybrid/PC/游戏/小程序等，工作内容包括但不限于性能稳定性监控，问题排查，深度优化，防劣化等。长期期望为业界输出更多更有建设性的问题发现和深度优化手段。

欢迎对字节APM团队职位感兴趣的同学投递简历到邮箱 xushuangqing@bytedance.com 。

参考文档

WWDC18 What’ s New in LLVM – actorsfit
https://developer.apple.com/videos/play/wwdc2015/718
https://developer.apple.com/forums/thread/
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/PrioritizeWorkWithQoS.html
https://github.com/llvm-mirror/clang/blob/google/stable/lib/StaticAnalyzer/Checkers/ GCDAntipatternChecker.cpp
Don’t use dispatch semaphores where mutexes (or dispatch queues) would suffice
Concurrency Problems Written by Scott Grosch
https://www.sigusoft.com/p/af64e05de503
https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_rwlock_wrlock.html
iOS中各种“锁”的理解及应用
不再安全的 OSSpinLock
https://blog.actorsfit.com/a?ID=00001-499b1c8e-8a7f-4960-a1c1-c8e2f42c08c6
https://objccn.io/issue-2-1/#Priority-Inversion
Introduction to RTOS – Solution to Part 11 (Priority Inversion)
https://threadreaderapp.com/thread/1229999590482444288.html#
深入理解iOS中的锁
Threads can infect each other with their low priority

添加小助手回复【APM】可加入性能监控交流群，获取更多技术干货

ZomboDB 通过使用 Elasticsearch 作为索引类型，为 Postgres 带来了强大的文本搜索和分析功能。其全面的查询语言和 SQL 函数支持以新颖和创造性的方式来查询您的关系数据。

从技术角度来看，ZomboDB是一个100%用Rust和PGX编写的本地Postgres扩展。ZomboDB使用Postgres的索引访问方法API来直接管理和优化ZomboDB的专门索引。作为一个原生的Postgres索引类型，ZomboDB允许你用CREATE INDEX … USING zombodb在你现有的Postgres表中。在这一点上，ZomboDB接管并完全管理远程Elasticsearch索引，保证交易上正确的文本搜索查询结果。

ZomboDB完全兼容Postgres的所有查询计划类型和大多数SQL命令，如CREATE INDEX, COPY, INSERT, UPDATE, DELETE, SELECT, ALTER, DROP, REINDEX, (auto)VACUUM，等等。

无论你是使用 Elasticsearch 云提供商还是管理你自己的集群都没有关系——ZomboDB 通过其 RESTful API 与 Elasticsearch 通信，因此你可以采用任何一种方式。

ZomboDB 允许你直接从 Postgres 使用 Elasticsearch 的强大功能和可扩展性。你不必管理 Postgres 和 Elasticsearch 之间的事务、异步索引管道、复杂的重新索引过程或多个数据访问代码路径——ZomboDB 会为你完成这一切。

特性：

MVCC 正确的文本搜索和聚合结果
通过标准 SQL 进行管理和查询
适用于当前的 Elasticsearch 版本（无需插件）
查询使用
- Elasticsearch 的查询字符串语法通过
- ZQL — ZomboDB 的自定义查询语言
- 原始 Elasticsearch QueryDSL JSON
- ZomboDB 的类型安全查询生成器 SQL 语法
- 以上的任意组合，甚至与标准 SQL 组合
评分和突出显示支持
支持所有 Elasticsearch 聚合
自动 Elasticsearch 映射生成
- 能够映射自定义域
- 每字段自定义映射
- 自动映射为动态嵌套对象
- 支持全套Elasticsearch 语言分析器
- 支持Elasticsearch的相似度模块
Hot standby兼容
支持索引和搜索 PostGIS和类型

Fosshost 是一家总部位于英国的开源软件托管和云计算提供商，Fosshost 的服务已被 GNOME、KDE、Armbian、Debian、Rocky Linux、Ubuntu Unity 和 Xfce 等众多知名开源项目所使用。近日他们宣布服务器即将关闭，不再提供服务。

一开始，当你访问各种 fosshost.org 的链接时，都会返回 404 错误信息，后来 fosshost.org 在网站上更新了一份声明并写道：

此时此刻，Fosshost 非常抱歉地宣布，我们不再能够继续提供我们的服务。

在官网的声明中，其实并没有透露停止服务的具体原因，仅仅是写道：

由于 Fosshost 志愿者无法控制的情况，我们现在无法保证我们的服务器会一直在线，事实上，我们预计它们很快就会下线。正因为如此，我们强烈建议所有 Fosshost 的用户立即备份他们的数据，并尽快迁移到其他地方。

在这个声明中，实际上是无法得知 Fosshost 关闭的真正原因。而在 HN 相关的帖子中，一位来自 Fosshost 的志愿者则是给出了更加明确的信息：

我们无力支付托管的费用，这就是为什么我们的服务器会因为无法联系上首席执行官 Thomas Markey 而下线，只有他能够访问银行账户，从而获得资金。

而且 CEO 失联的情况已经持续了半年时间，Fosshost 内部人员也因管理问题纷纷辞职，这位志愿者也是 Fosshost 的最后一位志愿者。

其实在今年 9 月，Fosshost 就因为可扩展性的问题暂停了其应用程序，给使用他们服务的开源项目造成了不便。在 11 月，维护者在试图操作一个芝加哥节点时也陷入了困境，因为首席执行官没有给其他任何人权限，该节点已无法访问、启动或恢复。

唯一的好消息是，前 Fosshost 志愿者和原架构师目前已经开始构建一个名为 Radix 的替代方案，并会提供免费的按需托管服务。

人工智能研究公司 OpenAI 上周正式推出 ChatGPT，这是一种基于对话的人工智能聊天机器人模型，它能够理解自然语言并以自然语言的方式做出回应。

ChatGPT 基于 GPT-3.5 模型微调而成，以语言服务模型 InstructGPT 为基础，通过人类回馈增强学习训练模型 RLHF，不过数据设置略有不同。它以对话方式进行交互，既能够做到回答问题，也能承认错误、质疑不正确的前提以及拒绝不恰当的请求，能以更贴近一般人的对话方式与使用者互动。

这几天许多用户都展示了与 ChatGPT 对话的有趣内容，它宛如化身为地球“最强懂哥”，各种问题轻松应答，让它解答防疫政策与经济发展的关系，给出的答案不仅条理清晰，还会引用例子支撑观点。让它帮忙写程序，不仅提供了可用的代码，更是把实现思路也一并写了出来。

更别说开发者如何应付老板这种小儿科的问题了：

下面介绍一些 ChatGPT 的“极客”玩法。

在 ChatGPT 中构建虚拟机

这名玩家把 ChatGPT 训练成了一台 Virtual Machine，可以运行各种 Linux 指令，甚至可以使用 curl 来让 ChatGPT 和自己做交互。

首先是让 ChatGPT “扮演” Linux 终端：

执行 ls 命令，以及新建文件和读取文件：

在这之后，这名用户推测 ChatGPT 似乎懂文件系统的工作原理、文件存储及检索方式。下面直接快进到用这个虚拟机运行 docker 文件——首先制作一个 docker 文件，然后运行它：

可以看到，ChatGPT 成功扮演了一个“虚拟机”的角色。

在 ChatGPT 中构建编程语言解释器

这名开发者使用 ChatGPT 为自己开发的编程语言构建了一个语言解释器：

并成功编写了解决作者问题的应用程序：

接着这名作者通过提供参数，让 ChatGPT 对自己编写的这段程序进行了验证，同样没问题：

在 ChatGPT 中实现新的编程语言

这名玩家在 ChatGPT 中实现了一门新的编程语言：GPTLang，并用这个语言写了一个排序算法。

首先告诉 ChatGPT 正在实现一门新的编程语言，能不能给一些 idea 或者建议，ChatGPT 给出了 GPTLang 的一些基本特性。

定义编译器命令为 `gptlc`，并且可以使用 `gptlc file.gpt` 来进行编译。然后让 ChatGPT 给出一些常用的编译选项：

下图是最终的效果：让 ChatGPT 用 GPTLang 写了一个选择排序算法，并在命令行编译运行。

对于 ChatGPT 的这些“整活”案例，欢迎大家在评论区发表自己的看法。

作者：陈树煌，TCL 实业数据管理部副总监（本文为作者在 StarRocks Summit Asia 2022 上的分享）

作为伴随改革开放浪潮成长起来的中国领先电子企业，TCL 拥有 13 万员工，业务遍及 160 多个国家和地区，全球累计服务用户超 9.6 亿。如此庞大的企业体量和业务规模，构建统一的数据分析平台势在必行。

截止目前，TCL 已将 StarRocks 应用于新方舟实时大屏、集团 HR 服务、邮件告警等场景。新方舟实时大屏场景中，TCL 基于 StarRocks 构建了实时数仓，平均的响应速度在 200-500 毫秒内；集团 HR 服务场景中，TCL 把小时级数据从 ClickHouse 切换到 StarRocks 上进行多表关联的自助分析，查询性能提升了 3-5 倍；在邮件告警场景中，TCL 基于 StarRocks 构建了实时日志数据的数据分析及算法应用，实现了秒级预警功能，准确率达到 92.3%。

本文将围绕背景、OLAP 建设历程、StarRocks 典型应用场景、未来规划等几点展开介绍 TCL 选择并应用 StarRocks 的最佳实践。

#01

背景介绍

TCL 集团经过四十多年的发展，形成了两大集团和三大核心产业，其中 TCL 实业主要聚焦在智能终端业务，包括 TV、空调、冰箱等等。而 TCL 科技则向产业链的上游发展，聚焦在半导体显示、新能源与半导体材料等高科技产业。目前 TCL 有 13 万名员工，业务遍及 160 多个国家地区。

格创东智是 2018 年 TCL 战略孵化的工业互联网企业，背靠 TCL 这棵大树，对内负责 TCL 的数字化转型建设工作，对外则将在 TCL 内部实践成熟的方案转化成产品或服务对外输出。在去年刚获得工信部双跨平台的认证，累计为 20 多个行业提供产品和咨询服务。

TCL 即将迎来第 41 个生日，目前 TCL 正在进行第四次大的变革，全面地进行数字化转型，TCL 总部负责整体的统筹以及统一投资建设各个产业公共的设施以及技术平台，大数据平台是其中的共享平台之一。产业则根据自身的情况，自行规划转型的节奏。

TCL 实业目前正在进行业务模式、业务流程、规则等的梳理，输出了 13 个一级流程。最近几年会聚焦在研发领域的 IPD、供应链领域的 ISC、财务领域的 IFS 等重点的几个流程，梳理清楚每个业务的步骤以及上面所承载的数据将流程数据固化到新的自研的一套业务系统，用这套业务系统替换掉现有的业务系统。

在今年年中，我们在一家子公司投入了 300 多名业务人员、200 多名技术人员，同时上线了七套供应链系统。紧接着在八月份上线了国内的营销中台，目前正在进行的是国内的服务售后平台、研发平台，以及相关其他子公司的供应链系统的建设。

接下来的一两年是 TCL 实业建设的高峰期，对个人而言，这是积攒能力或者学习历练的好机会。放眼当今中国，很少有集团级的企业做这么大的投入，这对个人来说还是比较好的机遇，再此也欢迎感兴趣的朋友加入我们，助力 TCL 的数字化转型成功。

为什么 TCL 会投入这么多资源做标准的建设呢？做过数据分析平台的朋友应该比较清楚，数据分析的难点不在于技术，而是数据。就像厨师要做出美味的佳肴，关键不在于使用多先进、多精美的厨具，而是在于食材以及相应的方法。

TCL 实业是与多家原先独立经营的子公司整合而成，各个子公司的业务、数据、标准、流程都不一致，以研发运维为例，就存在了四套 PLM，在这上面所承载的对同一个电容，各个系统的编码是不一致的，而描述这个电容所使用的字段是不一样的。有些系统可能用 10 个字段去描述这个电容，有些系统用 50 个字段描述这个电容，从系统层面是没办法识别成同一个电容，这导致后续无法进行集中采购，通过规模去降低成本，同时也无法进行整个库存的分析，支撑后续的排查。有可能在 a 系统显示的是缺料，但在 b 系统其实材料已经积压。

所以实业目前想通过业务流程的标准化系统整合数据的治理，从数据产生就保证数据的干净、清洁，实现数据在全流程的贯通。一方面提升整个业务的运作效率，同时数据会汇聚到大数据平台，做进一步的数据分析，支撑量化的决策，驱动业务的改进。

为了支撑数据从产生到后期的消费、运营，全生命周期的管理，我们在建设整个数据管理体系，包括一些政策、规范、流程组织等一些 IT 系统。

#02

OLAP 建设历程

这是我们在建设的大数据及 AI 平台的应用架构，最上面是数据分析的平台，主要支撑的是自助 BI、大屏等等的一些分析。

TCL 经过几十年的发展，有一些数据分析平台，最简单的就是关系数据库，再加一些开源的组件，复杂点的是基于 Hive 平台其它 BI 做相应的建设。

为了保证业务的平滑迁移，在集团统一的平台建设的时候，我们也是基于整个 Hadoop 生态构建的 Hive 的数仓，将加工后的数据导入到关系型数据库或 Kudu 等数据库去做数据的分析。

2021 年随着财务数据的接入，海量分析的问题凸显，于是我们引入了 ClickHouse。随着业务发展、自助分析场景的应用越来越多，截至八月份，整个自助分析平台累计达到 6000 用户。多表关联的性能以及并发的问题也逐渐出现，同时，业务对数据的实效性也要求更高，在此背景下，我们引入了 StarRocks 解决相应的问题。

上图展现的是当前数据分析的相关组件，能看出组件还是比较多的，包括一些关系型的数据库、Kudu、ClickHouse 的组件。这导致运维的成本比较高，开发也要基于不同的场景选用不同的组件，增加了开发的难度。我们希望逐渐替换成 StarRocks，去降低运维成本以及开发的难度，提升开发的效率。

目前我们也在做 StarRocks 相应些场景的验证，基于前面的一些实践，我们总结了 ClickHouse 与 StarRocks 的一些优缺点，ClickHouse 目前来说还是单表的性能最优，StarRocks 的优点在于多表关联、写入的性能以及高并发，整体来说跟业界的指标是一致的，这里就不展开。

这是年初我们在做 POC 的时候做的多表上的写入和查询的对比，可以看出，随着数据量增加，StarRocks 的优势越来越明显。

#03

StarRocks 典型应用场景介绍

1、新方舟实时大屏

第一个场景是新方舟的实时大屏，我们基于 StarRocks 构建了实时数仓，去支撑实时数据的分析，体现的是 StarRocks 的时效性和高并发。

新方舟是我们今年刚上线的营销中台。基于营销，我们要做很多方面的数据的分析，这个场景要面临跨越营销、供应、制造等等多域的数据的集成分析，不同域的数据时效性，对分析的要求不一样。

新方舟的整体架构如上图所示。对于实时性要求比较高的分析，我们通过构建实时数仓去接入，而对于时效性要求比较低的，我们则通过离线数仓去接入。实时数仓和离线数仓加工后的数据全部导入到 StarRocks，以支持前端的数据应用，包括一些大屏的分析、自助分析等等。

这是当时做的 618 的销售看板，通过新方舟场景的验证，StarRocks 能很好的支撑实时数仓以及实时报表分析的需求。

整体的体验还是比较好的，平均的响应在 200 到 500 毫秒内。

2、集团 HR 服务

第二个场景是集团 HR 的服务，这里主要是验证 StarRocks 自助分析的过程中多表关联的查询性能。

集团 HR 是我们首个建设的数据资产，我们接入了各个产业的 E-HR 系统，进行数据的清洗，形成了整个数据的资产，支撑了几个人力的应用和数字化运营的分析。

这里面会有个指标极端的场景，TCL 每年会收到政府的一些临时的报数要求，为了应付这种场景，我们会做一个花名册，花名册里面有 200 多个字段，字段会分布在 30 多张表里面。

没有做整个数据分析平台之前，HR 是从 SAP 每月导出数据到 Excel 进行报数分析，整个导入的过程将近 30 分钟。上线整个数据分析平台之后，我们在数据平台里面会生成每个月的快照，支撑需要的自助分析，后来时效性提高到每天，今年提出更高的要求，要求小时级别的刷新。

这个场景主要面临的是多表关联的查询，刚开始，我们通过 ClickHouse 实现，包括每月的快照，每日的快照，用大宽表这种方式，整个体验还是比较好的。但到了小时级别，就需要做多表的关联，整个查询的时间比较长，大概 15 秒左右。

在今年我们引进了 StarRocks 之后，把小时级的数据切换到上面，查询的性能提升了 3-5 倍，查询只需要 3-5 秒，用户体验比较好。

3、邮件告警

第三个场景是邮件告警，主要验证的是 StarRocks 海量的读写、实时、高并发的能力。

整个 TCL 目前有 7 万多名用户，每天都面对着黑客攻击等威胁，为了避免相关的安全隐患给公司造成损失，我们目前在尝试通过一些 AI 等新技术去识别相应的风险。

这个场景主要面临的挑战是实时的要求比较高，海量数据的写入性能要求比较高，以及高并发的数据统计查询。

以前我们用 Kudu 加 Impala 实现，我们内部做了几个 StarRocks 和 Kudu 的性能对比，发现 StarRocks 的整体性能优于 Kudu，包括写入、查询和高并发。于是我们整个场景都切换成 StarRocks 去实现，整体的效果还是比较好的。目前我到外地出差，一下飞机打开邮件很快就能收到相应的提示。

#04

未来规划

1. 打通融合：StarRocks 是我们今年新上线的 MPP 数据库，跟我们自研的大数平台存在很多整合的工作，我们会继续往下开展。

2. 提升效能：整个实时数仓这块规划逐渐切换到 StarRocks，提升整个实时数仓效能。

3. 化繁为简：我们逐渐去收敛 OLAP 引擎到 StarRocks，降低运营以及开发的成本。

4. 极速统一：极速统一相关的开发。打造以 StarRocks 为主的 OLAP 数据分析平台，并基于此实现数据统一存储、统一分析、统一服务、赋能不同业务场景，加速数据价值产出。

5. 稳定运行：StarRocks 还算比较新的 MPP 产品，可靠性、稳定性有待进一步的观察，我们也在逐步完善 StarRocks 的监控。

关于 StarRocks

StarRocks 创立两年多来，一直专注打造世界顶级的新一代极速全场景 MPP 数据库，帮助企业建立“极速统一”的数据分析新范式，助力企业全面数字化经营。

当前已经帮助腾讯、携程、顺丰、Airbnb 、滴滴、京东、众安保险等超过 170 家大型用户构建了全新的数据分析能力，生产环境中稳定运行的 StarRocks 服务器数目达数千台。

2021 年 9 月，StarRocks 源代码开放，在 GitHub 上的星数已超过 3600 个。StarRocks 的全球社区飞速成长，至今已有超百位贡献者，社群用户突破 7000 人，吸引几十家国内外行业头部企业参与共建。

本期 News 快读有 GitHub 官方大动作一下子开源了两款字体，同样大动作的还有 OpenAI 发布的对话模型 ChatGPT，引燃了一波人机对话。

项目这块，也许会成为新的 Web 开发生产力工具的 leptos 和 Python UI 库 CustomTkinter，还有提升开发体验的 jsonhero-web 帮你读 JSON，以及本地跑 GitHub Actiona 的 act。最好玩的，当然是互帮互助的 Villain 一起给彼此的系统留个门。

最后，校招的小伙伴记得绕开这些坑，CampusShame 收录对应届生不友好的公司，当然也有部分对应届生不错的公司选择。

以下内容摘录自微博@HelloGitHub 的 GitHub Trending 及 Hacker News 热帖（简称 HN 热帖），选项标准： | | ，根据项目 release 时间分类，发布时间不超过 14 day 的项目会标注，无该标志则说明项目 release 超过半月。由于本文篇幅有限，还有部分项目未能在本文展示，望周知 🌝

本文目录
- News 快读
  - 新品·GitHub 官方开源多款字体
  - 爆款·ChatGPT 相关仓库
- 1. 本周特推
  - 1.1 Web 应用构建：leptos
  - 1.2 JSON 更好读：jsonhero-web
- 2. GitHub Trending 周榜
  - 2.1 Python UI 库：CustomTkinter
  - 2.2 本地跑 Action：act
  - 2.3 事件驱动微服务：go-coffeeshop
  - 2.4 系统开后门：Villain
  - 2.5 校招避坑：CampusShame
- 3. 往期回顾

News 快读

新品·GitHub 官方开源多款字体

上周五，GitHub 官方发布了两款可变字体，分别名为：Mona Sans 和 Hubot Sans，你可以基于需求使用这两款字体。

这两款字体可以多种组合，做出漂亮的效果图（如下），更多介绍就得查看官方博客 https://github.blog/2022-12-02-introducing-mona-sans-and-hubot-sans/

爆款·ChatGPT 相关仓库

不知道本周你的朋友圈有没有被 ChatGPT 攻陷呢？一个可以帮你写代码、找 bug、写小说、写注释，各种工作都能搞定的文本机器人。比如，知乎的『电光幻影炼金术』提问过如何找男友的问题。

就这个神奇的聊天模型，也引发了 GitHub 的 ChatGPT 热潮，仅仅 2 天时间，便有 115 个相关的 repo。有兴趣的话，你可以了解下：

ChatGPT 逆向工程，自己搞个聊天机器人 https://github.com/acheong08/ChatGPT
跑在你 macOS 状态栏的 ChatGPT https://github.com/vincelwt/chatgpt-mac

1. 本周特推

1.1 Web 应用构建：leptos

主语言：Rust

可用 Rust 快速构建 Web 应用。特性：

全栈：它可在浏览器中运行，也可以在服务器端渲染、运行，或是服务器渲染 HTML 时在浏览器中添加交互；
同构：你可以在客户端和服务端用相同形式调用函数，但它只在服务器上运行；
Web：leptos 基于 Web 平台和 Web 标准之上，没有新的学习成本；
框架：提供构建现代 Web 应用所需的大部分内容：响应式系统、模版库、可在服务端和客户端跑的路有；
精细的响应：leptos 由响应式原语构造，当响应信号变化时，可以更新单个文本节点、单个类或是从 DOM 中删除一个素，不用动其他代码；
声明式；

示例代码：

GitHub 地址→https://github.com/gbj/leptos

1.2 JSON 更好读：jsonhero-web

主语言：TypeScript

API HERO 团队开源的 JSON HERO，旨在提供一个简洁、漂亮的 UI 给 JSON 使用者，让阅读和理解 JSON 更容易。部分特性：

多种查看方式，可树形、列视图、编辑器视图等方式看 JSON；
自动推断字符串内容，并提供有用预览；
创建可用于验证 JSON 的推断 JSON Schema；
可用键、值来检索 JSON 文件；

GitHub 地址→https://github.com/apihero-run/jsonhero-web

2. GitHub Trending 周榜

2.1 Python UI 库：CustomTkinter

本周 star 增长数：850+，主语言：Python

基于 Tkinter（Tk GUI 工具包的 Python 绑定包）的 Python UI 库，提供了新颖、现代、可定制的小部件。你可以单独使用这些部件，也可以组合使用。下图为 Windows 下的蓝黑主题。

GitHub 地址→https://github.com/TomSchimansky/CustomTkinter

2.2 本地跑 Action：act

本周 star 增长数：1,350+，主语言：Golang

在本地跑起你的 GitHub Actions。至于为什么选 act，项目给出了两个简单粗暴的理由：快速反馈，不需要每次测试都提交相关变更；免去 Makefile 烦恼，本地任务器就能搞定。

GitHub 地址→https://github.com/nektos/act

2.3 事件驱动微服务：go-coffeeshop

本周 star 增长数：1,700+，主语言：Golang

Golang 实现的事件驱动微服务演示。部署用到了 Nomad、Consul、Vault 和 Terraform。

GitHub 地址→https://github.com/thangchung/go-coffeeshop

2.4 系统开后门：Villain

本周 star 增长数：1,350+，主语言：Python

一个给 Windows 和 Linux 系统生成后门和多会话处理的工具，允许用户连接兄弟服务器（运行 Villain 的其他机器）并共享后门会话。

GitHub 地址→https://github.com/t3l3machus/Villain

2.5 校招避坑：CampusShame

本周 star 增长数：700+

什么只允许公司做海王把应届生当鱼，不能学生自己当海王去养公司的鱼呢？CampusShame，校招污点与非污点公司名单，校招污点行为包括但不限于：毁意向书、毁两方协定、毁三方协定、试用期裁员、大量裁应届生。

GitHub 地址→https://github.com/forthespada/CampusShame

3. 往期回顾

往期回顾：

快速绘制流程图「GitHub 热点速览 v.22.47」
视觉享受，兼顾人文观感和几何特征的字体「GitHub 热点速览 v.22.46」

以上为 2022 年第 48 个工作周的 GitHub Trending 🎉如果你 Pick 其他好玩、实用的 GitHub 项目，记得来 HelloGitHub issue 区和我们分享下哟 🌝

V853芯片包含两个CPU。一个是主核心Arm A7 CPU，运行Tina Linux（全志自研Linux）系统，为芯片主系统；一个是RISC-V E907辅助CPU，运行Melis（全志自研RTOS）系统，主要功能是提供通用算力补充、辅助 Linux 实现快起和低功耗管理等功能。

A7 – Linux系统

V853主核心 A7上运行的是Tina Linux系统。Tina Linux是全志针对AIoT类产品，基于Linux内核深度定制的嵌入式系统。

在 Tina Linux 中，提供 AMP 与 RPMsg 对接 E907

1.Linux remoteproc 管理控制 E907
2.RPMsg 与 E907 通讯

E907 – RTOS系统

V853 辅助核心 E907 上运行的是全志自研 RTOS 系统 Melis。其独立于 A7 主核心中的 Linux 系统。可以独立运行。

在 E907 Melis 中，提供 OpenAMP 软件框架来与 A7 Linux 系统进行通信。

1.提供了处理器的生命周期管理（LCM，Life Cycle Management），与 Linux 的 remoteproc 兼容
2.提供了处理器间的消息传输机制，与 Linux 的 RPMsg 兼容

异构系统启动流程

首先，由芯片内部的 BORM 寻找启动介质，在 V853 开发板上便是 eMMC 储存器。找到启动介质后会运行其中的 BOOT0 代码。BOOT0 会在 A7 主核心中运行 Linux 系统，也会在 E907 核心中运行 RTOS 系统。启动的两个系统是独立运行的。

异构系统的通信

V853 的异构系统通讯在硬件上使用的是 MSGBOX，在软件层面上使用的是 AMP 与 RPMsg 通讯协议。其中 A7 上基于 Linux 标准的 RPMsg 驱动框架，E907基于 OpenAMP 异构通信框架。

V853 所带有的 A7 主核心与 E907 辅助核心是完全不同的两个核心，为了最大限度的发挥他们的性能，协同完成某一任务，所以在不同的核心上面运行的系统也各不相同。这些不同架构的核心以及他们上面所运行的软件组合在一起，就成了 AMP 系统（Asymmetric Multiprocessing System, 异构多处理系统）。

由于两个核心存在的目的是协同处理，因此在异构多处理系统中往往会形成 Master – Remote 结构。主核心启动后再启动辅助核心。当两个核心上的系统都启动完成后，他们之间就通过 IPC（Inter Processor Communication）方式进行通信，而 RPMsg 就是 IPC 中的一种。

在AMP系统中，两个核心通过共享内存的方式进行通信。两个核心通过 AMP 中断来传递讯息。内存的管理由主核负责。

AMP 系统在每个通信方向上都有两个缓冲区，分别是 USED 和 AVAIL，这个缓冲区可以按照 RPMsg 中消息的格式分成一块一块链接形成一个环。

当主核需要和从核进行通信的时候可以分为四步：

主核先从USED中取得一块内存（Allocate）
将消息按照消息协议填充
将该内存链接到 AVAIL 缓冲区中（Send）
触发中断，通知辅助核有消息处理

反之，从核需要和主核通信的时候也类似：

主核先从AVAIL中取得一块内存（Allocate）
将消息按照消息协议填充
将该内存链接到 USED 缓冲区中（Send）
触发中断，通知主核有消息处理。

既然 RPMsg 是一种信息交换的协议，与TCP/IP类似，RPMsg 协议也有分层，主要分为三层，分别是传输层、MAC层和物理层。

其中 MAC层的 VirtIO 是一种I/O 半虚拟化解决方案，是一套通用 I/O 设备虚拟化的程序，是对半虚拟化 Hypervisor 中的一组通用 I/O 设备的抽象。提供了一套上层应用与各 Hypervisor 虚拟化设备之间的通信框架和编程接口，减少跨平台所带来的兼容性问题，大大提高驱动程序开发效率。

RPMsg 总线上的消息都具有以下结构，包含消息头和数据两个固定的部分，该消息格式的定义位于drivers/rpmsg/virtio_rpmsg_bus.c中，具体定义如下：

异构系统的控制

在异构系统中，不止需要消息的传输，还需要相关控制。例如主核对辅助核心的开启，加载固件，关闭等等。这就需要用到 remoteproc 框架。

remoteproc 框架支持对不同平台，不同架构的处理器进行控制，可以监控辅助核心的运行情况。

对于 V853 来说，remoteproc 用于对 E907 进行生命周期管理，一般来说包含有加载固件、检测远端处理器是否崩溃等功能。它在加载远端处理器的固件时，会根据固件中定义的 resource table 来申请资源，并创建 VirtIO 设备。

本文分享自微信公众号 – 全志在线

本文为全志在线开发者社区整理的详解全志V853上的ARM A7和RISC-V E907之间的通信方式

文章目录

1.简介
2.接口介绍
- 开发流程
- 接口说明
3.使用
- 3.1环境准备
- 3.2下载并加载python驱动
- 3.3创建数据库连接用户
- 3.4示例
4.常见报错

1.简介

Psycopg是一种用于执行SQL语句的PythonAPI，可以为PostgreSQL、openGauss数据库提供统一访问接口，应用程序可基于它进行数据操作。Psycopg2是对libpq的封装，主要使用C语言实现，既高效又安全。它具有客户端游标和服务器端游标、异步通信和通知、支持“COPY TO/COPY FROM”功能。支持多种类型Python开箱即用，适配PostgreSQL数据类型；通过灵活的对象适配系统，可以扩展和定制适配。Psycopg2兼容Unicode和Python 3。
openGauss数据库提供了对Psycopg2特性的支持，并且支持Psycopg2通过SSL模式链接。

2.接口介绍

开发流程

接口说明

openGauss提供了如下接口供开发者使用：

psycopg2.connect()
此方法创建新的数据库会话并返回新的connection对象（连接openGauss数据库实例的对象）。

conn=psycopg2.connect(dbname=“test”,user=“postgres”,password=“secret”,host=“127.0.0.1”,port=“5432”)

或者

conn = psycopg2.connect(“dbname=test user=postgres password=secret
host=127.0.0.1 port=5432”)

创建连接对象（SSl连接）

conn = psycopg2.connect(dbname=“postgres”, user=“user”, password=“password”, host=“localhost”, port=port, sslmode=“verify-ca”, sslcert=“client.crt”, sslkey=“client.key”, sslrootcert=“cacert.pem”)

注意：如果sslcert, sslkey,sslrootcert没有填写，默认取当前用户.postgresql目录下对应的client.crt， client.key， root.crt

connection.cursor()
此方法用于返回新的cursor对象（用于整个数据库使用Python编程的cursor）。

cursor(name=None, cursor_factory=None, scrollable=None,
withhold=False)

cursor.execute(query,vars_list)
此方法执行被参数化的SQL语句（即占位符，而不是SQL文字）。psycopg2模块支持用％s标志的占位符。

curosr.execute(query,vars_list)

curosr.executemany(query,vars_list)
此方法执行SQL命令所有参数序列或序列中的SQL映射。

curosr.executemany(query,vars_list)

connection.commit()
此方法将当前挂起的事务提交到数据库。默认情况下，Psycopg在执行第一个命令之前打开一个事务：如果不调用commit()，任何数据操作的效果都将丢失。

connection.commit()

connection.rollback()
此方法回滚当前挂起事务。执行关闭连接“close()”而不先提交更改“commit()”将导致执行隐式回滚。

connection.rollback()

cursor.fetchone()
此方法提取查询结果集的下一行，并返回一个组。返回单个组，为结果集的第一条结果，当没有更多数据可用时，返回为“None”。

cursor.fetchone()

cursor.fetchall()
此方法获取查询结果的所有（剩余）行，并将它们作为组列表返回。返回组列表，为结果集的所有结果。空行时则返回空列表。

cursor.fetchall()

cursor.close()
此方法关闭当前连接的游标。

cursor.close()

connection.close()
此方法关闭数据库连接。此方法关闭数据库连接，并不自动调用commit()。如果只是关闭数据库连接而不调用commit()方法，那么所有更改将会丢失。

connection.close()

3.使用

3.1环境准备

本篇使用环境信息：

华为云HECS 2核4G
CentOS Linux release 7.6
Python 3.6.8
openGauss 3.1.0 极简版

3.2下载并加载python驱动

1、可以在openGauss官网下载后用FTP工具比如winscp等上传到服务器，也可以直接在服务器上用wget方式获取，根据操作系统版本下载对应的驱动。

root用户下新建存放目录，执行wget和解压命令。

解压后有两个文件夹 lib和psycopg2，分别放置对应的库文件。
2、在解压后的路径下执行拷贝命令，将驱动拷贝到python3下的site-packages目录

3、修改psycopg2/目录权限为755

4、对于非数据库用户，需要将解压后的lib目录，配置在LD_LIBRARY_PATH中。

3.3创建数据库连接用户

注意，由于psycopg2只能使用MD5方式连接，而openGauss默认安装时使用sha256加密，所以这里需要修改一下配置。
修改 data/single_node/postgresql.conf 中password_encryption_type = 1 ，表示支持md5和sha256。
修改pg_hba.conf 中加密算法

然后重启openGauss：gs_ctl restart -D /opt/software/openGauss/data/single_node
连接到openGauss创建用户和数据库。

如果在修改加密方式前之前已经创建过用户了，需要在配置文件修改及数据库重启完成后，重新建用户或者设置用户密码。

3.4示例

编写python文件

将如下测试语句拷贝进去，根据实际情况修改对应的openGauss数据库连接信息。

连接测试

报错了,psycopg2.OperationalError: SCRAM authentication requires libpq version 10 or above

解决办法：
根据提示升级版本

根据提示输入y,等提示Complete!
重新测试连接

注意，如果使用本地工具连接远端云服务器的数据库时，需要修改云服务器安全组，将openGauss的端口放开，否则会连接不上。

4.常见报错

执行python3 ogconn.py报错
1.提示如下错误
File “/opt/software/psycopg2/psycopg2/init.py”, line 122, in connect
conn = _connect(dsn, connection_factory=connection_factory, kwasync)
psycopg2.OperationalError: SCRAM authentication requires libpq version 10 or above

这个错是说libpq版本应该在10以上，需要升级下版本。
解决办法：

根据提示输入y,等提示Complete!

2.提示如下错误：
psycopg2.OperationalError: none of the server’s SASL authentication mechanisms are supported
这个就是加密方式的问题，参考文章中“创建数据库连接用户”部分解决。

欢迎大家测试、交流！

🍒如果您觉得博主的文章还不错或者有帮助的话，请关注一下博主，如果三连点赞评论收藏就更好啦！谢谢各位大佬给予的支持！

主要更新：

1. simple admin tools 升级至 v0.1.0

2. 新增基于Ent 的 CRUD 代码生成，快速生成 RPC 服务

3. 新增基于 Proto 文件的 CRUD 代码生成，快速生成 api 网关逻辑代码

4. 新增代码生成文档

5. 优化api请求路径

6. 新增错误类型

7. 修复多个 bugs

即将支持

前端代码生成，尽请期待

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

UEditor是由百度开发的所见即所得的开源富文本编辑器，基于MIT开源协议，该富文本编辑器帮助不少网站开发者解决富文本编辑器的难点。

UEditorPlus 是有 ModStart 团队基于 UEditor 二次开发的富文本编辑器，主要做了样式的定制，更符合现代浏览器的审美。

在开发过程中解决了部分使用上的Bug，期待更多伙伴一期加入维护。

v2.7.0亮点介绍

附件优化，附件默认样式全部优化，附件图标替换为SVG格式，样式美观大方。

编辑器文档重新整理发布，方便二次开发和使用。

版本介绍

UEditorPlus v2.7.0 已经发布。

新增：开放UEditorPlus使用文档独立站
优化：优化OSX系统编辑器字体显示问题
优化：附件显示样式调整，图标替换为SVG
优化：源码模式下光标显示错位问题优化
修复：源码模式下内容编辑不生效问题修复

关于Bug反馈与维护

众所周知 UEditor 使用的人数多，目前已经累积了N个Bug，开源不易需要大家共同维护
对于在实际使用中遇到的问题，如果急需解决推荐使用悬赏Issue ，这样让更多有能力的开发者有共同维护的动力

在线演示

https://open-demo.modstart.com/ueditor-plus/_examples/

在线文档

https://open-doc.modstart.com/ueditor-plus/

开源地址

国内：https://gitee.com/modstart-lib/ueditor-plus
国外：https://github.com/modstart-lib/ueditor-plus

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

4.12.5 – 正式版更新详情:

build

spring-boot > 2.7.6
nacos.version > 2.1.2
spring-boot-admin.version>2.7.7
jasypt.version>3.0.4
aliyun-java-sdk-core.version>4.6.2
esdk-obs-java.version>3.22.3.1
qiniu-java-sdk.version>7.12.0
gson.version>2.8.9
jsoup.version>1.15.3
JustAuth.version>1.16.5
okhttp3.version>4.10.0

feat

新增员工、岗位、部门等业务 @Echo回显的具体实现
演示环境拦截器启用IP白名单放行功能，方便特定IP的管理员操作数据，并拦截其他IP非法操作数据。

refactor

spring.factories 文件替换为 org.springframework.boot.autoconfigure.AutoConfiguration.imports
特定的样式环境禁止取消应用授权和解绑用户
优化 okhttp3.OkHttpClient 配置
删除 HuaweiFileStrategyImpl 中无用代码
排除三方组件中低版本okhttp，固定使用okhttp 4.10.0

fix

升级后，原写法 `applicationContext.getBean(RequestMappingHandlerMapping.class)` 会报错，替换为 `(RequestMappingHandlerMapping) applicationContext.getBean(“requestMappingHandlerMapping”)`

本次更新主要是为后续升级SpringBoot3奠定基础。

更多功能，等你来体验：

《灯灯》官网： https://tangyh.top/
4.x 数据源模式体验地址： https://datasource.tangyh.top/
4.x 字段模式体验地址： https://column.tangyh.top/
4.x 非租户模式体验地址： https://none.tangyh.top/
3.x 体验地址 1： https://boot.tangyh.top/
3.x 体验地址 2： https://boot.tangyh.top/lamp-web/

《灯灯》中后台快速开发平台

如果你非要说 lamp 是 Linux+Apache+MySQL+PHP，那就算是吧，毕竟 PHP 是世界上最好的语言，我也希望此项目成为世界上最好的后台框架！😈😈😈

基于 jdk11/jdk8 ++ SpringCloudAlibaba+ 的微服务快速开发平台，专注于解决 SaaS 多租户体系问题，具备 RBAC 功能、网关统一鉴权、Xss 防跨站攻击、自动代码生成、多种存储系统、分布式事务、分布式定时任务等多个模块，支持多业务系统并行开发，支持多服务并行开发，可以作为后端服务的开发脚手架。代码简洁，注释齐全，架构清晰，非常适合学习和企业作为基础框架使用。

核心技术采用 Spring Cloud Alibaba、SpringBoot、Mybatis、Seata、Sentinel、RabbitMQ、FastDFS/MinIO、SkyWalking 等主要框架和中间件。希望能努力打造一套从 – – – 的解决方案。

技术栈

开发方面：
- JSON 序列化：Jackson
- 消息队列：RabbitMQ
- 缓存：Redis
- 数据库： MySQL 5.7.9 或者 MySQL 8.0.19
- 定时器：采用 xxl-job 项目进行二次改造
- 前端 1 (后台管理)：vue2 + element-ui
- 前端 2 (后台管理)：vue3 + ant-design-vue + vite + TypeScript
- 持久层框架： Mybatis-plus
- 代码生成器：基于 Mybatis-plus-generator 自定义
- API 网关：Gateway
- 服务注册 & 发现和配置中心: Nacos
- 服务消费：OpenFeign
- 负载均衡：Ribbon
- 服务熔断：Sentinel
- 项目构建：Maven
- 分布式事务： seata
- 文件服务器：FastDFS 5.0.5 / 阿里云 OSS / 本地存储 / MinIO / 华为云 / 七牛云
监控方面：
- 监控： spring-boot-admin
- 链路调用跟踪： SkyWalking
- 分布式系统的流量防卫兵： Sentinel
部署方面：
- 服务器：CentOS
- Nginx
- Jenkins
- Docker
- Kubernetes

项目截图：

预览预览

12月5日，DataEase开源数据可视化分析平台正式发布v1.17.0版本。

这一版本的功能升级包括：数据集方面，支持将数据集数据按指定条件导出为Excel文件，方便用户对权限范围内的数据进行二次处理。数据集字段支持日期解析格式设置，解决了日期过滤组件无效的问题；仪表板方面，Tab组件新增轮播功能，以满足多屏内容自动切换的需求；悬浮模式下组件支持精确位置设置和大小设置，用户可以制作更加精细的仪表板；视图方面，新增横向百分比柱状图。同时AntV图库的所有柱状图、面积图、仪表盘新增渐变色支持，对视图展示效果做了增强。

X-Pack增强功能方面，DataEase新增仪表板水印设置，用户可以为仪表板添加水印，保护自己的数据版权；数据集支持脱敏规则设置，用户可以通过制定多样的规则来保护用户的数据安全；定时报告新增对富文本支持，报告内容更加丰富多彩。

另外，我们还对其他一些常用的功能进行了功能优化和问题修复。

新增功能

■ 视图：AntV图库的柱状图、面积图、仪表盘等新增渐变色支持，展示效果更丰富

数据可视化工具除了清晰准确地表达数据内在意义以外，良好的展示效果对于用户的使用体验也很重要。在v1.17.0版本中，DataEase对AntV图库中的所有柱状图、面积图以及仪表盘均增加了渐变色的支持，丰富了这些图表类型的展示效果。

■ X-Pack增强包：定时报告新增富文本支持，报告内容更精彩

在DataEase v1.17.0之前的版本中，定时报告中的报告内容只能添加普通文本内容，不支持用户添加图片、链接等内容。

在v1.17.0版本中，DataEase将报告内容使用的普通文本编辑器替换为富文本编辑器，用户可以在报告内进行字体设置、文字排版、内容编号等操作，也可以添加诸如图片、超链接等素。

此外，DataEase对目前所支持的邮件、企业微信、钉钉、飞书、飞书国际版等所有报告分发渠道均进行了富文本的适配，用户无论通过哪个渠道发送报告，都可以获得内容丰富、形式多彩的报告。

■ X-Pack增强包：仪表板支持水印设置，数据分享更放心

随着企业数字化的推广与普及，企业用户日益重视保护数字产品的版权和完整性，并开始关注防复制或去向追踪的相关技术。

在v1.17.0版本中，DataEase加入了对水印设置的支持，用户可以将DataEase账号、昵称、IP和系统当前时间进行自由组合，形成水印内容。设置的水印将会影响所有仪表板展现的场景，包括仪表板预览、报告、PDF导出等。对数据安全具有较高要求的用户，还可以强制要求所有仪表板必须带有水印。

■ X-Pack增强包：数据集新增脱敏规则设置，数据展示更安全

在v1.17.0版本之前，DataEase为数据集数据提供了简单的脱敏处理功能，可以将指定字段的源数据用“*”号进行替代展示。但在某些情况下，用户希望一些类型的数据仅屏蔽关键部分的信息，而非完全屏蔽所有信息，例如屏蔽身份证号、手机号、人名等。用户仅需隐藏这些数据的中间部分，这样既可以看到省份、手机归属地等信息，又很好地把生日、具体号码、姓名等隐私信息进行了脱敏处理。

DataEase v1.17.0版本中新增数据脱敏规则支持，用户可以指定数据全脱敏、指定头尾位数脱敏、指定中间位数脱敏等脱敏规则，有效满足用户个性化的数据处理需求，让敏感数据在展示时更加安全。

除了上述新增功能外，DataEase v1.17.0版本还包含了很多其他的功能更新和优化，欢迎进入我们的官方文档及GitHub仓库的Release页面查看更加详细的更新日志。

功能优化

■ refactor（数据源）：调整数据源类型选择页的样式（#3814）；

■ refactor（仪表板）：组件样式设置中，边框浏览背景颜色支持自适应；

■ refactor（仪表板）：优化仪表板过滤组件中表格等组件的自适应缩放方式，防止组件在仪表板不同分辨率下出现组件大小不适配问题；

■ refactor（仪表板）：优化置顶置底逻辑，以适配新画布（#3905）；

■ refactor（视图）：富文本视图允许修改标题；

■ refactor（视图）：优化批量操作逻辑；

■ refactor（应用）：优化应用模板界面，防止因误触导致关闭信息填写页面的问题（#3854）；

■ refactor（插件）：优化插件显示效果；

■ refactor：优化数据源类型的展示效果；

■ refactor：NPM（NodePackage Manager）缓存清理。

Bug修复

■ fix（数据源）：修复添加API数据源时大小写无法作为区分不同字段名的依据的问题（#3424）；

■ fix（数据集）：修复关联数据集保存出错问题（#3426）；

■ fix（数据集）：修复API数据集存在空数据时导致定时任务同步报错的问题（#3668、#3792）；

■ fix（数据集）：修复MongoDB表名中带“-”号时创建数据集失败的问题（#3160）；

■ fix（仪表板）：修复开启辅助网格模式后矩阵和悬浮视图重叠的问题（#3717）；

■ fix（仪表板）：修复Tab下加入多个视图，公共链接打开后，饼图的图示内折叠切换按钮不可用的问题（#3761）；

■ fix（视图）：修复地图缩放功能异常（#3782）；

■ fix（视图）：修复PG数值类型长度不够的问题（#3632、#3745）；

■ fix（应用）：修复含有关联数据集的应用导入后关联数据集报错的问题（#3714）；

■ fix：修复dectl脚本错误（#3683）。

Go 语言通用代码生成器仙童发布尝鲜版十一，兼容Java通用代码生成器的Excel模板

GO语言通用代码生成器：仙童尝鲜版十一。在尝鲜版十基础上有增强和修错，并支持数据库表与字段的中文注释和兼容所有java通用代码生成器的SGS2模板，直接生成go语言后端和Vue前端，并自动格式化java语言SGS2模板至go语言模板。支持三大变形功能群，支持四种数据库，支持Excel数据导出。支持复杂版面和图形报表。

尝鲜版十一最大特点是兼容Java通用代码生成器的Excel模板。您需要打开“使用Java兼容性”复选框，系统即可使用java通用代码生成器光，和平之翼代码生成器和无垠式代码生成器的SGS2模板（即Excel模板）生成go语言的代码生成物。唯一的不同是仙童的daoimpl,serviceimpl的包名不支持点号，您需要把文件夹设为单层即可。

仙童第一个稳定版，是尝鲜版十。功能基本完备，所有示例通过检测，并初步完整测试。

在尝鲜版九至尝鲜版十的研发中，克服了许多困难。终于得到了一个功能初步完整，没有已知缺陷，而且数据库和登录模块和 java 通用代码生成器光 2.3.0 文明 Beta8 版完全兼容的版本。这是仙童的新起点。大概至尝鲜版十二，仙童即可进入 Beta 版本阶段。

Go 语言通用代码生成器：仙童，已发布最新视频，演示了 SimpleAuth 弹性登录模块的使用。
视频请见：

https://www.bilibili.com/video/BV1a5411R7Zt/

https://www.bilibili.com/video/BV1pR4y1w7aB/

Go 语言通用代码生成器：仙童，已有重大功能增强，新增弹性登录模块 SimpleAuth。实现了弹性登录认证功能，现在功能已完整，前端支持动态菜单功能。
Go 语言通用代码生成器：仙童尝鲜版十拥有卓绝的变形能力。支持三大变形功能群即动态椰子树功能群，动词否定功能群和字段否定功能群。其 SimpleAuth 弹性登录模块是全自动的弹性登录模块，高度可配置。其三个模块的域对象都可以动态配置。系统自动完成编译检查，并生成符合要求的登录模块。
现在仙童已支持前端和后端复杂版面和图形报表功能。现已支持 Vue 和 ElementUI 的独立前端，一键生成双系统。现在支持 MariaDB,MySQL8,PostgreSQL 和 Oracle 四种数据库。多惊喜等着您去发现。
弹性登录模块 SimpleAuth 弹性模块包含了前端和后端功能，实现了登录认证功能。密码，角色权限功能都有自动数据增强。一键生成。已实现完整的角色和权限功能。

仙童的项目地址：https://gitee.com/jerryshensjf/Fairchild

二进制版本下载地址：https://gitee.com/jerryshensjf/Fairchild/attach_files

项目图片：

独立前端截图：

vue 前端复杂版面：树表

vue 前端图形报表

柱状图：

折线图：

代码生成物后端登录页面：

后端内页：

自从我们提供公共镜像库以来，不少同学询问是否支持手工上传镜像到镜像库。答案是：不支持。

今天给大家聊一聊为什么公共镜像库不应该支持手工上传，主要基于以下几个方面的考量：

Code First

建木作为一个完整实现GitOps理念的工具，开发团队在实现任何服务时所秉承和推广的当然也首选Code First的方式。

因此，我们提供的公共镜像库与GitHub和国内的Gitee都实现了集成，用户授权后可以直接选择代码库中的Dockerfile来进行镜像的构建，后续还会完成与更多代码托管平台的集成。

当然也支持根据分支、Tag等来设置自动构建计划的规则。

一旦使用了Code First的方式，用户就无需自己维护构建服务器或者在本地手工进行镜像构建。

镜像的变更与版本记录与镜像构建的过程一一对应，可追溯可审计，完美符合当前主流的工程理念。

便于生成软件物料清单(SBOM)

不提供手工上次镜像的功能的另一个理由是保证公共库镜像的安全性。最近的研究报告显示，恶意镜像已经成为软件供应链攻击中的攻击手段。而软件物料清单(SBOM)是应对软件供应链攻击的工具之一。

什么是SBOM

软件物料清单 (SBOM) 是一份正式记录，其中包含用于构建软件的各种组件的详细信息和供应链关系。BOM(物料清单)的说法来源于制造业的MES系统，简单说就是类似成分列表。当然BOM也可以包含层次结构，可以层层包含，列表中的组成部分可以继续拆分为子BOM。

在最新的OCI镜像标准中，已经有了推荐的SBOM的描述规范，但是如何生成SBOM并且进行可信的数字签名对于大部分用户仍然是个问题。

因此，建木Hub后续也将在镜像构建过程中增加相关的支持来降低针对公共镜像的软件供应链攻击风险。

上行带宽占用

众所周知，维护一个公共镜像库需要相当高的成本。因此建木Hub目前使用了CDN来优化镜像下载速度和降低镜像下载的流量成本，但是如果开放手工Push镜像功能，对于上行带宽和流量的成本暂时还没有好的优化方案。

总结

基于以上考量，建木Hub的公共镜像仓库不会开通手工上传镜像的功能。当然，随着产品的迭代完善，我们将会在私有镜像仓库中提供手工上传镜像的功能。如果大家确实需要，敬请期待。

最后，放上我们的服务地址。建木Hub 欢迎使用！

从 Android 12 开始，Google 就在 Android 系统中带来了 Rust 语言的支持，作为 C/C++ 的替代方案，他们的目标并不是把现有的 C/C++ 代码都转换成为 Rust，而是在新编写的代码中使用 Rust 语言开发。

通过将越来越多的 Rust 代码集成到其 Android 操作系统中，Google 在减少漏洞方面的努力最终是获得了回报。

Google 在公告中表示，”在过去几年/几个 Android 系统版本中，内存安全漏洞的数量大幅下降”。

具体而言，2019 年至 2022 年期间，每年的内存安全漏洞数量从最初的 223 个下降到如今的 85 个。内存安全漏洞现在在 Android 系统总漏洞的占比也只有 35%，四年前的占比则是 76%，而且 2022 年也是内存安全漏洞首次不再是 Android 系统漏洞最大占比的一年。

在此期间，进入 Android 系统的新内存不安全代码的数量也已经减少。

Rust 占了 Android 13 所有新的原生代码的 21%，在 AOSP 中已经有大约 150 万行 Rust 代码，涵盖各种功能和件，其中就包括超宽带（UWB）栈、DNS-over-HTTP3、Keystore2、Android 的虚拟化框架（AVF），以及各种其他组件及其开源依赖。

到目前为止，在整个 Android 12 和 13 系统中，Rust 代码中发现的内存安全漏洞为零，这是一个重要的发现，因为过去 Android 漏洞密度大于 1/kLOC，也就是说，每一千行代码至少会发现一个漏洞，基于 Rust 代码的行数来看，此举可能已经阻挡了成百上千个漏洞进入 Android 系统。

2022年11月30日，国内知名开源技术社区OSCHINA（开源中国）公布了“2022年度优秀开源技术团队”获奖名单。openKylin（开放麒麟）凭借在开源技术创新和开源社区运营方面的积极表现，荣获“2022年度优秀开源技术团队”奖项。

作为国内首个桌面操作系统根社区，openKylin社区自成立以来便积极推动开源生态建设。截至目前，已有131家企业加入社区，包括操作系统厂商、CPU厂商、GPU厂商、整机厂商、以及软件厂商等，并成立了56个SIG组开展各类技术研究和创新。

此番获奖不仅是openKylin社区的荣誉，也是全体社区成员的共同荣誉，是大家共同努力的结果，促使openKylin社区蓬勃发展。未来，openKylin社区也将保持初心，为构建良好开源生态发展持续努力。

openKylin（开放麒麟）社区旨在以“共创”为核心，在开源、自愿、平等、协作的基础上，通过开源、开放的方式与企业构建合作伙伴生态体系，共同打造桌面操作系统顶级社区，推动Linux开源技术及其软硬件生态繁荣发展。

社区首批理事成员单位包括麒麟软件、普华基础软件、中科方德、麒麟信安、凝思软件、一铭软件、中兴新支点、心科技、中国电科32所、技德系统、北京麟卓、先进操作系统创新中心等13家产业同仁和行业机构。

审核：openKylin

摘要：华为云Solution as Code重磅推出《基于MetaTown构建数字资产平台》解决方案。

本文分享自华为云社区《基于MetaTown构建数字资产平台》，作者：阿米托福。

华为云Solution as Code重磅推出《基于MetaTown构建数字资产平台》解决方案，由华为云数字资产链支撑底层区块链技术，实现数字资产的铸造、发行、流转、确权等全生命周期管理。同时，推出一键部署的解决方案和快速体验版本，并开放源代码，帮助中小企业快速构建属于自己的数字资产平台。

基于MetaTown构建数字资产平台

一、NFT市场前景

目前，在国内，NFT在数字藏品与数字营销等场景率先大规模落地。2021年被称为“数字藏品”的年，数字藏品共创造了超816万总交易量和超65亿美的总交易额。截至到2022年5月，国内数字藏品平台超过450家，Top50家平台销售藏品500万份，销售额达到2亿。预测2023年度数字藏品国内云市场空间达到3亿。

二、NFT场景痛点需求

1. 唯一性

NFT需要利用区块链技术赋予其唯一性和不可篡改性。同时，还需要利用数字资产链平台，实现数字资产的确权、可信保存和安全交易。在国内NFT多使用联盟链，搭载区块链是否为自主研发，共识机制和验证节点是否具有权威度和信誉度已然成为中国数字资产交易平台的评价指标。

2. 实名认证

区块链信息服务提供者应当按照《中华人民共和国网络安全法》的规定，对区块链信息服务使用者进行基于组织机构代码、身份证件号码或者移动电话号码等方式的真实身份信息认证。用户不进行真实身份信息认证的，区块链信息服务提供者不得为其提供相关服务。

3. 高并发、弹性业务场景

在数字资产秒杀场景下，由于大量玩家涌入，业务高并发，常常会出现应用无法访问，无法支付等崩溃的情况。此外，数字资产大多情况都是限时发售，就会存在明显的浪涌现象，如何从容度过业务高峰又不至于造成资源浪费成为客户迫切需求。

4. 图片及多媒体存储

数字资产品类丰富，目前以数字图片，3D模型，视频等形式为主，大量发行时需要大量存储空间，且需支持加速访问。

三、基于MetaTown数字资产平台

该解决方案基于华为云开源项目MetaTown，可以帮助您在华为云上快速构建自己的数字资产管理平台。MetaTown 是利用华为云数字资产链DAC提供的底层区块链技术构建的数字资产管理平台，可以实现数字资产的铸造、发行、流转、确权等全生命周期管理。

基于MetaTown构建数字资产平台

能力一：数字资产链DAC

数字资产链（Digital Asset Chain，简称DAC）采用NFT技术，是华为云自研的数字资产链平台，基于华为云区块链引擎，通过时间戳、智能合约等技术创新，可实现数字资产的确权、可信保存、安全交易。支持多种形式的原创数字产品的版权保护，获得由中国版权保护中心分配的数字版权唯一标识符。版权交易流转过程清晰可循，具有公信力。同时，提供侵权监测、证据固证、版权鉴定等能力，快速解决版权纠纷。

能力二：人证核身

人证核身服务IVS通过身份证信息、人脸图片，与权威数据库进行比对，进而实现身份验证。该服务可以帮助客户快速核验区块链信息服务使用者的身份，满足法律法规要求。

能力三：分布式缓存

通过集成分布式缓存服务 Redis，支持藏品数据放入缓存，加快客户端访问速度，提高购买体验。

能力四：数字资产存储

数字资产链提供丰富的资产存储管理接口，支持图片、视频、音频、3D模型、文本等富媒体的一键存储，安全、高可靠、类型丰富。NFT数据存储到对象存储服务OBS，从OBS里面直接下载，提供单桶EB级存储能力，满足NFT数据存储诉求，拥有超高性能，支持千万级TPS，2.4Gb/s单流上传速度。

基于此， MetaTown数字资产平台具有三大优势：

（1）超高性能。华为云数字资产链 DAC支持五万次/秒并发链上数字资产创建，支持百亿级数字资产发行流转。

（2）支持一键部署。用户可以基于官方示例模板，一键部署各项云服务资源，快速构建 MetaTown数字资产平台。

（3）开源和定制化。解决方案已开源，用户可以免费用于商业用途，并且还可以在源码基础上进行定制化开发，以满足复杂多样的NFT业务场景。

四、MetaTown方案应用场景

基于MetaTown构建数字资产平台解决方案覆盖多行业，满足各种数字资产场景需求：

场景1：文旅行业

数字藏品是指使用区块链技术，对应特定的作品、艺术品生成的唯一数字凭证，在保护其数字版权的基础上，实现真实可信的数字化发行、购买、收藏和使用。将文物藏品、艺术品等通过实体数字化映射、数据上链等技术手段赋予了数字藏品额外价值，供消费者收藏，极大提升艺术品的变现能力。

场景2：数字营销

品牌零售业NFT数字营销，获取私域流量、直接形成销售转化、积累客户数据是品牌数字化营销的主要目标。数字藏品作为品牌理念载体，品牌价值与数字商品的结合体，即“品牌价值+数字带货”。不仅承载了品牌内容，还能与实体产品结合。数字藏品还是品牌传播介质，通过权益、徽章、门票、礼盒等形式进行展现，链接用户互动场景。

场景3：游戏

将游戏道具、资产或IP周边数字资产化，数字资产可流通、变现，从而扩大用户量、增加用户粘性。游戏IP孵化、游戏场景创新是目前游戏厂商面临巨大挑战，尤其游戏版号限制下，减少厂商试错机会，对游戏出品要求更高。预先通过数字资产发行流转等预测用户喜爱情况，有助于创新决策。

目前《基于 MetaTown 的数字资产平台》已上线华为云官网。华为云云宝NFT也已发布在体验网址，快来体验吧！

关注，第一时间了解华为云新鲜技术~

本文基于 KubeSphere 可观测性与边缘计算负责人霍秉杰在北美 KubeCon 的 Co-located event Open Observability Day 闪电演讲的内容进行整理。

整理人：米开朗基杨、大飞哥

Fluent Operator 简介

2019 年 1 月 21 日，KubeSphere 社区为了满足以云原生的方式管理 Fluent Bit 的需求开发了 FluentBit Operator，并在 2020 年 2 月 17 日发布了 v0.1.0 版本。此后产品不断迭代，一直维护到 v0.8.0，实现了 Fluent Bit 配置的热加载，而无需重启整个 Fluent Bit 容器。2021 年 8 月，Kubesphere 团队将该项目捐献给 Fluent 社区，并从 v0.9.0 一直持续迭代到 v0.13.0。

2022 年 3 月，FluentBit Operator 正式更名为 Fluent Operator，因为我们增加了对 Fluentd 的支持，而且把 FluentBit CRDs 定义范围从命名空间扩大到集群级别，并于 2022 年 3 月 25 日发布了里程碑版本 v1.0.0。

整体架构预览

Fluent Operator 可以构建完整的云原生日志采集通道。FluentBit 小巧轻量，适合作为 Agent 收集日志；Fluentd 插件丰富功能强大，适合对日志进行集中处理，二者可以独立使用，也可以协作共存，使用方案非常灵活。

仅使用 Fluent Bit 收集日志

Fluent Operator 可以非常便捷地部署 FluentBit Daemonset 服务，运行于各计算节点。当然集群层级的 FluentBit CRD 也可以配置各种 Input，Filter，Parser，Output 等。Fluent Bit 支持将日志直接导出到 ElasticSearch，Kafka，Loki，S3 等众多目标服务，这些只需配置 CRD 即可。

仅使用 Fluentd 收集日志

Fluent Operator 可以非常便捷地将 Fluentd 部署为 Statefulset 服务，应用可以通过 HTTP，Syslog 等方式发送日志，同时 Fluentd 还支持级联模式，即 Fluentd 可以接收来自另一个 Fluentd 服务的日志。类比于 Fluent Bit，Fluentd 也支持集群级别的 CRD 配置，可以方便的配置 Input，Filter，Parser，Output 等。Fluentd 内置支持上百种插件，输入输出都非常丰富。

同时使用 Fluentd 和 Fluent Bit

Fluentd 和 Fluent Bit 在设计架构上极为相似，都有着丰富的社区插件支持，但二者侧重的使用场景有所差异。Fluent Bit 小巧精致，资源消耗少，更适合作为 Agent 来采集日志，而 Fluentd 相对前者功能更加丰富，作为数据中转站或数据治理服务更为贴切。所以绝大多数场景中，二者配合可以构建出灵活高效且扩展性极强的日志收集流水线。

v1.0 后的重要更新

至 Fluent Operator 发布 v1.0.0 至今，仍然在高速迭代。v1.1.0 版本新增了对 OpenSearch 输出的支持；v1.5.0 新增了对 Loki 输出的支持，同时还增加了对监控指标（Metrics）采集的支持，支持清单如下：

Node Exporter 指标采集
Prometheus Scrape 指标采集
Fluent Bit 指标采集
Prometheus 远程写入的输出信息采集
OpenTelemetry 输出采集

正是基于对监控指标采集的支持，Fluent Operator 才可以完美构建云边统一的可观测性。

以上内容关注的是对云端资源的数据采集，下面我们来看看 Fluent Operator 在边缘计算场景下的支持情况。

我们使用的边缘计算框架是 KubeEdge，下面我给大家介绍下 KubeEdge 这个项目。

KubeEdge 介绍

KubeEdge 是 CNCF 孵化的面向边缘计算场景、专为边云协同设计的云原生边缘计算框架，除了 KubeEdge 之外还有很多其他的边缘计算框架，比如 K3s。K3s 会在边缘端创建完整的 K8s 集群，而 KubeEdge 只是在边缘端创建几个边缘节点（Edge Node），边缘节点通过加密隧道连接到云端的 K8s 集群，这是 KubeEdge 与 K3s 比较明显的差异。

KubeEdge 的边缘节点会运行一个与 Kubelet 类似的组件叫 Edged，比 Kubelet 更轻量化，用来管理边缘节点的容器。Edged 也会暴露 Prometheus 格式的监控指标，而且暴露方式和 Kubelet 保持一致，都是这种格式：。

统一可观测性方案架构

下面着重讲解如何使用 Fluent Bit 来实现云边统一的可观测性。

直接来看架构图，云端部署了一个 K8s 集群，边缘端运行了一系列边缘节点。云端通过 Prometheus Agent 从 Node Exporter、Kubelet 和 kube-state-metrics 等组件中收集监控指标，同时还部署了一个 Fluent Operator 用来同时管理和部署云端和边缘端的 Fluent Bit Daemonset 实例。

对于边缘节点来说，情况就不那么乐观了，因为边缘节点资源有限，无法部署以上这些组件来收集可观测性数据。因此我们对边缘端的监控指标收集方案进行了改良，将 Prometheus (Agent) 替换为 Fluent Bit，并移除了 Node Expoter，使用更轻量的 Fluent Bit Node Exporter Metrics 插件来替代，同时使用 Fluent Bit Prometheus Scrape Metrics 插件来收集边缘端 Edged 和工作负载的监控指标。

这个架构的优点是只需要在边缘端部署一个组件 Fluent Bit，而且可以同时收集边缘节点和边缘应用的日志和监控指标，对于资源紧张的边缘节点来说，这是一个非常完美的方案。

统一可观测性方案实践

最后给大家演示下如何在边缘端部署 Fluent Bit，并使用它来收集边缘节点的监控指标和日志数据。Fluent Bit 的部署方式通过自定义资源（CR）FluentBit 来声明，内容如下：

我们通过 Node Affinity 将 Fluent Bit 指定部署到边缘节点。为了能够替代 Node Exporter 组件的功能，还需要将 Node Exporter 用到的主机路径映射到容器中。

接下来需要通过自定义资源创建一个 Fluent Bit Prometheus Scrape Metrics 插件来收集边缘端工作负载的监控指标：

并通过自定义资源再创建一个 Fluent Bit Node Exporter Metrics 插件来收集边缘节点的监控指标（替代 Node Exporter）：

最后还需要通过自定义资源创建一个 Fluent Bit Prometheus Remote Write 插件，用来将边缘端收集到的监控指标写入到 K8s 集群的 Prometheus 长期存储中。

基于上述步骤，最终我们通过 Fluent Bit 实现了云边统一的可观测性。

总结

虽然 Fluent Bit 的初衷是收集日志，但最近也开始支持收集 Metrics 和 Tracing 数据，这一点很令人兴奋，这样就可以使用一个组件来同时收集所有的可观测性数据（Log、Metrics、Tracing）了。如今 Fluent Operator 也支持了这些功能，并通过自定义资源提供了简单直观的使用方式，想要使用哪些插件直接通过自定义资源声明即可，一目了然。

当然，Fluent Operator 这个项目还很年轻，也有很多需要改进的地方，欢迎大家参与到该项目中来，为其添砖加瓦。

本文由博客一文多发平台 OpenWrite 发布！

摘要：本案例是CenterNet-Hourglass论文复现的体验案例，此模型是对Objects as Points 中提出的CenterNet进行结果复现。

本文分享自华为云社区《CenterNet-Hourglass (物体检测/Pytorch)》，作者：HWCloudAI。

目标检测常采用Anchor的方法来获取物体可能存在的位置，再对该位置进行分类，这样的做法耗时、低效，同时需要后处理（比如NMS）。CenterNet将目标看成一个点，即目标bounding box的中心点，整个问题转变成了关键点估计问题，其他目标属性，比如尺寸、3D位置、方向和姿态等都以估计的中心点为基准进行参数回归。

本案例是CenterNet-Hourglass论文复现的体验案例，此模型是对Objects as Points 中提出的CenterNet进行结果复现（原论文Table 2 最后一行）。本模型是以Hourglass网络架构作为backbone，以ExtremNet 作为预训练模型，在COCO数据集上进行50epochs的训练后得到的。本项目是基于原论文的官方代码进行针对ModelArts平台的修改来实现ModelArts上的训练与部署。

具体算法介绍：https://marketplace.huaweicloud.com/markets/aihub/modelhub/detail/?id=380f95a6-1552-4128-ac96-f

注意事项：

1.本案例使用框架:PyTorch1.4.0

2.本案例使用硬件:GPU: 1*NVIDIA-V100NV32(32GB) | CPU: 8 核 64GB

3.运行代码方法: 本页面顶部菜单栏的三角形运行按钮或按Ctrl+Enter键运行每个方块中的代码

4.JupyterLab的详细用法: 请参考《ModelAtrs JupyterLab使用指导》

5.碰到问题的解决办法: 请参考《ModelAtrs JupyterLab常见问题解决办法》

1.下载数据和代码

运行下面代码，进行数据和代码的下载和解压

本案例使用COCO数据集。

2.训练

2.1依赖库加载和安装

2.2训练函数

2.3开始训练

训练需要一点时间，请耐心等待

3.模型测试

3.1推理函数

3.2开始推理

可以自行修改预测的图像路径

关注，第一时间了解华为云新鲜技术~

sonic-cpp 是由字节跳动 STE 团队和服务框架团队共同研发的一款面向 C++ 语言的高效 JSON 库，极致地利用当前 CPU 硬件特性与向量化编程，大幅提高了序列化反序列化性能，解析性能为 rapidjson 的 2.5 倍。 sonic-cpp 在字节内部上线以来，已为抖音、今日头条等核心业务，累计节省了数十万 CPU 核心。近日，我们正式对外开源 sonic-cpp，希望能够帮助更多开发者，欢迎大家star、fork。

Github：https://github.com/bytedance/sonic-cpp

为什么自研 JSON 解析库

在字节跳动，有大量的业务需要用到 JSON 解析和增删查改，占用的 CPU 核心数非常大，所对应的物理机器成本较高，在某些单体服务上JSON CPU 占比甚至超过 40%。因此，提升 JSON 库的性能对于字节跳动业务的成本优化至关重要。同时，JSON 解析库几经更新，目前业界广泛使用的 rapidjson 虽然在性能上有了很大的改进，但相较于近期一些新的库（如 yyjson 和 simdjson），在解析性能方面仍有一定的劣势。

图 1.1 yyjson、simdjson 和 rapidjson 解析性能对比

图片来源： https://github.com/ibireme/yyjson

yyjson 和 simdjson 虽然有更快的 JSON 解析速度，但是都有各自的缺点。simdjson 不支持修改解析后的 JSON 结构，在实际业务中无法落地。yyjson 为了追求解析性能，使用链表结构，导致查找数据时性能非常差。

图1.2 yyjson数据结构

图片来源自： https://github.com/ibireme/yyjson

基于上述原因，为了降低物理成本、优化性能，同时利用字节跳动已开源 Go JSON 解析库 sonic-go 的经验和部分思路，STE 团队和服务框架团队合作自研了一个适用于 C/C++ 服务的 JSON 解析库 sonic-cpp。

sonic-cpp 主要具备以下特性：

高效的解析性能，其性能为 rapidjson 的 2.5 倍
解决 yyjson 和 simdjson 各自的缺点，支持高效的增删改查
基本上支持 json 库常见的所有接口，方便用户迁移
在字节跳动商业化广告、搜索、推荐等诸多中台业务中已经大规模落地，并通过了工程化的考验

sonic-cpp 优化原理

sonic-cpp 在设计上整合了 rapidjson ，yyjson 和 simdjson 三者的优点，并在此基础上做进一步的优化。在实现的过程中，我们主要通过充分利用向量化（SIMD）指令、优化内存布局和按需解析等关键技术，使得序列化、反序列化和增删改查能达到极致的性能。

向量化优化（SIMD)

单指令流多数据流（Single Instruction Multiple Data，缩写：SIMD）是一种采用一个控制器来控制多个处理器，同时对一组数据中的每一个数据分别执行相同的操作，从而实现空间上的并行性技术。例如 X86 的 SSE 或者 AVX2 指令集，以及 ARM 的 NEON 指令集等。sonic-cpp 的核心优化之一，正是通过利用 SIMD 指令集来实现的。

序列化优化

从 DOM 内存表示序列化到文件的过程中，一个非常重要的过程是做字符串的转义，比如在引号前面添加转义符“ 。比如，把序列化成，存放在文件。常见的实现是逐个字符扫描，添加转义，比如 cJson 的实现

sonic-cpp 则通过五条向量化指令，一次处理 32 个字符，极大地提高了性能。

序列化过程如下：

通过一条向量化 load 指令，一次读取 32 字节到向量寄存器 YMM1；

<!—->

YMM1 和另外 32 字节（全部为）做比较，得到一个掩码(Mask)，存放在向量寄存器 YMM2；
再通过一条 move mask 指令，把 YMM2 中的掩码规约到 GPR 寄存器 R1；
最后通过指令计算下 R1 中尾巴 0 的个数，就可以得到的位置

但如果没有 AVX512 的 load mask 指令集，在尾部最后一次读取 32 字节时，有可能发生内存越界，进而引起诸如 coredump 等问题。 sonic-cpp 的处理方式是利用 Linux 的内存分配以页为单位的机制，通过检查所要读取的内存是否跨页来解决。只要不跨页，我们认为就算越界也是安全的。如果跨页了，则按保守的方式处理，保证正确性，极大地提高了序列化的效率。具体实现见 sonic-cpp 实现。

反序列化优化

在 JSON 的反序列化过程中，同样有个非常重要的步骤是解析数值，它对解析的性能至关重要。比如把字符串”12.5″ 解析成浮点数 12.5。常见的实现基本上是逐个字符解析，见 Rapidjson 的实现 ParseNumber。

sonic-cpp 同样采用 SIMD 指令做浮点数的解析，实现方式如下图所示。

和序列化向量化类似，通过同样的向量指令得到小数点和结束符的位置，再把原始字符串通过向量减法指令，减去, 就得到真实数值。

当我们确定了小数点和结束符的位置，以及向量寄存器中存放的 16 个原始数值，通过乘加指令把他们拼成最终的和指数。

针对不同长度的浮点数做 benchmark 测试，可以看到解析性能提升明显。

但我们发现，在字符串长度相对比较小（少于 4 个）的情况下，向量化性能反而是劣化的，因为此时数据短，标量计算并不会有多大劣势，而向量化反而需要乘加这类的重计算指令。

通过分析字节跳动内部使用 JSON 的特征，我们发现有大量少于 4 位数的短整数，同时我们认为，浮点数位数比较长的一般是小数部分，所以我们对该方法做进一步改进，整数部分通过标量方法循环读取解析，而小数部分通过上述向量化方法加速处理，取得了非常好的效果。流程如下，具体实现见 sonic-cpp ParseNumber 实现

按需解析

在部分业务场景中，用户往往只需要 JSON 中的少数目标字段，此时，全量解析整个 JSON 是不必要的。为此，sonic-cpp 中实现了高性能的按需解析接口，能根据给定的 JsonPointer（目标字段的在 JSON 中的路径表示）解析 JSON 中的目标字段。在按需解析时，由于JSON 较大，核心操作往往是如何跳过不必要的字段。如下。

传统实现

JSON 是一种半结构化数据，往往有嵌套 object 和 array。目前，实现按需解析主要有两种方法：递归下降法和两阶段处理。递归下降法，需要递归下降地“解析”整个 JSON，跳过所有不需要的 JSON 字段，该方法整体实现分支过多，性能较差；两阶段处理需要在阶段一标记整个 JSON token 结构的位置，例如等，在阶段二再根据 token 位置信息，线性地跳过不需要的 JSON 字段，如按需查找的字段在 JSON 中的位置靠前时，该方法性能较差。

sonic-cpp 实现

sonic-cpp 基于 SIMD 实现了高性能的单阶段的按需解析。在按需解析过程中，核心操作在于如何跳过不需要的 JSON object 或 array。sonic-cpp 充分利用了完整的 JSON object 中 左括号数量必定等于右括号数量这一特性，利用 SIMD 读取 64 字节的 JSON 字段，得到左右括号的 bitmap。进一步，计算 object 中左括号和右括号的数量，最后通过比较左右括号数量来确定 object 结束位置。具体操作如下：

经过全场景测试，sonic-cpp 的按需解析明显好于已有的实现。性能测试结果如下图。其中，rapidjson-sax 是基于 rapidjson 的 SAX 接口实现的，使用递归下降法实现的按需解析。simdjson 的按需解析则是基于两阶段处理的方式实现。Normal，Fronter，NotFoud 则分别表示，按需解析时，目标字段在 JSON 中的位置居中，靠前或不存在。不过，使用 sonic-cpp 和 simdjson 的按需解析时，都需要保证输入的 JSON 是正确合法的。

按需解析扩展

sonic-cpp 利用 SIMD 前向扫描，实现了高效的按需解析。在字节跳动内部，这一技术还可以应用于两个 JSON 的合并操作。在合并 JSON 时，通常需要先解析两个 JSON，合并之后，再反序列化。但是，如果两个 JSON 中需要合并的字段较少，就可以使用按需解析思想，先将各个字段的值解析为 raw JSON 格式，然后再进行合并操作。这样，能极大地减少 JSON 合并过程中的解析和序列化开销。

DOM 设计优化

节点设计

在 sonic-cpp 中，表示一个 JSON value 的类被称作 node。node 采用常见的方法，将类型和 size 的信息合为一个，只使用 8 字节，减少内存的使用。对于每个 node，内存上只需要 16 字节，布局更紧凑，具体结构如下：

DOM树设计

sonic-cpp 的 DOM 数据结构采用类似于 rapidjson 的实现，可以对包括 array 或 object 在内的所有节点进行增删查改。

在 DOM 的设计上，sonic-cpp 把 object 和 array 的成员以数组方式组织，保证其在内存上的连续。数组方式让 sonic-cpp 随机访问 array 成员的效率更高。而对于 object，sonic-cpp 为其在 meta 数据中保存一个 map。map 里保存了 key 和 value 对应的 index。通过这个 map，查找的复杂度由 O(N) 降到 O(logN)。sonic-cpp 为这个 map 做了一定的优化处理：

按需创建： 只在调用接口时才会生成这个 map，而不是解析的时候创建。
使用 string_view 作为 key： 无需拷贝字符串，减少开销。

内存池

sonic-cpp 提供的内存分配器默认使用内存池进行内存分配。该分配器来自 rapidjson。使用内存池有以下几个好处：

避免频繁地 malloc。DOM 下的 node 只有 16 byte，使用内存池可以高效地为这些小的数据结构分配内存。
避免析构 DOM 上的每一个 node，只需要在析构 DOM 树的时候，统一释放分配器的内存即可。

Object 内建的 map 也使用了内存池分配内存，使得内存可以统一分配和释放。

性能测试

在支持高效的增删改查的基础上，性能和 simdjson、yyjson 可比。

不同 JSON 库性能对比

基准测试是在 https://github.com/miloyip/nativejson-benchmark 的基础上支持 sonic-cpp 和 yyjson，测试得到。

反序列化（Parse）性能基准测试结果

序列化（Stringify）性能基准测试结果:

不同场景性能对比

sonic-cpp 与 rapidjson，simdjson 和 yyjson 之间在不同场景的性能对比（HIB: Higher is better）。

生产环境中性能对比

在实际生产环境中，sonic-cpp 的性能优势也得到了非常好的验证，下面是字节跳动抖音某个服务使用 sonic-cpp 在高峰段 CPU 前后的对比。

展望

sonic-cpp 当前仅支持 amd64 架构，后续会逐步扩展到 ARM 等其它架构。同时，我们将积极地支持 JSON 相关 RFC 的特性，比如，支持社区的 JSON 合并相关的 RFC 7386，依据 RFC 8259 设计 JSON Path 来实现更便捷的 JSON 访问操作等。

欢迎开发者们加入进来贡献 PR，一起打造业界更好的 C/C++ JSON 库！

直播预告

为了帮助大家更好地理解 sonic-cpp，我们将于2022年12月15日19:30在《掘金公开课18期》，与大家直播分享 sonic-cpp 的技术原理、实践效果和未来规划。参与直播互动还有机会赢取周边礼品哦！礼品多多，欢迎大家关注并扫描下方二维码预约直播。

直播互动礼品图片

OpenAI 上周推出的 AI 对话模型 ChatGPT 这几天风靡全网，其回答各种问题的强大能力让许多人感慨它可替代 Google 等搜索引擎，甚至替代编程问答社区 Stack Overflow。

事实上，Stack Overflow 这几天也涌入了大量用 ChatGPT 生成的答案。不过 Stack Overflow 对 ChatGPT 生成的内容并不待见 —— 他们今天发布了一项临时规则：禁止使用 ChatGPT 生成的内容来回答 Stack Overflow 上的问题。

Stack Overflow 称，在使用 ChatGPT 生成的文本回复的问题中，其正确率非常低，而这些内容对整个网站以及寻求正确答案的用户来说是有害的。

Stack Overflow 认为，这里的主要问题是，由于使用 ChatGPT 的门槛非常低，很多人最近都在尝试使用 ChatGPT 回答 Stack Overflow 上的问题，但他们缺少专业知识，也不愿意在回复前验证 ChatGPT 生成的答案是否正确。因此现在 Stack Overflow 产生了许多无价值，甚至引起误导的回答。

针对这种情况，Stack Overflow 决定采取措施来减少使用 ChatGPT 生成的答案。在禁止 ChatGPT 的规则公布后，如果用户被发现仍在使用 ChatGPT 回答问题，他们可能会被禁止发帖。

延伸阅读

整活大师 ChatGPT：实现编程语言、构建虚拟机……

Github：https://github.com/bytedance/sonic-cpp

为什么自研 JSON 解析库

图 1.1 yyjson、simdjson 和 rapidjson 解析性能对比

图片来源： https://github.com/ibireme/yyjson

图1.2 yyjson数据结构

图片来源自： https://github.com/ibireme/yyjson

sonic-cpp 主要具备以下特性：

高效的解析性能，其性能为 rapidjson 的 2.5 倍
解决 yyjson 和 simdjson 各自的缺点，支持高效的增删改查
基本上支持 json 库常见的所有接口，方便用户迁移
在字节跳动商业化广告、搜索、推荐等诸多中台业务中已经大规模落地，并通过了工程化的考验

sonic-cpp 优化原理

向量化优化（SIMD)

序列化优化

sonic-cpp 则通过五条向量化指令，一次处理 32 个字符，极大地提高了性能。

序列化过程如下：

通过一条向量化 load 指令，一次读取 32 字节到向量寄存器 YMM1；

<!—->

YMM1 和另外 32 字节（全部为）做比较，得到一个掩码(Mask)，存放在向量寄存器 YMM2；
再通过一条 move mask 指令，把 YMM2 中的掩码规约到 GPR 寄存器 R1；
最后通过指令计算下 R1 中尾巴 0 的个数，就可以得到的位置

反序列化优化

sonic-cpp 同样采用 SIMD 指令做浮点数的解析，实现方式如下图所示。

和序列化向量化类似，通过同样的向量指令得到小数点和结束符的位置，再把原始字符串通过向量减法指令，减去, 就得到真实数值。

当我们确定了小数点和结束符的位置，以及向量寄存器中存放的 16 个原始数值，通过乘加指令把他们拼成最终的和指数。

针对不同长度的浮点数做 benchmark 测试，可以看到解析性能提升明显。

按需解析

传统实现

sonic-cpp 实现

按需解析扩展

DOM 设计优化

节点设计

DOM树设计

sonic-cpp 的 DOM 数据结构采用类似于 rapidjson 的实现，可以对包括 array 或 object 在内的所有节点进行增删查改。

按需创建： 只在调用接口时才会生成这个 map，而不是解析的时候创建。
使用 string_view 作为 key： 无需拷贝字符串，减少开销。

内存池

sonic-cpp 提供的内存分配器默认使用内存池进行内存分配。该分配器来自 rapidjson。使用内存池有以下几个好处：

避免频繁地 malloc。DOM 下的 node 只有 16 byte，使用内存池可以高效地为这些小的数据结构分配内存。
避免析构 DOM 上的每一个 node，只需要在析构 DOM 树的时候，统一释放分配器的内存即可。

Object 内建的 map 也使用了内存池分配内存，使得内存可以统一分配和释放。

性能测试

在支持高效的增删改查的基础上，性能和 simdjson、yyjson 可比。

不同 JSON 库性能对比

基准测试是在 https://github.com/miloyip/nativejson-benchmark 的基础上支持 sonic-cpp 和 yyjson，测试得到。

反序列化（Parse）性能基准测试结果

序列化（Stringify）性能基准测试结果:

不同场景性能对比

sonic-cpp 与 rapidjson，simdjson 和 yyjson 之间在不同场景的性能对比（HIB: Higher is better）。

生产环境中性能对比

在实际生产环境中，sonic-cpp 的性能优势也得到了非常好的验证，下面是字节跳动抖音某个服务使用 sonic-cpp 在高峰段 CPU 前后的对比。

展望

欢迎开发者们加入进来贡献 PR，一起打造业界更好的 C/C++ JSON 库！

直播预告

直播互动礼品图片

DBeaver 22.3.0 已发布。

DBeaver 是免费的多平台数据库工具，适用于开发人员、数据库管理员、分析师和所有需要使用数据库的人，并且支持所有流行的数据库：MySQL、PostgreSQL、SQLite、Oracle、DB2、SQL Server、Sybase、MS Access、Teradata、Firebird、Apache Hive、Phoenix、Presto 等。

更新内容

数据编辑器
- 优化数据导出按钮 UI
- 将获取所有数据和大小的控件重新添加到状态栏
- 将套索工具 (Lasso tool) 添加到空间查看器 (spatial viewer)
- 修复空间查看器初始化中的错误
- 修复在 macOS 和 Linux 系统中，使用外部编辑器打开 BLOB 内容时出现的错误
- 修复基于浏览器的图像查看器控件（空图像句柄或无效图像句柄）
SQL 编辑器
- 改进对大 SQL 文件的支持（自动禁用语法验证）
- 重新设计表格自动完成工具提示 UI
- 修复非关联脚本打开错误
通用
- 修复默认 SSL 信任库的选择问题（目前支持配置）
- 改进连接编辑/创建对话框的性能
- 数据库服务器版本现在显示在连接的工具提示中
- 重新设计对象删除对话框
- 数据库创建按钮已从不支持它的数据库的连接对话框中删除
- 打包驱动程序的安全补丁（添加 zip 存档的额外验证）
SSH: 修复 SSHJ 隧道失效的问题
Tasks: 修复在缺失（删除）表的情况下操作任务的问题
Clickhouse: 修复标识符的引用问题 (for non ASCII characters)
Intersystems Cache: 再次添加社区驱动程序
MySQL:
- 修复 procedures 的超链接导航问题
- 修复复杂标识符的引用问题
Netezza: 改进数据列的读取
PostgreSQL:
- 修复角色的 create/edit 命令
- 改进 PostgreSQL 15 支持（支持新的数据类型类别）

下载地址 | 发布说明

Brave 是基于 Chromium 的一款免费开源网络浏览器，主打隐私保护，其默认设置就会自动阻止在线广告和网站跟踪。Brave Software（Brave 浏览器所属公司）于 2015 年由 Brendan Eich 和 Brian Bondy 联合创立，其中前者是 JavaScript 的创造者，同时也是 Mozilla 联合创始人。

Brave 1.46 发布，更新内容如下：

将 Chromium 升级到 108.0.5359.94
增加了通过管理策略禁用 Brave Wallet 的功能
为 Brave Rewards 增加了国家选择要求
增加了对新标签页下多个自定义背景图片的支持
在 Windows 上的首次运行对话框和 brave://settings/getStarted 中增加了 “钉在任务栏” 选项
在 macOS 上的首次运行对话框和 brave://settings/getStarted 中增加了 “保留在 Dock” 选项
为 Brave News 增加了西班牙、墨西哥和巴西的内容支持
在 brave://settings/content 下增加了 Brave Shields 设置
增加了对侧边栏的右侧显示支持
[安全] 禁用了隐私窗口中的块状素选择器
为 Brave Wallet 启用了 ENS L2 解析
为使用 Tor 的隐私窗口启用了 HTTPS-Only 模式
启用了默认的浏览器信息栏提示
改进了非英语字符的字体外观
更新了 DNSLink 重定向的 “Ask” IPFS 解析方法
更新了 Brave News 的自定义 UI
更新了 Brave News 来源建议
更新了跳转功能，只适用于跨网站导航
更新了广告屏蔽组件以使用纯文本列表
重新启用了 brave://settings/appearance 下的 “侧面板” 显示设置
用 Poppins 替换了 Muli 字体
修正了对没有 DNS 记录的 URL 重定向的 x-ipfs-path 处理
修正了在 brave://settings/shields/filters 下启用 “RU Adlist” 时在 https://d3ward.github.io/toolz/adblock 的崩溃
修正了 HTTPSE 重定向优先于 adblock 重定向的问题
修正了应用某些主题时工具栏上不正确的按钮颜色
修复了拖放完成后，拖放指示器没有从侧边栏消失的问题

更多详情可查看：https://brave.com/latest/

Spring Shell 2.1.4 和 3.0.0-M3 已发布。

Spring Shell 是基于 Spring 的交互式 Shell，可让开发者使用简单的基于 Spring 的编程模型来开发命令。

Spring Shell 3.0.0-M3 是建立在 Spring Boot 3.0.0 GA 版本之上的第一个里程碑。

Spring Shell 2.1.4 版本主要变化：

修复

此 GA 包含一些显着变化：

基于 Spring Boot 2.7.6 构建
向后移植了一些错误修复

问题

#577 backport 没有连字符的 ShellOption 没有注册
#573 backport 如果没有值，方法执行应该不会出错
#571 升级 spring-boot 2.7.6
#570 backport 处理选项值中的空格

详情查看 release note 。

3.0.0-M3 版本主要变化：

修复

这个里程碑使用并包含一些显着的变化：

常见错误修复
新测试模块

问题

#576 在 linux 上使用 musl 构建示例
#575 ShellOption 未在没有连字符的情况下注册
#574 升级 spring-boot 3.0.0
#572 方法执行不应在没有值的情况下出错
#568 升级 spring-boot 3.0.0-RC2
#567 处理选项中的空格值
#565 自动配置类应该使用@autoConfiguration
#558 文档更新
#552 在本地修复 e2e flow.test.ts
#516 JLine 终端应该是可配置的
#489 提供测试框架

详情查看 3.0.0 M3 release note 。

pgAdmin 是 PostgreSQL 领先的开源图形化管理工具。pgAdmin 4 旨在满足新手和有经验的 Postgres 用户的需求，提供强大的图形界面，简化了数据库对象的创建、维护和使用。

这个版本的 pgAdmin 4 包括错误修复和新功能，主要更新内容如下：

安全

请注意这个版本包括一个安全更新，以确保在使用服务器模式下运行的 pgAdmin 时，只有授权和认证的用户可以验证二进制路径。在服务器模式下运行 pgAdmin 的用户应该尽快升级到这个版本。

这个问题不影响在桌面模式下运行的用户。

Bugs/Housekeeping:

确保只有授权和认证的用户可以验证二进制路径（CVE-2022-4223）
将 BigAnimal 的 API 版本更新为 V2
删除所有 Backbone 和 Underscore 的痕迹
修正了一个问题，即在模式差异工具中为外键显示了错误的模式。
确保桌面模式下的查询历史日期格式与 pgadmin 服务器的地区设置的格式一致。
修正了一个问题，即如果 CSV 引号字符长度超过 1，CSV 文件将无法下载。
确保 DATA_DIR 依赖的文件夹/文件如果没有在配置文件中单独指定，会自动在指定的 DATA_DIR 内创建。
修复了在编辑结果网格中的数据时，编辑器的位置是错误的问题。
确保查询工具对注册有 PostgreSQL 服务的服务器成功启动

更多详情可查看：https://www.postgresql.org/about/news/pgadmin-4-v617-released-2553/

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

Armbian Linux 是一款适用于 ARM 开发板的、基于 Debian 的 Linux 发行版，具有强大的图形化配置工具和安装程序，简单易上手。Armbian 每三个月提供一次稳定版本，由最近的 LTS 内核驱动，喜欢滚动发布的用户可以检查 EDGE 版本，这些版本使用来自 sid、hirsute 或 impish userland 的最新每日内核构建。

Armbian 22.11 版本已发布发布，此版本的重大更改包括：引入了对 Banana Pi M5、ODROID-M1 和 Rock Pi 4C+ 单板计算机的支持、RISC-V 64 UEFI 构建支持，以及改进了对 ROCK Pi S （基于瑞芯微 RK3308 的单板计算机）的支持。

此版本还添加了针对软件部署优化的极小映像，通过默认冻结内核升级来提高稳定性，实现了对 Linux 内核 5.19或更高版本的 Plymouth 启动启动支持，并为 ARMhf 和 AArch64 服务器和桌面添加了对 gpiod 库的支持（用于访问 GPIO 引脚/线）。

其他值得注意的变化，Armbian 22.11 为 nand-sata-install 添加了 UEFI 安装支持，在 Rock Pi 4 单板计算机上启用了正确的 ES8316 音频，添加了 ZFS 存储库，为 postinst 脚本中的所有用户添加了 SKEL 分发，以及将 Intel 声音固件添加到桌面图像。

在软件方面，此版本为 Terminator 终端模拟器应用程序添加了初始配置，重新启用了 Mozilla Thunderbird 电子邮件客户端，并在基于 Debian Sid 的图像上添加了 Codium IDE。

Armbian 22.11 中还修复了许多错误，以进一步改进对现有开发板的支持，包括 Raspberry Pi、ODROID-XU4、PINE H64、NanoPi NEO3 、JetHub D1 和 ROCK Pi S。

有关此版本的所有更改，可查看完整的变更日志。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

摘要：本文重点介绍几种通过优化Cache使用提高程序性能的方法。

本文分享自华为云社区《编译器优化那些事儿（7）：Cache优化》，作者：毕昇小助手。

引言

软件开发人员往往期望计算机硬件拥有无限容量、零访问延迟、无限带宽以及便宜的内存，但是现实却是内存容量越大，相应的访问时间越长；内存访问速度越快，价格也更贵；带宽越大，价格越贵。为了解决大容量、高速度、低成本之间的矛盾，基于程序访问的局部性原理，将更常用数据放在小容量的高速存储器中，多种速度不同的存储器分层级联，协调工作。

图1 memory hierarchy for sever [1]

现代计算机的存储层次可以分几层。如图1所示，位于处理器内部的是寄存器；稍远一点的是一级Cache，一级Cache一般能够保存64k字节，访问它大约需要1ns，同时一级Cache通常划分为指令Cache（处理器从指令Cache中取要执行的指令）和数据Cache（处理器从数据Cache中存/取指令的操作数）；然后是二级Cache，通常既保存指令又保存数据，容量大约256k，访问它大约需要3-10ns；然后是三级Cache，容量大约16-64MB，访问它大约需要10-20ns；再接着是主存、硬盘等。注意，CPU和Cache是以word传输的，Cache到主存以块（一般64byte）传输的。

前文提到了程序的局部性原理，一般指的是时间局部性（在一定时间内，程序可能会多次访问同一内存空间）和空间局部性（在一定时间内，程序可能会访问附近的内存空间），高速缓存（Cache）的效率取决于程序的空间和时间的局部性性质。比如一个程序重复地执行一个循环，在理想情况下，循环的第一个迭代将代码取至高速缓存中，后续的迭代直接从高速缓存中取数据，而不需要重新从主存装载。因此，为了使程序获得更好的性能，应尽可能让数据访问发生在高速缓存中。但是如果数据访问在高速缓存时发生了冲突，也可能会导致性能下降。

篇幅原因，本文重点讨论编译器在Cache优化中可以做哪些工作，如果读者对其他内存层次优化感兴趣，欢迎留言。下面将介绍几种通过优化Cache使用提高程序性能的方法。

对齐和布局

现代编译器可以通过调整代码和数据的布局方式，提高Cache命中率，进而提升程序性能。本节主要讨论数据和指令的对齐、代码布局对程序性能的影响，大部分处理器中Cache到主存是以Cache line（一般为64Byte，也有地方称Cache块，本文统一使用Cache line）传输的，CPU从内存加载数据是一次一个Cache line，CPU往内存写数据也是一次一个Cache line。假设处理器首次访问数据对象A，其大小刚好为64Byte，如果数据对象A首地址并没有进行对齐，即数据对象A占用两个不同Cache line的一部分，此时处理器访问该数据对象时需要两次内存访问，效率低。但是如果数据对象A进行了内存对齐，即刚好在一个Cache line中，那么处理器访问该数据时只需要一次内存访问，效率会高很多。编译器可以通过合理安排数据对象，避免不必要地将它们跨越在多个Cache line中，尽量使得同一对象集中在一个Cache中，进而有效地使用Cache来提高程序的性能。通过顺序分配对象，即如果下一个对象不能放入当前Cache line的剩余部分，则跳过这些剩余的部分，从下一个Cache line的开始处分配对象，或者将大小（size）相同的对象分配在同一个存储区，所有对象都对齐在size的倍数边界上等方式达到上述目的。

Cache line对齐可能会导致存储资源的浪费，如图2所示，但是执行速度可能会因此得到改善。对齐不仅仅可以作用于全局静态数据，也可以作用于堆上分配的数据。对于全局数据，编译器可以通过汇编语言的对齐指令命令来通知链接器。对于堆上分配的数据，将对象放置在Cache line的边界或者最小化对象跨Cache line的次数的工作不是由编译器来完成的，而是由runtime中的存储分配器来完成的[2]。

图2 因块对齐可能会浪费存储空间

前文提到了数据对象对齐，可以提高程序性能。指令Cache的对齐，也可以提高程序性能。同时，代码布局也会影响程序的性能，将频繁执行的基本块的首地址对齐在Cache line的大小倍数边界上能增加在指令Cache中同时容纳的基本块数目，将不频繁执行的指令和频繁指令的指令放到不同的Cache line中，通过优化代码布局来提升程序性能。

利用硬件辅助

Cache预取是将内存中的指令和数据提前存放至Cache中，达到加快处理器执行速度的目的。Cache预取可以通过硬件或者软件实现，硬件预取是通过处理器中专门的硬件单实现的，该单通过跟踪内存访问指令数据地址的变化规律来预测将会被访问到的内存地址，并提前从主存中读取这些数据到Cache；软件预取是在程序中显示地插入预取指令，以非阻塞的方式让处理器从内存中读取指定地址数据至Cache。由于硬件预取器通常无法正常动态关闭，因此大部分情况下软件预取和硬件预取是并存的，软件预取必须尽力配合硬件预取以取得更优的效果。本文假设硬件预取器被关闭后，讨论如何利用软件预取达到性能提升的效果。

预取指令prefech(x)只是一种提示，告知硬件开始将地址x中的数据从主存中读取到Cache中。它并不会引起处理停顿，但若硬件发现会产生异常，则会忽略这个预取操作。如果prefech(x)成功，则意味着下一次取x将命中Cache；不成功的预取操作可能会导致下次读取时发生Cache miss，但不会影响程序的正确性[2]。

数据预取是如何改成程序性能的呢？如下一段程序：

假设一个Cache line可以存放两个double素，当第一次访问a[0]时，由于a[0]不在Cache中，会发生一次Cache miss，需要从主存中将其加载至Cache中，由于一个Cache line可以存放两个double素，当访问a[1]时则不会发生Cache miss。依次类推，访问a[2]时会发生Cache miss，访问a[3]时不会发生Cache miss，我们很容易得到程序总共发生了50次Cache miss。

我们可以通过软件预取等相关优化，降低Cache miss次数，提高程序性能。首先介绍一个公式[3]：

上述公式中L是memory latency，S是执行一次循环迭代最短的时间。iterationAhead表示的是循环需要经过执行几次迭代，预取的数据才会到达Cache。假设我们的硬件架构计算出来的iterationAhead=6，那么原程序可以优化成如下程序：

由于我们的硬件架构需要循环执行6次后，预取的数据才会到达Cache。一个Cache line可以存放两个double素，为了避免浪费prefetch指令，所以prologue和steady state循环都展开了，即执行prefetch(&a[0])后会将a[0]、a[1]从主存加载至Cache中，下次执行预取时就无需再次将a[1]从主存加载至Cache了。prologue循环先执行数组a的前12个素的预取指令，等到执行steady state循环时，当i = 0时，a[0]和a[1]已经被加载至Cache中，就不会发生Cache miss了。依次类推，经过上述优化后，在不改变语义的基础上，通过使用预取指令，程序的Cache miss次数从50下降至0，程序的性能将会得到很大提升。

注意，预取并不能减少从主存储器取数据到高速缓存的延迟，只是通过预取与计算重叠而隐藏这种延迟。总之，当处理器有预取指令或者有能够用作预取的非阻塞的读取指令时，对于处理器不能动态重排指令或者动态重排缓冲区小于我们希望隐藏的具体Cache延迟，并且所考虑的数据大于Cache或者是不能够判断数据是否已在Cache中，预取是适用的。预取也不是万能，不当的预取可能会导致高速缓存冲突，程序性能降低。我们应该首先利用数据重用来减少延迟，然后才考虑预取。

除了软件预取外，ARMv8还提供了Non-temporal的Load/Store指令，可以提高Cache的利用率。对于一些数据，如果只是访问一次，无需占用Cache，可以使用这个指令进行访问，从而保护Cache中关键数据不被替换，比如memcpy大数据的场景下，使用该指令对于其关键业务而言，是有一定的收益的。

循环变换

重用Cache中的数据是最基本的高效使用Cache方法。对于多层嵌套循环，可以通过交换两个嵌套的循环（loop interchange）、逆转循环迭代执行的顺序（loop reversal）、将两个循环体合并成一个循环体（loop fusion）、循环拆分（loop distribution）、循环分块（loop tiling）、loop unroll and jam等循环变换操作。选择适当的循环变换方式，既能保持程序的语义，又能改善程序性能。我们做这些循环变换的主要目的是为了实现寄存器、数据高速缓存以及其他存储层次使用方面的优化。

篇幅受限，本节仅讨论循环分块（loop tiling）如何改善程序性能，若对loop interchange感兴趣，请查阅。下面这个简单的循环：

我们假设数组a、b都是超大数组，m、n相等且都很大，程序不会出现数组越界访问情况发生。那么如果b[j]在j层循环中跨度太大时，那么被下次i层循环重用时数据已经被清出高速缓存。即程序访问b[n-1]时，b[0]、b[1]已经被清出缓存，此时需要重新从主存中将数据加载至缓存中，程序性能会大幅下降。

我们如何通过降低Cache miss次数提升程序的性能呢？通过对循环做loop tiling可以符合我们的期望，即通过循环重排，使得数据分成一个一个tile，让每一个tile的数据都可以在Cache中被hint[4]。从内层循环开始tiling，假设tile的大小为t，t远小于m、n，t的取值使得b[t-1]被访问时b[0]依然在Cache中，将会大幅地减少Cache miss次数。假设n-1恰好被t整除，此时b数组的访问顺序如下所示：

经过loop tiling后循环变换成：

假设每个Cache line能够容纳X个数组素，loop tiling前a的Cache miss次数为m/X，b的Cache miss次数是m*n/X，总的Cache miss次数为m*(n+1)/x。loop tiling后a的Cache miss次数为(n/t)*(m/X)，b的Cache miss次数为(t/X)*(n/t)=n/X，总的Cache miss次数为n*(m+t)/xt。此时，由于n与m相等，那么loop tiling后Cache miss大约可以降低t倍[4]。

前文讨论了loop tiling在小用例上如何提升程序性能，总之针对不同的循环场景，选择合适的循环交换方法，既能保证程序语义正确，又能获得改善程序性能的机会。

小结

汝之蜜糖，彼之砒霜。针对不同的硬件，我们需要结合具体的硬件架构，利用性能分析工具，通过分析报告和程序，从系统层次和算法层次思考问题，往往会有意想不到的收获。本文简单地介绍了内存层次优化相关的几种方法，结合一些小例子深入浅出地讲解了一些内存层次优化相关的知识。纸上得来终觉浅，绝知此事要躬行，更多性能优化相关的知识需要我们从实践中慢慢摸索。

参考

John L. Hennessy, David A. Patterson. 计算机体系结构：量化研究方法（第6版）. 贾洪峰,译
Andrew W.Apple, with Jens Palsberg. Modern Compiler Implenentation in C
http://www.cs.cmu.edu/afs/cs/academic/class/15745-s19/www/lectures/L20-Global-Scheduling.pdf
https://zhuanlan.zhihu.com/p/

关注，第一时间了解华为云新鲜技术~

AutoCut 是一款通过字幕来剪切视频的工具。

AutoCut 对你的视频自动生成字幕，然后你选择需要保留的句子，AutoCut 将对你视频中对应的片段裁切并保存。你无需使用视频编辑软件，只需要编辑文本文件即可完成剪切。

使用例子

假如你录制的视频放在这个文件夹里。那么运行

autocut -d 2022-11-04

提示：如果你使用 OBS 录屏，可以在中将空格改成，即。那么视频文件将放在日期命名的文件夹里。

AutoCut 将持续对这个文件夹里视频进行字幕抽取和剪切。例如，你刚完成一个视频录制，保存在。AutoCut 将生成。你在里面选择需要保留的句子后，AutoCut 将剪切出，并生成来预览结果。

你可以使用任何的 Markdown 编辑器。例如我常用 VS Code 和 Typora。下图是通过 Typora 来对编辑。

全部完成后在里选择需要拼接的视频后，AutoCut 将输出和对应的字幕文件。

当你看一张图片时，你会先注意图片的哪些部分，或者说图片中的哪些区域会首先吸引你的注意力，机器学习能不能提前知道用户的注意力会集中在什么地方？

基于这个想法，Google 训练了一个机器学习模型可以做出这样的预测，并将该模型应用于 JPEG XL 图像编码格式。当应用该模型之后，浏览器会首先加载用户会第一时间注意的图像部分，从用户的视角来看，图像加载速度会有明显提升，可以显著改善用户体验。

当然，这个模型不仅可以适用于 JPEG XL 图像的编码，只要是需要根据用户注意力来调整内容加载优先级的项目都可以使用这个模型（比如在 VR 中，可以结合摄像头和模型来调整 VR 画面的清晰度，优先加载用户目光所及的画面）。

如果各位的网龄足够大，是可以回想一下网速还不够快的年代，当时想要浏览一张图片，图片通常是一行一行逐渐出现，有很大的割裂感，图像不加载个 60%-70%，你根本看不出图像描绘的具体是什么东西。现在网速已经越来越快，图片通常能够一瞬间就加载完成，用户大多数情况下察觉不到图片的加载，但是该模型在一些欠发达地区仍然具有重要的意义。

根据这个模型的原理，当加载一张图像时，首先会在一开始显示整个图像的低分辨率版本（如上图，刚开始加载），当你的目光开始注视图像时，机器学习就会预测你目光会注视的区域，并加速将该区域的加载，使其变得足够清晰（如下图，加载 30%）。

然后，当你的目光在图片上游走时，机器学习已经猜到你的眼睛接下来会看哪里，图像的这些地方就会逐渐加载清晰（如下图，加载 50%）。

图片后续依然是基于注意力逐步加载图像（如下图，加载 80%）。

最后就是那些用户的目光可能完全不会特别关注的边缘区域，就完成了 100% 加载。

如果这套机器学习模型预测得足够准确，用户可能完全不会注意到图像是一部分一部分慢慢加载出来的，甚至会有一种图片一开始就是完整加载出来的错觉。

目前 Google 也放出了该技术的演示，用户可以自己试试看。要想获得最佳体验，前提是需要使用基于 Chromium 的浏览器，并启用其实验性的 JPEG-XL 图像渲染器（进入，搜索并启用它）。

Google 放出的这个演示使用了 JPEG-XL 图像格式，但在 10 月份的时候他们就表示过将在后续的 Chrome 版本中删除这个格式（难道团队没有沟通？）。目前还不清楚 Google 未来会在什么领域使用这个机器学习模型。

该模型的 GitHub 地址：https://github.com/google/attention-center

TIOBE 公布了 2022 年 12 月的编程语言排行榜。

TIOBE 将于下个月揭晓其 2022 年度编程语言，目前共有 3 个候选者：Python、C 和 C++。TIOBE CEO Paul Jansen 指出，虽然 Python 和 C 已多次斩获该头衔，而 C++ 仅在 2003 年获得过一次；但在本月 TIOBE 指数中， C++ 已经实现了历史上首次超越 Java，Java 现已跌至榜单第 4 位。这是自 2001 年 TIOBE 指数开始以来，Java 首次未进入前 3 名。除此之外，Kotlin 和 Julia 也越来越接近 Top 20。

TIOBE 12 月 TOP 20 编程语言

除了 C++ 取代 Java 跃至第 3 位外，Top 10 中还有 SQL 继续上升一位至榜单第 8，Assembly language 被挤到第 9；其他语言排名不变。

Top 11-20 区间中的语言排行则反复波动。少儿编程语言 Scratch 短暂的从第 23 名上升至榜单第 17 后，又在本月跌出 Top 20 到了第 21 位。与此同时，Perl 又重回 Top 20 榜单，从上月的第 23 位攀升至现在的第 18 位；Go 和 R 语言也互换了位置。

具体而言排名出现上升的有：R（12→11）、Matlab（15→14）、Swift（18→15）、Ruby（19→17）。下降的有：Go（11→12）、Delphi/Object Pascal（14→16）、Objective-C（16→19）。Classic Visual Basic 和 Rust 分别保持第 13 和 20 的位置不变。

TOP 10 编程语言 TIOBE 指数走势（2002-2022）

第 21-50 名编程语言排行

第 51-100 名如下，由于它们之间的数值差异较小，仅以文本形式列出（按字母排序）：

ABC, ActionScript, Alice, Apex, APL, AutoLISP, Awk, B4X, C shell, CL (OS/400), CLIPS, Clojure, Common Lisp, Crystal, Elixir, Emacs Lisp, Forth, Hack, Icon, Io, J#, JScript, Korn shell, Ladder Logic, LPC, Modula-2, MQL5, MUMPS, NATURAL, Occam, OpenCL, OpenEdge ABL, PL/I, Q, Racket, Raku, Ring, RPG, S, Smalltalk, Solidity, SPARK, Stata, Tcl, VBScript, Verilog, VHDL, WebAssembly, X++, Xojo

TIOBE 编程社区指数（The TIOBE Programming Community index）是一个衡量编程语言受欢迎程度的指标，该指数每月更新一次。评判的依据来自世界范围内的工程师、课程和第三方供应商，包括流行的搜索引擎，如 Google、必应、雅虎、维基百科、亚马逊、YouTube 和百度都被用于指数计算。值得注意的是，TIOBE 指数并不代表编程语言的好坏或编写代码的多少。

该指数可以用来检查你的编程技能是否还能跟上时代的步伐，或者在开始建立一个新的软件系统时，基于指数对采用何种编程语言做出决策。

TIOBE 指数的定义方式，以及详细榜单信息均可查看官网。

1992年12月3日，世界上第一条 SMS 消息成功发送，如今已经过去 30 周年。在这个关键节点，谷歌再度发文赞美 RCS 短信标准，并批评苹果迟迟不采用该标。

RCS 全称 Rich Communication Suite – 富媒体通信标准，属于高级消息传递标准的一部分。它由 GSM(Global System for Mobile Communications) 协会发起，目标是取代当前的 SMS 消息传递标准。

目前 RCS 已获得了全球主流移动网络运营商（包括国内三大运营商）、 500 多家 Android 设备制造商（小米、HTC、索尼、LG、华为、OPPO 、三星和中兴等）的支持。

在博文中，Google 集团产品经理 Neena Budhiraja 列举了 RCS 标准对比 SMS 的三大好处：

RCS 支持端到端加密，该加密功能已经扩展到群聊，而 SMS 则不支持。
RCS 功能更丰富，除了文本消息，RCS 还默认支持高达 10MB 的高品质图片消息、群聊、位置共享，甚至视频通话。此外，RCS 服务还支持已读回执（已读功能）和打字指示符（ “对方正在输入” 功能）等复杂功能，还可以通过 WiFi 发短信。
市场上主要的移动运营商和设备制造商都采用 RCS 作为标准，无论用户处于哪个地区、使用什么型号的手机，其短信体验都相同。

目前苹果是主流手机厂商里唯一一位“ RCS 标准反对者“，使用 iPhone 向 Android 手机发送消息时，Apple 继续依赖 SMS 。谷歌博客文末也是呼吁苹果尽快采用 RCS 标准，顺便嘲讽了一把苹果“短信技术停留在 1990 年代”，实在是“拖大家后腿”。

除此之外，谷歌还提到了“绿蓝气泡”问题，该问题源于苹果 iMessage 即时通信应用程序存在的一些差异：Apple 用户在 iMessage 中默认使用蓝色文本气泡，而由于苹果公司未采用 RCS 标准，iPhone 对 Andriod 设备使用 SMS 而不是通过网络数据发送消息，因此，Android 用户在 iMessage 中的消息会用绿色气泡显示，“蓝 / 绿气泡” 之差让使用 Android 手机的青少年在社交活动中饱受歧视 —— “永远不要与绿色短信者约会”。

讲师：袁鹏，一页科技架构师

摘要：君润人力采用多套 Apache APISIX 集群来满足自研服务平台的功能需求。

君润人力成立于 2019 年，是一家以科技驱动的人力资源解决方案服务商，依托行业领先的科技水平和服务能力，专注于为客户提供一站式人力资源服务。自研数十家人力资源服务平台，深度链接 B 端企业和 C 端用户，构建数字化人力资源服务生态。

本文从君润人力业务快速扩张的背景入手，重点介绍开源 API 网关 Apache APISIX 对其自研平台系统架构的多样化应用场景支持，共有四大线上实战案例，希望对仍在网关选型过程中的企业或用户有所帮助。

君润人力自研系统架构概述

君润人力在搭建自研服务平台架构时，首要原则就是“开放、开源、拥抱云原生”。平台基于 Kubernetes 微服务架构构建云端系统，整体架构参考下图。

右侧是君润自研服务平台，DevOps 流程依托 Git webhook、coding、Kubernetes 集群实现全自动化与无感发布，业务系统基于 PaaS 平台进行迭代开发，确保研发规范，并达成技术栈的统一。上侧是监控手段，系统集成了 sky-agent 和 arthas，满足了线上服务观测多维度的需求。与此同时，采用腾讯日志云与 Kubernetes 结合的方式将服务日志存储在云上，实现 Kubernetes 集群内无文件化服务，避免磁盘容量堆积从而影响到 Kubernetes 集群单个节点的健康。

左侧是业务系统中最重要的环节 —— 流量管理。所有流量会通过 WAF（WAF，Web 应用防火墙，负责网络安全）进入三层网络里面的第一层 CLB，主要负责流量转发；第二层就是云原生网关 APISIX，它承担了业务系统的内部服务治理；第三层则是业务系统的 Gateway 应用内部的网关，负责单系统鉴权和路由。

其中第一层的 CLB 和第二层的 APISIX 尤其重要，它是所有系统的入口，一旦出现问题，那么所有系统将无法被访问。CLB 采用的是腾讯云服务，稳定性、扩展性与抗并发性能都比较高，业务架构需要解决的是第二层云原生网关 APISIX，保证它的高可用。

APISIX-Service 被部署在 Kubernetes 集群内部，Kubernetes 集群采用的是腾讯云提供的服务，为了保证出现问题后能够快速恢复，系统外置了 etcd 集群，使数据得以保留，这是 APISIX 集群高可用的体现。

那么，如何来保证 APISIX 的高并发和高性能？这里系统利用了 Kubernetes 的机制，当 APISIX 进行路由转发时，通过 Kubernetes 的服务名 + 服务端口使它在同一个网段内跳转；因为网关服务部署在 Kubernetes 内部，依托于 Kubernetes 的特性，可以进行滚动升级，进而达到 APISIX 网关升级的无感发布。

通过该架构图不难发现，第二层是所有流量的入口，选择一个满足业务扩张需求的云原生网关，对系统架构来说至关重要，下面谈谈在网关技术选型时的主要思考。

技术网关选型痛点

数量庞大的业务系统。 目前人力资源这个领域有 15+ 服务平台，生态业务多样化，面临的问题也比较多，服务请求需要频繁变更，导致需要操作和配置的路由也非常多。原来系统是基于 CLB 进行流量转发，久而久之，运维人员需要配置和操作的地方非常多，耗费了大量的人力与时间。
频繁的高并发大流量。 举个例子，客户集中在同一天发薪或提现大额资金。在用户数量达到大几十万时，集中进行的某些行为，如打卡、签约、领取任务或工资等，此时系统并发流量非常大，短期翻倍的情况比比皆是。
个性化需求的扩张压力。 APISIX 是基于 OpenResty、Nginx 和 Lua 开发的，但如果用 Lua 来开发插件，会有一定的研发投入和维护成本。对于插件的支持，APISIX 已经提前做好了准备。APISIX 的官网提供了自定义插件来支持 Java 开发，技术栈问题迎刃而解。此外 APISIX 的生态非常好，作为国产网关产品，社区极其活跃，业内实践还特别多，在云原生网关这层来说，业内也是顶级存在。

我们的团队非常开放，做完技术选型后，快速实践落地。从上线部署到服务分批次接入，耗时不到 1 个月时间。目前 99% 的服务通过 APISIX 访问，上线一年多至今零事故，稳定性非常好。下面这张图里，大家能看到 APISIX 的一些特性，红字部分是我们最看重的几点。

APISIX 四大实践场景

下面我们来逐一介绍 APISIX 的四个实践场景。

路由策略

Apache APISIX 基于 Radixtree 和 etcd 提供路由极速匹配与配置快速同步的能力。路由和插件的设计实现都满足了极速性能和超低延迟的需求。比如以下两个场景中，都表现出了不错的性能：

高峰期的 API 紧急停用。 业务系统处在高峰期时，用户导出百万数量级的报表数据，会使 MySQL 数据库直接宕机，此时重启服务也无法解决，用户继续导出操作会持续故障，这个问题以前我们得发版才能解决；而现在只需要运维人员简单配置一番，就可以做到 API 紧急停用，通过路由优先级策略和失效策略（依托 Serverless 插件），配合使 API 接口在分钟级下线，从而保证服务的稳定。
业务系统较多。 其中 SaaS 系统需要支持客户自定义域名访问，我们采用了泛域名匹配，做到一次配置，全局通用。下图是君润人力 2022 年度路由增长趋势图。可以看到，不论前端还是后端路由，在引入 APISIX 之后，都实现了三倍或以上的数量增长。

安全控制

我们基于 APISIX 做了双层网关架构，在 APISIX 上隔离出一个逻辑网关，用户访问 CLB 进来 APISIX 再转发到业务系统。如果用户使用的这个功能需要用到 PaaS，就会通过 PaaS 服务网关进行访问，此时的 PaaS 服务网关就是一个逻辑网关。

我们在 Kubernetes 内部封闭了一个区域，即 PaaS 平台，里面包含大量的基础服务。利用 APISIX 网关的特性：熔断、安全、身份识别，使上层业务系统访问 PaaS 服务都需要通过 PaaS 网关。

流量管理

由于业务系统数量较多，核心服务（SSO、PaaS 服务和发薪服务）可用性要求高，这些服务的流量管控需要依赖 APISIX 提供的流量管理灰度策略。

为此，系统内部采用了两种方式进行。一是基于标签灰度。核心服务上到生产环境之前，测试人员先在灰度环境验证。我们会将测试用户流量转发到灰度服务，进行生产环境验证，验证通过后再基于权重切入流量，观察一段时间，没问题后再把全部流量切换到新版本；二是生产环境内。相同的服务并存多个版本，不同的业务系统访问不同的版本时，基于标签进行路由转发。

日志管理

从下图的架构模式可以看出，APISIX 和 Pod 服务都基于 Kubernetes 架构，所有后端路由都被绑定在同一服务上，在 APISIX 服务上配置的 Kafka 插件用来采集日志数据，同时配置了 Skywalking 监控程序性能。根据 RequestId 和 TraceId 在 Skywalking 和日志云，可以观测到整个调用链路，并查看每个环节的日志记录和 API 请求耗时。

从目前观测到的数据来看，系统每天都有上千万次的 API 请求，平均每天产生的日志数据达到 30G ，日志总量达到 TB 级。

使用 APISIX 的经验与展望

在使用 APISIX 的过程中，我们总结了一些经验之谈，在这里分享给对 APISIX 感兴趣的朋友们。

构建基础镜像需要拉取国外资源。 APISIX 需要部署在 Kubernetes 内部，内部会进行一定的二次开发和源码编译，这时需要到 GitHub 上拉取资源，目前官方提供的 Docker 镜像有一部分需要拉取国外资源，在进行本地开发和线上部署时，环境调试相对麻烦。

调试环境部署有要求。 自定义插件，需要基于 runner.sock 进行 RPC 通讯，现有案例较少，调试起来有一定困难，它需要和 APISIX-Service 在同一个镜像内。

每天产生大量的日志记录到本地。 刚刚发布生产时，我们发现就算只开启 error 级别日志，每天的增长数量都非常大，导致 Kubernetes 集群中一个节点磁盘告警。后面打包镜像时将日志由文件记录改变为输出至控制台，收集至云日志服务 CLS 存储记录分析，实现本地无文件化存储。

当然，以上都属于前期准备工作上的必经之路，在正式投入使用后，APISIX 给我们带来的收益远远大于期望，总体有以下三点：

对业务发展起到了强有力的支撑。 使用 APISIX 后，系统功能更加丰富，性能更加强劲。APISIX 对 API 服务提供了多种可观测性和安全防护手段，可以支持我们每天千万次流量的访问。
助力研发交付效率。 比如原来配置 DNS 解析需要 10 分钟才能生效，而现在通过泛域名配置，几秒钟就能生效；因为原先需要在 CLB 和 Nginx 两个地方手动修改配置，而我们有 10 多个系统、100 多个服务，需要配置的点很多，应用了 APISIX 的泛域名配置后，现在只需要在控制面板上修改，极大地减少 DevOps 工作量。
大幅降低成本。 LB （负载均衡）成本的变化。LB 服务数量由 200+ 缩减到了 10+，大大降低了系统维护成本。后期我们还会有一系列需要借助 APISIX 云原生网关达成的功能开发包括但不限于：集成 Sentinel 使服务具备热插拔动态限流功能、开发多维度流量控制、风控识别功能升级、分层治理和全链路日志分析等等。届时将采用多套 APISIX 集群来满足自研服务平台的功能需求。

总结下来，使用 APISIX 云原生网关给君润人力服务平台带来了非常大的帮助，使我们能轻松应对多样化的复杂场景，打造趋于完美的数字化人力资源服务生态。

本文由博客一文多发平台 OpenWrite 发布！

概述

在某些情况下，Metrics 监控的 2 大顶流：

Zabbix: 用于非容器的虚拟机环境
Prometheus: 用于容器的云原生环境

是共存的。但是在这种情况下，统一监控展示就不太方便，本文介绍利用 Grafana 对接 Zabbix, 来作为统一监控展示端。Let’s go!

在这里，主要是用到了 alexanderzobnin/grafana-zabbix 开源项目。

Grafana-Zabbix 功能亮点

Grafana-Zabbix 是 Grafana 的一个插件，允许可视化来自 Zabbix 的监控数据，并创建用于分析指标和实时监控的仪表板。该项目的主要目标是扩展 Zabbix 的监控数据可视化功能，并提供快速、强大的方法来创建仪表板。

Grafana 与 Grafana-Zabbix 插件相结合，可以创建很棒的仪表板。 Grafana-Zabbix 有如下的功能亮点：

丰富的绘图功能；
使用 Regex 选择多个指标；
使用模板 (template) 变量 (variableds) 创建交互式和可重用的仪表板；
在带有注释 (Annotations) 的图形上显示事件
使用指标处理函数（平均值 Avg、中值 Median、最小值 Min、最大值 Max、乘 Multiply、汇总 Summarize、时移 Time shift、别名 Alias）转换和调整数据
在同一仪表板或面板中混合来自多个数据源的指标
在 Grafana 中创建告警
使用 Problems 面板显示 triggers
在官方库中发现和共享仪表板

快速演示

接下来我们进行一个快速演示，所有资源都安装在 K8s 中。

（前提）安装 K3s
安装 Grafana
安装 Zabbix
在 Grafana 上安装 Grafana-Zabbix 插件并启用
在 Grafana 上配置 DB 数据源和 Zabbix 数据源
在 Grafana 上导入 Zabbix 仪表板并查看监控效果
（可选）在 Grafana 上基于 Zabbix 指标配置告警

安装 K3s

安装完成后执行以下命令查看运行状态：

安装 Grafana

使用 Helm 安装：

这里为了后续使用方便加了 2 个参数：

数据持久化，重启不丢失
方便通过 NodePort 直接访问 Grafana UI

安装 Zabbix

为了图省事，也直接将 Zabbix 安装在 K3s 中。

但是🐾注意，往往在生产使用场景中，Zabbix 是安装在虚拟机环境上的，并用 Zabbix Proxy 和 Zabbix Agent 监控 Prometheus 覆盖不到的区域（典型如：非容器化的物理机、虚机；网络设备；数据库等）

直接在 Helm Chart 官方市场 – Artifact Hub 里找一个安装：

这个 aekondratiev/zabbix-server helm chart 会安装以下组件：

zabbix-server
和 zabbix-server 一起，以 sidecar 形式运行的 zabbix-agent
zabbix-web
postgresql

在 Grafana 上配置 DB 数据源和 Zabbix 数据源

Grafana-Zabbix 的数据库直连功能

这里提一下，Grafana-Zabbix 插件可以使用 MySQL、Postgres 或 InfluxDB 数据源直接从 Zabbix 数据库查询历史和趋势数据。为了执行查询，插件仅需要对、、和表的读访问权限。为了使连接更安全并防止不必要数据泄漏，强烈建议只授予对表的读访问权限。但是如果您想使用这个数据源来查询其他数据，您可以向整个 zabbix 数据库授予 SELECT 权限。此外，所有查询都由 Grafana 服务器调用，因此您可以将连接限制为仅与 Grafana 主机连接。下面是 MySQL 示例：

配置 DB 数据源

在 Grafana 的创建 Data Source 选项中，选择数据源类型并提供数据库主机地址和端口（默认值为）。填写数据库名称（通常为）并指定凭据。如下图所示：

之所以启用数据库直连, 是因为如果海量的 zabbix 历史和趋势数据都通过 zabbix 的 API 查询，性能会有一定问题。

在 Grafana 上安装 Grafana-Zabbix 插件并启用

进入 Grafana 容器中，并使用安装：

🐾Warning:

通过安装插件后需要重启生效，所以一定需要配置 , 否则重启后数据丢失，插件还是没装上。

安装后，就可以启用插件了。

通过 Grafana 的 Nodeport （如：http://192.168.1.5:30000) 访问并登录 Grafana(📝密码在 K8s Secret 中）, 进入 Grafana 侧面板的 plugins 界面，选择选项卡，然后选择，打开选项卡并启用插件。如下图：

配置 Zabbix 数据源

启用插件后，就可以添加 Zabbix data source 了。

要添加新的 Zabbix 数据源，单击并从下拉列表中选择。如下图：

关键的配置项有以下几个：（其他一般不需要动）

HTTP
- URL: Zabbix API url, 一般就是 , 如上图 1 中的：http://zabbix-web.zabbix/api_jsonrpc.php
Zabbix API details
- Username 和 Password: 登录 Zabbix API 的账号密码。记得要用足够的权限。
- Trends: 如果是 Zabbix 3.x 及以上就 enable. 当显示长时间段（超过几天）时这个选项强烈建议使用，因为几天的项目历史包含海量的数据点。使用趋势将提高 Grafana 的性能。
Direct DB Connection
- 启用并选择上面创建好的 Zabbix DB Data Source.

在 Grafana 上导入 Zabbix 仪表板并查看监控效果

之后，导入自带的几个 Zabbix 的仪表板：

接下来就能看到效果啦：

如上图，Grafana 支持灵活的表达式配置 zabbix 仪表板：

Query Mode
Group
Host
item tag
Item: 聚合的表达式
Functions

完全不用担心 Zabbix 上某些复杂的仪表板无法在 Grafana 上复现。

下面是官方的一些 demo:

在 Grafana 上基于 Zabbix 指标配置告警

侧边栏 , 就可以创建基于 Zabbix 的告警，也可以直接在仪表板上编辑 panel 的 alert 进行配置，配置后效果如下：

以上就是本次全部的演示全过程，感兴趣的可以自己尝试复现一下。

🎉🎉🎉

总结

在本文中，我们介绍了利用 Grafana + 插件：Grafana-Zabbix 实现了以下效果：

Grafana 负责展示甚至告警
Zabbix 作为 Grafana 的其中一个数据源。

更近一步，我们的环境上，可能不止有 Zabbix 和 Prometheus 2 个数据源，甚至还会有：

Metrics
- AWS CloudWatch
- …
Logging
Tracing

在这种情况下，将所有的这些监控都视作 Grafana 的数据源，实现监控数据的统一展示和联动：

联动:

在 Slack 上收到 Grafana 发出的告警
链接或仪表板跳转到 Grafana 对应 Dashboard
在 Grafana 上查看相关 Metrics
在 Grafana 上跳转到 Metrics 异常时间点的日志
在 Grafana 上跳转到 Logs 异常的 Trace
发现并在 IDE 上 coding 解决问题

只能说，Grafana 为我们描绘了一个相当美妙的场景，未来可期。👍️👍️👍️

本文由东风微鸣技术博客 EWhisper.cn 编写！

目前针对 DNS 监控的 Grafana Dashboard 并不多，使用率较高的 Grafana CoreDNS 只适用于 K8s 环境，对于云服务器、物理硬件模式下的 DNS 监控也并不通用；同时，对于应用研发人员想定位 DNS 查询异常或者时延问题时，CoreDNS 的 Dashboard 仅提供 DNS 服务端视角，无法从应用视角出发来分析问题，只能依赖自身代码增加了 DNS 日志。

明确这些问题后，我们基于 DeepFlow 构建了对一个高效、可配置、无侵入、面向应用的 DNS 监控面板，可监控 DNS 服务的网络异常、吞吐、时延，以及访问日志，以快速定位性能瓶颈和排查故障原因。部署了 DeepFlow 之后，deepflow-agent 会自动采集所在节点上的可观测数据，我们基于这些数据构建了一个 Dashboard，内容包括：

Overview
Delay
Error
Request
Log Analysis

前往我们的在线 Demo 也可快速体验 Dashboard。

同时，欢迎大家预约 “原力释放云原生可观测性分享会” 直播。

直播活动由云原生社区主办，云杉网络发起，并联合OPPO联合举办，本期聚焦 “浅谈可观测性生态的优化和丰富” 主题。将分享OPPO自研时序数据库在业务高基数、持久化存储、乱序写入、多租户隔离等场景下的思考及实战演进，以及 DeepFlow 对 Grafana 插件做详细解析，讲解如何从零开始开发一个 Grafana 的 Datasource。

直播时间：12 月 8 日（周四） 20:00～21:00
直播平台：云原生社区视频号＆B 站、云杉网络视频号、开源江湖、GrafanaFans
活动链接：https://www.slidestalk.com/m/1336
扫描海报二维码预约直播

0x0: Dashboard 介绍

接下来，详细介绍下 Dashboard 的使用

进入 Dashboard 后，可通过变量来控制需要分析的 DNS 服务端，下面详细说下变量的使用方式：

①：DNS 服务端部署在 K8s 环境中，例如 CoreDNS，使用 // 变量
- cluster：选择 DNS 服务端所部署的 K8s 集群
- dns_service：选择 DNS 服务端对应的 K8s 服务名
- dns_wildcard：通过通配符的形式筛选 dns_service
②：DNS 服务端部署在云服务器环境中，使用变量
- 特别说明：此时需要将 / 设置为
③：使用外部的 DNS 服务端，例如使用运营商提供的，则在变量输入对应的 IP 即可
- 特别说明：此时需要将 // 设置为
④：DeepFlow 可在多个位置采集数据，可通过来控制需要查看的数据统计位置，位置点的详细说明，可参考文档

模板变量说明

设置好变量后，接下来就可以利用 Dashboard 来分析 DNS 了，通过 Overview 可快速了解、、、，得到大概总览情况后，可以结合、、模块中的曲线快速分析问题发生的时间点，然后利用分组，可快速得到触发问题发生的客户端服务

Overview

Error

Delay + Request

接下来可以利用模块来详细分析发生问题的客户端服务的 DNS 请求，分析之前，需要先设置和变量

⑤ client_for_Log_Analysis：输入在前面模块得到的客户端服务
⑥ status_for_Log_Analysis：确定需要分析的 DNS 请求的状态
⑦ domain_for_Log_Analysis：输入需要分析的 DNS 请求的域名

模板变量说明

通过模块，可快速得到存在问题的 TOP N 、、、以及客户端服务访问 DNS 的整个时延分布

Log_Analysis

接下来，让我们结合实际案例，来体验一下 DNS Dashboard 给我们带来的高效分析能力。

0x1: 案例1 – 无效内部域名解析

现象：

我们的集群里的应用规模不大，理论上 DNS 请求不会太多，但我们打开 DNS Dashboard 后，发现有大量 DNS 查询请求，且有访问异常：

Client Request Log Error

其中有较多 DNS 客户端异常，响应码为 0x3，错误描述是：Non-Existent Domain，意味着应用访问了不存在的域名。（更多的异常定义可见 DeepFlow-数据库字段定义）

我们通过异常排序，查看访问无效 Top10 域名，发现大量 DNS 请求后缀包含了，而这是 k8s 自动填充的搜索域：

Client Request Domain TopN Error

原因分析：

我们结合 k8s 的 DNS 原理来分析问题原因。首先，一个典型的 k8s Pod 中 resolv.conf 文件的内容如下：

1 2 3

search default.svc.cluster.local svc.cluster.local cluster.local nameserver 10.96.0.10 options ndots:5

这里有三个配置，是域名检索的搜索域，是集群内的 DNS 服务地址，是自定义选项，其中 ndots=5，意味着当一个域名中包含的数量小于 5 时，会优先解析为内部域名，并按照 search 的顺序依次添加搜索域后缀来检索，如果它依然无法被解析，才会把这个域名当作外部域名来解析。
那为什么 k8s 的 ndots 默认配置是 5 呢？Issue#33554 也做出了解释，简单来说：

同命名空间下，形如的域名要被优先解析为内部域名，所以 ndots>=1，并在搜索域 $namespace.svc.$zone 下搜索。
跨命名空间下，形如的域名要被优先解析为内部域名，所以 ndots>=2，并在搜索域 svc.$zone 下搜索。
访问非 Service Name 时，形如的域名要被优先解析为内部域名，所以 ndots>=3，并在搜索域 $zone 下搜索。
对于 StatefulSet 类型的应用，由于需要支持形如的域名内部解析，所以 ndots>=4。
对于形如的 SRV Record 要被优先解析为内部域名，所以 ndots>=5。

综上，k8s 的 resolv.conf 中 ndots 默认值是 5 。但这符合我们的使用场景吗？我们要访问的域名是一个小于 5 的外部域名，但它被解析为内部域名，并尝试通过 $url.default.svc.cluster.local / $url.svc.cluster.local / $url.cluster.local 的顺序来解析，最后才去访问 $url 本身，所以产生了大量的异常记录。

修复建议：

要解决这个问题，有几个可选的方案：

k8s 文档中 Pod DNS 配置一节，只需要修改 Pod 的 DNS 策略，定义 ndots=2，这样就可以优先将域名解析为外部域名，弊端在于这样反而会使得内部域名的解析变慢。
把访问的外部域名修改为 FQDN，比如我们要访问的是，修改为，这样可以直接访问域名，不会依次检索搜索域。
CoreDNS 使用 autopath 插件，减少搜索次数，但这依赖于 API Watch 机制，会使得 CoreDNS 增加内存消耗。
使用 Node LocalDNS，增加 DNS 解析性能，减少 CoreDNS 压力，但同样的，它需要使用内存来做 DNS 缓存查询，增加了内存消耗。

经过权衡，方案(2)对集群的侵入性和修改难度是最低的，效果也比较理想，所以我们采用方案(2)达成了目标。

0x2: 案例2 – 对已失效服务的依赖

现象：

同样通过 DNS Request Log 分析，我们发现还有大量的 Non-Existent Domain 异常，且它不是访问外部域名：

Client Request Domain TopN

原因分析：

集群里没有 zipkin 的 Service，按照上述的 k8s 的 DNS 原理分析，在访问域名的时候同样会尝试按搜索域顺序依次访问，造成了不小的 CoreDNS 压力，这说明应用的配置有错误，尝试访问无效的服务，导致冗余的开销。

修复建议：

检查代码或配置中是否还在访问失效的服务，去掉配置后恢复正常。

0x3: 后续规划

我们目前在制作一批 Dashboard，包括：Nginx、MySQL/PostgreSQL、HTTP、Dubbo/gRPC、Kafka/MQTT、TCP/UDP/IP 等，希望能带来社区高度自动化、高精度的可观测性体验，期待有社区的小伙伴能加入一起。

0x4: 什么是 DeepFlow

DeepFlow 是一款开源的高度自动化的可观测性平台，是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术，创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制，帮助开发者提升埋点插码的自动化水平，降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口，开发者可以快速将其融入到自己的可观测性技术栈中。

GitHub 地址：https://github.com/deepflowys/deepflow

访问 DeepFlow Demo，体验高度自动化的可观测性新时代。

作者：李浩

责编：宇亭

当我们选择一款 HTAP 数据库时，总是先被其相关文档里所描述的优异性能所吸引。卓越的性能是我们选择一款产品的出发点，因为我们希望该款产品能够解决我们业务中的痛点。而大家使用 HTAP 产品的出发点就是希望该款数据库能够解决我们在事务处理过程中的实时分析痛点。不过，性能优势只能算作我们选择一款产品的考量因素之一，实际上，公司层级去选择一款HTAP产品时，还需要额外考量一些其他的因素，本篇文章，StoneDB首席架构师李浩给大家分享一下选择 HTAP 产品的六大关键考量因素。

在 TP 产品非常成熟的今天，各类 TP 类型数据库早已在各行各业中支撑着业务系统的高速发展。随着业务系统越来越复杂，所产生的数据量也在飞速增长。同时，对于这些数据的实时分析需求也日益迫切。然而，当前的解决方案却无法满足实时分析的需求。例如：如果直接在TP数据库上进行分析，虽然可以满足实时性要求，但其分析的性能基本无法满足要求，并且在进行分析时会占用大量的计算资源和 IO 资源，从而影响到 TP 性能。因此，传统的做法是将分析任务放在业务低峰时候（通常是半夜进行，因此大家经常会看见 T+1的说明情况）。

HTAP 的出现则解决了这个实时数据分析的痛点。HTAP，即Hybrid Transaction/Analytical Processing，一套系统可以同时解决 TP 需求和 AP需要。如果你的业务对于 TP 业务所产生的数据需要进行实时的 AP 分析，那么 HTAP 将会是你很好的选择。
Gartner 预计在 2024 年左右，HTAP 市场将会走向成熟。 从最早 2014 年概念的提出到最近这几年，国内外对于 HTAP 已经从概念走向具体的产品落地。早期大家炒炒概念还可以接受，但显而易见，现在的市场越来越明确地走向产品质量和方案落地的竞争。
无论国内外的 SnowFlake（Unistore）、Google（AlloyDB）、Oracle（ HeatWave ）还是国内的 TiDB、OceanBase、StoneDB 等都推出了其各自的 HTAP 产品并且在积极的落地到生产系统。那么面对越来越多的 HTAP 产品，我们该如何选择一款适合自己业务的 HTAP 数据库产品呢？我们选择一款 HTAP 数据库又需要从那些方面进行考察呢？本篇文章中，StoneDB将给出一些自己的思考，需要说明的是，本篇作为产品选择篇，我们不从技术架构和具体的实现上进行讨论，而是主要从业务需求端的角度来作分析。 对于硬核的技术实现角度，我们将在《什么是真正的 HTAP？实践篇》的下一章进行讨论。

业务场景

首先，我们从业务场景的角度来讨论如何选择一款HTAP数据库，主要有以下四个维度：

1.1、业务类型
业务所在的领域决定了产品底层技术栈的选择。这个很好理解，比如电商这个业务场景所需要的技术栈和产品特点与传统制造、CRM 等所关注的侧重点就完全不一样——电商关注高并发、低延时、 数据一致性和秒杀场景等等，而传统制造商则对海量多样化数据的处理和如何有效挖掘数据价值这些方面更加关注。
在不同的业务类型下，选择一款 HTAP 产品需要重点考察的是——这个业务类型需要哪一部分能力为主：TP 能力为主亦或是 AP 能力为主。
对于电商系统需要更加注重其在 TP 方面的关键能力，例如：事务、数据一致性等等；而对于CRM系统，经销存等等对TP能力则不会那么严苛，其可能更加看重AP的能力，在 TP 能力满足其基本业务需求的情况下，哪款产品的 AP 能力更强，业务侧可能会更倾向于选择该款产品。
而现有 HTAP 产品从技术实现路线上，基本可以分为这么两类路线，其决定产品的基因：即侧重于 TP 还是 AP？
路线1： 以成熟的TP系统为基础，在其上进行AP能力的扩展。现有大部分 HTAP 数据库产品均采用该种策略。为什么采用该种策略？其原因是显而易见的，TP 系统发展到现在其相较于 AP 系统，更加成熟。例如：国内外的 OB，StoneDB，TiDB，Oracle MySQL Heatwave 和 Google AlloyDB 等； 路线2： 在 AP 系统的基础上扩展其处理 TP 的能力。例如：Snowflake 等。这种路线，比较困难，但是成熟的科技公司会有更多的资源去做这个事儿，难度大，但是做出来了，也会是一大利器。

1.2、端到端的解决方案能力：
对于业务开发相关人员，一个新产品或者解决方案的引入，自然希望不会给其带来额外的工作负担，并且最好能够与其原有的技术栈相兼容，这样对于原有业务系统的改动要求最少。但也不完全就是为了让干的活儿更轻松一些，因为，对于一个在线运行的系统，其对于稳定性的要求非常高，而新组件的引入往往会让整个业务的不稳定因素增大。因此，如果不能够保持原有的技术栈，则需要提供端到端的解决方案。例如： 原系统采用的 ClickHouse 或者 ElasticSearch， 如果需要替换为 OB 或者StoneDB ，那么需要考虑原系统 ClickHouse 或者 ElasticSearch 上下游相关模块接口兼容性，数据同步 到 CK 或者 ES 的方式等等，这些解决方案都要提供出来。
1.3、数据实时性要求：
数据实时性的高低同样也会影响到产品的选择。 当前现有的 HTAP 数据库在 TP和 AP 之间的数据同步策略实现机制不尽相同。例如：有些云厂商通过 MySQL+Binlog+ClickHouse 的组合方式提供 HTAP 服务，从用户的角度看似乎该服务具备了HTAP的能力，但实际上完全不是那么回事儿——因为通过 Binlog 这种方式会有很多弊端，这里可以参考我们之前的两篇文章；又如有厂商通过 TP+Redo+Raft+AP 这样的组合构成 HTAP 产品，其相较于前一种在数据的实时性上有了较大的提升，但也只是提供数据的最终一致性，同样数据的实时性还是得不到保证；有的厂商则采用了基于 LSM-tree 实现的行列混存，这种可以基本保证对于数据实时性的要求；而像 MySQL Heatwave 和 StoneDB 则提供了基于内存计算的强实时性的方案。
HTAP 数据库在产品具体实现的时候，其选择的存储方案会直接到影响架构的选择：是一体化的架构？还是 TP 系统叠加 AP 系统的方案？架构的选择则会直接决定数据同步策略和数据实时性的高低。
1.4、技术能力：
产品背后其公司所代表的技术实力也是业务方选择一款产品的考量因素，例如：我们在下文第六点中给出的观点。

性能

考量完业务场景相关的因素后，接下来需要考量的一个重要因素就是性能。不同于TP系的 Benchmark TPC-C 或者 AP 系统的 Benchmark TPC-H，对于HTAP 的性能测评一般不再使用这两个传统的方式来进行衡量。

当前大家更多地使用 TPC-H 来对其 AP 的能力进行评估，该种方法可以对其系统有一定的评价作用，但也存在着一定的弊端，那就是 TPC-H 无法全面地衡量一款 HTAP——因为 HTAP 数据库的系统中会同时存在两类负载：TP负载和AP负载 。两类负载需要同时使用系统的CPU资源、IO 资源和网络资源等等。对资源的竞争会导致两类负载的相互干扰。因此，为了更好的衡量 HTAP 数据库，无论是学术界还是工业界，都逐渐提出了一些适用于HTAP数据库的 Benchmark 系统，具体可以参考我们之前的文章：《 如何给一个 HTAP 数据库做基准测试？ 》
这里也简单提一下，除了具体的性能指标，例如：TPS、 QPS、吞吐量等等，资源隔离性也是我们的重要考量。而资源隔离通常有两种方式： （1） 通过系统手段（软件）隔离。 例如，通过 Cgroup 的方式进行资源的管理； （2） 通过物理手段进行隔离。 例如，依据不同的负载类型 Route 到不同引擎上，将 AP 查询路由到列存引擎节点上，这样可将 TP 负载和 AP 负载运行于不同的节点上，从而做到真正的物理隔离。

运维

运维的难度也需要我们认真考量。 数据库的运维不同于其它基础系统，其对于 DBA 的综合素质有比较高的要求。在系统长时间运行的过程中会遇到各种数据库的使用、功能、性能等等问题。解决这些问题除了需要数据库、操作系统和业务等多方面的知识，同样也需要相关运维工具的支持。运维手段和运维工具可以高效的支持 DBA 的运维工作。复杂的系统形态，会导致 DBA 的运维工作量增大，最直接的影响就是难以快速定位问题，增加了解决问题的耗时。

生态

生态是选择一款 HTAP 数据库的一个重要因素。 当前有两类生态：PostgreSQL 和 MySQL。选择哪一种生态，会直接影响到后续围绕数据库所构成的整个技术栈。同时，业务也会从其自身的特点选择相应的技术路线。例如：如果业务系统是基于 JSON 和 GIS 能力的话，那么多数的业务开发者可能更倾向于选择 PostgreSQL 生态；如果是电商业务则更多的会选择 MySQL 生态。
具体来讲，生态中的周边工具、中间件和解决方案的完整性和丰富性非常重要。除工具、方案外，社区参与的人数（不管是对开源的 HTAP 数据库，还是对于商业或云上的 HTAP 服务，都需要考量该使用该服务的人群数量），更多的社区参与人数往往意味着社区比较活跃，那么，我们使用者遇到的一些问题就可以得到快速的响应。
生态的繁荣也从另外一个侧面反映出该技术路线获得了相当多的上下游厂商的支持。

成本

成本是一个无法绕过的话题，一般企业/组织内的管理者对于成本的关注度往往是多于其他项的。 如果想要使用一款 HTAP，需要考量的成本主要包括以下几个方面：硬件成本、替换（迁移）成本、运维成本等：

5.1、硬件成本：
其中最主要包括： 计算成本和存储成本。 在 StoneDB 实际的产品 POC 过程中，遇到很多客户实际的业务数据量在 100GB-1TB 内。如果采用一些现有的其他国产 HTAP 产品，由于这些产品对最小集群有要求，从而使得这些小厂商在使用 HTAP 服务时，必须付出比较高的集群硬件成本，这个是他们不愿意接受的。特别地，当需要替换现有MySQL数据库的时候，目前的一些国产 HTAP 数据库，基本都存在 MySQL 语法兼容性的问题，这导致迁移到新的业务系统上需要进行大量的修改，从而造成整体成本的飙升。如果厂商比较在乎这一部分的成本的话，StoneDB 就是很好的选择了。
5.2、替换成本：
需要能够提供对于原系统的 平滑迁移 能力。对于业务侵入改动最小，业务无需做修改即可平滑迁移到新的数据库平台。
5.3、运维成本：
在第三点中我们讨论运维问题，这里就不再详细讨论了。运维成本将会是系统稳定后，最主要的支出成本。

LTS 支持性

对于LTS（Long Term Support，长期支持版）支持性，这里又可以从两个方面来讨论。 （1）商业 HTAP 数据库 （2）开源 HTAP 数据库 无论对于商业数据库还是开源数据库都面临某个版本的生命周期问题。
商业数据库相对来说，其售后服务有保障，但同时商业数据库又面临闭源和售后服务需要支付昂贵的服务费用等问题。而 开源数据库，其 LTS 的支持除了需要社区支持以外，也需要由其背后的公司来进行保证。我们也很容易发现， 一个成功的开源数据库项目背后，通常都有一个成功的商业公司支撑。
因此，无论是选择哪类 HTAP 数据库，都需要注意所选择的产品的 LTS 支持性的问题。
好了，以上就是我们总结的选择一款 HTAP 数据库需要考量的六大因素，也即：业务场景、性能、运维、生态、成本和 LTS 支持性，希望对于这六点的分析能给大家在做 HTAP 产品选型时提供帮助。
StoneDB 的 2.0 架构完全对标 Oracle MySQL MDS（HeatWave），目前，我们的架构设计方案的RFC文档也完全公布在了 Github 上： https://github.com/stoneatom/stonedb/issues/436 如果您想了解更多，也可以关注我们的 Github 仓库： https://github.com/stoneatom/stonedb 本周五（12月9号）下午，StoneDB 开源社区PMC、StoneDB 首席架构师李浩老师也将参与由 ITPUB 社区举办的开源小秀场线上 Meetup 活动，欢迎大家前往官网 http://os.itpub.net/ 关注：

以上就是本次的分享，欢迎大家批评指正。如果您还有其他疑问，欢迎添加StoneDB小助手，加入StoneDB开源社区技术交流群，在群里您可以随时提问，我们会认真为您解答。

扫码添加小助手

加入StoneDB开源社区用户群

讨论交流，共同进步

今年 2 月，Alluxio 宣布以实现收入同比增长 3 倍的成绩结束了 2022 财年。“这个财年的业绩进一步表明了市场需要更好的方法来访问大规模分析和 AI/ML 应用程序中的数据，尤其是在分布式混合云和多云环境中。”Alluxio 创始人兼 CEO 李浩源表示。

事实上，从当初一个论文项目到如今被市值最大的十家公司中的七家使用，李浩源用了九年的时间。那么，Alluxio 这样一个基础软件领域的创企，是如何从零成长至取得如今成绩？Alluxio 又会如何应对当前动荡的市场呢？

起步：另辟蹊径的数据架构

2000 年初期，大数据伴随着互联网的蓬勃发展应运而生，从而衍生出整个数据科技的发展。从宏观角度看，数据科技可以分成两层：上层的计算和下层的存储。一直以来，存储占据了整个数据生命周期的绝大部分。

2013 年，北大毕业后来到伯克利攻读博士学位的李浩源在准备毕业论文时，自然而然地想要做存储相关的选题。但在调研了存储行业的发展历程后，李浩源发现，这个行业每 5～10 年就会发生一次革新，新产品取代上一代产品。同时，存储市场极其分散，没有一家企业的市场份额能占到 25%以上，也没有一款产品的数据存储量能占整个全球数据量的 5%以上。

有鉴于此，在存储领域做到改变行业的颠覆性创新，在可预见的未来几乎是不可能的。”李浩源说道，“但是，我们可以把存储里面的数据管理好，让这些数据更好地来服务上层数据应用，从而提高整个社会效率。”

带着这个想法，李浩源提出了一种新的架构，即将虚拟分布式文件系统（Virtual Distibuted File Syestem）作为计算层和存储层之间的新层，为上层 Spark、Presto、Tensorflow、Pytorch 等计算框架提供服务。

这就是李浩源的博士论文《虚拟分布式文件系统》研究的主题。这个项目在当时被称为 Tachyon，也是如今 Alluxio 的前身。

伯克利大学一直有开源的传统，李浩源顺应了这一传统，在第一时间将这个项目开源。开源后，李浩源发现整个技术演进路线的确在往其预想的方向发展，项目也有了越来越多的用户，收到了越来越多业界的正向反馈。

不过，要想实现更宏大的愿景就需要更加体系化的公司化运营，因此，2015 年，李浩源选择了创业。

创业初期，很多事情都要李浩源亲力亲为，但最重要的还是按照规划把产品打磨到 1.0 版本。“我们要把代码写好，大家对代码有了反馈后去进行支持或回应，把产品打磨的越来越好。”李浩源说道。

2016 年，Alluxio 1.0 版本正式发布，这是首个以内存为中心的虚拟分布式存储系统，统一了数据访问的方式，在上层计算框架和底层存储系统之间搭建了桥梁。

与此同时，Alluxio 开源社区也在不断发展。社区日常管理由 PMC（项目管理委员会）负责。而在有了更多用户后，李浩源开始把更多时间用在与用户和开发者交流上，希望参与进来的人可以为社区做出贡献。据悉，Alluxio 目前在 GitHub 上的贡献者已超过 1,200 人，社区 Slack 频道成员接近 10,000 人。

开源助力商业化

产品逐渐成熟后，Alluxio 开始进入商业化阶段。早期没有客户时候的商业化很难，但好在 Alluxio 的开源社区获得了一些行业和社区的认可，因此当这些开发者有需求的时候便会主动找到 Alluxio。李浩源也很重视与潜在用户的交流，帮助解决用户具体痛点，建立信任后再进行更大的合作。这样的方式，帮助 Alluxio 完成了早期用户积累。

Alluxio 的商业化模型与其他开源产品差不多，都是在开源版本基础上添加商业化功能，并以付费的企业版输出，企业版根据客户使用的节点情况收取费用。

据悉， Alluxio 企业版在全球市场客单价从几十万美到数百万美规模不等，客户多集中在科技、金融、电信等行业。李浩源此前表示，Alluxio 90%的客户都是全球五百强，产品已经得到很好的市场验证。

随着企业的发展，李浩源开始将精力放在为公司的整体发展和方向做出决策，以确保制定最为有效的战略，让公司成长为一家全球领先的企业。

实际上，自 Alluxio 创立以来，数据生态系统发生了巨大的变化，越来越多的企业开始上云。与在传统数据仓库中提供托管分析工作不同，云中的数据服务变得更加遥远（如从 S3 传输）、孤立（如分布在多个不同的区域或存储服务中），并且通常在性能上存在很大差异。

为此，在 2019 年的纽约 AWS 峰会上，Alluxio 发布了大版本 2.0，针对多云增加了多项功能，包括支持跨本地和任意数量云进行自动数据分层等，还为云计算优化数据访问、与 AWS Elastic Map Reduce (EMR) 服务集成等。

而最近发布的2.9版本增加了跨环境集群同步功能，支持横向扩展的多租户架构，显著改进在 Kubernetes 上部署的工具集和指南，增强 Alluxio 的易管理性，并通过优化 S3 API 和 POSIX API 实现安全性和性能提升。

如今，全球头部互联网企业 Facebook、Airbnb、Uber、阿里巴巴、腾讯和字节跳动等已经在生产环境里部署了 Alluxio 的软件系统；全球前六名的云厂商中有五家云厂商已经嵌入了 Alluxio 的技术；全球前两名的芯片厂商英特尔、英伟达也在使用 Alluxio。

同时，Alluxio 也正在全球扩大目标市场规模和研发运营覆盖范围，其中包括大力拓展国内市场业务，将北京设立为中国区总部，并成立本地化的研发团队。今年 9 月，Alluxio 还与北京大学计算机学院签署产学研合作框架协议。

如何“过冬”

作为创业公司，Alluxio 在科研方面一直在进行大量投入，员工人数相比之前也实现了三倍增长，并且还在进一步扩大公司执行管理团队等。这些投入的背后主要来自 Alluxio 自身快速增长的营收和投资人的支持。

一方面，Alluxio 在前年营收实现了同比 3.5 倍的增长，去年实现 3 倍增长。另一方面，Alluxio 一步步兑现甚至超额完成预期也得到了投资人坚定支持，比如 a16z 一直在加磅 Alluxio。

不过当前受疫情影响，资本进入“寒冬”，全球企业都在面临着一场生死“大考”，Alluxio 也不例外。对此，李浩源的应对之道就是“练内功”。

“在市场动荡的情况下，企业更多还是要做好核心根基。正所谓‘集中力量练内功’，本质上就是把核心产品做得更好，为你的核心客户带来更多的价值，让已有客户更满意，在此基础之上再扩张。”李浩源补充道，“这也是 Alluxio 一直以来的发展策略。”

结束语

未来，Alluxio 将继续加强对大规模数据分析、人工智能技术的支持，通过加强与 Kubernetes 的整合等方式，优化用户使用体验。而对于其进一步深入扩展全球市场能做出什么样的成绩，李浩源很有信心。

“兵来将挡，水来土掩，面对未来的种种困难，只要一一处理就好了。”李浩源说道。

内容转载自：InfoQ
作者：褚杏娟

想要了解更多关于Alluxio的干货文章、热门活动、专家分享，可进入【Alluxio智库】：

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

2022年12月6日，MiniFramework 发布了 2.9.5 版本，主要变化如下：

新增 MiniBaseRequest 类的 getHost() 方法，用于获取当前请求的 HOST 地址。
新增 MiniBaseRequest 类的 getUserAgent() 方法，用于获取当前请求的客户端 User-Agent 信息。
改进 MiniBaseRequest 类的 getHeaders() 方法，支持获取指定名称的 Header 信息。
改进 MiniBaseModel 类的 regDb() 方法，当注册的数据库对象已经存在时会抛出异常。
改进 MiniBaseModel 类的 useDb() 方法，当无法正常使用数据库对象时会抛出异常。
改进 MiniBaseLayout 类的 setLayoutPath() 方法，增加针对参数的类型约束。
修复 MiniDbMysql 类在某些特定场景下无法正常加载 PDO 扩展的问题。
优化 MiniDbMysql 类的异常报错信息。

（了解详情：https://gitee.com/jasonwei/miniframework/releases/tag/2.9.5）

获取源代码：

Gitee（推荐）：https://gitee.com/jasonwei/miniframework

Github：https://github.com/jasonweicn/miniframework

开发者指南：

在线版：https://www.miniframework.com/docv2/guide/

MiniFramework 是一款遵循 Apache2 开源协议发布的，支持 MVC 和 RESTful 的超轻量级 PHP 开发框架。如果对您有所帮助，请不要吝惜您手中的小星星噢！

ioGame 是一个由 java 语言编写的网络游戏服务器框架。支持 websocket、tcp ，适用于全球同服、回合制游戏、策略游戏、即时战斗等游戏服务器的开发。具有高性能、稳定、易用易扩展、超好编程体验等特点。可做为 H5、手游、端游的 java 游戏服务器。

ioGame 是轻量级的网络游戏服务器框架，在使用 ioGame 时，只需一个依赖即可获得整个框架，而无需在安装其他服务，如： Nginx、Redis、MQ、Mysql、ZooKeeper、Protobuf协议编译工具 … …等。简单点说，就是无需安装其他产品，就能支持开头介绍的内容特性；这意味着在使用上简单了，在部署上也为企业节约了成本。

通过 ioGame 你可以很容易的搭建出一个稳定、高性能、集群无中心节点、分步式、自带负载均衡、跨进程通信、避免类爆炸设计的网络游戏服务器。游戏框架借助于蚂蚁金服 sofa-bolt 通信框架来提供通信方面的稳定与高性能。

在 ioGame 中能让你遗忘 Netty，你几乎没有机会能直接的接触到 Netty 的复杂，但却能享受 Netty 带来的高性能。对开发者要求极低，为开发者节约开发时间。

即使之前没有游戏编程的经验，也能参与到游戏编程中。如果你之前具备一些游戏开发或者 webMVC 相关的知识，则会更容易上手游戏服务器的开发。

ioGame 可以做到同样的一套业务代码，无需开发者做代码的变更，就能同时支持多种通信协议：websocket、socket。简单点说，就是一个游戏服务端的项目，具有同时对接 socket 和 websocket 游戏客户端的能力。

ioGame 可以做到同样的一套业务代码，无需开发者做代码的变更，就能支持多种协议的切换，如：protobuf、json。协议的切换是简单的，只需要一行代码。简单点说，如果开发者的项目之前使用的是 json 数据来传输的，以后想改用 protobuf 来传输，是不需要改变业务方法的。框架除了内置支持的 protobuf、json 协议外，开发者还可以对协议进行扩展。

开发者基于 ioGame 编写的项目、模块通常是条理清晰的，得益于框架对路由的合理设计。当我们整理好这些模块后，对于其他开发者接管项目或后续的维护中，会是一个不错的帮助（模块的整理与建议）。

基于 ioGame 编写的项目，通常是语法简洁的、高性能的、低延迟的。框架最低要求使用 JDK17，这样即可以让项目享受到 ZGC 带来的改进，还能享受语法上的简洁。从 JDK17 开始 GC 已经处理得越来越好了，JDK17 中的 ZGC 远低于其亚毫秒级暂停时间的目标；当开发者使用 JDK17 时，相当于在你们的项目中变相的引入了一位 JVM 调优大师，详细请看 JDK17 垃圾回收GC性能飞跃提升。

在部署上，支持多服单进程的方式部署（类似单体应用、在分步式开发时，调试更加方便）、也支持多服多进程多机器的方式部署。在部署方式上可以随意切换，而不需要更改代码；日常中按照单体思维开发，在生产上可以使用多进程的方式部署；当然，也可以使用单进程的方式部署。

ioGame 框架职责清晰、业务开发几乎零学习成本、源码有高质量注释、示例多、使用文档多，开发体验最佳、业务代码自动生成与游戏前端对接的文档、逻辑服之间可跨进程跨机器通信、业务代码定位–神级特性、异常机制。提供了丰富的在线高质量使用文档，为你的团队助力，带上你们的小伙伴一起，这样就不用手把手的教了。

ioGame 可以很方便的与 spring 集成（5 行代码）。

综上，ioGame 屏蔽了很多复杂且重复性的工作；超棒的开发体验，使用简单，无中间件依赖，只需一个依赖即可获得整个框架；减少了学习成本、减少了使用成本、减少了开发者的工作量、减少了项目的运维成本。并可为项目中的功能模块结构、开发流程等进行清晰的组织定义，减少了后续的项目维护成本。从而让开发团队更方便快捷高效的开发游戏项目。

11月我们发布了 HStreamDB 0.11，修复了多项已知问题。同时也在继续推进 HStream Platform 的开发，并计划于本月底上线首个 Alpha 版本。

v0.11 发布

随着云原生流数据库 HStreamDB 项目的日益成熟，为了更好地适应项目发展，我们决定逐渐缩短发版周期，以更快的速度进行迭代。因此，继10月底我们发布 v0.10 之后，11月我们又发布了 v0.11，主要带来了以下更新和问题修复：

调整 HServer 的启动参数和为和，使它们更容易被理解和使用
移除 HServer 端的压缩选项，目前推荐使用端到端压缩功能
统一内部资源命名规则并改进了相应的资源命名校验
支持获取 stream 和 subscription 的创建时间
修复对部分 Client 的 RPC 请求的路由校验
HStream CLI 新增 subscription 子命令
修复提交 subscripton 进度可能失败的问题
修复 query 的 join 可能产生错误结果的问题
修复写操作超时不可重试的问题

hdt 新增对 ELK Stack 的部署支持

hdt 是 HStreamDB 的自动化集群部署工具，目前它除了能在多个节点上快速部署 HStreamDB 的核心组件外，还支持同时可选地部署 Prometheus、HStream Exporter、Grafana 等监控组件。

为了更方便用户部署测试以及观测 HStreamDB 集群，11月 hdt 新增了支持通过部署 ELK Stack 来收集和查询 HStreamDB 的运行日志，如果启用了相应选项，hdt 在部署的过程中会自动配置好 Logstash 将 HStreamDB 集群的日志导入 ElasticSearch，并提供默认的 Kibana 面板。

HStream Platform 即将上线

HStream Platform 是我们即将推出的基于公有云的 Serverless 流数据平台服务，提供免部署、零运维、高可用、一站式的流数据存储、实时处理和分析服务。

HStream Platform 的首个 Public Alpha 版本计划将于本月底上线，届时将提供免费的注册试用，敬请期待！您也可以在 The Next-Gen Streaming Data Platform in the Cloud 提前注册，第一时间获取上线通知。

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://hstream.io/zh/blog/hstreamdb-newsletter-

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

漏洞描述

Apache Camel 是一个基于规则路由和中介引擎，提供企业集成模式的 Java 对象的实现，通过应用程序接口来配置路由和中介的规则。

受影响版本的 Apache Camel 的 camel-ldap 组件中由于 LdapProducer.java 类没有对 ldap 搜索字符串有效过滤存在 ldap 注入漏洞。攻击者可利用此漏洞向 camel-ldap 服务发送恶意构造 ldap 搜索字符串绕过 ldap 过滤器，从而获取对 Apache Camel 目录的未授权访问权限，查看或修改系统目录中的敏感文件信息。

漏洞名称 Apache Camel camel-ldap 组件存在 LDAP 注入漏洞漏洞类型 LDAP查询中使用的特殊素转义处理不恰当（LDAP注入）发现时间 2022-12-06 漏洞影响广度小 MPS编号 MPS-2022-63953 CVE编号 CVE-2022-45046 CNVD编号 –

影响范围

org.apache.camel:camel-ldap@[3.14.0, 3.14.6)

org.apache.camel:camel-ldap@[3.18.0, 3.18.4)

修复方案

升级org.apache.camel:apache-camel到 3.14.6 或 3.18.4 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-63953

https://nvd.nist.gov/vuln/detail/CVE-2022-45046

https://camel.apache.org/security/CVE-2022-45046.html

https://github.com/apache/camel/commit/ad44f93fa9df74b2accde0b8812f6798f92ad0bf

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

Brave Software（Brave 浏览器所属公司）宣布在其搜索引擎 Brave Search 上投放广告，但承诺 Brave Search 上的广告会保护隐私，不会跟踪搜索引擎的用户。

在 Brave Search 的搜索结果中，广告投放的搜索结果带有非常清晰的广告标记，以便与自然搜索结果区分。“广告图标”显示在 Brave Search 广告的右侧，该功能目前处于 Beta 阶段，因此图标上也附有 Beta 标签。此外，在测试阶段Brave Search 上只显示文本广告。

Brave 承诺广告不会跟踪或分析用户。该公司透露，其搜索广告仅使用三种类型的信息在 Brave Search 上展示广告：搜索查询、国家和设备类型。理论上，搜索行为和搜索内容中会包含大量可识别的用户信息，但 Brave 称其搜索引擎“不会保留任何类型的用户搜索资料”。换句话说：Brave Search 将回到互联网广告的经典时代，广告都是根据页面或网站主题显示。

不想在搜索中看到广告的 Brave Search 用户需要订阅 Search Premium，Search Premium 每月 3 美，将在 Brave Search 上提供无广告的搜索结果。

Brave Software 于 2015 年由 Brendan Eich 和 Brian Bondy 联合创立，其中前者是 JavaScript 的创造者，同时也是 Mozilla 联合创始人。Brave Software 旗下的 Brave Software

在 2021 年底，Brave 浏览器已连续第五年将月活跃用户数量翻了一番，其月活跃用户从 2020 年底的 2400 万增加到 5020 万，日活跃用户超过 1550 万，其广告收入更是处于高速增长期，年增长达 400%。

近日，惠州高盛达科技有限公司（以下简称“高盛达”）签署openKylin社区CLA（Contributor License Agreement 贡献者许可协议），正式加入openKylin开源社区。

高盛达成立于1999年，是一家致力于电子产品研发、生产和销售的高科技现代化企业，主要经营WI-FI/BT 、2G/4G Cat1、Zigbee、NB-IOT、语音、毫米波、UWB、智能感知与交互等无线模组;遥控器、高频头、智能触控屏产品、智能终端产品、模组代加工等，其综合实力位于全国同类企业前列,被授予“广东省高新技术企业”。

在加入openKylin社区后，高盛达将开放合作，给openKylin社区带来更多创新活力，并积极参与社区共建，完善社区生态适配体系，助力openKylin生态跨区域、跨产品形态式发展，成为引领桌面操作系统发展的根社区。

社区会员持续招募中

目前，openKylin社区会员招募正在火热进行中，欢迎更多企业伙伴加入，携手共建，打造桌面操作系统顶级社区，推动国产操作系统产业生态健康发展。详情可查看：【https://sigusoft.com/s/yk82DEQSG0knaQNKyc-vsg 】

审核：openKylin

Github：https://github.com/bytedance/sonic-cpp

为什么自研 JSON 解析库

图 1.1 yyjson、simdjson 和 rapidjson 解析性能对比

图片来源： https://github.com/ibireme/yyjson

图1.2 yyjson数据结构

图片来源自： https://github.com/ibireme/yyjson

sonic-cpp 主要具备以下特性：

高效的解析性能，其性能为 rapidjson 的 2.5 倍
解决 yyjson 和 simdjson 各自的缺点，支持高效的增删改查
基本上支持 json 库常见的所有接口，方便用户迁移
在字节跳动商业化广告、搜索、推荐等诸多中台业务中已经大规模落地，并通过了工程化的考验

sonic-cpp 优化原理

向量化优化（SIMD)

序列化优化

sonic-cpp 则通过五条向量化指令，一次处理 32 个字符，极大地提高了性能。

序列化过程如下：

通过一条向量化 load 指令，一次读取 32 字节到向量寄存器 YMM1；

<!—->

YMM1 和另外 32 字节（全部为）做比较，得到一个掩码(Mask)，存放在向量寄存器 YMM2；
再通过一条 move mask 指令，把 YMM2 中的掩码规约到 GPR 寄存器 R1；
最后通过指令计算下 R1 中尾巴 0 的个数，就可以得到的位置

反序列化优化

sonic-cpp 同样采用 SIMD 指令做浮点数的解析，实现方式如下图所示。

和序列化向量化类似，通过同样的向量指令得到小数点和结束符的位置，再把原始字符串通过向量减法指令，减去, 就得到真实数值。

当我们确定了小数点和结束符的位置，以及向量寄存器中存放的 16 个原始数值，通过乘加指令把他们拼成最终的和指数。

针对不同长度的浮点数做 benchmark 测试，可以看到解析性能提升明显。

按需解析

传统实现

sonic-cpp 实现

按需解析扩展

DOM 设计优化

节点设计

DOM树设计

sonic-cpp 的 DOM 数据结构采用类似于 rapidjson 的实现，可以对包括 array 或 object 在内的所有节点进行增删查改。

按需创建： 只在调用接口时才会生成这个 map，而不是解析的时候创建。
使用 string_view 作为 key： 无需拷贝字符串，减少开销。

内存池

sonic-cpp 提供的内存分配器默认使用内存池进行内存分配。该分配器来自 rapidjson。使用内存池有以下几个好处：

避免频繁地 malloc。DOM 下的 node 只有 16 byte，使用内存池可以高效地为这些小的数据结构分配内存。
避免析构 DOM 上的每一个 node，只需要在析构 DOM 树的时候，统一释放分配器的内存即可。

Object 内建的 map 也使用了内存池分配内存，使得内存可以统一分配和释放。

性能测试

在支持高效的增删改查的基础上，性能和 simdjson、yyjson 可比。

不同 JSON 库性能对比

基准测试是在 https://github.com/miloyip/nativejson-benchmark 的基础上支持 sonic-cpp 和 yyjson，测试得到。

反序列化（Parse）性能基准测试结果

序列化（Stringify）性能基准测试结果:

不同场景性能对比

sonic-cpp 与 rapidjson，simdjson 和 yyjson 之间在不同场景的性能对比（HIB: Higher is better）。

生产环境中性能对比

在实际生产环境中，sonic-cpp 的性能优势也得到了非常好的验证，下面是字节跳动抖音某个服务使用 sonic-cpp 在高峰段 CPU 前后的对比。

展望

欢迎开发者们加入进来贡献 PR，一起打造业界更好的 C/C++ JSON 库！

直播预告

直播互动礼品图片

Redis数据结构

1. SDS

Redis 是用 C 语言写的，但是对于 Redis 的字符串，却不是 C 语言中的字符串（即以空字符’0’结尾的字符数组），它是自己构建了一种名为简单动态字符串（simple dynamic string,SDS）的抽象类型，并将 SDS 作为 Redis 的默认字符串表示

因为 C 语言字符串存在很多问题：

获取字符串长度的需要通过运算
非二进制安全
不可修改

例如，我们执行命令：

那么 Redis 将在底层创建两个 SDS，其中一个是包含 “name” 的 SDS，另一个是包含 “zhangsan” 的 SDS。

1.1 SDS 是什么

Redis 是 C 语言实现的，其中 SDS 是一个结构体，源码如下：

例如，一个包含字符串 “name” 的 sds 结构如下：第一次分配时并不会分配多余空间

SDS 之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为 “hi” 的 SDS：

假如我们要给 SDS 追加一段字符串 “,Amy”，这里首先会申请新内存空间：

如果新字符串小于 1M，则新空间为扩展后字符串长度的两倍 + 1；

如果新字符串大于 1M，则新空间为扩展后字符串长度 + 1M+1。称为内存预分配。

1.2 SDS 的优点

获取字符串长度的时间复杂度为 O (1)
支持动态扩容
支持内存预分配，减少用户线程与内核线程交互次数
二进制安全

一般来说，SDS 除了保存数据库中的字符串值以外，SDS 还可以作为缓冲区（buffer）：包括 AOF 模块中的 AOF 缓冲区以及客户端状态中的输入缓冲区

2. Inset

intset 是 set 集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。

2.1 Inset是什么？

结构如下：

其中的 encoding 包含三种模式，表示存储的整数大小不同：

为了方便查找，Redis 会将 intset 中所有的整数按照升序依次保存在 contents 数组中，结构如图：

现在，数组中每个数字都在 int16_t 的范围内，因此采用的编码方式是 INTSET_ENC_INT16，每部分占用的字节大小为：

encoding：4 字节（可以理解为标识每个素的类型）
length：4 字节
contents：2 字节 * 3 = 6 字节

2.2 inset自动升级

我们向该其中添加一个数字：50000，这个数字超出了 int16_t 的范围，intset 会自动升级编码方式到合适的大小。以当前案例来说流程如下：

升级编码为 INTSET_ENC_INT32 , 每个整数占 4 字节，并按照新的编码方式及素个数扩容数组
倒序依次将数组中的素拷贝到扩容后的正确位置
将待添加的素放入数组末尾
最后，将 inset 的 encoding 属性改为 INTSET_ENC_INT32，将 length 属性改为 4

那么如果我们删除掉刚加入的 int32 类型时，会不会做一个降级操作呢？

不会。主要还是减少开销的权衡

源码如下：

2.3 总结：

Intset 可以看做是特殊的整数数组，具备一些特点：

Redis 会确保 Intset 中的素唯一、有序
具备类型升级机制，可以节省内存空间
底层采用二分查找方式来查询

3. Dict

我们知道 Redis 是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过 Dict 来实现的。是 set 和 hash 的实现方式之一

3.1 Dict是什么？

Dict 由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

当我们向 Dict 添加键值对时，Redis 首先根据 key 计算出 hash 值（h），然后利用 h & sizemask 来计算素应该存储到数组中的哪个索引位置。我们存储 k1=v1，假设 k1 的哈希值 h =1，则 1&3 =1，因此 k1=v1 要存储到数组角标 1 位置。

注意这里还有一个指向下一个哈希表节点的指针，我们知道哈希表最大的问题是存在哈希冲突，如何解决哈希冲突，有开放地址法和链地址法。这里采用的便是链地址法，通过 next 这个指针可以将多个哈希值相同的键值对连接在一起，用来解决哈希冲突。

Dict 由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

3.2 深入理解

哈希算法：Redis 计算哈希值和索引值方法如下：

解决哈希冲突：这个问题上面我们介绍了，方法是链地址法。通过字典里面的 *next 指针指向下一个具有相同索引值的哈希表节点。
扩容和收缩：当哈希表保存的键值对太多或者太少时，就要通过 rerehash (重新散列）来对哈希表进行相应的扩展或者收缩。具体步骤：

计算新 hash 表的 realeSize，值取决于当前要做的是扩容还是收缩：
- 如果是扩容，则新 size 为第一个大于等于 dict.ht [0].used + 1 的 2^n
- 如果是收缩，则新 size 为第一个小于等于 dict.ht [0].used 的 2^n （不得小于 4）
按照新的 realeSize 申请内存空间，创建 dictht ，并赋值给 dict.ht [1]
设置 dict.rehashidx = 0，标示开始 rehash
将 dict.ht [0] 中的每一个 dictEntry 都 rehash 到 dict.ht [1]
将 dict.ht [1] 赋值给 dict.ht [0]，给 dict.ht [1] 初始化为空哈希表，释放原来的 dict.ht [0] 的内存
将 rehashidx 赋值为 – 1，代表 rehash 结束
在 rehash 过程中，新增操作，则直接写入 ht [1]，查询、修改和删除则会在 dict.ht [0] 和 dict.ht [1] 依次查找并执行。这样可以确保 ht [0] 的数据只减不增，随着 rehash 最终为空

触发扩容的条件：
1. 服务器目前没有执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于 1。
2. 服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于 5。

ps：负载因子 = 哈希表已保存节点数量 / 哈希表大小。

渐进式rehash

什么叫渐进式 rehash？也就是说扩容和收缩操作不是一次性、集中式完成的，而是分多次、渐进式完成的。如果保存在 Redis 中的键值对只有几个几十个，那么 rehash 操作可以瞬间完成，但是如果键值对有几百万，几千万甚至几亿，那么要一次性的进行 rehash，势必会造成 Redis 一段时间内不能进行别的操作。所以 Redis 采用渐进式 rehash, 这样在进行渐进式 rehash 期间，字典的删除查找更新等操作可能会在两个哈希表上进行，第一个哈希表没有找到，就会去第二个哈希表上进行查找。但是进行增加操作，一定是在新的哈希表上进行的。

3.3 总结：

Dict 的结构：

类似 java 的 HashTable，底层是数组加链表来解决哈希冲突
Dict 包含两个哈希表，ht [0] 平常用，ht [1] 用来 rehash

Dict 的伸缩：

当 LoadFactor 大于 5 或者 LoadFactor 大于 1 并且没有子进程任务时，Dict 扩容
当 LoadFactor 小于 0.1 时，Dict 收缩
扩容大小为第一个大于等于 used + 1 的 2^n^
收缩大小为第一个大于等于 used 的 2^n^
Dict 采用渐进式 rehash，每次访问 Dict 时执行一次 rehash
rehash 时 ht [0] 只减不增，新增操作只在 ht [1] 执行，其它操作在两个哈希表

4. ZipList

ZipList 是一种特殊的 “双端链表” ，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入 / 弹出操作，并且该操作的时间复杂度为 O (1)。

4.1 ZipList 是什么？

zlbytes : 字段的类型是 uint32_t , 这个字段中存储的是整个 ziplist 所占用的内存的字节数

zltail : 字段的类型是 uint32_t , 它指的是 ziplist 中最后一个 entry 的偏移量。用于快速定位最后一个 entry, 以快速完成 pop 等操作

zllen : 字段的类型是 uint16_t , 它指的是整个 ziplit 中 entry 的数量。这个值只占 2bytes（16 位）: 如果 ziplist 中 entry 的数目小于 65535 (2 的 16 次方), 那么该字段中存储的就是实际 entry 的值。若等于或超过 65535, 那么该字段的值固定为 65535, 但实际数量需要一个个 entry 的去遍历所有 entry 才能得到。

zlend 是一个终止字节，其值为全 F, 即 0xff. ziplist 保证任何情况下，一个 entry 的首字节都不会是 255

4.2 ZipListEntry

ZipList 中的 Entry 并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用 16 个字节，浪费内存。而是采用了下面的结构：

previous_entry_length：前一节点的长度，占 1 个或 5 个字节。
- 如果前一节点的长度小于 254 字节，则采用 1 个字节来保存这个长度值
- 如果前一节点的长度大于 254 字节，则采用 5 个字节来保存这个长度值，第一个字节为 0xfe，后四个字节才是真实长度数据
encoding：编码属性，记录 content 的数据类型（字符串还是整数）以及长度，占用 1 个、2 个或 5 个字节
contents：负责保存节点的数据，可以是字符串或整数

第一种情况：一般结构 <prevlen> <encoding> <entry-data>

prevlen：前一个 entry 的大小，编码方式见下文；

encoding：不同的情况下值不同，用于表示当前 entry 的类型和长度；

entry-data：真是用于存储 entry 表示的数据；

第二种情况：在 entry 中存储的是 int 类型时，encoding 和 entry-data 会合并在 encoding 中表示，此时没有 entry-data 字段；

redis 中，在存储数据时，会先尝试将 string 转换成 int 存储，节省空间；此时 entry 结构：<prevlen> <encoding>

prevlen编码

当前一个素长度小于 254（255 用于 zlend）的时候，prevlen 长度为 1 个字节，值即为前一个 entry 的长度，如果长度大于等于 254 的时候，prevlen 用 5 个字节表示，第一字节设置为 254，后面 4 个字节存储一个小端的无符号整型，表示前一个 entry 的长度；

encoding 编码

encoding 的长度和值根据保存的是 int 还是 string，还有数据的长度而定；

前两位用来表示类型，当为 “11” 时，表示 entry 存储的是 int 类型，其它表示存储的是 string；

存储string时：

|00xxxxxx| ：此时 encoding 长度为 1 个字节，该字节的后六位表示 entry 中存储的 string 长度，因为是 6 位，所以 entry 中存储的 string 长度不能超过 63；

|01xxxxxx|xxxxxxxx| 此时 encoding 长度为两个字节；此时 encoding 的后 14 位用来存储 string 长度，长度不能超过 16383；

||xxxxxxxx|xxxxxxxx|xxxxxxxx|xxxxxxxx| 此时 encoding 长度为 5 个字节，后面的 4 个字节用来表示 encoding 中存储的字符串长度，长度不能超过 2^32 – 1;

存储int时：

|| encoding 为 3 个字节，后 2 个字节表示一个 int16；

|| encoding 为 5 个字节，后 4 个字节表示一个 int32;

|| encoding 为 9 个字节，后 8 字节表示一个 int64;

|| encoding 为 4 个字节，后 3 个字节表示一个有符号整型；

|| encoding 为 2 字节，后 1 个字节表示一个有符号整型；

|1111xxxx| encoding 长度就只有 1 个字节，xxxx 表示一个 0 – 12 的整数值；

|| zlend

4.3 ZipList 的连锁更新问题

ZipList 的每个 Entry 都包含 previous_entry_length 来记录上一个节点的大小，长度是 1 个或 5 个字节：
如果前一节点的长度小于 254 字节，则采用 1 个字节来保存这个长度值
如果前一节点的长度大于等于 254 字节，则采用 5 个字节来保存这个长度值，第一个字节为 0xfe，后四个字节才是真实长度数据
现在，假设我们有 N 个连续的、长度为 250~253 字节之间的 entry，因此 entry 的 previous_entry_length 属性用 1 个字节即可表示，如图所示：

ZipList 这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。虽然发生的条件非常苛刻，但不代表不会发生

4.4 总结：

ZipList 特性：

压缩列表的可以看做一种连续内存空间的” 双向链表”
列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低
如果列表数据过多，导致链表过长，可能影响查询性能
增或删较大数据时有可能发生连续更新问题

5. QuickList

5.1 QuickList 是什么？

ZipList 虽然节省内存，但申请内存必须是连续空间，但是我们要存储大量数据，内存中碎片比较多，很难找到一块大的连续空间。于是，大数据量下，内存申请效率低成了 ziplist 的最大问题，而 quickList 就是为了帮助 zipList 摆脱困境的。

为了缓解内存申请效率低的问题，QuickList 提供了可限制 ZipList 的最大节点数和每个 entry 的大小的方式。
那么对于大数据量，我们可以采用分片的思想，存储在多个 ZipList 中，而 QuickList 可以将这些 ZipList 作为节点连接起来。

为了避免 QuickList 中的每个 ZipList 中 entry 过多，Redis 提供了一个配置项：list-max-ziplist-size 来限制。

如果值为正，则代表 ZipList 的允许的 entry 个数的最大值
如果值为负，则代表 ZipList 的最大内存大小，分 5 种情况：
- -1：每个 ZipList 的内存占用不能超过 4kb
- -2：每个 ZipList 的内存占用不能超过 8kb
- -3：每个 ZipList 的内存占用不能超过 16kb
- -4：每个 ZipList 的内存占用不能超过 32kb
- -5：每个 ZipList 的内存占用不能超过 64kb

其默认值为 -2：

以下是 QuickList 的和 QuickListNode 的结构源码：

5.2 QuickList 内存布局

5.3 总结：

QuickList 的特点：

是一个节点为 ZipList 的双端链表
节点采用 ZipList ，解决了传统链表的内存占用问题
控制了 ZipList 大小，解决连续内存空间申请效率问题
中间节点可以压缩，进一步节省了内存

6. SkipList

跳跃表结构在 Redis 中的运用场景只有一个，那就是作为有序列表 (Zset) 的使用。跳跃表的性能可以保证在查找，删除，添加等操作的时候在对数期望时间内完成，这个性能是可以和平衡树来相比较的，而且在实现方面比平衡树要优雅，这就是跳跃表的长处。跳跃表的缺点就是需要的存储空间比较大，属于利用空间来换取时间的数据结构

6.1 SkipList 是什么？

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：

素按照升序排列存储
节点可能包含多个指针，指针跨度不同。

6.2 SkipListNode 结构

ele 字段，持有数据，是 sds 类型
score 字段，其标示着结点的得分，结点之间凭借得分来判断先后顺序，跳跃表中的结点按结点的得分升序排列.
backward 指针，这是原版跳跃表中所没有的。该指针指向结点的前一个紧邻结点.
level 字段，用以记录所有结点 (除过头节点外)；每个结点中最多持有 32 个 zskiplistLevel 结构。实际数量在结点创建时，按幂次定律随机生成 (不超过 32). 每个 zskiplistLevel 中有两个字段
forward 字段指向比自己得分高的某个结点 (不一定是紧邻的), 并且，若当前 zskiplistLevel 实例在 level [] 中的索引为 X, 则其 forward 字段指向的结点，其 level [] 字段的容量至少是 X+1. 这也是上图中，为什么 forward 指针总是画的水平的原因.
span 字段代表 forward 字段指向的结点，距离当前结点的距离。紧邻的两个结点之间的距离定义为 1.

6.3 skiplist 与平衡树、哈希表的比较

skiplist 和各种平衡树（如 AVL、红黑树等）的素是有序排列的，而哈希表不是有序的。因此，在哈希表上只能做单个 key 的查找，不适宜做范围查找。所谓范围查找，指的是查找那些大小在指定的两个值之间的所有节点。

在做范围查找的时候，平衡树比 skiplist 操作要复杂。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在 skiplist 上进行范围查找就非常简单，只需要在找到小值之后，对第 1 层链表进行若干步的遍历就可以实现。

平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而 skiplist 的插入和删除只需要修改相邻节点的指针，操作简单又快速。

从内存占用上来说，skiplist 比平衡树更灵活一些。一般来说，平衡树每个节点包含 2 个指针（分别指向左右子树），而 skiplist 每个节点包含的指针数目平均为 1/(1-p)，具体取决于参数 p 的大小。如果像 Redis 里的实现一样，取 p=1/4，那么平均每个节点包含 1.33 个指针，比平衡树更有优势。

查找单个 key，skiplist 和平衡树的时间复杂度都为 O (log n)，大体相当；而哈希表在保持较低的哈希值冲突概率的前提下，查找时间复杂度接近 O (1)，性能更高一些。所以我们平常使用的各 Map 或 dictionary 结构，大都是基于哈希表实现的。

从算法实现难度上来比较，skiplist 比平衡树要简单得多。

6.4 总结：

SkipList 的特点：

跳跃表是一个双向链表，每个节点都包含 score 和 ele 值
节点按照 score 值排序，score 值一样则按照 ele 字典排序
每个节点都可以包含多层指针，层数是 1 到 32 之间的随机数
不同层指针到下一个节点的跨度不同，层级越高，跨度越大
增删改查效率与红黑树基本一致，实现却更简单

7. RedisObject

7.1 RedisObject 是什么？

Redis 中的任意数据类型的键和值都会被封装为一个 RedisObject，也叫做 Redis 对象

从 Redis 的使用者的角度来看，⼀个 Redis 节点包含多个 database（非 cluster 模式下默认是 16 个，cluster 模式下只能是 1 个），而一个 database 维护了从 key space 到 object space 的映射关系。这个映射关系的 key 是 string 类型，⽽ value 可以是多种数据类型，比如：string, list, hash、set、sorted set 等。我们可以看到，key 的类型固定是 string ，而 value 可能的类型是多个。

⽽从 Redis 内部实现的⾓度来看，database 内的这个映射关系是用⼀个 dict 来维护的。dict 的 key 固定用⼀种数据结构来表达就够了，这就是动态字符串 sds。而 value 则比较复杂，为了在同⼀个 dict 内能够存储不同类型的 value，这就需要⼀个通⽤的数据结构，这个通用的数据结构就是 robj，全名是 redisObject。

type : 占 4bit , 五个取值类型，表示对象类型 String , Hash , List , set , zset。
encoding : 占 4bit ，十一种编码方式
lru : 占用 3 字节，记录最后一次被访问的时间，主要用于 lru 算法，最近最少使用
refcount ：占用 4 字节，引用计数器，无人用就回收
*ptr：占用 8 字节，只想存放实际数据的空间

redis 的头部占用 16 字节

7.2 encoding 取值：

Redis 中会根据存储的数据类型不同，选择不同的编码方式，共包含 11 种不同类型：

编号编码方式说明 0 OBJ_ENCODING_RAW raw 编码动态字符串 1 OBJ_ENCODING_INT long 类型的整数的字符串 2 OBJ_ENCODING_HT hash 表（字典 dict） 3 OBJ_ENCODING_ZIPMAP 已废弃 4 OBJ_ENCODING_LINKEDLIST 双端链表 5 OBJ_ENCODING_ZIPLIST 压缩列表 6 OBJ_ENCODING_INTSET 整数集合 7 OBJ_ENCODING_SKIPLIST 跳表 8 OBJ_ENCODING_EMBSTR embstr 的动态字符串 9 OBJ_ENCODING_QUICKLIST 快速列表 10 OBJ_ENCODING_STREAM Stream 流

7.3 五种数据结构

Redis 中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：

数据类型编码方式 OBJ_STRING int、embstr、raw OBJ_LIST LinkedList 和 ZipList (3.2 以前)、QuickList（3.2 以后） OBJ_SET intset、HT OBJ_ZSET ZipList、HT、SkipList OBJ_HASH ZipList、HT

本文由教研团队发布。

如果本文对您有帮助，欢迎和；如果您有任何建议也可或，您的支持是我坚持创作的动力。

转载请注明出处！

[TOC]

最近有小伙伴告诉松哥说面试中被问到这个问题了，不知道该怎么回答，这能忍？捋一篇文章和小伙伴们分享下吧。

既然捋成文章，就连同 Spring 事务一起梳理下吧。

1. 什么是事务

数据库事务是指作为单个逻辑工作单执行的一系列操作，这些操作要么一起成功，要么一起失败，是一个不可分割的工作单。

在我们日常工作中，涉及到事务的场景非常多，一个 service 中往往需要调用不同的 dao 层方法，这些方法要么同时成功要么同时失败，我们需要在 service 层确保这一点。

说到事务最典型的案例就是转账了：

> 张三要给李四转账 500 块钱，这里涉及到两个操作，从张三的账户上减去 500 块钱，给李四的账户添加 500 块钱，这两个操作要么同时成功要么同时失败，如何确保他们同时成功或者同时失败呢？答案就是事务。

事务有四大特性（ACID）：

原子性（Atomicity）： 一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
一致性（Consistency）： 在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
隔离性（Isolation）： 数据库允许多个并发事务同时对其数据进行读写和修改，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read Uncommitted）、提交读（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。
持久性（Durability）: 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

这就是事务的四大特性。

2. Spring 中的事务

2.1 两种用法

Spring 作为 Java 开发中的基础设施，对于事务也提供了很好的支持，总体上来说，Spring 支持两种类型的事务，声明式事务和编程式事务。

编程式事务类似于 Jdbc 事务的写法，需要将事务的代码嵌入到业务逻辑中，这样代码的耦合度较高，而声明式事务通过 AOP 的思想能够有效的将事务和业务逻辑代码解耦，因此在实际开发中，声明式事务得到了广泛的应用，而编程式事务则较少使用，考虑到文章内容的完整，本文对两种事务方式都会介绍。

2.2 三大基础设施

Spring 中对事务的支持提供了三大基础设施，我们先来了解下。

PlatformTransactionManager
TransactionDefinition
TransactionStatus

这三个核心类是 Spring 处理事务的核心类。

2.2.1 PlatformTransactionManager

PlatformTransactionManager 是事务处理的核心，它有诸多的实现类，如下：

PlatformTransactionManager 的定义如下：

可以看到中定义了基本的事务操作方法，这些事务操作方法都是平台无关的，具体的实现都是由不同的子类来实现的。

这就像 JDBC 一样，SUN 公司制定标准，其他数据库厂商提供具体的实现。这么做的好处就是我们 Java 程序员只需要掌握好这套标准即可，不用去管接口的具体实现。以为例，它有众多实现，如果你使用的是 JDBC 那么可以将作为事务管理器；如果你使用的是 Hibernate，那么可以将作为事务管理器；如果你使用的是 JPA，那么可以将作为事务管理器。、以及都是的具体实现，但是我们并不需要掌握这些具体实现类的用法，我们只需要掌握好的用法即可。

中主要有如下三个方法：

1.getTransaction()

getTransaction() 是根据传入的 TransactionDefinition 获取一个事务对象，TransactionDefinition 中定义了一些事务的基本规则，例如传播性、隔离级别等。

2.commit()

commit() 方法用来提交事务。

3.rollback()

rollback() 方法用来回滚事务。

2.2.2 TransactionDefinition

用来描述事务的具体规则，也称作事务的属性。事务有哪些属性呢？看下图：

可以看到，主要是五种属性：

隔离性
传播性
回滚规则
超时时间
是否只读

这五种属性接下来松哥会和大家详细介绍。

类中的方法如下：

可以看到一共有五个方法：

getIsolationLevel()，获取事务的隔离级别
getName()，获取事务的名称
getPropagationBehavior()，获取事务的传播性
getTimeout()，获取事务的超时时间
isReadOnly()，获取事务是否是只读事务

TransactionDefinition 也有诸多的实现类，如下：

如果开发者使用了编程式事务的话，直接使用即可。

2.2.3 TransactionStatus

TransactionStatus 可以直接理解为事务本身，该接口源码如下：

isNewTransaction() 方法获取当前事务是否是一个新事务。
hasSavepoint() 方法判断是否存在 savePoint()。
setRollbackOnly() 方法设置事务必须回滚。
isRollbackOnly() 方法获取事务只能回滚。
flush() 方法将底层会话中的修改刷新到数据库，一般用于 Hibernate/JPA 的会话，对如 JDBC 类型的事务无任何影响。
isCompleted() 方法用来获取是一个事务是否结束。

这就是 Spring 中支持事务的三大基础设施。

3. 编程式事务

我们先来看看编程式事务怎么玩。

通过 PlatformTransactionManager 或者 TransactionTemplate 可以实现编程式事务。如果是在 Spring Boot 项目中，这两个对象 Spring Boot 会自动提供，我们直接使用即可。但是如果是在传统的 SSM 项目中，则需要我们通过配置来提供这两个对象，松哥给一个简单的配置参考，如下（简单起见，数据库操作我们使用 JdbcTemplate）：

有了这两个对象，接下来的代码就简单了：

这段代码很简单，没啥好解释的，在中进行业务操作，没问题就 commit，有问题就 rollback。如果我们需要配置事务的隔离性、传播性等，可以在 DefaultTransactionDefinition 对象中进行配置。

上面的代码是通过 PlatformTransactionManager 实现的编程式事务，我们也可以通过 TransactionTemplate 来实现编程式事务，如下：

直接注入 TransactionTemplate，然后在 execute 方法中添加回调写核心的业务即可，当抛出异常时，将当前事务标注为只能回滚即可。注意，execute 方法中，如果不需要获取事务执行的结果，则直接使用 TransactionCallbackWithoutResult 类即可，如果要获取事务执行结果，则使用 TransactionCallback 即可。

这就是两种编程式事务的玩法。

编程式事务由于代码入侵太严重了，因为在实际开发中使用的很少，我们在项目中更多的是使用声明式事务。

4. 声明式事务

声明式事务如果使用配置，可以做到无侵入；如果使用配置，也只有一个注解侵入而已，相对来说非常容易。

以下配置针对传统 SSM 项目（因为在 Spring Boot 项目中，事务相关的组件已经配置好了）：

4.1 XML 配置

XML 配置声明式事务大致上可以分为三个步骤，如下：

配置事务管理器

配置事务通知

配置 AOP

第二步和第三步中定义出来的方法交集，就是我们要添加事务的方法。

配置完成后，如下一些方法就自动具备事务了：

4.2 Java 配置

我们也可以使用 Java 配置来实现声明式事务：

这里要配置的东西其实和 XML 中配置的都差不多，最最关键的就两个：

事务管理器 PlatformTransactionManager。
@EnableTransactionManagement 注解开启事务支持。

配置完成后，接下来，哪个方法需要事务就在哪个方法上添加注解即可，向下面这样：

当然这个稍微有点代码入侵，不过问题不大，日常开发中这种方式使用较多。当注解加在类上面的时候，表示该类的所有方法都有事务，该注解加在方法上面的时候，表示该方法有事务。

4.3 混合配置

也可以 Java 代码和 XML 混合配置来实现声明式事务，就是一部分配置用 XML 来实现，一部分配置用 Java 代码来实现：

假设 XML 配置如下：

那么 Java 代码中的配置如下：

Java 配置中通过 @ImportResource 注解导入了 XML 配置，XML 配置中的内容就是开启注解的支持，所以 Java 配置中省略了 @EnableTransactionManagement 注解。

这就是声明式事务的几种配置方式。好玩吧！

5. 事务属性

在前面的配置中，我们只是简单说了事务的用法，并没有和大家详细聊一聊事务的一些属性细节，那么接下来我们就来仔细捋一捋事务中的五大属性。

5.1 隔离性

首先就是事务的隔离性，也就是事务的隔离级别。

MySQL 中有四种不同的隔离级别，这四种不同的隔离级别在 Spring 中都得到了很好的支持。Spring 中默认的事务隔离级别是 default，即数据库本身的隔离级别是啥就是啥，default 就能满足我们日常开发中的大部分场景。

不过如果项目有需要，我们也可以调整事务的隔离级别。

调整方式如下：

5.1.1 编程式事务隔离级别

如果是编程式事务，通过如下方式修改事务的隔离级别：

TransactionTemplate

TransactionDefinition 中定义了各种隔离级别。

PlatformTransactionManager

这里是在 DefaultTransactionDefinition 对象中设置事务的隔离级别。

5.1.2 声明式事务隔离级别

如果是声明式事务通过如下方式修改隔离级别：

XML：

Java：

5.2 传播性

先来说说何谓事务的传播性：

> 事务传播行为是为了解决业务层方法之间互相调用的事务问题，当一个事务方法被另一个事务方法调用时，事务该以何种状态存在？例如新方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行，等等，这些规则就涉及到事务的传播性。

关于事务的传播性，Spring 主要定义了如下几种：

具体含义如下：

传播性描述 REQUIRED 如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务 SUPPORTS 如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行 MANDATORY 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常 REQUIRES_NEW 创建一个新的事务，如果当前存在事务，则把当前事务挂起 NOT_SUPPORTED 以非事务方式运行，如果当前存在事务，则把当前事务挂起 NEVER 以非事务方式运行，如果当前存在事务，则抛出异常 NESTED 如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于 TransactionDefinition.PROPAGATION_REQUIRED

一共是七种传播性，具体配置也简单：

TransactionTemplate中的配置

PlatformTransactionManager中的配置

声明式事务的配置（XML）

声明式事务的配置（Java）

用就是这么来用，至于七种传播的具体含义，松哥来和大家一个一个说。

5.2.1 REQUIRED

REQUIRED 表示如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。

例如我有如下一段代码：

我在 handle2 方法中调用 handle1。

那么：

如果 handle2 方法本身是有事务的，则 handle1 方法就会加入到 handle2 方法所在的事务中，这样两个方法将处于同一个事务中，一起成功或者一起失败（不管是 handle2 还是 handle1 谁抛异常，都会导致整体回滚）。
如果 handle2 方法本身是没有事务的，则 handle1 方法就会自己开启一个新的事务，自己玩。

举一个简单的例子：handle2 方法有事务，handle1 方法也有事务（小伙伴们根据前面的讲解自行配置事务），项目打印出来的事务日志如下：

从日志中可以看到，前前后后一共就开启了一个事务，日志中有这么一句：

这个就说明 handle1 方法没有自己开启事务，而是加入到 handle2 方法的事务中了。

5.2.2 REQUIRES_NEW

REQUIRES_NEW 表示创建一个新的事务，如果当前存在事务，则把当前事务挂起。换言之，不管外部方法是否有事务，REQUIRES_NEW 都会开启自己的事务。

这块松哥要多说两句，有的小伙伴可能觉得 REQUIRES_NEW 和 REQUIRED 太像了，似乎没啥区别。其实你要是单纯看最终回滚效果，可能确实看不到啥区别。但是，大家注意松哥上面的加粗，在 REQUIRES_NEW 中可能会同时存在两个事务，外部方法的事务被挂起，内部方法的事务独自运行，而在 REQUIRED 中则不会出现这种情况，如果内外部方法传播性都是 REQUIRED，那么最终也只是一个事务。

还是上面那个例子，假设 handle1 和 handle2 方法都有事务，handle2 方法的事务传播性是 REQUIRED，而 handle1 方法的事务传播性是 REQUIRES_NEW，那么最终打印出来的事务日志如下：

分析这段日志我们可以看到：

首先为 handle2 方法开启了一个事务。
执行完 handle2 方法的 SQL 之后，事务被刮起（Suspending）。
为 handle1 方法开启了一个新的事务。
执行 handle1 方法的 SQL。
提交 handle1 方法的事务。
恢复被挂起的事务（Resuming）。
提交 handle2 方法的事务。

从这段日志中大家可以非常明确的看到 REQUIRES_NEW 和 REQUIRED 的区别。

松哥再来简单总结下(假设 handle1 方法的事务传播性是 REQUIRES_NEW)：

如果 handle2 方法没有事务，handle1 方法自己开启一个事务自己玩。
如果 handle2 方法有事务，handle1 方法还是会开启一个事务。此时，如果 handle2 发生了异常进行回滚，并不会导致 handle1 方法回滚，因为 handle1 方法是独立的事务；如果 handle1 方法发生了异常导致回滚，并且 handle1 方法的异常没有被捕获处理传到了 handle2 方法中，那么也会导致 handle2 方法回滚。

> 这个地方小伙伴们要稍微注意一下，我们测试的时候，由于是两个更新 SQL，如果更新的查询字段不是索引字段，那么 InnoDB 将使用表锁，这样就会发生死锁（handle2 方法执行时开启表锁，导致 handle1 方法陷入等待中，而必须 handle1 方法执行完，handle2 才能释放锁）。所以，在上面的测试中，我们要将 username 字段设置为索引字段，这样默认就使用行锁了。

5.2.3 NESTED

NESTED 表示如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于 TransactionDefinition.PROPAGATION_REQUIRED。

假设 handle2 方法有事务，handle1 方法也有事务且传播性为 NESTED，那么最终执行的事务日志如下：

关键一句在。

此时，NESTED 修饰的内部方法（handle1）属于外部事务的子事务，外部主事务回滚的话，子事务也会回滚，而内部子事务可以单独回滚而不影响外部主事务和其他子事务（需要处理掉内部子事务的异常）。

5.2.4 MANDATORY

MANDATORY 表示如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

这个好理解，我举两个例子：

假设 handle2 方法有事务，handle1 方法也有事务且传播性为 MANDATORY，那么最终执行的事务日志如下：

从这段日志可以看出：

首先给 handle2 方法开启事务。
执行 handle2 方法的 SQL。
handle1 方法加入到已经存在的事务中。
执行 handle1 方法的 SQL。
提交事务。

假设 handle2 方法无事务，handle1 方法有事务且传播性为 MANDATORY，那么最终执行时会抛出如下异常：

由于没有已经存在的事务，所以出错了。

5.2.5 SUPPORTS

SUPPORTS 表示如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

这个也简单，举两个例子大家就明白了。

假设 handle2 方法有事务，handle1 方法也有事务且传播性为 SUPPORTS，那么最终事务执行日志如下：

这段日志很简单，没啥好说的，认准表示加入到已经存在的事务中即可。

假设 handle2 方法无事务，handle1 方法有事务且传播性为 SUPPORTS，这个最终就不会开启事务了，也没有相关日志。

5.2.6 NOT_SUPPORTED

NOT_SUPPORTED 表示以非事务方式运行，如果当前存在事务，则把当前事务挂起。

假设 handle2 方法有事务，handle1 方法也有事务且传播性为 NOT_SUPPORTED，那么最终事务执行日志如下：

这段日志大家认准这两句就行了：表示挂起当前事务；表示恢复挂起的事务。

5.2.7 NEVER

NEVER 表示以非事务方式运行，如果当前存在事务，则抛出异常。

假设 handle2 方法有事务，handle1 方法也有事务且传播性为 NEVER，那么最终会抛出如下异常：

5.3 回滚规则

默认情况下，事务只有遇到运行期异常（RuntimeException 的子类）以及 Error 时才会回滚，在遇到检查型（Checked Exception）异常时不会回滚。

像 1/0，空指针这些是 RuntimeException，而 IOException 则算是 Checked Exception，换言之，默认情况下，如果发生 IOException 并不会导致事务回滚。

如果我们希望发生 IOException 时也能触发事务回滚，那么可以按照如下方式配置：

Java 配置：

XML 配置：

另外，我们也可以指定在发生某些异常时不回滚，例如当系统抛出 ArithmeticException 异常并不要触发事务回滚，配置方式如下：

Java 配置：

XML 配置：

5.4 是否只读

只读事务一般设置在查询方法上，但不是所有的查询方法都需要只读事务，要看具体情况。

一般来说，如果这个业务方法只有一个查询 SQL，那么就没必要添加事务，强行添加最终效果适得其反。

但是如果一个业务方法中有多个查询 SQL，情况就不一样了：多个查询 SQL，默认情况下，每个查询 SQL 都会开启一个独立的事务，这样，如果有并发操作修改了数据，那么多个查询 SQL 就会查到不一样的数据。此时，如果我们开启事务，并设置为只读事务，那么多个查询 SQL 将被置于同一个事务中，多条相同的 SQL 在该事务中执行将会获取到相同的查询结果。

设置事务只读的方式如下：

Java 配置：

XML 配置：

5.5 超时时间

超时时间是说一个事务允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。

事务超时时间配置方式如下(单位为秒)：

Java 配置：

XML 配置：

在中以 int 的值来表示超时时间，其单位是秒，默认值为-1。

6. 事务失效

那么什么情况下事务会失效呢？

6.1 方法自调用

这个主要是针对声明式事务的，经过前面的介绍，小伙伴们其实也能够看出来，声明式事务底层其实就是 AOP，所以在声明式事务中，我们我们拿到的服务类并不是服务类本身，而是一个代理对象，在这个代理对象中的代理方法中，自动添加了事务的逻辑，所以如果我们直接方法自调用，没有经过这个代理对象，事务就会失效。

我写一段伪代码小伙伴们一起来看下：

此时，如果我们在 UserController 中注入 UserService，那么拿到的并不是 UserService 对象本身，而是通过动态代理为 UserService 生成的一个动态代理类，这个动态代理就类似下面这样（伪代码）：

所以你最终调用的并不是 UserService 本身的方法，而是动态代理对象中的方法。

因此，如果存在这样的代码：

在 useSayHello 中调用 sayHello 方法，sayHello 方法上虽然有事务注解，但是这里的事务不生效（因为调用的不是的动态代理对象中的 sayHello 方法，而是当前对象 this 的 sayHello 方法）。

6.2 异常被捕获

搞明白了 6.1，再来看 6.2 小节就很容易懂了。

如果我们在 sayHello 方法中将异常捕获了，那么动态代理类中的方法，就感知不知道目标方法发生异常了，自然也就不会自动处理事务回滚了。还是以前面的 UserServiceProxy 为例：

如果调用的时候，sayHello 方法自动将异常捕获了，那么很明显，这里就不会进行异常回滚了。

6.3 方法非 public

这个算是 Spring 官方的一个强制要求了，声明式事务方法只能是 public，对于非 public 的方法如果想用声明式事务，那得上 AspectJ。

6.4 非运行时异常

这个前面 5.3 小节介绍过了，默认情况下，只会捕获 RuntimeException，如果想扩大捕获范围，可以自行配置。

6.5 不是 Spring Bean

基于 6.1 小节的理解，来看这个应该也很好懂。声明式事务主要是通过动态代理来处理事务的，如果你拿到手的 UserService 对象就是原原本本的 UserService（如果自己 new 了一个 UserService 就是这种情况），那么事务代码在哪里？没有事务处理的代码，事务自然不会生效。

> 声明式事务的核心，就是动态代理生成的那个对象，没有用到那个对象，事务就没戏。

6.6 数据库不支持事务

这个没啥好说，数据库不支持，Spring 咋配都没用。

7. 小结

好啦，这就是松哥和大家分享的 Spring 事务的玩法，不知道小伙伴们搞明白没有？

如何 build NebulaGraph？如何为 NebulaGraph 内核做贡献？即便是新手也能快速上手，从本文作为切入点就够了。

NebulaGraph 的架构简介

为了方便对 NebulaGraph 尚未了解的读者也能快速直接从贡献代码为起点了解它，我把开发、贡献内核代码入手所需要的基本架构知识在这里以最小信息量的形式总结一下。作为前导知识，请资深的 NebulaGraph 玩家直接跳过这一章节。

服务、进程

NebulaGraph 的架构和 Google Spanner、TiDB 很相似，核心部分只有三种服务进程：Graph 服务、Meta 服务和 Storage 服务。它们之间彼此通过 TCP 之上的 Thrift RPC 协议进行通信。

计算层与存储层

NebulaGraph 是存储与计算分离的架构，Meta 服务和 Storage 服务共同组成了存储层，Graph 服务是内核提供的计算层。

这样的设计使得 NebulaGraph 的集群部署可以灵活按需分配计算、存储的资源。比如，在同一个集群中创建不同配置的两组 Graph 服务实例用来面向不同类型的业务。

同时，计算层解耦于存储层使得在 NebulaGraph 之上的构建不同的特定计算层成为可能。比如，NebulaGraph Algorithm、NebulaGraph Analytics 就是在 NebulaGraph 之上构建了异构的另一个计算层。任何人都可以按需定制专属计算层，从而满足统一图基础存储之上的复合、多样的计算需求。

Graph Service：nebula-graphd

Graph 服务是对外接收图库登录、图查询请求、集群管理操作、Schema 定义所直接连接的服务，它的进程名字叫 graphd，表示 nebula graph daemon。

Graph 服务的每一个进程是无状态的，这使得横向扩缩 Graph 服务的实例非常灵活、简单。

Graph 服务也叫 Query Engine，其内部和传统的数据库系统的设计非常相似，分为：解析、校验、计划、执行几部分。

Meta Service：nebula-metad

Meta 服务顾名思义负责数据管理，进程名字叫 metad。这些数据包括：

所有的图空间、Schema 定义
用户鉴权、授权信息
集群服务的发现与服务的分布
图空间中的数据分布

Meta 服务的进程可以单实例部署。在非单机部署的场景下，为了数据、服务的高 SLA ，以奇数个实例进行部署。通常来说 3 个 nebula-metad 就足够了，3 个 nebula-metad 通过 Raft 共识协议构成一个集群提供服务。

Storage Service：nebula-storaged

Storage 服务存储所有的图数据，进程名字叫 storaged。storaged 分布式地存储图数据，为 Graph 内部的图查询执行期提供底层的图语义存储接口，方便 Storage 客户端通过 Thrift RPC 协议面向涉及的 storaged 示例进行图语义的读写。

当 NebulaGraph 中图空间的副本数大于 1 的时候，每一个分区都会在不同 storaged 示例上有副本，副本之间则通过 Raft 协议协调同步与读写。

进程间通信、服务发现机制

在 NebulaGraph 中 graphd、metad、storaged 之间通过 Thrift 协议进行远程调用（RPC），下边给一些例子：

graphd 会通过 metaclient 调用 metad：将自己报告为一个正在运行的服务，以便被发现；再为用户（使用 graphclient ）登录进行 RPC 调用；当它处理 nGQL 查询时，获取图存储分布情况；
graphd 会通过 storageclient 调用 storaged：当 graphd 处理 nGQL 时，先从 metad 获得所需的信息，再进行图数据的读/写；
storaged 会通过 metaclient调用 metad：将 storaged 报告为一个正在运行的服务，以便被发现。

当然，有状态的存储引擎内部也有集群同步的流量与通信。比如，storaged 与其他 storaged 有 Raft 连接；metad 与其他 metad 实例有 Raft 连接。

开发环境搭建

接下来，我们开始 NebulaGraph 的构建、开发环境的部分。

NebulaGraph 只支持在 GNU/Linux 分支中构建。目前来说，最方便的方式是在社区预先提供好了依赖的容器镜像的基础上在容器内部构建、调试 NebulaGraph 代码的更改和 Debug。

创建一个容器化的 NebulaGraph 集群

为了更方便地调试代码，我习惯提前创建一个 NebulaGraph Docker 环境。推荐使用官方的 Docker-Compose 方式部署，也可以使用我在官方 Docker-Compose 基础之上弄的一键部署工具：nebula-up。

下面以 nebula-up 为例：

在 Linux 开发服务器中执行就可以了。

代码获取

NebulaGraph 的代码仓库托管在 GitHub 之上，在联网的情况下直接克隆：

创建开发容器

有了 NebulaGraph 集群，我们可以借助 nebula-dev-docker 提供的开箱即用开发容器镜像，搭建开发环境：

其中，表示当前的 NebulaGraph 代码本地的路径会被映射到开发容器内部的，而启动的容器名字是。

待这个容器启动后，会自动进入到这个容器的 bash shell 之中。如果我们输入退出容器，它会被关闭。如果我们想再次启动容器，只需要执行：

之后的编译、Debug、测试工作都在容器内部进行。在容器是运行状态的情况下，可以随时新建一个容器内部的 bash shell 进程：

为了保持编译环境是最新版，可以定期删除、拉取、重建这个开发容器，以保持环境与代码相匹配。

编译环境

在这个容器内部，我们可以进行代码编译。进入编译容器：

用 CMake 准备 makefile。第一次构建时，为了节省时间、内存，我关闭了测试：

开始编译，根据服务器的空闲 CPU 个数和内存量力而行。比如，我在 72 核心的服务器上准备允许同时运行 64 个 job，则运行：

第一次构建的时间会慢一些，在 make 成功之后，我们也可以执行把二进制安装到像生产安装时候一样的路径：

调试 NebulaGraph

以 graphd 调试为例。

安装依赖

安装一些后边会方便 Debug 额外用到的依赖：

准备客户端

准备一个 NebulaGraph 的命令行客户端：

连接到前边我们 nebula-up 准备的集群之上，加载 basketballplayer 这个测试数据：

gdb 运行 graphd

用 gdb 执行刚刚编译的 nebula-graphd 二进制，让它成为一个新的 graphd 服务，名字就叫。

首先启动 gdb：

在 gdb 内部执行设置必要的参数，跟随 fork 的子进程：

设置待调试 graphd 的启动参数（配置）：

填已经启动的集群的所有 metad 的地址；
和填本容器的域名，是 graphd 监听端口；
是输出日志的目录，和是日志的输出等级；

如果我们想加断点在 2783 行，可以再执行：

配置前边安装的 gdb-dashboard，一个开源的 gdb 界面插件。

最后我们让进程通过 gdb 跑起来吧：

之后，我们就可以在这个窗口/shell 会话下调试 graphd 程序了。

修改 NebulaGraph 代码

这里，我以 issue#3513 为例子，快速介绍一下代码修改的过程。

读代码

这个 issue 表达的内容是在有一小部分用户决定把 JSON 以 String 的形式存储在 NebulaGraph 中的属性里。因为这种方式比较罕见且不被推崇，NebulaGraph 没有直接支持对 JSON String 解析。

由于不是一个通用型需求，这个功能是希望热心的社区用户自己来实现并应用在他的业务场景中。但在该 issue 中，刚好有位新手贡献者在里边回复、求助如何开始参与这块的功能实现。借着这个契机，我去参与讨论看了一下这个功能可以实现成什么样子。最终讨论的结果是可以做成和 MySQL 中的函数那样，改为只接受 JSON String、无需处理输出路径参数。

一句话来说就是，为 NebulaGraph 引入一个解析 JSON String 为 Map 的函数。那么，如何实现这个功能呢？

在哪里修改

显然，引入新的函数，项目变更肯定有很多。所以，我们只需要找到之前增加新函数的 PR 就可以快速知道在哪些地方修改了。

一般情况下，可以自底向上地了解 NebulaGraph 整体的代码结构，再一点点找到函数处理的位置。这时候，除了代码本身，一些面向贡献者的文章可能会帮助大家事半功倍对整体有一个了解。NebulaGraph 官方也除了一个系列文章，大家做项目贡献前不妨阅读了解下，参见：延伸阅读 5。

具体的实操起来呢？我从 pr#4526 了解到所有函数入口都被统一管理在 src/common/function/FunctionManager.cpp 之中。通过搜索、理解当中某个函数的关键词之后，可以很容易理解一个函数实体的关键词、输入/输出数据类型、函数体处理逻辑的代码在哪里实现。

此外，在同一个根目录下，之中则是所有这些函数的单测试代码。用同样的方式也可以知道新加的一个函数需要如何在里边实现基于 gtest 的单测试。

开始改代码

在修改代码之前，确保在最新的 master 分支之上创建一个单独的分支。在这里的例子中，我把分支名字叫：

通过 Google 了解与交叉验证 NebulaGraph 内部使用的 utils 库，知道应该用把字符串读成。再 cast 成 NebulaGraph 内置的类型。最后，借助于 Stack Overflow/GitHub Copilot，我终于完成了第一个版本的代码修改。

调试代码

我兴冲冲地改好了第一版的代码，信心满满地开始编译！实际上，因为我是 CPP 新手，即使在 Copilot 加持下，我的代码还是花了好几次修改才通过编译。

编译之后，我用 gdb 把修改了的 graphd 启动起来。用 console 发起的函数调用。先调通了期待中的效果，并试着跑几种异常的输入。在发现新问题、修改、编译、调试的几轮循环下让代码达到了期望的状态。

这时候，就该把代码提交到远端 GitHub 请项目的资深贡献者帮忙 review 啦！

提交 PR

PR（Pull Request）是 GitHub 中方便多人代码协作、代码审查中的一种方式。它通过把一个 repo 下的分支与这个审查协作的实例（PR）做映射，得到一个项目下唯一的 PR 号码之后，生成单独的网页。在这个网页下，我们可以做不同贡献者之间的交流和后续的代码更新。这个过程中，代码提交者们可以一直在这个分支上不断提交代码直到代码的状态被各方同意 approve，再合并 merge 到目的分支中。

这个过程可以分为：

创建 GitHub 上远程的个人开发分支；
基于分支创建目标项目仓库中的 PR；
在 PR 中协作、讨论、不断再次提交到开发分支直到多方达到合并、或者关闭的共识；

提交到个人远程分支

在这一步骤里，我们要把当前的本地提交的 commit 提交到自己的 GitHub 分叉之中。

commit 本地修改

首先，确认本地的修改是否都是期待中的：

再 commit，这时候是在本地仓库提交 commit：

提交到自己远程的分支

在提交之前，要确保自己的 GitHub 账号之下确实存在 NebulaGraph 代码仓库的分叉 fork。比如，我的 GitHub 账号是 wey-gu，那么我对 https://github.com/vesoft-inc/nebula 的分叉应该就是 https://github.com/wey-gu/nebula 。

如果还没有自己的分叉，可以直接在 https://github.com/vesoft-inc/nebula 上右上角的 Fork，创建自己的分叉仓库。

当远程的个人分叉存在之后，我们可以把代码提交上去：

在个人远程分叉分支上创建 PR

这时候，我们访问这个远程分支：https://github.com/wey-gu/nebula/tree/fn_JSON_EXTRACT，就能找到 Open PR 的入口：

按钮，进入到创建 PR 的界面了，这和在一般的论坛里提交一个帖子是很类似的：

提交之后，我们可以等待、或者邀请其他人来做代码的审查 review。往往，开源项目的贡献者们会从他们的各自角度给出代码修改、优化的建议。经过几轮的代码修改、讨论后，这时候代码会达到最佳的状态。

在这些审查者中，除了社区的贡献者（人类）之外，还有自动化的机器人。它们会在代码库中自动化地通过持续集成 CI 的方式运行自动化的审查工作，可能包括以下几种：

CLA：Contributor License Agreement，贡献者许可协议。PR 作者在首次提交代码到项目时，所需签署的协议。因为代码将被提交到公共空间，这份协议的签署意味着作者同意代码被分享、复用、修改；
lint：代码风格检查，这也是最常见的 CI 任务；
test：各种层面的测试检查任务。

通常来说，所有自动化审查机器人执行的任务全都通过后，贡献的代码状态才能被认为是可合并的。不出意外，我首次提交的代码果然有测试的失败提示。

调试 CI 测试代码

NebulaGraph 里所有的 CI 测试代码都能在本地被触发。当然，它们都有被单独触发的方式。我们需要掌握如何单独触发某个测试，而不是在每次修改一个小的测试修复、提交到服务器，就等着 CI 做全量的运行，这样会浪费掉几十分钟。

CTest

本次 PR 提交中，我修改的函数代码同一层级下的单测试 CTest 就有问题。问题发生的原因有多种，可能是测试代码本身、代码变更破坏了原来的测试用例、测试用例发现代码修改本身的问题。

我们要根据 CTest 失败的报错进行排查和代码修改。再编译代码，在本地运行一下这个失败的用例：

成功！

将新的更改提交到远程分支上，在 PR 的网页中，我们可以看到 CI 已经在新的提交的触发下重新编译、执行了。过一会儿全部 pass，我开始兴高采烈地等待着 2 位以上的审查者帮忙批准代码，最后合并它！

但是，我收到了新的建议：

另一位贡献者请我添加 TCK 的测试用例。

TCK

TCK 的全称是 The Cypher Technology Compatibility Kit，它是 NebulaGraph 从 openCypher 社区继承演进而来的一套测试框架，并用 Python 做测试用例格式兼容的实现。

它的优雅在于，我们可以像写英语一样去描述我们想实现的端到端功能测试用例，像这样！

在添加了自己的一个新的 tck 测试用例文本文件之后，我们只需要在测试文件中临时增加标签，并在执行的时候指定标签，就可以单独执行新增的 tck 测试用例了：

再次邀请 review

待我们把需要的测试调通、再次提交 PR 并且 CI 用例全都通过之后，我们可以再次邀请之前帮助审查代码的同学做做最后的查看，如果一切都顺利，代码就会被合并了！

就这样，我的第一个 CPP PR 终于被合并成功，大家能看到我留在 NebulaGraph 中的代码了。

关于 Spring Cloud Blade

采用前后端分离的模式，前端开源两个框架：Sword (基于 React、Ant Design)、Saber (基于 Vue、Element-UI)
后端采用SpringCloud全家桶，并同时对其基础组件做了高度的封装，单独开源出一个框架：BladeTool
BladeTool 已推送至Maven中央库，直接引入即可，减少了工程的臃肿，也可更注重于业务开发
集成Sentinel从流量控制、熔断降级、系统负载等多个维度保护服务的稳定性。
注册中心、配置中心选型Nacos，为工程瘦身的同时加强各模块之间的联动。
极简封装了多租户底层，用更少的代码换来拓展性更强的SaaS多租户系统。
借鉴OAuth2，实现了多终端认证系统，可控制子系统的token权限互相隔离。
借鉴Security，封装了Secure模块，采用JWT做Token认证，可拓展集成Redis等细颗粒度控制方案。
项目分包明确，规范微服务的开发模式，使包与包之间的分工清晰。

模块说明

Spring Cloud Blade 完整部署的服务拓扑图

基于应用商店快速部署 Spring Cloud Blade

通过开源应用商店部署 Spring Cloud Blade，在 平台管理 -> 应用市场 -> 开源应用商店 中搜索并一键安装。

部署完成后，如上图 Spring Cloud Blade 完整部署的服务拓扑图 所示。

基于源码部署 Spring Cloud Blade

本篇文章基于 Spring Cloud Blade v3.5.0 版本部署。

一、部署 Nacos

通过开源应用商店部署，在开源应用商店中搜索并选择安装版本。

二、部署 Redis

通过开源应用商店部署，在开源应用商店中搜索并选择安装版本。

三、部署 Sentinel Dashboard

通过开源应用商店部署，在开源应用商店中搜索并选择安装版本。

四、初始化数据库

从开源应用商店安装的自带了组件，进入该组件中 -> 端口 -> 打开对外服务，通过客户端工具连接。

创建数据库。
初始化表结构和数据：Blade SQL

五、部署 Blade 后端服务

1.基于源码创建组件，填写以下信息：

内容组件名称自定义组件英文名称自定义仓库地址代码版本: Tag v3.5.0

2.检测出多模块构建，进入多模块构建页面

创建前，在多模块构建页面 -> 右侧修改按钮 -> 修改每个模块的启动命令，如下。

创建后，删除每个组件的默认端口，为每个组件添加对应的新端口和端口别名并打开端口的对内服务，如下。

修改完成后构建组件。

组件端口启动命令 blade-auth 8100 blade-gateway 80 blade-admin 7002 blade-develop 7007 blade-report 8108 blade-resource 8010 blade-swagger 18000 blade-desk 8105 blade-log 8103 blade-system 8106 blade-user 8102

3.编辑依赖关系，切换到拖动组件进行依赖关系建立。

4.进入组件内 -> 端口 -> 打开端口的对外服务，访问 Nacos 并登录，默认用户密码，创建配置文件。

创建配置文件，内容如下：

更新或重启除之外的所有组件。

六、部署 Blade 前端 Saber

基于源码创建组件，填写以下信息：

内容组件名称自定义组件英文名称自定义仓库地址代码版本 v3.5.0

进入组件内 -> 端口 -> 删除默认端口，新增端口并打开对外服务。
编辑依赖关系，切换到拖动组件进行依赖关系建立，将依赖并更新组件。
使用默认域名访问并登录。

部署完成后，如上图 Spring Cloud Blade 完整部署的服务拓扑图 所示。

在去年的 DevCon上，PingCAP 联合创始人兼 CTO 黄东旭提出了一个猜想：“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式。”如今，这个猜想正在得到证实——几乎所有的数据库厂商，都在云上提供服务，并且还有不少数据库正在强化其云原生属性。

那么，云原生之后，数据库的下一步是什么？12 月 1 日，在 PingCAP DevCon 2022 大会上，黄东旭给出了答案：Serverless。

过去一年，PingCAP 一直在忙着把数据库技术变成数据库云服务，最后诞生了 TiDB Cloud。而今年开始，Serverless 则成为了 PingcCAP 的重点技术方向。

业内普遍认为，Serverless 最早可以追溯到 AWS Lambda 等无服务器云函数的引入，它允许开发人员通过简单的 API 调用来启动和停止应用程序。开发人员无需为其配置任何硬件即可运行代码。之后，这个概念被扩展到数据库领域。

Serverless，往往会被翻译为“无服务器”，但黄东旭认为，应该称为之“服务器无感化”。那么在软件开发这一更高的维度来看，则是“技术无感化”。他表示，Serverless 的核心，就是通过更高层次的抽象，把数据库的复杂性一步步降低，如此一来，开发者对具体的技术几乎不需要感知，就能把数据库用起来。

为了更好地理解 Serverless 与开发效率之间的关系，黄东旭引入了“抽象”的概念。

二十年前，如果要建一个网站，开发者除了要写代码，还要把大量时间花在与业务无关的事情上，比如买服务器、租机房、网络租用等，抽象程度很低，迭代速度很慢。

而后，公有云的出现把硬件、部署、网络等数据中心的复杂性抽象掉了，变成了虚拟机。开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。

接下来，云原生的概念出现了。原来的计算单是 VM 虚拟机，在云原生的世界里，计算单进一步被抽象成了一个 Container。Container 是比 VM 虚拟机更高层次的抽象。在虚拟机时代，你依然要考虑 VM 挂了怎么办，但在 Container 世界里，Container 以及底下云的调度器都不用管，这些都被抽象掉了。这意味着，云原生软件的开发迭代速度会比传统基于 VM 的抽象程度更更快。

尽管已经来到云原生的时代，开发效率得到了前所未有的提升，但黄东旭仍然认为还不够。他表示，开发效率低下，开发者没有时间专注于于业务创新，这是阻碍数字化转型进一步深入的一个重要原因。Inapps 公司的研究支持了这一观点。“开发人员每天将 41% 的时间花在基础设施维护上，而不是创新或将新产品推向市场。”

实际中，这一原因通常会被很多人忽视，但作为一个开发者，黄东旭却对此深有体会。“当我想要雄心勃勃地开发一个新的应用时，真正开发的时间可能只占整个时间的 10%-20%。大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面。”

除了数据架构系统本身的复杂之外，数据库技术的多点开花也成为了开发者的压力。

上大学的时候，老师告诉黄东旭，数据库这个东西很简单，你只要会写 SQL 就可以了。但工作以后，黄东旭发现，除了SQL ，还有 OLTP、OLAP、时序数据库、图数据库以及各种各样稀奇古怪的数据库，且每一种数据库都有着自己复杂的概念与运维，想要用好它们，得学习一大堆东西。

“业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了······这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者。”黄东旭说：“我一直想把数据库带回到我上大学的那个时候，那时候多简单。”

这正是 PingCAP 在做的事：Serverless。这也是 PingCAP 所认为的，云原生之后，数据库的下一个方向。一个月前， PingCAP 发布了 TiDB 的 Serverless 云服务—— TiDB Cloud Serverless Tier 。

据了解，TiDB Cloud Serverless Tier 具备四大特性：

一是数据库内核稳定，可以在云上提供很好的弹性、自动 Failover、SQL 等非常硬核的基础能力。
二是 HTAP 能够提供实时的一栈式数据服务。用户无需关心关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务。
三是 Serverless 部署成本极低，不用关心任何运维的细节。通过代码和 open API 就能控制集群的起停。尤其在处理更复杂或更大系统的时候，Serverless 能显著减低复杂性。
四是真正地按需计费。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，召之即来，不用的时候，也不用给钱。任何时候访问，数据库都能对外提供服务。

黄东旭表示，设计 TiDB Cloud Serverless Tier 的一个原则就是，充分利用好云提供的不同服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。它对云上所有的弹性资源都进行了有效的整合以及巧妙的调度，为用户提供了极致弹性的体验。“用户体验比原来的云原生数据库往前跨越了一步，细节更少，抽象程度更高。”

他还表示，Serverless 架构还能解锁更多的可能性。“以 TiDB Serverless Tier 底下重度依赖的云对象存储服务——S3 为例，A 用户用 S3，B 用户也用 S3，数据共享就变得很简单。但在私有环境下，要先把数据下载，拷贝一份，再上传，然后才能做分析。如果数据量比较大，这几乎是难以想象的。而 Serverless 架构从技术层面来说，是能够做到数据共享的。”

就当前而言， PingCAP 还只是迈出了 Serverless 路上的第一步。

关于 Serverless 的未来，PingCAP 副总裁刘松早就畅想过：“下一代应用开发者的编程范式会发生重大的变化，就是因为有了 Serverless 这样‘技术无感化’的技术。未来所有的云厂商，包括数据库厂商都开始进入到了 Serverless 这张门票。最后的一个根本性变化，那就是三五年以后，90% 的应用开发者，都不用关心数据库是什么。”

黄东旭想得更远。“未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来，只需要关注 web 前端开发就好。“

2022 年初，历经一年时间研发的智能终端操作系统 USmart 问世。一家厂商嗅到了商机，找上门来寻求合作，却遭到了拒绝。统信软件给出的理由是，系统还不够好用。

这家企业不过才成立三四年，怎么敢如此“傲慢”？

“不自主一定不安全”

2019 年，统信软件技术有限公司（简称：统信软件）在北京注册成立。也正是在那一年，信创工程也正式走上了舞台，其核心是建立自主可控的信息技术底层架构和标准，在芯片、传感器、基础软件等领域实现国产替代。操作系统就是最具代表性的基础软件之一。

“自主可控和安全可靠是一个结合体，不能孤立地看。自主是安全的必要条件，自主不一定安全，但不自主一定不安全。”统信软件 USmart 产线总经理林明祥解释道，作为中国操作系统的核心厂商，统信软件责无旁贷，应该去挑起大梁去把事情做起来。

过去几十年，中国涌现了一批又一批操作系统公司，统信软件当属其中的佼佼者。统信软件的前身是深度科技，其研发历程从深度操作系统 deepin 开始，可以追溯到 2004 年。

基于这十多年的研发积累，统信软件成立后很快就面向桌面端和服务器端推出了操作系统，并大获成功。统信桌面操作系统给用户带来美观、流畅体验的同时，也为统信软件这家公司积攒了良好的口碑，在通用新增市场持续保持市占第一。面向服务器端的操作系统 UOS V20 一经发布便广受欢迎，2021年在服务器端通用新增市场销售额增速为行业第一。

但这还不够。林明祥认为：“信创工程要解决的是国家信息安全的根本问题，光有桌面操作系统和服务器操作系统是不完整的，必须还得解决数量更加庞大的智能终端的安全问题。”

在这一背景下，2020 年底，研发面向智能终端的操作系统在统信软件内部达成了共识。一年后，基于 Linux 内核的统信智能终端操作系统——USmart 诞生了。不过，这仅仅是预研版本。一家智能设备厂商闻讯而来，想让旗下智能设备搭载 USmart 对外出售，但一提议遭到了统信软件的拒绝。

“这个产品顶多算能用，并不好用。请再给我们一些时间，把产品打磨好。”这就是统信软件给出的理由。

而打磨产品的时间，又花了近一年。

在这一年里，统信软件积极与开放原子开源基金会及 OpenHarmony 社区开展密切合作，把 OpenHarmony 的一些主要特性以及统信软件过去在 Linux 操作系统上的积累相结合，最终开发出了现在的 USmart 系统。

统信软件通过面向服务器、桌面、智能终端的三大操作系统产品，进一步丰富了在操作系统领域的布局。

与此同时，统信软件也意识到，操作系统固然在信息安全保护方面起到了核心的作用，但并不能解决所有的安全问题，还需要上下游共同构建一个“云-网-端”协同的安全体系。因此，今年 4 月，统信软件联合发起了 UOS 主动安全防护计划（UAPP），以共同打造具备世界顶级安全水平的中国操作系统，共建信创基础软件平台安全底座，形成兼容稳定、安全易用的中国操作系统生态，从而共建中国操作系统的安全屏障。

打磨产品是首要目标

在 2021 年的品牌发布会上，统信软件更换了自己的 logo，一个鲁班锁。“它传递的是，以鲁班的工匠精神坚持打造好产品。”林明祥解释，“统信软件给自己的定位，一直是以技术创新来驱动的产品型公司。我们要传承这一精神，用心打造好产品，为用户提供好的服务。”

现在回头看，当初拒绝了那家智能终端厂商，统信软件做对了。

“当时并不是双方合作的好时机。我们不希望为了短期的商业目的把一个不好用的产品推给用户。”林明祥解释道：“用户对移动端和 PC 端的体验感受存在很显著的差别。在移动终端，必须做到毫秒级的用户响应。”

确实如此，这十多年来，安卓系统及 iOS 给移动端用户带来了极致体验，没有人能够容忍一个不好用的移动端产品。“所以，”林明祥说，“极致的用户体验就是我们要追求的目标。”

据了解，如今的 USmart 具有兼容性良好、安全可信、灵活定制、高效低耗等特性，拥有丰富的软硬件生态支撑。在芯片上， USmart 支持 ARM 和 X86 架构，支持包括海思、瑞芯微、展锐等在内的主流智能终端芯片平台。在应用生态上， USmart 支持 Qt 和 OpenHarmony 应用。它可搭载在平板电脑、手持终端、智慧大屏、车机、穿戴、摄像头、自助终端、云终端等不同形态的智能设备上，充分满足党政军及各行业对办公、娱乐、生产、物流、教育、安全等应用领域的应用需求。

今年 9 月初，统信软件携手伙伴打造的搭载 USmart 的首款商务平板正式亮相。这款商务平板已正式通过 OpenAtom OpenHarmony 兼容性测评，成功登陆 OpenHarmony 社区官网。

务实，这是林明祥对统信软件的评价。对于现在的 USmart 来说，他多次表示：“打造出稳定可靠、安全易用，用户认可的智能终端操作系统，这是我们的首要目标。”

即使在某些应用场景下，尤其是为此特别设计的功能，USmart 的体验已经可以做得很好，但林明祥仍然表示不敢妄自尊大。“USmart 和世界主流的操作系统相比，无论是从功能全面性、软硬件生态、设备数量以及用户群体等各个方面综合来看，还有比较大的差距。我们还有很长的路要走。”

林明祥透露，统信软件为 USmart 的未来的发展制定了一个“三年规划”，即 2022 年解决产品在某些应用场景可用和好用的问题，2023 年将硬件生态及应用生态构建方面重点发力，着重于提升适配效率和降低适配成本，2024 年将在自有生态的基础上，挖掘及塑造产品特性，比如围绕 AI 等新技术打造产品亮点，延展产品的适用范围。

“经过这三年的打磨之后，相信我们向垂直行业拓展的路会越来越快，应用场景应该可以实现逐年翻倍。”

操作系统不能没有生态力量

尽管有了桌面操作系统和服务器操作这两大杰作，但统信软件要用新产品来打开新市场，显然不是那么容易。

林明祥指出，桌面操作系统和服务器操作系统都可以用一张光盘来交付，但智能终端操作系统不行，他需要和设备绑定。智能终端操作系统要适配的设备类型丰富多样，比如手机、平板、盒子、大屏、打印机、高拍仪等等，因此要更加注重和设备厂商的联系和合作。

“还有一点不同的是，围绕桌面操作系统，统信软件与很多整机厂商建立了非常紧密的合作关系，不过销售的时候，仍然是两个不同的产品。但是对于智能终端产品而言，是软硬一体的，谁脱离了谁，你都很难说它是一个产品。”林明祥说。

是的，USmart 终究还是要依托智能硬件才能被终端用户看到。因此，USmart 要走得长远，光在自己身上下功夫还不行，还得让硬件厂商、应用软件厂商加入进来，共同构建一个成熟的智能终端操作系统生态。

作为 USmart 产品线负责人，林明祥只有四分之一的时间在北京，其他时间基本上都在外地出差，跟合作伙伴现场沟通是一个常态。“很多设备厂商，都希望和统信软件的合作能给用户带来额外的惊喜。”

一方面，统信软件积极发展自有生态。“跟我们合作的每家设备厂商，都由统信软件工程部直接与其沟通，并且有专人负责该产品线，而不仅仅是简单地适配。我们要保证最终到呈现给用户面前的，是易用、好用的产品。这是统信软件和设备厂商共同的价值。”林明祥说。

而且，统信软件依靠桌面操作系统构建的庞大生态体系——从软件到外设，兼容适配组合数量接近百万，仍然可以在 USmart 上延续。这对 USmart 来说，无疑是一件好事。

另一方面，统信软件还通过技术手段兼容现有的成熟生态，比如安卓系统的一些应用，能通过兼容的方式运行在 USmart 上，这可以帮助硬件厂商在极短时间内、极低成本下适配统信软件的操作系统，快速把产品推向市场，交付给用户。

与此同时，合作伙伴也在不断给统信软件带来创新灵感。

此前，统信软件认为，移动端侧不是一个强力的计算平台，更多的是负责人机交互和简单的数据加工和防护。然而，在和合作伙伴的沟通中，统信软件发现，在一些特定领域，移动端在发挥便携的特性基础上，也可以是生产力工具，需要分布式计算的能力。

“这给了我们很大的启发。在考虑多端协同的时候，不单单要考虑数据处理、数据同步、应用协同等单个场景，还要站在更高的视角，把架构搭建得更完善，来支撑更多场景，为合作伙伴提供更广泛的能力。”林明祥颇为感慨地说。

他还表示，未来，统信软件将联合合作伙伴，针对多个垂直行业打造出标杆产品，让更多用户对国产操作系统和国产智能终端更有信心。

如林明祥所言，USmart 与安卓系统相比，还存在着很大的差距，但是从国家信息安全的角度来看，开发出中国自主的移动操作系统是非常有必要的。如今，统信已经迈出了追赶安卓系统的第一步。“我们相信，经过我们的不懈努力能够缩小这些差距，甚至超越它。而这，需要我们的用户、合作伙伴抱有信心及耐心，一起来完善它。“

痛并快乐

自上一次 Sundial 发布已过 12 天，借助 Furion 框架的人气，Sundial 在 Nuget 平台下载量达到了 1900+ 次，随着越来越多的开发者使用，也暴露出了之前架构设计一些不灵活的问题，收集到了不少建议和问题反馈。

这一次不再是独自一人，为了尽快优化架构和功能改进，拉了4个小伙伴一起对所有代码、注释、文档进行了完整性审查工作，历尽5天的时间，终于解决了现有的所有问题还添加了不少新特性。

这十多天被各种问题搞得焦头烂额，但痛并快乐着~

项目概况

仓库地址：https://gitee.com/dotnetchina/Sundial
文档地址：https://furion.baiqian.ltd/docs/job

亮点展现

此版本在解决不少问题的同时，也增加了不少亮点。

1. 简化作业执行上下文默认字符串输出行为

JobExecutionContext 重写了 ToString() 方法并提供以下几种格式：

2. 添加动态委托作业功能

3. 支持动态编译作业处理程序代码

4. 提供更多内置作业触发器方法和特性

5. 改进作业持久化设计

还有更多更多功能改进可查阅文档：https://furion.baiqian.ltd/docs/job

本期更新

新特性
- [新增] 定时任务间隔分钟作业触发器和特性 4.8.2.8 ⏱️2022.12.01 8e1f06f
- [新增] 定时任务工作日作业触发器和特性 4.8.2.6 ⏱️2022.11.30 28b2d20
- [新增] 定时任务作业校对功能，可对误差进行校正 4.8.2.6 ⏱️2022.11.30 f725a25
- [新增] 定时任务所有带的表达式触发器构建器及特性 4.8.2.5 ⏱️2022.11.29 #I63PLR
- [新增] 定时任务批量添加作业功能 4.8.2.4 ⏱️2022.11.29 5faa67b
- [新增] 定时任务配置，可设置生成不同数据库类型的语句 4.8.2.3 ⏱️2022.11.29 293f9bc !675
- [新增] 和自定义输出配置 4.8.2 ⏱️2022.11.27 0bb9d8f
- [新增] 作业触发器属性，支持只运行一次的作业重新启动服务重复执行 4.8.1.5 ⏱️2022.11.25 a8be728
- [新增] 动态作业处理程序委托支持 4.8.1.8 ⏱️2022.11.27 e02266c
突破性变化
- [调整] 定时任务底层所有代码，日志，注释，文档 4.8.1.10 ⏱️2022.12.05
问题修复
- [修复] 作业触发器不符合下一次执行规律但不为情况 4.8.1.5 ⏱️2022.11.25 a8be728
- [修复] 运行时启动/暂停作业无效问题 4.8.1.6 ⏱️2022.11.25 #I6368M
- [修复] 定时任务生成的语句不支持问题 4.8.1.7 ⏱️2022.11.26 #I638ZC
其他更改
- [调整] 定时任务调度器时间精度，控制持续执行一年误差在以内 4.8.2.9 ⏱️2022.12.01 334d089
- [调整] 定时任务作业计划工厂方法逻辑 4.8.2.7 ⏱️2022.11.30 #I63VS2
文档
- [新增] 作业触发器文档 4.8.1.5 ⏱️2022.11.25 a8be728
- [新增] 通过动态编译代码创建类型文档 4.8.1.5 ⏱️2022.11.25 2c5e5be
- [新增] 自定义和输出文档 4.8.2 ⏱️2022.11.27 0bb9d8f

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

漏洞描述

Node.js 是一个开源、跨平台的 JavaScript 运行时环境。

Node.js 18.7.0版本中的 http 模块中存在 HTTP 请求走私漏洞，漏洞源于 llhttp 解析器无法正确处理未以 CLRF 终止的标头字段，攻击者可通过恶意构造位于之前，包含空值且未用 CLRF 正确分隔的标头触发此漏洞。攻击者可利用此漏洞获取 web 程序敏感信息，并获得对 web 应用程序的未授权访问。

漏洞名称 Node.js v18.7.0 存在 HTTP 请求走私漏洞漏洞类型 HTTP请求的解释不一致性（HTTP请求私运）发现时间 2022-12-06 漏洞影响广度广 MPS编号 MPS-2022-50637 CVE编号 CVE-2022-35256 CNVD编号 –

影响范围

nodejs@[14.0.0, 14.21.1]

nodejs@[18.0.0, 18.12.1]

nodejs@[16.0.0, 16.18.1]

nodejs/llhttp@(-∞, 6.0.10)

修复方案

升级nodejs到 19.0.0 或更高版本

升级nodejs/llhttp到 6.0.10 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-50637

https://nvd.nist.gov/vuln/detail/CVE-2022-35256

https://hackerone.com/reports/

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

Node.js 是一个开源、跨平台的 JavaScript 运行时环境。

由于 CVE-2022-32212 修复不完全，Node.js 的受影响版本中仍存在操作系统命令注入漏洞。漏洞源于发出允许重新绑定攻击的 DBS 请求之前，IsIPAddress 没有正确检查 IP 地址是否无效，导致 Node.js 的 rebinding 保护器允许无效的 IP 地址（如：八进制格式）。攻击者可利用此漏洞通过恶意构造八位字节的无效 IP 如（1.09.0.0）绑定到 –inspect 会话中，在浏览器通过 DNS 解析此无效的八进制地址时进行 DNS 重新绑定，并远程执行恶意代码。

漏洞名称 Node.js 存在操作系统命令注入漏洞漏洞类型命令注入发现时间 2022-12-06 漏洞影响广度广 MPS编号 MPS-2022-60662 CVE编号 CVE-2022-43548 CNVD编号 –

影响范围

nodejs@[18.0.0, 18.12.1)

nodejs@[16.0., 16.18.1)

nodejs@[19.0.0, 19.0.1)

nodejs@[14.0.0, 14.21.1)

修复方案

升级nodejs到 14.21.1 或 16.18.1 或 18.12.1 或 19.0.1 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-60662

https://nvd.nist.gov/vuln/detail/CVE-2022-43548

https://nodejs.org/en/blog/vulnerability/november-2022-security-releases/

https://nodejs.org/en/blog/release/v14.21.1/

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

前言

随着Android平台的飞速发展，许多老牌App，都发展成了所谓的“超级应用”，不但功能模块众多、代码量巨大，团队规模更是扩大到了几十人甚至上百人的规模。一线大厂的旗舰应用，甚至可能涉及到多个部门的协同开发。

在这个过程里，必然的产生了一些“代码复用”和“协同效率”方面的问题。所以，组件化开发逐渐被各个大厂提上了日程。如今，移动端开发除了要解决“代码”方面的问题，也需要关注“工程”方面的问题。

2022年，百度网盘App迎来了10周年，在这10年的发展过程中，我们也遇到过各种各样的的“工程”问题，为了解决这些问题，我们引入了组件化开发，而Rubik就是在这个过程中诞生的。

关于Rubik

Rubik由百度网盘团队出品，从2019年开始建设，至今已经迭代了两个大版本，并在多款线上产品中得到应用。

Rubik是一套解决Android平台组件化的综合框架，也就是说，Rubik在帮助我们实现模块解耦的同时，还能能够提供一些组件管理能力。Rubik所提供的模块解耦能力是一种基于“函数路由”的组件间低耦合通讯方案。组件管理能力能够帮助我们实现组件的版本控制、maven发布、aar/jar与源码之间的切换等能力，Rubik还可以通过配置文件，更简便的把现有的组件，组合成不同的APK。

Rubik框架的工程结构

换而言之，Rubik专注于解决Android应用开发过程中的组件化问题。但是，Rubik作为一个完全由Kotlin语言实现的开源框架，即使你没有组件化开发方面的需求，也非常欢迎关注Rubik的技术实现，欢迎阅读Rubik的代码，因为：

首先，Rubik完全采用kotlin开发，并且大量应用了Kotlin的函数式编程、DSL等特性，非常适合正在学习Kotlin的小伙伴交流学习；

另外，在Rubik的实现过程中，也应用到了Kotlin代码自动生成方面的技术。几乎尝试了目前全部Kotlin代码自动生成的相关方案，也用到了Tranform这样的传统的字节码修改技术。

最后，作为一个贯穿于Android编译过程的工具链类项目，Rubik中有大量的，关于Gradle插件方面的实践，也封装了大量的Gradle方面的工具类。非常适合想要开发Gradle插件的小伙伴参考和借鉴。最重要的是，这一切都是基于Kotlin的。

关于组件化

关于组件化开发，有很多不同的定义。在这里，定义并不重要，我们更应该关心，对于客户端开发而言，组件化开发所能解决的最核心的问题是什么。我们认为，组件化开发的核心，在于两点：

隔离：让业务组件之间保持相对的独立性
复用：复用业务组件形成可运行软件

怎样才算彻底的组件隔离？

让业务组件之间保持独立性，通常可以与代码层面上的“解耦”划上等号，如果两个业务的代码混杂在一起，缺乏对边界的定义，肯定是代码隔离不彻底的表现。

代码隔离不彻底的情况

另外，对于组件化来说，业务隔离的标准还要更苛刻一些，当两个模块，在业务上的关联并不强时，如果存在直接的代码调用，也要视作代码隔离不彻底。由于编译顺序的关系，在Android平台，模块之间是无法建立双向的代码依赖的，这显然与组件化的理念有出入，我们希望组件之间是平等、独立的，应该可以自由的在任何组件之间建立松耦合的依赖关系。像这种基于代码调用的单向依赖，本质上一种“剪不断”的“从属关系”。

代码隔离不彻底的情况

所以，在组件化开发中，组件之间应该保持没有代码耦合，在需要互相通信时，使用一种通过接口，间接的依赖的通信方式。

间接的依赖

在实际的组件化开发过程中，隔离往往是最难以实际操作的，无论是面对难以维护的历史代码，还是在前期规划不足的新业务。但是，一旦清晰的划分出两个组件间的边界，把彼此的代码隔离开，就会带来一系列的工程方面的好处：

明确开发人员的职责：由于对一个模块的修改不会直接影响另一个模块，所以负责开发不同模块的开发人员，只需要对约定好的接口负责，不需要关心其他组件的具体实现。
降低测试成本：同样的，对于测试人员而言，如果能够保证对一个组件的修改，只影响组件本身和组件的接口，那么对于没有被修改过的组件，就没有回归测试的必要了。
提升编译速度：在实际开发中，可以让大部分组件提前编译成二进制，只让少数经常变更的组件保持源码状态。
故障隔离：当一个组件出现故障，能够做到不影响其他组件的正常运行。

对于组件的隔离，可以总结成一句话：隔离代码不是目的，隔离变化才是最重要的！

除此之外，隔离也是对组件进行复用的前提，只有隔离了一个业务组件对外部的全部隐式的影响，才能保证这个组件在被其他场景复用时是安全、可靠、无副作用的。

组件级别的复用应该做到什么程度？

组件级别的复用，指的是在不同应用程序之间，复用已有的业务组件。这往往都是为了快速搭建新项目，并且最大限度的保证新老项目的代码的一致性，从而降低代码的维护成本。所以，组件化开发框架，应该能够做到对现有的组件进行储备，并且在新项目启动时，通过简单的配置，对已有的组件进行筛选，快速的生成新的应用程序。

组件的筛选复用

在实际开发中，有可能会遇到同一个组件，给不同的应用复用时，存在一些功能差异的情况。所以，组件化框架也必须能够做到将同一套代码，差异化的编译成在功能上略有差异的组件变体，以便在不同需求下复用。

组件的变体复用

Rubik在组件化中的作用？

Rubik由两部分组成，一部分是解决组件间低耦合通信的Rubik Router模块，另一部分是基于Gradle Plugin实现的Rubik工具链，负责解决组件管理和依赖管理方面的问题。

Rubik Router：基于Kotlin DSL的“函数”路由

Rubik在依赖倒置与依赖注入的基础上，实现了一套基于Uri的路由通信方式，与一般的页面路由或四大组件路由不同，Rubik Router允许把Uri及参数，导航到组件内部任意的一个公开的Java或Kotlin函数的执行上。Rubik Router的选择以函数而非Android中的四大组件为路由的终点，主要基于三方面考虑：

灵活性：在实际开发中，组件的边界通常不是简单的页面跳转，有可能是Api的调用或数据、实例的获取，相比于传统的页面路由，“函数”路由可以更加轻量级的满足这些需求。
可扩展性：“函数”路由有更低的层次，使用者可以在函数的基础上延伸更多的用法。
一致性：对于路由调用者而言，路由的终点无论是函数、页面还是数据，Rubik Router都提供一致的调用方式。

函数路由

另外，Rubik Router提供了基于Kotlin DSL的调用方式，提供了基于注解的路由声明方式，让使用者可以更加简便、直观的调用其他组件提供的接口。

用注解把函数注册到路由

通过Kotlin DSL调用其他组件提供的接口

Rubik Plugins：基于Gradle Plugin的组件管理和依赖管理工具

Rubik gradle plugins 提供了组件定义、版本控制、maven发布、二进制依赖与源码依赖切换等能力，包括4个gradle plugin:

rubik：
- 提供全局定义组件的能力，并根据全局定义自动启用rubik-context、rubik-root等插件
  
  rubik插件工程结构
```
 
```
  组件的定义方式
rubik-root：
- 给App工程提供筛选组件能力，根据flavor、版本号筛选要打包进apk的业务组件
- 提供组件的源码工程和aar切换的能力

组件的筛选与依赖方式切换

筛选组件的方式

rubik-context：
- 提供把业务代码按flavor、版本号编译成aar 并发布到maven的能力
- 提供辅助函数路由，把中间代码打包成context.jar ，并按版本号发布到maven的能力，并根据全局定义，为组件自动添加其他组件的中间代码依赖

组件及中间代码的发布和自动依赖

rubik-test:
- 给工程提供单测试环境

最后

希望Rubik能够帮助大家更便捷的实现组件化开发，也欢迎大家进行代码和技术层面的交流，如果你觉得我们做的还不错，请小伙伴们不要吝惜star、fork和watching：
https://github.com/baidu/Rubik

新增流式查询，分页查询内存优化；Bee Sharding V2.0, 增加分库分表的分片功能；分片就是如此简单，增加一行配置即可；

Bee 经过 10 几个版本的迭代，ORM 的基本功能已趋于成熟稳定；现在增加 Sharding 功能，方便伙伴们提升分库分表的功能。

在 ORM 实现分片功能，更加简单，合理。

新增功能列表:

V2.0.0.1207 (2022・怀念版)

新增流式查询，分页查询内存优化，降低内存消耗

Sharding 分片功能

1) 面向对象分片
2) Suid,SuidRich, 查询，更新分片
3) MoreTable 多表查询分片
4) 批量插入分片
5) MAX,MIN,COUNT,SUM,AVG 分片查询分片
6) 分页 / 排序分片
7) 分片种类支持：分库分表，仅分库，仅分表
8) 分片路由种类支持：一库一表，一库多表，多库多表，全库全表，只指定表，只指定库
9) 通过 Hint 强制指定当次操作的分片路由 (指定 ds 和 table)
10) 分片的广播表
11) Sharding 分片配置支持

参考示例

//1. 分片配置

ShardingConfig.addShardingBean(Orders.class,new ShardingBean(“ds[0..1].orders[0..5]”, “userid”));

//2. 查询

Suid suid=BF.getSuid(); // 获取 select,update,insert,delete 操作对象

Orders orders1=new Orders();

orders1.setUserid(3L); // 分片值

List<Orders> list=suid.select(orders1,condition); // 查询 Orders 实体列表

其中：”ds [0..1].orders [0..5]”, “userid” 表示，数据源有:ds0, ds1; ds0 里有：orders0，orders1，orders2； ds1 里有表：orders3，orders4，orders5；表的分片键是：userid；默认是根据表分片键（字段）的值，来路由到相应的表，如条件 where userid =3, 则 3%6=3, 就会路由到表 orders3。Bee 默认还支持分片值是 String 的类型。

示例中，“//2. 查询” 注释的部分代码，是原来数据库没有分片时，ORM 用来查询的代码。在分片的情况下，只需要添加 “//1. 分片配置” 部分的代码即可；该部分是 Java 风格的配置，也可以使用 properties 风格的方式进行添加配置信息。

Bee 使用分片的相关配置：
#开启 Bee Sharding 分片功能进行分库分表
bee.dosql.multiDS.enable=true
bee.dosql.multiDS.sharding=true
# since v2.0 开启 Sharding 日志
bee.osql.showSQL=true
bee.osql.showShardingSQL=true

Bee Sharding 分片功能特点
1) 可以支持已实现 JDBC 规范的所有数据库；
2) 处理流程简单，无需对 sql 字符串进行解析；
3) 代码低侵入设计良好，如 DataSource 无需耦合 Bee 框架的代码；
4) 约定优于配置，使用最好的实现方案作为约定方式，配置简单，用户使用方便；
5) 通过解析实体对象获取分片信息，更准确；
6) 支持四则运算表达式；
7) 配置简单，使用方便；
8) ORM 工具内置支持，无需再使用其它 ORM 中间件；
9) 数据源不与 ORM 代码耦合。

相关文档：

分库分表 Sharding: 分库分表介绍 (目录)

分库分表 Sharding: 6. Sharing 最佳实践

https://my.oschina.net/u//blog/

Bee 是一个简单，易用，功能强大，开发速度快，编码少的 JAVA ORM 框架。连接，事务都可以由 Bee 框架负责管理. Bee 简化了与 DB 交互的编码工作量，是 编码复杂度为 O(1) 的 Java 框架！

Bee 简单易用：单表操作、多表关联操作，可以不用写 sql, 极少语句就可以完成 SQL 操作；概念简单 ,10 分钟即可入门。
Bee 功能强大：复杂查询也支持向对象方式，分页查询性能更高，一级缓存即可支持个性化优化；具有分布式特性。从 2.0 开始，增加了 Sharding 分片功能，使用分库分表更方便！

Sharding 功能，还在继续哦，有什么好的主意，赶紧告诉我们！打造一个你认为称心如意的 ORM 工具！

码云上的项目首页:

https://gitee.com/automvc/bee
https://gitee.com/automvc/bee-springboot

github：https://github.com/automvc/bee

SQLAlchemy 2.0 的第四个 Beta 版本已发布。

SQLAlchemy 是一个 Python 的 SQL 工具包以及数据库对象映射 (ORM) 框架。它包含整套企业级持久化模式，专门用于高效和高性能的数据库访问。

发布公告写道，2.0.0b4 目前已接近可以正式发布的状态。尤其是新的基于注释的声明性功能，包括数据类 (Python Dataclasses) 支持。这些功能在 Beta 测试期间受到很多关注，关于注解和数据类映射的不同风格的各种问题已被报告并完成了修复，以及一系列与类型相关的修复和改进，以继续允许完全严格的类型而不需要插件。

此外，在 schema、SQL 渲染和 SQL 类型系统中也有新的改进，以及其他的优化和修复。这些改进和修复要么已经在 SQLAlchemy 1.4.44 中发布，要么将在 1.4.45 中发布。

开发团队表示，当前的 2.0 已经非常接近于“功能冻结”状态，由于该版本积累了一系列变化，一旦发布可能会导致长时间的调整。此外，2.0 Beta 版本目前每天平均只有几千次下载，而 1.4 版本在工作日平均每天下载量约为 130 万次。因此，团队认为 SQLAlchemy 2.0 的下载基数预计在头几个月内至少增长 10000%。而且由于 2.0 在所有 SQLAlchemy 版本中具有最多没有向后兼容的变化，因此新 issue 和使用问题在发布后预计会非常多。

2.0 旨在适应现代化 Python 的实际使用，开发团队花费了三年多的时间来升级 SQLAlchemy 用例模型和架构。他们表示，自 2006 年 SQLAlchemy 发布第一个版本以来出现了三个主要的 Python 范式：Python 3、pep-484 类型支持和 asyncio。此次 SQLAlchemy 的 2.0 更新正是为了适应 Python 社区的不断变化。而且与 16 年前相比，Python 社区的规模变得更大，拥有更多新的开发者，他们对严格性、易用性，以及在文档方面有更高的标准。

最后，SQLAlchemy 2.0 计划在 2023 年 1 月中旬发布最终正式版。

Portable OpenCL (pocl) 是一个高效的 OpenCL 标准实现，提供易移植的 OpenCL 实现。该项目另外一个目的是通过编译器优化实现性能的提升，减少人工优化的步骤。

目前 PoCL 3.1 发布了，此版本带来如下改动：

提供与 LLVM/Clang 15.0 版本的兼容性
所有通过 POCL_DEVICES 控制平台设置的设备名称都改为小写
自定义设备驱动程序（以前称为 Accel，现在称为 AlmaIF）的重大返工，支持更多实现 AlmaIF 的设备类型
大大改进了 SPIR-V 对 CPU 和 CUDA 驱动程序的支持
改进了在 WIP Vulkan 驱动程序中实现完整 API 的步骤
cl_khr_command_buffer 的基本实现

PoCL Vulkan 驱动程序依赖于 libvulkan 和 clspv，目前已经针对开源 Mesa Vulkan 驱动程序进行了测试。该驱动程序目前实现了大部分 Vulkan 1.2 API，但 OpenCL 图像支持、命令缓冲区无缓存和其他缺失素尚未处理完毕。

完整的变更可查看 Change Logs 。

RawTherapee 是适用于 Windows、macOS 和 Linux 的免费开源 Raw 图像转换器和照片处理应用，RawTherapee 的常规更新在 2020 年 2 月发布 5.8 版本就停滞了，通常情况下，RawTherapee 每年至少会发布两个更新。如今经过 2 年多的开发，RawTherapee 于近日发布了 5.9 版本。

新功能：

增加了 Spot Removal 工具（详细信息选单），用于去除灰尘斑点和小物体
颜色外观和照明工具（高级选单），以前被称为 CIECAM02，现在包括 CAM16。通过考虑被拍摄场景的条件和观看图像的条件，它允许你以符合人类色彩感知的方式调整图像。
增加了 Local Adjustments 工具（局部选单），用于对图像的某个区域进行由其几何形状或颜色的广泛操作。
Wavelet Levels 工具（高级选单）得到了各种改进。
白平衡工具（颜色选单）增加了一种新的自动白平衡方法，名为 “色温关联”（旧的方法被重新命名为 “RGB 灰阶”）
底片工具（颜色选单）得到了各种改进，包括对非 Raw 文件的支持
增加了预处理白平衡工具（Raw 选单），允许你指定是否应该自动平衡，或者是否应该使用相机记录的白平衡值来代替。
增加了一个新的透视校正工具（Transform 选单），其中包括一个自动透视校正功能。
改进了主直方图的新模式：波形、矢量图和 RGB Parade。
改进了检查功能（文件浏览器选单）。
去马赛克工具（Raw 选单）中新的双重去马赛克方法
Haze Removal 工具（详细信息选单）获得了一个饱和度调整器
RawTherapee 主题得到了改进，包括使其更容易看到哪些工具被启用的变化

更多详情可查看：https://www.rawtherapee.com/downloads/5.9/

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

digiKam 是 KDE 桌面环境的影像管理和编辑程序，支持所有主要图像格式，并可以组织目录为基础的照片收藏，或按日期、时间、或标签的动态相册。用户还可以对图像添加标题和注释，搜索他们和透过智能文件夹保存搜索。添加插件还可以输出到 Flickr 的相册、Gallery2、谷歌地球的 KML 文件、Simpleviewer、刻录成光盘或创建 Web 画廊。

近日，digiKam 7.9 正式发布，本次更新的部分内容如下：

新功能：

IconView：增加对灰度和 16-bits PSD 图像的支持
AppImage 移植到 Qt5 5.15.5
所有捆绑软件都移植到 KF5 5.96
常规：HIF 文件被识别为 HEIF 图像
常规：Libraw 更新至 2022-07-14 快照
- 支持相机格式：
  - 支持 Phase One/Leaf IIQ-S v2
  - 佳能 CR3 filmrolls/RawBurst
  - 佳能 CRM 文件
- 支持相机：
  - 佳能 EOS R3、R7 和 R10
  - 富士 X-H2S，X-T30 II
  - 徕卡 M11
  - 索尼 A7-IV (ILCE-7M4)
  - DJI Mavic 3
  - 尼康 Z9
插件：GMicQt 工具更新到最新的 3.1 版本

错误修复：

Appimage 无法在 Fedora 36 中启动
MacOS 改为 macOS
文件传输终止导致 0 字节的文件被传输到目标位置，与此同时文件被从源头删除
不显示 PSD 16-bit 图像
macOS 上的黑暗模式支持
在 macOS 10.14 上打开任何文件夹都会出现崩溃
在相册之间一次移动超过 30 到 40 张图片后，缩略图中的数据丢失
在许多素上使用标签的剪切和粘贴操作会产生一个意外的结果
digiKam 在选择多个文件并进行批处理时崩溃
文档中的文字不清楚
缩略图在图像重命名时消失，只有在选择或鼠标移动时才重新出现
……

更多详情可查看：https://invent.kde.org/graphics/digikam/-/blob/master/project/NEWS.7.9.0

FreeBSD 12.4 已正式发布，这是 FreeBSD 12 稳定分支的第 5 个版本。

FreeBSD 12.4 目前支持 amd64、i386、powerpc、powerpc64、powerpc64le、powerpcspe、armv6、armv7、aarch64 和 riscv64 架构。

新版本重要变化：

ena(4) 内核驱动升级到 2.6.1
if_epair(4) 驱动程序现在支持使用多个核心来处理流量，以提高性能
unbound(8) 程序已升级到 1.16.3
telnetd(8) 守护进程已被弃用
tcpdump(1) 程序现在支持用户在规则上设置一个数字，这些规则将作为 pflog header 的一部分被公开。
OpenSSL 已升级到 1.1.1q
OpenSSH 已升级到 9.1p1
LLVM 工具链套件已升级到 13.0.0
dma(8) 程序已升级到 snapshot 2022-01-27
file(1) 程序已升级到 5.43
libarchive(3) 库已升级到 3.6.0
……

发布公告 | Release Notes

下载地址：https://www.freebsd.org/

PhpStorm 2022.3 现已正式发布，此次更新带来了新 UI 的预览、完整的 PHP 8.2 支持、数据库工具中的 Redis 支持、PHP 的代码视觉、快速修复预览、Xdebug 配置验证、对 ParaTest 的支持、PHPDoc 的阅读器模式以及许多其他功能。

新 UI

全新的用户界面现已开放试用，新 UI 仍处于 Beta 阶段，默认关闭，可以在设置/首选项中切换到新的 UI。

PHP 8.2

PhpStorm 2022.3 完全支持 PHP 8.2，包含以下功能：

对只读类的各项支持
访问不存在的属性将导致弃用通知
添加了对析取范式类型以及独立的 null、true 和 false 类型的支持
可以使用 #[SensitiveParameter] 属性标记敏感参数
弃用 ${ 字符串插值

改进的快速文档

按下F1 / Ctrl+Q任何函数、类或方法，PhpStorm 将直接在编辑器中显示文档。

日期时间格式预览

将鼠标悬停在日期格式字符串上时，PhpStorm 2022.3 会显示带有示例日期的工具提示。

以上为此版本部分新功能，更多内容可以在发布公告中查阅。

🍈项目介绍

项目地址：https://gitee.com/bootx/bootx-platform，非常欢迎看看项目介绍留以及个Star呀🤺🤺🤺

基于Spring Boot框架打造，针对单体式应用进行专门设计，提供整套服务模块，支持支付收单(支付宝、微信、聚合、组合支付)、工作流(Flowable)、三方对接(微信、钉钉、企微、短信)等模块，后端基于Spring Boot和Spring Cloud，前端基于Vue2和Vue3分别打造，可应用在不同业务场景中，目标致力将开源版打造成超越商业后台管理框架的脚手架。

Spring Cloud版本使用Spring Cloud Alibaba技术栈

vue2使用ANTD PRO VUE 作为脚手架

vue3使用 Vben-Admin-Next 作为脚手架

移动端使用 Taro ue3+TS为技术栈

🛠️本次功能更新

项目主要更新

优化: 升级基础依赖
优化: redisson启动机制修改, 不再会导致项目无法启动
优化: 钱包报错提示优化
优化: vue3模板调整
fix ts映射字段类型缺失

Vue3进度

新增: 企业微信机器人和钉钉机器人配置
新增: 新增a-link组件，替代标签
新增: 除流程图设计之外的流程基础配置
新增: 消息通知查看和未读列表
新增: 添加wangEditor组件
新增: 用户全局websocket消息推送
新增: 菜单支持配置单独打开内部页面
新增: 菜单支持配置在内部打开外部页面
新增: 消息模板渲染测试功能
新增: 微信支付通道配置
新增: 支付宝支付通道配置
新增: 超级查询器及演示DEMO
新增: 微信支付通道
新增: 支付记录/退款记录/回调记录
新增: 储值卡管理
新增: 钱包管理
新增: 简单复杂和简单结算台演示Demo
优化: 字典初始化提早到项目加载时
优化: 用户和角色选择器新增数据源属性配置项
优化: basic-modal 最低高度为无限制
优化: 项目路由配置,无用代码删除

Vue2更新

优化: 用户和角色选择器新增数据源属性配置
优化: diffForm逻辑重构
优化: 表单提示补全
优化: 富文本功能样式优化
优化: 部分请求地址变更
优化: 错误命名和无用代码修正
优化: 超级查询器文本更新, 菜单编辑校验格式优化

🚅 路线图

工作流功能完善【完成】
Vue3 版本前端【进行中，进度75%】
基础功能补全【进行中】
短信通知对接
minio对接
文档预览功能对接
自定义报表大屏
认证控制功能优化，支持登录错误次数锁定，二次操作验证等
Spring Cloud 版本【规划中】
代码组织结构调整 [完成]
网关定制开发 [完成]
功能模块移植 [进行中]

🥞功能截图

| | | | | | | | | |

| | | | | | | |

漏洞描述

Cacti 是一个开源平台，可为用户提供强大且可扩展的操作监控和故障管理框架。

在Cacti受影响版本中，由于$poller_id参数可控且未做过滤处理，导致用户可通过该控制该参数满足poller_item = POLLER_ACTION_SCRIPT_PHP，进而proc_open函数触发，执行任意代码。如果为任何受监控设备选择了特定数据源，未经身份验证的攻击者可在运行 Cacti 的服务器上执行任意代码。

漏洞名称 Cacti存在命令执行漏洞漏洞类型注入发现时间 2022-12-06 漏洞影响广度极小 MPS编号 MPS-2022-65562 CVE编号 CVE-2022-46169 CNVD编号 –

影响范围

cacti@[1.2.22, 1.2.23)

cacti@[1.2.22, 1.3.0)

修复方案

将组件 cacti 升级至 1.2.23 及以上版本

将组件 cacti 升级至 1.3.0 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65562

Commit

NVD

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

Cacti 是一个开源平台，可为用户提供强大且可扩展的操作监控和故障管理框架。

漏洞名称 Cacti存在任意代码执行漏洞漏洞类型注入发现时间 2022-12-06 漏洞影响广度极小 MPS编号 MPS-2022-65562 CVE编号 CVE-2022-46169 CNVD编号 –

影响范围

cacti@[1.2.22, 1.2.22]

修复方案

参考链接

https://www.oscs1024.com/hd/MPS-2022-65562

Commit

NVD

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

Node.js 是一个开源、跨平台的 JavaScript 运行时环境。

Node.js 18.7.0版本中的 http 模块中存在 HTTP 请求走私漏洞，漏洞源于 llhttp 解析器无法正确处理未以 CLRF 终止的标头字段，攻击者可通过恶意构造位于之前、包含空值且未正确使用 CLRF 进行分隔的 http 请求标头触发此漏洞。攻击者可利用此漏洞获取 web 程序敏感信息，并获得对 web 应用程序的未授权访问。

漏洞名称 Node.js http 模块存在 HTTP 请求走私漏洞漏洞类型 HTTP请求的解释不一致性（HTTP请求私运）发现时间 2022-12-06 漏洞影响广度广 MPS编号 MPS-2022-50637 CVE编号 CVE-2022-35256 CNVD编号 –

影响范围

nodejs@[18.0.0, 18.12.1]

nodejs@[14.0.0, 14.21.1]

nodejs@[16.0.0, 16.18.1]

nodejs/llhttp@(-∞, 6.0.10)

修复方案

nodejs 暂未发布新版本，请关注官方公告：https://nodejs.org/en/blog/

升级nodejs/llhttp到 6.0.10 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-50637

https://nvd.nist.gov/vuln/detail/CVE-2022-35256

https://hackerone.com/reports/

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

每当TIOBE榜单发布的时候，那个笑话就会回响在开源社区诸位的耳边：

美女：你能一句话让这个社区的人吵起来我今晚跟你走。

程序员：PHP是最好的语言。

美女：我跟你走。

程序员：不行，我得说服他们PHP是最好的语言。

这就让我们产生了一个问题，即使这份榜单20名开外的语言的开发者也会参与这样的吵架么？他们的开源活动的策略和估计是什么？本文作者作为scheme-langserver的开发者，希望在这里为大家做一点分享。以下为原文：

在对于中国开源运动的估计和伴随而来的行为策略问题上，开源社区的人们还没有进行系统的梳理过。大家虽然相信开源的盘子是不可避免的越来越大的，却更多的是把这种运动当成一种“电子榨菜”。因此他们实际上不赞成对开源运动进行深入的参与，只想要蜻蜓点水，能够在求职的时候打一打游击，能快速找到几个Java、Python或者PHP项目解决需求就好了。同时，他们也没有把自己独特的想法和创造性贡献给开源社区的意愿，因此也就没有这种开源运动会快速发展去促成全信息技术产业链高度变革的观念。他们似乎认为开源运动对于改善自己的职业生涯是有益但是有限的，至少对于遥远的35岁危机和996工时是徒劳的。他们最多用比较轻便的“使用-宣传-拉人头”的循环扩大开源的影响，等到他们所谓全国乃至全世界的工作都做好了，或者做到某个地步了，再“咔”一声把旗帜举起来就能促成自己对封闭的、陈旧的、没有人道主义精神的不自由996式样的开发的颠覆。

他们这种全领域的，包括一切地方的、拉人头式样的开源活动的理论是不切合实际的。这种不切合实际的幻想主要是因为对于一个事实没有认知清楚：企业和组织正在把开源当成一种KPI，而且从2014年开始已经当成了KPI（据《中国开源报告2022》）——也就是说，对开源产品的“使用-宣传-拉人头”是他们在学校里听到的关于就业的神话；是过去一段时间企业之间抢夺人才优势织造的一个梦；是2022年知乎上所谓计算机行业失业大潮戳破的一个泡泡——唯独不是绝大多数开源产品使用者的自觉。他们是跟着走的羊，在吃草的时候故意不去看狼或者牧羊犬。

如果认识清楚了当前中国乃至国外的开源活动越来多的成为许多企业互相争夺的“半殖民地”而不是社区的“自留地”，则：第一，就会明白为什么Gitee会宣称所谓的“全球第二大开源社区”而许多人从未向某一开源项目提交过一个pull request；第二，就会明白把明白为什么开源中国的“综合资讯”主要是各大企业的新闻自留地，“软件更新资讯”评论最多的软件往往是Web、大前端，即使开源中国置顶了《如何在 OSC 社区运营你的开源项目？》而不是《如何在 OSC 社区运营企业的开源项目？》；第三就会明白为什么还会有TIOBE12月榜单上排名20开外的语言的项目在活跃；第四，就会明白为什么硅谷仍然是创新的中心而不是什么深圳或者北京；第五，就会明白写一些小众语言的代码，构成企业使用这些代码的技术壁垒是一种必要的形式。

这等等等等的事实都说明，要在程序员所谓“已经很高”的工资收入基础上继续改善程序员的生活，要挣得自己的劳动所创造的比较大的那一部分，就必须在当前开源社区已经占据的广大地域，用小众的语言去开发更多的东西：可以是网站，可以是APP，可以是视频剪辑软件。要用曾经弱小的社区能够壮大来教育自己，用更加紧密的团结、更加丰富的开发和“多样性”倒逼市场提高待遇——让不是市场主体的自己享受更多利好。特别是某些市场主体已经展露了吃白食的獠牙的时候。

当然也不必犯反主流文化的急性病。控制论曾经将计算、反主流文化和设计联系起来，就仿佛美国6、70年代的披头士们诞生了苹果一样，大企业对于小众需求的傲慢和无视渐渐孕育了伟大的反抗和伟大的下一代，这就是中学政治课本里面的矛盾论。在当代这种孕育是什么我们并不知道，但是如果开源社区有这样的意愿，我们也将在历史中学习和塑造自己的能力。

让一切不够尊重开源和程序员的人发抖吧。星星之火，可以燎原。

导读： Apache Doris 是小米集团内部应用最为广泛的 OLAP 引擎之一，本文主要从数据的角度分析 A/B 实验场景查询的性能现状，探讨基于 Apache Doris 的性能优化的解决方案。经过一系列基于 Doris 的性能优化和测试，A/B 实验场景查询性能的提升超过了我们的预期。希望本次分享可以给有需要的朋友提供一些参考。

作者｜小米集团大数据工程师乐涛

业务背景

A/B 实验是互联网场景中对比策略优劣的重要手段。为了验证一个新策略的效果，需要准备原策略 A 和新策略 B 两种方案。随后在总体用户中取出一小部分，将这部分用户完全随机地分在两个组中，使两组用户在统计角度无差别。将原策略 A 和新策略 B 分别展示给不同的用户组，一段时间后，结合统计方法分析数据，得到两种策略生效后指标的变化结果，并以此判断新策略 B 是否符合预期。

小米 A/B 实验平台是一款通过 A/B 实验的方式，借助实验分组、流量拆分与科学评估来辅助完成科学的业务决策，最终实现业务增长的一款运营工具产品。其广泛的应用于产品研发生命周期中各个环节：

数据平台架构

本文主要从数据的角度分析 A/B 实验场景查询的性能现状，探讨一下基于 Apache Doris 的性能优化的解决方案。A/B实验平台的架构如下图所示：

平台使用的数据主要包含平台自用的实验配置数据、数据，以及业务方上报的日志数据。
由于业务方引入 SDK，并与分流服务进行交互，日志数据中包含其参与的实验组 ID 信息。
用户在实验平台上配置、分析、查询，以获得报告结论满足业务诉求。

鉴于 AB 实验报告各个业务方上报数据的链路都大体类似，我们就拿头部业务方广告业务举例，数据流程如下图所示：

从上图可知，整个数据链路并不复杂，日志数据传入后，经过必要的数据处理和清洗工作进入 Talos（小米自研消息队列），通过 Flink 任务以明细数据的形式实时写入到 Doris 表中，同时 Talos 数据也会同步到 Hive 表进行备份，以便问题排查和数据修复。

出于对高效写入以及字段增减需求的考虑，Doris 明细表以 Duplicate 模型来建模：

在提速之前，小米 A/B 实验平台完成实验报告查询的 P95 时间为小时级，实验报告使用数据的方式存在诸多的性能问题，直接影响业务部门做运营和决策的效率。

报告查询基于明细

当前报告查询的数据来源为明细表，而明细表的数据量巨大：

而且，实验报告的查询条件中时间范围常常横跨多天。基于历史查询报告统计，查询条件中时间范围大于一天的报告占比 69.1%，具体的时间跨度占比分布如下：

明细数据的巨大扫描量给集群带来了不小的压力，且由于报告查询存在并发以及 SQL 的拆分，如果一个 SQL 请求不能快速的返回结果释放资源，也会影响到请求的排队状况。因此在工作时间段内 Doris 集群BE节点 CPU 负载状况基本是持续满载，磁盘 IO 也持续处于高负荷状态，如下图所示：

BE节点CPU使用率

BE节点磁盘IO

个人思考：

当前报告所有查询基于明细数据，且平均查询时间跨度为 4 天，查询扫描数据量上百亿。由于扫描数据量级大，计算成本高，给集群造成较大压力，导致数据查询效率不高。
如果通过对数据进行预聚合处理，控制 Scan Rows 和 Scan Bytes，减小集群的压力，查询性能会大幅提升。

字段查询热度分层分布

由于之前流程管控机制相对宽松，用户添加的埋点字段都会进入到明细表中，导致字段冗余较多。统计历史查询报告发现，明细表中常用的维度和指标只集中在部分字段，且查询热度分层分布：

参与计算的指标也集中在部分字段，且大部分都是聚合计算(sum)或可以转化为聚合计算(avg)：

个人思考：

明细表中参与使用的维度只占 54.3%，高频使用的维度只占 15.2%，维度查询频次分层分布。
数据聚合需要对明细表中维度字段做取舍，选择部分维度进行上卷从而达到合并的目的，但舍弃部分字段必然会影响聚合数据对查询请求的覆盖情况。而维度查询频次分层分布的场景非常适合根据维度字段的热度做不同层次的数据聚合，同时兼顾聚合表的聚合程度和覆盖率。

实验组 ID 匹配效率低

当前明细数据的格式为：

明细数据中的实验组 ID 以逗号分隔的字符串形式聚拢在一个字段中，而实验报告的每条查询语句都会使用到过滤，查询数据时使用 LIKE 方式匹配，查询效率低下。

个人思考：

将实验组 ID 建模成一个单独的维度，可使用完全匹配代替 LIKE 查询，且可利用到 Doris 索引，提高数据查询效率。
将逗号分隔的实验组 ID 直接打平会引起数据量的急剧膨胀，因此需要设计合理的方案，同时兼顾到数据量和查询效率。

进组人数计算有待改进

进组人数查询是实验报告的必查指标，因此其查询速度很大程度上影响实验报告的整体查询效率，当前主要问题如下：

当进组人数作为独立指标计算时，使用近似计算函数处理，是通过牺牲准确性的方式提升查询效率。
当进组人数作为复合指标的分母进行计算时，使用处理，此方式在大数据量计算场景效率较低。

个人思考：

AB实验报告的数据结论会影响到用户决策，牺牲准确性的方式提升查询效率是不可取的，特别是广告这类涉及金钱和业绩的业务场合，用户不可能接受近似结果。
进组人数使用的计算需要依赖明细信息，这也是之前查询基于明细数据的重要因素。必须为此类场景设计新的方案，使进组人数的计算在保证数据准确的前提下提高效率。

数据优化方案

基于以上的数据现状，我们优化的核心点是将明细数据预聚合处理，通过压缩数据来控制 Doris 查询的 Scan Rows 和 Scan Bytes。与此同时，使聚合数据尽可能多的覆盖报告查询。从而达到，减小集群的压力，提高查询效率的目的。

新的数据流程如下图所示：

整个流程在明细链路的基础上增加聚合链路，Talos 数据一方面写入 Doris 明细表，另一方面增量落盘到 Iceberg 表中，Iceberg 表同时用作回溯明细数据以及生成聚合数据，我们通过工场 Alpha（小米自研数据开发平台）的实时集成和离线集成保证任务的稳定运行和数据的一致性。

选取高频使用维度聚合

在生成数据聚合的过程中，聚合程度与请求覆盖率是负相关的。使用的维度越少，能覆盖的请求就越少，但数据聚合程度越高；使用的维度越多，覆盖的请求也越多，但数据粒度就越细，聚合程度也越低。因此需要在聚合表建模的过程中取得一个平衡。

我们的具体做法是：拉取历史（近半年）查询日志进行分析，根据维度字段的使用频次排序确认进入聚合表的优先级。在此基础上得出聚合表的覆盖率和数据量随着建模字段增加而变化的曲线，如下图所示：

其中覆盖率根据历史请求日志代入聚合表计算得出。

我们的原则是：针对 OLAP 查询，聚合表的数据量应尽可能的控制在单日 1 亿条以内，请求覆盖率尽可能达到 80%以上。

因此不难得出结论：选择 14 个维度字段对聚合表建模比较理想，数据量能控制到单日 8 千万条左右，且请求覆盖率约为 83% 。

使用物化视图

在分析报告历史查询日志时，我们发现不同的维度字段查询频次有明显的分层：

Top7 维度字段几乎出现在所有报告的查询条件之中，对于如此高频的查询，值得做进一步的投入，使查询效率尽可能的提升到最佳。Doris 的物化视图能够很好的服务于此类场景。

什么是物化视图？

物化视图是一种特殊的物理表，其中保存基于基表(base table)部分字段进一步上卷聚合的结果。

虽然在物理上独立存储，但它是对用户透明的。为一张基表配置好物化视图之后，不需要为其写入和查询做任何额外的工作：

当向基表写入和更新数据时，集群会自动同步到物化视图，并通过事务方式保证数据一致性。
当对基表进行查询时，集群会自动判断是否路由到物化视图获取结果。当查询字段能被物化视图完全覆盖时，会优先使用物化视图。

因此我们的查询路由如下图所示：

用户的查询请求会尽可能的路由到聚合表物化视图，然后是聚合表基表，最后才是明细表。

如此使用多梯度的聚合模型的配合来应对热度分层的查询请求，使聚合数据的效能尽可能的发挥到最大。

精确匹配取代 LIKE 查询

既然物化视图这么好用，为什么我们不是基于 Doris 明细表配置物化视图，而是单独开发聚合表呢？是因为明细数据中的实验组ID字段存储和查询方式并不合理，聚合数据并不适合通过明细数据直接上卷来得到。

上文中已经提到，（实验组ID）在明细表中以逗号分隔的字符串进行存储，查询数据时使用 LIKE 方式匹配。作为 AB 实验报告查询的必查条件，这种查询方式无疑是低效的。

我们希望的聚合方式如下图所示：

我们需要将字段拆开，把数据打平，使用精确匹配来取代LIKE查询，提高查询的效率。

控制聚合表数据量

如果只做拆分打平的处理必然会导致数据量的激增，未必能达到正向优化的效果，因此我们还需要想办法来压缩打平后的数据量：

聚合表选取维度字段建模的时候，除了上文提到的，以字段的使用频次热度作为依据之外，也要关注字段的取值基数，进行综合取舍。如果取值基数过高的维度字段进入聚合表，必然会对控制聚合表的数据量造成阻碍。因此，我们在保证聚合表请求覆盖量的前提下，酌情舍弃部分高基数（取值有十万种以上）的维度。
从业务的角度尽可能过滤无效数据（比如一个实验组的流量为 0% 或者 100%，业务上就没有对照的意义，用户也不会去查，这样的数据就不需要进入聚合表）。

经过这一系列步骤，最终聚合表的数据量被控制在单日约 8000 万条，并没有因为打平而膨胀。

值得一提的是，字段拆分后，除了查询从LIKE匹配变为精确匹配，还额外带来了两项收益：

字段从类型变为类型，作为查询条件时的比对效率变高。
能利用Doris的前缀索引和布隆过滤器等能力，进一步提高查询效率。

使用 BITMAP 去重代替 COUNT DISTINCT

要提速实验报告查询，针对进组人数（去重用户数）的优化是非常重要的一个部分。作为一个对明细数据强依赖的指标，我们如何在不丢失明细信息的前提下，实现像 Sum,Min,Max 等指标一样高效的预聚合计算呢？BITMAP 去重计算可以很好的满足我们的需求。

什么是BITMAP去重？

BITMAP 去重简单来说就是建立一种数据结构，表现形式为内存中连续的二进制位(bit)，参与去重计算的每个素（必须为整型）都可以映射成这个数据结构的一个 bit 位的下标，如下图所示：

计算去重用户数时，数据以的方式进行合并，以的方式得到结果。更重要的是，如此能实现去重用户数的预聚合。BITMAP 性能优势主要体现在两个方面：

空间紧凑：通过一个 bit 位是否置位表示一个数字是否存在，能节省大量空间。以 Int32 为例，传统的存储空间为 4 个字节，而在 BITMAP 计算时只需为其分配 1/8 字节（1个 bit 位）的空间。
计算高效：BITMAP 去重计算包括对给定下标的 bit 置位，统计 BITMAP 的置位个数，分别为 O(1) 和 O(n) 的操作，并且后者可使用 CLZ，CTZ 等指令高效计算。此外，BITMAP 去重在 Doris 等 MPP 执行引擎中还可以并行加速处理，每个节点各自计算本地子 BITMAP，而后进行合并。

当然，以上只是一个简化的介绍，这项技术发展至今已经做了很多优化实现，比如RoaringBitmap，感兴趣的同学可以看看：https://github.com/RoaringBitmap/RoaringBitmap

全局字典

要实现 BITMAP 去重计算，必须保证参与计算的素为 UInt32 / UInt64，而我们的为类型，因此我们还需设计维护一个全局字典，将映射为数字，从而实现 BITMAP 去重计算。

由于聚合数据目前只服务于离线查询，我们选择基于Hive表实现全局字典，其流程如下：

指标聚合

生成 Doris 聚合表时，将作为查询指标以 BITMAP 类型来存储，其他常规查询指标则通过 COUNT/SUM/MAX/MIN 等方式聚合：

如此明细表和聚合表的指标计算对应关系如下：

优化效果

SQL视角

查询请求转换成 SQL 之后，在明细表和聚合表的表现对比如下：

常规聚合指标查询的性能提升自不必说（速度提升 50~60 倍）
进组人数查询性能的提升也非常可观（速度提升 10 倍左右）

集群视角

SQL 查询的快进快出，使查询占用的资源能快速释放，对集群压力的缓解也有正向的作用。

Doris 集群 BE 节点 CPU 使用情况和磁盘IO 状况的改变效果显著：

需要说明的是，集群状况的改善（包括实验报告查询 P95 提升）并不全归功于数据预聚合优化工作，这是各方合力协作（如产品业务形态调整，后端查询引擎排队优化，缓存调优，Doris 集群调优等）的综合结果。

小技巧

由于业务查询需求的多样，在查询明细表时，会出现一个字段既作为维度又作为指标来使用的情况。

如广告业务表中的(目标转化个数)字段，此字段的取值为 0 和 1，查询场景如下：

如果这个字段被选取进入聚合表，应该如何处理呢？

我们的处理方式是：

在聚合表中把这类字段建模成维度
聚合表中需要一个计数指标 cnt，表示聚合表中一条数据由明细表多少条数据聚合得
当这类字段被作为指标查询时，可将其与cnt指标配合计算得到正确结果

明细表查询：

结束语

经过这一系列基于 Doris 的性能优化和测试，A/B 实验场景查询性能的提升超过了我们的预期。值得一提的是，Doris 较高的稳定性和完备的监控、分析工具也为我们的优化工作提效不少。 希望本次分享可以给有需要的朋友提供一些参考。

最后，感谢 SelectDB 公司和 Apache Doris 社区对我们的鼎力支持。Apache Doris 是小米集团内部应用最为广泛的 OLAP 引擎之一，目前集团内部正在推进最新的向量化版本升级工作。未来一段时间我们将会把业务优化工作和 Doris 最新的向量化版本进行适配，进一步助力业务的正向发展。

— End —

最后，欢迎更多的开源技术爱好者加入 Apache Doris 社区，携手成长，共建社区生态。Apache Doris 社区当前已容纳了上万名开发者和使用者，承载了 30+ 交流社群，如果你也是 Apache Doris 的爱好者，扫码加入 Apache Doris 社区用户交流群，在这里你可以获得：

专业全职团队技术支持
直接和社区专家交流，获取免费且专业回复
认识不同行业的开发者，收获知识以及合作机会
Apache Doris 最新版本优先体验权
获取一手干货和资讯以及活动优先参与权

Scheme-langserver 是基于 Chez Scheme 并兼容 scheme r6rs 的 language server protocol 实现。它最大的特点是基于未完成的代码做编程辅助，包括自动完成、定义跳转等。这些功能是基于对r6rs标准的scheme进行静态分析得到的。它被发布在Akku和github。

一些辅助功能如自动完成、定义跳转、鼠标悬停显示文档等功能对于编程十分有帮助。但是，和其他的编程语言如java、python、javascript和c，lisp系的语言服务器协议实现（language server protocol implementation）几乎是一篇空白。emacs的Geiser、Dr. Racket的racket langserver还有swish-lint等等，他们的工作基本上是基于repl（Read-Eval-Print Loop）或者词法解析器的，而不是基于编程的一般过程。例如，如果程序员正参与一个未完成的项目，里面的代码还并不是都能跑起来，Geiser或者其他的竞品都只能提供对顶级变量、标识符的自动补全，这些标识符在Chez Scheme里面一般都通过environment-symbols过程列出来。也就是说，对于未完成的代码和局部标识符、局部变量（在其他语言中自动完成功能主要就是在补全它们），Geiser等等无济于事。类似的事情同样出现在定义跳转等其他功能上。

一个根本的原因是，对于scheme和lisp的其他方言，它们丰富的数据结构和灵活的控制机制让代码的静态分析变成了一个很大的挑战。事实上，scheme甚至没有通用的项目管理框架及对应的文件扩展名。以.ss和.scm为例，大多数程序员假设使用这两个文件扩展名的代码被用于一个正在运行中的环境，并且并不明示代码所需要的库信息。虽然Akku和Snow鼓励通过.sls和.sld提供文件信息并建构一套稳定的库管理框架，但是involve、load和很多其他过程让库链接动态化，这就更不可能在代码静态分析阶段得到什么信息了。

John MacFarlane 是加州大学的哲学教授，也是一名程序员。他是文档工具 Pandoc 的作者，也是 CommonMark 标准的制定者之一。CommonMark 是强定义的 Markdown 规范，它会对很多细节做出定义，以避免歧义性。

近日，John MacFarlane 又发布了一种轻量的标记语法：Djot（发音：/dʒɑt/）。Djot 包含许多派生自 CommonMark 的功能，同时修复了一些使 CommonMark 语法复杂且难以有效解析的问题。

按照 John MacFarlane 的说法，Djot 属于 Markdown 的升级版，最初是为了实现他在 Beyond Markdown 中提出的一些想法。

据介绍，Djot 的功能比 CommonMark 更全面，支持定义列表、脚注、表格、几种新的内联格式（插入、删除、高亮、上标、下标）、数学、智能标点符号、可应用于任何的属性素，以及用于块级 (block-level)、内联级 (inline-level) 和原始内容 (raw content) 的通用容器。

在 Djot 的语法中，对硬换行的解析与常见的 Markdown 不同。

比如使用 Markdown 可以写成这样：

但在 Djot 中，如果使用了块级素，一定要采用硬换行：

对于列表也是同样的处理：

Markdown

Djot

Djot 的解释器采用解释性语言 Lua 编写，据称速度很快，可以生成 AST、渲染 HTML，以及语法高亮显示或 linting 工具。

Djot 语法说明：https://htmlpreview.github.io/?https://github.com/jgm/djot/blob/master/doc/syntax.html。

Mozilla 和微软已经对 TrustCor 的三个根证书采取了行动，这些根证书现在不再被 Firefox 和 Edge 浏览器所信任。

整个事情的起因可以追溯到今年年初，当时卡尔加里大学（University of Calgary）教授 Joel Reardon 在一系列总下载量超过 4600 万次的 Android 应用程序中发现了有收集用户数据的恶意行为。

调查发现，这些软件中的恶意代码都是由 Measurement Systems 开发的，他们的 SDK 包含这些恶意代码，而且 Measurement Systems 还与一家为美国政府从事网络情报和情报拦截工作的承包商之间存在联系。

进一步调查还发现，Measurement Systems 和 TrustCor 的域名都是由 Vostrom Holdings 所注册，注册时间仅相隔一个月；这两个公司实体都有相同的公司管理人员；TrustCor 运营的 Msgsafe “加密” 电子邮件服务，包含 Measurement Systems 的间谍软件 SDK，而且该服务实际上是以明文形式发送电子邮件，用户的电子邮件一览无余，与 “加密” 毫无关系。

虽然目前没有证据表明 TrustCor 作为一家根证书颁发机构（CA）有违反相应政策或程序的行为，也没有证据表明他们曾错误地颁发了受信任的证书，但调查结果使人们对 TrustCor 作为公众信任的 CA 运营的能力产生了合理怀疑。

Mozilla 项目经理 Kathleen Wilson 就表示：

对 TrustCor 的担忧已经得到证实，TrustCor 继续成为 Mozilla Root Program 成员的风险高于对最终用户的好处。

正因如此，目前 Mozilla 和微软都将 TrustCor 列入了不再信任的名单中，其中 Firefox 将不信任的日期设定为 2022 年 11 月 30 日，而微软将该日期设定为 2022 年 11 月 1 日。Google 的 Chrome 和苹果的 Safari 暂时没有采取任何行动，不确定他们会在何时跟进。

虽然 Chrome 和 Safari 暂时没有跟进，但用户可以在浏览器中手动删除或选择不信任 TrustCor 证书（上图以 Safari 浏览器为例）。

在今年 3 月份，JetBrains 曾宣布将无限期暂停在俄罗斯的销售和研发活动，以及无限期暂停在白俄罗斯的销售。现在，该公司又发布了有关该事件的最新更新公告。

公告内容指出，除了终止所有销售外，JetBrains 在俄罗斯的所有办事处，包括莫斯科、新西伯利亚和圣彼得堡都已被关闭，在圣彼得堡的新园区的工作也被终止。所有研发活动逐渐停止，其俄罗斯法人实体的清算文件也已于 2022 年 8 月提交。

JetBrains 俄罗斯团队共有 800 多人。目前该公司已设法将大部分员工从俄罗斯迁出，因个人原因无法搬迁的则已与公司分道扬镳。JetBrains 将这些迁出的人员分配到了在欧洲的办事处，包括在阿姆斯特丹、慕尼黑和柏林的研发中心。同时还在塞浦路斯、塞尔维亚和亚美尼亚开设了新据点。

该公司表示，鉴于客户的大力支持和公司整体良好的财务状况，其有能力继续开发优质的开发工具。并且还发布了一些职位招聘，涵盖 IntelliJ IDEA 团队的 UI/UX 设计师、软件工程师，以及 Kotlin IDE 的高级软件开发人员等等。

JetBrains 方面称，虽然这对公司来说是一个非常具有挑战性和困难的时期。但他们依然选择继续支持乌克兰，并重申了其对俄罗斯政府发起的袭击的谴责。

相关阅读：JetBrains：无限期暂停在俄罗斯的销售和研发活动

在解雇了大部分技术人员的同时，Twitter 新所有者兼首席执行官 Elon Musk 似乎也放弃了对其开源工作的支持。

与大多数现代软件公司一样，Twitter 依赖于开源程序；其基于 CentOS 7 运行，该版本将于 2024 年 6 月结束生命周期。因此，Twitter 方面原本的计划是迁移到 CentOS Stream。但鉴于目前的情况，Twitter 方面好像已经没剩下什么人来推进这个操作系统迁移了。

而 Twitter 对开源软件的依赖也远不止其基础操作系统。Twitter 前开源负责人 Will Norris 在接受 ZDNet 采访时表示，他曾与当时的 Twitter 首席执行官 Parag Agrawal 详细讨论过关于改进 Twitter 对关键开源项目的投资事项。

当我加入时，已经有许多大型的现代化工作正在进行中，其中包含大型开源组件。Pants 构建系统正在被 Bazel 取代，准备用 Kubernetes 取代 Apache Aurora 和 Mesos 的工作也正在进行中。而且，我们已经是 Apache Kafka、Hadoop 和 Scala 的最大用户之一。我们还有一个 JVM 的自定义分支，我们希望它最终能够开源。有很多令人惊叹的工作正在发生，他们成功地从这些社区聘请了非常优秀的人来从事这些项目。

然后今年发生了这些变故：-

首先，马斯克开始时断时续地收购 Twitter。因此在看到一条明确的前进道路前，Twitter 高管选择冻结了其开源计划和投资；但最终，马斯克解雇了所有高管。很快，大多数开发人员也被解雇。如今，Twitter 一半以上的员工要么被赶走，要么跳槽。

Norris 指出，“大多数在 Twitter 从事开源工作的关键人物都离开了。所有与我一起从事开源工作的工程师都离开了”。他认为，这对 Twitter 意味着：

短期内，可能不会有太多开源工作计划。对于 Twitter 来说，变回仅仅作为开源的消费者而不做出任何有意义的贡献是相对容易的；反正很多公司都是这么做的，他们可以像以前一样继续使用 CentOS、Scala、Kafka 和其他所有软件。对于处于迁移过程中的项目，例如 Bazel 和 Kubernetes，停止可能会更痛苦，但这取决于事情处于什么状态。我不得不想象所有的重点只是保持服务运行和添加 Musk 想要的任何产品改变。

Twitter 的现任员工透露，他们目前所能做的就是“keep the wheels turning”。并表示，Twitter 每月 8 美的蓝 V 认证服务延迟推出的真正原因不仅仅是因为被冒名账号所滥用，而是因为开发人员还无法自动化阻止此类滥用行为。

从长远来看，Norris 认为 Twitter 在开源社区中已经变得无关紧要。“他们已经失去了作为一个严肃的工程组织的所有信誉，我不在乎你如何称自己为’hardcore’。开源社区建立在关系和信任的基础上，而现在 Twitter 与这些团体没有任何关系。他们已经失去了任何有意义地参与这些社区的能力。”

但是，有一个迫在眉睫的问题是：Twitter 自己的开源项目。Norris 表示：

它们中的许多不再被积极维护（这是它自己的问题），但它们非常流行，尤其是在 Scala 世界（Finagle、Twemoji、Scalding 和 Algebird）。Twitter 有适当的流程来维持其中一些开源项目（如 Finagle）与代码的内部副本保持同步，但这些都不是完全自动化的。我非常怀疑是否有人留下来做这项工作。那么这些项目的外部用户（包括 ING Bank、Pinterest 和 SoundCloud 等公司）会怎样呢？

此外，Norris 指出，https://github.com/twitter 中的项目维护将会变得很奇怪。因为 Twitter 有一个内部系统来管理它在 GitHub 上的存在。它允许 Twitter 员工注册自己的 GitHub 帐户来访问他们的 Twitter 开源项目。过去的情况是，当某人离开公司时他们的访问权限会被留下，但他们会从 GitHub 上的 Twitter 组织的成员转为外部合作者。

然而即使在马斯克接手之前，Twitter 有时也没能让离开公司的开发人员很好的剥离权限。在 2022 年 8 月，一名员工在离开公司 18 个月后就仍能访问 Twitter 的 GitHub 和源代码。Twitter 在今年早些时候对这一问题进行了修复，但相关工作并未正式完成。因此，Norris 称，“一些维护人员已经在多年前离开了 Twitter 的项目，可能仍然有感兴趣的人在继续访问。”

当然，那些最近被解雇或辞职的人以及“最了解剩余活跃项目的人，几乎可以肯定已经被删除了他们的访问权限” 。几个月前甚至几年前的 Twitter 前员工则很可能仍然拥有代码访问权限，而那些知道谁应该拥有代码访问权限的、但在最近已经被解雇了的员工将不再负责解决问题。

至于 Twitter 自己的开源项目 (如 Finagle)，Norris 预计 Twitter 不会做任何事情来继续维护这些项目，至少不会达到以前的水平。因此，从现实的角度来看，所有这些项目可能都需要分叉并转移到一个新的地方，但这将是一个混乱的过程，而且可能会有很大的破坏性。

11 月 27 日，知名前端框架 Vue 的周 npm 下载量激增十倍，以至于 Vue 创始人尤雨溪发推求助“我也不知道谁搞出来的，请你赶紧修复吧。”

从 NPM Trends 页面上可以看到，上上周（11 月 27 日）的 vue npm 下载量达到惊人的 3800 万，比前一周（11 月 20 日）的 360 万下载量暴增了十倍。而其他前端框架，如 React 和 angular 都没有明显的波动。

反而是另一款前端 UI 框架 Svelte 也经历了过山车式的体验，周下载量先是从日常 40 万飙升到 2800 万，然后又狠狠地下跌，但仍未恢复至正常水平。

热心网友建议尤雨溪直接问 npm 官方，但是 Svelte 框架作者 Rich Harris 表示他已经尝试过和 npm 方面沟通，然而 npm 官方无法透露任何有用的信息，目前只知道 UA 来自 Deno，其他情况一概不知。

大伙纷纷在尤雨溪的推文下面评论调侃，猜测 Npm 下载量暴涨的原因：Vue 框架贡献者 Johnson Chu 称这也许是一项行为艺术，以此来表达通过下载量来比较前端框架毫无意义。

又有网友认为也许是最近火热的 chatGPT AI 正在大量学习如何制作 Vue 应用程序，在每次迭代中都会运行 npm install，导致下载量暴增。此外，也有人认为该事件与 Nuxt 框架 3.0 版本的正式发布有关，Nuxt 3.0 版本基于 Vue 3 构建，可能会导致 Vue 的下载量暴增。

但导致 Vue npm 下载量暴增的原因尚未有明确的定论，只能等下一轮 npm 统计数据或者官方公告，我们会密切跟踪后续发展。

摘要：糟糕，数据库异常不可用怎么办？挺着急的，在线等。

本文分享自华为云社区《糟糕，数据库异常不可用怎么办？》，作者：GaussDB 数据库。

随着数字化转型的加速，数据量爆发式增长，用户对数据库运维能力要求更高，实现对数据库的高效智能管理，尤其是业务异常时，数据库运维平台能自动定位故障并修复，或者提供有价值信息，帮助客户快速定位解决问题。

华为云数据库团队打造的RDS for MySQL智能DBA助手，为数据库管理人员提供了一站式数据库运维方案，能够帮助用户快速处理异常，保持业务稳定运行。近期，我们新上线了自治限流功能，通过限流非核心业务SQL来保障核心业务稳定运行，下面将为您带来该项业界领先的功能的详细解读。

在遭遇异常流量高峰时，如何处理？

在实际运维场景中，客户因为业务变更或者业务高峰期会带来流量高峰，导致系统指标异常，实例CPU飙升近100%，会话SQL处理变慢，活跃连接数增加，数据库响应异常甚至不可用。可能的原因有以下两个方面：

SQL问题：SQL执行效率慢，如对无主键、无索引的表进行查询操作时，CPU和 IO被打满。
流量问题：突发的流量急剧上升，数据库容量达到瓶颈，影响正常业务。

解决方案：

针对上述问题，一般会采用两种方式来处理：

方式一：先分析异常SQL，定位后手动Kill会话

方式二：简单粗暴，重启数据库。

但面对复杂问题，传统解决方案往往无法从根本上解决，定位解决问题花费时间长，导致业务受损。针对这一挑战，业界采用限流的方式来处理，不区分业务，即不会区分限流SQL所在的库或者客户端用户，这可能导致无差别的kill会话，核心业务受损。

我们今天介绍的自治限流功能是如何应对这一潜在风险呢？

自治限流，指的是通过预先设置限流策略，自动限定执行SQL的并发度，通过小部分业务受损，保障核心业务的正常运行。具体来说，可以通过以下三个策略来进行流控：

分库、分用户设置限流范围

自治限流功能支持分库、分用户两种方式设置，客户根据业务情况，识别核心业务库和客户端用户，按需选择相应的限流方式。

按库设置：根据业务重要程度，选择对特定的一个或者多个库进行限流，默认不区分库名。
按用户名设置：根据不同用户业务差异，选择对特定的一个或者多个用户进行限流，默认不区分用户。

设置限流时间：

通过设置限流时间窗（即自治限流功能只在该时间段生效）和每次最大限流时长（即自治限流生效后持续时长），方便定位SQL异常，请注意：同一天只在该时间窗内生效一次。

设置限流策略

条件1：根据业务情况，设置CPU利用率大于多少【且/或】活跃会话数大于多少，且上述条件持续时间大于多少分钟，会触发限流。

条件2：设置允许的最大活跃并发数，当前活跃会话数大于最大活跃会话数时，会将会话数清理到小于最大活跃会话数。

设置界面如下：

完成上述设置后，自治限流功能可以自动检测客户实例异常，触发限流策略后，根据配置的限流范围和时间，自动进行分库分用户限流处理，在保证核心业务SQL稳定运行的前提下，限制引发CPU飙升的新上业务SQL，带来活跃会话数逐渐降低，CPU下降到正常值，QPS恢复到业务正常水平，数据库实例恢复正常。

流量高峰常常是不可预测的，这给运维带来非常大的挑战和工作负担。华为云数据库自治限流功能，通过分库与分用户限流方式，自动检测数据库异常，并及时进行限流处理，保障核心业务的稳定运行，极大减轻了DBA的运维压力，使其更聚焦数据架构设计以及数据价值挖掘等核心工作。目前该功能已上线，欢迎大家体验。https://www.huaweicloud.com/product/mysql.html

关注，第一时间了解华为云新鲜技术~

摘要：华为云Solution as Code推出基于Ploto构建自动驾驶平台解决方案。

本文分享自华为云社区《基于Ploto构建自动驾驶平台》，作者：阿米托福。

2022年6月15日，主题为“因聚而生为你所能”的华为伙伴暨开发者大会 2022 正式开启，在自动驾驶专场中，华为云携手合作伙伴联合发布“乐高式”自动驾驶研发平台解决方案，实现自动驾驶研发效率提升。

联合发布“乐高式”自动驾驶研发平台解决方案

一、自动驾驶商业化落地加速，研发业务面临 4 大挑战

近几年，自动驾驶行业整体加速发展，一线城市开放道路达到1600公里+，二三线也在逐步开放，牌照发放数量持续增长年增长600张+，得益于开放道路和牌照的大幅度增长，2022年中国路测里程达到2000万公里以上，当前国内车企研发的L3/L4自动驾驶技术，单车数据可达60TB/天，因此，自动驾驶的发展对数据和算力的需求成倍增加。

自动驾驶对数据和算例的需求主要体现在 4 个方面：海量数据管理难、成本高；算法训练计算资源需求大；数据处理业务流程复杂，新技术门槛高；全流程的数据合规要求高。

华为云自动驾驶业务研发平台业务全景图

二、基于Ploto构建自动驾驶平台

华为云Solution as Code重磅推出基于Ploto构建自动驾驶平台解决方案，该解决方案基于华为云开源项目Ploto构建，集合业界优秀伙伴提供的专业自动驾驶研发工具，打造“乐高式”解决方案，具有模块化架构体系，为自动驾驶全链路提供可靠服务（数据采集、数据传输、数据脱敏、场景数据提取、数据标注、AI训练、仿真测试、评估评价、OTA升级全链路流程）。

基于Ploto构建自动驾驶平台一键部署

基于这种灵活部署的架构和接口，客户在各个环节都能自主选择业界最契合自己业务发展的伙伴；同时本着激活自动驾驶生态圈、促进自动驾驶行业发展的目标，华为云欢迎更多的专业软件服务商加入共建生态，推动自动驾驶产业的革新。

自动驾驶研发平台 Ploto 数据大屏

在实际业务中，“乐高式”自动驾驶研发平台解决方案聚焦“路测数据上云、算法训练及场景仿真”等 3 类自动驾驶典型场景。通过华为云与伙伴共建 POP 点、提供专属 CPU 资源池、优化仿真环节等工作，帮助客户大幅节省存储成本，算法训练效率显著提升，实现降本增效。

三、乐高式、开放化——高效构建自动驾驶研发平台的行业新解

华为云汽车行业解决方案负责人赵刚谈到：华为云坚持“生态开放”的理念，深度联合禾多科技、51WORLD、星尘数据、易图通等合作伙伴，共同发布“乐高式”自动驾驶研发平台解决方案（以下简称“乐高式”解决方案），帮助客户最快 2 周即可独立完成一套自动驾驶研发平台的搭建。

本次发布的解决方案依托华为云丰富的云服务及生态伙伴在自动驾驶领域的经验沉淀，赋能客户打通数据闭环流程，并联合伙伴在全国建设数据接入点，传输效率最高提升 3 倍、实现当日上云；软硬件协同优化，多机多卡训练效率提升 50%；支持云原生集群化部署，调度性能提升 30%；支持数据加密、合规治理，保障业务安全合规。

华为云自动驾驶业务研发平台以开源代码库 Ploto 为门户，由安全合规、路测数据管理、AI 算法训练、场景仿真、场景库交易、量产车联网及平台管理等 7 个模块组成，支持 3 种业务部署模式。华为云及伙伴们希望通过“乐高式、模块化”的简单操作，来帮助不同诉求的客户实现自动驾驶研发平台快速构建的目标。

模式 1：模块按需构建

“乐高式”解决方案自身具备“按需搭建，灵活组合”的能力，适用于对部分研发模块有诉求的客户，最少只需 9 个标准 API 便可快速与自有研发平台对接上云。

模式 2：E2E 快速构建

对于有端到端构建研发平台诉求的客户，“乐高式”解决方案提供一站式的服务，帮助用户基于参考代码快速构建。

模式 3：自有专业软件服务商集成

相比 SaaS 化自动驾驶研发平台，华为云提供标准 API，支持客户自选如标注、仿真等环节的专业软件服务商快速集成。

目前《基于Ploto构建自动驾驶平台》已上线华为云官网，快来体验吧！

关注，第一时间了解华为云新鲜技术~

摘要：MindStudio提供精度比对功能，支持Vector比对能力。

本文分享自华为云社区《【MindStudio训练营第一季】MindStudio 高精度对比随笔》，作者：Tianyi_Li。

训练场景下，迁移原始网络 (如TensorFlow、PyTorch) ，用于NPU上执行训练，网络迁移可能会造成自有实现的算子运算结果与用原生标准算子运算结果存在偏差。推理场景下， ATC模型转换过程对模型进行优化，包括算子消除、算子融合算子拆分，这些优化也可能会造成自有实现的算子运算结果与原生标准算子(如TensorFlow、ONNX、 Caffe ) 运算结果存在偏差。

为了帮助开发人员快速解决算子精度问题，需要提供自有实现的算子运算结果与业界标准算子运算结果之间进行精度差异对比的工具。

对策:

精度比对工具能够帮助开发人员定位本次任务两个网络间的精度差异。准备好昇腾腾AI处理器运行生成的dump教据与Ground Truth数据 (基于GPU/CPU运行生成的数据)后，即可进行不同算法评价指标的数据比对。

MindStudio提供精度比对功能，支持Vector比对能力，支持下列算法：

余弦相似度
最大绝对误差
累积相对误差
欧氏相对距离
KL散度…

精度比对根据推理/训练和不同的框架分为多个比对场景。

原始模型数据即为原始网络在GPU/CPU侧生成的数据，主要依赖原始框架中的源生能力，将模型中每一个算子节点的输入输出数据进行保存。

NPU模型数据即为通过对原始模型的迁移或训练在县腾A处理器上得到的数据，主要依赖华为侧提供对应用推理及训练提供的Dump能力，将模型中每一个算子节点的输入输出数据进行保存。

由于MindStudio精度比对工具的使用约束，数据需要满足以下格式:

原始模型数据准备

以TensorFlow为例

在进行TensorFlow模型生成npy数据前，您需要已经有一套完整的、可执行的、标准的TensorFlow模型应用工程。然后利用TensorFlow官方提供的debug工具tfdbg调试程序，从而生成npy文件。通常情况下，TensorFlow的网络实现方式主要分为Estimator模式和session.run模式，具体操作如下:

1.修改tf训练脚本，添加debug选项设置

2.执行推理或训练脚本，任务运行到前面debug配置后暂停

3.进入调试命令行交互模式后,

3.1 输入run命令，训练会往下执行一个step
3.2 执行lt >tensor name将所有tensor的名称暂存到文件里，在另一个窗口，在Linux命令下执行下述命令，用以生成在tfdbg命令行执行的命令:

3.3 将上一步生成的tensor name cmd.txt文件内容粘贴执行，即可存储所有npy文件，实现训练数据的Dump。

注: 更加详细操作见《CANN开发辅助工具指南》中“精度比对工具使用指南”章节。

NPU模型数据准备

以推理场景为例

推理场景数据准备一NPU的融合后推理数据NPU采用AscendCL完成离线推理:

1.在代码中调用acllnit(“https://www.xujun.org/acl.json”)

acl.json的文件内容如下:

2.运行推理应用，生成dump数据

以训练场景为例

训练场景数据准备-NPU的迁移后网络训练数据

以TensorFlow为例，步骤如下：

1.设置“DUMP GE GRAPH=2”生成计算图文件，同时修改训练脚本，开启dump功能

2.执行训练脚本，生成dump数据和计算图文件

计算图文件:“ge”开头的文件，存储在训练脚本所在目录
dump数据文件: 生成在dump path指定的目录下，即(dump path)/time)/(deviceid)/(model name)/(model id)/(data index) 。

3.选取计算图文件

可使用grep lterator* Build.txt命令快速查找出的计算图文件名称，如ge proto 00005 Build.txt.

4.选取dump数据文件

打开上述计算图文件，找出第一个graph中的name字段，即为dump文件存放目录名称。

精度对比工具使用方法

创建对比任务

将准备好的标准数据文件与待比对数据文性作为输入文件，并配置对应的离线模型文件，通过对文件内所有参与计算的算子输入与输出进行精度比对。

整网比对在MindStudio界面菜单栏洗择“Ascend > Model Accuracy Analvzer > New Task菜单，进入比对界面。

整网对比结果

整网比对结果主要分为四大展示模块:

整网对比结果表；
精度散点图;
模型可视化:
精度专家建议

精度比对工具本身只提供自有实现算子在昇腾AI处理器上的运算结果与业界标准算子的运算结果的差异比对功能，而输出的比对结果需要用户自行分析并找出问题。而对结果的分析工作对于用户来说也是一大难点，而专家系统工具为用户提供精度比对结果的结果分析功能，有效减少用户排查问题的时间。只需在比对操作配置任务时勾选“Advisor”选项，系统则会在比对完成后自动进行结果文件的分析，并输出优化建议。

当前支持的分析检测类型有：FP16溢出检测、输入不一致检测、整网一致性检测（整网一致性检测包括：问题节点检测、单点误差检测和一致性检测三个小点）

这里特别说明下FP16溢出检测，针对比对数据中数据类型为FP16的数据，进行溢出检测。如果存在溢出数据，输出专家建议，示例图如下所示。

单算子对比

可针对整网任务中的某个算子进行单算子比对，分析某个算子的具体精度差异。

使用约束

精度比对功能不支持打开多个工程同时进行比对，可以先完成一个比对程序后再进行下一个。
精度比对支持的dump数据的类型：

特别说明

dump文件无法通过文本工具直接查看其内容，为了查看dump文件内容，需要用脚本将dump文件转换为numpy格式文件后，再通过numpy官方提供的能力转为txt文档进行查看。脚本在/home/HwHiAiUser/Ascend/ascend-toolkit/latest/tools/operator_cmp/compare目录，名为msaccucmp.py。举例用法如下：

调用Python，转换numpy文件为txt文件的完整示例如下：

但转换为.txt格式文件后，维度信息、Dtype均不存在。详细的使用方法请参考numpy官网介绍。

总结

精度对比总计分为环境准备、数据准备和对比三步。

数据准备要根据推理场景和训练场景分别分析：

推理场景：准备第三方框架原始模型的npy数据文件与离线模型的dump数据文件。
训练场景：准备基于GPU运行生成的第三方框架原始训练网络npy数据文件与基于昇腾AI处理器运行生成的训练网络dump数据和计算图文件。

准备后上述步骤，可进行对比：

执行整网比对操作。
开启MindStudio的“Ascend > Model Accuracy Analyzer”功能，将准备好的比对数据文件配置到对应参数下并配置具体比对参数。
MindStudio执行比对操作并输出比对结果。
比对结果专家建议（可选）。请参见比对结果专家建议。
根据分析结果定位具体问题算子。
执行单算子比对操作。
分析单算子具体问题。

最后说下Tensor比对，Tensor对比提供整网比对和单算子比对两种精度比对方式，需要根据比对场景选择比对方式。其中，整网比对：将准备好的标准数据文件与待比对数据文件作为输入文件，通过对文件内所有参与计算的算子进行精度比对。而单算子比对：在整网比对的基础上指定具体算子名，对单个算子进行详细数据的比对。

个人认为，精度对比这是一个需要时间、精力和经验的操作，要充分利用好MindStudio工具，或查文档，或提问，可大大降低我们的工作量，提高效率。但是不得不说，这是需要一定经验的，还是要多看多学习，多试多问啊。

关注，第一时间了解华为云新鲜技术~

前言

链路追踪是每个微服务架构下必备的利器，go-zero 当然早已经为我们考虑好了，只需要在配置中添加配置即可使用。

关于 go-zero 如何追踪的原理追溯，之前已经有同学分享，这里我就不再多说，如果有想了解的同学去 https://sigusoft.com/s/hJEWcWc3PnGfWfbPCHfM9g 这个链接看就好了。默认会在 api 的中间件与 rpc 的 interceptor 添加追踪，如果有不了解 go-zero 默认如何使用默认的链路追踪的，请移步我的开源项目 go-zero-looklook 文档 https://github.com/Mikaelemmmm/go-zero-looklook/blob/main/doc/chinese/12-%E9%93%BE%E8%B7%AF%E8%BF%BD%E8%B8%AA.md。

今天我想讲的是，除了 go-zero 默认在 api 的 middleware 与 rpc 的 interceptor 中帮我们集成好的链路追踪，我们想自己在某些本地方法添加链路追踪代码或者我们想在 api 发送一个消息给 mq 服务时候想把整个链路包含 mq 的 producer、consumer 穿起来，在 go-zero 中该如何做。

场景

我们先简单讲一下我们的小 demo 的场景，一个请求进来调用 api 的方法，在 Login 方法中先调用 rpc 的方法，之后在调用 api 本地的方法，紧接着调用传递消息到 mq 服务。

go-zero 默认集成了 jaeger、zinpink，这里我们就以 jaeger 为例

我们希望看到的链路是

2、rpc 中的代码

3、mq 中的代码

代码详解

1、go-zero 默认集成

当一个请求进入 api 后，我们可以在 go-zero 源码中查看到 https://github.com/zeromicro/go-zero/blob/master/rest/engine.go#L92。go-zero 已经在 api 的 middleware 中帮我们添加了第一层 trace，当进入 Login 方法内，我们调用了 rpc 的方法，通过 go-zero 的源码 https://github.com/zeromicro/go-zero/blob/master/zrpc/internal/rpcserver.go#L55 可以看到在 rpc 的 interceptor 也默认帮我们添加好了，这两层都是 go-zero 默认帮我们做好的。

2、本地方法

当调用完 rpc 的之后，api 调用了本地的，如果我们想在整个链路上体现出来调用了本地方法，那默认的 go-zero 是没有帮我们做的，需要我们手动来添加。

我们通过上面代码拿到 tracer，ctx 之后开启一个 local 的 span，因为 start 时候会从 ctx 获取父 span 所以会将 local 方法与 Login 串联起父子调用关系，这样就将本次操作加入了这个链路

3、mq 的 producer 到 mq 的 consumer

我们在mq传递中如何串联起来这个链路呢？也就是形成。

想一下原理，虽然跨越了网络，api 可以通过传递，rpc 可以通过传递，那么 mq 是不是也可以通过、传递就可以了，按照这个想法来看下我门的代码。

首先获取到了这个全局的，然后开启一个的，跟方法一样，我们开启的时候也是通过获取到上一级父级，这样就可以将的与形成父子调用关系，那我们想将的与 mq 的中的形成调用父子关系怎么做？我们将的注入到中，这里我们通过 mq 的将发送给，发送完成我们我们的，那么的这层链路完成了。

随后我们来看在接收到消息之后怎么做的。

接收到消息后反序列化出来，然后通过取出来注入的，在通过、创建的，这样就是的子，就形成了调用链路关系，最终我们得到的关系就是

项目地址

go-zero 微服务框架：https://github.com/zeromicro/go-zero

https://gitee.com/kevwan/go-zero

go-zero 微服务最佳实践项目：https://github.com/Mikaelemmmm/go-zero-looklook

欢迎使用并 star 支持我们！

微信交流群

关注『微服务实践』公众号并 交流群 获取社区群二维码。

一

在Java的平台里，其实是可以执行其他的语言的。包括且不仅限于jvm发展出来的语言。

有的同学可能会说，在java项目里执行其他语言，这不吃饱了撑着么，java体系那么庞大，各种工具一应俱全，放着好好的java不写，还要去执行其他语言干嘛。

写java的都知道，java是需要事先编译的，这意味着你很难去在运行中改变编译好的class信息，除非你用字节码等技术栈，但是这也是需要很大的成本的。要想在运行中很方便的改变业务逻辑，其实用java去执行其他的脚本语言是一个好办法。况且有的脚本语言有着比java更简洁的语法特性。

有兴趣的小伙伴也可以看看之前的这篇文章：Java 项目有可能做到所有的代码逻辑均可热部署吗？

二

在java中执行其他语言，可能你会觉得这应该很复杂，需要去学习每种语言包相关的api。

笔者是开源框架LiteFlow的作者，在规则引擎LiteFlow中实践并支持了许多的其他语言，如groovy，js，python，lua等。

我可以负责任的说，在Java平台中调用其他脚本语言，其实一点都不复杂，你无需关心每种语言的实际api。

这一切都归功于一个规范：。

相信有大部分人没听过这个Java平台的规范。

JSR223规范最初在Java6平台被提出，提供了一套标准的API为脚本语言的执行提供了内置支持。

也就是说，你只要熟悉这一套API就能执行大部分的脚本语言。

而且这套API的使用也是非常方便的，几个核心方法仔细看个10分钟就能明白如何使用。

三

来个最简单的例子：

上述代码演示的是用JSR223 API去执行javascript语言。值得一提的是，java内置了javascript引擎，你无需引入任何第三方包依赖就可以获得这个引擎。

整个过程分4块，分别是获得引擎，脚本编译，绑定java参数，执行。

在实际业务中，建议在系统启动的时候去编译脚本，然后把编译好的脚本对象对象给缓存起来，因为编译过程相对比较耗时，运行时每次去编译是个糟糕的设计。

如果在运行中改变了脚本，只需要重新去编译这个脚本并缓存其编译后的对象即可。

你只需要掌握以上代码，那几乎就已经掌握了JSR223规范的使用了。是不是很简单？

四

如果你想换成groovy脚本语言，那你需要依赖第三方依赖

然后在上述的代码里获得引擎这块换成groovy即可：

如果你想换成python，需要依赖第三方依赖

然后在上述的代码里获得引擎这块换成python即可：

看到这，是不是对利用规范如何执行脚本恍然大悟了呢。

五

其实现在很多的语言在java平台都推出了自己的java三方执行依赖包，而且很多的包都支持了JSR223规范。只要支持了JSR223规范的语言，都可以利用上述的代码来执行。

JSR223规范的API可以支持java和其他语言的绑定和互通，一个java对象通过bindings对象也是可以传到脚本语言中的，在脚本语言中，你可以获得java的对象，来进行调用其方法和进行逻辑计算。

不过不同的语言调用操作符也许有所不同，比如groovy，javascript都是通过点操作符，和java很像，笔者在LiteFlow里新支持了Lua脚本，Lua脚本的对java对象的操作符是冒号。所以当你的项目支持相关的脚本语言之前，你先要熟悉下相关语言的语法。

六

用脚本语言来担当java平台中经常需要变动的部分是一个不错的选择。关键原因是脚本语言的编译，执行完全是动态的，这意味着你可以在java运行中改变脚本，重新编译，并执行。利用此特性来进行变相的热部署。

LiteFlow就是这样一款能够让你用多种脚本语言来定义你逻辑的规则引擎框架，这其中也利用了JSR223的规范API，不仅能用脚本来编写逻辑，还能进行规则编排。

项目官网:

https://liteflow.yomahub.com

gitee托管仓库：

https://gitee.com/dromara/liteFlow

希望大家都能从JSR223规范中找到一些设计你们相关业务系统的灵感。

作者：京东云质量部

背景

随着前端技术发展，已经转变为数据绑定为主流的框架方式，与后端服务一样，前端代码实现也会涉及相互依赖，引用这些场景，那么应该如何准确的评估前端代码改动的影响范围？依赖开发评估？依靠经验评估？或者直接前端自动化全回归？手工测试全回归？显然以上的策略都不是最优策略，本文叙述了通过对前端代码进行静态分析，找到改动文件影响的功能范围，从实现了一种前端精准测试的思路。

如何进行精准分析

前端对外可直接感知的就是页面，最终目标是要确定影响哪个功能。整个前端精准测试划分为4步：

第一步，确定影响的页面。

第二步，确定影响的功能。

第三步，根据分析结果，找到对应的自动化用例集合，并触发运行

第四步，对比前端代码增量覆盖率，确认改动覆盖完成

前端页面与路由直接相关，从路由入手，建立路由与展示页面的关系，再依据入口文件的import关系，建立前端代码文件依赖树，再通过git diff对比找到改动的文件，从而反查到影响的前端页面。

精准分析实现

设计思路

解析路由文件，建立路由文件中每个菜单的依赖树，从而根据改动文件反查影响页面

实现逻辑

鉴于上述设计思路，结合目前技术支撑现状及快速实验的目标，开发了前端精准分析的第一版方案。

（路由文件分析暂时未找到规律，且实际场景中，路由文件变更不会频繁，维护成本不高，所以此步骤暂由人工维护）

关键逻辑：文件依赖树的分析及存储

应用

webhook自动触发分析

在代码平台上配置webhook触发分析接口，即可实现代码提交，自动触发分析

平台手动触发分析

规划

目前平台仅仅实现了前端精准测试4步中第一步的80%（路由与入口文件的关联还未实现自动分析），推荐仅仅到了页面级别，还未达到按钮级别，此处还需要再研究一下前端开发的相关技术，找到自动解析路由的方法。第二步计划尝试借助istanbul前端覆盖率工具，做一下增量覆盖率对比，保证手动回归可覆盖改动。

作者：李玉亮

引言

数据库事务与大多数后端软件开发人员的工作密不可分，本文从事务理论、事务技术、事务实践等方面对常用的相关事务知识进行整理总结，供大家参考。

事务理论介绍

事务定义

在数据库管理系统中，事务是单个逻辑或工作单，有时由多个操作组成，在数据库中以一致模式完成的逻辑处理称为事务。一个例子是从一个银行账户转账到另一个账户：完整的交易需要减去从一个账户转账的金额，然后将相同的金额添加到另一个账户。

事务特性

原子性( atomicty)

事务中的全部操作在数据库中是不可分割的，要么全部完成，要么全部不执行。

一致性(consistency)

事务的执行不能破坏数据库数据的完整性和一致性。一致性指数据满足所有数据库的条件，比如字段约束、外键约束、触发器等，事务从一致性开始，以一致性结束。

隔离性( isolation)

事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务是透明的。

持久性(durability)

对于提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障。

注：DBMS一般采用日志来保证事务的原子性、一致性和持久性。

事务隔离级别

并发事务带来的问题

不可重复读的重点是数据修改场景，幻读的重点在于新增或者删除场景。

事务隔离级别

SQL92标准定义了4种隔离级别的事务

大多数数据库系统如oracle的默认隔离级别都是 Read committed，mysql默认为可重复读，InnoDB 和 XtraDB 存储引擎通过多版并发控制（MVCC，Multivesion Concurrency Control）解决了幻读问题，Repeatable read 是 Mysql 默认的事务隔离级别，其中 InnoDB主要通过使用 MVVC 获得高并发，使用一种被称为 next-key-locking 的策略来避免幻读。

事务模型

事务提交模型

显式事务：又称自定义事务，是指用显式的方式定义其开始和结束的事务，当使用start transaction和 commit语句时表示发生显式事务。

隐式事务：隐式事务是指每一条数据操作语句都自动地成为一个事务，事务的开始是隐式的，事务的结束有明确的标记。即当用户进行数据操作时，系统自动开启一个事务，事务的结束则需手动调用 commit或 rollback语句来结束当前事务，在当前事务结束后又自动开启一个新事务。

自动事务：自动事务是指能够自动开启事务并且能够自动结束事务。在事务执行过程中，如果没有出现异常，事务则自动提交；当执行过程产生错误时，则事务自动回滚；一条SQL语句一个事务。

事务编程模型

本地事务模型：事务由本地资源管理器来管理。简单理解就是直接使用JDBC的事务API。

编程式事务模型：事务通过JTA以及底层的JTS实现来管理，对于开发人员而言，管理的是“事务”，而非“连接”。简单理解就是使用事务的API写代码控制事务。

示例一、JTA的API编程

示例二、Spring的事务模版

声明式事务：事务由容器进行管理，对于开发人员而言，几乎不管理事务。简单理解就是加个事务注解或做个AOP切面。

比较

附：SQL相关小知识

SQL的全称：Structured Query Language。中文翻译：结构化查询语言。

关系数据库理论之父：埃德加·科德。是一位计算机的大牛,他凭借关系数据模型理论获得了图灵奖，核心思想就两个：关系代数和关系演算，发表了一篇牛逼的论文“A Relational Model of Data for Large Shared Data Banks”。

写第一句SQL的人：Donald D. Chamberlin 和 Raymond F. Boyce。埃德加·科德的两个同事Donald D. Chamberlin和Raymond F. Boyce根据论文，发明出了简单好用的SQL语言。

SQL 标准：有两个主要的标准，分别是 SQL92 和 SQL99 。92 和 99 代表了标准提出的时间。除了 SQL92 和 SQL99 以外，还存在 SQL-86、SQL-89、SQL:2003、SQL:2008、SQL:2011 和 SQL:2016 等其他的标准。

事务技术介绍

以Spring+Mybatis+JDBC+Mysql为例，常见的事务类请求的调用链路如下图。请求调用应用服务，应用服务中开启事务并进行业务操作，操作过程中调用Mybatis进行数据库类操作，Mybatis通过JDBC驱动与底层数据库交互。

因此接下来先按Mysql、JDBC、Mybatis、Spring来介绍各层的事务相关知识；最后进行全链路的调用分析。

Mysql事务相关

Mysql逻辑架构

架构图如下(InnoDB存储引擎)：

MySQL事务是由存储引擎实现的，MySQL支持事务的存储引擎有InnoDB、NDB Cluster等，其中InnoDB的使用最为广泛，其他存储引擎如MyIsam、Memory等不支持事务。

Mysql的事务保证

Mysql的4个特性中有3个与 WAL（Write-Ahead Logging，先写日志，再写磁盘）有关系，需要通过 Redo、Undo 日志来保证等，而一致性需要通过DBMS的功能逻辑及原子性、隔离性、持久性共同来保证。

MVCC

MVCC最大的好处是读不加锁，读写不冲突，在读多写少的系统应用中，读写不冲突是非常重要的，可极大提升系统的并发性能，这也是为什么现阶段几乎所有的关系型数据库都支持 MVCC 的原因，目前MVCC只在 Read Commited 和 Repeatable Read 两种隔离级别下工作。它是通过在每行记录的后面保存两个隐藏列来实现的，这两个列，一个保存了行的创建时间，一个保存了行的过期时间，存储的并不是实际的时间值，而是系统版本号。MVCC在mysql中的实现依赖的是undo log与read view。

read view

在 MVCC 并发控制中，读操作可以分为两类: 快照读（Snapshot Read）与当前读（Current Read）。

•快照读：读取的是记录的快照版本（有可能是历史版本）不用加锁（select）。

•当前读：读取的是记录的最新版本，并且当前读返回的记录，都会加锁，保证其他事务不会再并发修改这条记录(select… for update 、lock或insert/delete/update）。

redo log

redo log叫做重做日志。mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Buffer Pool(缓冲池)里，当作缓存来用以提升性能，使用后台线程去做缓冲池和磁盘之间的同步。那么问题来了，如果还没来及的同步的时候宕机或断电了怎么办？这样会导致丢部分已提交事务的修改信息！所以引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，系统重启之后再读取redo log恢复最新数据。redo log是用来恢复数据的，保障已提交事务的持久化特性。

undo log

undo log 叫做回滚日志，用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息。undo log主要记录的是数据的逻辑变化。为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。undo log 记录事务修改之前版本的数据信息，假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。undo log是用来回滚数据的，保障未提交事务的原子性。

示例

假设 F1～F6 是表中字段的名字，1～6 是其对应的数据。后面三个隐含字段分别对应该行的隐含ID、事务号和回滚指针，如下图所示。

具体的更新过程如下：

假如一条数据是刚 INSERT 的，DB_ROW_ID 为 1，其他两个字段为空。当事务 1 更改该行的数据值时，会进行如下操作，如下图所示。

•用排他锁锁定该行，记录 Redo log；

•把该行修改前的值复制到 Undo log，即图中下面的行；

•修改当前行的值，填写事务编号，并回滚指针指向 Undo log 中修改前的行。

如果再有事务2操作，过程与事务 1 相同，此时 Undo log 中会有两行记录，并且通过回滚指针连在一起，通过当前记录的回滚指针回溯到该行创建时的初始内容，如下图所示，这里的undolog不会一直增加，purge thread在后面会进行undo page的回收，也就是清理undo log。

JDK事务相关

JDBC规范

java定义了统一的JDBC驱动API，各数据库厂商按规范实现。jdbc驱动相关包在java.sql包下：

使用示例：

JDBC驱动注册机制

之前需要调用Class.forName或其他方式显式加载驱动，现在有了SPI机制后可不写。

JTA规范

JTA 全称 Java Transaction API，是 X/OPEN CAE 规范中分布式事务 XA 规范在 Java 中的映射，是 Java 中使用事务的标准 API，同时支持单机事务与分布式事务。

作为 J2EE 平台规范的一部分，JTA 与 JDBC 类似，自身只提供了一组 Java 接口，需要由供应商来实现这些接口，与 JDBC 不同的是这些接口需要由不同的供应商来实现。

相关代码在jta jar的javax.transaction包下。

Mybatis事务相关

Mybatis核心是提供了sql查询方法、结果集与应用方法及对象之间的映射关系，便于开发人员进行数据库操作。

整体模块如下：

各模块与下面的各子包一一对应：

Mybatis执行的核心类如下：

Mysql的核心入口类为SqlSession，事务相关的操作通过TransactionFactory来处理，可选择使用Spring事务(SpringManagedTransaction)还是内置事务管理。

事务相关的控制处理可见SqlSessionInterceptor类，主要逻辑如下：

源码见下：

Spring事务相关

spring事务相代码主要位于spring-tx包，如TransactionInterceptor。spring-jdbc包中有spring jdbc对事务的相关支持实现，如JdbcTransactionManager。核心类如下图，主要有三大部分：事务管理器（TransactionManager)、事务定义（TransactionDefinition)、事务状态（TtransactionStatus)，这也是经常见的一种架构思维，将功能模块抽象为配置态定义、运行态实例和执行引擎，在开源组件jd-easyflow(
https://github.com/JDEasyFlow/jd-easyflow) 中也是此种设计理念。从下面的类图可以Spring的设计非常有层次化，很有美感。

Spring编程式事务

常用类为TransacitonTemplate，执行逻辑为：获取事务状态->在事务中执行业务->提交或回滚，源码见下：

Spring声明式事务

声明式事务实现原理就是通过AOP/动态代理。

在Bean初始化阶段创建代理对象：Spring容器在初始化每个单例bean的时候，会遍历容器中的所有BeanPostProcessor实现类，并执行其
postProcessAfterInitialization方法，在执行AbstractAutoProxyCreator类的postProcessAfterInitialization方法时会遍历容器中所有的切面，查找与当前实例化bean匹配的切面，这里会获取事务属性切面，查找@Transactional注解及其属性值，然后根据得到的切面创建一个代理对象，默认是使用JDK动态代理创建代理，如果目标类是接口，则使用JDK动态代理，否则使用Cglib。

在执行目标方法时进行事务增强操作：当通过代理对象调用Bean方法的时候，会触发对应的AOP增强拦截器，声明式事务是一种环绕增强，对应接口为MethodInterceptor，事务增强对该接口的实现为TransactionInterceptor，类图如下：

事务拦截器TransactionInterceptor在invoke方法中，通过调用父类TransactionAspectSupport的invokeWithinTransaction方法进行事务处理，包括开启事务、事务提交、异常回滚。

声明式事务有5个配置项，说明如下：

事务配置一、事务隔离级别

配置该事务的隔离级别，一般情况数据库或应用统一设置，不需要单独设值。

事务配置二、事务传播属性

事务传播属性是spring事务模块的一个重要属性。简单理解，他控制一个方法在进入事务时，在外层方法有无事务的场景下，自己的事务的处理策略，如是复用已有事务还是创建新事务。

spring支持的传播属性有7种，如下：

事务配置三、事务超时

事务的超时设置是为了解决什么问题呢？

在数据库中，如果一个事务长时间执行，这样的事务会占用不必要的数据库资源，还可能会锁定数据库的部分资源，这样在生产环境是非常危险的。这时就可以声明一个事务在特定秒数后自动回滚，不必等它自己结束。

事务超时时间的设置

由于超时时间在一个事务开启的时候创建的，因此，只有对于那些具有启动一个新事务的传播行为（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、ROPAGATION_NESTED），声明事务超时才有意义。

事务配置四、事务只读

如果一个事务只对数据库进行读操作，数据库可以利用事务的只读特性来进行一些特定的优化。我们可以通过将事务声明为只读，让数据库对我们的事务操作进行优化。

事务配置五、回滚规则

回滚规则，就是程序发生了什么会造成回滚，这里我们可以进行设置RuntimeException或者Error。

默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚。

我们可以声明事务在遇到特定的异常进行回滚。同样，我们也可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。

声明式事务失效的场景

事务同步管理器

Spring中有一个事务同步管理器类
TransactionSynchronizationManager，它提供了事务提交后处理等相关回调注册的方法。当我们有业务需要在事务提交过后进行某一项或者某一系列的业务操作时候我们就可以使用
TransactionSynchronizationManager。

事务请求处理链路示例

下图为全链路的从应用发起到开启事务，到业务逻辑处理（SQL执行），最后关闭事务的正向链路。

事务实践相关

数据一致性

同一个数据源的操作在一个事务内可保证一致，但实际场景中会因为不同事务或不同数据源（不同关系数据库、缓存或远端服务）而导致数据不能强一致。在CAP理论框架下，我们一般是保证可用性、分区容错性，基于BASE理论达到最终一致性。但如何达到数据的最终一致性需要合理设计。

数据库的提交、缓存的更新、RPC的执行、消息的发送的先后顺序

一般我们以数据库数据为准，先数据库提交，再更新缓存或发送消息，通过异步轮询补偿的方式保证异常情况下的最终一致性。

不建议用法：

1、事务回滚会导致缓存和数据库不一致

2、事务回滚会导致消息接收方收到的数据状态错误

建议用法：

1、先更新数据库，事务提交后再更新缓存或发送消息

2、通过异步异常重试或批处理同步来保证数据的最终一致性

3、核心交易以数据库数据为准

系统健壮性增强，但编程模型复杂一些

长事务

如果事务中有耗时长的SQL或有RPC操作可能会导致事务时间变长，会导致并发量大的情况下数据库连接池被占满，应用无法获取连接资源，在主从架构中会导致主从延时变大。

建议事务粒度尽量小，事务中尽量少包含RPC操作。事务尽量放在下层。

不建议用法

建议用法

这种方式需要应用程序保证多个事务操作的最终一致性，一般可通过异常重试来实现。

事务代码层级

事务该加在哪一层？放在上层的优点是编程简单，放在底层则需要需要在一个事务的操作封装在一起沉淀到底层。

对于传统架构（如下图），建议在DAO层和Manager层加事务。Service层可以有，但重的Service或有rpc的Service操作慎用。

对于领域设计类架构（如下图），从DDD的思想上，建议放在APP层（基础设施不应是领域层关注的），但考虑到长事务问题，不建议放在APP层，更建议优先放在基础设施层，domain的service层也可有。

总结

以上对事务的常用知识进行了总结整理，相关实践规范有的并无完美固定答案，需要结合实际而论，欢迎大家留言沟通！

作者：翟贺龙

一、背景

在计算机领域，涉及性能优化动作时首先应被考虑的原则之一便是使用缓存，合理的数据缓存机制能够带来以下收益：

1.
缩短数据获取路径，热点数据就近缓存以便后续快速读取，从而明显提升处理效率；

2.
降低数据远程获取频次，缓解后端数据服务压力、减少前端和后端之间的网络带宽成本；

从 CPU 硬件的多级缓存设计，到浏览器快速展示页面，再到大行其道的 CDN、云存储网关等商业产品，处处应用了缓存理念。

在公网领域，如操作系统、浏览器和移动端 APP 等成熟产品所具备的缓存机制，极大的消解了网络提供商如电信移动联通、内容提供商如各大门户平台和 CDN 厂商直面的服务压力，运营商的 DNS 才能从容面对每秒亿万级的 DNS 解析，网络设备集群才能轻松承担每秒 Tbit 级的互联网带宽，CDN 平台才能快速处理每秒亿万次的请求。

面对公司目前庞大且仍在不断增长的的域名接入规模，笔者所在团队在不断优化集群架构、提升 DNS 软件性能的同时，也迫切需要推动各类客户端环境进行域名解析请求机制的优化，因此，特组织团队成员调研、编写了这篇指南文章，以期为公司、客户及合作方的前端开发运维人员给出合理建议，优化 DNS 整体请求流程，为业务增效。

本文主要围绕不同业务和开发语言背景下，客户端本地如何实现 DNS 解析记录缓存进行探讨，同时基于笔者所在团队对 DNS 本身及公司网络环境的掌握，给出一些其他措施，最终致力于客户端一侧的 DNS 解析请求规范化。

二、名词解释

1. 客户端

本文所述客户端，泛指所有主动发起网络请求的对象，包括但不限于服务器、PC、移动终端、操作系统、命令行工具、脚本、服务软件、用户 APP 等。

2. DNS

Domain Name System(Server/Service)，域名系统（服务器/服务），可理解为一种类数据库服务；

客户端同服务端进行网络通信，是靠 IP 地址识别对方；而作为客户端的使用者，人类很难记住大量 IP 地址，所以发明了易于记忆的域名如 www.jd.com，将域名和 IP 地址的映射关系，存储到 DNS 可供客户端查询；

客户端只有通过向 DNS 发起域名解析请求从而获取到服务端的 IP 地址后，才能向 IP 地址发起网络通信请求，真正获取到域名所承载的服务或内容。

参考：域名系统域名解析流程

3. LDNS

Local DNS，本地域名服务器；公网接入环境通常由所在网络供应商自动分配（供应商有控制权，甚至可作 DNS 劫持，即篡改解析域名得到的 IP），内网环境由 IT 部门设置自动分配；

通常 Unix、类Unix、MacOS系统可通过 /etc/resolv.conf 查看自己的 LDNS，在 nameserver 后声明，该文件亦支持用户自助编辑修改，从而指定 LDNS，如公网常见的公共 DNS 如谷歌 DNS、114DNS 等；纯内网环境通常不建议未咨询IT部门的情况下擅自修改，可能导致服务不可用；可参考指令结果。

当域名解析出现异常时，同样应考虑 LDNS 服务异常或发生解析劫持情况的可能。

参考：windows系统修改TCP/IP设置（含DNS）；

4. hosts

DNS 系统可以动态的提供域名和IP的映射关系，普遍存在于各类操作系统的hosts文件则是域名和IP映射关系的静态记录文件，且通常 hosts 记录优先于 DNS 解析，即本地无缓存或缓存未命中时，则优先通过 hosts 查询对应域名记录，若 hosts 无相关映射，则继续发起 DNS 请求。关于 Linux 环境下此逻辑的控制，请参考下文 C/C++ 语言 DNS 缓存介绍部分。

所以在实际工作中，常利用上述默认特性，将特定域名和特定 IP 映射关系写到 hosts 文件中（俗称“固定 hosts”），用于绕开 DNS 解析过程，对目标 IP 作针对性访问（其效果与 curl 的-x选项，或 wget 的 -e 指定 proxy 选项，异曲同工）；

5. TTL

Time-To-Live，生存时间值，此概念在多领域适用且可能有不同意义。

本文涉及到 TTL 描述均针对数据缓存而言，可直白理解为已缓存数据的“有效期”，从数据被缓存开始计，在缓存中存在时长超过 TTL 规定时长的数据被视为过期数据，数据被再次调用时会立刻同权威数据源进行有效性确认或重新获取。

因缓存机制通常是被动触发和更新，故在客户端的缓存有效期内，后端原始权威数据若发生变更，客户端不会感知，表现为业务上一定程度的数据更新延迟、缓存数据与权威数据短时不一致。

对于客户端侧 DNS 记录的缓存 TTL，我们建议值为 60s；同时如果是低敏感度业务比如测试、或域名解析调整不频繁的业务，可适当延长，甚至达到小时或天级别；

三、DNS 解析优化建议

1. 各语言网络库对 DNS 缓存的支持调研

以下调研结果，推荐开发人员参考，以实现自研客户端 DNS 缓存。各开发语言对 DNS 缓存支持可能不一样，在此逐个分析一下。

C/C++ 语言

（1）glibc 的 getaddrinfo 函数

Linux环境下的 glibc 库提供两个域名解析的函数：gethostbyname 函数和 getaddrinfo 函数，gethostbyname 是曾经常用的函数，但是随着向 IPv6 和线程化编程模型的转移，getaddrinfo 显得更有用，因为它既解析 IPv6 地址，又符合线程安全，推荐使用 getaddrinfo 函数。

函数原型：

getaddrinfo 函数是比较底层的基础库函数，很多开发语言的域名解析函数都依赖这个函数，因此我们在此介绍一下这个函数的处理逻辑。通过 strace 命令跟踪这个函数系统调用。

1）查找 nscd 缓存（nscd 介绍见后文）

我们在 linux 环境下通过 strace 命令可以看到如下的系统调用

通过 unix socket 接口”/var/run/nscd/socket”连接nscd服务查询DNS缓存。

2）查询 /etc/hosts 文件

如果nscd服务未启动或缓存未命中，继续查询hosts文件，我们应该可以看到如下的系统调用

3）查询 DNS 服务

从 /etc/resolv.conf 配置中查询到 DNS 服务器（nameserver）的IP地址，然后做 DNS 查询获取解析结果。我们可以看到如下系统调用

而关于客户端是优先查找 /etc/hosts 文件，还是优先从 /etc/resolv.conf 中获取 DNS 服务器作查询解析，是由 /etc/nsswitch.conf 控制：

实际通过 strace 命令可以看到，系统调用 nscd socket 之后，读取 /etc/resolv.conf 之前，会读取该文件

4）验证

综上分析，getaddrinfo 函数结合 nscd ，是可以实现 DNS 缓存的。

（2）libcurl 库的域名解析函数

libcurl 库是 c/c++ 语言下，客户端比较常用的网络传输库，curl 命令就是基于这个库实现。这个库也是调用 getaddrinfo 库函数实现 DNS 域名解析，也是支持 nscd DNS 缓存的。

Java

Java 语言是很多公司业务系统开发的主要语言，通过编写简单的 HTTP 客户端程序测试验证 Java 的网络库是否支持 DNS 缓存。测试验证了 Java 标准库中 HttpURLConnection 和 Apache httpcomponents-client 这两个组件。

（1）Java 标准库 HttpURLConnection

测试结果显示 Java 标准库 HttpURLConnection 是支持 DNS 缓存，5 次请求中只有一次 DNS 请求。

（2）Apache httpcomponents-client

测试结果显示 Apache httpcomponents-client 支持 DNS 缓存，5 次请求中只有一次 DNS 请求。

从测试中发现 Java 的虚拟机实现一套 DNS 缓存，即实现在 java.net.InetAddress 的一个简单的 DNS 缓存机制，默认为缓存 30 秒，可以通过 networkaddress.cache.ttl 修改默认值，缓存范围为 JVM 虚拟机进程，也就是说同一个 JVM 进程中，30秒内一个域名只会请求DNS服务器一次。同时 Java 也是支持 nscd 的 DNS 缓存，估计底层调用 getaddrinfo 函数，并且 nscd 的缓存级别比 Java 虚拟机的 DNS 缓存高。

Go

随着云原生技术的发展，Go 语言逐渐成为云原生的第一语言，很有必要验证一下 Go 的标准库是否支持 DNS 缓存。通过我们测试验证发现 Go 的标准库 net.http 是不支持 DNS 缓存，也是不支持 nscd 缓存，应该是没有调用 glibc 的库函数，也没有实现类似 getaddrinfo 函数的功能。这个跟 Go语言的自举有关系，Go 从 1.5 开始就基本全部由 Go(.go) 和汇编 (.s) 文件写成的，以前版本的 C(.c) 文件被全部重写。不过有一些第三方 Go 版本 DNS 缓存库，可以自己在应用层实现，还可以使用 fasthttp 库的 httpclient。

（1）标准库net.http

从测试结果来看，net.http 每次都去 DNS 查询，不支持 DNS 缓存。

（2）fasthttp 库

fasthttp 库是 Go 版本高性能 HTTP 库，通过极致的性能优化，性能是标准库 net.http 的 10 倍，其中一项优化就是支持 DNS 缓存，我们可以从其源码看到

可以参考如下方法使用 fasthttp client 端

（3）第三方DNS缓存库

这个是 github 中的一个 Go 版本 DNS 缓存库

可以参考如下代码，在HTTP库中支持DNS缓存

Python

（1）requests 库

（2）httplib2 库

（3）urllib2 库

Python 测试三种库都是支持 nscd 的 DNS 缓存的(推测底层也是调用 getaddrinfo 函数)，以上测试时使用 HTTP 短连接，都在 python2 环境测试。

总结

针对 HTTP 客户端来说，可以优先开启 HTTP 的 keep-alive 模式，可以复用 TCP 连接，这样可以减少 TCP 握手耗时和重复请求域名解析，然后再开启 nscd 缓存，除了 Go 外，C/C++、Java、Python 都可支持 DNS 缓存，减少 DNS查询耗时。

这里只分析了常用 C/C++、Java、Go、Python 语言，欢迎熟悉其他语言的小伙伴补充。

2. Unix/类 Unix 系统常用 dns 缓存服务：

在由于某些特殊原因，自研或非自研客户端本身无法提供 DNS 缓存支持的情况下，建议管理人员在其所在系统环境中部署DNS缓存程序；

现介绍 Unix/类 Unix 系统适用的几款常见轻量级 DNS 缓存程序。而多数桌面操作系统如 Windows、MacOS 和几乎所有 Web 浏览器均自带 DNS 缓存功能，本文不再赘述。

P.S. DNS 缓存服务请务必确保随系统开机启动；

nscd

name service cache daemon 即装即用，通常为 linux 系统默认安装，相关介绍可参考其 manpage：；

（1）安装方法：通过系统自带软件包管理程序安装，如

（2）缓存管理（清除）：

1.
重启服务清除所有缓存；

2.
清除 hosts 表中的域名缓存（hosts 为域名缓存使用的 table 名称，nscd 有多个缓存 table，可参考程序相关 manpage）

dnsmasq

较为轻量，可选择其作为 nscd 替代，通常需单独安装

（1）安装方法：通过系统自带软件包管理程序安装，如

（2）核心文件介绍（基于 Dnsmasq version 2.86，较低版本略有差异，请参考对应版本文档如 manpage 等）

（3）/etc/default/dnsmasq 提供六个变量定义以支持六种控制类功能

（4）/etc/dnsmasq.d/ 此目录含 README 文件，可参考；目录内可以存放自定义配置文件

（5）/etc/dnsmasq.conf 主配置文件，如仅配置 dnsmasq 作为缓存程序，可参考以下配置

（6）缓存管理（清除）：

1.
推荐方式，无需重启服务

2.
或

3.
或

（7）官方文档：https://thekelleys.org.uk/dnsmasq/doc.html

3. 纯内网业务取消查询域名的AAAA记录的请求

以 linux 操作系统为例，常用的网络请求命令行工具常常通过调用 getaddrinfo() 完成域名解析过程，如 ping、telnet、curl、wget 等，但其可能出于通用性的考虑，均被设计为对同一个域名每次解析会发起两个请求，分别查询域名 A 记录（即 IPV4 地址）和 AAAA 记录（即 IPV6 地址）。

因目前大部分公司的内网环境及云上内网环境还未使用 ipv6 网络，故通常 DNS 系统不为内网域名添加 AAAA 记录，徒劳请求域名的 AAAA 记录会造成前端应用和后端 DNS 服务不必要的资源开销。因此，仅需请求内网域名的业务，如决定自研客户端，建议开发人员视实际情况，可将其设计为仅请求内网域名 A 记录，尤其当因故无法实施本地缓存机制时。

4. 规范域名处理逻辑

客户端需严格规范域名/主机名的处理逻辑，避免产生大量对不存在域名的解析请求（确保域名从权威渠道获取，避免故意或意外使用随机构造的域名、主机名），因此类请求的返回结果（NXDOMAIN）通常不被缓存或缓存时长较短，且会触发客户端重试，对后端 DNS 系统造成一定影响。

作者：贾世闻

我们在开发应用后端系统的时候经常要和各种数据库、缓存等资源打交道。这一期，我们聊聊如何访问redis 并将资源池化。

在一个应用后端程序访问redis主要要做的工作有两个，单例和池化。

在后端应用集成redis，我们主要用到以下几个crate:[once_cell](https://github.com/matklad/once_cell)、[redis-rs](https://github.com/redis-rs/redis-rs)、[r2d2](https://github.com/sfackler/r2d2).once_cell 实现单例；redis-rs 是 redis的 rust 驱动；r2d2 是一个池化连接的工具包。本期代码均出现在[fullstack-rs](https://github.com/jiashiwen/fullstack-rs)项目中。[fullstack-rs](https://github.com/jiashiwen/fullstack-rs)是我新开的一个实验性项目，目标是做一个类似[gin-vue-admin](https://github.com/flipped-aurora/gin-vue-admin)的集成开发框架。

redis资源的定义主要是在https://github.com/jiashiwen/fullstack-rs/blob/main/backend/src/resources/redis_resource.rs 中实现的。

一、redis-rs 封装

在实际开发中，我们面对的redis资源可能是单实例也有可能是集群，在这里我们对redis-rs进行了简单封装，便于适应这两种情况。

RedisInstance,定义redis资源的描述，与配置文件相对应。详细的配置描述可以参考 https://github.com/jiashiwen/fullstack-rs/blob/main/backend/src/configure/config_global.rs 文件中 RedisConfig 和 RedisPool 两个 struct 描述。

RedisClient 和 RedisConnection 对redis 的链接进行了封装，用来实现统一的调用接口。

二、基于 r2d2 实现 redis 连接池

以上，基本完成的reids资源的准备工作，下面来实现一个redis链接池。

利用 r2d2 来实现连接池需要实现 r2d2::ManageConnection trait。connect 函数获取连接；is_valid 函数校验连通性；has_broken 判断连接是否崩溃不可用。

gen_redis_conn_pool 函数用来生成一个 redis 的连接池，根据配置文件来指定连接池的最大连接数，最小闲置连接以及连接超时时长。

三、连接池单例实现

在后端开发中，对于单一资源一般采取单例模式避免重复产生实例的开销。下面来聊一聊如果构建一个全局的 redis 资源。

这一部分代码在https://github.com/jiashiwen/fullstack-rs/blob/main/backend/src/resources/init_resources.rs 文件中。

利用 OnceCell 构建全局静态变量。

init_global_redis 函数，用来初始化 GLOBAL_REDIS_POOL 全局静态变量。在一般的后端程序中，资源是强依赖，所以，初始化简单粗暴，要么成功要么 panic。

四、资源调用

准备好 redis 资源后，我们聊聊如何调用。

调用例子在这里https://github.com/jiashiwen/fullstack-rs/blob/main/backend/src/httpserver/service/service_redis.rs

https://github.com/jiashiwen/fullstack-rs/tree/main/backend 这个工程里有从http入口开始到写入redis的完整流程，http server 不在本文讨论之列，就不赘述了，有兴趣的同学可以去github看看。

咱们下期见。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

系统介绍

ModStart 是一个基于 Laravel 模块化极速开发框架。模块市场拥有丰富的功能应用，支持后台一键快速安装，让开发者能快的实现业务功能开发。

系统完全开源，基于 Apache 2.0 开源协议。

功能特性

丰富的模块市场，后台一键快速安装
会员模块通用且完整，支持完整的API调用
大文件分片上传，进度条显示，已上传文件管理
强大的模块扩展功能，所有模块可以无缝集成，支持在线安装、卸载模块
完善的开发助手，实现模块、主题的的一键创建
完善的后台权限管理，支持基于RBAC的权限管理系统
后台管理支持使用手机、平板、PC，无论何时何地都可方便管理
第三方登录（、微信、微博、支付宝、微信小程序）
第三方支付支持（微信、支付宝、支付宝当面付、微信扫码、微信小程序）
第三方云存储支持，支持云储存分片上传（阿里云、百度云、华为云、腾讯云、FTP、七牛云、UCloud、又拍云）
第三方短信支持（阿里云、腾讯云、华为云、百度云、253云通讯、聚合、七牛云、融云、赛邮、UCloud、云片、网易云）

V6.3.0版本更新

2022年12月07日ModStartBlog发布v6.3.0版本，增加了以下9个特性：

[新功能] 任务调度新增上次运行时间设定
[新功能] 任务调度记录调度日志和调度结果
[新功能] 响应新增永久重定向方法 redirectPermanently
[新功能] 补全部分数据库模型文件
[新功能] 文件上传预期错误重传机制
[新功能] 数字动态增长组件，数字动态显示效果
[新功能] UEditorPlus升级2.7.0版本
[Bug修复] 浏览器自适应或尺寸变更时轮播自动更新
[Bug修复] Detail页面为模型时异常问题

模块市场一键安装

系统内置模块市场，有行业应用、插件、云存储、云短信等功能模块，后台支持一键安装、启用、禁用、卸载，可快速搭建属于自己的系统应用。

系统演示与文档

码云仓库：https://gitee.com/modstart/ModStartBlog
Github仓库：https://github.com/modstart/ModStartBlog
系统演示：https://blog.demo.tecmz.com/
下载试用：https://modstart.com/download
开发者文档：https://modstart.com/doc
模块市场：https://modstart.com/store

漏洞描述

Apache ManifoldCF 是一个具有多种连接器的多存储库爬虫框架。

Apache ManifoldCF 2.23及之前版本中由于 ActiveDirectoryAuthority.java 类没有对用户的用户名或域字符串进行有效过滤，导致 Apache ManifoldCF 的 ActiveDirectory 和 Sharepoint ActiveDirectory 权限连接器存在 LDAP 注入漏洞。攻击者可在用户进行 LDAP 查询期间注入恶意搜索字符进行 LDAP 注入攻击，从而获取对 Apache ManifoldCF 系统目录的未授权访问权限，查看或修改系统目录中的敏感文件信息或造成程序崩溃。

漏洞名称 Apache ManifoldCF <=2.23 存在 LDAP 注入漏洞漏洞类型 LDAP查询中使用的特殊素转义处理不恰当（LDAP注入）发现时间 2022-12-07 漏洞影响广度极小 MPS编号 MPS-2022-65273 CVE编号 CVE-2022-45910 CNVD编号 –

影响范围

org.apache.manifoldcf:mcf-activedirectory-connector@(-∞, 2.24)

org.apache.manifoldcf:mcf-sharepoint-connector@(-∞, 2.24)

修复方案

升级org.apache.manifoldcf:mcf-activedirectory-connector到 2.24 或更高版本

升级org.apache.manifoldcf:mcf-sharepoint-connector到 2.24 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65273

https://nvd.nist.gov/vuln/detail/CVE-2022-45910

https://github.com/apache/manifoldcf/commit/7df176b2a73ebea2dd3e319c7e9fc68bc162bab8

https://github.com/apache/manifoldcf/commit/4bc75e6aa0cefce5e4e3c45680d543bff5f3ed73

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

一股“神秘力量”使得知名前端框架 Vue 的周 npm 下载量激增十倍，以至于 Vue 创始人尤雨溪发推解释：“我也不知道谁搞出来的，请搞出这事的人赶紧修复吧，这样会搞得统计数据毫无意义。”

反而是另一款前端 UI 框架 Svelte 也经历了过山车式的体验，周下载量先是从日常 40 万飙升到 2800 万，然后又狠狠地下跌，但仍未恢复至正常水平。

但导致 Vue npm 下载量暴增的原因尚未有明确的定论，只能等下一轮 npm 统计数据或者官方公告，我们会密切跟踪后续发展。

近日，平头哥半导体有限公司（以下简称“平头哥”）签署openKylin社区CLA（Contributor License Agreement 贡献者许可协议），正式加入openKylin开源社区。

平头哥成立于2018年9月19日，是阿里巴巴集团的全资半导体芯片业务主体。作为高性能RISC-V处理器的先行者，平头哥不断拓展RISC-V性能、应用与生态的边界，打造出从低功耗、低成本到高性能、高能效的丰富RISC-V处理器产品家族，广泛应用于边缘计算、无线通讯、工业控制、通用MCU等30多个领域及应用场景。

在加入openKylin社区后，平头哥积极参与社区合作，推动openKylin与RISC-V架构融合发展。目前，平头哥已与openKylin社区合作，完成了平头哥曳影 1520 SoC与openKylin操作系统的适配工作，并基于社区软件源构建了镜像版本。

该版本包含近1600个软件包，集成了一系列稳定版本的基础库和图形开发库，能够顺畅运行UKUI桌面环境。此外，系统包含丰富的openKylin自研软件和第三方开源软件，如浏览器、视频、音频和文档编辑等，可以满足用户的基本使用需求。

社区会员持续招募中

审核：openKylin

为推动社区繁荣发展，打造开源操作系统创新生态， openKylin（开放麒麟）社区根据领域划分了不同的SIG组，并积极开展各种技术研究和创新。其中，11月份社区新增SIG小组4个，共有56个SIG组在运行，接下来，让我们一起盘点11月份openKylin社区SIG组的最新技术进展：

社区新增SIG

InputSolution SIG

致力于组建openKylin社区输入法解决方案框架特殊兴趣小组以及输入法解决方案开源社区，推进输入法解决方案框架在社区落地并维护。

RTHypervisor SIG

致力于实时虚拟化技术的研究，目前主要包括jailhouse。提供工控、车载等领域实时控制的虚拟化解决方案。

GPU SIG致力于GPU驱动相关技术研究，包括OpenGL、OpenCL、Vulkan、VDPAU和VAAPI等。提供GPU相关软件包的技术规划、设计、开发、维护和升级服务，共同推动国产GPU技术发展。

Easylosu SIG

负责为开放麒麟开发简单高效的编程语言，致力于让用户以最低的门槛，轻松享受编程的便利，促进编程语言国产化，促进开放麒麟在非开发者群体的推广。

openKylin社区技术进展与成果

一、UKUI SIG

UKUI(Ultimate Kylin User Interface) SIG小组致力于桌面环境相关软件包的规划、维护和升级工作，满足各种设备和用户需求的桌面环境程序，主要包含程序启动器（开始菜单）、用户配置、文件管理、登录锁屏、桌面、网络工具、快捷配置等，为用户提供基本的图形化操作平台。11月进展如下：

推进0.9版本遗留bug修复；
1.0计划剩余需求合入；
推进新增bug的修复，包括：修复定时关机翻译、控制面板设置网络后被最小化、平板切PC窗口三联状态未恢复、插拔HDMI显示器分辨率异常、蓝牙耳机未自动回连、外接4K显示器显示异常、电量即将耗尽时未弹窗、工具箱偶现闪退、锁屏界面无电量状态等bug；
UKUI网站信息更新与新版网站设计稿评审；
推动UKUI移除包列表移入对应SIG组；
解决任务栏与开始菜单显示位置异常问题；
通知、网络、电源管理、控制面板、USD完成需求，合入最新代码；
新增可变强度毛玻璃特效；
企业网新增LEAP、PWD、FAST认证类型需求；
UKUI网站更新：敲定产品特性、社区展示页等设计素。

欢迎各位感兴趣的社区开发者加入我们，一起打造openKylin桌面系统稳定易用的桌面环境！

二、RISC-V SIG

本SIG组主要负责RISC-V架构开源软件包的维护，发布openKylin的RISC-V版本，进行软件包构建、系统构建等工作。

完成专利“一种面向RISC-V的可扩展分段自动化镜像构建技术”初稿以及相关脚本的编写；
交叉编译opensbi、内核并解决相关问题。RVTrans增加了对于GtkApplication、GApplication、GtkTextView3、GtkTextContainer3的支持；
解决了运行扫雷等gtk应用问题；
平头哥开发板构建完成符合开发板要求的rootfs镜像，后续需要继续调试优化；
封装GTK3相关类及运行扫雷等小游戏需要的动态库函数，增加或修改代码400+行，增强了对RVTrans对于Gtk3的支持；
平头哥曳影1520开发板适配：
（1）系统镜像已通过修改uboot环境变量的方法成功设置分区，测试已能够正常烧录镜像并且能够正常启动我们制作的rootfs；
（2）适配RISC-V原生Firefox和LibreOffice，进度完成20%；
rvtrans：
（1）增加了对于GtkButton3、GamesScoresImporter类及libgnome-game-support动态库的封装，增强了对于gnome游戏的支持；
（2）封装了运行gtk应用必须的动态库函数30+；
（3）解决了缺少g_object_connect相关回调函数问题。

欢迎所有对RISC-V技术方向感兴趣的爱好者加入到RISC-V SIG！

三、Virtualization SIG

Virtualization SIG致力于构建openKylin社区系统虚拟化技术，打造面向端、边、云的全场景虚拟化解决方案。本SIG组11月份主要进展如下：

virtio-gpu 硬件编码框架virglerenderer补丁集已被上游社区接受；
向极狐社区gitlab云原生沙龙会议提供主题和专家资料；
修复qemu 7.1编译错误，暂时关闭qemu uring支持；
添加仓库spice libvirt spice-protocol；
virglrender移植上游virtio-gpu硬件加速编解码补丁；
qemu 添加virtio-gpu硬件加速补丁以及运行依赖相关库12个；
新增6个虚拟化依赖包，解决在openkylin上打包失败的问题；
修复libvirt运行崩溃问题。

欢迎所有对虚拟化技术方向感兴趣的爱好者加入到Virtualization SIG！

四、Release SIG

Release SIG主要负责协调各个SIG组，把控版本开发进度和风险，制定版本发布计划，完成版本发布工作等。Release SIG本月主要进展如下：

筛选影响较大的严重bug 34个，推进修复27个，正式发布openkylin 0.9版本，开启公测；
梳理所有开发、项目管理、规则流程文档，编写社区签署CLA参与指南、提交和审核issue指南；
社区需求管理规范定稿；
确定1.0alpha、beta、RC版本计划；
推进软件商店和UKUI需求排期；
1.0 版本宣传亮点梳理；
社区看板功能对接讨论；

欢迎所有对openKylin社区版本集成、版本管理、版本发行等工作感兴趣的爱好者加入到Release SIG！

五、Kernel SIG

Kernel SIG负责openKylin社区版本的内核选型、代码维护等工作。本月主要进展如下：

完成分级冻结机制内核补丁的开发、移植。

欢迎所有对openKylin社区内核开发维护感兴趣的爱好者加入到Kernel SIG！

六、Framework SIG

Framework SIG致力于为openKylin社区提供集程序编辑、编译、调试、发布、分析等全套开发功能的编程环境，涵盖通用集成开发环境、编译工具链、运行时环境、类库等。SIG初期重点研制高效率、跨平台、插件化、易调试的通用集成开发环境，支持C、C++、Java、Go、Fortran、Python、JavaScript等多种标准编程语言，涵盖编码、编译、调试、性能分析、软件交付等一整套开发流程，满足openKylin平台上软件开发需求。本月主要进展如下：

修复优化同时持续推进CMake智能编辑、分布式编译集成插件、死锁检测、代码性能分析、项目创建等功能开发；

欢迎所有对openKylin社区应用集成开发环境感兴趣的爱好者加入到Framework SIG！

七、Infrastructure SIGInfrastructure SIG负责openKylin社区的基础平台系统功能的开发、维护。本月主要进展如下：

CI平台
（1）增加changelog格式检查功能、打包上传后跟踪OKBS处理情况、打包成功自动关闭旧的issue；
（2）修复部分软件包gbp.conf启用tag签名导致打包失败的问题；
数字看板
（1）与小程序端进行接口联调上线；
（2）支持查看SIG成员贡献详情；
CLA平台
（1）支持第三方供应商推广个人CLA签署；
（2）企业会员增加logo管理功能，增加重置企业管理员密码功能，增加会员证书等文件。

欢迎所有对openKylin社区基础设施平台开发维护感兴趣的爱好者加入到Infrastructure SIG！

八、Defend SIG

Defend SIG组致力于在openKylin社区版本中引入的系统防护功能。SIG组11月份主要进展如下：

组织Defend SIG组第一次公开例会，邀请社区会员山石网科安全专家参加交流；
openKylin安全防护软件功能模块继续梳理。

欢迎所有对操作系统防护软件感兴趣的爱好者加入到Defend SIG！

九、Xfce/KDE SIG

主要负责维护Xfce和KDE桌面环境在openKylin社区的适配和发展。11月份SIG组主要进展如下：

Xfce桌面环境的所有组件已上传完毕，通过OKBS软件包编译平台发布到了openKylin proposed源，可以安装和使用。当前处于日常维护状态，本月修复一个CVE-2022-45062漏洞。
KDE桌面环境的基本组件已上传完毕，通过OKBS软件包编译平台发布到了openKylin proposed源，可以安装和使用。目前移植了KDE的部分图形类、网络类和游戏类等应用，将进行日常维护和继续移植更多的KDE应用。

欢迎各位感兴趣的社区爱好者，一同加入我们！

十、Docs SIG

Docs SIG小组致力于创建openKylin社区各种文档，包括但不限于使用文档、开发文档、各类教程等等，帮助社区新人和开发人员更好的使用、开发openKylin版本及周边。Docs SIG 11月份进展如下：

主导更新openkylin SDK v2.0开发指南文档，并转换成markdown格式。

欢迎所有对文档编写、文档管理感兴趣的社区爱好者加入我们！

十一、Packaging SIG

Packaging SIG负责维护openKylin社区的软件包打包规范，维护公共软件包，以及协调和决策社区版本发布过程中的包依赖问题。11月份主要进展如下：

python3.10、python2.7、llvm编译上传；
处理glibc、gcc、libkysdk-ocr-dev、libkysdk-sysinfo、libkysdk-sysinfo-dev、python3-stdlib-extensions、python3-defaults、python-pip、libjs-sphinxdoc、fakeroot、dh-python、glibc等版本升级工作，并处理依赖问题；
新增44个源码包；
解决gspell、perl等编译问题，升级更新fakeroot/glibc2.36、systemd251.4 ；
新增21个上游包，上传gitee13个软件包；
撰写《移植Hello软件到openKylin》；
分析python3.10、glibc，正在形成文档；
本地新编包6个，处理perl-5.36、gimp、xrdp、batik、remmina、openjdk-lts等软件包编译问题；

欢迎所有对openKylin社区软件自主选型、编译打包工作感兴趣的社区爱好者加入我们！

十二、QA SIG

QA SIG组致力于提升openKylin社区版本质量，包括社区版本测试、质量保障等。本月主要进展如下：

RC-1101版本、RC-1102版本回归测试；
0.9发布版本测试（x86和RISC-V）；
编写openKylin 0.9共测方案，已上传码云并同步给产品；
0.9版本测试报告完成并发送，剩余需求梳理及新节点确认，共测issue审核及评分，本周审核10个issue；
openKylin 软件商店-新增openKylin ID登录支持需求补丁包测试准备；
传书及openKylin漏洞修复测试完成。安全漏洞已修复，影响域测试传书基础功能测试通过，两个版本共执行禅道用例82条，通过76条，失败4条；
0.9版本共测活动Issue审核及评分处理；
新版软件商店及登录ID需求确认测试范围，提交7个issue包括6个高等级，发送初步测试结果；
编写1.0版本测试方案完成待评审；
UKUI部分新需求编写测试用例；

欢迎所有对openKylin社区版本测试、质量管理感兴趣的社区爱好者加入我们！

十三、SecurityGovernance SIG

openKylin SecurityGovernance SIG通过接收和响应openKylin社区的产品安全问题报告、提供社区安全指导，开展安全治理等活动提升社区产品的安全性。本月主要进展如下：

规划了三个安全研发流程相关开源项目，提交相关的流程介绍、仓库及落地方案；
poc仓库（openkylin-exploit-db），新增15个漏洞POC；
fuzzing仓库
（1）引入Google fuzz仓库技术文档内容；
（2）新增原创技术文章3篇；
安全漏洞扫描框架仓库（genmai）
（1）完成“诊脉”扫描框架的YAML和JSON配置文件的解析功能，并提交代码；
（2）完成优化三个模块功能(沙箱接口模块，YAML配置解析模块，JSON配置解析模块)，提交go代码两千多行；
攻防智库（attack-defense-think-tank）
（1）新增收录5篇技术文章和应急响应工具箱。之后会持续将常见漏洞（如命令注入、目录操纵）纳入相关漏洞修复总结，与漏洞修复建议相结合，供社区开发者阅读；
（2）新增技术文章3篇，两名外部人员（360攻防实验室研究员、星澜科技安全研究员）加入贡献；
（3）“终端安全”版块新增7篇漏洞分析复现文章，新增技术文章5篇（外部来源4篇、内部原创1篇：netlink通信模块研究及利用）；
已在openKylin社区提交cveissue202个，提供CVE信息、评分、补丁和参考文献等内容。SecurityGovernance共修复85个；
新建项目openkylin-cve-tracer用于建设openkylin情报共享机制，并新增项目介绍；
新建项目openkylin-cve-manager-bot，用于漏洞信息的自动化流转；
漏洞感知大脑项目新增架构图与发布issue流程；
安全漏洞扫描框架仓库(genmai)完成优化三个模块功能(沙箱接口模块，YAML配置解析模块，JSON配置解析模块)，提交go代码两千多行；
“诊脉”漏洞检测框架/工具（genmai），编写poc交互解析器、终端文字UI界面，代码量新增一千三百多行；
安全治理SIG组自主打补丁83个；
openKylin社区终端插件仓库（a-cool-config）累计上传三十几个插件，编写两个安装脚本，编写相关的配置使用说明；
对openkylin统一用户中心（id.openkylin.top）初步探测，存在文件上传接口未限制上传类型漏洞，可导致攻击者拿到管理员权限，已告知整改。

欢迎所有对openKylin版本安全全漏洞挖掘/验证、安全漏洞修复等安全方面工作感兴趣的社区爱好者加入我们！

十四、UKUIApplications SIG

本SIG组致力于openKylin社区的基础应用开发和维护，扩展openKylin系统的生态。本月主要进展如下：

推进0.9版本遗留bug修复；
修复安全漏洞 KVE-2022-1103。

欢迎所有对openKylin社区UKUI应用开发工作感兴趣的社区爱好者加入我们！

十五、OpenSDK SIG

本SIG组负责openKylin开发者套件（base、system、applications）规划、开发、维护等工作，致力于解决应用在多操作系统中的兼容性问题。本月主要进展如下：

推进0.9版本遗留bug修复；
解决因pc文件导致应用引用sdk库失败问题；
完善openSDK v2.0开发指南文档；
新增完成通知模块；
新增多编程语言支持。

欢迎所有对openKylin社区openSDK开发维护工作感兴趣的社区爱好者加入我们！

十六、Connectivity SIG

本SIG组致力于openKylin社区的互联互通基础能力开发与维护。11月主要进展如下：

推进0.9版本遗留bug修复。

欢迎所有对openKylin社区互联互通应用及万物互联能力提升工作感兴趣的社区爱好者加入我们！

十七、InputMethod SIG

本SIG组致力于组建输入法开源社区，推进输入法在社区维护。本月主要进展如下：

增加禁用输入法的标志位；
允许IM module在创建InputContext对象的时候禁用fcitx5提供的得到焦点和失去焦点时虚拟键盘弹出和关闭行为；
和fcitx社区讨论QCompleter焦点策略问题，已向Qt社区提交问题issues，同时提供补丁解决方案；
推进0.9版本遗留bug。

欢迎所有对openKylin社区fcitx输入法框架、桌面虚拟键盘开发工作感兴趣的社区爱好者加入我们！

关于openKylin社区SIG

openKylin（开放麒麟）社区是一个自由开放的社区，社区中所有的SIG小组都是开放的，任何人和组织都可以参与。你可以选择加入已有SIG，也可以选择创建新的SIG。截至目前，openKylin社区已有56个SIG在运行，包括Architecture、Infrastructure、Release、Kernel、Security、Compatibility等。

如果您对此感兴趣，想要加入openKylin（开放麒麟）社区，参与SIG贡献，可 “https://www.openkylin.top/sig/index-cn.html ” 了解更多详细内容。

关于openKylin社区

审核：openKyli

2019 年，腾讯低调发布了 Linux 的更新，目前版本停留在 2.0 Beta2。

时隔 3 年， for Linux 基于 NT 技术架构迎来全新升级。今日（12 月 7 日）起，全新 Linux 正式开启公测，版本号为 2.0.1。

下载链接：deb | rpm | AppImage

需要注意的是， for Linux 新版本目前只支持 x64 架构，arm64 架构还在加急适配中。

根据腾讯项目组的通告，全新的 for Linux 基于 Electron 开发，因此理论上支持所有 Linux 发行版。

Electron 是跨平台的桌面应用开发工具，基于 Electron 构建的应用可同时支持 Linux、Windows 和 Mac。

一张广泛传播的聊天截图显示，基于 Electron 构建的还会提供支持 Windows 的版本，并将于明年对外公布。

目前已经推出的 for Mac 新版本也提到了采用全新架构——“NT技术架构”，而 for Mac 新版本正是基于 Electron 构建。

延伸阅读

腾讯悄悄发布 Linux ，版本 2.0 Beta
for Linux 复活，微信 for Linux 还远吗？

1. 用户空间和内核态空间

1.1 为什么要区分用户和内核

服务器大多都采用 Linux 系统，这里我们以 Linux 为例来讲解:

ubuntu 和 Centos 都是 Linux 的发行版，发行版可以看成对 linux 包了一层壳，任何 Linux 发行版，其系统内核都是 Linux 。我们的应用都需要通过 Linux 内核与硬件交互

用户的应用，比如 redis ，mysql 等其实是没有办法去执行访问我们操作系统的硬件的，所以我们可以通过发行版的这个壳子去访问内核，再通过内核去访问计算机硬件

计算机硬件包括，如 cpu，内存，网卡等等，内核（通过寻址空间）可以操作硬件的，但是内核需要不同设备的驱动，有了这些驱动之后，内核就可以去对计算机硬件去进行内存管理，文件系统的管理，进程的管理等等

我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而简介的实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu 等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去操作随意的去操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开

1.2 进程寻址空间

进程的寻址空间划分成两部分：内核空间、用户空间

什么是寻址空间呢？我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数。

比如一个 32 位的操作系统，他的带宽就是 32，他的虚拟地址就是 2 的 32 次方，也就是说他寻址的范围就是 0~2 的 32 次方，这片寻址空间对应的就是 2 的 32 个字节，就是 4GB，这个 4GB，会有 3 个 GB 分给用户空间，会有 1GB 给内核系统

在 linux 中，他们权限分成两个等级，0 和 3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。

比如：

Linux 系统为了提高 IO 效率，会在用户空间和内核空间都加入缓冲区：

写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

针对这个操作：我们的用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的 buffer 中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望 read 也好，还是 wait for data 也最好都不要等待，或者时间尽量的短。

2. 网络模型

2.1 阻塞IO

过程 1：应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区。
过程 2：如果是阻塞 IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

用户去读取数据时，会去先发起 recvform 一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回 ok，整个过程，都是阻塞等待的，这就是阻塞 IO

总结如下：

顾名思义，阻塞 IO 就是两个阶段都必须阻塞等待：

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态

阶段二：

数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据

可以看到，阻塞 IO 模型中，用户进程在两个阶段都是阻塞状态。

2.2 非阻塞 IO

顾名思义，非阻塞 IO 的 recvfrom 操作会立即返回结果而不是阻塞用户进程

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
返回异常给用户进程
用户进程拿到 error 后，再次尝试读取
循环往复，直到数据就绪

阶段二：

将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
可以看到，非阻塞 IO 模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致 CPU 空转，CPU 使用率暴增。

2.3 信号驱动

信号驱动 IO 是与内核建立 SIGIO 的信号关联并设置回调，当内核有 FD 就绪时，会发出 SIGIO 信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

用户进程调用 sigaction ，注册信号处理函数
内核返回成功，开始监听 FD
用户进程不阻塞等待，可以执行其它业务
当内核数据就绪后，回调用户进程的 SIGIO 处理函数

阶段二：

收到 SIGIO 回调信号
调用 recvfrom ，读取
内核将数据拷贝到用户空间
用户进程处理数据

当有大量 IO 操作时，信号较多，SIGIO 处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

2.4 异步 IO

这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步 IO 模型中，用户进程在两个阶段都是非阻塞状态。

2.5 IO 多路复用

场景引入

为了更好的理解 IO ，现在假设这样一种场景：一家餐厅

A 情况：这家餐厅中现在只有一位服务员，并且采用客户排队点餐的方式，就像这样：

每排到一位客户要吃到饭，都要经过两个步骤：

思考要吃什么顾客开始点餐，厨师开始炒菜

由于餐厅只有一位服务员，因此一次只能服务一位客户，并且还需要等待当前客户思考出结果，这浪费了后续排队的人非常多的时间，效率极低。这就是阻塞 IO。

当然，为了缓解这种情况，老板完全可以多雇几个人，但这也会增加成本，而在极大客流量的情况下，仍然不会有很高的效率提升

B 情况：这家餐厅中现在只有一位服务员，并且采用客户排队点餐的方式。

每排到一位客户要吃到饭，都要经过两个步骤：

思考要吃什么
顾客开始点餐，厨师开始炒菜

与 A 情况不同的是，此时服务员会不断询问顾客：“你想吃番茄鸡蛋盖浇饭吗？那滑蛋牛肉呢？那肉末茄子呢？……”

虽然服务员在不停的问，但是在网络中，这并不会增加数据的就绪速度，主要还是等顾客自己确定。所以，这并不会提高餐厅的效率，说不定还会招来更多差评。这就是非阻塞 IO。

C 情况：这家餐厅中现在只有一位服务员，但是不再采用客户排队的方式，而是顾客自己获取菜单并点餐，点完后通知服务员，就像这样：

每排到一位客户要吃到饭，还是都要经过两个步骤：

看着菜单，思考要吃什么
通知服务员，我点好了

与 A B 不同的是，这种情况服务员不必再等待顾客思考吃什么，只需要在收到顾客通知后，去接收菜单就好。这样相当于餐厅在只有一个服务员的情况下，同时服务了多个人，而不像 A B，同一时刻只能服务一个人。此时餐厅的效率自然就提高了很多。

映射到我们的网络服务中，就是这样：

客人：客户端请求
点餐内容：客户端发送的实际数据
老板：操作系统
人力成本：系统资源
菜单：文件状态描述符。操作系统对于一个进程能够同时持有的文件状态描述符的个数是有限制的，在 linux 系统中 $ulimit -n 查看这个限制值，当然也是可以 (并且应该) 进行内核参数调整的。
服务员：操作系统内核用于 IO 操作的线程 (内核线程)
厨师：应用程序线程 (当然厨房就是应用程序进程咯)
餐单传递方式：包括了阻塞式和非阻塞式两种。
- 方法 A: 阻塞 IO
- 方法 B: 非阻塞 IO
- 方法 C: 多路复用 IO

2.6 多路复用 IO 的实现

目前流程的多路复用 IO 实现主要包括四种: select、poll、epoll、kqueue。下表是他们的一些重要特性的比较:

IO 模型相对性能关键思路操作系统 JAVA 支持情况 select 较高 Reactor windows/Linux 支持，Reactor 模式 (反应器设计模式)。Linux 操作系统的 kernels 2.4 内核版本之前，默认使用 select；而目前 windows 下对同步 IO 的支持，都是 select 模型 poll 较高 Reactor Linux Linux 下的 JAVA NIO 框架，Linux kernels 2.6 内核版本之前使用 poll 进行支持。也是使用的 Reactor 模式 epoll 高 Reactor/Proactor Linux Linux kernels 2.6 内核版本及以后使用 epoll 进行支持；Linux kernels 2.6 内核版本之前使用 poll 进行支持；另外一定注意，由于 Linux 下没有 Windows 下的 IOCP 技术提供真正的异步 IO 支持，所以 Linux 下使用 epoll 模拟异步 IO kqueue 高 Proactor Linux 目前 JAVA 的版本不支持

多路复用 IO 技术最适用的是 “高并发” 场景，所谓高并发是指 1 毫秒内至少同时有上千个连接请求准备好。其他情况下多路复用 IO 技术发挥不出来它的优势。另一方面，使用 JAVA NIO 进行功能实现，相对于传统的 Socket 套接字实现要复杂一些，所以实际应用中，需要根据自己的业务需求进行技术选择。

2.6.1 select

select 是 Linux 最早是由的 I/O 多路复用技术：

linux 中，一切皆文件，socket 也不例外，我们把需要处理的数据封装成 FD，然后在用户态时创建一个 fd_set 的集合（这个集合的大小是要监听的那个 FD 的最大值 + 1，但是大小整体是有限制的），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据。

其内部流程：

用户态下：

创建 fd_set 集合，包括要监听的读事件、写事件、异常事件的集合
确定要监听的 fd_set 集合
将要监听的集合作为参数传入 select () 函数中，select 中会将集合复制到内核 buffer 中

内核态：

内核线程在得到集合后，遍历该集合
没数据就绪，就休眠
当数据来时，线程被唤醒，然后再次遍历集合，标记就绪的 fd 然后将整个集合，复制回用户 buffer 中
用户线程遍历集合，找到就绪的 fd ，再发起读请求。

不足之处：

集合大小固定为 1024 ，也就是说最多维持 1024 个 socket，在海量数据下，不够用
集合需要在用户 buffer 和内核 buffer 中反复复制，涉及到用户态和内核态的切换，非常影响性能

2.6.2 poll

poll 模式对 select 模式做了简单改进，但性能提升不明显。

IO 流程：

创建 pollfd 数组，向其中添加关注的 fd 信息，数组大小自定义
调用 poll 函数，将 pollfd 数组拷贝到内核空间，转链表存储，无上限
内核遍历 fd ，判断是否就绪
数据就绪或超时后，拷贝 pollfd 数组到用户空间，返回就绪 fd 数量 n
用户进程判断 n 是否大于 0, 大于 0 则遍历 pollfd 数组，找到就绪的 fd

与 select 对比：

select 模式中的 fd_set 大小固定为 1024，而 pollfd 在内核中采用链表，理论上无上限，但实际上不能这么做，因为的监听 FD 越多，每次遍历消耗时间也越久，性能反而会下降

2.6.3 epoll

epoll 模式是对 select 和 poll 的改进，它提供了三个函数：eventpoll 、epoll_ctl 、epoll_wait

eventpoll 函数内部包含了两个东西 :
- 红黑树：用来记录所有的 fd
- 链表：记录已就绪的 fd
epoll_ctl 函数，将要监听的 fd 添加到红黑树上去，并且给每个 fd 绑定一个监听函数，当 fd 就绪时就会被触发，这个监听函数的操作就是将这个 fd 添加到链表中去。
epoll_wait 函数，就绪等待。一开始，用户态 buffer 中创建一个空的 events 数组，当就绪之后，我们的回调函数会把 fd 添加到链表中去，当函数被调用的时候，会去检查链表（当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等），如果链表中没有有 fd 则 fd 会从红黑树被添加到链表中，此时再将链表中的的 fd 复制到用户态的空 events 中，并且返回对应的操作数量，用户态此时收到响应后，会从 events 中拿到已经准备好的数据，在调用读方法去拿数据。

2.6.4 总结：

select 模式存在的三个问题：

能监听的 FD 最大不超过 1024
每次 select 都需要把所有要监听的 FD 都拷贝到内核空间
每次都要遍历所有 FD 来判断就绪状态

poll 模式的问题：

poll 利用链表解决了 select 中监听 FD 上限的问题，但依然要遍历所有 FD，如果监听较多，性能会下降

epoll 模式中如何解决这些问题的？

基于 epoll 实例中的红黑树保存要监听的 FD，理论上无上限，而且增删改查效率都非常高
每个 FD 只需要执行一次 epoll_ctl 添加到红黑树，以后每次 epol_wait 无需传递任何参数，无需重复拷贝 FD 到内核空间
利用 ep_poll_callback 机制来监听 FD 状态，无需遍历所有 FD，因此性能不会随监听的 FD 数量增多而下降

2.7 基于 epoll 的服务器端流程

一张图搞定：

我们来梳理一下这张图

服务器启动以后，服务端会去调用 epoll_create，创建一个 epoll 实例，epoll 实例中包含两个数据

红黑树（为空）：rb_root 用来去记录需要被监听的 FD
链表（为空）：list_head，用来存放已经就绪的 FD

创建好了之后，会去调用 epoll_ctl 函数，此函数会会将需要监听的 fd 添加到 rb_root 中去，并且对当前这些存在于红黑树的节点设置回调函数。
当这些被监听的 fd 一旦准备就绪，与之相关联的回调函数就会被调用，而调用的结果就是将红黑树的 fd 添加到 list_head 中去 (但是此时并没有完成)
fd 添加完成后，就会调用 epoll_wait 函数，这个函数会去校验是否有 fd 准备就绪（因为 fd 一旦准备就绪，就会被回调函数添加到 list_head 中），在等待了一段时间 (可以进行配置)。
如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接事件，则调用 accept () 接受客户端 socket ，拿到建立连接的 socket ，然后建立起来连接，如果是其他事件，则把数据进行写出。

2.8 五种网络模型对比：

最后用一幅图，来说明他们之间的区别

3. redis 通信协议

3.1 RESP 协议

Redis 是一个 CS 架构的软件，通信一般分两步（不包括 pipeline 和 PubSub）：

客户端（client）向服务端（server）发送一条命令，服务端解析并执行命令
返回响应结果给客户端，因此客户端发送命令的格式、服务端响应结果的格式必须有一个规范，这个规范就是通信协议。

而在 Redis 中采用的是 RESP（Redis Serialization Protocol）协议：

Redis 1.2 版本引入了 RESP 协议
Redis 2.0 版本中成为与 Redis 服务端通信的标准，称为 RESP2
Redis 6.0 版本中，从 RESP2 升级到了 RESP3 协议，增加了更多数据类型并且支持 6.0 的新特性–客户端缓存

但目前，默认使用的依然是 RESP2 协议。在 RESP 中，通过首字节的字符来区分不同数据类型，常用的数据类型包括 5 种：

单行字符串：首字节是 ‘+’ ，后面跟上单行字符串，以 CRLF（ “ ” ）结尾。例如返回”OK”： “+OK ”
错误（Errors）：首字节是 ‘-’ ，与单行字符串格式一样，只是字符串是异常信息，例如：”-Error message ”
数值：首字节是 ‘:’ ，后面跟上数字格式的字符串，以 CRLF 结尾。例如：”:10 ”
多行字符串：首字节是 ‘$’ ，表示二进制安全的字符串，最大支持 512MB：
- 如果大小为 0，则代表空字符串：”$0 ”
- 如果大小为 – 1，则代表不存在：”$-1 ”
数组：首字节是 ‘*’，后面跟上数组素个数，再跟上素，素数据类型不限 :

本文由教研团队发布。

如果本文对您有帮助，欢迎和；如果您有任何建议也可或，您的支持是我坚持创作的动力。

转载请注明出处！

摘要：本篇文章将分享图像分类原理，并介绍基于KNN、朴素贝叶斯算法的图像分类案例。

本文分享自华为云社区《[Python图像处理] 二十六.图像分类原理及基于KNN、朴素贝叶斯算法的图像分类案例丨【百变AI秀】》，作者：eastmount 。

一.图像分类

图像分类（Image Classification）是对图像内容进行分类的问题，它利用计算机对图像进行定量分析，把图像或图像中的区域划分为若干个类别，以代替人的视觉判断。图像分类的传统方法是特征描述及检测，这类传统方法可能对于一些简单的图像分类是有效的，但由于实际情况非常复杂，传统的分类方法不堪重负。现在，广泛使用机器学习和深度学习的方法来处理图像分类问题，其主要任务是给定一堆输入图片，将其指派到一个已知的混合类别中的某个标签。

在下图中，图像分类模型将获取单个图像，并将为4个标签{cat，dog，hat，mug}，分别对应概率{0.6, 0.3, 0.05, 0.05}，其中0.6表示图像标签为猫的概率，其余类比。该图像被表示为一个三维数组。在这个例子中，猫的图像宽度为248像素，高度为400像素，并具有红绿蓝三个颜色通道（通常称为RGB）。因此，图像由248×400×3个数字组成或总共个数字，每个数字是一个从0（黑色）到255（白色）的整数。图像分类的任务是将这接近30万个数字变成一个单一的标签，如“猫（cat）”。

那么，如何编写一个图像分类的算法呢？又怎么从众多图像中识别出猫呢？这里所采取的方法和教育小孩看图识物类似，给出很多图像数据，让模型不断去学习每个类的特征。在训练之前，首先需要对训练集的图像进行分类标注，如图所示，包括cat、dog、mug和hat四类。在实际工程中，可能有成千上万类别的物体，每个类别都会有上百万张图像。

图像分类是输入一堆图像的像素值数组，然后给它分配一个分类标签，通过训练学习来建立算法模型，接着使用该模型进行图像分类预测，具体流程如下：

输入： 输入包含N个图像的集合，每个图像的标签是K种分类标签中的一种，这个集合称为训练集。
学习： 第二步任务是使用训练集来学习每个类的特征，构建训练分类器或者分类模型。
评价： 通过分类器来预测新输入图像的分类标签，并以此来评价分类器的质量。通过分类器预测的标签和图像真正的分类标签对比，从而评价分类算法的好坏。如果分类器预测的分类标签和图像真正的分类标签一致，表示预测正确，否则预测错误。

二.常见分类算法

常见的分类算法包括朴素贝叶斯分类器、决策树、K最近邻分类算法、支持向量机、神经网络和基于规则的分类算法等，同时还有用于组合单一类方法的集成学习算法，如Bagging和Boosting等。

1.朴素贝叶斯分类算法

朴素贝叶斯分类（Naive Bayes Classifier）发源于古典数学理论，利用Bayes定理来预测一个未知类别的样本属于各个类别的可能性，选择其中可能性最大的一个类别作为该样本的最终类别。在朴素贝叶斯分类模型中，它将为每一个类别的特征向量建立服从正态分布的函数，给定训练数据，算法将会估计每一个类别的向量均值和方差矩阵，然后根据这些进行预测。

朴素贝叶斯分类模型的正式定义如下：

该算法的特点为：如果没有很多数据，该模型会比很多复杂的模型获得更好的性能，因为复杂的模型用了太多假设，以致产生欠拟合。

2.KNN分类算法

K最近邻分类（K-Nearest Neighbor Classifier）算法是一种基于实例的分类方法，是数据挖掘分类技术中最简单常用的方法之一。该算法的核心思想如下：一个样本x与样本集中的k个最相邻的样本中的大多数属于某一个类别yLabel，那么该样本x也属于类别yLabel，并具有这个类别样本的特性。

简而言之，一个样本与数据集中的k个最相邻样本中的大多数的类别相同。由其思想可以看出，KNN是通过测量不同特征值之间的距离进行分类，而且在决策样本类别时，只参考样本周围k个“邻居”样本的所属类别。因此比较适合处理样本集存在较多重叠的场景，主要用于预测分析、文本分类、降维等处理。

该算法在建立训练集时，就要确定训练数据及其对应的类别标签；然后把待分类的测试数据与训练集数据依次进行特征比较，从训练集中挑选出最相近的k个数据，这k个数据中投票最多的分类，即为新样本的类别。KNN分类算法的流程描述为如下图所示。

该算法的特点为：简单有效，但因为需要存储所有的训练集，占用很大内存，速度相对较慢，使用该方法前通常训练集需要进行降维处理。

3.SVM分类算法

支持向量机（Support Vector Machine）是数学家Vapnik等人根据统计学习理论提出的一种新的学习方法，其基本模型定义为特征空间上间隔最大的线性分类器，其学习策略是间隔最大化，最终转换为一个凸二次规划问题的求解。SVM分类算法基于核函数把特征向量映射到高维空间，建立一个线性判别函数，解最优在某种意义上是两类中距离分割面最近的特征向量和分割面的距离最大化。离分割面最近的特征向量被称为“支持向量”，即其它向量不影响分割面。图像分类中的SVM如下图所示，将图像划分为不同类别。

下面的例子可以让读者对SVM快速建立一个认知。给定训练样本，支持向量机建立一个超平面作为决策曲面，使得正例和反例的隔离边界最大化。决策曲面的构建过程如下所示：

在下图中，想象红球和蓝球为球台上的桌球，首先需要找到一条曲线将蓝球和红球分开，于是得到一条黑色的曲线。

为了使黑色曲线离任意的蓝球和红球距离最大化，我们需要找到一条最优的曲线，如下图所示。

假设这些球不是在球桌上，而是抛在空中，但仍然需要将红球和蓝球分开，这时就需要一个曲面，而且该曲面仍然满足所有任意红球和蓝球的间距最大化，如图16-7所示。离这个曲面最近的红色球和蓝色球就被称为“支持向量（Support Vector）”。

该算法的特点为：当数据集比较小的时候，支持向量机的效果非常好。同时，SVM分类算法较好地解决了非线性、高维数、局部极小点等问题，维数大于样本数时仍然有效。

4.随机森林分类算法

随机森林（Random Forest）是用随机的方式建立一个森林，在森林里有很多决策树的组成，并且每一棵决策树之间是没有关联的。当有一个新样本出现的时候，通过森林中的每一棵决策树分别进行判断，看看这个样本属于哪一类，然后用投票的方式，决定哪一类被选择的多，并作为最终的分类结果。

随机森林中的每一个决策树“种植”和“生长”主要包括以下四个步骤：

假设训练集中的样本个数为N，通过有重置的重复多次抽样获取这N个样本，抽样结果将作为生成决策树的训练集；
如果有M个输入变量，每个节点都将随机选择m(m<M)个特定的变量，然后运用这m个变量来确定最佳的分裂点。在决策树的生成过程中，m值是保持不变的；
每棵决策树都最大可能地进行生长而不进行剪枝；
通过对所有的决策树进行加来预测新的数据（在分类时采用多数投票，在回归时采用平均）。

该算法的特点为：在分类和回归分析中都表现良好；对高维数据的处理能力强，可以处理成千上万的输入变量，也是一个非常不错的降维方法；能够输出特征的重要程度，能有效地处理缺省值。

5.神经网络分类算法

神经网络（Neural Network）是对非线性可分数据的分类方法，通常包括输入层、隐藏层和输出层。其中，与输入直接相连的称为隐藏层（Hidden Layer），与输出直接相连的称为输出层（Output Layer）。神经网络算法的特点是有比较多的局部最优值，可通过多次随机设定初始值并运行梯度下降算法获得最优值。图像分类中使用最广泛的是BP神经网络和CNN神经网络。

BP神经网络

BP神经网络是一种多层的前馈神经网络，其主要的特点为：信号是前向传播的，而误差是反向传播的。BP神经网络的过程主要分为两个阶段，第一阶段是信号的前向传播，从输入层经过隐含层，最后到达输出层；第二阶段是误差的反向传播，从输出层到隐含层，最后到输入层，依次调节隐含层到输出层的权重和偏置，输入层到隐含层的权重和偏置，具体结构如下图所示。

神经网络的基本组成单是神经。神经的通用模型如图所示，其中常用的激活函数有阈值函数、Sigmoid函数和双曲正切函数等。

CNN卷积神经网络

卷积神经网络（Convolutional Neural Networks）是一类包含卷积计算且具有深度结构的前馈神经网络，是深度学习的代表算法之一。卷积神经网络的研究始于二十世纪80至90年代，时间延迟网络和LeNet-5是最早出现的卷积神经网络。在二十一世纪后，随着深度学习理论的提出和数值计算设备的改进，卷积神经网络得到了快速发展，并被大量应用于计算机视觉、自然语言处理等领域。

三.基于KNN算法的图像分类

1.KNN算法

K最近邻分类（K-Nearest Neighbor Classifier）算法是一种基于实例的分类方法，是数据挖掘分类技术中最简单常用的方法之一。该算法的核心思想是从训练样本中寻找所有训练样本X中与测试样本距离（欧氏距离）最近的前K个样本（作为相似度），再选择与待分类样本距离最小的K个样本作为X的K个最邻近，并检测这K个样本大部分属于哪一类样本，则认为这个测试样本类别属于这一类样本。

假设现在需要判断下图中的圆形图案属于三角形还是正方形类别，采用KNN算法分析如下：

当K=3时，图中第一个圈包含了三个图形，其中三角形2个，正方形一个，该圆的则分类结果为三角形。
当K=5时，第二个圈中包含了5个图形，三角形2个，正方形3个，则以3:2的投票结果预测圆为正方形类标。设置不同的K值，可能预测得到不同的结果。

KNN在Sklearn机器学习包中，实现的类是neighbors.KNeighborsClassifier，简称KNN算法。构造方法为：

KNeighborsClassifier可以设置3种算法：brute、kd_tree、ball_tree，设置K值参数为n_neighbors=3。调用方法如下：

from sklearn.neighbors import KNeighborsClassifier
knn = KNeighborsClassifier(n_neighbors=3, algorithm=“ball_tree”)

它包括两个步骤：

训练：nbrs.fit(data, target)
预测：pre = clf.predict(data)

2.数据集

该部分主要使用Scikit-Learn包进行Python图像分类处理。Scikit-Learn扩展包是用于Python数据挖掘和数据分析的经典、实用扩展包，通常缩写为Sklearn。Scikit-Learn中的机器学习模型是非常丰富的，包括线性回归、决策树、SVM、KMeans、KNN、PCA等等，用户可以根据具体分析问题的类型选择该扩展包的合适模型，从而进行数据分析，其安装过程主要通过“pip install scikit-learn”实现。

实验所采用的数据集为Sort_1000pics数据集，该数据集包含了1000张图片，总共分为10大类，分别是人（第0类）、沙滩（第1类）、建筑（第2类）、大卡车（第3类）、恐龙（第4类）、大象（第5类）、花朵（第6类）、马（第7类）、山峰（第8类）和食品（第9类），每类100张。如图所示。

接着将所有各类图像按照对应的类标划分至“0”至“9”命名的文件夹中，如图所示，每个文件夹中均包含了100张图像，对应同一类别。

比如，文件夹名称为“6”中包含了100张花的图像，如下图所示。

3.KNN图像分类

下面是调用KNN算法进行图像分类的完整代码，它将1000张图像按照训练集为70%，测试集为30%的比例随机划分，再获取每张图像的像素直方图，根据像素的特征分布情况进行图像分类分析。KNeighborsClassifier()核心代码如下：

from sklearn.neighbors import KNeighborsClassifier
clf = KNeighborsClassifier(n_neighbors=11).fit(XX_train, y_train)
predictions_labels = clf.predict(XX_test)

完整代码及注释如下：

代码中对预测集的前十张图像进行了显示，其中“818.jpg”图像如图所示，其分类预测的类标结果为“8”，表示第8类山峰，预测结果正确。

下图展示了“452.jpg”图像，其分类预测的类标结果为“4”，表示第4类恐龙，预测结果正确。

下图展示了“507.jpg”图像，其分类预测的类标结果为“7”，错误地预测为第7类恐龙，其真实结果应该是第5类大象。

使用KNN算法进行图像分类实验，最后算法评价的准确率（Precision）、召回率（Recall）和F值（F1-score）如图所示，其中平均准确率为0.64，平均召回率为0.55，平均F值为0.50，其结果不是非常理想。那么，如果采用CNN卷积神经网络进行分类，通过不断学习细节是否能提高准确度呢？

四.基于朴素贝叶斯算法的图像分类

下面是调用朴素贝叶斯算法进行图像分类的完整代码，调用sklearn.naive_bayes中的BernoulliNB()函数进行实验。它将1000张图像按照训练集为70%，测试集为30%的比例随机划分，再获取每张图像的像素直方图，根据像素的特征分布情况进行图像分类分析。

代码中对预测集的前十张图像进行了显示，其中“368.jpg”图像如下图所示，其分类预测的类标结果为“3”，表示第3类大卡车，预测结果正确。

下图展示了“452.jpg”图像，其分类预测的类标结果为“4”，表示第4类恐龙，预测结果正确。

使用朴素贝叶斯算法进行图像分类实验，最后预测的结果及算法评价准确率（Precision）、召回率（Recall）和F值（F1-score）如图所示。

五.总结

本篇文章主要讲解Python环境下的图像分类算法，首先普及了常见的分类算法，包括朴素贝叶斯、KNN、SVM、随机森林、神经网络等，接着通过朴素贝叶斯和KNN分别实现了1000张图像的图像分类实验，希望对读者有一定帮助，也希望这些知识点为读者从事Python图像处理相关项目实践或科学研究提供一定基础。

参考文献：

[1]冈萨雷斯著. 数字图像处理（第3版）[M]. 北京：电子工业出版社，2013.
[2]杨秀璋, 颜娜. Python网络数据爬取及分析从入门到精通（分析篇）[M]. 北京：北京航天航空大学出版社, 2018.
[3]gzq0723. 干货——图像分类（上）[EB/OL]. (2018-08-28). https://blog.csdn.net/gzq0723/
[4]article/details/.
[5]sinat_. OpenCV分类器学习心得[EB/OL]. (2016-08-03). https://blog.csdn.net/sinat_/article/details/.
[6]baidu_. 机器学习之贝叶斯算法图像分类[EB/OL]. (2018-10-10). https://blog.csdn.net/baidu_/article/details/.
[7]baidu_. 机器学习之KNN算法实现图像分类[EB/OL]. (2018-09-28). https://blog.csdn.net/baidu_/article/details/.
[8]normol. svm实现图片分类（python）[EB/OL]. (2018-11-19). https://blog.csdn.net/normol/article/details/.
[9]wfjiang. SVM-支持向量机原理详解与实践[EB/OL]. (2017-03-14). https://www.cnblogs.com/spoorer/p/6551220.html.
[10]快乐的小飞熊. 随机森林原理[EB/OL]. (2017-03-05). https://www.sigusoft.com/p/57e862d695f2.
[11]烨枫_邱. 深入理解BP神经网络[EB/OL]. (2018-06-01). https://www.sigusoft.com/p/6ab6f53874f7.
[12]smilejiasmile. 卷积神经网络(CNN)及其实践[EB/OL]. (2018-06-20). https://blog.csdn.net/smilejiasmile/article/details/.
[13] 誓天断发. 机器学习之BP神经网络算法实现图像分类[EB/OL]. (2018-10-23). https://blog.csdn.net/baidu_/article/details/.
[14] 杨秀璋. [Python人工智能] 十.Tensorflow+Opencv实现CNN自定义图像分类案例及与机器学习KNN图像分类算法对比[EB/OL]. https://blog.csdn.net/Eastmount/article/details/.

关注，第一时间了解华为云新鲜技术~

从2014年 Forrester Research 首次提出“低代码开发平台（LCAP）”这一概念开始，低代码行业便备受关注。随着 SaaS 场景的加持，aPaaS 场景也被孵化了出来。与此同时，随着近两年 Outsystems 的快速发展，让其成为一方独角兽的同时，也加速了低代码行业的进一步发展。

2022年12月1日，为进一步推进低代码/无代码技术的应用与发展，企业数字化发展共建共享平台、云计算标准和开源推进委员会（CCSA TC608）联合云智慧等企业及专家举办了“低代码/无代码应用深度探索系列沙龙”。本期沙龙中，云智慧生动形象地讲解了低代码平台在公司内部的落地实践，帮助企业及开发者更好地理解研发设计、企业协同、流程治理、数字化大屏、运维管理等众多场景低代码/无代码化。

理解企业现状痛点，推进低代码落地

云智慧专注于数据可视化大屏业务，通过将电商、金融等各行业数据与内部系统接入后，以大屏的形式简洁、快速地呈现出来。当前低代码数据可视化行业主要存在以下痛点：

技术栈太多：正常前端页面编写仅需用到 UI 框架等简单技术栈，而在可视化方面开发人员会用到很多可视化相关的技术栈，包括图表相关的 Highcharts、Echarts、D3 等技术栈；关系图、系统架构图以及网络链路图相关的 G6、Vis 等技术栈；3D 可视化相关的 Three、WebGL等技术栈。
架构复杂：数据可视化大屏的制作过程并非是各技术栈的堆砌，而是需从系统兼容性以及多端适配优化处理等方面考虑，将各技术进行有效结合。
部署复杂：以单纯业务方面部署为例（如Docker、K8S等），企业开发人员需做 Ngnix代理、网管、注册中心、缓存等方面的管理。

除上述外，对于企业低代码开发人员来讲，一方面日常工作需应对频繁变更的需求；另一方面还需面对性能兼容、高可用、国际化等方面的高复杂性；此外，还需应对技术栈、版本更新以及人员整体能力等多方面的持续变化。与此同时，对于企业来讲，一方面因企业没有统一低代码基础平台，导致大量工作重复从而开发造成人员浪费；此外，企业产品系统开发过于依赖开发人员的习惯，导致数据复用性较差以及开发质量无法保证；同时，在产品系统开发过程中，因大量简单基础的工作需要重复完成，导致降低开发效率。

低代码赋能企业，促进企业发展

云智慧作为低代码专业厂商，通过低代码为各大企业带来全新产品供给模式的同时，使各大企业更容易获得全方位的生态解决方案。此外，低代码作为效率工具，加速推进了企业数字化进程同时使企业实现规模化发展。具体主要体现在以下几方面：

增效：可视化变成所见即所得，一站式开发无需搭建环境，通过拖拉拽的形式快速生成一整套解决方案。
高质量：开箱即用的高质量组件，同一套规则、同一套标准，经过多轮测试验证发版，稳定可靠。
可复用：从原本一锤子的买卖，变成可以沉淀的资产，组件之间可以复用，数据方向可以规范标准，复用性强。
低门槛：由于低代码开发的特征，大大降低了开发的难度，使其可以非常快速搭建一套解决方案，无代码基础也可快速上手。

简洁高效，加速开发者成长

低代码作为一种全新的开发模式，相比于传统开发模式，低代码很大程度地减少了开发者代码量，使开发者通过简单地复刻及拖拉拽即可完成应用开发。另一方面，由于低代码的简单直观性，开发者也更容易发现技术应用业务过程中的问题。因此低代码更能加快开发者在技术领域的成长速度，具体表现为以下几方面：

开箱即用：云智慧低代码平台 FlyFish 通过内置多化开箱即用的数据可视化组件，使开发者可以通过拖拉拽的方式即可快速使用组件、模版完成数据可视化大屏制作。

随时随地：无需安装各类插件，云智慧在线低代码平台使开发者随时随地可开发所需数据可视化大屏。

能力复用：云智慧在线低代码平台使开发者可以看到代码配置详情，可快速进行能力复用。

减少发布流程：低代码往往作为一个aPaaS 应用，一定程度上可以省略发布流程。

新一代开发模式，云智慧 FlyFish

飞鱼平台 (FlyFish) 是云智慧公司自主设计、研发的一款低门槛、高拓展性的低代码应用开发平台，为数据可视化开发场景提供了高效的一站式解决方案。飞鱼提供丰富的组件和应用模板库，可通过拖拉拽的形式完成数据可视化开发，零开发背景的用户也可完成数据可视化开发工作。

FlyFish 整体架构如下图所示。组件与组件之间相互隔离，且通过Event调度中心与函数进行交互。数据源接入系统后，可以被封装成数据集合被大屏调用。此外，FlyFish 在渲染处理、兼容处理、通信处理、动效处理以及性能处理方面均做了优化。

云智慧在 FlyFish 的开发应用过程中成功沉淀了近千张大屏模版以及2500+应用组件。此外，FlyFish 在云智慧的整体业务应用流程中，使其效率得到了有效提升。至今，除开发人员外，云智慧内部已有30%的人员通过FlyFish开发出数据可视化大屏供个人工作所需。

最后

低代码/无代码技术作为新一代开发模式，现已成为赋能企业数字化发展转型的加速器。现如今，云智慧数据可视化编排平台 FlyFish 已开源，感兴趣的伙伴可下方链接查看详情。未来，云智慧也将联合更多企业联盟不断完善低代码应用建设，为各行业企业生态发展注入生命力。

GitHub 地址： https://github.com/CloudWise-OpenSource/FlyFish

Gitee 地址： https://gitee.com/CloudWise/fly-fish

本文转载自阿里云Hologres产品负责人合一在ITPUB的访谈，谈谈他眼中的实时数仓

这两年，企业IT领域掀起实时数仓热潮。然而，只要稍做梳理就会发现，实时数仓格局未定，各种流派群雄逐鹿，还有很多需要进一步探讨的话题方向。

比如：实时数仓是什么？如何从概念上去定义？有人认为，传统数据仓库做了实时化，就是实时数仓；有人认为，云数仓、湖仓一体是实时数仓；还有人认为，HTAP是解决实时数仓需求的一个重要手段！

再比如：实时数仓是一款产品，还是一个解决方案？99%的企业都会认为是一个解决方案，1%的企业会认为是一款产品，这1%就是阿里云！

为了弄清事实真相，帮助用户找到应用选型“快速通道”，本期实时数仓系列访谈，特邀请到阿里云自研大数据平台产品负责人刘一鸣（合一），请他从实时数仓的技术演进、应用场景、架构以及Hologres自身实践角度，一层一层揭开实时数仓的“谜团”！

阿里云自研大数据平台产品负责人刘一鸣（合一）

实时数仓进化

如果，非要给实时数仓下一个定义，一定要符合从1.0到3.0时代的进化特征。

首先，得是一个数仓，具备规模数据的交互式分析能力。实时数仓不只是“实时”，很多系统不支持标准SQL，不能算数仓。所以，属于1.0时代的实时数仓，有一个重要前提，就是支持较为完善的SQL以及优秀的大规模分析能力，因此很多系统采用了分布式、列存、索引、压缩等数仓加速的技术。

其次，面向实时场景做了针对性优化，包括实时写入、实时分析、实时取数等。如果和普通数据库相同，没有针对实时场景做优化，很难达到实时数仓对吞吐和分析的时效性要求。实时数仓需要具备高吞吐写入和更新能力，数据写入即可用，支持灵活的数据更新。比如：很多普通数据库，虽然能写也能查，但当数据规模放大到一定规模，要么牺牲了写入性能保查询，要么牺牲了查询性能优化写入，无法针对实时数据多场景进行优化，这不能算好的实时数仓。

进入2.0时代，实时数仓就要尽可能快地支持在线业务。企业之所以做实时数仓，是希望数据进来之后能够被足够新鲜地消费，能实时写入、实时分析，还要支撑在线服务。在线服务场景需要更高的性能、低抖动、稳定性、并发能力，对在线服务场景进行支持，是实时数仓关键一环。

而3.0时代的实时数仓，可以定义为一站式实时数仓。这个时候的实时数仓，不仅具有高吞吐写入与更新、端到端的全链路实时加工以及低延迟高并发在线服务能力，在保证数据一致的前提下，需要支持多种负载之间完备的隔离和弹性能力，以确保各个业务互不干扰，各自按需使用资源。同时实时数仓的使用通常离不开离线数仓的组合关系，通过离线平台对历史数据的周期性汇聚、抽象和加工，并将结果数据导入实时数仓进行丰富和修正，需要更有效地打通实时与离线两套系统，实现数据和数据的无缝交换，这也是实时数仓落地时需要具备的能力。这种一站式体现在存储状态的一致性，减少了不同负载之间的数据同步和存储开销，避免了数据服务层的数据孤岛难题。

所以，实时数仓既不是传统数据库的旧瓶装新酒，也不是湖仓一体的多产品组合，它和离线数仓的本质区别是，通过对易变数据结构（包括内存结构、文件存储）和计算资源的细粒度灵活管控，更好地支撑数据的实时写入、实时更新、实时查询 。至于，很多公司之所以把实时数仓定义为是一个解决方案，是因为技术相对更加复杂，既要考虑写入和加工能力，又要支持查询和在线分析场景，不得已针对不同技术需求将多种技术栈堆砌在一起，包括采用流式计算、消息中间件来达到端到端的实时加工，采用列式数据库应对分析需求，采用行存系统支撑在线服务系统，并依赖复杂的调度配置，实现数据在中间件、存储系统之间的最终一致性。而将复杂技术落地成为一款易于使用的成熟数仓产品，仍然是少数技术创新者在努力的方向。

阿里云Hologres，整体技术水平领先业界1-2年，是基于在阿里巴巴内部数据技术的广泛应用与沉淀，一步一步走过来的。阿里有海量数据的复杂应用场景，有历年双11等大促的深度压力测试，有在存储和计算领域深扎多年的技术专家，有上万名数据小二支持业务的灵活需求与快速迭代，这些都是其他公司不具备的得天独厚的条件，推动着阿里在数据技术领域的持续创新。

Hologres支撑的业务的规模、复杂性和对效率的极致追求，实现了通过有些开源技术组合无法达成的数据价值目标。行业内不少企业采用部分开源技术栈，如：用Kafka做中间件，用Hudi做离线存储，用Presto做离线查询加速，用ClickHouse做OLAP查询，用Flink做流式数据加工，用MySQL做缓存，用HBase做在线服务引擎。这些架构也是阿里采用过的第一代实时数仓架构，但当开发效率遇到瓶颈时，当数据链路复杂到成为运维负担时，当数据不一致不得不80%时间在对数排查时，工程师们开始思考是否还有更好的解决方案，是否有一个更加集中化、一体化、能力更全面的数仓选择。而Hologres的出现也就重新定义了实时数仓的形态。

基于此，OLAP查询和在线服务使用Hologres，满足分析的灵活和效率，离线数仓使用MaxCompute，支撑规模性和Serverless扩展性，实时流式计算用Flink，凸显端到端全实时加工，三者的结合让实时和离线计算，分析和服务都能达到一个非常好的平衡，满足业务的多种需求。

阿里云Flink版的出处与Hologres的渊源

有人可能会说，阿里云Hologres+Flink这套组合也用了Flink，和其他解决方案相比，有什么不同呢？

没错，Hologres要想发挥最佳水平，与Flink结合，一定是首选。实时计算需要后台有一套强大的大数据计算能力，而Apache Flink作为一款开源大数据流式计算技术，从设计之初就由流计算开启，相比传统的Hadoop、Spark等计算引擎，更能确保数据处理的低延时，让数据在第一时间发挥价值。

早在2016年，Apache Flink捐献给Apache之后的第三年，阿里已经开始大规模上线使用实时计算产品，用于阿里最核心的搜索推荐以及广告业务场景。2017年，基于Flink的实时计算产品，开始服务于整个阿里巴巴集团，同年双11服务全集团的数据实时化，包括双11的实时大屏。2018年，基于Flink的实时计算平台产品不仅服务于集团内部，同时开始服务于云上中小企业，以公有云的形式对外提供服务。2019年，阿里巴巴收购了Flink的创始公司-Ververica，阿里的Flink实时计算技术团队和德国总部的Flink创始团队，组成全球顶领先的Flink技术团队，共同推进整个Apache Flink开源社区的发展。

用户通过Flink可以把数据实时写入到Hologres，也可以通过Hologres做维表关联。如此一来，离线分析走MaxCompute，数据的点查、联邦分析以及OLAP分析走Hologres。举一个维表加工的例子，Flink每次加工进来之后，每一条事件都要跟维表做关联，比如：事件数据中包含了渠道ID，在分析时需要知道是什么渠道类型，因为要通过加工链路将ID还原为渠道属性，这种关联有时候每秒钟要达到上万、上十万的 QPS。过去，很多业务团队采用HBase来支撑这类点查业务，但HBase没有 Schema，数据写错很难发现，很难修正；现在，Hologres只用过去50% 的资源，支撑了HBase完整的业务。

与开源Flink相比，阿里的实时计算Flink版进行了多处核心功能的优化，在存储、网络和传输等方面都调整到满足业务场景所需要的效果。并且，阿里云Flink版和Hologres做了大量的结合优化工作，不仅支持维表到结果表，也支持通过阿里云Flink的全量读取、Binlog 读取、CDC 读取、全增量一体化等多种方式读取 Hologres 源表数据，尤其是阿里云Flink支持读取Hologres Binlog，就使得Hologres能够达到像Kafka等消息中间件同等的能力，一个 Hologres Table 的数据既可以提供给下游阿里云 Flink 任务消费，还可以对接上游 OLAP/在线服务查询，不仅节省了成本，还简化数仓架构，同时也让数仓中的每一个层次都可以实时构建、实时查询，提升数据的流转效率。在数据管理方面，阿里云Flink版与Hologres数据打通，支持Hologres Catalog，实现数据的自动发现和管理，也大大简化了开发和运维管理工作。

HSAP分析服务一体化的独特之处

Hologres是两个英文单词的组合，即Holographic+Postgres，Holographic来源于物理学，Postgres代表的是PostgreSQL生态。

从物理学原理看，地球没有被黑洞吸进去，是因为有一个临界点，这个临界点所组成的面，被证明是一个球面，也叫世界面。与此同时，黑洞里所有信息在世界面上都有投影，即3D全息投影技术。Hologres想做的事情是，通过产品化的能力对数据黑洞做全息展示。

为了简化数据存储和统一数据服务，阿里云提出了HSAP架构理论 (Hybrid Serving & Analytical Processing，后续简称HSAP)，而Hologres是实践HSAP目标的一个具体实现。Hologres的目标是，做分析服务一体化的实时数仓，典型特征是：存算分离的云原生架构、多负载隔离、端到端实时毫秒级的交互式分析体验、超高QPS的在线服务能力等。从应用场景来看，既可满足实时数仓的需求，也能对离线数据进行查询加速，同时还可实现实时与离线数据的联邦计算，为用户构筑全链路、精细化运营能力。

为什么说分析服务一体化能力特别重要呢？

以广告推荐为例，这是一个非常典型的在线服务场景，如果一个人收藏了一个链接，他就会获得相应的广告推荐，该推荐包含了你过去30 天、60天或者90 天里的行为，还包括你的教育程度、家庭关系，这些是典型的离线特征。对于后端技术平台来说，这些行为不用每天去算，每周算一次就可以。但另一部分特征是实时的，比如你当下点了什么内容，对什么感兴趣，跳转了什么链接，这部分行为就需要通过Flink 这样的流式计算实时处理。只有把实时和离线两部分信息结合起来做推荐，才有全面的360信息，使得推荐更加精准，更加具备上下文相关性。

过去，没有Hologres之前，如果一个大数据系统要支撑广告推荐业务需要写一条很长的链路，反复同步数据，这很难提供灵活敏捷的数据服务，大量数据作业开发成本很高，出现数据不一致等问题。阿里的工程师尝试把问题简化，让数据不动，通过Flink或者MaxCompute加工好的数据，直接提供在线服务，这就需要把Serving场景做强，面向应用程序，或者面向API 消费数据的场景时，要有高QPS、低延迟能力。

而针对Analytics能力，很多企业都会基于OLAP引擎做数据分析。这部分数据一般会有两个出口：一个出口是给机器使用，通过API访问，主要是推荐系统和风控系统；另一个出口是给分析师使用，通过SQL访问，看报表，做对比分析，找到趋势变化。这两个出口的数据需要保持一致性。Hologres作为交互式分析引擎，针对两个场景做了执行优化。在支持在线的高 QPS 服务型查询时，这类查询逻辑相对简单，但并发高，因此采用了Short-Cut技术，通过FixedPlan执行优化，减少在SQL解析优化和调度层的开销，请求直达存储节点，延迟更短；在支持分析师的复杂多维分析时，采用MPP分布式计算框架、列式存储和向量化引擎，有效率大范围过滤数据，保障了亿级数据的秒级数据分析。这样，通过Hologres统一数据服务出口，同时支持在线服务和多维分析两个场景。

Hologres借鉴了主流的数据架构，包括采用类似LSM-tree(Log-Structured Merge Tree)这种高吞吐写入和更新友好的存储架构，利用了CPU指令向量化、异步化的最新技术创新，基于云原生的计算存储分离架构，形成了一款低门槛的生产级产品。Hologres在协议层面上用到了PostgreSQL的这种协议，简化了与业务系统的对接，应用无需重写，也没有厂商引擎绑定，开箱即用，核心的存储引擎、查询引擎是阿里自研的一套系统，持续改进效率、稳定和易用。

Lambda 与Kappa的纷争

其实，最早阿里云没想到要做实时数仓，只是想把实时和离线数据实现一体化。

换言之，阿里云的HSAP架构也是由Lambda架构走过来的。众所周知，Lambda架构有一个优势，既支持流式数仓，又能满足离线数仓的计算要求；但是也有一个弊端，就是流和批分为两套技术栈，运维要维护两套系统架构。后来，Kappa架构出现，有人认为能很好地解决Lambda架构的问题，但事实并非如此。因为企业的数据加工永远会有实时和离线两条链路，这是数据加工作业的属性决定的。实时链路数据总会晚来，或者不来，数据质量并不可靠。所以，只有实时链路，解决不了数据质量问题，还需要离线链路对实时链路的修正和丰富，而依赖消息中间件支撑海量数据的回刷是成本极高及不稳定的架构。也就是说，只要有离线场景，Lambda架构就有存在的合理性。

但问题是，Lambda架构一定需要两套系统，这该如何解决？本质上，还是技术的割裂，导致架构不统一。好的Lambda架构，应该是状态层统一的，实时的业务逻辑和离线的业务逻辑尽管加工链路不同，但存储层应该统一，减少数据割裂和不一致，通过实时和离线两套业务逻辑相互补充，离线的业务逻辑对实时数据链路进行修正。

在Lambda架构实践过程中，很多企业实时业务用HBase，离线业务用Hive，这种存储割裂状态，导致数据不一致，口径不一致。正确的架构选择应该是Lambda的改进版，把数据状态统一存储在一个存储系统，这个存储同时支持离线批量导入，也支持实时更新与查询，这也是一种可落地的批流一体实践。

虽然，有些企业在推Kappa，但从实践的角度看，Kappa其实是个伪概念，因为实时业务系统如果取代离线，意味着数据要频繁地修正、更新，而Kappa无法从根本上解决这个问题。目前，推Kappa架构的企业，大部分是消息中间件厂商，或者一些纯粹做实时的团队。他们假设了一种状态，所有的数据都可以通过消息中间件恢复。但现实是，企业不会把所有的状态都通过消息中间件去回放，或者长期存储。所以，通过消息中间件替代数据库的方式，只有消息中间件厂商在力推，不具备广泛落地的参考意义。

在阿里内部，HSAP架构把分析和服务两个场景放在一起，解决了数据不一致问题，减少了数据同步的开销，避免了数据孤岛，数据加工链路保持了实时和离线双链路，实时业务系统解决时效性问题，离线可以为实时业务系统进行修正和丰富，两条链路各解决各自的问题，使得实时和离线由一套系统承载，也就真正实现了流批一体。

下一代实时数仓更重实操

到今天为止，Hologres作为标准产品对外提供服务已经两年多，每年客户数都是三位数增长。在实践中，60%的用户主要使用OLAP场景，20%主要使用Serving场景，还有20%做到了HSAP混合负载的优化架构，通过技术创新为企业降本提效。实时数仓还处于发展过程中，相信随着大数据的不断推动，实时数仓会成为推动业务发展的“有力抓手”。

过去，数据团队更偏内部业务场景，主要的工作就是给管理层出报表，做领导驾驶舱。但在今天，数据团队正从成本中心转为盈利中心，大数据团队要想去影响业务，提升价值感，包括风控、实时画像、实时推荐等手段，是提升业务的主要入口，这也是实时数仓需求快速增长的最根本原因。实时数仓会成为大数据平台里一个重要组成部分，是数据消费端的核心组件。

当然，实时数仓并不是一个新事物，从有数仓开始，用户需求一直存在。但是，因为方案的不成熟，很多都是由开源组件堆在一起，从开发和运维成本上看，技术门槛比较高，导致实时数仓没有实现规模化发展。企业必须招聘来自BAT的人才才能玩得转实时数仓，这个是不正常的，也不是时代发展的趋势，技术一定会普惠化，所有的企业都会用上大数据，但不应该所有的企业都成为技术专家。

真正受市场欢迎的实时数仓产品，简单、易用是前提，能处理海量数据，不用懂很多参数，不用写很多程序，能做到只会写SQL就可以上手。另外，企业希望数据写进来就能用，尽量减少数据加工过程，减少数据链条，实现敏捷化。即使业务方突然提出一个新需求，只要改下SQL就可以了，不用做任何数据重刷，对开发效率提升来说，带来的是根本性的转变。

所以，下一代实时数仓到底如何发展？ Hologres已经“打好样”！那就是技术门槛会越来越低，同时计算力会越来越强大，使用方式越来越简单，不仅数据能实时写得进来，还要在原始数据上直接做分析，查询要足够快，并发足够高，取数不用等，需求不求人。希望通过Hologres这样的产品，能够将实时数仓变得更加普惠化、敏捷化，让各行各业的数智化建设迈上新台阶。

亲爱的社区小伙伴们，经历数月的等候，我们很高兴地宣布，Apache Doris 于 2022 年 12 月 7 日迎来了 1.2.0 Release 版本的正式发布！有近 118 位 Contributor 为 Apache Doris 提交了超 2400 项优化和修复，感谢每一位让 Apache Doris 更好的你！

自从社区正式确立 LTS 版本管理机制后，在 1.1.x 系列版本中不再合入大的功能，仅提供问题修复和稳定性改进，力求满足更多社区用户在稳定性方面的高要求。而综合考虑版本迭代节奏和用户需求后，我们决定将众多新特性在 1.2.0 版本中发布，这无疑承载了众多社区用户和开发者的深切期盼，同时也是一场厚积而薄发后的全面进化！

在 1.2 版本中，我们实现了全面向量化、实现多场景查询性能3-11 倍的提升，在 Unique Key 模型上实现了 Merge-on-Write 的数据更新模式、数据高频更新时查询性能提升达 3-6 倍，增加了 Multi-Catalog 多源数据目录、提供了无缝接入 Hive、ES、Hudi、Iceberg 等外部数据源的能力，引入了 Light Schema Change 轻量表结构变更、实现毫秒级的 Schema Change 操作并且可以借助 Flink CDC 自动同步上游数据库的 DML 和 DDL 操作，以 JDBC 外部表替换了过去的 ODBC 外部表，支持了 Java UDF 和 Romote UDF 以及 Array 数组类型和 JSONB 类型，修复了诸多之前版本的性能和稳定性问题，推荐大家下载和使用！

下载安装

GitHub下载： https://github.com/apache/doris/releases

官网下载页： https://doris.apache.org/download

源码地址： https://github.com/apache/doris/releases/tag/1.2.0-rc04

下载说明

由于 Apache 服务器对文件大小限制，官网下载页的 1.2.0 版本的二进制程序分为三个包：

apache-doris-fe
apache-doris-be
apache-doris-java-udf-jar-with-dependencies

其中新增的包用于支持 1.2 版本中的 JDBC 外表和 JAVA UDF 新功能。下载后需要将其文件放到目录下，方可启动 BE，否则无法启动成功。

为了便于大家下载使用，我们将预编译好的二进制程序提前打包好，该版本基于 Apache Doris 1.2.0 正式版，仅内置了 java8 运行时环境，复制下方链接到浏览器下载，解压后即可使用。

下载链接：

ARM64：https://selectdb-doris-.cos.ap-beijing.myqcloud.com/release/selectdb-doris-1.2.0-arm.tar.gz
x86：https://selectdb-doris-.cos.ap-beijing.myqcloud.com/release/selectdb-doris-1.2.0-x86_64-no-avx2.tar.gz
x86_no_avx2：https://selectdb-doris-.cos.ap-beijing.myqcloud.com/release/selectdb-doris-1.2.0-x86_64-no-avx2.tar.gz

部署说明

从历史版本升级到 1.2.0 版本，需完整更新 fe、be 下的 bin 和 lib 目录。

其他升级注意事项，请完整阅读以下文档：

本通告最后一节「升级注意事项」
安装部署文档：https://doris.apache.org/zh-CN/docs/dev/install/install-deploy
集群升级文档：https://doris.apache.org/zh-CN/docs/dev/admin-manual/cluster-management/upgrade

如在版本升级、功能验证、生产上线等过程中出现问题，可以在社区用户群中寻求 SelectDB 专职技术工程师帮助。

重要更新

全面向量化支持，性能大幅提升

在 Apache Doris 1.2.0 版本中，系统所有模块都实现了向量化，包括数据导入、Schema Change、Compaction、数据导出、UDF 等。新版向量化执行引擎具备了完整替换原有非向量化引擎的能力，后续我们也将考虑在未来版本中去除原有非向量化引擎的代码。

与此同时，在全面向量化的基础上，我们对数据扫描、谓词计算、Aggregation 算子、HashJoin 算子、算子之间 Shuffle 效率等进行了全链路的优化，使得查询性能有了大幅提升。

我们对 Apache Doris 1.2.0 新版本进行了多个标准测试集的测试，同时选择了 1.1.3 版本和 0.15.0 版本作为对比参照项。经测，1.2.0 在 SSB-Flat 宽表场景上相对 1.1.3 版本整体性能提升了近 4 倍、相对于 0.15.0 版本性能提升了近 10 倍，在 TPC-H 多表关联场景上较 1.1.3 版本上有近 3 倍的提升、较 0.15.0 版本性能至少提升了 11 倍。

图1 SSB

图2 TPC-H

同时，我们将1.2.0版本的测试数据提交到了全球知名数据库测试排行榜 ClickBench，在最新的排行榜中，Apache Doris 1.2.0 新版本取得了通用机型（c6a.4xlarge, 500gb gp2）下查询性能 Cold Run 第二和 Hot Run 第三的醒目成绩，共有 8 个 SQL 刷新榜单最佳成绩、成为新的性能标杆。导入性能方面，1.2.0 新版本数据写入效率在同机型所有产品中位列第一，压缩前 70G 数据写入仅耗时 415s、单节点写入速度超过 170 MB/s，在实现极致查询性能的同时也保证了高效的写入效率！

图3 Cold Run

图4 Hot Run

UniqueKey 模型实现 Merg-On-Write 数据更新模式

在过去版本中， Apache Doris 主要是通过 Unique Key 数据模型来实现数据实时更新的。但由于采用的是 Merge-On-Read 的实现方式，查询存在着效率瓶颈，有大量非必要的 CPU 计算资源消耗和 IO 开销，且可能将出现查询性能抖动等问题。

在 1.2.0 版本中，我们在原有的 Unique Key 数据模型上，增加了 Merge-On-Write 的数据更新模式。 该模式在数据写入时即对需要删除或更新的数据进行标记，始终保证有效的主键只出现在一个文件中（即在写入的时候保证了主键的唯一性），不需要在读取的时候通过归并排序来对主键进行去重，这对于高频写入的场景来说，大大减少了查询执行时的额外消耗。此外还能够支持谓词下推，并能够很好利用 Doris 丰富的索引，在数据 IO 层面就能够进行充分的数据裁剪，大大减少数据的读取量和计算量，因此在很多场景的查询中都有非常明显的性能提升。

在比较有代表性的 SSB-Flat 数据集上，通过模拟多个持续导入场景，新版本的大部分查询取得了 3-6 倍的性能提升。

使用场景： 所有对主键唯一性有需求，需要频繁进行实时 Upsert 更新的用户建议打开。
使用说明： 作为新的 Feature 默认关闭，用户可以通过在建表时添加下面的 Property 来开启：

另外新版本 Merge-On-Write 数据更新模式与旧版本 Merge-On-Read 实现方式存在差异，因此已经创建的 Unique Key 表无法直接通过 Alter Table 添加 Property 来支持，只能在新建表的时候指定。如果用户需要将旧表转换到新表，可以使用的方式来实现。

Multi Catalog 多源数据目录

Multi-Catalog 多源数据目录功能的目标在于能够帮助用户更方便对接外部数据目录，以增强 Apache Doris 的数据湖分析和联邦数据查询能力。

在过去版本中，当我们需要对接外部数据源时，只能在 Database 或 Table 层级对接。当外部数据目录 Schema 发生变化、或者外部数据目录的 Database 或 Table 非常多时，需要用户手工进行一一映射，维护量非常大。1.2.0 版本新增的多源数据目录功能为 Apache Doris 提供了快速接入外部数据源进行访问的能力，用户可以通过命令连接到外部数据源，Doris 会自动映射外部数据源的库、表信息。之后，用户就可以像访问普通表一样，对这些外部数据源中的数据进行访问，避免了之前用户需要对每张表手动建立外表映射的复杂操作。

目前能支持以下数据源：

Hive Metastore：可以访问包括 Hive、Iceberg、Hudi 在内的数据表，也可对接兼容 Hive Metastore 的数据源，如阿里云的 DataLake Formation，同时支持 HDFS 和对象存储上的数据访问。
Elasticsearch：访问 ES 数据源。
JDBC：支持通过 JDBC 访问 MySQL 数据源。

注：相应的权限层级也会自动变更，详见「升级注意事项」部分

相关文档：

https://doris.apache.org/zh-CN/docs/dev/ecosystem/external-table/multi-catalog

轻量表结构变更 Light Schema Change

在过去版本中，SchemaChange是一项相对消耗比较大的工作，需要对数据文件进行修改，在集群规模和表数据量较大时执行效率会明显降低。同时由于是异步作业，当上游Schema发生变更时，需要停止数据同步任务并手动执行SchemaChange，增加开发和运维成本的同时还可能造成消费数据的积压。

在 1.2.0 新版本中，对数据表的加减列操作，不再需要同步更改数据文件，仅需在 FE 中更新数据即可，从而实现毫秒级的 Schema Change 操作，且存在导入任务时效率的提升更为显著。与此同时，使得 Apache Doris 在面对上游数据表维度变化时，可以更加快速稳定实现表结构同步，保证系统的高效且平稳运转。如用户可以通过 Flink CDC，可实现上游数据库到 Doris 的 DML 和 DDL 同步，进一步提升了实时数仓数据处理和分析链路的时效性与便捷性。

使用说明： 作为新的 Feature 默认关闭，用户可以通过在建表时添加下面的 Property 来开启：

相关文档：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Data-Definition-Statements/Create/CREATE-TABLE

JDBC 外部表

在过去版本中，Apache Doris 提供了 ODBC 外部表的方式来访问 MySQL、Oracle、SQL Server、PostgreSQL 等数据源，但由于 ODBC 驱动版本问题可能造成系统的不稳定。相对于 ODBC，JDBC 接口更为统一且支持数据库众多，因此在 1.2.0 版本中我们实现了 JDBC 外部表以替换原有的 ODBC 外部表。在新版本中，用户可以通过 JDBC 连接支持 JDBC 协议的外部数据源，当* 前已适配的数据源包括*：

MySQL
PostgreSQL
Oracle
SQLServer
ClickHouse

更多数据源的适配已经在规划之中，原则上任何支持 JDBC 协议访问的数据库均能通过 JDBC 外部表的方式来访问。而之前的 ODBC 外部表功能将会在后续的某个版本中移除，还请尽量切换到 JDBC 外表功能。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/ecosystem/external-table/jdbc-of-doris/

JAVA UDF

在过去版本中，Apache Doris 提供了 C++ 语言的原生 UDF，便于用户通过自己编写自定义函数来满足特定场景的分析需求。但由于原生 UDF 与 Doris 代码耦合度高、当 UDF 出现错误时可能会影响集群稳定性，且只支持 C++ 语言，对于熟悉 Hive、Spark 等大数据技术栈的用户而言存在较高门槛，因此在 1.2.0 新版本我们增加了 Java 语言的自定义函数，支持通过 Java 编写 UDF/UDAF，方便用户在 Java 生态中使用。同时，通过堆外内存、Zero Copy 等技术，使得跨语言的数据访问效率大幅提升。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/ecosystem/udf/java-user-defined-function

示例：

https://github.com/apache/doris/tree/master/samples/doris-demo

Remote UDF

远程 UDF 支持通过 RPC 的方式访问远程用户自定义函数服务，从而彻底消除用户编写 UDF 的语言限制，用户可以使用任意编程语言实现自定义函数，完成复杂的数据分析工作。

相关文档：

https://doris.apache.org/zh-CN/docs/ecosystem/udf/remote-user-defined-function

示例：

https://github.com/apache/doris/tree/master/samples/doris-demo

Array/JSONB 复合数据类型

Array 类型

支持了数组类型，同时也支持多级嵌套的数组类型。在一些用户画像，标签等场景，可以利用 Array 类型更好的适配业务场景。同时在新版本中，我们也实现了大量数组相关的函数，以更好的支持该数据类型在实际场景中的应用。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Data-Types/ARRAY

相关函数：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-functions/array-functions/array

JSONB 类型

支持二进制的 JSON 数据类型 JSONB。该类型提供更紧凑的 JSONB 编码格式，同时提供在编码格式上的数据访问，相比于使用字符串存储的 JSON 数据，有数倍的性能提升。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Data-Types/JSONB

相关函数：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-functions/json-functions/jsonb_parse

DateV2/DatatimeV2 新版日期/日期时间数据类型

支持 DataV2 日期类型和 DatatimeV2 日期时间类型，相较于原有的 Data 和 Datatime 效率更高且支持最多到微秒的时间精度，建议使用新版日期类型。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Data-Types/DATETIMEV2/
https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Data-Types/DATEV2

影响范围：

用户需要在建表时指定 DateV2 和 DatetimeV2，原有表的 Date 以及 Datetime 不受影响。
Datev2 和 Datetimev2 在与原来的 Date 和 Datetime 做计算时（例如等值连接），原有类型会被cast 成新类型做计算
Example 相关文档中说明

全新内存管理框架

在 Apache Doris 1.2.0 版本中我们增加了全新的内存跟踪器（Memory Tracker），用以记录 Doris BE 进程内存使用，包括查询、导入、Compaction、Schema Change 等任务生命周期中使用的内存以及各项缓存。通过 Memory Tracker 实现了更加精细的内存监控和控制，大大减少了因内存超限导致的 OOM 问题，使系统稳定性进一步得到提升。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/admin-manual/maint-monitor/memory-management/memory-tracker

Table Valued Function 表函数

增加了 Table Valued Function（TVF，表函数），TVF 可以视作一张普通的表，可以出现在 SQL 中所有“表”可以出现的位置，让用户像访问关系表格式数据一样，读取或访问来自 HDFS 或 S3 上的文件内容，

例如使用 S3 TVF 实现对象存储上的数据导入：

或者直接查询 HDFS 上的数据文件：

TVF 可以帮助用户充分利用 SQL 丰富的表达能力，灵活处理各类数据。

相关文档：

https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-functions/table-functions/s3
https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-functions/table-functions/hdfs

升级注意事项

FE 数据版本变更【重要】

FE Meta Version 由 107 变更为 114，因此从 1.1.x 以及更早版本升级至 1.2.0 版本后，不可回滚到之前版本。

升级过程中，建议通过灰度升级的方式，先升级部分节点并观察业务运行情况，以降低升级风险，若执行非法的回滚操作将可能导致数据丢失与损坏。

行为改变

权限层级变更，因为引入了 Catalog 层级，所以相应的用户权限层级也会自动变更。规则如下：
- GlobalPrivs 和 ResourcePrivs 保持不变
- 新增 CatalogPrivs 层级。
- 原 DatabasePrivs 层级增加 internal 前缀（表示 internal catalog 中的 db）
- 原 TablePrivs 层级增加 internal 前缀（表示internal catalog中的 tbl）
GroupBy 和 Having 子句中，优先使用列名而不是别名进行匹配。
不再支持创建以 “mv ” 开头的列。”mv” 是物化视图中的保留关键词
移除了 orderby 语句默认添加的 65535 行的 Limit 限制，并增加 Session 变量可以自定配置这个限制。
“Create Table As Select” 生成的表，所有字符串列统一使用 String 类型，不再区分 varchar/char/string
audit log 中，移除 db 和 user 名称前的字样。
audit log 中增加 sql digest 字段
union 子句总 order by 逻辑变动。新版本中，order by 子句将在 union 执行完成后执行，除非通过括号进行显式的关联。
进行 Decommission 操作时，会忽略回收站中的 Tablet，确保 Decomission 能够完成。
Decimal 的返回结果将按照原始列中声明的精度进行显示，或者按照显式指定的 Cast 函数中的精度进行展示。
列名的长度限制由 64 变更为 256
FE 配置项变动
- 默认开启参数。
- 增大了值。建表操作的默认超时时间将增大。
- 修改默认值为 3天。
- 修改的默认值为一个月。
- 增加参数用于限制 alter 作业中涉及的 Replica 数量，默认为。
- 添加。默认禁用了 Iceberg 和 Hudi 外表，推荐使用 Multi Catalog功能。
BE 配置项变动
- 移除了参数。2PC的 Stream Load 可直接使用。
- 修改从 1800 秒修改为 300 秒。
Session 变量变动
- 修改变量默认为 true。这会导致一些之前可以执行，但是插入了非法值的 insert 操作，不再能够执行。
- 修改变量默认为 true
- 默认通过 lz4 压缩进行数据传输，通过变量控制
- 增加变量，用于调试 Unique 或 Agg 模型的数据。相关* *文档：https://doris.apache.org/zh-CN/docs/dev/advanced/variables
BE 启动脚本会通过检查数值是否大于200W，否则启动失败。
移除了 mini load 接口

升级过程需注意

升级准备

需替换：lib, bin 目录（start/stop 脚本均有修改）
BE 也需要配置，已支持 JDBC Table 和 Java UDF。
中默认参数修改为 8GB。

升级过程中可能的错误

Repeat 函数不可使用并报错：，可以在升级前先关闭向量化执行引擎。
Schema Change 失败并报错：desc_tbl is not set. Maybe the FE version is not equal to the BE
向量化 Hash Join 不可使用并报错。vectorized hash join cannot be executed可以在升级前先关闭向量化执行引擎。

以上错误在完全升级后会恢复正常。

性能影响

默认使用 JeMalloc 作为新版本 BE 的内存分配器，替换 TcMalloc 。JeMalloc 相比 TcMalloc 使用的内存更少、高并发场景性能更高，但在内存充足的性能测试时，TcMalloc 比 JeMalloc 性能高5%-10%，详细测试见: https://github.com/apache/doris/pull/12496
中修改为至少 8K。
默认关闭 Page Cache 和减少 Chunk Allocator 预留内存大小。

Page Cache 和 Chunk Allocator 分别缓存用户数据块和内存预分配，这两个功能会占用一定比例的内存并且不会释放。由于这部分内存占用无法灵活调配，导致在某些场景下可能因这部分内存占用而导致其他任务内存不足，影响系统稳定性和可用性，因此新版本中默认关闭了这两个功能。

但在某些延迟敏感的报表场景下，关闭该功能可能会导致查询延迟增加。如用户担心升级后该功能对业务造成影响，可以通过在中增加以下参数以保持和之前版本行为一致。

API 变化

BE 的 HTTP API 错误返回信息，由变更为更具体的{“status”:”Notfound”,”msg”:”Tabletnotfound.tablet_id=1202″}
中， Comment 的内容由双引号包裹变为单引号包裹
支持普通用户通过 HTTP 命令获取 Query Profile。相关文档：https://doris.apache.org/zh-CN/docs/dev/admin-manual/http-actions/fe/manager/query-profile-action
优化了 Sequence 列的指定方式，可以直接指定列名。相关文档：https://doris.apache.org/zh-CN/docs/dev/data-operate/update-delete/sequence-column-manual
和返回结果中，增加远端存储的空间使用情况
移除了 Num-Based Compaction 相关代码
重构了BE的错误码机制，部分返回的错误信息会发生变化

其他

支持 Docker 官方镜像。
支持在 MacOS(x86/M1) 和 ubuntu-22.04 上编译 Doris。
支持进行 image 文件的校验。相关文档：https://doris.apache.org/zh-CN/docs/dev/admin-manual/maint-monitor/metadata-operation
脚本相关
- FE、BE 的 stop 脚本支持通过参数退出FE、BE（使用 kill -15 信号代替 kill -9）
- FE start 脚本支持通过查看当前FE 版本
支持通过 ADMIN COPY TABLET命令获取某个 tablet 的数据和相关建表语句，用于本地问题调试。相关文档：https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Database-Administration-Statements/ADMIN-COPY-TABLET
支持通过 http api，获取一个SQL语句相关的建表语句，用于本地问题复现。相关文档：https://doris.apache.org/zh-CN/docs/dev/admin-manual/http-actions/fe/query-schema-action
支持建表时关闭此表的 Compaction 功能，用于测试。相关文档：https://doris.apache.org/zh-CN/docs/dev/sql-manual/sql-reference/Data-Definition-Statements/Create/CREATE-TABLE

致谢

Apache Doris 1.2.0 版本的发布离不开所有社区用户的支持，在此向所有参与版本设计、开发、测试、讨论的社区贡献者们表示感谢，他们分别是（首字母排序）：

贡献者名单

@aliou

@adonis0147

@Aiden-Dong

@aiwenmo

@AshinGau

@b19mud

@BePPPower

@BiteTheDDDDt

@bridgeDream

@ByteYue

@caiconghui

@CalvinKirs

@cambyzju

@caoliang-web

@carlvinhust2012

@catpineapple

@ccoffline

@chenlinzhong

@chovy-3012

@coderjiang

@cxzl25

@dataalive

@dataroaring

@dependabot

@dinggege1024

@DongLiang-0

@Doris-Extras

@eldenmoon

@EmmyMiao87

@englefly

@FreeOnePlus

@Gabriel39

@gaodayue

@geniusjoe

@gj-zhang

@gnehil

@GoGoWen

@HappenLee

@hello-stephen

@Henry2SS

@hf

@huyuanfeng2018

@jacktengg

@jackwener

@jeffreys-cat

@Jibing-Li

@JNSimba

@Kikyou1997

@Lchangliang

@LemonLiTree

@lexoning

@liaoxin01

@lide-reed

@link3280

@liutang123

@liuyaolin

@LOVEGISER

@lsy3993

@luozenglin

@luzhijing

@madongz

@morningman

@morningman-cmy

@morrySnow

@mrhhsg

@Myasuka

@myfjdthink

@nextdreamblue

@pan3793

@pangzhili

@pengxiangyu

@platoneko

@qidaye

@qzsee

@SaintBacchus

@SeekingYang

@smallhibiscus

@sohardforaname

@song7788q

@spaces-X

@ssusieee

@stalary

@starocean999

@SWJTU-ZhangLei

@TaoZex

@timelxy

@Wahno

@wangbo

@wangshuo128

@wangyf0555

@weizhengte

@weizuo93

@wsjz

@wunan1210

@xhmz

@xiaokang

@xiaokangguo

@xinyiZzz

@xy720

@yangzhg

@Yankee24

@yeyudefeng

@yiguolei

@yinzhijian

@yixiutt

@yuanyuan8983

@zbtzbtzbt

@zenoyang

@zhangboya1

@zhangstar333

@zhannngchen

@ZHbamboo

@zhengshiJ

@zhenhb

@zhqu

@zuochunwei

@zy-kkk

— END —

专业全职团队技术支持
直接和社区专家交流，获取免费且专业回复
认识不同行业的开发者，收获知识以及合作机会
Apache Doris 最新版本优先体验权
获取一手干货和资讯以及活动优先参与权

更新内容：

1，应用绑定默认https域名
2，ssl证书管理
3，可根据服务器筛选发布记录
4，应用配置UI优化

BUG修复：
1，新建项目/应用后，导航栏未立即显示，需刷新页面
2，应用首次选择设定发布目录后，没有立即显示，需刷新页面
3，用户编辑资料页无法打开
4，应用在线编辑器，高度未自适应

网址：https://www.oauthapp.com/

文档：https://web.oauthapp.com/4/docs

漏洞描述

TensorFlow 是一个用于机器学习的开源平台。

受影响版本的 TensorFlow 中由于 MakeGrapplerFunctionItem 函数采用固定大小的输入和输出参数，导致用户的输入大于或等于输出的大小时存在越界写入漏洞，攻击者可利用此漏洞造成程序拒绝服务。

漏洞名称 TensorFlow 存在越界写入漏洞漏洞类型跨界内存写发现时间 2022-12-07 漏洞影响广度一般 MPS编号 MPS-2022-58539 CVE编号 CVE-2022-41902 CNVD编号 –

影响范围

tensorflow-cpu@[2.10.0, 2.10.1)

tensorflow-gpu@(-∞, 2.8.4)

tensorflow-gpu@[2.10.0, 2.10.1)

tensorflow@[2.9.0, 2.9.3)

tensorflow@[2.10.0, 2.10.1)

tensorflow-cpu@[2.9.0, 2.9.3)

tensorflow-cpu@(-∞, 2.8.4)

tensorflow@(-∞, 2.8.4)

tensorflow-gpu@[2.9.0, 2.9.3)

修复方案

将组件 tensorflow-cpu 升级至 2.10.1 及以上版本

将组件 tensorflow-gpu 升级至 2.8.4 及以上版本

将组件 tensorflow 升级至 2.10.1 及以上版本

将组件 tensorflow-cpu 升级至 2.9.3 及以上版本

将组件 tensorflow-cpu 升级至 2.8.4 及以上版本

将组件 tensorflow 升级至 2.8.4 及以上版本

将组件 tensorflow-gpu 升级至 2.10.1 及以上版本

将组件 tensorflow 升级至 2.9.3 及以上版本

将组件 tensorflow-gpu 升级至 2.9.3 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-58539

https://nvd.nist.gov/vuln/detail/CVE-2022-41902

https://github.com/tensorflow/tensorflow/security/advisories/GHSA-cg88-rpvp-cjv5

https://github.com/tensorflow/tensorflow/commit/a65411a1d69edfb16b25907ffb8f73556ce36bb7

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

Kodexplorer 是一个基于 Web 的文件管理器和基于 Web IDE / 浏览器的代码编辑器。

Kodexplorer 4.50 之前版本中由于 request_url_safe 函数未对用户传入的 url 参数进行有效过滤，导致未经身份验证的远程攻击者可通过恶意构造的 url 字符串（如：/）进行路径遍历攻击，进而获取 Kodexplorer 主机进程可访问的任意文件。

漏洞名称 Kodexplorer <4.50 存在路径遍历漏洞漏洞类型路径遍历发现时间 2022-12-07 漏洞影响广度极小 MPS编号 MPS-2022-65547 CVE编号 CVE-2022-46154 CNVD编号 –

影响范围

kalcaddle/KodExplorer@(-∞, 4.50)

修复方案

将组件 kalcaddle/KodExplorer 升级至 4.50 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65547

https://nvd.nist.gov/vuln/detail/CVE-2022-46154

https://github.com/kalcaddle/KodExplorer/security/advisories/GHSA-6f8p-4w5q-j5j2

https://github.com/kalcaddle/KodExplorer/commit/1f7072c0ef10ee8cda82c004f04be98c

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

pdfmake 是一个支持服务端/客户端 PDF 打印的开源代码库。

pdfmake 0.2.6及之前版本中由于 server.js 类中存在远程代码执行漏洞，漏洞源于用于创建 PDF 的 “/api”端点中的 eval 方法不会清理用户输入进行过滤，执行也不会在沙盒环境中进行。攻击者可利用此漏洞发送恶意的 POST 请求远程执行恶意代码。

漏洞名称 pdfmake <=0.2.6 存在远程代码执行漏洞漏洞类型代码注入发现时间 2022-12-07 漏洞影响广度极小 MPS编号 MPS-2022-65554 CVE编号 CVE-2022-46161 CNVD编号 –

影响范围

pdfmake@(-∞, 0.3.0-beta.1)

修复方案

升级pdfmake到 0.3.0-beta.1 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65554

https://nvd.nist.gov/vuln/detail/CVE-2022-46161

https://securitylab.github.com/advisories/GHSL-2022-068_pdfmake/

https://github.com/bpampuch/pdfmake/blob/ac6de68a0bd0931b74150b33da0dd18/dev-playground/server.js#L32

https://github.com/bpampuch/pdfmake/commit/c153a2502d1625a56b3c29324a4fddedb75aa394

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

大家好，我是 Kagol，Vue DevUI 开源组件库和 EditorX 富文本编辑器创建者，专注于前端组件库建设和开源社区运营。

前两天检视代码时，发现PR里面有两个提交的描述信息一模一样，于是我提出应该将这两个提交合并成一个，保持提交树的清晰。

1 先储存起来！

而同事这时正在开发别的特性，工作区不是干净的，没法直接执行 git rebase 操作，于是很自然地执行

将正在修改的内容保存到一个栈中，并维持当前工作区干净。

这样就可以执行切换分支、变基等操作，这些操作能执行的前提是当前工作区是干净的。

2 使用 git rebase 合并两个提交

我们先执行 git log 命令，找到要合并的两个提交之前的那个提交：

然后执行 git rebase 变基命令：

这时会进入一个交互式命令行界面：

这时你可以移动光标，但是无法输入字符，因为这是个只读的界面，需要先输入 i 字符进入编辑态，此时界面底部会出现标识。

下面那些以 # 开头的都是注释，只有前面两行比较关键。

每一行都由三部分组成：

Command：需要执行的命令
Commit ID：提交 ID
Commit message：提交的描述信息

我们需要将 ec0218f 合并到 89f3d02 上，因此需要将第二行的 pick 改成 squash(s) 或 fixup(f)，这两个命令的区别在于：

squash(s) 是将当前的提交合并到上一行的提交上，保留两个提交的描述信息，可以在下一步中进行提交信息的编辑
fixup(f) 也是将当前的提交合并到上一行的提交上，但不保留当前提交的描述信息

由于我们两次提交信息完全一致，没必要保留，选择 fixup(f)：

修改好之后，先按 ESC 退出编辑态，然后按 :wq 保存，显示以下信息说明变基成功，两个提交已经合并在一起

执行 git log 看下效果：

可以看到两个提交已经合并在一起，并且生成了一个新的 Commit ID: 86930d03。

3 我代码没了！

1小时之后，同事慌慌张张地跟我说：

我代码没了！

我心里第一反应是：

刚才一顿变基猛如虎，不过变基变出问题来了吧？

作为一个成熟稳重的程序员，什么大风大浪没见过，于是轻轻地回了句：

少年，莫慌！你先讲下你刚才做了什么？

我没，没做什么…

没做什么代码怎么会自己丢了呢？

我就执行了一下 git stash pop，然后我之前写了一上午的代码就没…没了…

突然开始心里有点慌，把同事一上午代码搞没了，我怎么赔给人家？？

但心里不能表现出来，不着急，稳住少年！

你先执行下 git stash list 看下储存栈里还有没有内容：

看到之前储存的内容还在我立马不慌了！

不再执行下 git stash pop，我看下有没有报什么错？

执行完之后果然报了一个错：

大意是：

你本地修改了文件，储存栈里的内容如果弹出会覆盖掉你本地的代码，所以导致操作失败。然后建议你先提交你本地的修改或者将你本地的修改储存起来。并且特意提示你你储存的内容给你保留下来了，方便你下次要用的时候可以用。

不得不说，这 Git 真是太贴心了，考虑得很周到，为 Git 点个赞👍

虽然我其实已经猜到是什么原因了，但是作为成熟稳重的程序员，我依然不动声色地问了句：git rebase 之后，git stash pop 之前，中间你是不是还改了什么东西？

哦，好像是改了 main.ts 文件，我想起来了！

你把你改的东西先撤销下，然后执行 git stash pop 试试？

4 破案！收工！

果然，执行 git stash pop 成功，之前的上百行代码都找回来了！

破案！收拾吃饭的家伙，准备收工！

哦，不行，还有两个小时才下班…

我是 Kagol，如果你喜欢我的文章，可以给我点个赞，关注我的掘金账号和公众号，一起交流前端技术、一起做开源！

BabyOS V8.0.0 已经发布，为 MCU 项目开发提速的代码框架

此版本更新内容包括：

1.优化驱动框架，统一驱动代码编写方法

2.增加简易状态机，助力应用程序编写

3.优化IAP功能模块，助力OTA代码编写

4.增加和优化功能模块及接口…. ….

详情查看：https://gitee.com/notrynohigh/BabyOS/releases/V8.0.0

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

Linux Mint 21.1 发布了首个 Beta 版本，为三个桌面环境提供了更新：

Cinnamon – BETA Release
MATE – BETA Release
Xfce – BETA Release

下载地址：https://linuxmint.com/download_all.php

Linux Mint 21.1 不是大版本更新，主要是集成 Linux 21 发布以来的众多迭代改进，当然也增加了不少新功能，以及在视觉方面的变化。

比如新版本的主题外观有了明显的变化。Mint 团队选择了更鲜艳的颜色，同时减少了它们的使用范围，以确保不会太分散用户的注意力。本次更新还从面板移除了多个主题色，菜单和文件夹中的高亮色现在为黄色。但这次的主题颜色更新也引起了争议，因为 Mint 团队现在默认选择使用蓝色 Aqua 主题，而不是此前熟悉的薄荷绿。

下图是旧版的“薄荷绿”主题色：

对于此变化，官方的解释是：“我们不需要看起来很“绿”来体现 Linux Mint 的特点。无论如何变化，我们就是 Linux Mint，并且希望使用开箱即用看起来最令人舒服的颜色。”

Linux Mint 21.1 还有一个值得关注的变化是引入 Windows 风格的 “显示桌面” 按钮。

在这个版本中，他们采用新的 “Corner Bar” 来取代 Cinnamon 桌面面板中的 “show desktop” launcher。

Corner Bar 支持 “左键单击” 和 “中键单击”。这些操作可以被配置为显示桌面、显示 Desklets、显示工作区选择器或窗口选择器。此外还支持悬停时查看桌面。

其他变化包括：

改进驱动管理器

添加 “Dummy Test Device” 模式，可轻松地对各种不同的场景进行故障排除。

重新设计离线支持界面。如果处于离线状态，驱动程序管理器现在会显示一个专用界面：

如果它检测到 live USB 设备（或 DVD），则会出现不同的界面：

ISO 验证工具

该工具用于检查和校验文件的真实性和 ISO 的完整性。

隐藏部分桌面图标

以下桌面图标默认会隐藏：

Computer
Home
Trash
Network

原因是这些快捷方式在用户界面中重复出现，例如：通过面板、Mint 菜单中的链接，或 Nemo 文件管理器。

点此查看更多新变化。

Inkscape 是一个免费的开源矢量图形编辑器，适用于 Linux、Windows 和 macOS。它提供了丰富的功能，广泛用于艺术和技术插图。它使用矢量图形允许以无限分辨率进行清晰的输出和渲染。Inkscape 使用标准化的 SVG 文件格式作为其主要格式。它可以导入和导出各种文件格式，包括 SVG、AI、EPS、PDF、PS 和 PNG。

Inkscape 1.2.2 是 Inkscape 最新的维护版本，该版本终于可以让使用 AppImage 的 Windows 和 Linux 用户进行 OpenClipart 导入了。

对于 macOS，拼写检查终于正常运行了、撤销/重做选项也回到了菜单中。对于 Linux，snap 包不再可以用选项来安装，这意味着 snap 将不能访问用户主目录以外的数据。

Inkscape 1.2.2 的其他变化包括：

在某些情况下，当旋转物体并激活捕捉功能时，不再冻结。
由于性能下降，现在默认禁用 Dithering
对 DXF14 输出的几个修正
TIFF 导出现在支持透明度
JPG 和 TIFF 光栅导出时保留了 DPI 属性
在 Linux 中纠正了 PNG 文件的权限
测量工具现在可以显示形状的正确位置和尺寸

更多详情可查看：https://media.inkscape.org/media/doc/release_notes/1.2.2/Inkscape_1.2.2.html

Python 社区为 6 个不同的分支同时发布了更新，包括：Python 3.11.1, 3.10.9, 3.9.16, 3.8.16, 3.7.16 和 3.12.0 alpha 3。

这一系列的更新主要是为了修复安全问题，有些问题影响了从 Python 3.7 到 3.12 的所有版本，有些则只影响其中数个版本，部分总结如下：

3.7 – 3.12：gh-98739：将绑定的 libexpat 更新到 2.5.0 以修复 CVE-2022-43680 问题
3.7 – 3.12：gh-：不再允许在垃圾回收请求中发送的终端控制字符被打印到 stderr 服务器日志中
3.8 – 3.12：gh-87604：避免通过模块发布每个解释器的活跃审计 hook 列表
3.7 – 3.10：gh-98517：移植 XKCP 对 SHA-3 中缓冲区溢出的修复，以修复 CVE-2022-37454 问题
3.7 – 3.9：gh-68966：已弃用的 mailcap 模块现在拒绝将不安全文本（文件名、MIME 类型、参数）注入到 shell 命令，此举解决了 CVE-2015-20107 问题
……

详情查看发布公告。

FileZilla Server 是一个免费开源的 FTP 和 FTPS 服务器，能够提供与服务器的安全加密连接。Filezilla Server 没有实现对 SFTP（SSH 文件传输协议）的支持。

FileZilla Server 1.6.0 现已发布，更新内容如下：

新的功能：

UI：现在可以使用协议配置的安全页面中的特定选择器，直接从 UI 将 TLS 证书上传到服务器。
UI：所有文本控件中的最大字符数已限制为合理的数字，以避免在极端情况下出现潜在的崩溃或停顿。

错误修正和小改动：

修复了管理协议中锁定 mutexes 的潜在问题
MSW：如果先前安装的卸载程序已被删除，安装程序现在也可以正常工作。
修复了处理 TLS close_notify 警报时网络代码中的问题。

更多详情可查看：https://filezilla-project.org/

Ruby 3.2.0 RC 1 发布了，3.2.0 预览版引入基于 WASI 的 WebAssembly 支持和正则表达式超时退出机制，3.2.0 RC 1 则引入两项可显著缓解 ReDoS 攻击的改进，以及一些语言功能和性能改进。

改进的正则表达式匹配算法

从 Ruby 3.2 开始，Regexp 的匹配算法通过使用记忆技术得到了极大的改进。

改进后的匹配算法使得大多数 Regexp 匹配（实验中大约为 90%）在线性时间内完成。

对于 3.2.0 预览版本的用户：此优化可能会消耗与每个匹配的输入长度成比例的内存。预计不会出现实际问题，因为此内存分配通常会延迟，并且正常的 Regexp 匹配最多应消耗 10 倍的内存输入长度。

该功能最初的提议是 https://bugs.ruby-lang.org/issues/19104

其他值得注意的新功能

语法建议

（以前的）的功能已集成到 Ruby 中，可以帮助找到错误的位置，例如丢失或多余的 end 。

[Feature #18159]

错误高亮

现在它指向 TypeError 和 ArgumentError 的相关参数

语言

匿名 rest 和关键字 rest 参数可以作为参数传递，而不仅仅是在方法参数中使用。

[Feature #18351]

更多性能改进和细节变化可在发布公告中查阅。

回顾一下 3.2.0 预览版中引入的功能：

基于 WASI 的 WebAssembly 支持

这是基于 WASI 的 WebAssembly 支持的初始移植。此项特性使得 CRuby 二进制文件可在 Web 浏览器、Serverless Edge 环境和其他 WebAssembly/WASI 嵌入器上使用。目前，此移植可在不使用 Thread API 的前提下通过基本和引导测试套件的测试。

正则表达式超时退出机制

此版本引入了正则表达式超时退出机制。

由于正则表达式匹配会耗费不少时间，当代码试图向不受信任的输入匹配低效的正则表达式时，攻击者可能会利用它进行 DoS 攻击（即正则表达式 DoS，或称作 ReDoS）。

根据 Ruby 应用程序的要求进行配置，可以防止或显着降低 DoS 的风险。请注意，是全局配置项，如果希望对某些特殊的正则表达式使用不同的超时设置，需要使用关键字。

此项特性的最初提案：https://bugs.ruby-lang.org/issues/17837

Blender 是一个免费和开源的 3D 计算机图形软件工具集，用于创建动画电影、视觉效果、艺术、3D 打印模型、交互式 3D 应用、VR 和计算机游戏。Blender 3.4 现已正式发布，该版本包括 Cycles 中的路径引导、新的雕刻和 paint masking 工具、几何节点视口叠加、新的 UV 编辑工具、改进的性能等等。

具体一些更新亮点包括：

除了 Linux 上现有的 X11 支持之外，现在还启用了 Wayland 支持。
通过使用英特尔的 Open Path Guiding 库集成了路径引导支持，以提高采样质量。Open path Guiding 库目前仅适用于基于 CPU 的渲染。
现在支持带有 HIP 的 AMD Radeon RX 7000 系列 (RDNA3) 显卡。
修复了在 Linux 上使用 ROCm 5.3 及更新版本时 Vega 和 RDNA1 显卡的 texture issues。
FreeType 字体缓存以使用更少的资源和更好的性能。
WebP 图像缩略图生成更快，同时使用更少的 RAM。
Blender 的视频渲染现在支持 FFmpeg AV1 编解码。
现在在 Linux 下支持 Eevee headless 渲染。
UV 编辑器中添加了一个新的基于几何体的 relax brush。
几何节点有一个新的评估系统。
支持 MTL 文件中的 PBR 扩展。
Blender 内部网格格式的内部数据结构发生了很大的变化。

更多详情可查看 3.4 release notes。

下载地址：http://ftp.vim.org/graphics/blender/release/Blender3.4/

VS Code 1.74 已发布，此版本主要带来如下优化：

自定义资源管理器自动显示– 决定哪些文件在资源管理器中滚动到视图中。
隐藏活动栏和面板徽章– 通过切换状态徽章，简化编辑器 UI。
笔记本和差异视图的音频提示– 单格运行结果、添加或删除行的声音。
合并编辑器撤消/重做– 快速恢复或重新应用合并冲突操作。
管理不安全的存储库– 防止对不属于您的文件夹进行 Git 操作。
JavaScript console.profile 集合– 轻松创建 CPU 配置文件，并在 VS Code 中查看。
Go to Definition from return – 跳转到 JavaScript/TypeScript 函数的顶部。
远程隧道– 创建到任何设备的连接，无需 SSH。
Jupyter Notebook“Just My Code”调试– 避免进入 Python 库代码。
开发容器 GPU 支持– 创建开发容器时请求 GPU。

下面对部分功能作介绍：

自定义资源管理器的自动显示逻辑

此版本引入新设置 explorer.autoRevealExclude ，如果启用了自动显示（explorer.autoReveal，默认为 true），此设置允许您配置哪些文件在资源管理器中自动显示。

autoRevealExclude 设置使用 glob 模式来排除文件，类似于 files.exclude，也支持通过 when 子句进行兄弟匹配。

默认值不包括 node 和 bower 模块：

设置编辑器指示器、悬停和链接可用键盘导航

设置编辑器中的指示器、悬停和链接现在可以通过键盘导航，一些链接的样式也进行了调整，以便在设置编辑器中保持更好的一致性。在制表位和保持键盘焦点方面，设置编辑器指示器悬停表现得更好。

这种改进仍处于试验阶段，目前仅对设置编辑器指示器悬停启用，而不是对 VS 代码中的所有悬停启用。

隐藏视图容器的徽章

与通过右键单击视图容器隐藏视图容器的方式类似，现在也可以隐藏容器上的徽章（显示在活动栏、面板和侧栏中）。

徽章通常显示特定视图容器的数字、图标或进度指示器，例如，源代码管理视图的待处理更改数。

管理不安全的 Git 仓库

VS Code 使用 git.exe 执行所有 Git 操作。从 Git 2.35.2 开始，用户无法在非当前用户拥有的文件夹的存储库中运行 Git 操作，因为该存储库被认为具有潜在的不安全性。

从此版本开始，如果尝试打开此类可能不安全的存储库，VS Code 将在源代码管理视图中显示欢迎视图以及错误通知。欢迎视图和通知都带有“管理不安全存储库”命令，该命令允许您查看可能不安全的存储库列表，手动将它们标记为安全仓库，然后再打开它们。

管理不安全存储库命令也可在命令面板中使用，将存储库标记为安全会将存储库位置添加到 safe.directory git 配置。

终端快速修复改进

终端快速修复现在显示在代码操作控件中，以与编辑器中的体验保持一致。

远程隧道

Remote Tunnels 现在可作为 VS Code 稳定版的预览功能使用，远程隧道允许您从任何设备、任何地方安全地访问您的机器与 VS 代码。

要启用远程隧道访问，可以：

从帐户菜单或命令面板中选择打开远程隧道访问。
从安装了 VS Code 并位于 PATH 上的计算机运行。
下载新的 VS Code CLI ，并运行.

打开隧道访问后，您可以使用 vscode.dev 从任何设备连接到计算机，或使用VS Code 桌面中的 Remote – Tunnels扩展。

要了解更多信息，请查看该功能的博客文章或远程隧道文档。

JavaScript 调试

支持 console.profile

JavaScript 调试器现在支持 console.profile。在调试器下运行时，该功能将为 console.profile() 和 console.profileEnd() 之间的代码收集 CPU 配置文件。

生成的 .cpuprofile 文件将保存在您的工作区文件夹中，可以使用 VS Code 的内置配置文件查看器打开和查看。

支持嵌套源映射

有时，尤其是在 monorepo 设置中，源代码可能会被编译一次，然后重新编译或再次捆绑。在许多情况下，这个问题会导致生成的包的源映射引用了第一步中创建的编译文件。

JavaScript 调试器现在自动递归地解析源映射，无需额外步骤即可调试原始源文件。

TypeScript 4.9

VS Code 现在附带 TypeScript 4.9，带来了新的 TypeScript 语言功能，例如运算符和自动访问器。在工具方面则对文件监视进行了改进，并进行了许多其他修复和改进。

查看 TypeScript 4.9 公告，了解有关此更新的更多信息。

Go to Definition on return

JavaScript 和 TypeScript 现在支持在 return 关键字上运行 Go to Definition 以快速跳转到返回函数的顶部，在处理长的、复杂的或高度嵌套的函数时很有用。

可以使用 Go to Definition 命令/键绑定 (F12) 或简单地使用 Cmd/Alt + 单击 return 关键字。

远程开发扩展

远程开发扩展允许使用容器、远程计算机或适用于 Linux 的 Windows 子系统(WSL) 作为功能齐全的开发环境。此版本的亮点包括：

开发容器 GPU 支持
开发容器 Cygwin / Git Bash 套接字转发
远程隧道扩展 – 无需 SSH 即可连接到远程计算机。

可以在远程开发的发行说明中了解新的扩展功能和错误修复。

更多功能可以在发布公告中细阅。

Microsoft PowerToys 是 Windows 系统实用程序，供高级用户调整和简化其 Windows 体验，可最大限度地提高生产力。

以下是 PowerToys v0.65 版本中的一些重要更新内容：

亮点

代码库已经升级兼容 .NET 7
Quick Accent 现在可以显示所选字符的描述
ColorPicker 现在支持添加自定义格式
将依赖项 ModernWPF 降级到 0.9.4，以避免某些虚拟化技术的问题

已知问题

Text Extractor（文本提取器）工具在某些情况下无法识别运行 Windows 10 的 ARM64 设备上的文本
安装 PowerToys 后，PowerRename 和 Image Resizer 的新的 Windows 11 上下文菜单项在系统重启前可能不会出现
有报告称，用户无法打开 “设置” 窗口。这是由一些应用程序的不兼容造成的（RTSS RivaTuner统计服务器就是一个已知的例子）

快速启动器

目前一个新的 PR 显示，微软将为 PowerToys 引入快速启动器，用户可以通过系统托盘中的图标来启动各种 PowerToys 模块。

特点：

显示可通过启动器启动的激活模块
每个模块都有工具提示，以显示激活的快捷键
可以打开设置和文档
被禁用的模块将不被显示

更多详情可查看：https://github.com/microsoft/PowerToys/releases/tag/v0.65.0

本次升级内容：

build

spring-boot > 2.7.6
nacos.version > 2.1.2
spring-boot-admin.version>2.7.7
jasypt.version>3.0.4
aliyun-java-sdk-core.version>4.6.2
esdk-obs-java.version>3.22.3.1
qiniu-java-sdk.version>7.12.0
gson.version>2.8.9
jsoup.version>1.15.3
JustAuth.version>1.16.5
okhttp3.version>4.10.0
mybatis.version>3.5.10
mybatis-spring.version>2.0.7
jasypt.version>3.0.4
lombok.version>1.18.24
tencentcloud-sdk-java.version>3.1.548
aliyun-java-sdk-core.version>4.6.2
aliyun-dysmsapi.version>2.0.22
bce-java-sdk.version>0.10.217
ip2region.version>2.6.5

refactor

lamp-sms: 腾讯和阿里短信发送适配新版本api
lamp-authority: 登录日志获取浏览器、操作系统等信息方式变更
lamp-util: spring.factories 文件替换为 org.springframework.boot.autoconfigure.AutoConfiguration.imports
lamp-log-starter: 适配 ip2region.version 2.6.5
lamp-cloud-starter: 优化 OkHttpClient 配置
lamp-echo-starter: 启动时扫描指定包名下需要回显的实体类，优化echo首次回显慢的问题
lamp-echo-starter: 回显集合数据时，转换为普通类型进行查询

fix

解决 @Async 使用时， ThreadLocal会有问题

关于lamp

(简称灯，英文名：lamp)，她是一个项目集，为满足高内聚低耦合设计原则，将一个大项目拆解为以下几个子项目：

lamp-util：后端工具集
lamp-cloud：基于Spring Cloud实现的后台
lamp-boot：基于Spring Boot实现的后台
lamp-job：基于xxl-job集成本项目的分布式定时任务
lamp-generator：代码生成器
lamp-web：前端

lamp-cloud 简介

是基于 + + + 开发的微服务中后台快速开发平台，专注于多租户(SaaS架构)解决方案，亦可作为普通项目（非SaaS架构）的基础开发框架使用，目前已实现插拔式 数据库隔离、SCHEMA隔离、字段隔离 等租户隔离方案。

她拥有自研RBAC（基于租户应用的角色权限控制体系）、网关统一鉴权、数据权限、优雅缓存解决方案、防缓存击穿、前后端统一表单校验、字典数据自动回显、可视化前后端代码生成器、支持多种文件存储、支持多种短信邮件发送接口、灰度发布、防XSS攻击、防SQL注入、分布式事务、分布式定时任务等功能；支持多业务系统并行开发，支持多服务并行开发，是中后台系统开发脚手架的最佳选择。

lamp-cloud 代码简洁，注释齐全，架构清晰，非常适合个人学习以及中小企业作为基础框架使用。采用Spring Cloud Alibaba、SpringBoot、Mybatis、Seata、Sentinel、RabbitMQ、FastDFS/MinIO、SkyWalking等主要框架和中间件。本项目旨在实现基础框架能力，不涉及具体业务。

关注项目

官网：https://tangyh.top
源码：github
源码：gitee

一、背景介绍

随着4G网络的推广和网络带宽的提升，视频成为互联网用户主要的消费载体，用户通过短视频来分享和浏览信息。由此视频的编辑功能越来越重要、越来越普遍。视频编辑的App也如雨后春笋般涌现。为更好地推动得物App社区业务的发展，得物也自研符合得物需求的视频编辑工具。我们致力于打造一个“更快、更强”的视频编辑工具。

二、视频编辑工具介绍

为了让大家更好地了解得物App的视频编辑工具，我们先简单介绍一下视频编辑工具的主要功能。

下面是得物App视频编辑工具的主要功能：

视频编辑工具的重点如下：

视频编辑工具需要操作的资源：
- 文字：包括普通的文字、特殊的艺术字、花字等等；
- 图片：包括静态图，如JPEG/PNG等等，也包括HEIC/GIF等动态图；
- 视频：包括各种各样的视频（各种编码和封装格式），主流的格式一般是MP4的封装格式、H264视频编码格式、AAC音频编码格式等等；
- 音频：包括各种各样的音频（各种编码和封装格式），当然视频当然也是包含音频轨道的。
视频编辑工具主要的操作方式：
- 操作图片、视频帧：我们知道视频是一帧一帧的图片组成的，所以操作视频帧和操作图片是一样的道理，我们通过添加一些特效在图片和视频帧上面，实现一些有趣的效果来吸引用户。
- 操作音频：主流的操作音频方式如倍速、调整音量、变调等等，都是现今短视频的主要玩法。
视频编辑工具最终生成的是一个新的视频，这个视频将特定的资源应用一些特效生成一个新的视频。

下面的流程图可以很方便地让大家了解视频编辑的工作流程。为了方便，我们输入一个视频，加上一些特效，生成一个新的视频。

从上面的流程可以看出来，原始视频A.mp4经过解封装分离出音频轨道和视频轨道，对它们解码之后，对音频数据应用音频特效、对视频帧数据应用视频特效，然后编码封装合成一个新的视频。当然解码和编码都是有一个队列控制的，流程图上标注了，没有深入展开，大家了解即可。

经过上面的介绍，大家对视频编辑工具有了大概得了解，其实衡量一个视频编辑工具做得好不好，主要从下面这几个方面着手：

内存占用情况
导出视频的速度如何
导出视频的清晰度如何

下面从这三方面详细展开给大家阐述得物App的视频编辑工具优化的心路历程。

三、内存优化

性能是所有程序好不好的首要指标，一个工具即使功能再强大，但是一点就崩溃，或者用着用着内存暴涨、应用卡死，估计这个应用不能称为一个优秀的应用，下面我们具体谈一谈视频编辑工具的优化检测方案。

优化内存从良好的编码习惯开始，尤其对音视频这种对内存需求非常高的应用而言。例如一个1080 * 1920的视频，解码出来原始数据一帧图片大小也是1080 * 1920，占用内存是1080 * 1920 * （8 * 3 ) / 8 = 5.93 MB，一个视频帧就占用这么大，1秒一般有30帧，那得占用177.9MB，如果不加控制，那不管多高性能的手机也经不住这样的折腾。希望下面的内存检测和优化方案可以给你带来一些帮助。

3.1 合理设计队列

上面我们在介绍视频编辑流程的视频谈到了解码队列和编码队列的概念。其实队列这个概念在音视频中使用非常频繁，正是因为内存的限制，所以才引入队列这个控制方式。大家可能还有点懵，但是看完下面的流程图，我相信你一定会豁然开朗。
我们仅选取解码的部分来分析一下队列的重要应用。

在视频编辑工具中有几个重要的队列：

解码过程中：
- Video Packet Queue：视频解码之前Packet存放的队列，一般建议的队列大小是100
- Audio Packet Queue：音频解码之前Packet存放的队列，一般建议的队列大小是150
- Video Frame Queue：视频解码之后Frame存放的队列，一般建议的队列大小是3
- Audio Frame Queue：音频解码之后Frame存放的队列，一般建议的队列大小是8
编码过程中：
- Encode Video Packet Queue：视频编码之后Packet存放的队列，一般建议的大小是100
- Encode Audio Packet Queue：音频编码之后的Packet存放的队列，一般建议的大小是150

按照上面的方式设计队列的大小，可以在保证功能正常的情况下最大程度的降低内存占用，提升用户体验。

3.2 排查内存泄漏

Android上排查内存泄漏的方式有很多，这里介绍两种：

Asan检测
Profile检测

Asan全称是AddressSanitizer是一种基于编译器的快速检测的工具，用于检测原生代码中的内存错误问题，Asan可以解决如下四种核心问题：

堆栈和堆缓冲区上溢、下溢
释放之后堆重新使用问题
超过范围的堆栈使用情况
重复释放、错误释放问题

Asan的使用方式建议参考google官方文档，这儿就不多作介绍了： https://github.com/google/sanitizers/wiki/AddressSanitizer

关于Profile的使用，如果需要检测Native内存使用情况，需要满足API>=29，大家在使用的时候需要非常注意。

下面是我们在demo中应用Asan抓取的堆栈：

显示message是：heap-use-after-free on address 0x004ac1e41080 说明是使用了已经释放掉的内存了，再继续看，这个内存具体在什么地方被释放的？0x004ac1e41080 is located 0 bytes inside of 1792-byte region [0x004ac1e41080,0x004ac1e41780) Asan一个很大的优势就是可以追踪内存释放的路径，防止出现内存泄漏和野指针问题，特别是野指针，一旦出现特别难排查，简直是C++开发的噩梦，希望大家用好工具，同时培养良好的C++编码习惯。

3.3 优化线程

另一个影响内存的重要因素是线程，视频编辑工具涉及到的线程非常多，线程的使用得遵循一些基本的原则：

尽量少创建线程
尽量少使用pthread_mutex_t
本着功能隔绝原则使用线程
能同步就别异步

以编辑模块为例，这儿列一下我们使用到的所有线程：

GL处理线程
视频解封装线程
视频中视频轨道解码线程
视频音频轨道解码线程
抽取缩略图线程
音频编码线程
视频编码线程
视频封装线程

如果插入了独立的音频文件，还需要添加两个额外的线程：

音乐文件播放线程
音乐文件解码线程

上面列出的是一个视频编辑工具能正常工作所必备的最少线程，如果你的视频编辑工具中多了什么线程，我们建议可以适当优化一下，毕竟少一个线程，可以少一分开销，而且少一分线程同步的工作。

我们在底层也按照Android的消息机制重写了一套C++层的消息分发SDK，这个我们后续会另外分享文章阐释我们定制的消息分发SDK，这儿点到为止。

四、提升导出视频的速度

我们使用视频编辑工具，最终是希望导出一个视频，如果这个导出的过程很慢，那肯定是无法忍受的，从上面的介绍我们已知视频的导出需要经过“解码——应用特效——编码”的过程，其中解码和编码这两个过程对速度的影响至关重要。因为解码和编码视频需要耗费大量的资源，目前主要有两种方式——“软解/编码”和“硬解/编码”。

如果你使用过FFmpeg或者其他使用CPU进行视频编解码的来处理视频的话，你可能已经遇到了处理速度慢的问题。这主要是因为软编码和软解码使用CPU进行运算，而CPU在处理视频上的速度远低于DSP芯片；简而言之“软解/编码”主要通过CPU来工作，通过CPU来主导大量的计算工作，是原始的处理方式，当然耗费的时间也比较长；“硬解/编码”是通过GPU来处理，GPU是专用的图形处理芯片，对视频的解码和编码有专门的优化，所以编码和解码的速度非常快。

Android上使用MediaCodec来实现“硬解/编码”，iOS上使用VideoToolBox来实现“硬解/编码”，这里着重介绍Android上编码解码的速度优化。

从上面的流程我们可以看出，编码在解码的后面，一个时长60s（30fps）的视频，需要解码1800帧，然后编码1800帧视频才能完整生成另外一个视频，这样串行的等待是耗时的主要原因。

这时候我们参考多线程方案，将一个60s的视频均分为两段，然后这两段视频同时进行解码操作，生成导出了两个30s的临时缓存视频文件，随后将这两个30s的视频合并为一个60s的B.mp4视频，最后删除临时缓存文件，这样我们只需要同时处理900帧的数据，理论上可以提升一倍的导出速度。

这就是并行导出，下面是得物App并行导出的基本流程。

首先我们要明确导出视频是需要消耗资源的，这个资源就是MediaCodec，最终是送入到GPU中处理，一个手机中的MediaCodec实例是有限的，正常情况下，一个手机可以提供的MediaCodec实例最多有16个，如果当前使用的MediaCodec实例超过16个，那么手机将无法正常工作。MediaCodec资源是手机中的所有App共同持有。所以并行分段的个数不是越多越好。

只有一段，需要两个MediaCodec（一个用来解码视频，一个用来编码视频），注意：音频的解码和编码可以不要用MediaCodec，毕竟音频的耗时少多了，不是瓶颈。
分成两段需要四个MediaCodec，分成三段需要六个MediaCodec，分成四段需要八个MediaCodec，以此类推。

下面是并行导出的测试结果：
两段并行速度提升50% ~ 70%，内存增加20%，三段并行速度提升60% ~ 90%，内存增加80%；并行超过三段的话就无法明显提升速度了。我们比较建议并行两段，在一些性能很好的机型上并行三段。

如果有些同学对视频导出过程中文件操作还有疑问的，下面的示意图可以比较清楚地看出并行导出操作本地文件的过程：

并行导出的过程中，生成了两个临时文件
并行导出完成后，这两个临时文件合并为一个新的文件，两个临时生成的文件被删除了（节省用户宝贵的存储空间）
原始文件jeffmony_out.mp4并没有被删除/修改

Tips：目前我们在处理过程中生成的临时文件和最终的适配文件都会保存在/sdcard/Pictures/duapp/Compile/下，而在处理完成后的临时文件清理过程会触发在某些机型上的保护机制，建议后续调整到App的私有目录下。

当然还有其他的提升导出速度的建议，例如在视频帧特效处理的过程中，我们建议：

尽量采用FBO/EBO/ABO方式处理texture
纹理如果过大要进行压缩
严禁采用glFinish()

这些做法都是我们在视频编辑开发过程中的切实经验，希望能给大家带来一些帮助。

五、提升导出视频的清晰度

一个视频编辑功能是否足够优秀，其中的一个重要指标就是同等条件下导出的视频是否足够清楚，通常而言，衡量视频是否清晰的有两种方式：

主观标准：找一些用户观看不同的视频，根据用户的观感输出视频清晰度的对比结果，用户一般根据色彩、画面亮度、柔和度等来评估清晰度。
客观标准：利用算法计算视频画面质量分，目前比较推荐Netflix推出的开源库VMAF来计算视频帧的质量分。

实际上主观标准是比较准确的，但是可操作性比较差，特别是处理海量视频的时候，需要大量的人力，无法有效开展，因此日常工作中还是推荐客观标准进行海量计算，主观标准进行重点判断。具体的可以结合业务的重要程度来开展。

下面结合我们实际的工作给出具体提升视频清晰度的方式：

视频基础编码信息优化
- Profile优化：Profile有三种Level，分别是Baseline、Main、High，其中Baseline Profile对应清晰度最低，Android 3.0之后的版本都支持的，Main Profile清晰度比Baseline Profile清晰度要好，但是从Android 7.0之后才支持，High Profile清晰度最高，也是从Android 7.0之后才支持。我们在设置Encoder Profile Level之前，需要判断一下当前是否支持。
- Bitrate码率设置： 视频码率是视频数据传输时单位时间内传送的数据位数。单位是kbps，望文生义，码率越大，单位时间填充的数据就越多，视频质量就越高。但码率也不是设置的越大越好，超过必要限度，对视频画质的提升已不明显，建议采用合适的factor来调整码率。Bitrate = width * height * frameRate * factor，其中factor=0.15。
- Bitrate Mode： 有三种通过的编码模式——VBR（可变码率）、CBR（固定码率）、ABR（平均码率），其中ABR是最好的方式，可以兼顾质量和视频大小。
- B帧设置： 视频有I帧、P帧、B帧构成，其中I帧最大，P帧次之，B帧最小，我们在编码时尽量多设置B帧（在合理的范围内），并不会降低清晰度，但是可以大大降低视频的大小，这样我们就可以相应地调大码率，最终实现了提升清晰度的目标。
HEVC编码优化： 使用HEVC编码，可以保证在不增加文件大小的情况下，大大提升视频的清晰度。在相同的图像质量下，HEVC编码的视频比H.264编码的视频约减少40%
色彩调优
- 综合调整亮度、对比度、色温、饱和度、锐度等颜色参数，进而优化整体的视频画面，让视频画面看上去“更清晰”。
超分算法：采用ESRGAN算法，利用机器学习的优势对图片和视频进行去模糊、Resize、降噪、锐化等处理，重建图片，实现对图片的超分辨率处理。
- 特征提取：计算噪点
- 非线性映射：放大，模糊化噪点
- 图像重建：差分，平滑过度，去噪
下面是使用超分算法处理前后的对比图，可以很明显地看出右边的图更加清晰，少了很多噪点、图片更亮、过度更平滑。

如果大家想了解视频清晰度优化的技术细节，可以参考文章–视频清晰度优化指南

六、总结

本文开篇从介绍得物App的主要功能展开，提出了视频编辑工具优化的三个维度：

优化内存占用
提升视频导出速度
提升导出视频的清晰度

其中在“提升视频导出速度”时重点谈到了“并行导出”的技术方案，从最终的结果来看，视频导出速度的提升非常明显，同时也非常清楚地解释了“并行导出”过程中为什么生成临时文件？为什么有必要在导出完成之后删除临时文件？尽力给用户带来较好的体验。

最后在“提升导出视频的清晰度”中重点提到的超分算法应用效果提升明显，超分之后的视频帧相比原帧图更加清晰、噪点更少，而且细节部分更加真实。

后续我们还会结合AR特效输出更多有意义的技术分享，敬请期待。

*文 /Jeff Mony

关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～

Djot（发音：/dʒɑt/）是轻量的标记语法，包含许多派生自 CommonMark 的功能，同时修复了一些使 CommonMark 语法复杂且难以有效解析的问题。

Djot 属于 Markdown 的升级版，且 Djot 的功能比 CommonMark 更全面，支持定义列表、脚注、表格、几种新的内联格式（插入、删除、高亮、上标、下标）、数学、智能标点符号、可应用于任何的属性素，以及用于块级 (block-level)、内联级 (inline-level) 和原始内容 (raw content) 的通用容器。

在 Djot 的语法中，对硬换行的解析与常见的 Markdown 不同。

比如使用 Markdown 可以写成这样：

但在 Djot 中，如果使用了块级素，一定要采用硬换行：

对于列表也是同样的处理：

Markdown

Djot

Djot 的解释器采用解释性语言 Lua 编写，据称速度很快，可以生成 AST、渲染 HTML，以及语法高亮显示或 linting 工具。

微软近日公布了实施 Manifest V3 和逐步淘汰 Manifest V2 浏览器扩展的更新路线图，更新后企业可以继续在配置了相应策略的系统上使用 Manifest V2 扩展，时间至少会到 2024 年 1 月。根据博客文章，微软可能会进一步延长对 Manifest V2 扩展的支持，但目前还没有最终的定论。

Manifest V3 在浏览器开发商、扩展开发者、企业组织和普通用户中被积极讨论，虽然大部分人都在批评 Manifest V3，但各大浏览器厂商仍然在陆续推进 Manifest V3 的支持工作，只不过各个厂商的支持程度各不相同。比如 Firefox 就计划在支持 Manifest V3 的同时支持 Manifest V2 功能，Vivaldi 没有具体说明如何实现，仅仅表示内容拦截扩展可以继续正常使用。

微软已于 2022 年 7 月停止接受 Manifest V2 的新扩展，但并没有在 Microsoft Edge 中取消支持，Manifest V2 和 V3 扩展均可以安装在最新版本的 Microsoft Edge 中，开发者也仍然可以为现有的扩展推送更新，以维护或增加新的功能。

微软 Edge Manifest V2 支持的官方迁移时间表还没有根据新信息进行更新。迁移过程目前还是处于上述这样的第一阶段。

到了下一阶段，微软将不再允许开发者更新 Manifest V2 的扩展，扩展开发者只能发布升级到 Manifest V3 的扩展。也是从这个阶段开始时，Edge 用户不能再运行 Manifest V2 扩展，除非企业策略被配置为允许 Manifest V2 扩展。

在第三阶段，也是最后一个阶段，无论企业策略如何设置，Manifest V2 的扩展都将无法在任何版本的 Edge 中发挥作用。

12 月 4 日，自由软件基金会 (FSF) 和 GNU 项目创始人 RMS 以线上形式在 EmacsConf 2022 大会发表了演讲，主题是《What I’d like to see in Emacs》。

RMS 说道，GNU Emacs 是他发布的第一个 GNU 程序，在这个过程中，他了解到软件许可证以及捍卫软件自由的知识。

于是 RMS 在演讲开头首先强调了 GNU 操作系统的目标。他表示 GNU 不仅仅是要在技术层面和使用层面做得好，它的主要目标——甚至可以说是整体目标，就是为了让大众自由使用软件，并帮助他们珍视和捍卫这份自由。

在谈到 GNU Emacs 支持的编程语言时，RMS 认为 Emacs 最不应该支持的语言是 JavaScript。但他说这不是因为语言本身存在问题。

RMS 表示自己不懂 JavaScript，他听说别人评价它相当笨拙，且设计得不好，但他不了解这些。他也不是因为这些问题而发表上面的观点。

RMS 认为 JavaScript 的糟糕之处并非语言本身，而是人们使用它的方式。大多数情况下，Web 服务器会将 JavaScript 编写的程序不知不觉地发送到用户的机器上。如此一来，这个无法知晓作者的程序就会在用户的电脑上运行，并做着用户不知道的事。这些举动无疑违背了 RMS 一直倡导和追求的“自由”。他认为让 Emacs 不支持 JavaScript 属于捍卫自由的一种方式。

当然，RMS 知道这个问题并非 JavaScript 导致，“罪魁祸首”是现代浏览器厂商。他提到了刚诞生时的互联网，当时的网页负责描述内容，浏览器则负责渲染内容，用户拥有自由控制浏览器的权限。但从大约二十年前开始，随着商业公司希望对用户屏幕上显示的内容进行越来越多的控制，浏览器的复杂性呈爆炸式增长。他们发明了很多功能来控制它，用户无法真正自定义某些内容的显示方式。因为整个问题的关键是商业公司控制了浏览器，以及在 Web 中运行的应用。这些都和 JavaScript 密切相关。

RMS 在本次大会上除了谈论“自由”哲学，更多的内容还是关于 Emacs 本身，他期望 Emacs 能带来更丰富的功能，比如集成 LibreOffice 和 TeX 中的优点。以及简化 Emacs 的命令界面，优化维护方式等。

RMS 完整演讲内容

文字：https://emacsconf.org/2022/talks/rms/
视频：https://media.emacsconf.org/2022/emacsconf-2022-rms–what-id-like-to-see-in-emacs–main.webm

文章目录

一、背景
二、环境准备
三、具体实施步骤
- 3.1、安装ansible
- 3.2、配置主机清单
- 3.3、测试主机连通性
- 3.4、创建相关目录
- 3.5、下载openGauss软件包到files目录
- 3.6、创建变量文件
- 3.7、创建安装时需要的xml模板
- 3.8、创建任务文件
四、执行自动化安装
- 4.1、校验语法
- 4.2、自动化安装openGauss
- 4.3、安装完成后验证

一、背景

由于IT建设的快速发展，当数据中心业务突增，需要快速部署多套的数据库时，给运维工作带来了不小的压力和挑战，作为运维人员该如何面对面对这种困境呢？另外由于个人的习惯等也会导致所部署的环境不一定与规划完全一致，那么对以后的运维也会产生一定的负面影响。很显然，这种传统的方式已经无法适应当前的情景了，自动化运维应运而生，ansible在自动化运维和devops 的应用中崭露头角。

本文基于ansible工具实现 openGauss 的一键批量部署，传统的部署方式是先修改系统配置、安装依赖包、创建omm用户和组、配置环境变量、上传安装包以及解压、安装等步骤。

按照这个流程和思路，我们把这些操作弄成剧本编排(playbook)，交给ansible来做。

二、环境准备

2台主机：
一台为Ansible的管理主机(10.10.10.142)，操作系统为CentOS Linux release 7.9.2009 (Core)；
另外一台为需要部署openGauss的主机(10.10.10.150)，操作系统为CentOS Linux release 7.9.2009 (Core)。

三、具体实施步骤

3.1、安装ansible

–在10.10.10.142上进行安装Ansible
yum install epel-release -y
yum install ansible –y

–配置/etc/ansible/ansible.cfg

3.2、配置主机清单

修改主机清单/etc/ansible/hosts，添加主机列表

10.10.10.150为本次需要安装openGauss的主机

3.3、测试主机连通性

3.4、创建相关目录

[root@cs79-mysql:~]# cd /etc/ansible/roles/
[root@cs79-mysql:/etc/ansible/roles]# mkdir -p openGauss_Install/{files,vars,tasks,templates}
[root@cs79-mysql:/etc/ansible/roles]# tree openGauss_Install/
openGauss_Install/
├── files
├── tasks
├── templates
└── vars

4 directories, 0 files

上述目录主要作用如下：
files：存放需要同步到异地服务器的安装文件或者配置文件；
tasks：openGauss安装过程需要进行的执行的任务；
templates：用于执行openGauss安装的模板文件，一般为脚本；
vars：安装openGauss定义的变量；

3.5、下载openGauss软件包到files目录

安装包下载地址：https://opengauss.org/zh/download.html

[root@cs79-mysql:/etc/ansible/roles]# cd openGauss_Install/files/
[root@cs79-mysql:/etc/ansible/roles/openGauss_Install/files]# # wget https://opengauss.obs.cn-south-1.myhuaweicloud.com/3.1.0/x86/openGauss-3.1.0-CentOS-64bit-all.tar.gz
–2022-10-09 21:42:01– https://opengauss.obs.cn-south-1.myhuaweicloud.com/3.1.0/x86/openGauss-3.1.0-CentOS-64bit-all.tar.gz
Resolving opengauss.obs.cn-south-1.myhuaweicloud.com (opengauss.obs.cn-south-1.myhuaweicloud.com)… 121.37.63.38, 139.159.208.64, 139.159.208.243
Connecting to opengauss.obs.cn-south-1.myhuaweicloud.com (opengauss.obs.cn-south-1.myhuaweicloud.com)|121.37.63.38|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: (117M) [application/gzip]
Saving to: ‘openGauss-3.1.0-CentOS-64bit-all.tar.gz’

100%[==================================================================================================================================================================================================>] 123,022,609 38.4MB/s in 3.2s

2022-10-09 21:42:04 (37.1 MB/s) – ‘openGauss-3.1.0-CentOS-64bit-all.tar.gz’ saved [/]

3.6、创建变量文件

[root@cs79-mysql:~]# vi /etc/ansible/roles/openGauss_Install/vars/main.yml

#安装包名称
openGauss_software: openGauss-3.1.0-CentOS-64bit-all.tar.gz
#解压目录
install_dir: /opt/software/openGauss
#omm用户密码
omm_password: openGauss@123
#数据库密码
db_password: openGauss@123

3.7、创建安装时需要的xml模板

[root@cs79-mysql:~]# vi /etc/ansible/roles/openGauss_Install/templates/cluster_config.j2

3.8、创建任务文件

3.9、创建剧本调用文件
[root@cs79-mysql:~]# vi /etc/ansible/playbook/InstallopenGauss.yml

name: Install openGauss
hosts: openGaussdb
remote_user: root
roles:
- openGauss_Install

四、执行自动化安装

4.1、校验语法

校验语法通过后，执行下一步安装

4.2、自动化安装openGauss

4.3、安装完成后验证

至此，整个自动化部署openGauss完毕，如果有多台机器需要部署，添加主机相关信息到/etc/ansible/hosts，再执行ansible-playbook即可。

作者：鸿惊九天
openGauss: 一款高性能、高安全、高可靠的企业级开源关系型数据库。

🍒如果您觉得博主的文章还不错或者有帮助的话，请关注一下博主，如果三连点赞评论收藏就更好啦！谢谢各位大佬给予的支持！

一次利用 ChatGPT 给出数据抓取代码，借助 NebulaGraph 图数据库与图算法预测体坛赛事的尝试。

作者：古思为

蹭 ChatGPT 热度

最近因为世界杯正在进行，我受到这篇 Cambridge Intelligence 的文章启发（在这篇文章中，作者仅仅利用有限的信息量和条件，借助图算法的方法做出了合理的冠军预测），想到可以试着用图数据库 NebulaGraph 玩玩冠军预测，还能顺道科普一波图库技术和图算法。

本来想着几个小时撸出来一个方案，但很快被数据集的收集工作劝退了，我是实在懒得去「FIFA 2022 的维基」抓取所需的数据，索性就搁浅、放了几天。

同时，另一个热潮是上周五 OpenAI 发布了 ChatGPT 服务，它可以实现各种语言编码。ChatGPT 可实现的复杂任务设计包括：

随时帮你实现一段指定需求的代码
模拟任意一个 prompt 界面：Shell、Python、Virtual Machine、甚至你创造的语言
带入给定的人设，和你聊天
写诗歌、rap、散文
找出一段代码的 bug
解释一段复杂的正则表达式的含义

ChatGPT 的上下文联想力和理解力到了前所未有的程度，以至于所有接触它的人都在讨论新的工作方式：如何掌握让机器帮助我们完成特定任务。

所以，当我试过让 ChatGPT 帮我写复杂的图数据库查询语句、解释复杂图查询语句的含义、解释一大段 Bison 代码含义之后，我突然意识到：为什么不让 ChatGPT 帮我写好抓取数据的代码呢？

抓取世界杯数据

我真试了下 ChatGPT，结果是：完全可以，而且似乎真的很容易。

整个实现过程，基本上我像是一个代码考试的面试官，或是一个产品经理，提出我的需求，ChatGPT 给出具体的代码实现。我再试着运行代码，找到代码中不合理的地方，指出来并给出建议，ChatGPT 真的能理解我指出的点，并给出相应的修正，像是：

这一全过程我就不在这里列出来了，不过我把生成的代码和整个讨论的过程都分享在这里，感兴趣的同学可以去看看。

最终生成的数据是一个 CSV 文件：

代码生成的文件 world_cup_squads.csv
手动修改、分开了生日和年龄的列 world_cup_squads_v0.csv

上面的数据集包含的信息有：球队、小组、编号、位置、球员名字、生日、年龄、参加国际比赛场次、进球数、服役俱乐部。

这是手动删除了 CSV 表头的数据集 world_cup_squads_no_headers.csv。

图方法预测 2022 世界杯

图建模

本文用到了图数据库 NebulaGraph 和可视化图探索工具 NebulaGraph Explorer，你可以在阿里云免费申请半个月的试用，入口链接是👉🏻 申请使用云端 NebulaGraph。

图建模（Graph Modeling）是把真实世界信息以”点–>边“的图形式去抽象与表示。

这里，我们把在公共领域获得的信息映射成如下的点与边：

点：

player（球员）
team（球队）
group（小组）
club（俱乐部）

边：

groupedin（球队属于哪一小组）
belongto（队员属于国家队）
serve（队员在俱乐部服役）

而队员的年龄、参加国际场次（caps）、进球数（goals）则很自然作为 player 这一类点的属性。

下图是这个 schema 在 NebulaGraph Studio/Explorer（后边称 Studio/Explorer）中的截图：

我们右上角的保存后，便能创建一个新的图空间，将这个图建模应用到图空间里。

这里可以参考下 Explore 草图的文档：https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/db-management/draft/

导入数据进 NebulaGraph

有了图建模，我们可以把之前的 CSV 文件（无表头版本）上传到 Studio 或者 Explorer 里，通过点、选关联不同的列到点边中的 vid 和属性：

完成关联之后，导入，就能把整个图导入到 NebulaGraph。成功之后，我们还得到了整个的关联配置文件：nebula_importer_config_fifa.yml，你可以直接拖拽整个配置，不用自己去配置它了。

这里可以参考 Explorer 数据导入的文档：https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/db-management/11.import-data/

数据导入后，我们可以在 schema 界面查看数据统计。可以看到，有 831 名球员参加了 2022 卡塔尔世界杯，他们服役在 295 个不同的俱乐部：

这里我们用到了 Explorer 的 schema 创建的文档：https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/db-management/10.create-schema/#_6

探索数据

查询数据

下面，我们试着把所有的数据展示出来看看。

首先，借助 NebulaGraph Explorer，我用拖拽的方式画出了任意类型的点（TAG）和任意类型点（TAG）之间的边。这里，我们知道所有的点都包含在至少一个边里，所以不会漏掉任何孤立的点。

让 Explorer 它帮我生成查询的语句。这里，它默认返回 100 条数据（），我们手动改大一些，将 LIMIT 后面的参数改到 10000，并让它在 Console 里执行。

初步观察数据

结果渲染出来是这样子，可以看到结果自然而然地变成一簇簇的模式。

这些外围、形成的簇多是由不怎么知名的足球俱乐部，和不怎么厉害的国家队的球员组成，因为通常这些俱乐部只有一两个球员参加世界杯，而且他们还集中在一个国家队、地区，所以没有和很多其他球员、国家队产生连接。

图算法辅助分析

在我了 Explorer 中的两个按钮之后（详细参考后边的文档链接），在浏览器里，我们可以看到整个图已经变成：

这里可以参考 Explorer 的图算法文档：https://docs.nebula-graph.com.cn/3.3.0/nebula-explorer/graph-explorer/graph-algorithm/

其实，Explorer 这里利用到了两个图算法来分析这里的洞察：

利用点的出入度，改变它们的显示大小突出重要程度
利用 Louvain 算法区分点的社区分割

可以看到红色的大点是鼎鼎大名的巴塞罗那，而它的球员们也被红色标记了。

预测冠军算法

为了能充分利用图的魔法（与图上的隐含条件、信息），我的思路是选择一种利用连接进行节点重要程度分析的图算法，找出拥有更高重要性的点，对它们进行全局迭代、排序，从而获得前几名的国家队排名。

这些方法其实就体现了厉害的球员同时拥有更大的社区、连接度。同时，为了增加强队之间的区分度，我准备把出场率、进球数的信息也考虑进来。

最终，我的算法是：

取出所有的的关系，过滤其中进球数过少、单场进球过少的球员（以平衡部分弱队的老球员带来的过大影响）
从过滤后的球员中向外探索，获得国家队
在以上的子图上运行 Betweenness Centrality 算法，计算节点重要度评分

算法过程

首先，我们取出所有进球数超过 10，场均进球超过 0.2 的的子图：

为了方便，我把进球数和出场数也作为了 serve 边上的属性了。

然后，我们全选图上的所有点，左边的工具栏，选择出方向的边，向外进行图拓展（遍历），同时选择将拓展得到的新点标记为旗帜的 icon：

现在，我们获得了最终的子图，我们利用工具栏里的浏览器内的图算法功能，执行 BNC（Betweenness Centrality）

最后，这个子图变成了这样子：

预测结果

最终，我们根据 Betweenness Centrality 的值排序，可以得到最终的获胜球队应该是：巴西 🇧🇷！

其次是比利时、德国、英格兰、法国、阿根廷，让我们等两个礼拜回来看看预测结果是否准确吧 :D。

注：排序数据（其中还有非参赛球队的点）

Vertex
Betweenness Centrality
Brazil🇧🇷 3499
Paris Saint-Germain 3073.00
Neymar 3000
Tottenham Hotspur 2740
Belgium🇧🇪 2587.0
Richarlison 2541
Kevin De Bruyne 2184
Manchester City 2125
İlkay Gündoğan 2064
Germany🇩🇪 2046
Harry Kane (captain 1869
England🏴󠁧󠁢󠁥󠁮󠁧󠁿 1864
France🇫🇷 1858.00
Argentina🇦🇷 1834.00
Bayern Munich 1567
Kylian Mbappé 1535.00
Lionel Messi (captain 1535.00
Gabriel Jesus 1344

原文地址：https://discuss.nebula-graph.com.cn/t/topic/11584

谢谢你读完本文 (///▽///)

Jay 是一位经验丰富并且对质量要求很高的开发者，对 Angular、React 等多种框架都很熟悉，我们在开源社区认识，在我做开源社区运营的过程中，Jay 给了我很多帮助，他也是 React DevUI 开源组件库的创建者。

2021年11月，由 Jay 主导发起了 React DevUI 开源组件库项目，经过一年多的孵化🐣，终于在发布 18.0.0 正式版本🎉

特性：

基于最新的++技术栈
包含个灵活、高质量的组件
包含配套的 Admin 系统（持续完善中）
支持主题定制
支持国际化
支持 TypeScript
支持 Monorepo
支持单测试（持续完善中）
包含完善的设计指南 / 开发规范 / 贡献流程
完善的构建 / 发布 / 测试 / 依赖管理等基础设施

除了使用了最新的技术进行组件开发之外，React DevUI 还对组件的细节体验进行极致的打磨，比如：

🌈 所有组件和网站均遵循WCAG 2.0规范做了无障碍设计（Accessibility），比较明显的就是焦点管理和对键盘方向键的支持，欢迎到我们的官网体验。
⚡ 针对大数据量的列表做了极致的虚拟滚动，渲染和筛选数十万数据无任何卡顿，感兴趣可以体验下我们的Select组件。
✨ 在API设计上，我们也经过了仔细的推敲和思考，所有组件的 API 都以易用和是否符合预期为设计原则，简洁、灵活、开发者友好，从Compose组件就可以窥见一斑。

为什么要开发这个组件库

接触前端从 Vue2 开始，深入学习的是 Angular（公司项目），这里插一句，Angular 作为前端开发者真的可以好好学一下，主要是学习其编程思想和比较与其它框架的差异。我个人对于 React 还是非常感兴趣的，所以当时就看了 React17 官网文档和相关教程，state => ui 这种纯粹的驱动模式简直是完美，我喜欢这种可靠的渲染，但奇葩的是异步函数里调用 setState 会立即重新渲染，虽然到目前为止我都没有过多时间了解 React18 之前的东西，不过当时我就想这绝对是个 bug 收集器。

可能缘分是个奇妙的东西，我不知道怎么就看到的 React18 的新特性，这个 concurrency（并发）那可真是看的我人麻了，这绝对会是目前最好的框架，那一刻 jay 知道必须写个组件库。

组件库的技术选型

开发组件库的技术栈为 react18 + ts + sass，react18 + ts 没啥好说的，这里说说为什么用 sass。

当初也有人建议用 css in js，其实在这之前我是不知道这个概念的，毕竟没用过 React，了解之后发现其灵活性的确是 sass 无法比拟的，但是我真的要为了这种灵活性舍弃：

开发成本，sass 作为最受欢迎的 css 扩展，但凡前端几乎了解，不了解的也无所谓，sass 完全兼容 css 语法。
样式独立，样式独立于组件，我希望开发其它框架组件时不用再写一套样式，本质是一种模块化，即样式的模块化，我相信好处不止于此。
性能。

最终我选择 sass，而且 sass + css 变量的灵活性不见得不如 css in js，特别是有样式规范的情况下。

组件遵循的规范

组件库从诞生之初就遵循下面最基本的规范：

如果有无障碍支持，那么一定要实现。
国际化（i18n）支持。
SSR 支持。
移动设备支持。

后面开发中添加了组件类支持：

Compose 组合
Form 表单

其它的一些规范：

Prop 命名，如支持 form 的输入为，弹窗状态统一为。
列表类组件的大数据支持，实现时间复杂度为 O(n)，如 Select 选择框。
一些边边角角我实在记不起来了。

样式规范

组件样式规范：

命名遵循 BEM 规范。
明显的聚焦或激活样式反馈。
内敛的动画，即动画变化属性数量尽可能少（一般小于等于 2 个），如 Button 聚焦时仅变化背景色或边框。

优势在于是由经验丰富的技术大佬主导的开源项目

说吧，为啥用你这组件库。

所有组件由 jay 开发，这意味着：

所有组件均遵循规范。
统一的 API 设计。
统一的样式设计。
性能的把控。
极简的大小，npm 包 未压缩 不超过 1MB！

网址

GitHub – 欢迎大家点亮Star🌟
React DevUI 官网
React DevUI Admin 官网

— END —

我是 Kagol，如果你喜欢我的文章，可以给我点个赞，关注我的掘金账号和公众号，一起交流前端技术、一起做开源！

最近，我被一款叫做 ChatGPT 的人工智能（AI）聊天机器人，刷屏了。网上有人说它是搜索引擎杀手，还有人说它将取代程序员…

最后，我还是没扛住铺天盖地的赞美，跑去注册了个账号，抱着调侃“人工智障”的心态，想要调戏 ChatGPT 一番。于是就有了下面的对话：

此时，我内心毫无波澜。

此刻，我放下了傲慢与偏见。

对不起，是我鲁莽了，我才是智障。

不得不承认 ChatGPT 确实有点东西，然后我就问了一嘴它有没有开源。

ChatGPT 没有给出准确的答复，所以我去查了下截止到本文发布时 ChatGPT 并没有开源，而且官方也没有任何关于 ChatGPT 的开源计划。

那 ChatGPT 未来会不会开源呢？为了回答这个问题，我去查了它背后的公司、创始人、提供的服务、开源的项目，综合这些信息文章最后我给出了自己的看法：不会。如果你也对这个话题感兴趣的话，那不妨一起来看看吧。

特别说明：ChatGPT 官方并未给出明确的开源计划，以下均为我的个人观点，仅供参考。

谁做出了火爆全网的 ChatGPT？

ChatGPT 是由 OpenAI 公司开放的免费 AI 聊天机器人服务。

OpenAI 是一个人工智能研究实验室，由营利组织 OpenAI LP 与母公司非营利组织 OpenAI Inc 组成，目的是促进和发展友好的人工智能，让更多人受益。它成立于 2015 年底，总部位于旧金山，目标是通过与其他机构和研究者的“自由合作”，向公众开放专利和研究成果。

程序员应该对 OpenAI 这个公司并不陌生，因为知名的人工智能编程助手 Copilot 就是它和 GitHub 合作开发的。

如果你不是程序员，那这个人你应该听说过。OpenAI 有两位创始人其中一位是埃隆·马斯克，对！就是那个特斯拉汽车的 CEO，最近刚收购了 Twitter 的那位。他曾在 2014 年，开放了特斯拉汽车的所有专利。另一位创始人是原 Y Combinator（美国著名创业孵化器）总裁山姆·阿尔特曼，美国斯坦福大学计算机系辍学生。

OpenAI 资金这块，创始人一个当过首富一个是创投，肯定是不缺投资，况且在 2019 年的时候微软还给它投了 10 个亿美。

如果将创始人比作公司的 DNA，那 OpenAI 无论是公司目标还是 DNA，对待“开放”都是积极的态度。虽然 OpenAI 不缺钱，但既然是公司就肯定要赚钱，所以也不会什么都“白给”。

OpenAI 与开源

OpenAI 喊着开放的口号，到底有没有做过“开放”的事儿？

我在 GitHub 上找到了 OpenAI 开源组织的地址：

https://github.com/openai

接下来，就通过介绍 4 款 OpenAI 开源的知名开源项目，从它们身上看看 OpenAI 对待开源的态度。

1.强化学习训练场：Gym

Star 数：29.2k｜编程语言：Python（99.9%）

这是一个用于强化学习研究的 Python 工具包，包含了许多经典的强化学习环境，如游戏、机器人控制、计算机视觉等。它还提供了一个统一的接口，可以让用户定义任务、训练智能体和评估性能。简单来说就是 Gym 提供问题和环境，你用 AI 框架来解。就像刷算法的网站提供算法题和测试用例，让你十分方便地刷算法一样。

比如，下面就是 Gym 提供的一个场景：

一个推车上立着一根棍子，让智能体（AI）控制推车左右移动，保证车子上的棍子不倒。

地址：https://github.com/openai/gym

2.强大的语言识别系统：Whisper

Star 数：17.6k｜编程语言：Python

该项目是一款开源的自动语音识别系统，支持包括中文在内的多种语言。尤其是在快语速、口音、背景噪音等场景，依旧表现出色能够达到极高的准确率。

地址：https://github.com/openai/whisper

3.用文字生成图片：DALL·E

Star 数：9.3k｜编程语言：Python

它能够将文本描述映射到对应的图像，并生成对应的图像。例如，如果向 DALL·E 提供文本描述“午后晒太阳的小猫”，它就会生成一张图片，展示一只猫在晒太阳。需要注意的是 DALL·E 并未完全开源，下图是用最新的 DALL·E 2 生成，该项目没有开源仅提供生成图片的服务。

地址：https://github.com/openai/DALL-E

4.大型语言模型：GPT

GPT 是 Generative Pretrained Transformer 的缩写，一种由 OpenAI 提出的大型预训练语言模型。它使用了许多深度学习技术，可以生成文本内容，也可以进行文本分类、问答等任务。GPT 与传统的机器学习方法不同，它通过预先训练来学习大量文本数据，然后可以进行各种自然语言处理任务。它的训练方法非常有效，在许多 NLP 挑战赛中取得了优异的成绩。

GPT-2 和 GPT-3 是两种不同的大型语言模型，GPT-3 是 GPT-2 的一个升级版，它在功能和性能方面都有所提高，比如具有更大的模型规模、更高的准确率、更快的训练速度和处理更复杂任务的能力，但GPT-3 并未开源。

ChatGPT 就是基于 GPT-3.5 最新训练出来的模型。

GPT-2：https://github.com/openai/gpt-2

GPT-3：https://github.com/openai/gpt-3

通过这些开源项目，我们不难看出 OpenAI 确实是以开放的态度，分享技术、开放研究成果，而且几乎每一次开源新项目都会掀起一波热潮。

但近些年，OpenAI 为了保证核心竞争力和提高盈利能力，开始选择部分开源或者不开源，逐步过渡到通过提供 API 有偿地提供服务。

最后

我想看到这里，关于「ChatGPT 未来会开源吗？」的问题，想必大家心中已经有了答案。

我个人的观点是：ChatGPT 不会开源。因为 GPT-3 截止目前都没有开源，所以我感觉 ChatGPT（3.5）开源的希望就更渺茫了，而且 OpenAI 商业化的趋势也已经显而易见。对此你怎么看，欢迎留言发表看法。

最后，虽然 ChatGPT 并不完美但已经让我重新审视 AI 的能力，甚至已经开始畅想那种：用类似与人对话的方式操作计算机，一种全新的人机交互方式。但我深知此事任重而道远，减少期望才会看到更多惊喜，慢慢来吧。

有人用 ChatGPT 写代码、解 bug、找乐子…还有人熬夜蹭它的热度，就为了一个“赞”。没错，正是在下。如果您觉得这篇文章写得还不错，就请给我点一个赞，您的支持就是我更新的动力。我们下期见～

基于文本识别（OCR）技术的成熟与应用，日常生活中的大部分“印刷体识别”需求都能被满足，替代了人工信息录入与检测等操作，大大降低输入成本。

而对于复杂的手写体识别需求，业界识别质量却参差不齐。大部分手写体存在字迹潦草，排版不固定，背景复杂，且不同的字体风格各异等问题，给手写体识别带来极大的挑战，不过华为HMS Core机器学习服务的OCR文字识别技术可以帮助解决识别问题。

华为HMS Core 机器学习服务基于OCR识别技术推出最新手写体识别能力，使用拍照设备将纸质信息转化为图片，对图片中横排的手写中文、英文、阿拉伯数字等符号进行检测和识别，支持印刷体识别、手写体识别、行间混排等，可以精准返回手写体和印刷体的类别。同时，对字迹潦草、连笔等情况和试卷、书信等场景进行专项优化，识别准确率可达95%以上。

效果演示：

应用场景：

由于手写体字迹的随意性很大，如背景繁杂、字体大小不一、角度倾斜等，这些问题都有可能直接影响到字符的识别准确率。

基于此，HMS Core 机器学习服务通过海量样本集训练来提升其鲁棒性，不管是浅色背景、田字格、米字格、四方格，还是在有下划线的情况下，识别准确率均可达95%以上，同时支持45°倾斜字体的识别。

手写体识别具有很强的实用性，可广泛应用于试卷批改、笔记电子化、大规模的数据统计如人口普查、信息登记等场景中。

1.智能批改

使用手写体识别技术，对学生日常作业、考试试卷中的手写内容进行自动识别，实现学生作业、考卷的线上批改，大幅提升教师的工作效率和质量。

2.笔记电子化

针对纸质手写文档、手写笔记等内容，同时支持墨水屏识别，实现对手写文字内容的扫描及存储。

开发者只需集成手写体识别服务，就可以将手写纸质文档、笔记、发票等图片中的文字转换成文本格式，供文字处理软件进一步编辑加工。有了它，即使是潦草、模糊的手写信息也能够识别，可以有效解决人工录入速度慢、易出错的问题，从而大大节约时间成本，提高录入效率。

总之，不管是印刷体，还是手写体，HMS Core机器学习服务都能准确识别，开发者们可以根据自己的业务需求自主选择。

了解更多详情>>

访问华为开发者联盟官网
获取开发指导文档
华为移动服务开源仓库地址：GitHub、Gitee

关注我们，第一时间了解 HMS Core 最新技术资讯~

Nginx rewrite 详解

本篇主要介绍 nginx 的 rewrite 重定向这个功能进行详解介绍, 以及介绍它的使用场景

1. rewrite 基本介绍

rewrite是实现URL重写的关键指令，根据regex (正则表达式)部分内容,重定向到replacement，结尾是flag标记。

基本语法:

regex: 正则表达式语句进行规则匹配
replacement: 将正则匹配的内容替换成replacement
flag: last | break | redirect | permanent
- last : 本条规则匹配完成后，继续向下匹配新的location URI规则
- break: 本条规则匹配完成即终止，不再匹配后面的任何规则
- redirect : 回302临时重定向，浏览器地址会显示跳转后的URL地址 (防爬虫)
- permanent : 返回301永久重定向，浏览器地址栏会显示跳转后的URL地址

rewrite 使用位置

server : 在server中针对所有的请求
location : 在 location 中则针对单个匹配路径的
If

2. server 中使用 rewrite

直接在server中使用 rewrite ,

2.1 rewrite 外部站点

rewrite 到外部站点是指 replacement 部分是一个完整的带 http/https 的外部路径 ,它的特点是浏览器会再次请求这个新的站点所以浏览器上的地址一定会发生变化不受 flag 参数影响

下面的配置是所有的请求都转发了 https://www.askajohnny.com

经过测试可以发现直接跳转过去并且浏览器中的地址也直接变成了 https://www.askajohnny.com , 待会我们再详细讨论什么时候会变化这个地址

, 因为我的登录当时填写的回调是 http,又因为互联的审核太麻烦太慢所以干脆就这样配置

2.2 rewrite 到内部站

点

rewrite 到内部站点是指 replacement 不带http/https 而是内部的另外一个路径 , 相当于访问隐藏起来的这个内部路径,

经过测试当访问 www.testfront.com/222.html 的时候

flag = last 浏览器不会变化隐藏了后端 /my.gif 地址
flag = break 浏览器不会变化隐藏了后端 /my.gif 地址
flag = redirect 和 permanent 浏览器变化了URL 变更状态码 302和 301

3. location 中使用rewrite

location 中也可以使用 rewrite 意思是只有匹配到这个location 后才经过 rewrite 的正则通过后再跳转

希望是如果访问的后缀是数字.html 则返回 my.gif 图 ,其他的都代理到 http://www.testbackend.com

经过测试只有访问www.testfront.com/数字.html 的时候才能获取到 my.gif 文件

4. 使用场景模拟

4.1 基于域名跳转

比如现在你所在的公司网站域名是 www.testfront.com 现在需要使用新的域名 www.newtestfront.com 替代, 但是旧的域名不能作废, 需要让旧的域名跳转到新的域名上 , 并且保持后面参数不变

4.2 基于客户端 IP 访问跳转

今天公司业务新版本上线，要求所有 IP 访问任何内容都显示一个固定维护页面，只有公司IP:192.168.200.100访问正常。

此时如果是 172.16.225.1 访问就可以到后端, 如果是其他的客户端ip 访问就只能到 weihu.html 页面

总结

本篇主要介绍了 nginx 中 rewrite 的基本概念以及基本的使用方式 ,rewrite 可以出现在 server , location , if 中

并且介绍了什么时候才会变化浏览器URL , 以及介绍了2个模拟场景

rewirte 内部站点

当rewrite 到内部站点的时候会根据 flag 参数 last break不变 redirect permanent 变化
rewrite 外部站点带http/https 等

当rewrite 外部站点不管flag 参数浏览器URL都会进行变化相当于浏览器进行了二次请求了

欢迎大家访问个人博客 Johnny小屋
欢迎关注个人公众号

应用发布后，尤其在发布初期，我们要格外关注应用的性能稳定性，如ANR、画面卡顿、加载慢等问题，如果不能及时被监测及解决，将会给用户带来非常糟糕的体验，导致低评、差评，甚至造成部分意向用户直接流失。HUAWEI AppGallery Connect性能管理服务，除了提供分钟级的应用性能监控能力，整体帮您快速定位、精准修复性能问题外，还提供了单点查询及日志回捞功能，可用于分析并解决特定用户遇到的问题，和获取指定用户终端上的日志进行分析，帮您更快速、更精准地定位、解决重点用户的问题，进一步提升应用的用户体验。

单点查询即查看单用户应用性能数据，页面目前覆盖了“ANR分析”、“页面分析”、“慢启动追踪”与“网络分析”子项。

您可以通过在“用户标识”搜索框输入应用中设定的用户标识，查询某个用户的应用性能监控数据。

基本步骤：进入“应用性能管理”页面，选择“单点查询”页签即可使用。

ANR，即Application Not Responding，也就是应用程序无响应。如果Android应用的界面线程处于阻塞状态的时间过长，就会触发“应用无响应”(ANR) 的错误。单点查询菜单下的ANR分析可以展示单用户在选定时间范围内应用ANR事件的发生次数、应用启动次数、用户ANR率，以及问题列表。

“问题列表”中右侧“操作”列的“查看详情”，可查看具体问题的“ANR问题详情”页面。该页面展示了ANR问题发生时的详细信息，包括设备信息、系统信息、应用信息以及主线程堆栈、其他线程堆栈、系统日志、ANR信息，帮助您快速定位解决ANR问题。另外还提供了记录导出功能，您可以可将该页面所有数据导出，进行对比分析。

页面分析展示单用户在选定时间范围内所打开的屏幕名称总览，某个屏幕的慢加载与慢呈现占比等信息。

屏幕名称右侧“操作”列的“查看详情”，可查看该屏幕详情页面，包括屏幕加载及屏幕呈现的具体信息。屏幕加载主要分析用户切换屏幕是否流畅，统计当前屏幕打开到用户可交互的时间。屏幕呈现主要分析该屏幕内容是否呈现完整，统计当前屏幕打开到内容呈现完毕的时间。详细的屏幕指标说明请参见查看体验分析数据。

慢启动追踪展示单用户冷启动与热启动时慢启动的发生事件列表，每条事件记录冷/热启动的发生时间、耗时、应用版本、系统版本以及接入方式等信息。

网络分析展示单用户在选定时间范围内访问的URL以及相应的网络指标信息。

查看单点查询功能更多详情。

什么是日志回捞？

为方便您根据详细的客户端运行日志进行问题定位分析，我们提供了自定义日志功能，最大2MB。所记录的日志内容记录在本地，当您需要查看此日志内容时，可以在AGC控制台创建日志回捞任务，获取指定用户终端上的日志进行查看分析。

1、选择“日志回捞”页签，“创建任务”开始创建。

（注：创建日志回捞任务之前需先接入应用，设置用户标识等，以此决定哪些用户可以接收到回捞任务。具体步骤及代码指导请见文档）

在创建任务界面，填写任务名称、任务描述、拉取日志的时间范围，以及用户标识。

作者：谢泽华

背景

众所周知单个机房在出现不可抗拒的问题（如断电、断网等因素）时，会导致无法正常提供服务，会对业务造成潜在的损失。所以在协同办公领域，一种可以基于同城或异地多活机制的高可用设计，在保障数据一致性的同时，能够最大程度降低由于机房的仅单点可用所导致的潜在高可用问题，最大程度上保障业务的用户体验，降低单点问题对业务造成的潜在损失显得尤为重要。

同城双活，对于生产的高可用保障，重大的意义和价值是不可言喻的。表面上同城双活只是简单的部署了一套生产环境而已，但是在架构上，这个改变的影响是巨大的，无状态应用的高可用管理、请求流量的管理、版本发布的管理、网络架构的管理等，其提升的架构复杂度巨大。

结合真实的协同办公产品：京办（为北京市政府提供协同办公服务的综合性平台）生产环境面对的复杂的政务网络以及京办同城双活架构演进的案例，给大家介绍下京办持续改进、分阶段演进过程中的一些思考和实践经验的总结。本文仅针对ES集群在跨机房同步过程中的方案和经验进行介绍和总结。

架构

1.
部署Logstash在金山云机房上，Logstash启动多个实例（按不同的类型分类，提高同步效率），并且和金山云机房的ES集群在相同的VPC

2.
Logstash需要配置大网访问权限，保证Logstash和ES原集群和目标集群互通。

3.
数据迁移可以全量迁移和增量迁移，首次迁移都是全量迁移后续的增加数据选择增量迁移。

4.
增量迁移需要改造增加识别的增量数据的标识，具体方法后续进行介绍。

原理

Logstash工作原理

Logstash分为三个部分input 、filter、ouput：

1.
input处理接收数据，数据可以来源ES，日志文件，kafka等通道.

2.
filter对数据进行过滤，清洗。

3.
ouput输出数据到目标设备，可以输出到ES，kafka，文件等。

增量同步原理

1. 对于T时刻的数据，先使用Logstash将T以前的所有数据迁移到有孚机房京东云ES，假设用时∆T

2. 对于T到T+∆T的增量数据，再次使用logstash将数据导入到有孚机房京东云的ES集群

3. 重复上述步骤2，直到∆T足够小，此时将业务切换到华为云，最后完成新增数据的迁移

适用范围：ES的数据中带有时间戳或者其他能够区分新旧数据的标签

流程

准备工作

1.
创建ECS和安装JDK忽略，自行安装即可

2.
下载对应版本的Logstash，尽量选择与Elasticsearch版本一致，或接近的版本安装即可

https://www.elastic.co/cn/downloads/logstash

1）源码下载直接解压安装包，开箱即用

2）修改对内存使用，logstash默认的堆内存是1G，根据ECS集群选择合适的内存，可以加快集群数据的迁移效率。

3. 迁移索引

Logstash会帮助用户自动创建索引，但是自动创建的索引和用户本身的索引会有些许差异，导致最终数据的搜索格式不一致，一般索引需要手动创建，保证索引的数据完全一致。

以下提供创建索引的python脚本，用户可以使用该脚本创建需要的索引。

create_mapping.py文件是同步索引的python脚本，config.yaml是集群地址配置文件。

注：使用该脚本需要安装相关依赖

拷贝以下代码保存为 create_mapping.py：

配置文件保存为config.yaml：

以上代码和配置文件准备完成，直接执行 python create_mapping.py 即可完成索引同步。

索引同步完成可以取目标集群的kibana上查看或者执行curl查看索引迁移情况：

全量迁移

Logstash配置位于config目录下。

用户可以参考配置修改Logstash配置文件，为了保证迁移数据的准确性，一般建议建立多组Logstash，分批次迁移数据，每个Logstash迁移部分数据。

配置集群间迁移配置参考：

增量迁移

预处理：

1. @timestamp 在elasticsearch2.0.0beta版本后弃用

https://www.elastic.co/guide/en/elasticsearch/reference/2.4/mapping-timestamp-field.html

2. 本次对于京办从金山云机房迁移到京东有孚机房，所涉及到的业务领域多，各个业务线中所代表新增记录的时间戳字段不统一，所涉及到的兼容工作量大，于是考虑通过elasticsearch中预处理功能pipeline进行预处理添加统一增量标记字段：gmt_created_at，以减少迁移工作的复杂度（各自业务线可自行评估是否需要此步骤）。

3. 检查pipeline是否生效

4. 各个index设置对应settings增加pipeline为默认预处理

5. 检查新增settings是否生效

增量迁移脚本

schedule-migrate.conf

index：可以使用通配符的方式

query: 增量同步的DSL，统一gmt_create_at为增量同步的特殊标记

schedule: 每分钟同步一把，”* * * * *”

问题：

mapping中存在join父子类型的字段，直接迁移报400异常

解决方法：

https://discuss.elastic.co/t/an-routing-missing-exception-is-obtained-when-reindex-sets-the-routing-value/

https://github.com/elastic/elasticsearch/issues/26183

结合业务特征，通过在filter中加入小量的ruby代码，将_routing的值取出来，放回logstah event中，由此问题得以解决。

示例：

作者：王嘉宁、汪诚愚、邱明辉、石秋慧、王洪彬、黄俊、高明

近日，阿里云机器学习平台 PAI 与华东师范大学高明教授团队合作在自然语言处理顶级会议 EMNLP2022 上发表基于 Prompt-Tuning 的小样本机器阅读理解算法 KECP（Knowledge Enhanced Contrastive Prompt-tuning）。KECP 是一种面向机器阅读理解的小样本学习算法，采用 Prompt-Tuning 作为基础学习范式，在仅需要标注极少训练数据的情况下，在给定文章中抽取满足要求的文本作为答案。

论文：

Jianing Wang*, Chengyu Wang*, Minghui Qiu, Qiuhui Shi, Hongbin Wang, Jun Huang, Ming Gao. KECP: Knowledge-Enhanced Contrastive Prompting for Few-shot Extractive Question Answering. EMNLP 2022

背景

在预训练语言模型广泛应用的背景下，传统的机器阅读理解（Machine Reading Comprehension）任务通常需要大量的标注数据来微调模型（例如 BERT）。机器阅读理解任务旨在给定一篇文章（Passage）和一个问题（Question），从文章中寻找对应问题的答案（Answer）。通常情况下，我们假设答案来自于文章中的子片段，这一任务可以进一步被称为抽取式阅读理解，或抽取式问答（Extractive Question Answering）。这一任务在大量深度学习应用中有广泛的应用场景，例如任务型对话系统等。

传统的抽取式问答采用序列标注或指针网络的方法，获得答案在给定文章的区间，其学习范式如下图（a）所示：

然而，这种方法需要重头开始学习 Preduction Head 的参数，在小样本场景下容易过拟合。最近 Prompt-Tuning（即提示微调）相关方法的提出缓解了预训练语言模型在低资源场景下的过拟合问题。特别地，对于 BERT 类模型，其通常是将下游任务目标转换为预训练目标（例如 Masked Language Modeling），以充分复用预训练阶段的先验知识。受到这个启发，我们将抽取式阅读理解转换为基于 BERT 的生成任务，如上图（b）。

算法概述

我们提出的 KECP（Knowledge Enhanced Contrastive Prompt-tuning）模型综合利用了模型表示的知识增强和对比学习技术，提升了小样本学习场景下的机器阅读理解准确度，模型架构图如下：

模型输入

首先，我们将问题（Question）转换为陈述句，并通过一些启发式规则将问题变为类似完形填空任务。例如，我们可以将问题

What was one of the Normans’major exports?

变为

[MASK] [MASK] [MASK] was one of the Normans’major exports.

其中[MASK]为待预测的 Token。最后，我们将这一陈述句和文章进行拼接在一起，形成统一的输入序列：

知识增强的语义表达

因为训练样本很少时，模型的推理能力有限；因此，我们提出了知识注入方法，即给定一个知识库（例如 Wikidata5M），我们使用实体链指工具识别出文章（Passage）中所有实体。在 KECP 算法中，我们提出了 Passage Knowledge Injection 模块，将预训练知识库实体表征与 Word Embedding 表征向量通过门控单进行向量融合：

为了避免注入过多知识引起知识噪音（Knowledge Noise）问题，我们将融合了知识的文章表征信息聚集到问题部分挑选的 Token 中。例如，在前述示例中，我们挑选了名词“Norman Major Exports”，我们可以通过 Self-Attention 模型将文章中的实体融合向量进一步融合到这些选定的 Token 中：

这样，我们能获得更好的文本表征。

对比学习增强的模型训练

在获得新的表征向量后，我们将这些表征喂入 BERT 模型中，进行模型的训练。我们复用了预训练任务目标 Masked Language Modeling（MLM）。为了提高模型效果，我们采用对比学习对学习目标进行增强。在 KECP 的对比学习模块中，正样本为 Ground Truth，负样本为通过知识库检索到文章中的一些错误的实体（这些实体可能会对模型预测产生混淆），损失函数如下：

KECP 协同最小化 MLM 和对比学习损失，得到最终的机器阅读理解模型。

算法精度评测

为了评测 KECP 算法的精度，我们在一些常用的机器阅读理解数据集上，随机采样 16 个样本进行训练，结果如下：

结果可以证明，KECP 在这些数据集上获得不错的效果。在未来，我们会拓展 KECP 到到 BART、T5 等生成式模型上，训练更加通用的生成式阅读理解模型。为了更好地服务开源社区，KECP 算法的源代码即将贡献在自然语言处理算法框架 EasyNLP 中，欢迎 NLP 从业人员和研究者使用。

EasyNLP 开源框架：https://github.com/alibaba/EasyNLP

参考文献

Chengyu Wang, Minghui Qiu, Taolin Zhang, Tingting Liu, Lei Li, Jianing Wang, Ming Wang, Jun Huang, Wei Lin. EasyNLP: A Comprehensive and Easy-to-use Toolkit for Natural Language Processing. EMNLP 2022
Xiang Lisa Li, Percy Liang. Prefix-Tuning: Optimizing Continuous Prompts for Generation. ACL/IJCNLP 2021: 4582-4597
Ori Ram, Yuval Kirstain, Jonathan Berant, Amir Globerson, Omer Levy. Few-Shot Question Answering by Pretraining Span Selection. ACL/IJCNLP 2021: 3066-3079
Rakesh Chada, Pradeep Natarajan. FewshotQA: A simple framework for few-shot learning of question answering tasks using pre-trained text-to-text models. EMNLP 2021: 6081-6090
Mandar Joshi, Danqi Chen, Yinhan Liu, Daniel S. Weld, Luke Zettlemoyer, Omer Levy. SpanBERT: Improving Pre-training by Representing and Predicting Spans. Trans. Assoc. Comput. Linguistics 8: 64-77 (2020)
Xiao Liu, Kaixuan Ji, Yicheng Fu, Zhengxiao Du, Zhilin Yang, Jie Tang. P-Tuning v2: Prompt Tuning Can Be Comparable to Fine-tuning Universally Across Scales and Tasks. CoRR abs/2110.07602 (2021)

论文信息

论文名字：KECP: Knowledge-Enhanced Contrastive Prompting for Few-shot Extractive Question Answering

论文作者：王嘉宁、汪诚愚、邱明辉、石秋慧、王洪彬、黄俊、高明

论文 pdf 链接：https://arxiv.org/abs/2205.03071

作者 | 任雪龙

导读

网络直播功能作为一项互联网基本能力已经越来越重要，手机中的直播功能也越来越完善，电商直播、新闻直播、娱乐直播等多种直播类型为用户提供了丰富的直播内容。随着直播的普及，为用户提供极速、流畅的直播观看体验也越来越重要。

全文6657字，预计阅读时间17分钟。

01 背景

百度 APP 作为百度的航母级应用为用户提供了完善的移动端服务，直播也作为其中一个必要功能为用户提供内容。随着直播间架构、业务能力逐渐成熟，直播间播放指标优化也越来越重要。用户直播资源时，可以快速的看到直播画面是其中一个核心体验，起播速度也就成了直播间优化中的一个关键指标。

02 现状

由于包体积等原因，百度 APP 的 Android 版中直播功能使用插件方式接入，在用户真正使用直播功能时才会将直播模块加载。为解决用户直播功能时需要等待插件下载、安装、加载等阶段及兼容插件下载失败的情况，直播团队将播放、IM 等核心能力抽到了一个独立的体积较小的一级插件并内置在百度 APP 中，直播间的挂件、礼物、关注、点赞等业务能力在另外一个体积较大的二级插件中。特殊的插件逻辑和复杂的业务场景使得 Android 版整体起播时长指标表现的不尽人意。

2022 年 Q1 直播间整体起播时长指标 80 分位在 3s 左右，其中二跳（直播间内上下滑）场景在 1s 左右，插件拆分上线后通过观察起播数据发现随着版本收敛，一跳进入直播间携带流地址（页面启动后会使用该地址预起播，与直播列表加载同步执行）场景起播时有明显的增长，从发版本初期 1.5s 左右，随版本收敛两周内会逐步增长到 2.5s+。也就是线上在直播间外直播资源进直播间时有很大一部分用户在后还需要等待 3s 甚至更长时间才能真正看到直播画面。这个时长对用户使用直播功能有非常大的负向影响，起播时长指标急需优化。

03 目标

△起播链路

起播过程简单描述就是用户直播资源，打开直播页面，请求起播地址，调用内核起播，内核起播完成，内核通知业务，业务起播完成打点。从对内核起播时长监控来看，直播资源的在内核中起播耗时大约为 600-700ms，考虑链路中其他阶段损耗以及二跳（直播间内上下滑）场景可以在滑动时提前起播，整体起播时长目标定位为1.5 秒；考虑到有些进入直播间的位置已经有了起播流地址，可以在某些场景省去 “请求起播地址” 这一个阶段，在这种直播间外已经获取到起播地址场景，起播时长目标定为 1.1 秒。

04 难点

特殊的插件逻辑和复杂的业务场景使得 Android 版每一次进入直播的起播链路都不会完全一样。只有一级插件且二级插件还未就绪时在一级插件中请求直播数据并起播，一二级插件都已加载时使用二级插件请求直播数据并处理起播，进直播间携带流地址时为实现秒开在 Activity 启动后就创建播放器使用直播间外携带的流地址起播。除了这几种链路，还有一些其他情况。复杂的起播链路就导致了，虽然在起播过程中主要节点间都有时间戳打点，也有天级别相邻两个节点耗时 80 分位报表，但线上不同场景上报的起播链路无法穷举，使用现有报表无法分析直播大盘起播链路中真正耗时位置。需要建立新的监控方案，找到耗时点，才能设计针对性方案将各个耗时位置进行优化。

05 解决方案

5.1 设计新报表，定位耗时点

△一跳有起播地址时起播链路简图

由于现有报表无法满足起播链路耗时阶段定位，需要设计新的监控方案。观察在打开直播间时有流地址场景的流程图（上图），进入直播间后就会同步创建直播间列表及创建播放器预起播，当直播间列表创建完毕且播放器收到首帧通知时起播流程结束。虽然用户到页面 Activity 的 onCreate 中可能有多个节点（一级插件安装、加载等），页面 onCreate 调用播放器预起播中可能多个节点，内核完成到直播业务收到通知中有多个节点，导致整个起播链路无法穷举。但是我们可以发现，从用户到 onCreate 这个路径是肯定会有的，onCreate 到创建播放器路径也是肯定有的。这样就说明虽然两个关键节点间的节点数量和链路无法确定，但是两个关键节点的先后顺序是一定的，也是必定会有的。由此，我们可以设计一个自定义链路起点和自定义链路终点的查询报表，通过终点和起点时间戳求差得到两个任意节点间耗时，将线上这两个节点所有差值求 80 分位，就可以得到线上起播耗时中这两个节点间耗时。将起播链路中所有核心关键节点计算耗时，就可以找到整个起播链路中有异常耗时的分段。

按照上面的思路开发新报表后，上面的链路各阶段耗时也就比较清晰了，见下图，这样我们就可以针对不同阶段逐个击破。

△关键节点间耗时

5.2 一跳使用一级插件起播

使用新报表统计的重点节点间耗时观察到，直播间列表创建（模版组件创建）到真正调用起播（业务视图就绪）中间耗时较长，且这个耗时随着版本收敛会逐步增加，两周内大约增加 1000ms，首先我们解决这两个节点间耗时增加问题。

经过起播链路观察和分析后，发现随版本收敛，这部分起播链路有较大变化，主要是因为随版本收敛，在二级插件中触发 “业务调用起播” 这个节点的占比增加。版本收敛期，进入直播间时大概率二级插件还未下载就绪或未安装，此时一级插件中可以很快的进行列表创建并创建业务视图，一级插件中在 RecyclerView 的 item attach 到视图树时就会触发起播，这个链路主要是等待内核完成首帧数据的拉取和解析。当二级插件逐渐收敛，进入直播间后一级插件就不再创建业务视图，而是有二级插件创建业务视图。由于二级插件中业务组件较多逐个加载需要耗时还有一级到二级中逐层调用或事件分发也存在一定耗时，这样二级插件起播场景就大大增加了直播间列表创建（模版组件创建）到真正调用起播（业务视图就绪）中间耗时。

5.2.1 一跳全部使用一级插件起播

基于上面的问题分析，我们修改了一跳场景起播逻辑，一跳全部使用一级插件起播。一级插件和二级插件创建的播放器父容器 id 是相同的，这样在一级插件中初始化播放器父容器后，当内核首帧回调时起播过程就可以结束了。二级插件中在初始化播放器父容器时也会通过 id 判断是否已经添加到视图树，只有在未添加的情况（二跳场景或一跳时出现异常）才会在二级中进行兜底处理。在一级插件中处理时速度可以更快，一级优先二级兜底逻辑保证了进入直播间后一定可以顺利初始化视图。

5.2.2 提前请求接口

使用由一起插件处理起播优化了二级插件链路层级较多问题，还有一个耗时点就是进直播间时只传入了房间 room_id 未携带流地址场景，此时需要通过接口请求获取起播数据后才能创建播放器和起播。为优化这部分耗时，我们设计了一个直播间数据请求管理器，提供了缓存数据和超时清理逻辑。在页面 onCreate 时就会触发管理器进行接口请求，直播间模版创建完成后会通过管理器获取已经请求到的直播数据，如果管理器接口请求还未结束，则会复用进行中请求，待请求结束后立刻返回数据。这样在进直播间未携带流数据时我们可以充分利用图中这 300ms 时间做更多必要的逻辑。

5.3 播放器Activity外预起播

通过进直播间播放器预创建、预起播、一跳使用一级插件起播等方案来优化进入直播间业务链路耗时后，业务链路耗时逐渐低于内核部分耗时，播放器内核耗时逐渐成为一跳起播耗时优化瓶颈。除了在内核内部探索优化方案，继续优化业务整个起播链路也是一个重要方向。通过节点间耗时可以发现，用户到 Activity 页面 onCrete 中间也是有 300ms 左右耗时的。当无法将这部分耗时缩到更短时，我们可以尝试在这段时间并行处理一些事情，减少页面启动后的部分逻辑。

一级插件在百度 APP 中内置后，设计并上线了插件预加载功能，上线后用户通过直播资源进入直播间的场景中，有 99%+ 占比都是直播一级插件已加载情况，一级插件加载这里就没有了更多可以的操作空间。但将预起播时机提前到用户处，可以将内核数据加载和直播间启动更大程度并行，这样来降低内核耗时对整个起播耗时影响。 △播放器在直播间外起播示意图

如上图，新增一个提前起播模块，在用户后与页面启动并行创建播放器起播并缓存，页面启动后创建播放器时会先从提前起播模块的缓存中尝试取已起播播放器，如果未获取到则走正常播放器创建起播逻辑，如果获取到缓存的播放器且播放器未发生错误，则只需要等待内核首帧即可。

播放器提前起播后首帧事件大概率在 Activity 启动后到达，但仍有几率会早于直播业务中设置首帧监听前到达，所以在直播间中使用复用内核的播放器时需要判断是否起播成功，如果已经起播成功需要马上分发已起播成功事件（含义区别于首帧事件，防止与首帧事件混淆）。

提前起播模块中还设计了超时回收逻辑，如果提前起播失败或 5s （暂定）内没有被业务复用（Activity 启动异常或其他业务异常），则主动回收缓存的播放器，防止直播间没有复用成功时提前创建的播放器占用较多内存及避免泄漏；超时时间是根据线上大盘起播时间决定，使用一个较大盘起播时间 80 分位稍高的值，防止起播还未完成时被回收，但也不能设置较长，防止不会被复用时内存占用较多。

通过提前起播功能，实验期命中提前起播逻辑较不进行提前起播逻辑，整体起播耗时 80 分位优化均值：450ms+。

5.4直播间任务打散

△内核首帧分发耗时

业务链路和内核链路耗时都有一定优化后，我们继续拆解重点节点间耗时。内核内部标记首帧通知到直播业务真正收到首帧通知之间耗时较长，如上图，线上内核首帧分发耗时 80 分位均值超过 1s，该分段对整体起播耗时优化影响较大。内核首帧是在子线程进行标记，通知业务时会通过主线程 Handler 分发消息，通过系统的消息分发机制将事件转到主线程。

通过排查内核标记首帧时间点到业务收到首帧通知事件时间点之间所有主线程任务，发现在首帧分发任务开始排队时，主线程任务队列中已有较多其他任务，其他事件处理时间较长，导致首帧分发排队时间较久，分发任务整体耗时也就较长。直播业务复杂度较高，如果内核首帧分发任务排队时直播间其他任务已在队列中或正在执行，首帧分发任务需要等直播任务执行完成后才能执行。

通过将直播间启动过程中所有主线程任务进行筛查，发现二级插件的中业务功能较多，整体加载任务执行时间较长，为验证线上也是由于二级业务任务阻塞了首帧分发任务，我们设计了一个二级组件加载需要等待内核首帧后才能进行的实验，通过实验组与对照组数据对比，在命中实验时首帧分发耗时和起播整体耗时全部都有明显下降，整体耗时有 500ms 左右优化。

通过实验验证及本地对起播阶段业务逻辑分析，定位到直播间各业务组件及对应视图的预加载数量较多且耗时比较明显，这个功能是二级插件为充分利用直播间接口数据返回前时间，二级插件加载后会与接口请求并行提前创建业务视图，提起初始化组件及视图为接口完成后组件渲染节省时间。如果不预创建，接口数据回来后初始化业务组件也会主动创建后设置数据。但将所有预创建任务全部串行执行耗时较长，会阻塞主线程，页面一帧中执行太多任务，也会造成页面明显卡顿。

发现这个阻塞问题后，我们设计了将预创建视图任务进行拆分打散，将一起执行的大任务拆分成多个小任务，每个组件的初始化都作为一个单独任务在主线程任务队列中进行排队等待执行。避免了一个大任务耗时特别长的问题。该功能上线后，整个二级插件中的组件加载大任务耗时降低了 40%+。

5.5 内核子线程分发首帧

由于主线程消息队列中任务是排队执行的，将阻塞首帧分发事件的大任务拆分成较多小任务后，还是无法解决首帧事件开始排队时这些小任务已经在主线程任务队列中排队问题。除了降低直播业务影响，还可以通过加快内核任务分发速度，使首帧分发耗时降低。需要设计一个在不影响内核稳定性与业务逻辑情况下内核首帧事件如何避免主线程排队或快速排队后被执行的方案。

为解决上面的问题，我们推动内核，单独增加了一个子线程通知业务首帧事件能力。业务收到子线程中首帧回调后通过 Handler 的 postAtFrontOfQueue() 方法将一个新任务插到主线程任务队列最前面，这样主线程处理完当前任务后就可以马上处理我们新建的这个任务，在这个新任务中可以马上处理播放器上屏逻辑。无需等待播放内核原本的主线程消息。

主线程任务前插无法打断新任务排队时主线程中已经开始执行的任务，需要正在执行任务结束后才会被执行。为优化这个场景，内核通过子线程通知首帧后，播放器中需要记录这个状态，在一级插件及二级插件中的直播间业务任务执行开始前后，增加判断播放器中是否已经收到首帧逻辑，如果已经收到，就可以先处理上屏后再继续当前任务。

通过直播内核首帧消息在主线程任务队列前插和业务关键节点增加是否可上屏判断，就可以较快处理首帧通知，降低首帧分发对起播时长影响。

5.6 起播与完载指标平衡

直播间起播优化过程中，完载时长指标（完载时长：用户到直播间核心功能全部出现的时间，其中经历页面启动，直播间列表创建，二级插件下载、安装、加载，直播间接口数据请求，初始化直播间功能组件视图及渲染数据，核心业务组件显示等阶段）的优化也在持续进行。直播间二级插件是在使用二级插件中的功能时才会触发下载安装及加载逻辑，完载链路中也注意到了用户到页面 onCreate 这段耗时，见下图。

△页面启动耗时示意图

为优化直播间完载指标，直播团队考虑如果将插件加载与页面启动并行，那么完载耗时也会有一定的优化。直播团队继续设计了二级插件预加载方案，将二级插件加载位置提前到了用户的时候（该功能上线在 5.4、5.5 章节对应功能前）。该功能上线后试验组与对照组数据显示，实验组完载耗时较对照组确实有 300ms+ 优化。但起播耗时却出现了异常，实验组的起播耗时明显比对照组增长了 500ms+，且随版本收敛这个起播劣化还在增加。我们马上很快发现了这个异常，并通过数据分析确定了这个数据是正确的。完载的优化时如何引起起播变化的？

经过数据分析，我们发现起播受影响的主要位置还是内核首帧消息分发到主线程这个分段引起，也就是二级插件加载越早，内核首帧分发与二级组件加载时的耗时任务冲突可能性越大。确认问题原因后，我们做了 5.4、5.5 章节的功能来降低二级组件加载任务对起播影响。由于二级插件中的耗时任务完全拆分打散来缓解二级插件预下载带来的起播劣化方案复杂度较高，对直播间逻辑侵入太大，二级插件提前加载没有完全上线，完载的优化我们设计了其他方案来实现目标。

虽然不能在进入直播间时直接加载二级插件，但我们可以在进入直播间前尽量将二级插件下载下来，使用时直接加载即可，这个耗时相对下载耗时是非常小的。我们优化了插件预下载模块，在直播间外展示直播资源时触发该模块预下载插件。该模块会通过对当前设备网络、带宽、下载频次等条件综合判断，在合适的时机将匹配的二级插件进行下载，插件提前下载后对完载指标有较大优化。除了插件预下载，直播间内通过 5.4 章节直播间二级组件初始化拆分，也将全部组件初始化对主线程阻塞进行了优化，这样接口数据请求成功后可以优先处理影响完载统计的组件，其他组件可以在完载结束后再进行初始化，这个方案也对直播完载指标有明显优化。

除了以上两个优化方案，直播团队还在其他多个方向对完载指标进行了优化，同时也处理了完载时长与起播时长的指标平衡，没有因为一个指标优化而对其他指标造成劣化影响。最终实现了起播、完载指标全部达到目标。

06 收益

△2022 Android 端起播耗时走势

经过以上多个优化方案逐步迭代，目前 Android 端最新版本数据，大盘起播时间已经由 3s+ 降到 1.3s 左右；一跳带流地址时起播时长由 2.5s+ 左右降低到 1s 以内；二跳起播时长由 1s+ 降低到 700ms 以内，成功完成了预定目标。

07 展望

起播时长作为直播功能一个核心指标，还需要不断打磨和优化。除了业务架构上的优化，还有优化拉流协议、优化缓冲配置、自适应网速起播、优化 gop 配置、边缘节点加速等多个方向可以探索。百度直播团队也会持续深耕直播技术，为用户带来越来越好的直播体验。

——END——

摘要：

对于MYSQL的INNODB存储引擎的索引，大家是不陌生的，都能想到是 B+树结构，可以加速SQL查询。但对于B+树索引，它到底“长”得什么样子，它具体如何由一个个字节构成的，这些的基础知识鲜有人深究。本篇文章从MYSQL行记录开始说起，层层递进，包括数据页，B+树聚簇索引，B+树二级索引，最后在文章末尾给出MYSQL索引的建议。文章涉及较多基础知识，内容较为枯燥，因此采用较多的图片补充说明，希望能对读者有帮助。

A. 一条记录存储格式：COMPACT行记录结构

mysql是关系型数据库，每一行记录都是表结构定义的关系的显示表达。在脑中很直观地想到，记录存储时也可能按行存储。

的确，mysql是这么存储一条行记录的。但会添加一些额外信息，来补充行记录信息。

有一个概念可能大家不熟悉，是【变长字段】。mysql数据库类型中的 VARCHAR(M), VARBINARY(M), 各种TEXT，BLOB类型，这些类型的数据长度是可变的，称数据类型为可变长类型的列为变长字段。

另外，mysql会默认为行记录添加一些列（隐藏列）。上图补充这些隐藏列之后，完整行记录的结构如：

DB_ROW_ID: 唯一标识一条记录，在表中未设置主键或未有不允许为NULL的UNIQUE键时，则MYSQL新增该隐藏列作为主键。 DB_TRX_ID: 事务ID。 DB_ROLL_PTR: 回滚指针。

下面再详细的铺开，关于记录的额外信息的具体内容。

通过真实的数据库表的行数据，来强化下上面的概念。首先新增一个表，并在表中insert两条记录。

做一个简单的查询，验证数据正常写入。

分析这两行数据的存储记录。

第一行记录：

第二行记录：

应该会注意到，变长字段长度列表与 NULL值列表都是逆序存放的。原因是：这样可以使得记录中位置靠前的字段和它们对应的字段长度信息在内存中的距离更近，可能会提高高速缓存的命中率。

B. 盛放记录的盒子：数据页

为了更清楚的理解数据页结构以及下文中的索引，更换一个带主键的表。

做一个简单的查询，验证数据正常写入。

根据行记录结构中的next_recrod属性的含义，多条行记录是以单向链表的形式存储。mysql为了后续更好的查询，单向链表上的记录是按照主键顺序排列的。上述这四条记录，可以显示的画成：

假如删除其中c1=2这条数据，则单向链表变更如下。其中变化点为 c1=2 这条数据中，deleted_flag变更成0， next_record=0，但并没有从磁盘上直接清除掉，head_no也未清除。第一条记录的next_record 指向了第三条记录。

当我们查询数据时，如果数据以行记录的形式一条一条从磁盘加载到内存中，那么因为IO过多的原因，整体性能肯定较为低效。因此mysql规定，磁盘与内存交换数据的基本单位是一个页大小。这个页大小默认是16K。根据页中存储的数据类型不同，页也分成许多类型。对于存储行记录的页，称为索引页（Index Page），也称为数据页。

那么接下来我们看看，数据页的结构如何，一条条行记录如何存放在数据页中。先上个图。

从上图中，我们可以猜到，数据页总共分成7个模块，目前咱们只关心 User Records 部分，它存储的就是用户真实的行记录。但是一个数据页的空间总共是16K，不会自动增大空间，随着User Records 模块中的行记录越来越多，那么肯定有其他模块的空间就越来越小。这个模块是 Free Space，是页中尚未使用的空间。更新一下上面这个图，补充 Free Space的内容。随着User Records中行记录的增加，Free Space空间则越来越小。

在一个数据页中，除了真实的行记录之外，还有两条固定的伪记录。其中一条记录称为 infimum 【[ɪnˈfaɪməm] ，下确界】行记录，规定是数据页中记录的最小值。 infimum记录特别简单，仅包含了记录头信息(5字节) + 真实记录数据(8字节)，其中【69 6E 66 69 6D 75 6D 00】16进制转换成对应的单词，就是【infimum】。

另外一条记录称为 supremum【[sə’priməm]，上确界】行记录，规定是数据页中记录的最大值。 supremum记录同样特别简单，仅包含了记录头信息(5字节) + 真实记录数据(8字节)，其中【73 75 70 72 65 6D 75 6D】16进制转换成对应的单词，就是【supremum】。

再更新一版数据库页结构，补充上infimum 与 supremum。

既然规定了页面中的最小记录与最大记录，理所应当，上文中串联各个行记录的单向链表，则应该有一个固定的头部与固定的尾部。更新一下单链表的图。注意下infimum 与 supremum中的几个关键值。

infimum: n_owned=1，表示是某一个分组的最后一条记录，当前分组共1条记录；record_type=2； next_record=第一条真实行记录的真实值的相对位置。 supremum: n_owned=5，表示是某个分组的最后一条记录，当前分组共5条记录；record_type=3； next_record=0，表示记录是本数据页中最后一条记录。

OK，到现在数据页中完整的单链表已经形成了。思考一个问题，如何根据主键值，在数据页中的单链表如何查找到相应的数据。最直接的做法是：从 infimum记录开始，沿着单链表的顺序不断的向后查找，直到supremum结束。在这期间，找到满足条件的记录就返回，找不到则不返回。

一个数据页默认大小是16K，用于存储真实行记录的空间超过 98%以上。也就是说，一个数据页中在行记录填充满的情况下，行记录的数量是较多的（当然与行记录大小有关）。如果每次查询都从单链表的infimum记录一直到 supremum记录，肯定是无法接受的，很有必要对此现状进行优化。由此，引出了数据页中的另一个模块，Page Directory，页目录。

首先返回看下上面完整单链表中，infimum记录与 supremum记录中的两个值，n_owned。这个值分别为 n_owned=1 与 n_owned=5。

参考下n_owned的定义，它是：【页面分组之后，每个组最后一条行记录中该值等于本组内的记录数量。本组内其他记录该值都等于0。】对于上面的单链表，其它行记录的owned值都为零。也就是说，infimum单条记录作为一个组，剩余的四条行记录+supremum记录作为一个组。 mysql规定：

•
对于infimum记录所在的分组只能有1条记录，也就是它本身。

•
对于supremum记录所在的分组的记录数在1~8条之间。

•
其它的分组记录的条数范围，在4~8条之间。

将每个组中最后一条记录在页面中的地址偏移量（该记录的真实数据与数据页中第0个字节之间的距离）单独提取出来，以倒序存储到数据页中的固定模块中。这个模块，就称为：Page Directory。Page Directory中存储的地址偏移量，也称为Slot 【[slɒt]，槽】，每个Slot两字节。【可以想想为啥是两字节？】

再次更新下数据页结构图。

目前的只有四条记录，两个分组，数量太少了。我们继续往表中继续增加一些记录。

在不断的插入新行记录时，因此不同类型分组数量的约束，所以分组也会增加。这个过程如下：

•
在初始情况下，一个数据页中只会有 infimum 与 supremum 这两条记录，它们分别属于两个组。此时Page Directory 也只会有两个slot，分别代表infimum的地址偏移量与 supremum的地址偏移量。

•
之后每新增一条行记录，都会从Page Directory中找到对应的记录的主键值比待新增记录的主键值大并且差值最小的slot【slot是一个组内最大的那条记录在页面中的地址偏移量，通过slot可以快速找到对应记录的主键值】，然后把该slot对应的记录的 n_owned值加1，表示本组内新增了一条记录，直到该组中的记录数等于8个。

•
当一个组中的记录数等于8后，再插入一条记录，会将组中的记录拆分成两个组，其中一个组中是4条记录，另外一个组中是5条记录。拆分过程中，会新增一个slot，记录这个新增分组中最大的那条记录的地址偏移量。

现在来看看下，目前该数据页中的行记录的分组情况。

来演绎一个根据主键查询行记录的例子。假如想查询主键值，也就是C1=6的行记录。通过二分法查找，过程如下：

1.
设置low=0，high=4。计算中间slot的位置，(0 + 4) / 2 = 2, 通过slot 2 查询到对应的主键值等于8。因为8 > 6，所以设置high = 2， low = 0不变。

2.
重新计算中间slot的位置，（0 + 2）/ 2 = 1, 查看 slot 1对应记录的主键值为4。又因为 4 < 6, 所以设置low = 1，high 不变。

3.
此时low = 1， high = 2，所以确定主键值为6的行记录在 slot2 对应的组中。此时找到slot 2的最小一条记录【通过slot 1 的next_record找到slot 2的最小记录】，遍历slot 2中的所有记录即可。

截止目前，数据页模块中，还要三个模块是未知的。回想一下，对于一条行记录，它有记录头信息来描述这条行记录的相关信息，那么对于一个数据页，它有对应的头部来记录数据页的相关信息吗？

有的，自然是有的，而且还不少。这个模块就称为 Page Header。

Page Header的结构如下：

主要作用是标识数据页中记录了多少条记录，Free Space在页面中的地址偏移量，页目录中包含多少slot等等。

额外说下page_direction 与 page_n_direction的含义。

page_direction: 假如新插入的一条记录的主键值比上一条记录的主键值比上一条记录大，我们说这条记录的插入方向是右边，反之则是左边。用来表示最后一条记录插入方向的状态就是page_direction。

page_n_direction: 假设连续几次插入新记录的方向都是一致的，InnoDB会把沿着同一个方向插入记录的条数记下来，这个条数就用PAGE_N_DIRECTION这个状态表示。当然，如果最后一条记录的插入方向改变了的话，这个状态的值会被清零重新统计。

到此为止，仅剩下两个模块了，加油啊。

上文中的Page Header 是专门针对数据页记录的各种状态信息。但数据页仅仅是多种页类型中的一种，其它的还有例如undo日志页，溢出页，存储段信息页，存储区信息页等。因此mysql 使用了File Header 来描述各种页的通用信息。

从fil_page_prev 与 fil_page_next 两个属性可以联想到，不同页之间是有关联的，而且是以双向链表的形式。

最后一个模块，File Trailer 【 [ˈtreɪlə(r)]，挂车】。

InnoDB存储引擎会把数据存储到磁盘上，但是磁盘速度太慢，需要以页为单位把数据加载到内存中处理，如果该页中的数据在内存中被修改了，那么在修改后的某个时间需要把数据同步到磁盘中。

但是在同步了一半的时候中断电了怎么处理呢？此时就需要靠 File Trailer 模块中数据起作用。

展示下完整的数据页结构。

盗用一下网上的一个很好的数据页图。

C. 快速查询的秘籍：B+树索引

上文在介绍File Header时，我们特别说明了里面的两个数据：FIL_PAGE_PREV，指向前一个页号。FIL_PAGE_NEXT, 指向后一个页号。由此可以得出，多个数据页之间的数据结构是双链表。

上文使用的数据共有16条，为了演示这个双链表的效果，现在假设【仅仅是假设】每个页中存放不超过4条行记录。则上文的16条记录，形成的数据页双链表结构如下图【此处省略了许多非必要展示的字段】。

从上面这个链表，可以得到以下结论：

1.
双向链表的页号并不保证是连续的。

2.
下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。【在依次写入主键数据不连续的行记录时，会发生页中数据的迁移。】

从目前的双向链表结构中，想要根据主键值查找记录，也只能是从第一页开始，一页一页的依次查找。虽然在一个数据页中，可以根据 Page Directory进行快速的二分查找，但总体效率肯定不尽人意。得优化。

我们注意到，【下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值】。因此，首先进行第一步改进。维护一个目录项，目录项中记录某个页中主键的最小值以及页号，各个目录项再以单向链表的形式链接起来。这样就可以根据主键查询目录项，得到满足的条件页，再进入相应的页中查询行记录即可。

到现在看看，目录项是不是也很像行记录，只是它的列值是主键与页号。那把这些目录项维护成在一个页中看看效果。毫无违和感，浑然天成。现在看到的，就是主键索引的雏形了。

目前数据有些少了，继续补充一些数据，再画个图看看。

现在看到的，就是一个典型的INNODB的主键索引了。它包含以下特点：

1.
整个主键索引的数据结构是一棵树，具体是以B+树实现。

2.
叶子节点与非叶子节点中的行记录按照主键大小顺序排成一个单向链表，页内的记录被划分成若干组。可以利用Page Directory进行二分法快速查找到行记录。

3.
存放用户记录的数据页，根据页中用户记录的主键大小顺序排成一个双向链表。所有用户记录都存放在叶子节点上。

4.
存放目录项记录的数据页都是非叶子节点，分层不同的层级。同一层级中的页也是根据页中目录项记录的主键大小顺序，排成一个双向链表。

通常也把INNODB的B+树索引称为聚簇索引（clustered/ˈklʌstəd / index），所有的真实数据都存储在聚簇索引中。【索引即数据，数据即索引】。

通常除了主键索引之外，肯定还会建一些普通索引，称为二级索引，或者辅助索引。上面的数据，我们以上文中的数据 C2列建立一个二级索引看看。

现在来看看下，INNODB中二级索引的特点。

1.
二级索引的数据结构与聚簇索引一样，是B+树结构。

2.
二级索引的所有目录项页存储行记录的真实数据是索引列+页号。

3.
二级索引的非叶子节点存储行记录的真实数据是索引列+主键值。

因为在二级索引中查询到的是主键值，如果想要得到完整的行记录，则需要拿着主键值再到聚簇索引中再进行一次查询。这个过程称为【回表】。【回表的过程，特别要强调下每次对于二级索引来说，每次查询到一条满足二级索引字段条件的记录时，都进行一次回表判断是否满足其他条件，然后将满足所有条件的一条查询结果返回给客户端。】

再讲讲联合索引。现在以C2 与 C3两列作为联合索引，为了更好的展示联合索引的效果，先修改几条行记录。

给联合索引画个图。

总结下联合索引的特点：

联合索引的数据页中记录的排序，默认是按照定义联合索引的第一列排序的，在第一列值相等的情况下，再按照第二列排序。其它的方面均与单列的二级索引无差别。

联合索引还有一个比较特殊的使用场景：最左前缀匹配。例如有联合索引的列包含：C1，C2，C3 三列，而且顺序也是 C1，C2，C3。则查询语句：select * from page_demo where c1 = x and c2 = y and c3= z, 使用到了C1，C2，C3 列排序的结果。 select * from page_demo where c1 = x and c2 = y, 使用到了C1，C2 列排序的结果。 select * from page_demo where c1 = x and c3 = z, 仅使用到了C1 列排序的结果。

D. 索引的优缺点及建议

优点：

1.
对于等值查询，可快速定位到对于的行记录。

2.
对于范围查询，可辅助缩小扫描区间。

3.
当ORDER BY的列名与索引的列名完全一致时，可加快排序的顺序。

4.
当GROUP BY的列名与索引的列名完全一致时，可加快分组。

5.
当二级索引列中包含了 SELECT 关键字后面写明的所有列，则在查询完成二级索引之后无需进行回表操作，直接返回即可。这种情况，称为【覆盖索引】。

缺点：

1.
建立索引占用磁盘空间。

2.
对表中的数据进行增加，删除，修改操作时，都需要修改各个索引树，特别是如果新增的行记录的主键顺序不是递增的，就会产生页分裂，页回收等操作，有较大的时间成本。

3.
当二级索引列的值的不重复值的个数较少时，通过二级索引查询找到的数据量就会比较多，相应的就会产生过多的回表操作。

4.
在执行查询语句的时候，首先要生成一个执行计划。通常情况下，一个SQL在执行过程中最多使用一个二级索引，在生成执行计划时需要计算使用不同索引执行查询时所需的成本，最后选择成本最低的那个索引执行查询。因此，如果建立太多的索引，就会导致成本分析过程耗时太多，从而影响查询语句的性能。

建议：

1.
只为用于搜索，排序，分组的列创建索引。

2.
索引的列需要有辨识性，尽可能地区分出不同的记录。

3.
索引列的类型尽量小。因为数据类型越小，索引占用的存储空间就越少，在一个数据页内就可以存放更多的记录，磁盘I/O带来的性能损耗也就越小。

4.
如果需要对很长的字段进行快速查询，可考虑为列前缀建立索引。【alter table table_M add index idx_key1(column_n(10)) –> 将table_M表的 idx_key1列的前10个字符创建索引】

5.
覆盖索引，当二级索引列中包含了 SELECT 关键字后面写明的所有列，则在查询完成二级索引之后无需进行回表操作，直接返回即可。因此，编写【select *】的时候，要想想是否必要。

6.
在查询语句中，索引列不要参与条件值计算，也是把条件值计算完成之后，再和索引列对比。【否则MYSQL会认为搜索条件不能形成合适的扫描区间来减少扫描的记录数量】

前言

Kubernetes 中大量用到了证书, 比如 ca证书、以及 kubelet、apiserver、proxy、etcd等组件，还有 kubeconfig 文件。

如果证书过期，轻则无法登录 Kubernetes 集群，重则整个集群异常。

为了解决证书过期的问题，一般有以下几种方式：

大幅延长证书有效期，短则 10年，长则 100 年；
证书快过期是自动轮换，如 Rancher 的 K3s，RKE2 就采用这种方式；
增加证书过期的监控，便于提早发现证书过期问题并人工介入

本次主要介绍关于 Kubernetes 集群证书过期的监控，这里提供 3 种监控方案：

使用 Blackbox Exporter 通过 Probe 监控 Kubernetes apiserver 证书过期时间；
使用 kube-prometheus-stack 通过 apiserver 和 kubelet 组件监控获取相关证书过期时间;
使用 enix 的 x509-certificate-exporter监控集群所有node的和下的证书以及 kubeconfig 文件

方案一: Blackbox Exporter 监控 Kubernetes apiserver 证书过期时间

Blackbox Exporter 用于探测 HTTPS、HTTP、TCP、DNS、ICMP 和 grpc 等 Endpoint。在你定义 Endpoint 后，Blackbox Exporter 会生成指标，可以使用 Grafana 等工具进行可视化。Blackbox Exporter 最重要的功能之一是测量 Endpoint 的可用性。

当然, Blackbox Exporter 探测 HTTPS 后就可以获取到证书的相关信息, 就是利用这种方式实现对 Kubernetes apiserver 证书过期时间的监控.

配置步骤

调整 Blackbox Exporter 的配置, 增加 , 如下:
重启 blackbox exporter:
增加对 Kubernetes APIServer 内部端点https://kubernetes.default.svc.cluster.local/readyz的监控.
1. 如果你没有使用 Prometheus Operator, 使用的是原生的 Prometheus, 则需要修改 Prometheus 配置文件的 configmap 或 secret, 添加 scrape config, 示例如下:
2. 如果在使用 Prometheus Operator, 则可以增加如下 Probe CRD, Prometheus Operator 会自动将其转换并 merge 到 Prometheus 中.

最后, 可以增加 Prometheus 告警 Rule, 这里就直接用 Prometheus Operator 创建 PrometheusRule CRD 做示例了, 示例如下:

效果

方案二: kube-prometheus-stack 通过 apiserver 和 kubelet 组件监控证书过期时间

这里可以参考我的文章:Prometheus Operator 与 kube-prometheus 之二 – 如何监控 1.23+ kubeadm 集群, 安装完成后, 开箱即用.

开箱即用内容包括:

抓取 apiserver 和 kubelet 指标;(即 serviceMonitor)
配置证书过期时间的相关告警; (即 PrometheusRule)

这里用到的指标有:

apiserver
kubelet

监控效果

对应的 Prometheus 告警规则如下:

方案三: 使用 enix 的 x509-certificate-exporter

监控手段

该 Exporter 是通过监控集群所有node的指定目录或 path 下的证书文件以及 kubeconfig 文件来获取证书信息.

如果是使用 kubeadm 搭建的 Kubernetes 集群, 则可以监控如下包含证书的文件和 kubeconfig:

安装配置

编辑 values.yaml:

通过 Helm Chart 安装:

通过这个 Helm Chart 也会自动安装:

ServiceMonitor
PrometheusRule

其监控指标为:

监控效果

该 Exporter 还提供了一个比较花哨的 Grafana Dashboard, 如下:

Alert Rules 如下:

总结

为了监控 Kubernetes 集群的证书过期时间, 我们提供了 3 种方案, 各有优劣:

使用 Blackbox Exporter 通过 Probe 监控 Kubernetes apiserver 证书过期时间；
1. 优势: 实现简单;
2. 劣势: 只能监控 https 的证书;
使用 kube-prometheus-stack 通过 apiserver 和 kubelet 组件监控获取相关证书过期时间;
1. 优势: 开箱即用, 安装 kube-prometheus-stack 后无需额外安装其他 exporter
2. 劣势: 只能监控 apiserver 和 kubelet 的证书;
使用 enix 的 x509-certificate-exporter监控集群所有node的和下的证书以及 kubeconfig 文件
1. 优势: 可以监控所有 node, 所有 kubeconfig 文件, 以及所有 tls 格式的 secret 证书, 如果要监控 Kubernetes 集群以外的证书, 也可以如法炮制; 范围广而全;
2. 需要额外安装: x509-certificate-exporter, 对应有 1 个 Deployment 和多个 DaemonSet, 对 Kubernetes 集群的资源消耗不少.

可以根据您的实际情况灵活进行选择.

🎉🎉🎉

📚️参考文档

如何使用 Blackbox Exporter 监控 URL? – 东风微鸣技术博客 (ewhisper.cn)
Prometheus Operator 与 kube-prometheus 之二 – 如何监控 1.23+ kubeadm 集群 – 东风微鸣技术博客 (ewhisper.cn)
x509-certificate-exporter/deploy/charts/x509-certificate-exporter at master · enix/x509-certificate-exporter (github.com)

三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.

本文分享自华为云社区《CTPN+CRNN 算法端到端实现文字识别》，作者：HWCloudAI。

OCR介绍

光学字符识别（英语：Optical Character Recognition，OCR）是指对文本资料的图像文件进行分析识别处理，获取文字及版面信息的过程。发展时间较长，使用很普遍。OCR作为计算机视觉中较早使用深度学习技术的领域，有很多优秀的模型出现。普遍的深度学习下的OCR技术将文字识别过程分为：文本区域检测以及字符识别。

文本区域检测——CTPN模型

文字区域检测：将图片中出现的文本位置检测出来，可能存在不同语言，不同文字大小，不同角度倾斜，不同程度遮挡等情况。CTPN网络结合了CNN与LSTM深度网络，通过固定宽度的anchor提取proposal，能有效的检测出复杂场景的横向分布的文字区域，不定长度文本识别效果较好，是目前使用广泛的文字检测算法。

字符序列检测——CRNN模型

字符识别算法：将文本区域的字符识别出来。通过深度神经网络对目标区域进行特征提取，然后对固定特征进行提取和比对，得出识别结果。采用文本识别网络CRNN+CTC。CRNN全称为卷积循环神经网络，将特征提取，序列建模以及转录整合到统一的模型框架中。主要用于端到端地对不定长的文本序列进行识别，不用先对单个文字进行切割，而是将文本识别转化为时序依赖的序列学习问题，就是基于图像的序列识别。如下图，CRNN网络分为：卷积层、循环层和转录层三部分，CTC为无词典的转录方式，不会被局限在预定义词汇范围中。

完整的端到端OCR流程

了解了文本区域检测以及字符识别后，下面详细讲解完整的端到端OCR流程：

（1）准备一张含有文字的原图；

（2）对原图进行文字位置的检测，检测结果可能是水平矩形框，也可能是倾斜矩形框；

（3）从原图中把文字框对应的图片切下来，并旋转正，得到水平的文字块切片图；

（4）对每个文字块切片图依次进行字符识别，每个切片图的识别结果汇总起来，就得到原图的文字识别结果。

因此完整的端到端OCR流程是：输入原图 -> 文字检测 -> 文字块切片 -> 字符识别 -> 识别结果汇总。

理论部分到此告一段落，下面开始在ModelArts中体验实战项目开发！

注意事项：

本案例使用框架: TensorFlow-1.8
本案例使用硬件规格: 8 vCPU + 64 GiB + 1 x Tesla V100-PCIE-32GB
进入运行环境方法：点此链接进入AI Gallery，Run in ModelArts按钮进入ModelArts运行环境，如需使用GPU,您可以在ModelArts JupyterLab运行界面右边的工作区进行切换
运行代码方法: 本页面顶部菜单栏的三角形运行按钮或按Ctrl+Enter键运行每个方块中的代码
JupyterLab的详细用法: 请参考《ModelAtrs JupyterLab使用指导》
碰到问题的解决办法: 请参考《ModelAtrs JupyterLab常见问题解决办法》

1. 下载代码和模型

本案例中已经将CTPN和CRNN的代码模型都整合到一起

2. CTPN相关模块导入

3. CRNN相关模块安装与导入

4. 加载CTPN模型

CTPN为了更好检测出文本区域，anchor为宽度固定为16 ，高度为[11, 16, 23, 33, 48, 68, 97, 139, 198, 283] 的文本框，共10个anchor。

这样的设计是为了更好检测出文字区域的水平位置，在文字检测中，检测文字的水平范围比较垂直范围要更困难。将anchor的宽度固定，只检测10个高度的anchor，尤其在面对多个分离的文本的情况时，能够更好检测文字的范围。

不同的anchor得到了边界框，利用nms（非极大值抑制）进行边界框回归计算，最终得到细粒度的文本区域。

5. 加载CRNN模型

下图给出CRNN的结构参考：

6. 定义文字位置检测函数

7. 定义文字块切片函数

8. 定义CRNN字符识别函数

9. 查看原图

10. 开始图片测试

关注，第一时间了解华为云新鲜技术~

本文分享自华为云社区《GaussDB(DWS)字符串、二进制、十六进制互转》，作者：你是猴子请来的救兵吗。

概述

现网中遇到很多小伙伴不清楚字符串与进制之间的转换方法，其实在GaussDB(DWS)中，进制转换是非常方便的。这次就来对不同的场景一一进行解析，整理出来供大家翻阅参考。

字符串&二进制互转

二进制&十六进制互转

字符串&十六进制互转

注意事项：

1，hex/unhex是820版本新增的一组十六进制的编码/解码函数，低于820版本需使用encode/decode函数替代。

hex行为与mysql数据库保持一致，输出全大写的十六进制字符串；encode输出的是全小写的十六进制字符串；对大小写有要求的小伙伴可以选择满足要求的函数，但实际在解析时是没有影响的。

2，在将二进制转为字符串的时候使用convert_from，第二个参数为源数据编码。

需要注意的是，一定保证源数据编码正确，否则就会产生非预期的结果，甚至报错。

像这样

这样

知识小结

转换函数encode

转换函数convert_from

转换函数hex/unhex，需820或以上版本

关注，第一时间了解华为云新鲜技术~

作者：乔中沛（伊灵）

背景

随着万物互联场景的逐渐普及，边缘设备的算力也不断增强，如何借助云计算的优势满足复杂多样化的边缘应用场景，让云原生技术延伸到端和边缘成为了新的技术挑战，“云边协同”正在逐渐成为新的技术焦点。本文将围绕 CNCF 的两大开源项目 KubeVela 和 OpenYurt，以一个实际的 Helm 应用交付的场景，为大家介绍云边协同的解决方案。

OpenYurt 专注于以无侵入的方式将 Kubernetes 扩展到边缘计算领域。OpenYurt 依托原生 Kubernetes 的容器编排、调度能力，将边缘算力纳入到 Kubernetes 基础设施中统一管理，提供了诸如边缘自治、高效运维通道、边缘单化管理、边缘流量拓扑、安全容器、边缘 Serverless/FaaS、异构资源支持等能力。简而言之，OpenYurt 以 Kubernetes 原生的方式为云边协同构建了统一的基础设施。

KubeVela 孵化于 OAM 模型，专注于帮助企业构建统一的应用交付和管理能力，为业务开发者屏蔽底层基础设施复杂度，提供灵活的扩展能力，并提供开箱即用的微服务容器管理、云资源管理、版本化和灰度发布、扩缩容、可观测性、资源依赖编排和数据传递、多集群、CI 对接、GitOps 等特性。最大化的提升开发者自助式应用管理的研发效能，提升也满足平台长期演进的扩展性诉求。

OpenYurt 与 KubeVela 结合能解决什么问题？

如上所述，OpenYurt 满足了边缘节点的接入，让用户可以通过操作原生 Kubernetes 的方式管理边缘节点。边缘节点通常用来表示距离用户更近的计算资源，比如某个就近机房中的虚拟机或物理服务器等，通过 OpenYurt 加入后，这些边缘节点会转化为 Kubernetes 中可以使用的节点（Node）。OpenYurt 用节点池（NodePool）来描述同一地域的一组边缘节点。在满足了基本的资源管理后，针对应用如何编排部署到一个集群中的不同节点池，我们通常会有如下核心需求：

1. 统一配置： 如果对每一份要下发的资源做手动修改，需要很多人工介入，非常容易出错和遗漏。我们需要统一的方式来做参数配置，不仅可以方便地做批量管理操作，还可以对接安全和审计，满足企业风险控制与合规需求。

2. 差异部署： 部署到不同节点池的工作负载有大部分属性相同，然而总有个性化的配置差异。关键在于如何设置和节点选择相关的参数，例如可以指示 Kubernetes 调度器将工作负载调度到不同的节点池。

3. 可扩展性： 云原生生态繁荣，无论是工作负载种类还是不同的运维功能都在不断增长，为了更灵活地满足业务需求，我们需要整体的应用架构是可扩展的，能够充分享受云原生生态的红利。

而 KubeVela 在应用层与 OpenYurt 可以很好的互补，满足上述三个核心需求。接下来，我们结合实际的操作流程来展示这些功能点。

将应用部署到边缘

我们将以Ingress控制器为例，展示如何使用KubeVela 将应用程序部署到边缘。在这种情况下，我们希望将 Nginx Ingress 控制器部署到多个节点池中，以实现通过边缘 Ingress 访问指定节点池提供的服务，某个 Ingress 仅能由所在节点池的 Ingress 控制器处理。

示意图的集群中有两个节点池：北京和上海，他们之间的网络不互通。我们希望再其中每个节点池都部署一个 Nginx Ingress Controller，并作为各自节点池的网络流量入口。一个靠近北京的客户端，可以通过访问北京节点池的 Ingress Controller，访问北京节点池内提供的服务，且不会访问到上海节点池提供的服务。

Demo 的基础环境

我们将使用 Kubernetes 集群模拟边缘场景。群集有 3 个节点，它们的角色分别是：

节点 1：master 节点，云端节点
节点 2：worker 节点，边缘节点，在节点池中
节点 3：worker 节点，边缘节点，在节点池中

准备工作

1. 安装 YurtAppManager

YurtAppManager 是 OpenYurt 的核心组件。它提供节点池 CRD 和控制器。OpenYurt 中还有其他组件，但在本教程中我们只需要 YurtAppManager.

2.安装KubeVela，启用 FluxCD 插件。

安装 Vela 命令行工具，并在集群中安装 KubeVela。

在本案例中，为了复用社区提供的成熟的 Helm Chart，我们用 Helm 类型的组件来安装 Nginx Ingress Controller。在微内核设计的 KubeVela 中，Helm 类型的组件是由 FluxCD 插件提供的，下面启用 FluxCD 插件 [ 1] 。

3. 准备节点池

创建两个节点池：北京节点池和上海节点池。在实际的边缘场景中，以地域划分节点池是常见的模式。不同分组的节点间往往存在网络不互通、资源不共享、资源异构、应用独立等明显的隔离属性。这也是节点池概念的由来。在 OpenYurt 中，通过节点池、服务拓扑等功能帮助用户处理上述问题。今天的例子中我们将使用节点池来描述和管理节点。

将边缘节点加入到各自的节点池，边缘节点的加入方式可以参考 OpenYurt 节点加入的方式。

预期输出

批量部署边缘应用

在我们深入细节之前，让我们看看 KubeVela 是如何描述部署到边缘的应用的。通过下面这个应用，我们可以将 Nginx Ingress Controller 部署多份到各自的边缘节点池。使用同一个应用来统一配置 Nginx Ingress 可以消除重复，降低管理负担，也方便后续对集群内的组件统一进行发布运维等常见操作。

一个 KubeVela Application 有 3 个部分：

一个类型组件。它描述了我们想要安装到集群的 Helm 包版本。此外，我们给这个组件附加了一个运维特征（trait）。我们稍后将展示这个运维特征的具体情况，现在你可以将其视为一个包含不同节点池的属性的补丁。
一个（组件分裂）策略。它描述了如何将组件复制到不同的节点池。该字段用于选择需要复制的组件。它的字段将把一个组件转换为具有不同 key 的两个组件。（“beijing”和“shanghai”）

3. 工作流步骤。它描述了如何部署应用程序。它指定策略执行复制工作的策略。

注意：

如果你希望此应用程序正常工作，请先在集群下发在下文介绍的特性。

是一个 KubeVela 内置的工作流程步骤。它还可以在多集群场景 [2 ] 中与、策略一起使用。

现在，我们可以将应用下发到集群。

检查应用状态和 KubeVela 创建的资源。

预期输出

Vela CLI 不仅可以站在较高层次统一汇集展示应用健康状态，当需要的时候，Vela CLI 也可以帮助你穿透应用，直达底层工作负载，并提供丰富的观测和 Debug 能力，例如，你可以通过把打印应用的日志；可以通过把部署应用的端口转发到本地；可以通过命令，深入到边缘的容器中执行 Shell 命令排查问题。

如果你想更直观地了解应用去情况，KubeVela 官方还提供了 Web 控制台插件 VelaUX。启用 VelaUX 插件 [3 ] ，你可以查看更详细的资源拓扑。

访问 VelaUX 的资源拓扑页面。

正如你所看到的，KubeVela 创建了两个资源，把 Nginx Ingress Controller 的 Helm Chart 交付到两个节点池。资源被上述 FluxCD 插件处理并在集群两个节点池中分别安装了 Nginx Ingress。通过以下命令，检查是否在北京节点池中创建了 Ingress Controller 的 Pod，上海节点池同理。

差异化部署

KubeVela 应用交付过程中如何实现了同一个组件的差异化部署？让我们继续深入了解支撑应用的 Trait（运维特征）和 Policy（应用策略）。上文提到我们在工作流中使用了 KubeVela 内置的组件分裂（replication） Policy，给 ingress-nginx 组件附加了一个自定义的。

组件分裂 Policy 将组件拆为两个组件，带有不同的。
Trait 使用不同的，将带有不同配置值的 Helm Chart 交付到集群中。让两个 Nginx Ingress Controller 运行在不同的节点池，监听具有不同 ingressClass 的 Ingress 资源。具体的方式是 Patch 了 Helm Chart 的 Values 配置，修改了和节点选择、亲和性以及 ingressClass 相关的字段。
在 Patch 不同字段时，使用了不同的 Patch 策略 [4 ] （PatchStrategy），例如使用策略能够覆盖原本的值，使用策略则会和原本的值合并。

让更多类型的应用走向边缘

可以看到，为了将 Nginx Ingress 部署到不同节点池，我们仅自定义了一个四十余行的 Trait 并充分利用了 KubeVela 内置的能力。在云原生生态愈加繁荣和云边协同的趋势下，更多的应用都可能走向边缘部署。当新场景中需要一个新的应用部署在边缘节点池时，也无需烦恼，因为在 KubeVela 的帮助下，仿照该模式扩展出一个新的边缘应用部署 Trait 也很容易，无需编写代码。

例如，我们希望将 K8s 社区近期的演进热点 Gateway API [5 ] 的实现也部署到边缘，通过 Gateway API 增强边缘节点池暴露服务的表达能力、扩展性，在边缘节点使用基于角色的网络 API 等。对于这种场景，我们也可以基于上述扩展方式轻松完成部署任务，只需要定义如下的一个新 Trait。

这个 Trait 和前文提到的部署 Nginx Ingress 使用的 Trait 非常相似，其中，我们也同样对 Nginx Gateway Chart 的 Values 做了一些相似的 Patch，包括节点选择、亲和性、资源名称。和前文 Trait 的区别是该 Trait 指定了 gatewayClass 而非 IngressClass。该案例的 Trait 和应用文件详见 GitHub 仓库 [6 ] 。通过自定义这样一个 Trait，我们就给集群扩展了部署一种新应用到边缘的能力。

如果我们无法预知未来边缘计算的发展带来的更多应用部署需求，至少我们可以通过这种更容易扩展的方式不断适应新的场景。

KubeVela 如何解决了边缘部署难题

回顾 KubeVela 是如何解决文章开始提出的关键问题的。

1. 统一配置： 我们使用一个组件来描述要部署的 ingress-nginx Helm Chart 的通用的属性例如 Helm 仓库、Chart 名称、版本等统一配置。

2. 属性差异： KubeVela 使用了一个用户自定义的运维特征定义，它描述下发到不同的节点池的 Helm 配置差异。该运维特征可以重复用于部署相同的 Helm Chart。

3. 可扩展性： KubeVela 可以为常见的工作负载（如 Deployment/StatefulSet）或其他打包方式（如 Helm/Kustomize/…）以可编程的方式进行扩展，只需若干行的代码，即可将一种新应用推向边缘场景。

这些得益于 KubeVela 在应用交付和管理领域提供的强大功能，KubeVela 除了能在单个集群内部解决应用的定义、交付、运维和可观测问题，还原生支持了多集群模式的应用发布和管理。目前适合边缘计算场景的 Kubernetes 部署模式并无定式，无论单集群+边缘节点池的架构，还是多边缘集群架构，KubeVela 都能胜任其中的应用管理任务。

在 OpenYurt 和 KubeVela 的配合下，云边应用以统一方式部署，共享相同的抽象、运维、可观测能力，避免了在不同场景中割裂的体验。并且云端应用和边端应用都得以使用 KubeVela 以插件形式不断集成的云原生生态的优秀实践。未来 KubeVela 社区还将不断丰富开箱即用的系统插件，持续交付更好用、更易用的应用交付和管理能力。

如果想了解更多应用部署、管理的能力，可以阅读 KubeVela 官方文档 [7 ] ，想要了解 KubeVela 社区的最新动态，欢迎来到 KubeVela 社区 [8 ] （钉钉群）参与讨论！若你对 OpenYurt 感兴趣，也欢迎来到 OpenYurt 社区（钉钉群）参与讨论。

您也可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节：

项目代码库：https://github.com/kubevela/kubevela 欢迎 Star/Watch/Fork！
项目官方主页与文档：kubevela.io ，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢迎开发者进行翻译。
项目钉钉群：；Slack：CNCF #kubevela Channel
加入微信群：请先添加以下 maintainer 微信号，表明进入 KubeVela 用户群：

戳此处 ：查看 KubeVela 项目官网！！

相关链接

[1] FluxCD 插件

https://kubevela.net/zh/docs/reference/addons/fluxcd

[2] 多集群场景

https://kubevela.net/docs/case-studies/multi-cluster

[3] 启用 VelaUX 插件

https://kubevela.net/zh/docs/reference/addons/velaux

[4] Patch 策略

https://kubevela.net/zh/docs/platform-engineers/traits/patch-trait#patch-strategy

[5] Gateway API

https://gateway-api.sigs.k8s.io/

[6] GitHub 仓库

https://github.com/chivalryq/yurt-vela-example/tree/main/gateway-nginx

[7] KubeVela 官方文档

https://kubevela.net/

[8] KubeVela 社区

https://github.com/kubevela/community

一、0xcc开篇

2020年3月，得物技术团队在三个月的时间内完成了整个交易体系的重构，交付了五彩石项目，业务系统也进入了微服务时代。系统服务拆分之后，虽然每个服务都会有不同的团队各司其职，但服务之间的依赖也变得复杂，对服务治理等相关的基础建设要求也更高。

对服务进行监控是服务治理、稳定性建设中的一个重要的环节，它能帮助提早发现问题，预估系统水位，以及对故障进行分析等等。从 2019 年末到现在，得物的应用服务监控系统经历了三大演进阶段，如今，整个得物的应用微服务监控体系已经全面融入云原生可观测性技术 OpenTelemetry。

回顾过去十年间，应用服务监控行业的竞争也很激烈，相关产品如雨后春笋般涌现，如推特在 2012 年开源的 Zipkin，韩国最大的搜索引擎和门户网站 Naver 开源的 Pinpoint，近几年 Uber 公司开源的 Jaeger，以及我们国内吴晟开源的 SkyWalking。

有人说，这些其实都归功于 Google 在 2010 年基于其内部大规模分布式链路追踪系统 Dapper 实践而发表的论文，它的设计理念是一切分布式调用链追踪系统的始祖，但其实早在二十年前（2002年），当年世界上最大的电商平台 eBay 就已拥有了调用链追踪系统 CAL(Centralized Application Logging)。2011 年，原eBay的中国研发中心的资深架构师吴其敏跳槽至大众点评，并且深入吸收消化了 CAL 的设计思想，主导研发并开源了CAT(Centralized Application Tracking）。

CAT 作为国人主导的开源系统，其本地化工作也是做得非常到位，而凭借着架构简单，开箱即用的特点，CAT 也是我们得物使用的第一个应用监控系统。

二、 0x01 第一阶段

从0～1基于CAT的实时应用监控

在得物五彩石项目交付之前，系统仅有基础设施层面的监控，CAT 的引入，很好地弥补了应用监控盲区。它支持提供各个维度的性能监控报表，健康状况检测，异常统计，对故障问题排查起到了积极推动的作用，同时也提供简单的实时告警的能力。

CAT 拥有指标分钟级别的聚合统计的能力，从 UI 上不难看出，它拥有丰富的报表统计能力和问题排障能力。

但随着公司业务规模逐步扩大，微服务粒度也不可避免地变小，我们发现，CAT 已经逐步无法满足我们的使用场景了：

无法直观呈现全链路视图：

问题排障与日常性能分析的场景也越来越复杂，对于一个核心场景，其内部的调用链路通常复杂多变，站在流量角度上看，需要完整地知道它的来源，上下游链路，异步调用等等，这对于 CAT 来说可能略显超纲。

缺少图表定制化能力：

CAT 虽供多维度报表分析，但定制化能力非常有限，在当时，业内的图表组件定制化解决方案逐步向 Grafana + Prometheus 靠拢，但若使用 CAT，则无法享受强大的图表绘制能力。与此同时，随着云原生社区可观测性项目 OpenTracing 的崛起，大约不到半年时间我们逐步下线了 CAT，向 OpenTracing 生态演进。

三、 0x02 第二阶段

持续创造基于OpenTracing全链路采样监控

OpenTracing 为全链路追踪 Trace 定制了完整的一套协议标准，本身并不提供实现细节。在 OpenTracing 协议中，Trace 被认为是 Span 的有向无环图（DAG）。官方也例举了以下 8 个 Span 的因果关系和他们组成的单 Trace示例图：

在当时， OpenTracing 相关的开源社区也是异常活跃，它使用 Jaeger 来解决数据的收集，调用链则使用了甘特图展示：

在 OpenTracing 生态中，我们对链路的采样使用头部采样策略，对于指标 Metrics，OpenTracing 并没有制定它的规范，但在 Google SRE Book 里，关于 Monitoring Distributed System 章节中提到了四类黄金指标：

吞吐量：如每秒请求数，通常的实现方式是，设定一个计数器，每完成一次请求将自增。通过计算时间窗口内的变化率来计算出每秒的吞吐量。

延迟：处理请求的耗时。

错误率/错误数：如 HTTP 500 错误。当然，有些即便是 HTTP 200 状态也需要根据特定业务逻辑来区分当前请求是否属于“错误”请求。

饱和度：类似服务器硬件资源如CPU,内存,网络的使用率等等。

所以，我们决定使用 Micrometer 库来对各个组件进行吞吐量，延迟和错误率的埋点，从而对 DB 类，RPC类的组件做性能监控。因此也可以说，我们第二阶段的监控是以指标监控为主，调用链监控为辅的应用性能监控。

3.1 使用 Endpoint 贯穿指标埋点帮助性能分析

在指标埋点过程中，我们在所有的指标中引入了“流量入口（Endpoint）”标签。这个标签的引入，实现了根据不同流量入口来区分关联 DB，缓存，消息队列，远程调用类的行为。通过流量入口，贯穿了一个实例的所有组件指标，基本满足了以下场景的监控：

RPC 调用排障，调用方除了拥有下游接口信息，也可溯源自身触发该调用的接口。

接口高耗时分析，根据指标，可还原出单位时间窗口的耗时分解图快速查看耗时组件。

3.2 关于选型的疑问

你可能会问，链路监控领域在业内有现成的 APM 产品，比如 Zipkin, Pinpoint, SkyWalking 等，为什么当时会选择 OpenTracing + Prometheus 自行埋点？主要有两大因素：

第一，在当时，CAT 无法满足全链路监控和一些定制化的报表分析，而得物交易链路五彩石项目交付也趋于尾声，贸然去集成外部一款庞大的 APM 产品在没有充分的验证下，会给服务带来稳定性风险，在极其有限的时间周期内不是个理智的选择。

第二，监控组件是随着统一的基础框架来发布，同时，由另一团队牵头开发的全链路影子库路由组件借助了 OpenTracing 随行数据透传机制，且与监控组件是强耦合关系，而基础框架将统筹监控，压测和其他模块，借助Spring Boot Starter 机制，一定程度上做到了功能的开箱即用，无缝集成。而使用字节码增强方式的 Pinpoint, SkyWalking，无法很好地做到与基础框架集成，若并行开发，也会多出基础框架与 Java Agent 两边的管理和维护成本，减缓迭代速度。

在之后将近两年的时间里，应用服务监控覆盖了得物技术部使用的将近 70% 的组件，为得物App在 2021 年实现全年 99.97% 的 SLA 提供了强有力的支持。现在看来，基于 OpenTracing + Prometheus 生态，很好地解决了分布式系统的调用链监控，借助 Grafana 图表工具，做到了灵活的指标监控，融合基础框架，让业务方开箱即用…然而，我们说第二阶段是基于 OpenTracing 全链路采样监控，随着业务的高速发展，这套架构的不足点也逐渐显露出来。

3.3 架构特点

体验层面
- 指标：覆盖面广，维度细，能清晰地根据各模块各维度来统计分析，基本做到了监控灵活的图表配置需求。但不可否认它是一种时序聚合数据，无法细化为个体。假如在某个时间点发生过几次高耗时操作，当吞吐量达到一定时，平均耗时指标曲线仍然趋于平稳，没有明显的突出点，导致问题发现能力降低。

- 链路：1%的采样率使得业务服务基本不会因调用链发送量大而导致性能问题，但同时也往往无法从错误，高耗时的场景中找到正好采样的链路。期间，我们曾经考虑将头部采样策略改为尾部采样，但面临着非常高昂的 SDK 改造成本和复杂调用情况下（如异步）采样策略的回溯，且无法保证发生每个高耗时，错误操作时能还原整个完整的调用链路。‍
- 集成方式：业务和基础框架均采用 Maven 来构建项目，使用 Spring Boot Starter “all in one”开箱即用方式集成，极大降低了集成成本的同时，也给依赖冲突问题埋下了隐患。‍
项目迭代层面

迭代周期分化矛盾，与基础框架的集成是当时快速推广落地全链路监控的不二选择，通过这种方式，Java 服务的接入率曾一度接近100%，但在业务高速发展的背景下，基础框架的迭代速度已经远远跟不上业务迭代速度了，这也间接制约了整个监控系统的迭代。

数据治理层面

数据治理成本逐步偏高，由于基础框架和业务系统的迭代节奏天然的不一致，且每个业务系统也有自身的迭代节奏，放眼全网后端服务上看，基础框架版本参差不齐。

尽管监控系统在每一次迭代时都会尽可能保证最大的向后兼容，但将近两年的迭代周期里，不同版本造成的数据差异也极大制约了监控门户系统天眼的迭代，开发人员长时间奔波于数据上的妥协，在很多功能的实现上曲线救国。

稳定性层面

相关预案依托于 Spring 框架 Bean 的自动装配逻辑，业务方理解成本低，便于变更，但缺少细粒度的预案，比如运行时期间特定逻辑降级等等。

2021 年下半年开始，为了充分平衡以上的收益与风险，我们决定将监控采集端与基础框架解耦，独立迭代。在此之前，在 CNCF（云原生计算基金会）的推动下，OpenTracing 也与 OpenCensus 合并成为了一个新项目 OpenTelemetry。

四、 0x03 第三阶段

向前一步基于OpenTelemetry全链路应用性能监控

OpenTelemetry 的定位在于可观测性领域中对遥测数据采集和语义规范的统一，有 CNCF (云原生计算基金会)的加持，近两年里随着越来越多的人关注和参与，整个体系也越发成熟稳定。

其实，我们在2020年底就已开始关注 OpenTelemetry 项目，只不过当时该项目仍处于萌芽阶段， Trace, Metrics API 还在 Alpha 阶段，有很多不稳定因素，考虑到需尽快投入生产使用，笔者曾在 2021 年中到年末期间也或多或少参与了 OpenTelemetry 社区相关 issue 的讨论，遥测模块的开发，底层数据协议的一致和一些 BUG 的修复。在这半年期间，相关 API 和 SDK 随着越来越多的人参与也逐步趋于稳定。

OpenTelemetry架构（图源自 opentelemetry.io）

4.1 迈入 Trace2.0 时代

OpenTelemetry 的定位致力于将可观测性三大要素 Metrics,Trace,Log 进行统一，在遥测 API 制定上，提供了统一的上下文以便 SDK 实现层去关联。如 Metrics 与 Trace 的关联，笔者认为体现在 OpenTelemetry 在 Metrics 的实现上包含了对 OpenMetrics 标准协议的支持，其中 Exemplar 格式的数据打通了 Trace 与 Metrics 的桥梁：

OpenMetrics 是建立在 Prometheus 格式之上的规范，做了更细粒度的调整，且基本向后兼容 Prometheus 格式。

在这之前，Metrics 指标类型的数据无法精确关联到具体某个或某些 Trace 链路，只能根据时间戳粗略关联特定范围内的链路。这个方案的缺陷源自指标采集器 vmagent 每隔 10s~30s 的 Pull 模式中，指标的时间戳取决于采集时刻，与 Trace 调用时间并不匹配。

Exemplar 数据在直方图度量格式末尾会追加当前上下文中的 Trace ID,Span ID 信息，如下：

为了采集 Exemplar 格式指标，同时又需防止分桶标签“le”产生的高基数问题，我们二次开发了指标采集 vmagent，额外过滤携带 Exemplar 数据的指标，并将这类数据异步批量发送到了 Kafka，经过 Flink 消费后落入 Clickhouse 后，由天眼监控门户系统提供查询接口和UI。

分位线统计与Exemplar 数据关联UI示意图

在数据上报层，OpenTelemetry Java SDK 使用了比 JDK 原生的阻塞队列性能更好的 Mpsc (多生产单消费）队列，它使用大量的 long 类型字段来做内存区域填充，用空间换时间解决了伪共享问题，减少了并发情况下的写竞争来提高性能。

在流量高峰时期，链路数据的发送队列这一块的性能从火焰图上看 CPU 占比平均小于2%，日常服务CPU整体水位与0采样相比几乎没有明显差距，因此我们经过多方面压测对比后，决定在生产环境客户端侧开放链路数据的全量上报，实现了在得物技术史上的全链路 100% 采样，终结了一直以来因为低采样率导致问题排查困难的问题，至此，在第三阶段，得物的全链路追踪技术正式迈入 Trace2.0 时代。

得益于 OpenTelemetry 整体的可插拔式 API 设计，我们二次开发了 OpenTelemetry Java Instrumentation 项目 Shadower Java，扩展了诸多功能特性：

4.2 引入控制平面管理客户端采集行

使用控制平面，通过客户端监听机制来确保配置项的下发动作，包括：

实时动态采样控制
诊断工具 Arthas 行为控制
实时全局降级预案
遥测组件运行时开关
实时 RPC 组件出入参收集开关
实时高基数指标标签的降级控制
按探针版本的预案管理
基于授权数的灰度接入策略。

… …

控制平面的引入，弥补了无降级预案的空白，也提供了更加灵活的配置，支持了不同流量场景下快速变更数据采集方案：

4.3 独立的启动模块

为了解决业务方因集成基础框架而长期面临的依赖冲突问题，以及多版本共存引起的数据格式分散与兼容问题，我们自研了无极探针工具箱 Promise, 它是个通用的 javaagent launcher, 结合远端存储，支持可配置化任意 javaagent 的下载，更新，安装和启动：

4.4 基于 Otel API 的扩展

4.4.1 丰富的组件度量

在第二阶段 OpenTracing 时期，我们使用 Endpoint 贯穿了多个组件的指标埋点，这个优秀的特性也延续至第三阶段，我们基于底层 Prometheus SDK 设计了一套完善的指标埋点 SDK，并且借助字节码插桩的便捷，优化并丰富了更多了组件库。（在此阶段，OpenTelemetry SDK 主版本是 1.3.x ，相关 Metrics SDK 还处于Alpha 阶段）

Otel 的 Java Instrumnetation 主要使用 WeakConcurrentMap 来做异步链路上下文数据传递和同线程上下文关联的容器，由于 Otel 对许多流行组件库做了增强，因此 WeakConcurrentMap 的使用频率也是非常高的，针对这个对象的 size 做监控，有助于排查因探针导致的内存泄露问题，且它的增长率一旦达到我们设定的阈值便会告警，提早进行人工干预，执行相关预案，防止线上故障发生。

部分自监控面板

4.4.2 扩展链路透传协

引入RPC ID

为了更好地关联上下游应用，让每个流量都有“身份”，我们扩展了TextMapPropagator 接口，让每个流量在链路上都知道请求的来源，这对跨区域，环境调用排障场景起到关键性作用。

此外，对于跨端场景，我们参考了阿里鹰眼调用链RPCID模型，增加了RpcID字段，这个字段在每次发生跨端调用时末尾数值会自增，而对于下游应用，字段本身的层级自增：

该字段拥有以下作用：

支持提供精简化的调用链路视图，查询臃肿链路（如那些涉及缓存，DB调用大于 2000 Span的链路）时只提供 RPC 调用节点和调用层次关系。

链路保真，客户端链路数据上报队列并不是个无界限队列，当客户端自身调用频繁时，若上报队列堆积达到阈值即会丢弃，这会造成整个链路的不完整，当然这是预期内的现象，但若没有RpcID字段，链路视图将无法关联丢失的节点，从而导致整个链路层级混乱失真。

自定义 Trace ID

为了实现链路详情页高效的检索效率，我们扩展 TraceID 生成逻辑，ID的前8位使用实例IP，中8位使用当前时间戳，后16位采用随机数生成。

这样的好处有两点：

通过 TraceID 反向解析时间戳，锁定时间范围，有助于提高存储库 Clickhouse 的检索效率，此外也能帮助决定当前的 Trace 应该查询热库还是冷库。

绑定实例 IP，有助于关联当前 Trace 流量入口所属的实例，在某些极端场景，当链路上的节点检索不到时，也能通过实例和时间两个要素来做溯源。

异步调用识别

业务系统为了提高服务吞吐量，充分运用硬件资源，异步调用场景可谓无处不在。我们基于Otel实现的异步链路上下文传递的基础上，额外扩充了”async_flag”字段来标识当前节点相对于父节点的调用关系，从而在展示层上能迅速找出发生异步调用的场景

4.4.3 更清晰的调用链结构

在 Otel 支持的部分组件中，有些操作不涉及到网络调用，或者具有非常频繁的操作，如 MVC 过程，数据库连接获取等，通常来说这类节点在链路详情主视图中的意义不大，因此我们对这类节点的产生逻辑进行了优化调整，使得整个链路主体结构聚焦于“跨端”，同时，对部分核心组件关键内部方法细节做了增强，以“事件”的形式挂载于它们的父节点上，便于更细粒度的排查：

RPC调用关键内部事件

DB 调用连接获取事件

4.4.4 profiling 的支持

1）线程栈分析的集成。通过集成 Arthas 这类工具，可以很方便地查看某个实例线程的实时堆栈信息，同时对采样间隔做控制，避免频繁抓取影响业务自身性能。

2）通过集成 pyroscope，打通高延迟性能排查最后一公里。Pyroscope 对 async profiler 做了二次开发，同时也支持 Otel 去集成，但截至目前，官方并没有实现完整的 Profiling 行为的生命周期，而 Profiling 行为一定程度上会影响性能，于是我们对官方 Pyroscope 的生命周期做了扩展，实现“停止”行为的同时，采用时间轮算法来检测特定操作的耗时，当达到期望的阈值将触发开启 profiling, 待操作结束或超过最大阈值则停止。

关于性能诊断相关的运用，请期待后续诊断专题。

五、 0xff 结语

纵观得物在应用监控采集领域的三大里程碑迭代，第一阶段的 CAT 则是 0~1 的过程，它提供了应用服务对自身观测的途径，让业务方第一次真实地了解了服务运行状况，而第二阶段开始，随着业务发展的飞速提升，业务方对监控系统的要求就不仅只是从无到有了，而是要精细，准确。

因此，快速迭代的背景下，功能与架构演进层面的矛盾，加上外部云原生大背景下可观测领域的发展因素，促使我们进行了基于 OpenTelemetry 体系的第三阶段的演进。功能，产品层面均取得了优异的结果。如今，我们即将进行下一阶段的演进，深度结合调用链与相关诊断工具，以第三阶段为基础，让得物全链路追踪技术正式迈入性能分析诊断时代。

六、关于我们

得物监控团队提供一站式的可观测性平台，负责链路追踪、时序数据库、日志系统，包括自定义大盘、应用大盘、业务监控、智能告警、AIOPS等排障分析。

参考文章：

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf

大众点评开源分布式监控平台 CAT 深度剖析-阿里云开发者社区

https://developer.aliyun.com/article/

趣谈“分布式链路追踪“组件发展史https://xie.infoq.cn/article/8e06e8d9e43d1768e021225cb
Jaeger Sampling https://www.jaegertracing.io/docs/1.39/sampling/
A brief history of OpenTelemetry (So Far) | Cloud Native Computing Foundation

https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/

The OpenMetrics project -Creating a standard for exposing metrics data

https://openmetrics.io/

Merging OpenTracing and OpenCensus: A Roadmap to Convergence
Monitoring Distributed Systems

*文/栉枫忻垣

关注得物技术，每周一三五晚18:30更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

更新内容：

[新增] select 组件 search-method 属性, 允许自定义搜索逻辑。
[新增] upload 组件 auto 属性, 是否自动上传配置。
[新增] tab 组件鼠标滚动功能, 兼容移动端 touch 事件。
[新增] textarea 组件 autosize 属性, 根据内容自适应大小。
[新增] icon-picker 组件 allow-clear 属性, 开启清空操作。
[修复] button 组件夜间模式下, 普通按钮边框高亮与背景色不一致的问题。
[修复] cascader 组件 v-model 属性不为空时, 无法正常回显。
[修复] select 组件 muilpart 为 true 时候 placeholder 属性无效。
[修复] page-header 组件 backIcon 插槽 html 中使用无效。
[修复] select 组件 search-method 属性, 自定义搜索逻辑不生效。
[修复] tag 组件 max-width 属性, 内容超出后 … 省略符缺失。
[修复] table 组件 column 属性 align 配置失效, 该问题仅存在 1.7.8 版本。
[修复] select 组件 build 后, 选中内容无法正确回显。
[修复] tab 组件 build 后, tab-item 无法正确显示, 在嵌套 v-for 时。
[修复] table 组件 default-toolbar 在配置数组时, 未按顺序渲染。
[修复] table 组件 ellipsisTooltip 属性不生效。
[优化] backtop 组件部分浏览器版本无法正常返回顶部。
[优化] date-picker 组件 btn 操作 border-radius 样式细节。
[优化] tag-input 组件 maxWidth 属性默认为 100%。
[优化] tag-input 组件 tagWidth 超出 input 宽度时自动省略文本。
[优化] table 组件 default-toolbar 属性支持 Array 类型, 举例：[‘print’]。
[优化] select 组件 dropdown 关闭时统一清空 search 内容。
[优化] checkbox 组件默认主题下, 勾选框多余的左边框。
[优化] icon-picker 组件下拉图标, 在打开关闭时赋予不同的状态。
[优化] table 组件 .layui-table-total 背景色 fixed 字段不生效的问题。
[优化] layer 组件 success 回调执行时机。

更多详情：http://www.layui-vue.com

11 月，EMQX 开源版和企业版分别发布了多个迭代版本，在安全性保障和生态集成方面又有了新的提升。

MQTT 消息云服务 EMQX Cloud 推出了新功能——自定义函数，用户可以更方便地将 IoT 数据处理为符合数据流的数据格式。

EMQX

11 月 EMQX 开源版发布了 v4.4.11、v4.3.22 以及 v5.0.10、v5.0.11 版本，企业版发布了 v4.3.17 以及 v4.4.11 版本。

由于开源版 4.3 版本已达到 18 个月生命周期（v4.3.0 于 2021 年 5 月 8 日发布），因此 v4.3.22 是 EMQX 4.3 开源版的最后一个社区版本。

同时，我们还将 v4.4 和 v5.0 的二进制包中 Erlang/OTP 版本从 v24.1.5 升级到了 v24.3.4.2。

Google Cloud Pub/Sub 集成

企业版 v4.4.11 中新增了 Google Cloud Pub/Sub 集成，您可以使用 Pub/Sub 将 MQTT 消息发送到位于 Google Cloud 上的服务和托管的后端应用中，更快地基于 GCP 构建物联网应用。

对于 Google IoT Core 用户，您无需做更多改变就能将 MQTT 传输层迁移至 EMQX，继续使用 Google Cloud 上的应用和服务。

CRL 与 OCSP Stapling

持有数字证书的物联网设备，如果出现私钥泄漏、证书信息有误的情况，或者设备需要永久销毁时，需要吊销对应证书以确保不被非法利用，4.4 版本中加入了 CRL 与 OCSP Stapling 功能用以解决这个问题，为您的物联网应用提供灵活且高级别的安全保障。

CRL（Certificate Revocation List，证书吊销列表）是由 CA 机构维护的一个列表，列表中包含已经被吊销的证书序列号和吊销时间。EMQX 允许配置 CA 的请求端点并定时刷新获取 CRL，而客户端无需维护 CRL，在连接握手时通过 EMQX 即可完成证书有效性验证。

OCSP（Online Certificate Status Protocol，在线证书状态协议）是另外一个证书吊销方案，相比于 CRL， OCSP 提供了实时的证书验证能力。OCSP Stapling 是该项技术的最新改进，进一步解决了 OCSP 隐私问题和性能问题。

启用 OCSP Stapling 后，EMQX 将自行从 OCSP 服务器查询证书并缓存响应结果，当客户端向 EMQX 发起 SSL 握手请求时，EMQX 将证书的 OCSP 信息随证书链一同发送给客户端，由客户端对证书有效性进行验证。

固定认证与 ACL 顺序

在 EMQX 4.x 版本中添加了两个新配置，用于设置认证和 ACL 检查顺序。当启用多个认证或 ACL 插件/模块时，您可以使用逗号分隔的插件名称或别名来设置其执行顺序。

通过文件初始化 API 密钥

4.x 版本的另一个新特性是能够通过文件初始化 API 密钥，预设的密钥可以帮助用户在 EMQX 启动时做一些工作：如运维人员编写运维脚本管理集群状态，开发者导入认证数据到内置数据库中、初始化自定义的配置参数，在之前这些工作必须在启动完成后新建密钥对才能进行。

 # 指定 bootstrap 文件 # etc/plugins/emqx_management.conf management.bootstrap_user_file ="etc/bootstrap_apps_file.txt"  # 使用 {appid}:{secret} 的格式初始化密钥对 # etc/bootstrap_apps_file.txt appid1:secret appid2:secret2

产品优化改进

我们修复了多个已知 BUG，包括连接 MongoDB 认证失败时打印大量日志的错误，消息重发布或桥接消息到其他 MQTT Broker 时添加主题校验流程避免消息发布错误，以及 EMQX 5.0 中大规模性能测试时连接数非常大的情况下复制节点可能无法启动的问题。

除此之外，我们还在 MQTT 协议实现和安全设计上中添加了许多改进，包括 gen_rpc 库质询-响应式的身份验证支持。

更好的运维体验

4.x 版本中移除对接口的认证要求，用户可以更方便地使用 Prometheus 抓取 EMQX 指标。

此外，上月发起的 v5.0 中 REST API 体验改善计划也正在进行。EMQX 5.0.11版本中已经包含了一些不错的改进，包括 API 的重新设计。

各版本详细更新日志请查看：

EMQX 开源版 v4.3.22
EMQX 开源版 v4.4.11
EMQX 企业版 v4.3.17
EMQX 企业版 v4.4.11
EMQX 开源版 v5.0.10
EMQX 开源版 v5.0.11

EMQX Cloud

自定义函数

EMQX Cloud 全新推出了自定义函数功能，借助云平台的函数计算能力，用户可定义编写脚本，并在数据集成功能中调用该函数。设备通过 topic 上报数据，平台接收数据后，数据解析脚本对设备上报的数据进行处理，进而再转入其他的工作流当中。

自定义函数功能可应用于多种场景：如将设备端上报的非十进制数据转化为十进制数据，符合应用标准后存入到数据库中；或者是将设备中的原始数据转化、整合为符合特殊行业协议的数据格式。

目前自定义函数支持部署在阿里云平台上的专业版用户，每个开通服务的部署都可以获得每个月 50000 次的免费调用次数，现在开通服务即可以立刻使用。有关自定义函数功能详情请关注后续推送。

优化丢弃消息监控指标

对丢弃消息监控指标进行了优化。现在，在部署控制台中选择，在丢弃消息指示中，可以看到丢弃消息的种类：过期而被丢弃的消息以及因为队列占满而被丢弃的消息。这将使运维监控和错误排查更方便。

EMQX Kubernetes Operator

11 月，自动化部署管理工具 EMQX Kubernetes Operator 进行了如下完善优化：

解决了在 v2alpha1 中，当没有发现 sts 时候出现的 crash bug
解决了在用户没有修改 CR 的情况下，sts 可能会一直更新的问题
解决了当 replicas 设置为 1 时，service 无法更新的问题
修复了在 status.Condition 中，lastTransitionTime 字段的错误
新增支持 EMQX 和 reloader 镜像 Registry

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/emqx-newsletter-

11 月，NanoMQ 继续保持稳步更新，最新的 0.14 版本已于本月初发布。此版本推出了用户期待许久的 ACL 鉴权（Access Control List）服务，并引入了全新的 HOCON 格式的配置文件。此外还缩减了发布版本时生成的 Docker 镜像的大小，并新增了带有 QUIC 支持的完整功能版镜像。

ACL 鉴权

将 MQTT 服务用于 IoT 应用时，为了保证服务和信息安全，需要 ACL 鉴权服务来防止恶意客户端发布错误数据和控制命令或订阅未经允许的主题获取敏感数据。NanoMQ 的 ACL 支持在众多用户呼声中于 0.14 版本正式发布。

目前 NanoMQ 支持通过在配置文件中编写规则来根据客户端 ID 和用户名配置鉴权规则。ACL 配置文件风格和语法与 EMQX 4.x 版本相同。

此处给出部分常用的场景规则配置示例：

需要从系统主题读取监控数据显示在控制台时，只允许用户名是 dashboard 的客户端订阅“$SYS/#”系统主题，忽略有非法操作的客户端：

 ## ACL 未命中时，允许或者拒绝 发布/订阅 操作 ## ## Value: allow: 允许 ##       deny: 拒绝 acl_nomatch=allow ## ACL 检查失败后，执行的操作。 ## ## Value: ignore:     忽略 ##       disconnect: 断开连接 acl_deny_action=ignore  # 允许用户名是 dashboard 的客户端订阅 "$SYS/#" 这个主题 acl.rule.1={"permit": "allow", "username": "dashboard", "action": "subscribe", "topics": ["$SYS/#"]}  # 拒绝其他所有用户订阅 "$SYS/#" 主题 acl.rule.2={"permit": "deny", "username": "#", "action": "subscribe", "topics": ["$SYS/#"]}

拒绝客户端 ID 为“malicious”和用户名为“unauthorized”的非法客户端向匹配“sensitive/#”和“Command/+/critical”的所有主题进行发布操作，并立刻断开有非法行为的客户端连接。

 acl_nomatch=allow acl_deny_action=disconnect  # 拒绝操作 acl.rule.1={"permit": "deny", "or" :["username": "unauthorized", "clientid": "malicious"], "action": "publish","topics": ["sensitive/#", "Command/+/critical"]}  # 前面的规则都没有匹配到的话，允许所有操作 acl.rule.2={"permit": "allow"}

ACL 功能可以在编译阶段关闭来提高性能和剪裁大小：

 cmake -DENABLE_ACL=OFF ..

未来会根据用户需求和反馈，提供更强大的 ACL 功能，如正则匹配、客户端 IP 匹配、关联数据库鉴权和 HTTP 鉴权等，欢迎大家在线提交功能申请和反馈。

全新 HOCON 配置文件

秉承 EMQX 5.0 的先进设计，NanoMQ 也采用了标准的 HOCON（Human-Optimized Config Object Notation/人性化配置对象表示法）作为配置文件格式。HOCON 是一种更适合人类阅读的数据格式，功能语法上是 JSON 和 properties 的一个超集，可以灵活拓展。它由 Lightbend 开发，同时也在 Sponge 和 Puppet 等项目中作为配置格式使用。

NanoMQ 为了保证项目原有的易移植性和高度兼容性，使用原生 C 语言开发实现了一个语法解释器来完成部分 HOCON 功能的解析并转换为 JSON 和内部结构体，使得用户能够在不引入其他依赖库的情况下也能使用 HOCON 风格的配置文件。从 0.14 版本开始，NanoMQ 以精简版本的 HOCON 格式为默认的配置文件。但考虑到许多老用户仍然习惯于使用原有风格的配置文件，所以旧的配置文件也予以保留，可以通过-old_conf命令来读取旧的配置文件格式。

在鉴权和桥接配置中使用 HOCON 语法

在 HOCON 格式中不需要再为多次出现的配置文件类目（如多个用户名密码键值对）增加数字下标。

 # #============================================================ # # Authorization   #============================================================ auth [ { login = "admin" password = "public" } {  login = "client" password = "public" }  ...... ]

对于复杂的配置层级关系，如多路桥接不分，能看到有更加明晰易读的隶属关系。

 bridges.mqtt {    nodes = [        {            name = emqx1            enable = true            connector {                server = "mqtt-tcp://127.0.0.1:1883"            }            forwards = ["topic1/#", "topic2/#"]            subscription = [                {                    topic = "cmd/topic1"                    qos = 1                }                {                    (......)                }            ]            parallel = 2,            ssl {                enable = false                }    }    {            name = emqx2            enable = true            connector {                server = "mqtt-quic://127.0.0.1:14567"            }            forwards = ["topic1/#", "topic2/#"]            subscription = [                {                    topic = "cmd/topic1"                    qos = 1                }            ]            (......)    } ]

其余功能的配置选项也根据 EMQX 5.0 的版本发布略有更改，请查阅 NanoMQ 官方文档查看更改后的配置文件细则。

其他优化

裁剪 Docker 镜像大小

NanoMQ 本身运行占用资源极小，但自 0.11 版本起由于引入了 QUIC 功能，使得镜像大小大大增加。为了帮助习惯采用 Docker 部署方式的用户节省部署空间，从 0.14 版本开始，Dockerfile 改为采用交叉编译方式发布具有完整功能的 Release 镜像。这一操作使得完整版镜像的大小缩小了数十倍。默认拉取的 NanoMQ 的镜像地址改为以 Alpine-Linux 为 base image 的版本，大小仅为 3MB。

MQTT over QUIC 桥接功能一经推出便得到了广泛的试用和热烈反响，但之前此功能必须通过源码编译开启，对于新手使用较为不便。自 0.14 版本起，NanoMQ 会自动一起发布开启 QUIC 支持的 Docker 镜像和二进制安装包。用户只需下载带有 -msquic 后缀的安装包或拉取带有 -full 后缀的 Docker 即可：

 ## 内置开启QUIC桥接功能的二进制安装包 nanomq-0.14.0-linux-amd64-msquic.deb ## 内置开启QUIC桥接功能的Docker镜像 docker pull emqx/nanomq:0.14.0-full

支持以共享库形式启动

不少用户有从自有程序调用 API 来启动 NanoMQ 的需求，或需要在 Android 或 iOS 移动端启动 MQTT 服务。为支持此类需求，NanoMQ 也可以编译成 .so 格式的动态链接库供使用：

 cmake -G Ninja -DBUILD_SHARED_LIBS=ON .. ninja

Bug Fix

修复了 QUIC 桥接中收到 Multi-Stream 功能影响造成的一个死锁问题。
修复了使用会话保持的客户端的 QoS 1/2 消息重发时，概率性顺序异常的问题。
修复了 QoS 1/2 消息只会重发一次从而造成的消息丢失。
修复了 Android 平台上通过动态链接库使用 NanoMQ 时由于 POSIX 时钟系统精度不足导致的计时器异常问题。
更新了 NanoSDK 的 close_all API 使其能够自动清理未完成的 AIO 避免线程阻塞。
为 MQTT over QUIC 桥接连接下线事件消息增加了MQTT V5 的 KeepAlive Timeout 错误码。

即将到来

由于配置文件格式更新，配置热更新和 Reload 功能将推迟到下一个版本中正式发布（只支持 HOCON 版本）。另外还将为 MQTT over QUIC 桥接功能增加 CUBIC/BBR 拥塞算法支持，以获取在不稳定带宽的网络环境中更稳定的传输质量保证。

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/nanomq-newsletter-

11 月我们发布了 Neuron 2.2.11 版本，主要优化修复了一系列在 2.2 版本中发现的问题，同时为 2.3 版本的发布做准备：增加 EtherNet/IP 驱动，完善 CNC FOOCAS 驱动，OPC DA 支持远程连接；MQTT 插件依赖库切换为 NanoSDK，极大提高数据收发性能。

新增 EtherNet/IP 驱动

EtherNet/IP 是由 ODVA 规范管理并公开的工业通信网络。OVDA 是一家国际标准开发组织，由世界领先的自动化供应商成员组成，EtherNet/IP 正是这个组织的代表作。EtherNet/IP 通过将 CIP 协议、TCP/IP、以太网这三者组合之后得以实现。

Neuron 新增的该协议驱动支持较为完善的数据类型，包括：UINT8/INT8、UINT16/INT16、UINT32/INT32、UINT64/INT64、FLOAT、DOUBLE、STRING、BIT。可用于连接支持 EtherNet/IP 协议的 PLC 设备。

完善 CNC FOCAS 驱动

CNC FOOCAS 驱动现支持更多类型的数据采集，包括 CNC 相关数据以及 PMC 区域的数据。

CNC 数据主要有 AXIS 相关数据（位置、速率等），以及 SPINDLE 相关数据。

PMC 数据支持采集的数据区域包括 message demand、counter、data table、extended relay、single to CNC → PMC、single to PMC → CNC、keep relay、input single from other device、output single from other device、internal relay、changeable timer、signal to machine → PMC、single to PMC ->machine；每个区域都支持多种数据类型。

OPC DA 远程连接

添加了局域网跨主机访问的功能；
添加了 GUI——可视化设置 DA 和 UA 连接参数，可以直观看到测点数据变化；
UA 服务器添加了默认加密连接和用户名/密码认证等功能；
主程序名称由 opcshift 更改为 neuopc；
添加了 DCOM 跨主机访问的设置文档；
添加了本机数据源读取的设置文档；

其他更新

WEB 与 API 端口统一为 7000。
增加适配 DTU 文档。
完善官网文档，适配即将发布的 2.3 版本。

问题修复

修复 MODBUS 插件处于 server 模式时重连异常的问题。

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/neuron-newsletter-

11月，XMeter 团队仍将工作重心放在 XMeter Cloud 专业版的开发上。目前，XMeter Cloud 专业版计划于12月上线，将为有大规模 MQTT 测试需求的用户提供更有力的支持，敬请期待。

模拟更高并发连接和消息吞吐

XMeter Cloud 基础版侧重于帮助用户快速体验 MQTT 性能测试服务，因此设置了 1000 并发连接和 1000 消息吞吐的规模限制。

专业版旨在向用户提供正式的持续性能测试环境，在可支持的 MQTT 并发连接数及消息吞吐量上都有大幅提升，与 XMeter Cloud 内置的多种 MQTT 经典测试场景配合使用，可快速运行高压力、稳定性等负载测试。

支持 VPC 测试

专业版将支持基于 VPC 对等连接的私有网络测试。完成与 XMeter Cloud 的 VPC 对等连接设置后，即可使用该对等连接来使用内网地址进行测试，降低网络时延的同时减轻带宽费用负担。

推出的 VPC 测试将首先基于华为云，如果您需要测试的 MQTT 服务搭建于其他平台上，也可以联系我们沟通支持规划。

更灵活的计费方式

专业版的测试定价将基于测试时长以及测试规格两个维度，以适配不同规模的性能测试。我们将推出基于资源包的预付费方式，提供不同规格的资源包，以灵活满足各种测试规模的需求。

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/xmeter-newsletter-

2022年12月7日更新内容：

1、新增“软件启动开始跟单”

当重启电脑或软件时，软件启动时，软件可自动启动开始按钮。

1）重启服务器后自动登录系统命令：开始-运行- control userpasswords2
regedit>计算机HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionPasswordLessDevice
DevicePasswordLessBuildVersion改为0

2）登录系统后自动打开软件：C:ProgramDataMicrosoftWindowsStart MenuProgramsStartUp

3）勾选软件中的系统设置》软件启动开始中单

2、修复报表中心中统计不到部分出金数据

3、Hookswork多帐户跨平台MT4跟单软件中的API跟单模式分为9档、5种跟单模式，以及任意跟单倍数三大部分。作为跟单账号可以按喊单开仓手数分档来进行跟单，每个档还可以分别按净值比、余额比、手数比、固定手数、自定义、并且可以随意设置相应的倍数来跟单。

MT4跟单中的九档：

一档：自定义喊单开仓的手数为某一区间时，跟单账号可以选择正跟/反跟，只跟多单/只跟空单/多空都跟，以下任意5种跟单模式，及任意倍数来跟单都可以

……

九档：分档区间最多可分9档区间设置，非常灵活。

五种MT4跟单模式：

资金比例（净值） – 喊单交易手数 * 跟单账户净值 / 喊单账户净值 * 模式参数 = 跟单交易手数

资金比例（余额） – 喊单交易手数 * 跟单账户余额 / 喊单账户余额 * 模式参数 = 跟单交易手数

手数比例 – 喊单交易手数 * 模式参数 = 跟单交易手数

固定手数 – 模式参数

自定义 – 可自定义设置跟单公式

任意跟单倍数：

模式参数：倍数或固定手数值

4、手动添加服务器IP地址

目前迈达克已经升级了MT4，因此安装了MT4 1367版本是搜索不到srv的，但是可以手动输入IP进行连接的。

选择多帐户跨平台MT4跟单软件的优势

1、毫秒级跟单延迟，最小延迟可以达到50毫秒，即0.05秒以内

2、支持全球所有经纪商的 MT4 交易软件

3、不需要平台开放任何权限，不需要 EA 插件

4、可选择性补单、可强制补重复的订单

5、可一次性全平所有跟单账号、可一次性全补单所有跟单账号

6、报表中心，可按年表、日表、自定义日期、品种进行查询

7、可定制开发特殊的功能

8、可通过安卓手机、Iphone 或Ipad进行实时配置、监控跟单情况

9、不需要打开 MT4 客户端，只需开启跟单软件即可

10、喊单及跟单账号数量无限制

11、观摩账号，也能跟单，跟单隐蔽不可追踪

12、丰富的风控系统，不跟单、强平功能

13、软件部署在自己的VPS上，信号源、账号密码、历史自己管理，安全可靠

14、开仓、平仓、补单、断线，手机可实时接受通知

15、提供最优的网络服务器解决方案，将延迟降到最低，连接稳定性更强

16、实时提供技术与服务支持

11 月， eKuiper 团队转入 1.8.0 版本的开发周期之中，目前已完成了一部分实用的新功能：添加了视频流 source，将边缘流式处理能力扩展到视频流领域，可以处理摄像头的视频流或者网络中的直播视频流；发布了通用的 tfLite 函数，用户只需上传训练好的 Tensor Flow Lite 模型，无需额外编写插件或代码即可在 eKuiper SQL 中调用模型进行流数据的 AI 推断，进一步简化了 AI/ML 处理的难度；针对边缘环境运维不便的特点进一步优化了规则自动化运维的能力，为规则添加了自动重启策略的配置，Portable 插件添加了热更新功能；继续完善了有状态分析函数的支持，增加 WHEN 子句进行按条件计算。

规则自动化运维

部署在边缘端的规则运维相对困难。而边缘端的部署数量通常较大，手工重启规则或重启 eKuiper 也会成为较为繁琐的工作。新的版本中，我们增强了规则的自治和自适应能力。

规则自动重启策略

规则因各种原因出现异常时可能会停止运行，其中有些错误是可恢复的。新的版本中，eKuiper 提供了可配置的规则自动重启功能，使得规则失败后可以自动重试从而从可恢复的错误中恢复运行。

用户可配置全局的规则重启策略，也可以针对每个规则配置单独的重启策略。规则重启配置的选项包括：

重试次数
重试间隔
重试间隔系数，即重试失败后重试时间增加的倍数
最大重试间隔
随机重试延迟，防止多个规则总是在同一个时间点重试，造成拥塞

通过配置重试，可以在出现偶发错误时自动恢复，减少人工运维的需要。

Portable 插件热更新

相比原生插件，Portable 插件更加容易打包和部署，因此也有更多的更新需求。之前的版本中，Portable 插件更新后无法立即生效，需要手动重启使用插件的规则或者重启 eKuiper。新的版本中，插件更新后，使用插件的规则可无缝切换到新的插件实现中，减少运维工作。

增强分析能力

新的版本继续加强了有状态分析函数的能力，同时提供了通用的 AI 分析函数，提升了产品原生的分析能力。

通用 AI 函数

我们提供了 Tensor Flow Lite 函数插件，用于在流式计算中进行实时 AI 推理。这个函数为通用的 AI 函数，可用于处理大部分已预训练好的 Tensor Flow Lite 模型。使用中，用户只需上传或提前部署好需要使用到的模型，无需额外编码即可在规则中使用这些模型。

tfLite 函数接收两个参数，其中第一个参数为模型（扩展名须为 .tflite）的名称，第二个参数为模型的输入。在以下两个例子中，tfLite 函数分别调用 sin_model.tflite 模型和 .tflite 模型针对数据流中的 data 字段进行实时 AI 计算。

 SELECT tfLite("sin_model", data) as result FROM demoModel SELECT tfLite("fizz_buzz_model", data) as result FROM demoModel

函数会在 eKuiper 层面针对输入数据格式进行验证。用户可以通过更多的 SQL 语句对模型的输入和输出做预处理或者后处理。

有条件分析函数

分析函数添加了 WHEN 条件判断子句，根据是否满足条件来确定当前事件是否为有效事件。当为有效事件时，根据分析函数语意计算结果并更新状态。当为无效事件时，忽略事件值，复用保存的状态值。完整的分析函数语法为：

 AnalyticFuncName(<arguments>...) OVER ([PARTITION BY <partition key>] [WHEN <Expression>])

增加了 WHEN 子句之后，分析函数可以实现更加复杂的有状态分析。例如，计算状态的持续时间：

 SELECT lag(StatusDesc) as status, StartTime - lag(StartTime) OVER (WHEN had_changed(true, StatusCode)), EquipCode FROM demo WHERE had_changed(true, StatusCode)

其中，将返回上次状态变化时的时间。因此，使用当前时间减去该时间可实时计算出状态的持续时间。

连接生态

eKuiper 可以处理二进制图像数据，但是此前的测试中，图像都是经由 MQTT、HTTP 等偏向文本数据传输的协议来发送。新版本提供了视频流源，增加了一种新的二进制数据源。同时，我们也继续适配新版本的 EdgeX。

视频流源

视频源用于接入视频流，例如来自摄像头的视频或者直播视频流。视频流源定期采集视频流中的帧，作为二进制流接入 eKuiper 中进行处理。

通过视频源接入的数据，可以使用已有的 SQL 功能，例如 AI 推理函数功能等，转换成数据进行计算或输出为新的二进制图像等。

EdgeX Levski 适配

eKuiper 1.7.1 及之后的版本适配了 EdgeX Levski 版本。同时，eKuiper EdgeX source 增加了 EdgeX 新增的 Nats 总线的支持。

产品新面貌

发布流程优化

11月我们优化了产品版本发布的流程。通过优化持续集成的基础设施，我们加快了版本发布的节奏，对于已完成的功能实现尽早交付，方便用户试用和反馈。

例如，11月已完成的 v1.8.0 功能已发布在 1.8.0-alpha.2 版本中，用户可通过 Docker 或 Github 页面进行下载试用。

持续集成同样应用在 1.7.x 版本中，根据用户反馈，我们在11月发布了 3 个 fixpack，修复了一些问题，目前最新的版本为 v1.7.3.

Logo 更新

eKuiper 的产品 Logo 于11月正式更新。新的 logo 更具动感，多段线条构成的向上不断流动的形象，与 eKuiper 作为运行在边缘端的轻量级物联网数据分析和流处理引擎的产品定位更加吻合。新 Logo 整体呈现出向上流动的动态，代表着 eKuiper 可将海量物联网数据从边缘实时移动到云端的能力，也彰显了无限变化和拥抱万物的概念，正如 eKuiper 所具备的灵活敏捷的集成能力，可在各类边缘计算框架上快速集成搭建边缘侧的流式数据解决方案。

即将到来

12月我们将继续进行 1.8.0 版本的开发，主要包括更高性能的静态 Schema 支持以及 Flow Editor 的推进。敬请期待。

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/ekuiper-newsletter-

项目介绍

BudWk 原名 NutzWk ，是基于国产框架 nutzboot 开发的开源 Java企业级Web开发框架，拥有近十年的开源历史，积累了一大批企业和个人用户，历经V1-V8数次迭代。

V8 在 V7具备的API网关、组件库、认证中心、控制中心等功能基础上，进一步对前后端功能进行升级改造、提升用户体验，同时大大减轻开发工作量，提升开发效率，为产品升级迭代提供极大便利。

框架同时提供及版本供选择，后台集权限体系、系统参数、数据字典、账户安全、行政区划、站内消息、定时任务、CMS、微信等最常用功能，使其具有上手容易、开发便捷、扩展灵活等特性，特别适合各类大中小型定制化项目需求。

演示地址：

https://demo.budwk.com

开发指南：

https://budwk.com

🎉 本版说明(BudWk v8.x)

功能特点

使用一套注解实现 OpenAPI3 在线文档的自动生成，同时实现表单参数验证功能，一举多得，减少开发量
统一异常拦截处理，业务逻辑判断抛出异常即可被捕获友好输出错误，无需一堆 if else 判断
一套控制类日志注解，轻松记录操作人、操作时间、IP、请求参数、响应结果，支持扩展不同数据存储方式
Excel 文件快速导入导出，只需在 Pojo 类上定义注解即可，支持键值对解析、子类属性解析、自定义日期格式等
Vue3前端表格支持动态列勾选显示、排序、固定等操作，分页组件进行了封装比Vue2版本减轻 80% 代码量
具备丰富的 wk-starter 组件库，使开发微服务应用像搭积木一样简单，组件开发也非常容易

更新内容

新增 Vue3 + Element-plus + Vite + TypeScript 前端
新增 wk-starter-config Nacos配置组件
新增 wk-starter-web 中的表单验证功能
新增 wk-starter-websocket 组件,方便扩展
新增 wk-starter-excel 导入导出组件
新增 wk-starter-apiauth API接口签名组件
修复 @JsonField(ignore = true) 忽略字段失效问题
更新 wk-starter-gateway 网关增加连接超时等配置项
其他功能的完善，交互体验优化

feilong 3.3.8 发布了，让Java开发更简便的工具库

让你从大量重复的底层代码中脱身,提高开发效率;
让你的代码，、、;

文档地址: http://feilong-core.mydoc.io/

maven 依赖配置:

 <dependency> <groupId>com.github.ifeilong</groupId> <artifactId>feilong</artifactId> <version>3.3.8</version> </dependency>

Gradle 依赖配置:

 com.github.ifeilong:feilong:3.3.8

本次升级共有处变更, 具体参见 3.3.8 milestone

🍑 feilong-core

#481 🗑️ Slf4jUtil.format Deprecated 过时 [deprecated] 原Slf4jUtil.format 方法,使用StringUtil.formatPattern 代替
#56 ✨ Validator.isNotNullOrEmpty 无法校验 ascii 码为 160 Unicode 为的不间断空格 [enhancement]
#55 ✨ 新建 com.feilong.core.lang.StringUtil.clean(CharSequence) 订单信息的address隐含’ backspace‘ ‘b’信息导致HUB不能解析订单 [enhancement]
#480 ✨ 新建 com.feilong.core.lang.StringUtil.formatPattern(String, Object…) 替换 Slf4jUtil.format(String, Object…)
#404 ✨ 新建 com.feilong.core.net.URIUtil.decodeIfExceptionDefault(String, String) 如果报错返回指定值 [enhancement]
#482 ✨ 新建 com.feilong.core.net.URIUtil.decodeIfExceptionDefault(String, String, String) [enhancement]

🍷 feilong-net

#478 ✨ 新建个工具类 DingTalkBotBuilder,可以快速new 一个DingTalkBot [enhancement]

ip2region (2.0 – xdb) 是一个离线的 IP 数据管理框架和定位库，支持亿级别的 IP 断管理，10 微秒级别的查询性能，提供了很多主流编程语言的 xdb 数据格式的生成和查询实现。

ip2region 2.11.0 具体更新：

1、增加 golang 实现的 xdb 数据编辑器，利用该编辑器可以非常方便的进行 IP 数据的修改或者批量更新，如下：

使用文档可以参考 ReadMe 或者 https://sigusoft.com/s/cZH5qIn4E5rQFy6N32RCzA 中的演示视频

2、更新 xdb 的数据，这不是一个全局的更新，而是融合社区的修正数据发的版本，感谢如下三个 issue 提供的数据修正：

3、发布利用社区数据进行一定量的数据更新方案，具体可以参考：https://sigusoft.com/s/cZH5qIn4E5rQFy6N32RCzA

4、golang / java maker 以及查询客户端的优化更新

ip2region 2.11.0 下载地址：

Gitee：https://gitee.com/lionsoul/ip2region/tree/v2.11.0

Github：https://github.com/lionsoul2014/ip2region/releases/tag/v2.11.0

十一月初，MQTT X 团队发布了 1.9.0 版本：MQTT X CLI 命令行客户端实现支持 MQTT 的性能测试，桌面端应用新增了关于学习 MQTT 的帮助页面等，此外还进行了一些使用优化和问题修复。

目前，团队正专注于 1.9.1 版本的开发。新版本中 MQTT X CLI 命令行客户端将支持自动重连，支持读取和存储本地配置文件，还可对于接收到的消息进行格式转换；桌面端应用支持设置滚动频率，并修复了一些使用上的问题。

桌面客户端

支持设置滚动频率

1.9.1 版本中我们新增了一个配置项：滚动频率。该配置项用于设置消息列表的滚动频率，需要在开启自动滚动时才可以配置。

在之前的版本中，当我们开启自动滚动时，消息列表会在接收到新的消息时自动滚动到底部，但是这样会导致消息列表的滚动速度过快，当接收到消息的速率过快时，用户无法马上查看到消息的具体内容。因此，我们新增了滚动频率的配置项，可以在设置页面中进行配置，滚动频率的单位为秒，用户可以根据自己的需求进行配置。设置完成后，当接收到新的消息时，消息列表会在滚动频率时间内滚动到底部，这样可以保证消息列表的滚动速度适中，用户可以在滚动前查看到消息的具体内容。

帮助页面调整

在之前的版本中，我们新增了帮助页面，用于帮助用户学习 MQTT。在这个版本中，我们将其设置成了一个独立的菜单，改名为「关于 MQTT 的一切」，方便用户快速到该菜单中，查看 MQTT 的相关知识，包括 MQTT 的基本概念、参数配置、主题消息、QoS 以及客户端编程等内容。

其它

用户属性配置支持添加多个重复的 key，并为其设置不同的 value，完全兼容 MQTT 协议
UI 样式与交互上的优化
修复一些已知 BUG

命令行客户端

支持自动重连

在之前的版本中，当 MQTT 服务器出现异常时，MQTT X CLI 命令行客户端会自动断开连接并退出，这样会导致用户无法在 MQTT 服务器恢复后继续使用 MQTT X CLI，需要重新手动连接。因此，我们在该版本中新增了自动重连的功能，当 MQTT 服务器出现异常后，MQTT X CLI 命令行客户端断开连接后会自动重连。

每次重连有一个最大重连次数，当达到最大重连次数后，MQTT X CLI 命令行客户端会退出，以防止客户端在无法连接的情况下一直重连。自动重连的最大重连次数默认为 10 次，可以使用参数进行配置。

 # 以连接命令时的自动重连次数配置为例，修改为 5 次  mqttx conn -h 'broker.emqx.io' -p 1883 --maximun-reconnect-times 5

除重连次数外，我们还新增了重连间隔的配置项，当 MQTT 服务器出现异常后，MQTT X CLI 命令行客户端会在重连间隔时间内进行重连，重连间隔的单位为毫秒，默认为 1000 毫秒，可以使用参数进行配置，

注意：当重连间隔设置为 0 时，表示关闭自动重连功能。

 # 以连接命令时的重连间隔配置为例，修改为 5000 毫秒  mqttx conn -h 'broker.emqx.io' -p 1883 --reconnect-period 5000

同时支持在命令中使用自动重连功能。对于自定数量中的连接，会对每一个异常断开连接的进行自动重连。

支持读取和存储本地配置文件

MQTT X CLI 命令行客户端在之前的版本中，每次连接都需要手动输入连接参数，这样会导致用户每次连接都需要输入一遍参数，比较繁琐。因此，我们在该版本中新增了读取和存储本地配置文件的功能。用户可以将连接参数保存到本地配置文件中，下次连接时可以直接读取本地配置文件中的参数，无需再次输入，且支持对所有 CLI 中的命令进行保存。

在运行命令时使用参数和保存文件的路径即可保存配置文件，默认保存的文件名为，保存的文件路径为当前运行命令的目录下。

在运行命令时，使用参数和配置文件的路径即可读取配置文件。

注意：MQTT X CLI 本地存储的文件同时支持 JSON 和 YAML 格式，但是在使用参数时，需要指定文件的格式，如或。

支持消息的格式转换

在之前的版本中，MQTT X CLI 命令行客户端只支持发送字符串类型的消息，当用户发送 Hex 类型的消息时，接收到的消息转换为字符串显示时就会出现问题。因此 MQTT X CLI 命令行客户端在该版本中新增了消息格式转换的功能，用户可以在接收消息时指定消息的格式。

消息格式支持以下几种：

String
Hex
Base64
JSON

除 String 格式外，只需要在订阅命令时添加一个参数即可指定消息的格式，如。

Web 客户端

MQTT X Web 客户端同步了 MQTT X 桌面端应用的相关功能修改与页面调整。

未来规划

MQTT X 还在持续增强完善中，以期为用户带来更多实用、强大的功能，为物联网应用与服务的测试和开发提供便利。接下来我们将重点关注以下方面，敬请期待：

接收消息和存储时的性能优化，大量消息不卡顿
MQTT Debug 功能
支持 Sparkplug B 格式
接收到的消息可以进行自动图表绘制
插件功能
脚本测试自动化（Flow）

版权声明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/mqttx-newsletter-

漏洞描述

Apache ManifoldCF 是一个具有多种连接器的多存储库爬虫框架。

Apache ManifoldCF 2.23及之前版本中由于 ActiveDirectoryAuthority.java 类没有对用户的用户名或域字符串进行有效过滤，导致 Apache ManifoldCF 的 ActiveDirectory 和 Sharepoint ActiveDirectory 权限连接器存在 LDAP 注入漏洞。攻击者可在 ManifoldCF 程序进行 LDAP 查询时注入恶意搜索字符进行 LDAP 注入攻击，从而获取对 Apache ManifoldCF 系统目录的未授权访问权限，查看或修改系统目录中的敏感文件信息或造成程序崩溃。

影响范围

org.apache.manifoldcf:mcf-activedirectory-connector@(-∞, 2.24)

org.apache.manifoldcf:mcf-sharepoint-connector@(-∞, 2.24)

修复方案

升级org.apache.manifoldcf:mcf-activedirectory-connector到 2.24 或更高版本

升级org.apache.manifoldcf:mcf-sharepoint-connector到 2.24 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65273

https://nvd.nist.gov/vuln/detail/CVE-2022-45910

https://github.com/apache/manifoldcf/commit/7df176b2a73ebea2dd3e319c7e9fc68bc162bab8

https://github.com/apache/manifoldcf/commit/4bc75e6aa0cefce5e4e3c45680d543bff5f3ed73

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

containerd 是一个开源的容器运行环境，containerd CRI 是一个使 kubelet 或 crictl 等服务能够使用 containerd 容器运行的接口，stream server 用于处理容器 IO 。

containerd 的受影响版本中的 CRI stream server 在处理用户调整终端大小的 tty 时请求存在不受控制的资源消耗漏洞，漏洞源于 CRI stream server 会启动一个 goroutine 线程来处理用户的 tty 请求，当用户的进程意外（如错误命令）无法启动时，该 goroutine 线程将在没有接收者的情况下等待发送（挂起），从而导致内存泄漏。攻击者可通过发送恶意的 tty 请求造成 containerd 程序拒绝服务。

漏洞名称 containerd CRI stream server 存在不受控制的资源消耗漏洞漏洞类型拒绝服务发现时间 2022-12-08 漏洞影响广度小 MPS编号 MPS-2022-1898 CVE编号 CVE-2022-23471 CNVD编号 –

影响范围

containerd@(-∞, 1.5.16)

containerd@[1.6.0, 1.6.12)

修复方案

升级containerd到 1.5.16 或 1.6.12 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1898

https://nvd.nist.gov/vuln/detail/CVE-2022-23471

https://github.com/containerd/containerd/security/advisories/GHSA-2qjp-425j-52j9

https://github.com/containerd/containerd/commit/a05db1145e5e6a735ad181e7fb0

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

Certifi 是一个用于验证 TLS 主机身份的同时验证 SSL 证书的可信度的开源代码库。

根据媒体报道：TrustCor 的所有权经营一家生产间谍软件的企业，Certifi 从根存储中删除“TrustCor”中的根证书，并且 TrustCor 正在被 Mozilla 从信任证书库中删除。请阅读相关链接：https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ

漏洞名称 Certifi 存在数据真实性验证不充分漏洞漏洞类型对数据真实性的验证不充分发现时间 2022-12-08 漏洞影响广度一般 MPS编号 MPS-2022-1918 CVE编号 CVE-2022-23491 CNVD编号 –

影响范围

certifi@[2017.11.05, 2022.12.07)

修复方案

将组件 certifi 升级至 2022.12.07 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1918

https://nvd.nist.gov/vuln/detail/CVE-2022-23491

https://github.com/certifi/python-certifi/security/advisories/GHSA-43fp-rhv2-5gv8

https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

在下周 Linux 6.2 合并窗口打开之前的早期拉取请求中，有一项更改是默认为 Linux 内核构建启用“-funsigned-char”，这意味着如果没有指定，“-funsigned-char”编译器标志会将所有“char”字符类型设为无符号。

C 的 char 字符数据类型分为 signed char 和 unsigned char，其中 unsigned char 占用内存的所有 8 位并且没有符号位。

char 在标准中是 unsigned，但不同的 CPU 体系结构/编译器能将其实现为 signed，也可以实现为 unsigned 。但此更改合并后，对于使用普通“char”类型编写的内核代码，将普遍将默认 char 类型视为 unsigned 。

WireGuard 首席开发人员 Jason Donenfeld 领导了 Linux 内核的 -funsigned-char 转换工作。早在 Linux 6.1 版本，Jason Donenfeld 在 ARM 上编译驱动程序时触发了构建错误，当时驱动程序假定裸类型已签名，但 ARM 将其视为未签名， C 标准则表示它依赖于体系结构。

发现这个 Char 类型混乱的问题后，他提出了 “treat char as always unsigned” 构建请求。并为 Linux 6.2 发送了一个默认启用 unsigned char 行为的早期 PR ，以及针对内核代码对 char 类型的符号性做出不同假设的各种内核修复。

感兴趣的朋友可以在构建请求和早期 PR 邮件中查阅更多详情。

算力时代，靠吃「硬件红利」便能搞定新应用场景的「甜蜜期」已经过去。

人类社会的每一次科技跃迁，其本质都是计算力的突破与演进。

算盘拨出农耕文明的繁荣，机械计算机催生出第一次工业革命的袅袅蒸汽，而云计算的发展让万物互联成为真正可能。

在数据爆发式增长以及算法日益精进的大背景下，属于「算力」的时代俨然到来。

以音视频行业为例，趋近饱和的场景渗透率、用户对体验的极致追求、多化的场景及技术需求，为底层算力和视频编码能力带来更大的挑战。

然而，在算力需求暴涨的同时，摩尔定律的演进速度却在放缓，「硬件红利」已然见底。

对于整个视频云赛道的算力困局，不仅需要上层软件系统的优化，也需要在底层硬件基础设施上，寻求破局之法。

01风口之下的算力困境

我们已经迈入社会视频化时代。视频无处不在，由此产生的流量已呈井喷式增长。

据《2022年中国网络视听发展研究报告》披露，截至2021年12月，我国网络视频(含短视频)用户规模达9.75亿，较2020年12 月增长4794万，占网民整体的94.5%。

网络视听正成为大众的娱乐刚需，视频正在成为各行业连接客户最广泛的载体，也成为各巨头抢占风口的关键点。

而在5G时代，视频流量将进一步增长。

视频流量激增的另一大原因，是用户对视频体验的「不将就」。

在视频规模持续增长的同时，随着网络和终端硬件设备的迭代，用户对视频清晰度体验的追求持续提升；视频超高清化也是继视频数字化之后的新一轮重大技术革新。

移动互联网终端观看分辨率从最开始的360P，480P，快速提升到720P，1080P以及近年出现的4K/8K超高清视频。

当前，国家也连续出台超高清产业支持措施并加速应用，如：5G+8K超高清技术在冬奥会和春晚实现商用；体育直播开始进入到4K HDR直播时代。

除了高分辨率，沉浸式视频体验还追求高帧率和宽色域，而每一次分辨率的提升，帧率的提升，色域增加带来的都是视频信息量的成倍增加。

因此，需要技术解决方案能更快应对更高清晰度、更低时延的视频编解码和转码，满足高清、高帧率、宽色域视频所带来的不断“扩容”的音视频数据流。

02难以调和的「视频编解码」矛盾

由于Raw（原始图像编码数据）视频数据是非常大的，如果不进行编码和压缩，不论是视频的存储还是传输，都将带来很大的麻烦，视频编码技术便是由此而来。

视频编解码起源于广播电视，从1951年第一部数字电视和广播诞生起，广播电视在很长一段时间里是视频编解码技术变革的核心推动力。

而到互联网时代，随着互联网的高速发展，使用互联网的用户和视频流量出现井喷式增长，互联网成为视频编码的主战场。

为了应对视频流量的不断增长，视频标准组织一直在推动视频编码技术的持续迭代。

从MPEG2开始，视频编码标准压缩率大约每10年提升50%，以2021年推出的h.266为例：相对于h.265压缩率提升50%，但其编码计算成本提升15倍。

然而，用户对视频极致体验的追求与视频编码的演进其实存在着巨大的矛盾。

1.编码标准升级速度远慢于视频信息量膨胀的速度：「十年磨一剑」的视频编解码技术（10年50%压缩率的提升）已经远远慢于视频化和体验升级带来的流量增长（过去3年音视频流量已高达68.9%的增速），而未来带宽压力会越来越大。

2.新编码标准压缩率的提升远低于视频分辨率提升的速度：每一代编码标准的演进，都是在不断探索极限压缩率。新一代的编码标准对比上一代的标准通常有50%的压缩率提升。然而如果视频分辨率每提升一档，比如360P到720P，则会使信息量增加4倍。

3.新编码标准复杂度的增加远高于CPU处理能力的增加：新一代的编码标准对比上一代的标准大多增加10倍以上的复杂度，远高于CPU处理能力的增强，而视频编码的高复杂度导致编码技术难以普惠，尤其在实时场景。

随着AR，VR时代的到来，4K-8K高分辨率，60-120FPS高帧率，10-12bit宽色域，让视频的信息量更是成倍增加；加之低延时意味着对编码速度有更高的要求；而CPU芯片处理能力也不再遵循摩尔定律快速增长，视频体验-带宽-计算成本-编码速度的矛和盾的冲突会越来越严重。

03软硬协同，锚定性能升级

视频编码与视频处理为计算密集型场景，面对视频云赛道的算力困局，如何让高压缩率的编码算法，更加普惠？

解法是：软硬协同+深度自研编码内核。

在该方向，我们一直在持续优化、迭代，而倚天ECS的出现带来更好的答案。

2021年云栖大会，阿里平头哥发布首颗为云而生的CPU芯片倚天710，该芯片针对云场景研发，同时兼顾了性能与易用性。

经过一年的业务验证，倚天710已大规模部署并提供云上服务，算力性价比提升超30%，单位算力功耗降低60%。

搭载倚天710的ECS自设计初就是一款云原生服务器，凭借其灵活、先进、弹性的云原生芯片特性和优异的CPU算力，超低功耗，与视频云的转码服务特点强匹配，为视频云云原生转码业务带来更多可能。

基于倚天ECS，阿里云视频云与平头哥数据中心解决方案团队联合，对s264、s265编码器进行深度优化。

最终实现：相对于C7，转码性能提升30%，在8K直播场景中提升达到33%，助力更普惠，更高清的转码服务。

04四维优化，释放「软硬结合」最大效能

基于阿里自研的倚天710芯片进行优化，通过深度重构视频编码数据结构、并行框架，重新调优快速算法策略，从软件、汇编、硬件层面跨层深度优化，打造ARM友好的视频编码器的同时，塑造极致性能。

主要体现在以下四方面的核心优化：

计算密集型汇编优化

计算密集型函数通过汇编实现单指令多数据操作优化，除常规汇编指令优化外，基于倚天710的特点，在视频编码中充分利用可伸缩向量指令集，mmla类型高并发指令的优势，塑造更高的汇编加速比，总体性能提升40%；

例如：在ME搜索优化中，结合710 SVE寄存器预取特性，设计内存预取算法以及寄存器访问流程优化，大幅降低内存访问次数，如一次六边形搜索，可以减少3.8倍行访问次数。

计算函数并行优化

在计算密集型函数汇编优化基础上，充分对有性能增益但原本串行处理数据的算法（如SDH）进行并行处理优化，并实现基于ARM平台的汇编版本代码，在压缩性能基本一致的情况下函数速度性能提升约40%。

偏控制函数优化

根据倚天710芯片特性，我们重构了视频编码数据结构，并行框架，同时重新调优了快速算法策略，联合提升总体性能，例如快速算法checkSkip，Earlyskip等，总体性能提升20%。

系统层优化

在算法优化的基础上，针对视频转码特点，结合倚天710平台和视频云特有场景下进行系统配置优化，将二者结合的能力发挥到最大。

目前倚天ECS已经在视频云点播上线，性能提升30%，压缩率提升5%，同时阿里云视频云同步探索AI辅助视频编码方向。

初步结果显示：借助倚天ECS的超强算力，倚天ECS在Saliencymap推理上成本低于G6ni 50%以上，在窄带高清的普惠化方面展现出了巨大空间。

未来，我们将基于自研处理器展开预研，深度结合视频云业务，沉淀视频云技术能力，从架构、指令、访存等方面优化设计。

同时，继续与平头哥开展深度合作，共建软硬件结合自研芯片竞争力，算法、加速库、驱动、固件一体化设计，不断探索创新音视频技术，加强其在更多视频应用、更多终端设备上的普适性。

将更多的技术普惠到广大消费者，赋能千行百业的视频化需求，催生新兴产品形态和业务模式，为客户提供更快、更省、更低功耗、更高清、更实时的编码力，并为广大观众带来更极致的视听体验和更创新的互动玩法。

1. 过期 key 处理

Redis 之所以性能强，最主要的原因就是基于内存存储。然而单节点的 Redis 其内存大小不宜过大，会影响持久化或主从同步性能。

我们可以通过修改配置文件来设置 Redis 的最大内存：

当内存使用达到上限时，就无法存储更多数据了。为了解决这个问题，Redis 提供了一些策略实现内存回收：

先要了解的是：redis 是一个存储键值数据库系统，那它源码中是如何存储所有键值对的呢？

Redis 本身是一个典型的 key-value 内存存储数据库，因此所有的 key、value 都保存在之前学习过的 Dict 结构中。不过在其 database 结构体中，有两个 Dict：一个用来记录 key-value；另一个用来记录 key-TTL。

内部结构

dict 是 hash 结构，用来存放所有的键值对
expires 也是 hash 结构，用来存放所有设置了过期时间的键值对，不过它的 value 值是过期时间

这里有两个问题需要我们思考：

Redis 是如何知道一个 key 是否过期呢？
利用两个 Dict 分别记录 key-value 对及 key-ttl 对，是不是 TTL 到期就立即删除了呢？

总结：Redis的过期删除策略就是：惰性删除和定期删除两种策略配合使用

惰性删除

惰性删除：顾明思议并不是在 TTL 到期后就立刻删除，而是在访问一个 key 的时候，检查该 key 的存活时间，如果已经过期才执行删除。

周期删除

周期删除：顾明思议是通过一个定时任务，周期性的抽样部分过期的 key，然后执行删除。执行周期有两种：

Redis 服务初始化函数 initServer () 中设置定时任务，按照 server.hz 的频率来执行过期 key 清理，模式为 SLOW
Redis 的每个事件循环前会调用 beforeSleep () 函数，执行过期 key 清理，模式为 FAST

SLOW 模式规则：

执行频率受 server.hz 影响，默认为 10，即每秒执行 10 次，每个执行周期 100ms。
执行清理耗时不超过一次执行周期的 25%. 默认 slow 模式耗时不超过 25ms
逐个遍历 db，逐个遍历 db 中的 bucket，抽取 20 个 key 判断是否过期
如果没达到时间上限（25ms）并且过期 key 比例大于 10%，再进行一次抽样，否则结束

FAST 模式规则（过期 key 比例小于 10% 不执行）：

执行频率受 beforeSleep () 调用频率影响，但两次 FAST 模式间隔不低于 2ms
执行清理耗时不超过 1ms
逐个遍历 db，逐个遍历 db 中的 bucket，抽取 20 个 key 判断是否过期
如果没达到时间上限（1ms）并且过期 key 比例大于 10%，再进行一次抽样，否则结束

2内存淘汰策略

①、设置Redis最大内存

在配置文件redis.conf 中，可以通过参数 maxmemory <bytes> 来设定最大内存：

②、设置内存淘汰方式

当现有内存大于 maxmemory 时，便会触发redis主动淘汰内存方式，通过设置 maxmemory-policy

有如下几种淘汰方式：

：设置了过期时间的key使用LRU算法淘汰；
：所有key使用LRU算法淘汰；
：设置了过期时间的key使用LFU算法淘汰；
：所有key使用LFU算法淘汰；
：设置了过期时间的key使用随机淘汰；
：所有key使用随机淘汰；
：设置了过期时间的key根据过期时间淘汰，越早过期越早淘汰；
：默认策略，当内存达到设置的最大值时，所有申请内存的操作都会报错(如set,lpush等)，只读操作如get命令可以正常执行；

比较容易混淆的有两个：

LRU（Least Recently Used），最少最近使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。

LFU（Least Frequently Used），最少频率使用。会统计每个 key 的访问频率，值越小淘汰优先级越高。

使用下面的参数maxmemory-policy配置淘汰策略：

Redis 的数据都会被封装为 RedisObject 结构：

LFU 的访问次数之所以叫做逻辑访问次数，是因为并不是每次 key 被访问都计数，而是通过运算：

生成 0~1 之间的随机数 R
计算 (旧次数 * lfu_log_factor + 1)，记录为 P
如果 R < P ，则计数器 + 1，且最大不超过 255
访问次数会随时间衰减，距离上一次访问时间每隔 lfu_decay_time 分钟，计数器 -1

本文由教研团队发布。

如果本文对您有帮助，欢迎和；如果您有任何建议也可或，您的支持是我坚持创作的动力。

转载请注明出处！

作者：康凯森，StarRocks PMC，负责查询方向的研发（本文转自其个人博客“编程小梦”）

从 2015 年开始，我在美团先后维护和研发过 Apache HBase、Apache Kylin、Apache Druid 和 Apache Doris，对大数据系统和 OLAP 数据库有了深入理解。

2020 年开始，我加入了 StarRocks 社区。我们先后打造了业界领先的向量化执行器、CBO 优化器、Pipeline 并行引擎、支持高效 Update 的存储引擎和极速数据湖分析。支持存储分离的 Cloud Native 版本也即将面世。

一路走来，随着 StarRocks 项目攻克一个又一个技术难题，解决一个又一个用户需求和难题，服务着越来越多的用户，我对如何打造一个强大且成熟的数据库有了更深的理解。在这篇文章中，我会和大家介绍打造一个强大且成熟的数据库都有哪些难点。

#01

本质矛盾

—

无论是一个年轻的社区团队，还是一家大公司的数据库部门，打造一款强大且成熟的数据库都会有下面两个本质矛盾：

有限人力和无限工作之间的矛盾

各种各样的用户需求，无止境的性能优化，永远也修不完的 Bug，一个又一个 Killer Feature 的打造，时刻不停的代码重构，增加不完的测试 Case，不间断的技术调研和系统设计。这些工作都需要大量人力，但无论哪家公司，人力总是不足的，优秀的数据库人才更是稀缺。

飞速增长与成熟稳定的矛盾

如果数据库的代码不大变，面对的应用场景不大变，我们让一个数据库变稳定会容易很多。但是如果一个数据库的代码在飞速变化和增长，应对的应用场景不断丰富和变化，让一个数据库稳定下来就会很难。

#02

定位和独特性之难

—

一款数据库想要在产品和商业上取得成功，想在很多竞品中脱颖而出，就必须有清晰的定位和自己的独特性。一款数据库的独特性就是自己的价值点，比如目前 StarRocks 的价值点就是极速统一。

一旦定位和独特性定义清楚，便意味着产研资源重心和方向的倾斜。而一款数据库想要让自己的独特性成为 Killer Feature，就必须超越所有竞品。这就意味着，这个数据库团队必须有足够强大的创新能力，足够强大的工程能力，才能做到其他数据库公司一定时间内无法做到的。

#03

架构之难

—

一个数据库的架构决定了一个数据库未来的上限，决定了一个数据库未来支持更多用户需求的难易程度。如果架构设计有误，后面的很多功能和优化成本就会很高，甚至无法实现。不过在当下，云时代数据库的架构逐渐趋同，想要有足够的独特性和明显的优势还是比较困难。

#04

功能之难

—

Killer Feature 的创新性和独特性

一般数据库在产品功能上肯定会推出几个 Killer Feature，作为自己产品的卖点。但是想作为 Killer Feature，就必须比竞品好很多，这时候 Killer Feature 就必须拥有一定的创新性和独特性。

持续不断的用户需求

用户越来越多，用户的需求自然就会越多，有些用户的需求很小众。但有时候为了服务一个用户，我们却不得不做，而且有时候做了还会给系统带来额外的复杂性。

各种各样的认证

认证里面的一些功能其实并不是你的数据库产品所必须的，做了不会明显增加产品竞争力。为了满足并获取更多企业级用户，还是得投入大量人力去通过认证。

用户迁移时的功能对齐

当一个新系统越来越好，要扩大市场规模，必然要去替换用户已有的旧数据库，但是替换过程中经常会遇到语法、函数、功能不对齐的场景。这时候，如果这个用户很重要，你就不得不去做一些和传统数据库功能对齐的事情。

系统越强大会越复杂

越强大的优化可能跨模块越多：比如 StarRocks 的低基数优化和导入、查询、Delete、Update、Compaction、Schema Change、 MVCC 等很多模块都有关系，所以这类功能的测试本身就会很复杂
一个新的功能或者优化可能会打破旧的功能或者优化的假设：比如 Tablet 并行可能和 Local exchange 有冲突，比如 Query Cache 可能和 Shared Scan 有冲突

系统越成熟，新的功能和优化要求越高，大规模使用周期越长

新系统的第一个版本往往会给用户建立一个 Baseline，之后的版本做的功能和优化就必须考虑所有用户的场景，在自己的用户场景下没有或者很少有 Bad Case
用户使用一个系统稳定后，升级的动力会越来越弱，所以越靠后的版本得到用户大规模验证的周期也会更长

#05

性能之难

—

CBO 优化器 Plan 的稳定性和正确性

统计信息的变化会导致查询 Plan 发生剧变
某些优化就是会导致部分查询变快，部分查询变慢
选择度估计和基数估计一般都假设了数据的均匀分布，但这和实际情况并不相符
统计信息收集如何做到相对准确又不耗费大量的系统资源

单核性能优化

单核性能优化是一个没有止境的过程，我在 StarRocks 技术内幕：向量化编程精髓一文中已经解释了单核优化的关键点和方法论，所有算子和函数的深度优化是需要数十人年的事情。

多核扩展性优化

StarRocks 单核性能登顶 ClickBench 后，我们在优化多核性能上投入了大量精力。相比单核，突破多核扩展性的瓶颈要更困难些，目前已经做了大量优化、还远远不够。不同类型的查询在高并发下会遇到不同的瓶颈：Lock，线程池，RPC，调度问题，NUMA，CPU Cache，内存管理，IO 异步等。

多机扩展性优化

多机的扩展性的常见瓶颈点主要包括：

RPC 的扩展性
数据的扩展性
如何解决数据倾斜
如何通过调度策略解决热点，充分调用整个集群的算力
优化器要确保每个算子，函数都可以生成分布式的执行计划，不会有单点执行的瓶颈

存储引擎的优化

存储引擎需要在导入性能和查询性能之间进行权衡，一般情况下，导入时候做的事情越多，查询时候的代价就更低些：

更新能力的持续优化
导入能力的持续优化
压缩和编码
Compaction 策略的持续优化
事务能力的优化
内存使用上的优化
各个级别 Cache 能力的优化

针对特定场景的性能优化一般会增加系统复杂性

数据库一般都是面向通用场景开发，但是在特定场景下可以获取更多信息和上下文，这时就可以进行更多的针对性优化。但这样也会带来问题，比如系统的代码逻辑更加复杂，测试和维护的难度更高。

如何保证性能不退化

当系统复杂之后，多人协作经常会出现的问题是，一个人之前精心写的一段对性能影响很大的代码，被后人不小心改掉了。或者是优化 A 优化了某些场景的性能，但是却导致之前优化 B 的优化失效了。

如何能 Cover 不同的硬件环境

数据库这个复杂的软件是构建在硬件之上的，硬件是决定性能的基础。但是 CPU 有不同的型号，网络带宽有高有低，磁盘的吞吐和 IOPS 也有很大的差别，有可能一些软件层面的优化只对某些硬件环境生效。

#06

稳定性之难

—

一款数据库的成熟，主要体现在稳定性上，而打造一个稳定的数据库有如下难点：

SQL 是声明式的

机器可以生成成千上万行的 SQL，SQL 各种算子和函数的组合是无法穷尽的，要保证任何一条 SQL 没有 bug，是极其困难的
SQL 里面的 Null 和 Nullable 是比较令人烦恼的，不仅对性能有很大影响，对正确性也有较大影响

成百上千的用户场景

每个用户的硬件配置，环境信息，应用特点不一样，都可能引发不同的问题。

各种各样的集群规模

很多时候，只有当集群规模、数据量、并发量到一定程度，一些稳定性和扩展性的问题才会暴露出来。如何在产品发布之前，在有限的资源下，通过测试暴露这些问题也是一个难点。

功能的组合

很多时候，一个功能单独 Work 没有问题，但是多个功能相互影响时，一些 Bug 才会暴露出来。比如节点下线，触发数据的均衡和复制，又会触发数据版本的问题，进而触发查询的问题。比如导入、查询、Compaction、系统任务对 IO 资源的共同影响，这些复杂功能组合时的测试难度会更大。

函数的预期行为没有标准

比如 Date 类型和数字的比较，字符串和数字的比较，应该是直接报错还是隐式转换，隐式转换的公共类型转成啥。这些其实都没有统一的标准，每个数据库都有自己的实现。关键问题是即使改成最合理的表现，一些用户可能会因为习惯自己熟悉的数据库的表现，觉得当时最合理的表现是不合理的。

还有聚合函数溢出后行为，Decimal 运算精度的确定，函数一些异常行为是抛异常还是转 Null。我们不仅要兼容用户期望的行为和正确性，还要兼顾正确性和性能。

多版本维护

由于快速迭代和发展，我们必然要维护很多版本，这给稳定性提出了更大的挑战：

定位，复现问题成本会更高，比如研发得用指定版本的代码部署环境，复现问题
解决问题后，也必须给所有版本 Cherry-pick，这时候很容易遗漏某个版本
要确定某个 Bug 到底在哪些版本修复了，成本也比较高
某个版本发生大的改动或者重构，之后的 Bug Fix PR Cherry-pick 就无法自动化，人工操作的成本会很高

兼容性问题

当我们维护很多个版本后，有时候不得不做一些不兼容的改动：

之前的行为本身是错误的或者不合理的
想完全删除某些旧代码

查询层是无状态的，所以不兼容的改动一般可以绕过或改 SQL 解决。但是存储层和数据层是有状态的，一旦有不兼容的问题会很麻烦。

不同语言的行为不一致

对于类似 StarRocks 这种多进程、多语言的数据库，在稳定性问题上还有一个额外的挑战是：

不同语言的一些标准库行为会不一样，这会导致在不同模块计算相同函数的结果不一致
之前遇到不同语言 Java 和 C++ 取余的结果不一致

这几年来，我遇到过挺多这样的 Case。

编译器的 Bug

一般编译器被各种项目大量使用，我们开发者遇到 Bug 的机会比较少。

不过在开发 StarRocks 向量化的过程中，我就遇到了一个编译器的 Bug:编译器进行向量化优化后，把 Boolean 值转成了 255：

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255

还有最近遇到的一个 C++ 正则标准库的 Bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164#c8

分布式相关问题

现在的数据库几乎都是分布式数据库，所以分布式系统遇到的问题，一般数据库都会遇到。比如分布式系统的常见挑战：单点故障，部分失败，不可靠的网络，不可靠的时钟。

硬件故障

数据库的存储引擎必须保证数据能被正确地存储和读取，但是我们在实际环境中不可避免会遇到各种硬件故障：磁盘坏掉，磁盘数据错误，服务器宕机，机房断电，网络异常等。

#07

生态之难

—

数据导入

数据格式的多样性：CSV，JSON，Parquet，ORC，ARROW 等
数据源的多样性：Local File，Kafka，Hive，数据湖，传统数据库等
导入时支持 Transform （表达式计算）

数据导出

导出格式的多样性
导出位置的多样性：客户端，本地，分布式存储等
全量导出和部分导出

BI 工具：数据可视化

市面上流行的 BI 工具多达几十种，每种 BI 工具深入使用后都或多或少会有些兼容性问题：Session 变量的兼容性，数据类型的兼容性，函数的兼容性等。要尽可能完美地兼容，必然有大量的人力投入。

数据迁移

要支持用户从传统数据库和各种竞品数据库顺滑迁移，就必须和各种数据库进行对接，这里面有大量琐碎的工作。

比如我们想将 Presto 的用户迁移到 StarRocks 上，我们就需要在 SQL 语法层进行兼容。

比如单机数据库上一些很容易实现的功能，在分布式数据库上就会相对困难，这时候如果为了功能对齐，就需要不少的工作。

#08

安全之难

—

安全包括：认证，鉴权，审计，加密，脱敏等。这里面每一项都有着大量的工作，对于金融、政府客户、安全体系要求很高，公有云上的安全要求则会更高。

#09

易用性之难

—

在未来，毋容置疑，易用性会越来越重要，并将会是一款数据库的核心竞争力。数据库分析师需要知道的数据库知识会越来越少，需要进行的操作会越来越少。易用性主要体现在 3 个层次：

架构层面的易用性：比如自适应执行，Automatic Clustering，Automatic Index，Automatic Scale 等。
产品层面的易用性：比如接口定义和功能上是不是足够简洁清晰，一个命令可以导入各种数据源，各种数据格式的文件，一个命令可以查询各种数据源、文件等。
细节层面的易用性：文档是否完善，报错信息是否清晰易懂，可观测性是否足够好。

#10

难点如何解决

—

在你将这些点一个一个深入思考下去，肯定会理解打造一个强大且成熟的数据库是多么困难，那么这些难题如何解呢？

欢迎关注 StarRocks 微信公众号，后续我们继续探讨、揭秘！

关于 StarRocks

面世两年多来，StarRocks 一直专注打造世界顶级的新一代极速全场景 MPP 数据库，帮助企业建立“极速统一”的数据分析新范式，助力企业全面数字化经营。

2021 年 9 月，StarRocks 源代码开放，在 GitHub 上的星数已超 3600 个。StarRocks的全球社区飞速成长，至今已有超 200 位贡献者，社群用户近万人，吸引几十家国内外行业头部企业参与共建。

学过 Spring 的小伙伴相信都知道 AOP，AOP 学的好的小伙伴相信对 AOP 的概念也是轻车熟路：面向切面编程、切点、切面、通知，Aspect、Pointcut、Advice 等如数家珍。

AOP 之所以这么重要，是因为它在项目中有着非常广泛的应用，今天这篇文章，松哥就来和大家总结一下，我们在日常开发中，都有哪些典型场景需要用到 AOP。

> 先来一句话总结下，AOP 的使用，基本上都会涉及到自定义注解，一个非常常见的组合，就是自定义注解+AOP。

在日常的开发中，有很多重复的代码，我们总是希望将之简化，AOP 就是一个非常常用的简化手段。简化的思路一般是这样：

首先，自定义一个注解。
定义 AOP 切面，在切面中，定义切点和通知，切点，也就是方法的拦截规则，我们可以按照注解来拦截，也就是某一个带有自定义注解的方法，将被我拦截下来。
拦截下来之后，前置通知、后置通知、异常通知、返回通知还是环绕通知，就可以随便写了。

所以，这些涉及到自定义注解的地方，基本上都可以算是 AOP 的使用场景了，因为自定义注解，需要用 AOP 来解析。

接下来我们来看几个比较典型的例子。

1. 幂等性处理

接口幂等性的处理，其实有很多种不同的方案，例如：

Token 机制
去重表
利用 Redis 的 setnx
设置状态字段
上锁

无论是哪种方案处理幂等性，每个方法里边都去写一遍幂等性的处理显然是不现实的，因此，一般都是将幂等性的处理通过自定义注解+AOP给封装起来，大致的思路如下：

首先自定义一个注解。
自定义切点，拦截所有加了自定义注解的方法。
定义环绕通知，在环绕通知中，先通过上述五种思路中的任意一种，对方法执行的幂等性进行判断，判断通过了，再执行目标方法，判断不通过，则直接抛出异常，不执行目标方法。

这就是自定义注解+AOP 的一个典型应用场景。

如果你对上面的表述云里雾里，不妨看看松哥之前发的这个视频，有详细的手把手教程：处理接口幂等性的两种常见方案|手把手教你。

2. 接口限流

对于接口限流，目前来说，一个比较成熟的方案是使用 Alibaba 的 Sentienl，简单配置一下就可以实现接口限流了。

但是如果没有用这个工具呢？如果是我们自己写呢？毫无疑问，还是自定义注解+AOP，思路大致如下：

自定义注解。
在需要进行限流的接口方法上添加自定义注解，同时还可以设置一些限流的参数，例如时间窗口值、流量大小等。
自定义切点，拦截规则就是所有添加了自定义注解的方法，拦截到方法之后，在环绕通知中，可以通过 Redis 插件 redis-cell、通过漏斗算法去处理限流，这个我这里就不罗嗦了，之前的文章中都写过了。限流计算没问题的话，就执行目标方法，否则将操作拦截下来。

大致思路如上，说白了就是自定义注解+ AOP，道理虽然简单，但是真正做起来，还是有很多细节，感兴趣的小伙伴可以参考松哥之前的这篇文章：Redis 做接口限流，一个注解的事！。

3. 日志处理

说到 AOP，所有人都能想到的使用场景了，这个我就不罗嗦了，松哥之前也有过专门的文章介绍，没看过的小伙伴们戳这里：记录项目日志，一个注解搞定。

4. 多数据源处理

有时候我们项目中存在多个不同的数据源，在实际使用中需要进行切换，网上也有一些开源的解决方案，不过这个东西其实并不难，我们也可以自己写。

自定义多数据源的处理，大致上思路如下：

从 Spring2.0.1 中引入了 AbstractRoutingDataSource 类，（注意是 Spring2.0.1 不是 Spring Boot2.0.1，所以这其实也算是 Spring 一个非常古老的特性了）, 该类充当了 DataSource 的路由中介，它能够在运行时, 根据某种 key 值来动态切换到真正的 DataSource 上。

大致的用法就是你提前准备好各种数据源，存入到一个 Map 中，Map 的 key 就是这个数据源的名字，Map 的 value 就是这个具体的数据源，然后再把这个 Map 配置到 AbstractRoutingDataSource 中，最后，每次执行数据库查询的时候，拿一个 key 出来，AbstractRoutingDataSource 会找到具体的数据源去执行这次数据库操作。

基于以上知识，我们可以自定义一个注解，在需要切换数据源的方法上，添加这个注解，然后通过 AOP 去解析这个自定义注解，当目标方法被拦截下来的时候，我们跟进注解中的配置，重新设置要执行的数据源，这样将来 service 中的方法在执行的过程中，就会使用到切换之后的数据源了。

思路并不难，松哥之前也写过详细的教程，小伙伴们参考这里：

手把手教你玩多数据源动态切换！
网页上点一下，就能切换不同数据源？松哥手把手教你！

5. 方法权限处理

这个其实也跟前面的差不多。

方法级别的权限处理，一般来说也是基于注解来完成的。如果你使用了 Spring Security 之类的权限框架，就不用自己解析权限注解了，按照框架的要求直接来使用就行了。

有的时候，我们可能没有使用 Spring Security，想自己处理权限注解，也是可以的。用户自定义权限注解，为注解添加属性，然后将注解添加到目标方法上，再通过 AOP 去解析这个注解，AOP 将目标方法的执行拦截下来，然后判断用户是否具备所需要的权限，如果具备，就执行目标方法，否则就不执行。

前两天松哥刚刚分享的在微服务中，服务内部的权限校验，就是自定义一个注解，将从其他微服务上来的请求给拦截下来，然后判断请求的来源，如果是从其他微服务上来的，就执行目标方法，如果不是从其他微服务上来的，而是从外部来的请求，那么就将之拦截下来抛出异常，不执行目标方法，参见：微服务中的鉴权该怎么做？。

6. 事务处理

这个倒是不需要自定义注解，对于声明式事务，直接用现成的注解就行了，但是本质上也是 AOP，如果有小伙伴在 Spring 的 XML 中配置过事务的话，就知道这个东西底层也是 AOP。

好啦，梳理了几个简单的案例，希望小伙伴们了解到 AOP 并不是屠龙术，而是在日常开发中有着广泛应用的技术。

2020年1月，时间跨度长达14年的，微软2.5亿条客户服务和支持记录在网上泄露；

同年4月，微盟发生史上最贵“删库跑路”事件，造成微盟市值一夜之间缩水约24亿港币；

今年7月，网信办依据《数据安全法》等法律法规，对滴滴公司开出人民币80.26亿的巨额罚款，对互联网企业敲响数据安全警钟。

数据作为互联网的重磅资源，当今重要的“生产要素”及核心竞争力，已经获得了立法上的认可。随着2021年9月1日，中国第一部有关数据安全的法律《数据安全法》正式施行，我国的数据安全制度已经进入了一个新阶段。

不同于网络安全侧重于通过保障计算环境的安全，从而最终保障计算对象的安全。数据安全是以“数据为中心”，主要侧重于数据全生命周期的安全和合规性，以此来保护数据的安全。而企业数据资产作为未来企业发展的基座，在数据采集、存储、处理的一系列流程中，无疑面临着巨大的安全风险挑战。

如何更好地保障数据安全，成为压在每个企业肩头沉甸甸的担子。

一站式大数据安全管理

作为全链路数字化技术与服务提供商，袋鼠云在数据安全方面有过多年的探索和实践。近日，袋鼠云依托其实践，在旗下产品大数据基础平台EasyMR上新增了一站式大数据应用安全防控以及数据权限管控能力。

EasyMR是袋鼠云今年7月最新推出的自研大数据基础平台，该产品集成了服务管控应用ChengYing和内部孵化大数据生态，提供Hadoop、Hive、Spark、Trino、HBase、Kafka等组件的自动化安装、中心化管理与集群监控告警功能，完全兼容Apache开源生态。是一款具备标准的服务部署、服务监控、服务管理等功能的产品。

此次，EasyMR通过集成第三方的安全管控服务Kerberos、Ldap和Ranger分别对大数据集群进行用户安全认证、访问用户管理以及用户数据权限管控。

借助EasyMR的部署和管理能力，以界面化方式部署大数据集群安全管控服务。大数据集群使用者无需关注安全服务部署逻辑以及应用内部工作逻辑，只需要在EasyMR界面查看具体开启进度以及开启结果状态。

通过EasyMR部署大数据集群管控服务，运维人员可以直观地在EasyMR界面对安全管控服务进行管理和运维，包括服务的启停、状态监控等。

EasyMR安全管控能力

相比与其他厂商的大数据集群安全管理，EasyMR可以做到一键部署安全管控服务，一键开启大数据集群组件的安全认证、用户管理以及权限管控服务。下面来具体聊聊EasyMR的安全管控能力。

操作便捷

借助EasyMR的管理能力，在部署安全管控服务之后，仅需要在对应的服务页面开启安全按钮，即可开启对应服务的安全。如图：

例如：需要对Zookeeper开启Kerberos，则只需要跳转到Zookeeper所在服务页面，开启按钮，等待开启完成。应用开启安全的内部具体实现流程如下：

EasyMR功能丰富，其中连接KDC进行服务票据的生成和服务票据的分发是通过EasyMR的脚本管理能力完成；配置变更和配置下发到各个主机则是凭借EasyMR的配置管理能力，在后台对开启安全服务配置进行新增和修改；而服务重启则依赖EasyMR对服务起停的管理能力，实现对大数据集群的自动重启。

借助EasyMR的配置文件管理能力，在未开启Kerberos状态下，针对大数据集群的配置会单独维护一份当前集群状态使用的配置。当开启Kerberos的按钮时，后台会将开启Kerberos的配置新增到当前的配置文件中。

例如 core-site.xml中的hadoop.security.authentication Kerberos。在未开启安全情况下，此配置会默认赋值simple；在开启安全操作触发后，此配置会后台替换为Kerberos，然后配置下发到对应服务所在主机上；配置下发完成后，EasyMR会自动触发服务重启逻辑，加载新的配置，重启完成后会显示安全开启成功。

具体开启步骤：

Part.1 开启按钮，确定开启安全

Part.2 查看具体开启进度以及开启打印日志

Part.3 开启成功

Part.4 票据下载使用

管理便捷

EasyMR具有大数据集群配置文件管理能力。在开启Hadoop安全后，使用者想利用客户端连接工具使用Hadoop或者Hive，对应的Hadoop集群配置文件hdfs-site.xml、core-site.xml、yarn-site.xml以及用户票据等文件不需要到服务器上去进行获取，直接在对应服务的页面下载配置按钮，即可下载对应配置的压缩包，方便快捷。如图：

EasyMR在对Kerberos和Ldap应用基本的部署、服务管理、服务监控等基础功能外，增加了对Ldap用户信息的管理，拥有了用户信息查看，用户或用户组信息过滤，用户信息新增、修改用户信息等功能。

使用者在EasyMR页面可以直接通过内嵌LDAP连接或者新增lDAP连接查看Ldap用户信息。以及可以通过用户过滤以及组过滤的方式，查看过滤后的用户信息以及组下的所有用户信息。

此外，EasyMR还新增了对Kerberos用户和用户票据的管理功能。在管理了Ldap服务后，使用者在Ldap中新增一个用户，EasyMR内部会在Kerberos中同步创建一个Kerberos用户。对于使用者来说，Kerberos用户信息与Ldap用户属于对应关系。Kerberos用户创建完成后，EasyMR会调用KDC服务对此用户进行票据信息的生成。使用者可以在此界面直接下在票据信息，无需再到服务器上连接KDC服务生成票据以及下载票据。

在EasyMR服务管理界面，用户可以直接通过Ranger Admin服务提供的web链接信息跳转到对应的web ui界面，对Ldap用户进行服务权限以及数据权限分配管理。

EasyMR安全能力规划

数据安全随着数字经济的发展以及越来越多企业开始数字化转型变得越来越重要，对于企业来说，有着“牵一发而动全身”的效应。

作为国产自主研发的大数据基础平台，在现有的安全管控能力基础上，EasyMR接下来还将丰富对大数据集群的管理能力，持续优化安全管理的便捷性与通用型。

在当前安全管控能力优化增强的基础上，EasyMR将持续增加KMS、SSL等一站式服务权限管理能力，保障大数据集群的服务安全、用户统一维护、权限统一管理。未来，EasyMR将会持续丰富大数据集群安全防控，以保障用户任务运行在安全高效的集群上。

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=szkyzg

添加【小袋鼠：dtstack001】入qun，免费获取大数据&开源干货

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术qun」，交流最新开源技术信息，qun号码：，项目地址：https://github.com/DTStack

KCL 团队很高兴地宣布 0.4.4 版本现在已经可用！本次发布主要为 KCL 语言增加了自定义 YAML Manifests 输出的能力，用户可以通过编写代码并调用系统函数来自定义 YAML 输出的样式而无需理解复杂的 schema settings 语义；此外本次发布提供了最新的 KCL Python SDK 可用于 Python 用户对 KCL 直接集成；同时我们大大降低了 KCL 安装包的体积，平均安装包体积降低为之前版本的五分之一，并包含多项编译器报错信息优化和 bug 修复。您可以在 KCL 发布页面获得更多详细发布信息和 KCL 二进制下载链接。

背景

KCL 是一个开源的基于约束的记录及函数语言，期望通过成熟的编程语言技术和实践来改进对大量繁杂配置和策略的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简单的逻辑编写，以及更快的自动化集成和良好的生态延展性。

本文将向读者介绍 KCL 社区的近期动态。

新增特性

自定义 YAML 格式输出

在过去的 KCL 版本中，YAML 输出的样式是在 KCL 编译器中是硬编码的，用户可以为 schema 的属性设置为不同的值来决定 YAML 输出样式，这带来了较高的复杂度和记忆成本，因此在 0.4.4 版本中我们提供了一个系统库函数用于开发人员更简单地自定义 YAML 输出样式，这个函数的签名如下：

这个函数的功能是将 KCL 对象列表序列化为带分隔符的样式 YAML 输出，它具有两个参数:

– 一个 KCL 对象列表
– YAML 序列化选项
- ：是否按属性名称的字典序对序列化结果进行排序（默认为）。
- ：是否忽略名称以开头的属性序列化输出（默认为）。
- ：是否忽略值为的属性（默认为）。
- ：在多个 YAML 文档之间选择怎样的分隔符（默认为）。

下面我们通过一个例子来说明:

首先我们通过关键字导入模块并定义 2 个 Deployment 以及 2 个 Service 资源，当我们想以 YAML stream 并以作为分隔符的格式依次输出这 4 个资源时，我们可以将它们合并为一个 KCL 列表并作为函数的形参进行传入 (如无特殊需求，opts 参数一般使用默认值即可)，最终得到 YAML 输出为:

更多信息请参阅：https://github.com/KusionStack/KCLVM/issues/94

Python SDK

除了已有的 KCL Go SDK, 本次发布还新增了 KCL Python SDK，使用 Python SDK 要求您本地具备高于 3.7.3 的 Python 版本和 pip 包管理工具，可以通过如下命令进行安装并获得帮助信息

命令行工具

编写名为的 KCL 文件:

执行如下命令并获得输出:

API

此外，我们还可以通过 Python 代码实现对 KCL 文件的执行

编写名为的 python 文件:

执行如下命令并获得输出:

可以看出通过命令行工具和 API 可以获得同样的输出。

目前 KCL Python SDK 还处于早期预览版本，后续 KCL 团队会持续更新并提供更丰富的功能，更多信息请参阅：https://github.com/KusionStack/kclvm-py

安装体积优化

在新的 KCL 版本中，我们将 KCL 内置的 Python3 剥离，使得 KCL 二进制压缩包的体积从平均 200M 降低为 35M，用户可以更快地下载并使用 KCL，并且 Python Plugin 成为一个可选项，如果您想启用 KCL Python 插件，一个额外要求是需要您本地具备高于 3.7.3 版本的 Python 以及 pip 包管理工具，更多详情请参考 https://github.com/KusionStack/kcl-plugin

错误修复

函数调用错误信息优化

在 0.4.4 版本中，KCL 优化了当函数参数个数不匹配时的错误信息输出，支持显示函数名称以及参数不匹配个数

更多信息请参阅：https://github.com/KusionStack/KCLVM/issues/299

插值三引号字符串格式化错误修复

在之前的 KCL 版本中，对如下代码进行格式化会错误将携带字符串插值的三引号格式化为单引号字符串并导致编译错误，在 0.4.4 版本中我们进行了修复

Copy

更多信息请参阅：https://github.com/KusionStack/KCLVM/issues/294

其他错误修复

更多错误修复详见：https://github.com/KusionStack/KCLVM/milestone/2?closed=1

文档

KCL 网站初步建立，并完善 Kubernetes 场景相关文档.

更多网站信息详见 https://kcl-lang.github.io/

社区动态

KCL 社区新增三名外部贡献者 @my-vegetable-has-exploded, @possible-fqz, @orangebees, 感谢他们热情并积极地参与贡献

下一步计划

预计 2023 年 1 月底，我们将发布 KCL v0.4.5 版本，预期重点演进包括

语言用户界面持续优化，体验持续提升和用户痛点解决
更多场景和生态如 Kubernetes 和 CI/CD Pipeline 场景 KCL 支持和文档更新
KCL Windows 版本支持
KCL 包管理工具 kpm 发布
KCL 新版 playground 支持

更多详情请参考 KCL v0.4.5 Milestone

常见问题及解答

常见问题及解答详见：https://kcl-lang.github.io/docs/user_docs/support/

其他资源

KCL 网站
Kusion 网站
KCL 仓库
Kusion 仓库
Konfig 仓库

欢迎加入我们的社区进行交流 👏👏👏：https://github.com/KusionStack/community

HummerRisk v0.6.0 已经发布，云原生安全检测平台

此版本更新内容包括：

快速开始

仅需两步快速安装 HummerRisk：

准备一台不小于 4 核 8 G 内存的 64位 Linux 主机；
以 root 用户执行如下命令一键安装 HummerRisk。

如果您已经部署旧版本，可通过如下命令一键升级至最新版本:

产品文档

完整文档查看完整的安装和使用文档

更新内容

” 新功能 Features”

feat（所有列表）：新增表头高级搜索功能，新增下载列表为 Excel 功能，新增列表展示与隐藏某些字段功能。
feat（对象存储）：新增对象存储七牛云与青云类型，根据云账号，同步存储桶信息，并可以上传下载存储对象，风险检测存储桶。
feat（操作审计）：新增操作审计火山引擎（火山云）类型，根据火山账号，同步操作审计数据，进而进行事件分析与聚合查询。

” 性能优化 Optimization”

refactor（主机管理）：优化主机一键校验和单个校验，实时修改状态刷新页面。
refactor（主机检测）：限制连接状态无效的主机不能一键检测。
refactor（K8s 管理）：优化 K8s 账号校验立刻刷新页面，加提示。无效状态的账号无法执行检测。
refactor（参数设置）：优化离线上传漏洞库，自动解压到指定目录。
refactor（资源态势）：优化 K8s 资源拓扑图，添加清理选中项按钮，风险镜像颜色随风险改变。
refactor（邮件设置）：优化邮件设置，端口号限制输入数字，并且大小限制 0-65535。
refactor（SBOM 分析）：优化 SBOM 分析只显示最新记录，不显示历史记录。
refactor（操作审计）：优化事件同步时加入时间范围限制，新增最近两周快捷选择。

” Bug修复 Bug Fixes”

fix (K8s 检测）：解决 K8s 检测报错问题。
fix（消息通知）：解决消息通知空指针报错问题和线程池堵塞问题。
fix（合规报告）：修复云资源合规报告数据不准确的问题。
fix（主机检测）：解决主机检测失败报错，一键校验卡顿的问题。
fix（主机管理）：修复对已经保存的主机，修改分组信息，保存后没有生效的问题。新增主机分组列。
fix（部署检测）：修复部署检测日志翻译问题。
fix（SBOM 分析）：修复 SBOM 分析列表最后一行展示被遮挡问题。
fix（资源态势）：修复 K8s 资源拓扑图，命名空间视角数量不正确的问题。
fix（镜像管理）：修复镜像管理编辑页面，手动改绑定镜像时报错问题。
fix（多云管理）：解决 OpenStack 账号校验失败的问题。
fix（检测规则）：解决云资源检测规则切换标签后搜索标签失效的问题。
fix（操作审计）：解决火山云区域同步数据数量重复问题。
fix（检测结果）：解决资源详情数量校准问题，检测结果跳转检测详情列表，区域等信息跟着过滤的问题，详情列表字段宽度显示的问题。

离线安装包

百度网盘下载链接: https://sigusoft.com/s/1LeDx5hF_RkkpO8HcsYUDAQ 提取码: 4ljt 网站资源下载链接: https://docs.hummerrisk.com/about/download/

详情查看：https://gitee.com/hummercloud/HummerRisk/releases/v0.6.0

漏洞描述

js-libp2p 是 libp2p networking stack 的 JavaScript 实现，用于运行网络应用程序。

js-libp2p 0.38.0之前的版本中由于缺少对连接的协议流有效限制，并且 fetch 协议的实现中没有在接收响应后关闭流，攻击者可通过针对 libp2p 的连接、流和内存管理进行大量请求分配大量内存，从而导致 libp2p 进行消耗大量系统资源从而造成拒绝服务。

漏洞名称 js-libp2p <0.38.0 存在拒绝服务漏洞漏洞类型拒绝服务发现时间 2022-12-08 漏洞影响广度极小 MPS编号 MPS-2022-1914 CVE编号 CVE-2022-23487 CNVD编号 –

影响范围

libp2p@(-∞, 0.38.0)

修复方案

升级libp2p到 0.38.0 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1914

https://nvd.nist.gov/vuln/detail/CVE-2022-23487

https://github.com/libp2p/js-libp2p/security/advisories/GHSA-f44q-634c-jvwv

https://github.com/libp2p/js-libp2p/pull/1255

https://github.com/libp2p/js-libp2p/pull/1255/commits/0a6dedeff922fbd4770f2ae63b7

https://github.com/libp2p/js-libp2p/pull/1255/commits/d18ae0cd9ea2ab74e47b69a86241b37c8b7b08d9

https://github.com/libp2p/js-libp2p/pull/1255/commits/a20e9d0bb58bc67d5f3c6c131d8f4a7cdb3a63d1

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

rust-libp2p 是 libp2p networking stack 的 rust 实现，用于运行网络应用程序。

rust-libp2p 0.45.1 之前版本中由于没有对连接流进行有效限制，攻击者可向基于 libp2p 的网络节点的连接中不断打开新流，网络节点由于分配大量小的内存块导致进程的内存不足，从而造成拒绝服务。

通过设置严格的每个连接流限制和连接限制并不能完全解决此问题，攻击者仍可在各种协议级别上发送恶意载荷来引起内存分配，建议用户更新 rust-libp2p 至 0.45.1 及更高版本。

漏洞名称 rust-libp2p <0.45.1 存在拒绝服务漏洞漏洞类型拒绝服务发现时间 2022-12-08 漏洞影响广度极小 MPS编号 MPS-2022-1913 CVE编号 CVE-2022-23486 CNVD编号 –

影响范围

修复方案

参考链接

https://www.oscs1024.com/hd/MPS-2022-1913

https://nvd.nist.gov/vuln/detail/CVE-2022-23486

https://github.com/libp2p/rust-libp2p/commit/5cb4886ab264ef0e70245c666d4fdc9afe059efa

https://github.com/libp2p/rust-libp2p/commit/2acbb457cde137cb3a1f4fb2a8b8556e2f2a86f4

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

PaddlePaddle 是一个开源的深度学习平台。

PaddlePaddle 2.4之前版本中的 gather_tree 函数实现中缺少对 ids_dims 参数大小的验证，如果本地攻击者传入的 ids 形状无效，将会导致内存越界读取，攻击者可利用此漏洞造成获取 Paddle 平台敏感数据信息或造成拒绝服务。

漏洞名称 PaddlePaddle <2.4 存在越界读取漏洞漏洞类型跨界内存读发现时间 2022-12-08 漏洞影响广度极小 MPS编号 MPS-2022-67098 CVE编号 CVE-2022-46741 CNVD编号 –

影响范围

paddlepaddle@(-∞, 2.4.0)

修复方案

升级paddlepaddle到 2.4.0 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-67098

https://nvd.nist.gov/vuln/detail/CVE-2022-46741

https://github.com/PaddlePaddle/Paddle/blob/develop/security/advisory/pdsa-2022-001.md

https://github.com/PaddlePaddle/Paddle/commit/ee6e6d511f9f33fc862cfb5abb99ed94

情报订阅

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

华仔 AutoJs 工具箱_Web端 V1.6.0 已经发布

此版本更新内容包括：

一、布局分析 1、树结构支持左右滚动。 2、绘制节点显示顺序调整，按照节点深度排序，鼠标移入，优先框选深层节点。 3、增加绘制背景图开关，可隐藏背景图只显示节点绘制情况。 4、增加只显示屏幕内节点开关。 5、绘制节点框，增加右键取消勾选当前框选节点。 6、增加布局分析范围，支持选择活跃窗口或全部窗口。 7、增加自定义函数过滤，更为灵活的过滤节点数据。 8、增加常见自定义函数过滤。二、远程脚本 1、增加一键远程执行功能 2、增加App模块、Device模块、Other模块的内置脚本三、其他 1、vue组件化拆分，抽离html、css、js文件。 2、按钮风格统一 3、增加消息通知，配置文件配置邮箱接收上线通知。

详情查看：https://gitee.com/zjh336/hz_autojs_toolbox_web/releases/V1.6.0

Vivaldi 近日正式发布了 Vivaldi 5.6，新版本中集成了 Mastodon、内置了新的搜索引擎，以及大幅改进了设置页面，提升了便利性。

Vivaldi 5.6 的具体更新内容如下：

Mastodon

几乎所有知名的社交媒体网络都由大公司控制。像 Mastodon 这样的平台，一个基于开放标准的分布式社交媒体网络，有助于打破控制。

Vivaldi 5.6 已经加入了 Mastodon 网络，有了自己的实例（服务器），即 Vivaldi Social，这是一个替代方案，可以帮助你重新控制你的新闻提要。

Vivaldi 将 Mastodon 整合到了 Panel（侧边栏）中，你可以与 Mastodon 上的任何人交流，无论他们是否使用 Vivaldi。此外，你可以把你选择的任何 Mastodon 实例作为 Web 面板添加到这个侧边栏，创建一个分屏视图。

Tab Stack

只需右击 Tab Stack（标签组），从上下文菜单中选择钉住（Pin）选项，就可以释放整个标签栏上的空间。

无论你喜欢如何使用 Tab Stack，你都可以钉住 Tab Stack —— 无论是以两行（两级标签堆栈）、手风琴式还是紧凑式打开。

新的搜索引擎

因为 Vivaldi 的用户普遍都喜欢使用对隐私友好的搜索引擎，因此新版本 Vivaldi 增加了一个新的搜索引擎。

You.com 现在已经集成在 Vivaldi 的默认搜索引擎列表中。只不过目前 You.com 只对包括美国、德国、英国和加拿大等国家的 Vivaldi 用户可用。

新的图标

设置页面已经改头换面了，每一个类别都有不同的颜色做区分，并更新了大量的功能图标。对用户而言，也更容易、更迅速地发现你想要调整的功能（作为可选项，用户也可以禁用这些）。

其他更新内容

[Chromium] 升级到 108.0.5359.105

macOS

macOS[macOS] 设置窗口控制在全屏下无法访问
[macOS] 窗口控制按钮在缩小的用户界面中无法访问
[macOS][更新] 将 Sparkle 库更新到 2.3.0

Linux

[Linux] 修改 “Media Support” 对话框中的措辞
[Linux][媒体] 将专有编解码器改为 108.0.5327.0-
[Linux][Wayland] 提供给窗口管理器的空白 app_id

Windows

[Windows] 在 Windows 10 上从打开一个从浏览器中拖动的链接时，会提示安全警报
[Windows][媒体] 在全屏视频中时，有一个带有圆角的透明小边框

更多详情可查看：https://vivaldi.com/new/

Conan 是一个去中心化、开源的 C/C++ 包管理器。适用于所有平台，包括 Linux、macOS、Windows、Solaris、FreeBSD、Docker、WSL 等。它可以为任何配置和平台创建、上传和下载二进制文件，甚至交叉编译，节省大量的开发和持续集成时间。

Conan 1.55 正式发布，更新内容如下：

特性：

为 AutotoolsToolchain 增加前缀参数
新的生成器
通过和实现环境变量
在 settings.yml 中添加 gcc 12.1 和 12.2
增加配置，以便在 CMakeToolchain、MesonToolchain 和 AutoToolsToolchain 中设置编译器变量
允许在 EnvVars 中使用占位符
新的 NMakeToolchain
在 CMakeToolchain 中的 PKG_CONFIG_PATH 环境变量中添加了生成器文件夹
确保 CMakeToolchain 将强制使用 tools.gnu:pkg_config 配置中设置的 pkg-config 可执行文件
在 CMake build helper configure 方法中增加 cli_args 参数
在 Autotools.install() 方法中添加目标参数
增加的读取属性
自动将所在的 msys2 文件夹添加到 PATH 中
添加 tools.meson.mesontoolchain:extra_machine_files=[“FILENAMES”] 到 Meson build helper 中，以便在 Conan 创建的文件中添加机器文件
在 CMakeToolchain 中添加 .user_presets_path 属性，以自定义 CMakeUserPresets.json 的位置或跳过生成它

修复

如果没有为定义，则会引发一个明确的错误
修复 cmake.test() 的 runenv
删除 CMakeToolchain 中 CMAKE_CXX_COMPILER 的硬编码定义
删除默认 build_type 编译器标志中多余的
在 Autotools build helper 中，优先考虑用户在配方中设置的 -j 参数，而不是 conan 的默认设置
不要在 Bazel BUILD 文件中包括构建环境的依赖
如果一个软件包被要求从给定配置的源码构建，则不要回退到一个兼容的二进制文件
修复可编辑模式下的时的问题

更多详情可查看：https://docs.conan.io/en/latest/changelog.html

Kali Linux 是一份基于 Debian 的发行，它带有一套安全和计算机取证工具，其特色在于及时的安全更新、对 ARM 架构的支持、有四种流行的桌面环境供选择，以及能平滑升级到新版本。

目前 Kali Linux 发布了 2022.4 版本，这是本年度最后一个版本，带来了更多平台支持和更多安全相关的工具包。

新内容

Microsoft Azure – Kali 已添加到 Microsoft Azure，但目前没有图形用户界面，也没有预装任何工具。
更多平台– 新增 Generic Cloud、QEMU VM 映像和 Vagrant libvirt
Kali NetHunter Pro – 在手机（PinePhone / Pro）上首次发布 Kali Linux
Kali NetHunter – 内部蓝牙支持、内核移植视频、固件更新和其他改进
桌面更新– 升级到 GNOME 43 和 KDE 5.26，GNOME 43 预览：

此外，新版本还添加了各种新的工具包：

bloodhound.py – 用于 BloodHound 的基于 Python 的摄取器
certipy – 用于 Active Directory 证书服务枚举和滥用的工具
hak5-wifi-coconut – USB Wi-Fi NIC 和 Hak5 Wi-Fi Coconut 的用户空间驱动程序
ldapdomaindump – 通过 LDAP 的 Active Directory 信息转储器
peass-ng – 适用于 Windows、Linux/Unix* 和 MacOS 的权限升级工具。
rizin-cutter – 由 rizin 提供支持的逆向工程平台

Kali ARM 更新

Kali 已添加到 Raspberry Pi Imager ( )，此外还附有快速指南。

其他修复项和杂项可查看更新公告。

下载地址

Go 1.19.3 和 1.18.8 已发布。这些次要版本包括 2 个遵循安全策略的安全修复程序：

os, net/http：避免在 Windows 上从 os.DirFS 和 http.Dir 转义

os.DirFS 函数和 http.Dir 类型提供对以给定目录为根的文件树的访问。这些函数允许访问该根目录下的 Windows 设备文件。例如，os.DirFS(“C:/tmp”).Open(“COM1”) 将打开 COM1 设备。 os.DirFS 和 http.Dir 都只提供只读文件系统访问。

但在 Windows 上，目录（当前驱动器的根）的 os.DirFS 可以允许恶意制作的路径从驱动器中逃逸，并访问系统上的任何路径。os.DirFS(“”) 的行为已经改变。以前，空根被视为等同于“/”，因此 os.DirFS(“”).Open(“tmp”) 将打开路径“/tmp”，现在则返回一个错误。

这是 CVE-2022-41720 和 Go issue https://go.dev/issue/56694

net/http：按字节限制规范标头缓存，而不是条目

攻击者可以在接受 HTTP/2 请求的 Go 服务器中导致内存过度增长。

HTTP/2 服务器连接包含客户端发送的 HTTP 标头密钥的缓存。虽然此缓存中的条目总数有上限，但攻击者发送非常大的密钥，可能会导致服务器为每个打开的连接分配大约 64 MiB。

此问题也在 golang.org/x/net/http2 vX.Y.Z 中修复，供用户手动配置 HTTP/2。

这是 CVE-2022-41717 和 Go issue https://go.dev/issue/56350。

Go 1.19.4 还包含其他修复项，详细可在 Milestone 中查阅。

Go 1.18.9 的其他细项查看对应的 Milestone 。

PHP 开发团队宣布了 PHP 8.2.0 的立即可用，这是 PHP 语言的最新次要版本。

PHP 8.2 带来了许多改进和新功能，例如：

只读类 (Readonly classes)

将一个类标记为只读会给每个声明的属性添加只读修饰符，并阻止动态属性的创建。此外，不可能通过使用 AllowDynamicProperties 属性来增加对它们的支持。试图这样做将触发一个编译时错误。

 <?php #[AllowDynamicProperties] readonly class Foo { } // Fatal error: Cannot apply #[AllowDynamicProperties] to readonly class Foo ?>

当且仅当子类也是一个只读类的时候，一个只读类可以被扩展。

析取范式 (DNF) 类型
新的独立类型：null、false 和 true
新的“Random”扩展
traits 中的常量
弃用动态属性。动态属性的创建已被弃用，除非该类通过使用属性选择加入。 stdClass允许动态属性。__get()/__set() magic methods 的使用不受此更改的影响。动态属性弃用警告可以通过以下方式解决：
- 声明属性（首选）。
- 将属性添加到类（这也适用于所有子类）。
- 如果需要将额外的数据与一个不属于自己的对象相关联，则使用 WeakMap 。

更多详情可查看 ChangeLog。

下载地址：https://windows.php.net/download/

深度操作系统 20.8 已发布，此版本新增社区自研应用“深度之家”，升级 Qt 至 5.15.6 版本，更新了 DTK 开发库，修复底层漏洞进一步提升系统兼容性和安全性；功能层面上积极响应社区用户反馈的需求，开发并集成了大量实用功能。

镜像下载：https://cdimage.deepin.com/releases/20.8/deepin-desktop-community-20.8-amd64.iso

下面介绍一下新版本的功能：

深度之家

新增社区自研信息聚合型应用“深度之家”，V1.0.0 阶段实现了对社区GitHub、Wiki、论坛、自媒体等重要信息平台的聚合，支持deepin ID 账户体系登录和基础消息推送能力。在这里，你可以实时接收到社区消息，进行互动交流、参与问卷调查等。未来我们将建立完善的需求、BUG追踪体系，以及·针对软件、硬件的专项反馈渠道，更好地为社区用户提供服务。

应用商店

提升了Wine应用下载完成后的开启速度，优化应用更新及应用管理页面视觉效果，支持应用详情页评论复制与粘贴，带来更好的下载使用体验。

文件管理

功能上进一步优化，新增光盘目录下将文件保存为镜像文件，支持右键菜单直接进行外设重命名与格式化，支持生成图片轮播屏保，让文件管理更加“智能”。

更新及优化

升级Qt至5.15.6版本
更新了DTK开发库
优化了汇顶科技相关指纹设备解锁慢的问题
系统仓库新增社区自研应用“深度之家”
对版本标识进行了变更，变更为20.8
系统启动图标替换为动态图标

内核

系统集成UTCS，未来可在安装阶段对N卡设备自动扫描，并安装合适的驱动
LTS内核升级至5.15.77版本
新增集成nvidia-driver-510、nvidia-graphics-drivers-470、nvidia-graphics-drivers-390N卡驱动包

应用商店

Wine应用下载过程中即在商店进行解压，提升了应用下载完成后的开启速度
优化应用更新和应用管理页面视觉效果
应用详情页评论支持复制
优化应用商店窗口在最小窗口尺寸时的自动缩放能力

文件管理

对系统监视器中的桌面进程图标进行了替换
“隐藏系统盘”选项文案调整为“隐藏内置磁盘”
新增光盘目录下文件保存为镜像文件
支持右键菜单直接进行外设重命名与格式化
在文管-设置-挂载增设“合并显示Samba共享目录入口”选项
支持用户指定文件路径，将该路径下满足要求的图片生成图片轮播屏保

邮箱

在邮箱进行搜索结束后，可通过快捷键ESC退出搜索状态
对邮箱通讯录模块进行了整体交互优化

浏览器

对浏览器前进、后退按钮进行了交互优化
书签页展示内容超过显示范围时，支持上下滑功能
浏览器默认项中，对“新标签页打开地址栏输入的网址”默认取消勾选
支持鼠标悬于网页地址内容时，展示对应的链接地址

修复

DDE

修复镜像安装完成后，任务栏与锁屏界面网络图标不显示的问题
修复内测用户在获取更新内容时显示为第三方仓库问题
修复界面WiFi图标展开WiFi列表，使用快捷键Alt+Tab，进入桌面切换正在运行的窗口问题
修复任务栏网络和蓝牙插件列表中没有刷新按钮问题
修复系统待机恢复后，启动器无法正常启动和展示问题

应用商店

修复应用更新和管理页面刷新时，下载管理窗口自动隐藏问题
修复系统语言为波兰语时，“更新”、“一键更新”按钮上的文字显示不全问题
修复应用更新类中，应用详情在英文环境下展示为中文的问题

内核

修复AX1800 WiFi 驱动安装 RTL8832AU RTL8852AU，内核驱动无加载固件问题
修复安装20.7.1发布镜像，使用笔记本自带的网卡时，系统没有无线网络问题
修复Thinkbook 14+笔记本电量低的情况下插电源，屏幕亮度由亮转暗问题
修复部分机型系统未更新用户锁屏待机一段时间后，出现触控板无法使用的情况问题
省去了显卡切换工具，在选用NVIDIA显卡时，对变量环境的操作流程

文件管理器

修复系统升级至新版本，smb收藏的服务器地址被清空问题
修复加密磁盘在文管进行安全移除，需要2次移除才会弹出U盘问题
修复蓝牙文件传输选择蓝牙设备界面，未选择蓝牙设备仍可对下一步按钮进行操作问题

终端

修复终端主题设置为“跟随系统”，会自动变为“深色”问题

字体管理器

修复字体管理器无法使用键盘快捷键正常切换问题

计算器

修复复制显示错误问题（如 0x80e12，带小写字母的16进制数）

设备管理器

修复音频适配器芯片信息显示不全问题

文档查看器

修复部分机型使用文档查看器无法打开附件中的docx文件问题

软件包安装器

修复安装xnview.deb包时，软件包安装器卡死在90%左右问题

文本编辑器

修复系统语言选择波兰语时，在空白处右键“跳到行”功能显示不全问题
修复通过鼠标中键粘贴文本，无法撤销问题
修复查找过程中，代码着色会消失问题
修复文本中含括号时，对文件多次进行删除操作后，不能准确撤回问题
修复打开附件中dtextedit.cpp文件，对代码中括号的匹配不准确问题
修复打开文件默认显示编码格式为WINDOWS-1252，文件显示异常，编码格式改为UTF-16BE显示正常问题
修复更改文本时不经保存直接关闭文本编辑器，再次打开文本使用Ctrl+S保存时，文本编辑器闪退问题
修复文本编辑器打开多个txt文件，静置一段时间后出现卡死情况问题

看图

修复在使用系统看图工具切换及查看图片时，内存消耗持续升高，产生内存泄露问题
修复文字识别功能在使用过程中，需要被截取的图片存在大片留白，否则会导致文字识别准确度低的问题

相册

修复系统语言为“波兰语”时，打开相册，鼠标右键照片，选择“照片信息”，图片信息弹框上文字显示不全问题
修复最近删除中的图片文件被永久删除后，回收站中未物理删除，仍然存在该文件的问题

截图录屏

修复在进行录屏时，右下角未显示时间问题

其它

修复加入内测源后，获取更新显示为第三方仓库问题
修复系统通过应用入口或快捷键无法正常开启帮助手册问题
修复启动器全屏模式下选中应用拖动时，实际拖动为非选中应用问题
修复系统安全漏洞，提升系统安全

更新公告：https://www.deepin.org/zh/deepin-20-8-is-officially-released/

Spring Tools 4.17.0 现已发布。Spring Tools 4 是由 Spring 团队打造的 Spring 开发工具，从零开始构建，融合了现代技术和开发者工具架构。它在单独的进程中运行，从构建之初就考虑到了性能问题，并且支持最新的 Spring 技术，为开发基于 Spring 的企业应用提供世界级支持。同时，全新版本的 Spring Tools 与 IDE 无关，可在各种编码环境中使用，支持 Eclipse、Visual Studio Code 与 Theia。

Spring PyCharm激活2022.3 Tools 4 for Eclipse 发行版的主要变化

更新到 Eclipse 20PyCharm激活2022.322-12 版本（新的和值得注意的）

抢先体验新的实验性功能

在许多错误修复和小改进中，此版本引入了对以下方面的实验性支持：

Spring Boot 版本验证：当有更新的主要版本、次要版本或补丁版本可用于你的 Spring Boot 项目时，IDE 会告诉你
Spring Boot 升级支持：该工具将帮助你将现有项目升级到更新的 Spring Boot 版本，包括升级到更新的补丁和次要版本，以及更新的主要版本（例如升级到 Spring Boot 3）
Spring 特定的验证和重构：该工具将指示是否可以或应该更改源代码中的某些内容，以使你的 Spring 项目与 Spring 中的最新建议或进展保持同步

更多详情可查看 ChangeLog。

下载地址：https://spring.io/tools/

Spring Tools 4.17.1 计划于 2023 年 2 月初发布。

PyCharm激活2022.3(PyCharm 2022.3 正式发布)

用户体验

新的 Settings Sync（设置同步）解决方案

管理 Conda 软件包的新方式

通过设置使用新 PyCharm UI

为 GitHub 和 Space 重新设计了 Review list（审查列表）

改进了 Tips of the Day（每日小技巧）

其他改进：

编辑器

Quick Documentation（快速文档）中的 docstring 呈现改进

意图操作预览默认启用

Python 3.11： 类型的代码洞察 [PEP 673]

其他改进：

针对 Python 控制台的 asyncio 支持

集成式开发者工具

安全性

软件包的漏洞检查器

安装程序

适用于 Windows 和 Linux ARM64 机器的安装程序（测试版）

亮点

值得注意的版本更新

1 CountDownLatch 实现网络同步请求

2 ReadWriteLock 名字服务路由管理

3 CompletableFuture 异步消息处理

安装

一、Vue 在国内的使用量远高于 React / Angular

二、Vue 中文资料多，学习曲线平缓，上手快

三、Vue 是渐进式框架，更轻量，性能高

四、Vue 官方支持的 Web 应用开发工具全面，可持续性好

漏洞描述

影响范围

修复方案

参考链接

情报订阅

新的功能：

软件升级：

漏洞描述

影响范围

修复方案

参考链接

情报订阅

从一个线上问题说起

初步分析

解决办法

方案一：去除对的优先级设置

方案二：临时修改线程优先级

Demo 验证

上线效果

深刻理解优先级反转

什么是优先级反转？

Bounded priority inversion

Unbounded priority inversion

优先级反转常规解决思路

Priority ceiling protocol

Priority inheritance

如何避免优先级反转？

QoS 传递

如何触发优先级反转避免机制？

基础API验证

pthread mutex

os_unfair_lock

pthread_rwlock_t

dispatch_sync

dispatch_wait

神秘的信号量

信号量卡死现身说法

几个概念

turnstile

优先级数值

总结

加入我们

参考文档

#01

背景介绍

#02

OLAP 建设历程

#03

StarRocks 典型应用场景介绍

#04

未来规划

Python 3.11：类型的代码洞察 [PEP 673]

4.12.5 – 正式版更新详情: