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

情报订阅

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

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：设置允许的最大活跃并发数，当前活跃会话数大于最大活跃会话数时，会将会话数清理到小于最大活跃会话数。

设置界面如下：

PhpStorm激活2022.3.1(PhpStorm 2022.3 发布，带来完整的 PHP 8.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社区会员招募正在火热进行中，欢迎更多企业伙伴加入，携手共建，打造桌面操作系统顶级社区，推动国产操作系统产业生态健康发展。详情可查看：【https://sigusoft.com/s/yk82DEQSG0knaQNKyc-vsg 】

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

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

审核：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

谢谢你读完本文 (///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能，留下「你的名片」一起玩耍呀~

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 数据库，帮助企业建立“极速统一”的数据分析新范式，助力企业全面数字化经营。

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

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 Tools 4 for Eclipse 发行版的主要变化

更新到 Eclipse 2022-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 月初发布。

Eclipse 4.26 (2022-12) 已正式发布。

Eclipse 下载地址
https://download.eclipse.org/eclipse/downloads/drops4/R-4.26-0/
更新内容
https://www.eclipse.org/eclipse/news/4.26/
升级已有安装版本（不要在生产环境进行）
https://download.eclipse.org/eclipse/updates/4.26/
Specific repository good for building against
https://download.eclipse.org/eclipse/updates/4.26/R-4.26-0/
Equinox 相关下载
https://download.eclipse.org/equinox/drops/R-4.26-0/

更新亮点

支持 Java 19

JDK 19 / Java 19 已正式 GA。Eclipse JDT 在 4.26 中为 Java 19 提供了支持。

该版本支持以下 Java 19 特性：

JEP 405: Record Patterns (Preview).
JEP 427: Pattern Matching for Switch (Third Preview).
JEP 425: Virtual Threads (Preview).
JEP 428: Structured Concurrency (Incubator).

请注意，上面这些 Java 19 特性仍处于预览阶段。

引入新的用于 class 的帮助功能

改进“提取局部变量”

Refactor > Extract Local Variable 中提供的提取局部变量重构已得到改进，可以识别添加局部变量可能导致 NullPointerException 的情况，因为它位于用于检查 null 的代码之前。在这些情况下，局部变量的定位被改变，因此空值检查发生在变量声明之前。

例如，在下面的类中，在验证 String 变量不为 null 之后调用 String length() 方法。

如果我们选择 s.length() 调用并选择将其提取到局部变量以替换所有出现的地方，结果是：

详情点此查看。

作者：乔中沛（伊灵）

背景

OpenYurt 与 KubeVela 结合能解决什么问题？

而 KubeVela 在应用层与 OpenYurt 可以很好的互补，满足上述三个核心需求。接下来，我们结合实际的操作流程来展示这些功能点。

将应用部署到边缘

Demo 的基础环境

我们将使用 Kubernetes 集群模拟边缘场景。群集有 3 个节点，它们的角色分别是：

节点 1：master 节点，云端节点
节点 2：worker 节点，边缘节点，在节点池中
节点 3：worker 节点，边缘节点，在节点池中

准备工作

1. 安装 YurtAppManager

YurtAppManager 是 OpenYurt 的核心组件。它提供节点池 CRD 和控制器。OpenYurt 中还有其他组件，但在本教程中我们只需要 YurtAppManager.

2.安装KubeVela，启用 FluxCD 插件。

安装 Vela 命令行工具，并在集群中安装 KubeVela。

3. 准备节点池

将边缘节点加入到各自的节点池，边缘节点的加入方式可以参考 OpenYurt 节点加入的方式。

预期输出

批量部署边缘应用

一个 KubeVela Application 有 3 个部分：

一个类型组件。它描述了我们想要安装到集群的 Helm 包版本。此外，我们给这个组件附加了一个运维特征（trait）。我们稍后将展示这个运维特征的具体情况，现在你可以将其视为一个包含不同节点池的属性的补丁。
一个（组件分裂）策略。它描述了如何将组件复制到不同的节点池。该字段用于选择需要复制的组件。它的字段将把一个组件转换为具有不同 key 的两个组件。（“beijing”和“shanghai”）

3. 工作流步骤。它描述了如何部署应用程序。它指定策略执行复制工作的策略。

注意：

如果你希望此应用程序正常工作，请先在集群下发在下文介绍的特性。

是一个 KubeVela 内置的工作流程步骤。它还可以在多集群场景 [2 ] 中与、策略一起使用。

现在，我们可以将应用下发到集群。

检查应用状态和 KubeVela 创建的资源。

预期输出

如果你想更直观地了解应用去情况，KubeVela 官方还提供了 Web 控制台插件 VelaUX。启用 VelaUX 插件 [3 ] ，你可以查看更详细的资源拓扑。

访问 VelaUX 的资源拓扑页面。

差异化部署

组件分裂 Policy 将组件拆为两个组件，带有不同的。
Trait 使用不同的，将带有不同配置值的 Helm Chart 交付到集群中。让两个 Nginx Ingress Controller 运行在不同的节点池，监听具有不同 ingressClass 的 Ingress 资源。具体的方式是 Patch 了 Helm Chart 的 Values 配置，修改了和节点选择、亲和性以及 ingressClass 相关的字段。
在 Patch 不同字段时，使用了不同的 Patch 策略 [4 ] （PatchStrategy），例如使用策略能够覆盖原本的值，使用策略则会和原本的值合并。

让更多类型的应用走向边缘

如果我们无法预知未来边缘计算的发展带来的更多应用部署需求，至少我们可以通过这种更容易扩展的方式不断适应新的场景。

KubeVela 如何解决了边缘部署难题

回顾 KubeVela 是如何解决文章开始提出的关键问题的。

1. 统一配置： 我们使用一个组件来描述要部署的 ingress-nginx Helm Chart 的通用的属性例如 Helm 仓库、Chart 名称、版本等统一配置。

您也可以通过如下材料了解更多关于 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

关注公众号

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

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

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

如今的各大浏览器为了改善资源占用，都已经内置了标签页休眠功能，其目的就是把不活跃的标签页置于休眠状态，从而节省内存并释放计算机的资源。这个功能对于那些动则打开几十个甚至近百个标签页的用户来说非常有用。

那么这个功能带来的具体效果到底如何，为用户释放了多少计算资源呢？如今微软就公布了他们所统计到的最新数据。

微软自 Edge 105 以来就为浏览器加入了标签页休眠功能，当设备的内存占用接近极限时，就会自动休眠资源占用高的不活跃标签页。根据微软最新统计（统计的 9 月份数据），单单在这一个月，Edge 浏览器就成功地将 13.8 亿个不活跃的标签页置于休眠状态，以减轻对 Windows 设备内存的压力。微软表示，以这种方式休眠标签页，平均可以节省 83% 的内存。

在今年 6 月份的时候，微软 Edge 官方也曾公布过一次统计数据（如下图）。

在过去的 28 天里，我们在 Windows 设备上休眠了 60 亿个标签页，节省了 273.7PB 的内存，平均每个标签页节省 39.1MB 内存。

以 6 月份的 60 亿个标签页的统计总量来看，每个标签页节省 39.1MB 的这个平均值还是十分具有参考价值的。因此将最新的 9 月份休眠 13.8 亿个标签页的数据量带入计算公式，“掐指一算” 我们可以得出微软 Edge 浏览器在当月节省下的内存大约为 54PB。

考虑到目前 Edge 浏览器的市场份额只有不到 4.5%，而 Chrome 的市场份额达到了 65.8%，两者在市场份额上有 15 倍的差距，虽然 Google 并没有公布节省了多少内存这样的数据，但我们也可以想象到这个数字会有多大。

FortiGuard Labs 最新发布的一份研究指出，研究人员在 11 月观察到了一个用 Go 语言编写的独特僵尸网络正在通过 IoT 漏洞进行传播。这个被称为 Zerobot 的僵尸网络包含多个模块，包括自我复制、针对不同协议的攻击和自我传播；还使用 WebSocket 协议与其命令和控制服务器通信。它主要针对 Linux 操作系统，以控制易受攻击的设备。

根据介绍，Zerobot 的目的是将受感染的设备添加到分布式拒绝服务 (DDoS) 僵尸网络中，以对指定目标发起强大的攻击。可以扫描网络并自我传播到邻近的设备，以及在 Windows (CMD) 或 Linux (Bash) 上运行命令。

Zerobot 有两个版本，11 月 24 日之前使用的第一个只包含基本功能，随后出现的新版本则包含额外的模块和针对新漏洞的漏洞利用。这一行为表明，该恶意软件正在积极开发中。

Zerobot 整合了对 21 个漏洞的利用，并利用这些漏洞获得对设备的访问；然后下载脚本以进一步传播。它使用文件名”zero,”进行保存，这也是其命名的由来。影响范围涵盖 F5 BIG-IP、Zyxel 防火墙、Totolink 和 D-Link 路由器以及 Hikvision cameras 等。除了一些物联网漏洞外，还包括 Spring4Shell、phpAdmin、F5 Big 等，以提高其成功率。

它可以针对一系列系统架构和设备，包括 i386、AMD64、ARM、ARM64、MIPS、MIPS64、MIPS64le、MIPSle、PPC64、PPC64le、RISC64 和 S390x。

当前下载脚本

Zerobot 中的漏洞利用列表

Zerobot 攻击的易受攻击的设备

此外，僵尸网络还使用了四个未分配标识符的漏洞。其中两个针对 GPON 终端和 D-Link 路由器。关于另外两个的细节目前还不清楚。

在受感染的设备上建立存在后，Zerobot 会设置到命令和控制 (C2) 服务器的 WebSocket 连接，并发送有关受害者的一些基本信息。C2 可能会响应以下命令之一：“ping”、“attack”、“stop”、“update”、“kill”、“disable_scan”、“enable_scan’”和“command”。

该恶意软件还使用一个“anti-kill”模块，旨在防止终止或杀死其进程的。目前，Zerobot 主要专注于发起 DDoS 攻击，但是它也可以用作 initial access。

Fortinet 总结称，Zerobot 是一种用 Go 编程语言编写的新型僵尸网络，通过 WebSocket 协议进行通信。自 11 月 18 日首次出现以来，Zerobot 开发人员已通过字符串混淆、复制文件模块、自我传播模块和几个新的漏洞进行了改进，使其更难检测并赋予它感染更多设备的更高能力。用户应该意识到这一新威胁，并在补丁可用时积极应用补丁。

据介绍，GCC Rust 补丁基于上游 GNU Compiler Collection 代码库重新编写，并为新的前端设置了布局骨架，还为 i386 和 ARM 提供初始 target hook，然后开始布局前端代码。此外，GCC 编译器支持的目标 (targets) 数量要远远多于标准的 Rust 编译器。

通过将 GCC 作为后端集成到 rustc 中，可以更好地实现支持这些 target。除了 LLVM 之外，rustc master 还为 Cranelift（更快的调试编译）和 GCC（访问不支持 LLVM 的架构）提供了开发中的后端。

开发者 Arthur Cohen 表示 Gccrs 仍处于实验性阶段，在发布之前会进行大量更改。

GCC Rust 的代码仍然需要更仔细的审查。按照计划，它有可能作为 GCC 13 的一部分而亮相，GCC 13 将于 2023 年 4 月左右发布稳定版，其对 Rust 语言的支持有希望达到 beta 级别。

点此查看更多内容。

hello，大家好，我是张张，「架构精进之路」公号作者。

在MySQL 中我们经常会接触到三个核心日志，它们分别是：binlog 、redo log、undo log。

好多同学对于它们可能并不陌生，但是具体区分起来各自的功能用途以及实现原理，那可能认知就会比较模糊了，今天就跟大家一起，来清晰明了的介绍一下这些日志的核心思想和功能原理。

1 binlog

1.1 binlog 设计目标

binlog 记录了对MySQL数据库执行更改的所有的写操作，包括所有对数据库的数据、表结构、索引等等变更的操作。

注意：这其中不包含SELECT、SHOW等，因为对数据没有修改

只要是对数据库有变更的操作都会记录到binlog里面来，我们可以把数据库的数据看做银行账户里的余额，而binlog就相当于我们银行卡的流水记录。账户余额只是一个结果，至于这个结果怎么来的，那就必须得看流水了。

在实际应用中， binlog 的主要应用场景分别是 主从复制 和 数据恢复。

主从复制 ：在 Master 端开启 binlog ，然后将 binlog 发送到各个 Slave 端， Slave 端重放 binlog 来达到主从数据一致。
数据恢复 ：通过使用 mysqlbinlog 工具来恢复数据。

1.2 binlog 数据格式

binlog 日志有三种格式，分别为 STATMENT 、 ROW 和 MIXED。

在 MySQL 5.7.7 之前，默认的格式是 STATEMENT ， MySQL 5.7.7 之后，默认值是 ROW。日志格式通过 binlog-format 指定。

ROW：基于行的复制（row-based replication, RBR），不记录每条SQL语句的上下文信息，仅需记录哪条数据被修改了。如果一个update语句修改一百行数据，那么这种模式下就会记录100行对应的记录日志。

优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题；
缺点：会产生大量的日志，尤其是 alter table 的时候会让日志暴涨。

STATMENT：基于SQL语句的复制( statement-based replication, SBR )，每一条会修改数据的SQL语句会记录到 binlog 中。相对于ROW模式，STATEMENT模式下只会记录这个 update 的语句，所以此模式下会非常节省日志空间，也避免着大量的IO操作。

优点：不需要记录每一行的变化，减少了 binlog 日志量，节约了 IO , 从而提高了性能；
缺点：在某些情况下会导致主从数据不一致，比如执行sysdate() 、 slepp() 等。

MIXED：基于 STATMENT 和 ROW 两种模式的混合复制（mixed-based replication, MBR），一般的复制使用 STATEMENT 模式保存 binlog ，对于一些函数，STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog。

基于这三种模式需要注意的是：

1）使用 row 格式的 binlog 时，在进行数据同步或恢复的时候不一致的问题更容易被发现，因为它是基于数据行记录的。

2）使用 mixed 或者 statement 格式的 binlog 时，很多事务操作都是基于SQL逻辑记录，我们都知道一个SQL在不同的时间点执行它们产生的数据变化和影响是不一样的，所以这种情况下，数据同步或恢复的时候就容易出现不一致的情况。

1.3 binlog 写入策略

对于 InnoDB 存储引擎而言，在进行事务的过程中，首先会把binlog 写入到binlog cache中（因为写入到cache中会比较快，一个事务通常会有多个操作，避免每个操作都直接写磁盘导致性能降低），只有在事务提交时才会记录 biglog ，此时记录还在内存中，那么 biglog 是什么时候刷到磁盘中的呢？

MySQL 其实是通过 sync_binlog 参数控制 biglog 的刷盘时机，取值范围是 0-N：

0：每次提交事务binlog不会马上写入到磁盘，而是先写到page cache。不去强制要求，由系统自行判断何时写入磁盘，在Mysql 崩溃的时候会有丢失日志的风险；
1：每次提交事务都会执行 fsync 将 binlog 写入到磁盘；
N：每次提交事务都先写到page cach，只有等到积累了N个事务之后才 fsync 将 binlog 写入到磁盘，在 MySQL 崩溃的时候会有丢失N个事务日志的风险。

很显然三种模式下，sync_binlog=1 是强一致的选择，选择0或者N的情况下在极端情况下就会有丢失日志的风险，具体选择什么模式还是得看系统对于一致性的要求。

2、redo log

2.1 redo log 设计目标

redo log 是属于引擎层(innodb)的日志，称为重做日志 ，当MySQL服务器意外崩溃或者宕机后，保证已经提交的事务持久化到磁盘中（持久性）。

它能保证对于已经COMMIT的事务产生的数据变更，即使是系统宕机崩溃也可以通过它来进行数据重做，达到数据的持久性，一旦事务成功提交后，不会因为异常、宕机而造成数据错误或丢失。

2.2 redo log 数据格式

redo log 包括两部分：

内存中的日志缓冲（redo log buffer）
内存层面，默认16M，通过innodb_log_buffer_size参数可修改
磁盘上的日志文件（redo logfile）
持久化的，磁盘层面

MySQL 每执行一条 DML 语句，先将记录写入 redo log buffer，后续某个时间点再一次性将多个操作记录写到 redo log file。

通常所说的Write-Ahead Log(预先日志持久化)指的是在持久化一个数据页之前，先将内存中相应的日志页持久化。

在计算机操作系统中，用户空间( user space )下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间( kernel space )缓冲区( OS Buffer )。

因此， redo log buffer 写入 redo logfile 实际上是先写入 OS Buffer ，然后再通过系统调用 fsync() 将其刷到 redo log file中，过程如下：

修改数据的操作流程：

先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝，产生脏数据
生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
默认在事务提交后将redo log buffer中的内容刷新到redo log file，对redo log file采用追加写的方式
定期将内存中修改的数据刷新到磁盘中（这里说的是那些还没及时被后台线程刷盘的脏数据）

2.3 关于 redo log 的几点疑惑

读到这里，相必有同学会有如下疑问：

Q1：为什么不直接修改磁盘中的数据？

因为直接修改磁盘数据的话，它是随机IO，修改的数据分布在磁盘中不同的位置，需要来回的查找，所以命中率低，消耗大，而且一个小小的修改就不得不将整个页刷新到磁盘，利用率低；

与之相对的是顺序IO，磁盘的数据分布在磁盘的一块，所以省去了查找的过程，节省寻道时间。

使用后台线程以一定的频率去刷新磁盘可以降低随机IO的频率，增加吞吐量，这是使用buffer pool的根本原因。

Q2：同为操作数据变更的日志，有了binlog为什么还要redo log？

我认为最核心的一点就是两者记录的数据变更粒度是不一样的。

以修改数据为例，binlog 是以表为记录主体，在ROW模式下，binlog保存的表的每行变更记录。

MySQL 是以页为单位进行刷盘的，每一页的数据单位为16K，所以在刷盘的过程中需要把数据刷新到磁盘的多个扇区中去。而把16K数据刷到磁盘的每个扇区里这个过程是无法保证原子性的，如果数据库宕机，那么就可能会造成一部分数据成功，而一部分数据失败的情况。而通过 binlog 这种级别的日志是无法恢复的，因为一个update可能更改了多个磁盘区域的数据，所以这个时候得需要通过redo log这种记录到磁盘数据级别的日志进行数据恢复。

由以上两者的对比可知：binlog 日志只用于归档，只依靠 binlog 是没有 crash-safe 能力的。

同样只有 redo log 也不行，因为 redo log 是 InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要 binlog和 redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。

Q3：redo log一定能保证事务的持久性吗？

不一定，这要根据redo log的刷盘策略决定，因为redo log buffer同样是在内存中，如果提交事务之后，redo log buffer还没来得及将数据刷新到redo log file进行持久化，此时发生宕机照样会丢失数据。

那该如何解决呢？刷盘写入策略。

2.4 redo log 写入策略

当redo log空间满了之后又会从头开始以循环的方式进行覆盖式的写入。MySQL 支持三种将 redo log buffer 写入 redo log file 的时机，可以通过 innodb_flush_log_at_trx_commit 参数配置，各参数含义如下：

0（延迟写）：表示每次事务提交时都只是把 redo log 留在 redo log buffer 中，开启一个后台线程，每1s刷新一次到磁盘中 ;
1（实时写，实时刷）：表示每次事务提交时都将 redo log 直接持久化到磁盘，真正保证数据的持久性；
2（实时写，延迟刷）：表示每次事务提交时都只是把 redo log 写到 page cache，具体的刷盘时机不确定。

除了上面几种机制外，还有其它两种情况会把redo log buffer中的日志刷到磁盘。

定时处理：有线程会定时(每隔 1 秒)把redo log buffer中的数据刷盘。
根据空间处理：redo log buffer 占用到了一定程度( innodb_log_buffer_size 设置的值一半)占，这个时候也会把redo log buffer中的数据刷盘。

3、undo log

3.1 undo log设计目标

redo log 是也属于引擎层(innodb)的日志，从上面的redo log介绍中我们就已经知道了，redo log 和undo log的核心是为了保证innodb事务机制中的持久性和原子性，事务提交成功由redo log保证数据持久性，而事务可以进行回滚从而保证事务操作原子性则是通过undo log 来保证的。

原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。

undo log 的主要应用场景分别：

事务回滚 ：前面提到过，后台线程会不定时的去刷新buffer pool中的数据到磁盘，但是如果该事务执行期间出现各种错误(宕机)或者执行rollback语句，那么前面刷进去的操作都是需要回滚的，保证原子性，undo log就是提供事务回滚的。
MVCC：当读取的某一行被其他事务锁定时，可以从undo log中分析出该行记录以前的数据版本是怎样的，从而让用户能够读取到当前事务操作之前的数据——快照读。

3.2 undo log 数据格式

undo log 数据主要分两类：

insert undo log

insert 操作的记录，只对事务本身可见，对其他事务不可见(这是事务隔离性的要求)，故该undo log可以在事务提交后直接删除，不需要进行purge操作。

update undo log

update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

在InnoDB存储引擎中，undo log使用rollback segment回滚段进行存储，每隔回滚段包含了1024个undo log segment。MySQL5.5之后，一共有128个回滚段。即总共可以记录128 * 1024个undo操作。

每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。

3.3 undo log 操作实例

1、首先准备一张原始原始数据表（user_info）

对于InnoDB引擎来说，每个行记录除了记录本身的数据之外，还有几个隐藏的列:

DB_ROW_ID∶记录的主键id。
DB_TRX_ID：事务ID，当对某条记录发生修改时，就会将这个事务的Id记录其中。
DB_ROLL_PTR︰回滚指针，版本链中的指针。

2、开启一个事务A

对 user_info 表执行如下SQL：

将会进行如下流程操作：

1、首先获得一个事务编号 104

2、把user_info表修改前的数据拷贝到undo log

3、修改user_info表 id=1的数据

4、把修改后的数据事务版本号改成当前事务版本号，并把DB_ROLL_PTR 地址指向undo log数据地址。

3、最后执行结束

结果如下所示：

可以发现每次对数据的变更都会产生一个undo log，当一条记录被变更多次时，那么就会产生多条undo log，undo log记录的是变更前的日志，并且每个undo log的序号是递增的，那么当要回滚的时候，按照序号依次向前推，就可以找到我们的原始数据了。

总结

binlog 是MySQL server层的日志，而redo log 和undo log都是引擎层（InnoDB）的日志，要换其他数据引擎那么就未必有redo log和undo log了。

它的设计目标是支持innodb的“事务”的特性，事务ACID特性分别是原子性、一致性、隔离性、持久性，一致性是事务的最终追求的目标，隔离性、原子性、持久性是达成一致性目标的手段，根据的之前的介绍我们已经知道隔离性是通过锁机制来实现的，而事务的原子性和持久性则是通过redo log 和undo log来保障的。

写入策略

事务执行过程中，先把日志写到bin log cache ，事务提交的时候，再把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。

binlog vs redo log

redo log 物理日志：记录内容是“在xx数据页做了xx修改”，属于InnoDB存储引擎层产生的。
binlog 逻辑日志：记录内容是语句的原始逻辑，类似于给ID=2这一行的c字段加1，属于服务层。

两个侧重点也不同， redo log让InnoDB有了崩溃恢复的能力，binlog保证了MySQL集群架构的数据一致性。

在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。

往期热文推荐：

太强了，全面解析缓存应用经典问题
如何把团队带成一盘散沙？
是什么影响了MySQL索引B+树的高度？

关注公众号，免费领学习资料

如果您觉得还不错，欢迎关注和转发~

分析服务

◆ 游戏行业新增“区服分析”埋点模板及分析报告，支持开发者分服务器查看用户付费、留存等指标，可进一步评估不同服务器的玩家质量；

◆ 新增营销活动报告，可查看广告任务带来的曝光、相关信息，让营销推广活动的前端效果一目了然；

◆ 新增Web归因及会话级归因，以及带来用户流量后的行为分析，满足开发者更多推广渠道的归因诉求。

查看详情>>

视频编辑服务

◆ 新增美颜功能，可提供美白、瘦脸、磨皮、亮眼、大眼功能，实时渲染，打造自然真实的美颜效果；

◆ 新增支持开发者自定义上传模板、贴纸等素材的功能，并提供模板制作SDK，满足开发者轻松审核、运营管理应用内素材的需求。

查看详情>>

音频编辑服务

◆ 新增支持草稿保存和编辑相关接口、枚举和方法，新增草稿信息和操作失败的相关类；

◆ 新增通用版变声可设置类型：赛博朋克（CYBERPUNK）、合成器（SYNTH）、混响（MIX）、星际战争（WAR），满足开发者的各种使用场景；

◆ 云侧AI配音能力同步接口（流式）新增输出采样率、声道、位深和格式的PCM流参数说明；

◆ 云侧歌声合成能力新增关键字对齐功能，音色新增国风女声，音高支持范围F3~C#5。

查看详情>>

3D建模服务

新增3D建模续扫功能，开发者可以在采集图像的过程中进行续扫补充，提升建模成功率；

新增支持高中低模设置，其中高模对应10w面片，中模对应5w面片，低模对应2.5w面片，满足不同要求的建模使用场景。

查看详情>>

运动健康服务

云侧新增支持通过周、月、年三个时间粒度查询用户历史数据，满足开发者实际使用场景中的数据读取与应用。默认情况下，从授权日期开始后的用户运动健康数据允许开放，最多可以开放授权用户前一年的历史数据，申请时需体验明确的使用场景，并且建议最小化历史数据权限。

查看详情>>

统一扫码服务

iOS端Customized View模式下，新增暂停连续扫码和恢复连续扫码功能。可在连续扫码特定使用场景中暂停连续扫码，等待数据返回，避免因相机未关闭连续扫描到多个码而导致数据出错等异常情况，待数据返回后，可恢复连续扫码功能。该功能可用于多商品录入、快递录入等场景中，提升信息录入效率。

查看详情>>

3D Engine

◆ 新增Android平台支持，提供Android应用一键构建打包并生成自验证安装包；

◆ 编辑器功能的实体大纲中新增一体化实体对象构建功能，可新建实体，并对实体绑定网格组件，可实例化的对象形状包括Cube（立方体）、Sphere（球体）、Cylinder（圆柱体）、Cone（锥体）、Plane（平面）五种；

◆ 编辑器功能新增自动保存工程与关卡数据的能力，满足日常开发使用需求；

◆ 渲染系统光源支持投射RT Shadow软阴影，可通过追踪物体和光源之间的光线路径，估算光线被遮挡程度，最终模拟物理真实的阴影，达到更为逼真的渲染效果；

◆ 体积雾增加自发光属性，支持自发光颜色和强度的调节；

◆ 水体系统支持水体表面渲染及水下后处理视觉效果，可实现水面的反射与折射；支持创建水体材质，编辑颜色、波形、光照等参数；支持水下后处理、焦散等效果编辑；支持水体物理碰撞，产生波纹效果。

◆ 粒子系统增强，新增以下4种能力：

支持粒子的拖尾效果，能够实现虚拟“烟花”放射时拖尾的特效效果；

增加曲线随机值使用的灵活度，可通过设置每帧更新、随粒子产生更新、随发射器创建更新等更新模式；

支持多个Emitter标签编辑，提供跨Emitter的发射器复制，支持Preview界面和Detial界面随着Emitter切换而变化；

新增若干粒子圆周运动功能，可使粒子的形变方向和朝向方向能够随粒子速度变化，多应用于旋涡状“烟花”特效；

◆ 新增支持将UI画布转换成材质纹理，可以实现在3D世界中放置UI画布。

查看详情>>

视频服务

◆ 新增播放器支持以非独立进程启动服务能力，解决集成在HMS Core框架中应用的问题；

◆ 新增获取设备当前屏幕亮度的能力，当对HDR Vivid片源进行Tonemapping处理时，可适应当前屏幕亮度，获取更好的显示效果。

查看详情>>

数字版权服务

◆ 新增客户端SDK允许App集成在非华为设备上提供软件级DRM能力，实现Provision、License和片源解密等相关功能。

访问Gitee>>

导航服务

◆ 路线规划新增未来出行估时、历史路况、限行区域功能；

◆ 导航中新增更优路线提醒功能。

访问Gitee>>

全量版本更新。查看详情>>

了解更多详情>>

访问华为开发者联盟官网
获取开发指导文档
华为移动服务开源仓库地址：GitHub、Gitee

关注我们，第一时间了解 HMS Core 最新技术资讯~

11月4日，HDC2022华为开发者大会在东莞松山湖举办。在本次大会的HMS Core创新图形能力分论坛中，HMS Core重点介绍了其在3D技术领域的创新应用方向，其中3D建模服务展示了创新的自动骨骼绑定功能，其具有高度自动化，超强鲁棒性，优质的蒙皮效果等优势，进一步助力开发者技术创新。

HMS Core 3D建模服务的自动骨骼绑定功能，基于AI技术，面向有商品展示、趣味教学、AR游戏、动画制作等诉求的开发者，提供骨骼绑定等服务。用户仅需基于普通手机相机拍摄二足人形物体的多张图像，即可在生成3D模型的同时自动绑定骨骼以及蒙皮权重，实现一键驱动。举例来说，在动画制作方面，传统建模团队在取得模型后，需单独创建人体骨骼，再由绑定师进行逐一骨骼点绑定，使骨骼在模型中起到支撑作用。而通过HMS Core的自动骨骼绑定功能，人体骨骼点在建模的同时实现无感化自动绑定，节省绑定时间，从而提高制作效率。

目前，少数实现自动关节估计的方法都需要目标模型摆好标准姿态。HMS Core则利用AI算法减少了人为规则的需求，可以支持非对称的多种姿态。这是源于华为自主研发的3D角色数据生成框架，基于数十万的3D绑定数据，全面提升AI绑定算法的准确性和泛化性。此外，在自动绑定人体骨骼技术方面，相较于行业普遍仅支持17个骨骼点的标准，HMS Core的自动骨骼绑定功能支持识别和跟踪23个骨骼点，能够更精准地识别人形姿势。

HMS Core 3D建模服务持续创新助力各领域的开发者和合作伙伴打造更好的用户体验。在今年，bilibili会员购和HMS Core携手，计划将3D建模服务的自动骨骼绑定功能用于虚拟场景下的商品展示。让普通的手办商品从2D平面，到生成3D模型，再与现实场景融合交互，提供跳舞等趣味互动，为消费者提供前所未有沉浸式购物体验。而在2021年，bilibili会员购就已将HMS Core AR Engine能力应用于塔罗牌系列，助力其搭建立体世界，实现新场景的融合交互，收获了更多用户正向反馈。

HMS Core 3D建模服务不仅为电商行业注入了新的商业体验，在教学模具，游戏开发，动画制作等领域有着更广阔的应用场景。

例如在教学领域，自动骨骼绑定功能可将教具建成3D模型，通过趣味性演示，提高学习兴趣；在游戏开发领域，通过实时骨骼动画，面部表情驱动，多重动画状态机融合等功能，可以帮助开发者打造更流畅真实的3D动画效果，提升制作动画游戏的效率。

作为华为持续开放的软硬件和端云能力，HMS Core也将坚持创新，打造基于鸿蒙生态下全场景万物智联的底座，助力广大开发者低门槛、低代码开发创新应用，赋能千行百业走进3D数字世界。

作者：王嘉宁、汪诚愚、谭传奇、邱明辉、黄松芳、黄俊、高明

近日，阿里云机器学习平台PAI与华东师范大学高明教授团队、达摩院机器智能技术NLP团队合作在自然语言处理顶级会议EMNLP2022上发表基于Span和学习的小样本实体识别算法SpanProto。这是一种面向命名实体识别的小样本学习算法，采用两阶段的训练方法，检测文本中最有可能是命名实体的Span，并且准确判断其实体类型，在仅需要标注极少训练数据的情况下，提升预训练语言模型在命名实体识别任务上的精度。

论文：

Jianing Wang, Chengyu Wang, Chuanqi Tan, Minghui Qiu, Songfang Huang, Jun Huang, Ming Gao. SpanProto: A Two-stage Span-based Prototypical Network For Few-shot Named Entity Recognition. EMNLP 2022

背景

大规模预训练语言模型的广泛应用，促进了NLP各个下游任务准确度大幅提升，然而，传统的自然语言理解任务通常需要大量的标注数据来微调预训练语言模型。例如，对于命名实体识别任务，模型的训练需要一定数量的语料来学习Token与Label之间的依赖关系。但是在实际应用中，标注数据资源比较稀缺，传统的序列标注方法很难达到较好的效果，因为其需要解决实体识别中的标签依赖（Label Depnedency）关系，同时也无法应对实体嵌套（Nested Entity）问题。因此，我们研究一种基于Span和学习的小样本实体识别技术。特别地，我们关注于解决N-way K-shot的实体识别场景。下图所展示了一个2-way 1-shot实体识别任务：

在上述2-way 1-shot任务中，包含了若干个Support Set和Query Set，每个Support Set只包含2个类别的实体（即上图的PER和LOC，除了非实体的“O”类别），且每个类别的标注实体数量只有1个。

算法概述

为了解决上述小样本命名实体识别问题，SpanProto采用两阶段方法，即将实体识别任务分解为两个阶段，分别是Span Extraction和Mention Classification。模型框架图如下所示：

Span Extraction

首先，SpanProto使用与类别无关的Span抽取器，抽取出可能的命名区间。在这个工作中，我们参考了Baffine Decoder和Global Pointer的技术，设计了Global Boundary Matrix，显式让模型学习到实体区间的边界信息。在这个Matrix中，每一个坐标素(i, j)恰好可以表示一个区间[i:j]，如果这个区间是一个实体，那么素将对应于1，如果这个区间不是一个实体，那么素将对应于0:

Span Extraction模型采用下述基于Span的Cross-Entropy损失函数进行训练：

通过上述模型，SpanProto可以利用Global Boundary Matrix抽取出所有可能的实体。

Mention Classification

在Mention Classification模块中，SpanProto采用标准的Prototypical Learning技术给每个Span分配标签，即最小化每个Span表征与对应类别的原型的欧式距离。与此同时，我们考虑到命名实体识别的False Positive问题，即存在一些抽取的Span在当前Episode内没有合适的类别可以分配的情况。例如，在上图中，Span Extraction阶段模型会抽取出August 15. 1954为一个Span，它可能是一个“Time”类别的实体，但是在当前episode任务中其实只有PER和LOC，没有合适的标签给到这个Span。针对False Positive，我们采用Margin Learning方法，最大化这些Span表征与所有实体类别的原型向量的欧式距离：

整体算法流程

SpanProto整体算法流程图如图所示：

算法精度评测

为了验证SpanProto算法的有效性，我们在Few-NERD这一标准评测数据集上进行了测试，效果证明SpanProto对精度提升明显：

我们也对算法的模块进行了详细有效性分析，我们可以发现Span Extraction和Mention Classification均对模型有一定贡献。

为了更好地服务开源社区，SpanProto算法的源代码即将贡献在自然语言处理算法框架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 (accepted)
Juntao Yu, Bernd Bohnet, Massimo Poesio. Named Entity Recognition as Dependency Parsing. ACL 2020: 6470-6476
Ning Ding, Guangwei Xu, Yulin Chen, Xiaobin Wang, Xu Han, Pengjun Xie, Haitao Zheng, Zhiyuan Liu. Few-NERD: A Few-shot Named Entity Recognition Dataset. ACL/IJCNLP 2021: 3198-3213
GlobalPointer：用统一的方式处理嵌套和非嵌套NER. https://spaces.ac.cn/archives/8373

论文信息

论文名字：SpanProto: A Two-stage Span-based Prototypical Network For Few-shot Named Entity Recognition
论文作者：王嘉宁、汪诚愚、谭传奇、邱明辉、黄松芳、黄俊、高明
论文pdf链接：https://arxiv.org/abs/2210.09049

有一个现象，让我印象很深刻：许多公司会聘请经验丰富的产品专家，希望他们能扩大产品规模。但在实际工作中，这些产品专家却有心无力，因为他们不是真正有决定权的人。

高层管理者总觉得自己很了解应该做什么，并希望产品经理服从他们的命令。所以在现实场景里，产品专家们只能根据指令完成「废话管理 Bullshit Management」，而不是产品管理。

没有决策权，产品经理就无法茁壮成长。

可要小心了！有些公司「说的」和「做的」总是截然相反。说是扁平化管理，但你可能会发现公司内部有层层决策链，最终还会因此陷入分析瘫痪；

你可能会被授予一定的决策自主权，但绝不会超出特定范围。比如你可以敲定如何更好地实施解决方案，但却无法决定先解决哪个问题。

凭借主观想法和管理层级推动业务，是让人震惊的。我特想知道，领导层聘请产品经理究竟是为了执行废话，还是管理产品。

下面我将举例说明什么是「废话管理」，以及产品经理们可以如何避免这些可怕的陷阱。

一、一直被误解，从未被实践的产品管理

随着公司的发展，内部政治化会逐渐加强，而敏捷性则越来越弱。有些时候，最重要事成了取悦内部的关键干系人，而不是弄清楚哪些终端用户的问题值得解决。

此时，你可能就会从「产品经理」降级为「待办所有者 Backlog Owner」或「故事写手 Story Writer」。这种情况下，取悦利益相关者比改善用户体验更有利于职业发展。

我时不时会看看招聘广告，了解企业如何看待「产品经理」一职。遗憾的是，我在其中看到了许多岗位误解，下面是我在最近发现的一些奇怪的要求。

您将会与组织中的利益相关者合作，获取他们的支持并满足他们的需求。

我以为产品经理必须要满足的是用户的需求，而不是内部利益相关者的需求

您需要在全球/区域基础上，制定商业计划和产品推广计划。

认真的吗？大多数商业计划本质都是瀑布式思维；创建一个计划、做几个漂亮的 PPT 和在线表格。那只能用来骗自己，计划越多，失败越大。

好的产品管理要有明确的愿景，能用很少的资金测试各种想法，并在得到客观的佐证后，逐步提升它们。目标服务于愿景，但也要拥抱试验才能发现隐藏的机会。

制定用于提高开发效率的工具和流程。

这点让我很困惑。我从没想过产品经理需要负责制定流程，提高开发效率。这是典型的产出导向（Output-oriented）的要求，而不是结果导向（Outcome-oriented）。

您需要为您的产品小组规划活动和资源，并与工程、市场、质量或销售等跨职能团队进行协调。

产品经理不计划具体的活动，而应该设定目标，并授权团队做出决策。这要求听着更像项目管理，而不是产品管理。

同「Context, Not Control」一般，优秀的产品经理主张情景管理，绝非控制管理。

使用全面的验收标准，定义史诗和用户故事。

将产品经理视作需求工程师是一个常见的陷阱。一些公司希望产品经理可以架起业务端和技术端的沟通桥梁。瀑布开发就是这样，但我们都知道它的效果并不好。

卓越的产品经理应该打造一个可以滋养伟大想法的环境和氛围，而不是设定实施要求。

您将确保整个公司展开强有力的协作和沟通，并就产品路线图达成共识。

追求共识除了会让团队速度变得超级慢之外，还会让大家趋于平庸。产品经理争取的从来不是共识，而是承诺。大家同不同意都没关系，经验和客观证据永远比主观想法和职位更有说服力。

我在阅读以上这些产品经理的岗位描述时，我知道我们还有很多机会，可以帮助公司实践良好的产品管理。尽管这极具挑战，但回报很可观。

其中的关键就在于了解预期的可能结果并调整方法，帮助企业取得产品管理方面的进步。过程可能会挑起一些争吵，但这听起来就很刺激。

二、什么是「废话管理」？

花时间做与产品管理无关的事情，我都称之为「废话管理」。展开详细解释之前，我想先分享一下「什么造就优秀的产品经理」。

通过确定要解决的重大问题，发现未开发的潜在机会，领导团队为终端用户和业务创造价值。

在我看来，一个优秀的产品经理善于鼓舞人心。TA 会舞动大家行动起来，有些事情甚至连行为人都不知道自己能做成；TA 还会设定振奋人心的目标，授权团队决定如何实现目标；TA 不是老板，而是团队追随的领导者。

如果你的日常工作与上面提到的有关，我相信你在做产品管理；但如果不相关，那大概率就在进行「废话管理」，就像这些常见情况一样：

收集和解决干系人的需求，而不与他们建立关系，满足终端用户的需求。
保留大量的产品待办列表，只为了告诉干系人「需求已登记」，却不删除与当前目标无关的待办事项。
频繁地为管理层准备绩效报告，却不评估交付物的效果。
努力地追求共识，取悦所有干系人，却不为产品找一个最优选择。
签署团队交付的所有项目，以确保他们符合你的质量控制标准，而不授权他们实现目标。
参加会议只是为了避免激怒干系人。
害怕拒绝无意义需求，因为你的老板可能因此收到「问候」。
承担业务干系人和开发人员之间的沟通，而不是成为促进协作的催化剂。
不了解终端用户的意见，基于主观想法就完成需求的优先级排序。
专注于功能模块的交付，却不追求价值最大化。
花时间为计划失败找原因，从不分享从失败中学到的经验和教训。

每当看到任何一个「伪产品管理」的迹象，产品经理都应该站出来，帮助团队扭转功能失调的管理，向可靠和稳固靠拢。别向错误模式低头，莽它！

三、如何避免陷入「废话管理」？

前面列举了一些常见的产品管理的错误模式，下面将提供一些纠正错误的实践技巧。

01 改掉主观想法，追求客观证据

干系人可能会步步紧逼，要求产品经理实现他们想要的功能。在做出任何决定前，你可以向他们提出以下问题：

这个功能与我们的目标有什么关系？
哪些证据能说明此功能解决了用户问题？
您想用这个功能解决哪个问题？
如果实现了这个功能，该怎么评估它的效果？
如果不做这个需求，会发生什么？

这些问题的答案可能会让你和干系人都大吃一惊。也许他们会撤回之前的请求；如果在缺乏有力证据的情况下他们仍旧坚持，那么坚持客观证据就是你的职责。主观想法不应该成为产品团队的驱动力。

产品经理要带领团队为终端用户提供解决方案。通过打造产品和服务，让用户的生活更美好。想要获得成功，就要从「取悦利益相关者」，转变为「帮用户获得进步」。

02 避免成为「传话筒」，鼓励直接交流

将产品经理视为业务团队和技术团队的桥梁，是一个常见的错误。更好的方法是为技术团队提供正确的上下文信息，授权他们自主决策，并鼓励他们在需要时，与业务利益相关者直接沟通。

你可能认为，让开发人员与干系人直接交流有点危险，他们可能尝试将干系人的需求劫持到冲刺中。

这确实有可能发生，但相比敢于解决问题的伙伴，循规蹈矩的团队更为危险。如果干系人试图劫持某些东西，请及时给予反馈，鼓励开发伙伴将此类讨论重定向给你，因为他们可能也不愿意处理它。

03 聚焦用户学习，摆脱无效计划

每个人都喜欢安全感，没有什么比为面前的一切制定一个按部就班的计划更好了。干系人会要求你制定规范性计划，并对截止日期做出承诺。

不要掉入这个陷阱！

没有任何计划能在与用户接触后还继续存在。与其费劲做计划，不如拟定一个假设清单，将想法实现必须要完成事情都列出来。再找一条能快速验证假设的捷径，你越快地了解清楚用户，就能越早迎来产品成功。

可靠的产品管理与计划无关。不要沉迷计划；把你的精力放在确定着陆点，和迈向它的第一步上。

除此之外，你的项目启动无需任何东西。之后根据你了解到的内容，调整具体行动。下面是聚焦用户学习，摆脱无效计划的几点标志：

产品待办列表很精简，工作量不超过几个月。
删除了待办列表中与学习成果无关的事项。
叫停了某些功能和需求，因为证据表明它们不会创造任何或令人满意的价值。

写在最后

产品经理的竞争比以往任何时候都要激烈，许多公司都在向优秀的专业人才抛出橄榄枝。如果你想加入，没有比现在更好的机会。

但是，准备好应对许多「伪产品管理」和实践挫折。尽管公司会招致优秀的产品专家，但这不意味着他们会提供一个良好的发展环境；你必须与错误模式对抗，帮助他们克服功能障碍。

伟大的产品经理永远不会向错误模式低头。他们将始终保持战斗状态，以确保能够为用户带来改善和提升。

原文作者：David Pereira

文章出处：Medium

了解更多敏捷开发、项目管理、行业动态等消息，关注我们 LigaAI@oschina 或LigaAI – 新一代智能研发协作平台，在线申请体验我们的产品。

作者：李岩科

1 背景

SpringBoot是一个框架，一种全新的编程规范，他的产生简化了框架的使用，同时也提供了很多便捷的功能，比如内置tomcat就是其中一项，他让我们省去了搭建tomcat容器，生成war，部署，启动tomcat。因为内置了启动容器，应用程序可以直接通过 Maven 命令将项目编译成可执行的 jar 包，通过 java -jar 命令直接启动，不需要再像以前一样，打包成 War 包，然后部署在 Tomcat 中。那么内置tomcat是如何实现的呢

2 tomcat启动过程及原理

2.1 下载一个springboot项目

在这里下载一个项目https://start.spring.io/ 也可以在idea新建SpringBoot-Web工程.

pom.xml会有 tomcat依赖

2.2 从启动入口开始一步步探索

进入run方法

进入到这个run方法之后就可以看到，我们认识的一些初始化事件。主要的过程也是在这里完成的。

2.3 源码代码流程大致是这样

代码中主要就是通过 switch 语句，根据 webApplicationType 的类型来创建不同的 ApplicationContext：

DEFAULT_SERVLET_WEB_CONTEXT_CLASS：Web类型，实例化 AnnotationConfigServletWebServerApplicationContext
DEFAULT_REACTIVE_WEB_CONTEXT_CLASS：响应式Web类型，实例化 AnnotationConfigReactiveWebServerApplicationContext
DEFAULT_CONTEXT_CLASS：非Web类型，实例化 AnnotationConfigApplicationContext

2.4 创建完应用上下文之后，我们在看刷新上下文方法

一步步通过断点方法进去查看，我们看到很熟悉代码spring的相关代码。

2.5 onRefresh() 方法是调用其子类实现的

也就是 ServletWebServerApplicationContext

其中 createWebServer() 方法是用来启动web服务的，但是还没有真正启动 Tomcat，只是通过ServletWebServerFactory 创建了一个 WebServer，继续来看这个 ServletWebServerFactory：

this.webServer = factory.getWebServer(getSelfInitializer()); 这个方法可以看出TomcatServletWebServerFactory的实现。相关Tomcat的实现。

2.6 TomcatServletWebServerFactory 的 getWebServer() 方法

清晰的看到new 出来了一个Tomcat.

2.7 Tomcat创建之后，继续分析Tomcat的相关设置和参数

2.8 继续getTomcatWebServer方法，找到initialize()方法，可以看到tomcat.start();启动tomcat服务方法。

//Tomcat.java

2.9 TomcatWebServer.java 控制台会打印这句话

Tomcat started on port(s): 8080 (http) with context path ‘’

3 总结

SpringBoot的启动主要是通过实例化SpringApplication来启动的，启动过程主要做了如下几件事情：

配置系统属性、获取监听器，发布应用开始启动事件、初始化参数、配置环境、创建应用上下文、预处理上下文、刷新上下文、再次刷新上下文、发布应用已经启动事件、发布应用启动完成事件。而启动 Tomcat 是刷新上下文这一步。

Spring Boot 创建 Tomcat 时，会先创建一个上下文，将 WebApplicationContext 传给 Tomcat；

启动 Web 容器，需要调用 getWebserver()，因为默认的 Web 环境就是 TomcatServletWebServerFactory，所以会创建 Tomcat 的 Webserver，这里会把根上下文作为参数给 TomcatServletWebServerFactory 的 getWebServer()；启动 Tomcat，调用 Tomcat 中 Host、Engine 的启动方法。

3.1 Tomcat相关名称介绍

HarmonyOS 3.1 版本主推ArkTS开发语言，ArkTS API的数量也将达到10000+，主要API能力包括：增强的声明式UI能力、全新的应用开发模型——Stage模型，并在DFX、Web组件开发、国际化开发、通信互联、媒体软件等子系统能力方面有所更新或增强，这些能力标志着HarmonyOS全面进入ArkTS语言的声明式开发阶段。

下面，让我们一起了解HarmonyOS 3.1版本主要有哪些关键特性吧。

一、声明式UI能力

ArkUI是一套构建HarmonyOS应用界面的声明式UI开发框架。它通过简洁自然的UI信息描述语法、丰富的UI动效组件和API，以及不断增强的一次开发、多端部署能力，帮助您提升HarmonyOS应用界面开发效率。

目前ArkUI已支持包括Canvas、XComponent、DatePicker等超70个UI组件，并且提供了丰富的响应式布局和自适应布局能力。

具体新增及增强能力如下所示：

1、声明式2D/3D绘制能力

1）新增Canvas绘制能力，支持W3C标准Canvas接口，结合声明式UI范式，增强应用开发者自定义绘制能力。

2）通过XComponent组件，配合NDK能力，构建C++/TS混合开发能力，支持游戏、媒体应用开发。

2、布局能力提升

1）扁平化布局能力，提升布局效率

2）自定义布局能力，布局更加灵活、可定制

3、组件能力提升

1）分栏架构组件使用提升

2）列表组件使用提升

4、多设备交互事件归一

交互归一后开发者无需关注当前设备和输入设备类型，只需在交互归一事件接口中做逻辑响应即可。

交互归一

二、应用开发模型——Stage模型

作为FA模型的一种补充，应用开发框架引入了Stage模型作为第二种应用开发模型。Stage模型包含生命周期管理、调度、回调、上下文获取、鉴权等，大大增强了应用的运行管理能力。Stage模型的重点特性如下：

1、重新定义应用运行规则，从根本上解决后台抢占系统资源问题

1）后台常驻进程数量减少

2）后台常驻进程内存开销减少

3）后台进程行为更加有序

4）前台进程所需资源可得到充分保障

重新定义应用运行规则

2、逻辑与UI解耦，应用异常恢复与应用跨设备迁移逻辑归一

1） UI与逻辑解耦，UI通过数据驱动

2）应用异常恢复只需载入关键节点数据

3）跨设备流转时，应用同样载入关键节点数据

逻辑与UI解耦

3、多设备应用模型归一，更利于应用一次开发多端部署

Stage模型的UIAbility生命周期和窗口显示/焦点事件分离，统一了多设备形态下UIAbility模型，促进多设备兼容应用代码更加简洁。

窗口状态与UIAbility生命周期关系

三、DFX

1、CPU耗时调优

用于在CPU负载高场景下，跟踪代码执行过程中的关键流程，度量分析热点函数耗时。

CPU耗时调优

2、内存分配调优

调优常见内存分配过多、内存泄漏等问题，开发者可快速找到内存生命周期的上下文。

内存分配调优

3、HiAppEvent(应用埋点框架)

提供HarmonyOS应用事件的预埋、预定义、自定义事件埋点、存储、分发、订阅框架。应用内开发者可集成SDK接入大数据云，通过HiAppEvent订阅机制完成埋点数据获取。

四、Web组件开发

本次更新支持文档类Web应用文档预览和基础编辑功能，支持图文混排内容跨设备复制粘贴。在统一W3C标准下支持文档类Web应用生态快速迁移，适配移植工作量小，调试成本低；支持图文混排内容跨设备复制粘贴，解决富文本内容跨设备复制图片丢失问题，提高移动办公体验。

五、国际化开发——伪本地化调试

支持界面语言的伪翻译替换，文本长度扩展，文本边界测试。开发者无需在APP中加入伪翻译资源即可测试，通过切换系统语言到en-XA区域可快速进行调试。

伪本地化前伪本地化后

六、通信互联

1、http增强功能

包括支持缓存、支持并发框架、支持gzip压缩、支持指定数据返回格式。

2、支持TLSSocket

支持客户端指定证书、密钥、CA等安全传输选项，向服务器发起连接，建立TLSSocket连接支持TLSv1.2和TLSv1.3。

七、媒体软件

1、音视频播放、录制、编解码

1）音视频播放，包括：本地播放、在线播放

2）音视频录制，包括：音频录制、视频录制

3）音视频编解码，包括：音频软编解码、视频硬编解码，支持H264

2、相机支持预览、拍照、录像功能

1）相机基础能力，包括：基础预览、基础拍照、基础录像

2）支持基本参数控制：闪光灯、对焦、变焦等

八、分布式数据管理

分布式数据为应用程序提供不同设备间数据库的分布式协同能力（KVStore支持分布式，RDB仅支持本地）。

除以上关键特性外，本次HarmonyOS 3.1还将在安全基础能力、网络管理、包管理、测试框架、文件管理、资源调度、USB服务、输入法、打印、位置服务、无障碍软件服务、用户IAM、窗口、电话服务、分布式软总线、电源服务、事件通知等子系统方面有不同程度的更新或增强。

以上HarmonyOS 3.1版本的主要更新内容，将会在后续的开发者版本中逐步开放。最后，我们一起来看看HarmonyOS 3.1的版本更新节奏：

版本特性路标

HDC2022发布了HarmonyOS 3.1 Developer Preview版本，已经携带了最新的Stage模型以及部分ArkUI增强能力，欢迎各位开发者小伙伴们到HarmonyOS官网下载并提前尝鲜，感谢您一路陪伴HarmonyOS成长！

关注公众号

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

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

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

PHP8.2是PHP语言现代化进程中的一个重要的里程碑。除了令人兴奋地新特性和改进之外，PHP8.2还简化了语言，取消了对动态类属性的支持，在遇到某些非最优的ini配置时发出警告，并修复了一些影响PHP数组排序和某些类型的字符串转换/编码操作的遗留PHP行为。

系统改进

PHP8.2解决了PHP类型系统的几个缺点和限制，允许PHP应用采用更好的类型安全。包括添加了true类型，允许null和false作为独立的类型使用，并支持DNF类型（泛型解析）。

PHP8.2支持分离范式类型，现在可以进行组合联合类型和交际类型，这可以定义声明精确而富有表现力的参数、返回值和属性。

php8.2之前

现在

支持true和false作为独立的类型，如果bool始终相同的时候可以用它来声明。

其中null的类型在之前的版本中就可以在联合类型声明中使用，现在可以独立使用了。

只读类

PHP8.1增加了一个readonly的属性声明。一个readonly的属性只能设置一次，并且PHP会阻止任何作用域内的修改。

PHP8.2对readonly声明进行更进一步的使用，可以将类声明为readonly。当一个类被声明为readonly，它的所有属性都会自动声明readonly。此外，这个类不能使用动态属性，以确保所有的属性都是有定义的。

所有的属性都会自动声明城readonly。

新的随机数扩展

在PHP的历史发展中，它支持各种各样的随机数生成器，他们有不同程度的性能和不同的用例，并且适合安全应用程序。PHP8.2更进一步，将所有与随机数相关的功能重构为一个名为random的扩展。新的扩展不会破坏任何现有的接口使用，因此现有的rand，mt_rand函数将继续工作，不需要任何更改。它还提供了一个对象接口，用可插拔的体系生成随机数，因此很容易模拟随机数生成器并提供新的随机数生成器，从而市PHP应用程序安全且易于测试。

trait常量

在PHP8.2中，可以在trait中声明常量。trait不能直接访问，但当类使用trait时，这些常量就变成了类的常量。

敏感参数支持

PHP8.2新增了一个内置参数属性命名：#[SensitiveParameter]。能够使PHP在堆栈跟踪和错误消息中隐藏掉实际值。

我们经常会在参数或属性中定义密码、秘钥或其他敏感信息。当PHP发生错误时，这些值会被记录下来。显示到屏幕上或者记录到日志中。这样人们就能通过这些方式得到敏感数据。

比如下面的例子：

打印的内容如下：

hunter2不会被打印出来。

新的函数和类

解析INI数量值：ini_parse_quantity

将PHP ini值识别成字节。

curl维持活动：

在PHP8.2中，curl扩展会触发底层curl库来运行必要任务，以保持curl连接存活。最常见的用法就是定期调用curl_upkeep来实现http持久连接（keep-alive）。

检索密码长度：

在PHP8.2 OpenSSL中，有一个名为openssl_cipher_key_length的函数，能够接受任何支持的密码所需的秘钥长度，在之前需要硬编码才能实现：

重置记录的峰值内存使用量：

这对于多次调用或迭代调用时很有用。

PHP8.2中的弃用

PHP8.2也带来了相当一部分的弃用。当语法、函数和特性被弃用时，PHP会发起一个弃用通知，该通知不应该中断PHP程序，但会被记录到错误日志中。

注意：PHP8.0以后，PHP的默认错误报告行为是E_ALL

已弃用动态属性

PHP8.2中最值得注意的弃用之一就是弃用动态属性。如果一个类属性没有声明就被调用或赋值，就会退出程序。

这个可能会影响到很多的的PHP遗留程序，推荐的修复方法是在类型中声明属性。

对此也有例外用法，比如stdClass和它的子类将正常使用，__get和__set魔术方法将正常使用，或者声明#AllowDynamicProperties。

其他一些弃用可以关注本站其他文章：

《PHP8.2中字串变量解析的新用法》https://phpreturn.com/index/a628de16a2adf8.html

安装和升级到PHP8.2

PHP 8.2现在可以在所有常规源代码中下载/安装:

Windows:编译后的二进制文件可在windows.php.net
Ubuntu/Debian: PHP 8.2可用 ondrej/phpPPA
Fedora/RHEL/CentOS/Alma/Rocky: 可以在Remi 的源中获取
Mac OS: PHP 8.2可以通过Homebrew安装 shivammathur/homebrew-php利用.
Docker：可以通过8.2*版本获取PHP 8.2

更详细的变动，作者将持续跟进发布。欢迎关注收藏。

原文标题：PHP8.2发布了！

原文地址：https://phpreturn.com/index/a639285aa925ed.html

原文平台：PHP武器库

版权声明：本文由phpreturn.com（PHP武器库官网）原创和首发，所有权利归phpreturn（PHP武器库）所有，本站允许任何形式的转载/引用文章，但必须同时注明出处。

“作者”名称关注我们

前言：开源跨境电商系统BeikeShop从v1.1.1到v1.1.2的功能更新，我们主要侧重修复bug和优化使用体验

这里要感谢，使用BeikeShop的用户，给我们提出的宝贵建议。因为有你们的存在，我们得以茁壮成长！

BeikeShop是什么？——BeikeShop是一款开源好用的跨境电商系统！

BeikeShop能够帮助卖家，快速的搭建属于自己的独立站，让卖家快速的进行国际网站建站——系统完全开源免费可商用！

✦✦

01 | BeikeShop1.1.2更新功能

来看看，这次跨境电商开源独立站BeikeShop从v1.1.1升级到v1.1.2版本，更新了哪些功能！

（1）新增功能

1. 完善表、字段备注，添加数据字典生成脚本

脚本路径：https://gitee.com/beikeshop/beikeshop/commit/02cdd6b0e31152d5eb072b4a8ef4a

* 最终效果如上图所示

↓查看文档↓

https://docs.beikeshop.com/dev/database.html

（2）修复功能

1. 修复品牌页翻页问题

2. 修复默认货币以及汇率

3. 修复后台商品列表创建商品按钮判断错误问题

4. 修复清理后台分类数据, 修复删除父级分类无法删除子分类

5. 修复后台部分配置多语言显示未启用语言

6. 修复后台编辑客户地址身份错误问题

7. 修复后台文章编辑丢失内容

8. 修复图片管理器创建目录权限问题

9. 修复轮播图在只有一张的时候，也轮播且无连接也跳转问题

10. 修复装修自定义链接无效问题

（3）优化功能

1. 优化购物车、结账页以及订单产品规格显示

2. 优化右侧弹出购物车局部结账等UI

3. 优化手机版UI

4. 优化用户头像上传

(第二次无法上传同一张图的问题)

5. 优化横幅模块在大分辨率屏幕下的居中问题

6. 完善Paypal && Stripe 结账

7. 优化优化第三方登录

✦✦

02 | BeikeShop独立站介绍优势？

1. 系统核心代码100%开源

一个好的开源系统，必须要做到100%核心代码开源，这个是一切的基础。有真功夫，敢拿出来亮剑

2. 业界知名框架Laravel开发

世界公认的PHP Web开发框架，简洁、优雅、富有表达力

3. 强大的插件机制

能使系统更好适应全球各地区的独立站运营场景，我们将系统的插件功能设置的极为强大，可轻松增加插件实现想要的功能

4. 支持多语言/多货币

系统完美的适配跨境外贸场景，一个商城可以安装多个语言。卖家可以轻松的服务更多地区的用户

5. 严格遵循MVC架构

公认的优秀系统架构，以低耦合性、高重用性、可适用性、快速的部署效率以及较低的维护成本，被众多开发者认可

6.代码分层清晰

8年的开源独立站开发经验，带来的清晰的代码逻辑，以及规范的开源代码格式

7.Event 机制实现Hook功能

方便代码修改！懂的都懂，极大地提升开发效率。让系统扩展性变强方便二次开发

8.界面美观/支持可视化装修

UI参考主流欧美独立站风格进行设计，符合欧美买家购物习惯，商城可视化装修功能，让卖家轻松装修商城

9. 系统操作简单/易上手

可快速上线，没有复杂的配置逻辑规则，系统后台清晰简洁，对运营人员相当友好

想要了解更多信息？链接访问！

官方网站：https://beikeshop.com/

↓前台链接↓

https://demo.beikeshop.com/

↓后台链接↓

https://demo.beikeshop.com/admin

账号：demo@beikeshop.com 密码：demo

欢迎随时私信联系我们！

作者：BladeDISC研发团队

BladeDISC 上一次更新主要发布了 GPU AStitch 优化，方法来源于我们发表在 ASPLOS 2022上的论文AStitch。这一次，我们发布了 0.3.0 版本。

本次更新中 BladeDISC 社区全面支持了 PyTorch 2.0 编译，推进了和 Torch-MLIR 社区的合作；增加了 CPU 量化编译和倚天新硬件支持；在编译优化方面 BladeDISC 社区增加了一系列特性，包括改进了 GPU 访存密集计算的性能，完成了 Shape Constaints IR 功能设计和支持。

本文描述 BladeDISC v0.3.0 版本对于 v0.2.0 的主要更新内容。

PyTorch 2.0 和动态编译支持

BladeDISC 近半年来高度关注 PyTorch 2.0 相关特性的新动态，积极参与社区的协作，在此期间完成了 TorchBlade 编译架构的调整，更好地 PyTorch 动态编译和训练支持。

TorchDynamo 优化

现在使用 PyTorch nightly 版本和 BladeDISC，只需要额外的两行代码改动即可完成 BladeDISC 的编译加速:

 import torch_blade # one more extra line model = ... compiled_model = torch.compile(model, backend='disc')

TorchBenchmark

BladeDISC 持续关注深度学习模型的通用优化，我们将 TorchBenchmark 作为优化的指南针评估和持续提升 BladeDISC 在不同模型上的鲁棒性和优化效果。

TorchMLIR(MHLO) 和动态性贡献

BladeDISC 一直是 MLIR/MHLO 动态性的主要贡献和推动者。这个版本中我们与字节 AML 团队合作往 Torch-MLIR 贡献了 Torch-to-MHLO 的模块，特别是对动态性的支持，请参考 [RFC] Adding Torch to MHLO conversion #999，特别感谢字节 AML 的同事的共同推动!

并且我们对 BladeDISC 中的 PyTorch 编译流程做了架构调整，Torch-MLIR 成为了 BladeDISC 的基础模块。下图中蓝色线框表示了 Torch-to-MHLO 工作在 BladeDISC 中相对的位置。

我们号召社区对此模块感兴趣的朋友们一起合作推动 Torch-MLIR(MHLO) 模块的迭代与演进，减少基础工作的碎片化。

PyTorch 训练支持

BladeDISC 正在逐步支持 PyTorch 模型的训练优化，目前已经成功支持 BERT 等模型的编译优化。BladeDISC 支持采用 PyTorch 2.0 的 TorchDynamo 和 Lazy Tensor Core 两种方式开启训练优化(当前此模块的接口没有完全确定，鉴于目前 PyTorch 社区的活跃度，我们会更优先支持 TorchDynamo 的使用方式)。目前此模块仍在持续更新和迭代，更多状态请关注我们的开发动态。

EasyCV/NLP 推理加速编译支持

BEVFormer: 是一种纯视觉的自动驾驶感知算法，借助 BladeDISC 优化，取得了 1.42 倍的端到端性能提升。
PAI-Diffusion Model: 在此版本中 BladeDISC 社区也对最近大热的 AIGC Diffusion 相关模型提供了通用优化支持。BladeDISC 为 PAI-Diffusion 提供了接近 3 倍的端到端的性能提升。

更多信息请查看 PAI EasyCV/NLP 相关系列文章和开源地址:

EasyCV: https://github.com/alibaba/EasyCV
EasyNLP: https://github.com/alibaba/EasyNLP

BladeDISC 量化 (Experimental)

在这半年中我们完成了编译+量化结合的一系列初步摸索，在包括X86、ARM多个不同硬件平台上完成了早期的方案及性能验证，下表中展示了我们一些初步的成果。

近期我们将支持更多硬件平台（例如CUDA），并提供如何量化PyTorch/TensorFlow模型的示例。此外，我们也将继续优化提升量化模型的推理性能。

BladeDISC 编译优化改进

新硬件支持：AArch64（倚天）

在这半年中我们进一步完善了对AArch64类硬件（尤其是倚天）的支持，进行了一系列针对性改进：

增加对BF16/int8 GEMM/Conv的支持，充分利用倚天硬件的能力；
对Arm Compute Library进行了一系列的定制和改进，解决其在dynamic shape及高并发场景下的各种可用性问题；
访存密集型算子CodeGen质量改进，包括Stitch-CPU对reshape类算子的支持从而支持更大粒度的kernel，以及op duplication策略的引入进一步减少访存量；

GPU上访存密集计算codegen性能增强

针对GPU上访存密集计算子图代码生成提供了一系列的深度优化，单个LayerNorm子图在常规推理shape下可带来最高2X的性能提升。主要的优化功能包括：

Fusion中若干独立控制流的合并。比如一个stitch fusion中包含多个独立的且shape相同的row reduce计算，则将这几个独立row reduce计算的控制流合并为同一个，一方面减少不必要的计算，另一方面增大ILP；
Row-reduce的schedule选择逻辑优化。针对不同的shape，选择更加合适的row reduce计算的的schedule；
优化element-wise fusion的向量化优化。通过指令交叉来支持element-wise fusion的数据读和计算的向量化；
Loop相关优化。添加loop unroll及instruction interleave优化，增大ILP；添加循环不变量外移优化，减少不必要的计算；
消除kernel的无效argument ，减小kernel launch开销。

以上功能可以通过设置变量来打开。

Shape Constraint IR

在这半年中我们完成Shape Constraint IR的设计和开发，通过将shape constraint作为第一等公民引入到IR中，可以方便我们充分挖掘计算图中蕴含的结构化约束，并以此来辅助完成一系列动态shape语意下的优化，进一步缩小与static shape compiler在优化空间上的差异。感兴趣的读者可以在这里了解我们的设计文档，也可以阅读我们在知乎上分享的技术文章 (link1, link2)。

对二次定制开发支持的增强

我们基于MLIR社区PDL的工作重构了BladeDISC中接入一个custom library call流程，极大的简化了相关的开发工作量。在新的方式下，用户只需要提供一个PDL的pattern描述文件，以及一个符合BladeDISC runtime接口的kernel，便可以在不重新编译BladeDISC的情况下，实现pattern的替换及对应kernel的调用，明显改进了BladeDISC对二次定制开发的支持。我们在量化这个场景下检验了新的基础设施的可用性及工程效率，感兴趣的同学可以参考这里和这里的例子。后续我们还将借助PDL和transform dialect进行进一步拓展，使得不仅仅是对custom kernel，也能对特定pattern的CodeGen策略进行定制。

Runtime Abstraction Layer 改进

大模型权重的支持：我们重构了常量（比如模型的权重参数）编译结果的存储格式，从基于protobuf改成了自定义的格式，从而去除了对const上限的约束，方便我们支持大模型的优化。

并发性能改进：针对高并发场景（比如同时服务数百路并发的推理请求）进行了一系列的优化，进一步缩小了kernel 调度以及共享资源锁同步的开销，在某语音识别200+并发的场景中进一步取得20%+的性能改进。

Ongoing Work

CUTLASS Gemm CodeGen

在GPU上接入了CUTLASS进行计算密集型算子的算子融合与代码生成，自动化地将GEMM及后续的element-wise（如GELU等激活函数子图、Tranpose算子等）进行计算融合与代码生成。目前GEMM + GELU及GEMM + Transpose的通路已经走通，且在BERT模型上取得了加速效果，鲁棒性正在提升中，可使用DISC_ENABLE_COMPUTE_INTENSIVE_FUSE=true设置来尝试使用。

MLIR Transform Dialect Based CodeGen

我们目前正在基于MLIR社区的transform dialect进行计算密集型相关pattern在dynamic shape语意下的代码生成，目前第一个目标是在AArch64平台上GEMM相关pattern达到与ACL相当的性能，以期通过白盒的方式彻底解决ACL在dynamic shape以及服务端多路请求并发的场景下的可用性问题，相关的工作的最新进展可以参见这里。

为阿里云负载均衡打开自动拦截功能

配置日志存储

负载均衡CLB（SLB）默认不启动日志存储功能，需要手工创建并启动。

在负载均衡管理面板中选择日志管理-访问日志中对应负载均衡最后的操作栏中，设置，按指引配置SLS日志存储

配置好后，显示的存储日志即可传入APIcat作为日志来源

配置拦截规则

拦截规则依托于负载均衡的访问控制功能，首先需要在访问控制中创建一个策略组，策略组名称即可传入APIcat作为拦截规则的目标设置组

设置AccessKey
正常运行APIcat除以上准备工作外，还需要为APIcat的运行申请一个Accesskey

在阿里云创建AccessKeyId和AccessKeySecret（头像，选择AccessKey管理），创建AccessKey或者子账户AccessKey都可以。

建议创建子账户AccessKey，子账户可以控制权限。可以选择AliyunSLBFullAccess或者自创建规则，包含slb的以下操作权限：

slb:AddAccessControlListEntry (写操作)
slb:DescribeAccessControlListAttribute (读操作)
slb:RemoveAccessControlListEntry (写操作)

以及日志权限

AliyunLogReadOnlyAccess

准备服务的OpenAPI定义

服务的OpenAPI定义可由开发生成，或者在线编辑

参数选择

完成以上设置之后，我们就可以运行APIcat（安装参考项目主页的说明）的watch命令实现实时读取日志，并实时配置拦截规则，运行参数如下

.apicat.exe watch -d .exampleopenapi.yaml –source aliyun –dest aliyun –aliyun-accesskey-id xx –aliyun-accesskey-secret xx –aliyun-region-id xx –aliyun-dest acl-xx project/logstore

参数设置包括

–source aliyun 设置为从阿里云日志读取

–dest aliyun 设置为配置到阿里云

–aliyun-accesskey-id xx –aliyun-accesskey-secret xx –aliyun-region-id xx

阿里云账户的accesskey-id和accesskey-secret，以及负载均衡所在的region的id

–aliyun-dest acl-xxx 阿里云负载均衡的控制规则名称

最后跟上存储日志的SLS地址即可。

后期可调整拦截的具体规则，具体参考这里

漏洞描述

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

Blender 是一个免费和开源的 3D 计算机图形软件工具集，用于创建动画电影、视觉效果、艺术、3D 打印模型、交互式 3D 应用、VR 和计算机游戏。随着 Blender 3.4 的发布，Blender 开发人员开始讨论提高 Blender 对 CPU 的要求，以便这款开源 3D 建模软件能更好发挥其性能。

目前运行 Blender 的最低要求是一个带有 SSE2 指令集或更新版本的 x86/x86_64 CPU ，SSE2 全名为Streaming SIMD Extensions 2，是一种 IA-32 架构的 SIMD(单一指令多重数据)指令集，在 2001 年随着 Intel 发表第一代 Pentium 4 处理器也一并推出。

当然，SSE2 实在是太古老了，只要不是 20 世纪的古董 CPU ，基本都能满足该要求。因此，Blender 开发者社区协调员 Thomas Dinges 发起了一场关于提高运行 Blender 的最低 CPU 要求的讨论，希望把 Blender 对 CPU 的最低要求改成 SSE4.1 指令集，SSE4.1 指令集随 2007 年英特尔的 45 纳米“ Penryn ”处理器发布。

跳到更高级的指令集有两个好处，首先更现代的 CPU 肯定能在 Blender 的各种繁重的计算功能中提高性能，其次，Blender Cycles 目前为 SSE2、SSE3、SSE41、AVX 和 AVX2 指令集分别编译各种内核，提高支持的指令级别可以减少软件的代码和编译时间。

除了升级到 SSE4.1 ，这次讨论还提到了升级到高级矢量扩展 (AVX) 的可能性，但 AVX 部分颇有争议，可能需要更多的意见和讨论，感兴趣的朋友可以通过这个 Blender DevTalk 进一步了解细节。

小众语言开源实践最需要注意的就是语言的基础设施问题，包括类似Maven的代码分发机制，辅助编程的language server protocol（LSP），甚至于统一的编译器。以Scheme语言为例，当前普遍使用的代码分发机制是Akku和Snow（开源中国甚至没收录这个软件），类似LSP的实现则有Emacs Geiser等。编译器和解释器简直五花八门，GNU的guile，公认具有堪比（未经优化的）C语言速度的Chez Scheme等等。

在进行开源的时候，需要认识到如下的这些要点：

小众语言的基础设施虽然弱，但是立足于其上的经济和社会力量的积累也是弱的。这就可以解释为什么TIOBE榜单后20名的小众编程语言仍然有活跃的项目和社区。现在虽然在编程上由于缺少基础设施而困难重重，但是若要获得更大的关注度和实现更多的成就，从小众语言入手一定能够比大众语言要快。
薄弱的基础设施一经加强就会“星星之火，可以燎原”。因为过去积累的，未曾使用这种基础设施的代码可以被快速规范化和通用化，实现Java的那种write once，run everywhere。特别是程序员的自我实现要求小众语言在社区和简历上充当在市场、职场竞争中的总参谋部。大浪之下或为鱼鳖潜底，或鹰隼敖翔，谁能够快速依托基础设施利用好留存代码，谁就能够取得竞争优势。
反对力量难以作用于小众语言基础设施的发展。在大的开源社区和组织中一些人相信了那种普遍的观念，即在企业与主流语言的练手镇压下不会存在任何一丝一毫的空间。这就产生了运动上的消极作用和悲观情绪，一部分人简直要把“红旗能打多久”之类的问题提出来了。但是决不能只看表象而不看实质。反对力量的反对力量当前还不是小众语言社区，而是其他反对力量。小众语言是跑马场，小众语言的基础设施是小马驹，它的存在就证明了它的不用扬鞭自奋蹄，是争取的对象。

中国开源社区的历史已经证明了，小众语言开源实践的个人依附于国外社区不在国内搞团结，就难以建立起扩大的、有广泛基础的开源社区。中国迫切需要一个由开源社区完全自治的运动：这个运动只能是由进行开源实践的个人开始；以争取团结更多人使用开源作品并提交更多代码为运动的手段；基础设施是这个运动的根据地，它让企业对私有的代码的依赖转化为对公有的代码的依赖，把知识产权的价值留在社区而不是私人老板。这个运动是在一天天的发展的，而且是以小众语言的基础设施的进步证明了的。

近日，北京名洋数字科技股份有限公司（简称“名洋集团”）签署openKylin社区CLA（Contributor License Agreement 贡献者许可协议），正式加入openKylin开源社区。

名洋集团创始于2003年，是国家高新技术企业、双软企业。公司聚焦民生和军工领域，投身数字中国建设，是以数字赋能传统产业的实践者和领跑者。企业基于会展全产业链二十年行业知识和资源的沉淀，形成多行业的大数据生产、治理、应用系统，充分利用AI、5G、物联网、区块链、数字孪生、宇宙等前沿数字技术和理念为会展、教育、军工、农林、食品等领域提供数字化产品和解决方案，让更多客户从数字经济的发展成果中受益。

截至目前，名洋集团已拥有数字会展（智会智展）、食品云、戏曲教育平台等数字化产品和军工、农林、医院等多领域解决方案及案例。

在加入openKylin社区后，名洋集团将结合公司的优势：行业相关经验、大数据和区块链技术与资源，以及专业团队，推进国产操作系统在会展、教育、食品等行业数字化领域的应用，推动相关领域设备的国产操作系统的适配和市场推广，推动openKylin社区生态及品牌建设，为我国桌面操作系统根社区的发展贡献力量。

社区会员持续招募中

审核：openKylin

以桌面应用为主的开源的Ubuntu桌面操作系统，为全球数百万的PC和笔记本电脑提供了生产力。

为方便用户选择合适的版本进行应用软件开发，我们发布了基于Ubuntu 64bit系统构建的Ubuntu16.04和Ubuntu18.04两个版本的 Ubuntu Desktop系统。

Ubuntu16.04和Ubuntu18.04 均具有资源占用少，稳定性强的特点。

采用简洁高效的轻量级Linux主流桌面环境Xfce4，为用户提供了一个默认GNOME 桌面环境之外的选择。

Ubuntu16.04和Ubuntu18.04 系统可定制性强，针对嵌入式平台，可以根据需求，增加裁剪系统服务。

基于Ubuntu系统，已经打通各通用底层接口。

提供基于Arm GE8300 GPU的OpenCL支持。
支持G2D加速
完美适配QT

目前宇芯已经应用Ubuntu16.04 和Ubuntu18.04 系统，开发了工业平板及智慧支付领域的系统解决方案，帮助客户产品快递开发并成功落地。

作者：李红建

责编：宇亭

在第一期研发分享中，我们解释了，为什么Tinamu作为一款列式存储引擎在初期不支持 Delete 功能的原因，然后对一些友商列式存储引擎的 Delete 方案进行了一些调研和总结，感兴趣的同学可以查看我们上一期的分享：关于列式数据库实现 Delete 功能的调研之旅。

本期文章，我将向社区小伙伴们详细地介绍一下给 StoneDB 的 Tianmu 存储引擎添加 Delete 功能的开发思路，希望对感兴趣的同学提供帮助。

Tianmu 引擎的存储结构

首先我们需要知道 Tianmu 引擎的数据是怎么样存储的，这样才知道应该怎么删除数据，所以我们先研究下 Tianmu 引擎的存储结构。Tianmu 为每个表单独建立了一个文件夹，以表名+tianmu 命名，每个表的文件夹下面又为各个列分别建立了对应列的文件夹，以列编号为名从 0 开始依次递增，列文件夹下面存储数据 DN 文件和实际列数据的 DATA 文件。

如上图所示，可以看到每个列文件夹下面有这么几个文件夹，其中：DATA 文件夹存储对应列 pack 的文件；DN 文件夹存储数据 DPN 的文件；filters 文件夹下存放着直方图、映射表、布隆过滤器（Bloom Filter）等中间数据的文件；META 文件夹存储了列的一些固有属性，如数据类型、版本、压缩类型等；v文件下存储了列数据的版本。

当然，可能一些同学乍一看上面的什么 DN、DPN 都不知道什么意思，其实是因为我们的 Tianmu 引擎使用了非常重要的知识网格（Knowledge Grid）技术，后面我们有时间会单独出更详细的文章来分享知识网格相关的最新研究。

如上图所示，DPN（Data Pack Node） 是知识网格的数据信息节点在代码中的数据结构，数据持久化在各个列文件夹下面的 DN 文件中，初始化数据信息节点时从利用 mmap机制把DN文件映射到内存中。pack 是物理的数据块，每个pack存储着对应列中多个列数据，pack 对象跟 DPN 对象 1:1 对应，负责从各个列文件夹下面的 DATA 文件写入数据和读取数据。pack 中的数据经过高度压缩后存储到 DATA 文件中。

Tianmu 的数据都是根据列按照行数据紧密排序进行存储的，从文件中读取和写入的单位是 pack，其中：

行号与 DPN & pack 的关系：

DPN id 由 row_id 进行位移右移运行得出， pss 的值一般为 16 ，也就是说每 65536 行的数据组成一个 pack，数据包结构的信息比如行与数据包的偏移量 pss, 数据化结构体为 COL_META 持久化在 META 文件中。

行号与 pack 中数据 id 的关系：

数据 ID 由 row_id 对 1 左移 pss 为后的值取余后得出，基本上数据ID也都是在 0~65536 之间。

可以看以下这幅图：

好了，以上就是我们对 Tianmu 引擎存储结构的一个简单介绍。

MySQL 的多引擎架构和执行接口

了解完 Tianmu 的存储结构后，我们就要去想如何进行删除的操作了，这个时候就需要用到 MySQL 的多引擎架构和执行接口了，因为我们要让用户使用 MySQL 客户端来进行 Tianmu 引擎里的删除操作。下图是 MySQL 的多引擎架构图：

可以看到，MySQL 架构的最大特点之一，就是支持可插拔存储引擎。再来看一下MySQL 的执行接口逻辑图：

这个部分，网络上的一些基础知识分享很多了，大家可以学习了解一下，我们这边特别要去讲解的是代码部分的逻辑，下面是我在 GDB 中调试的几个重要代码逻辑：

insert 调用堆栈：

update 调用堆栈：

delete调用堆栈：

由调用堆栈可知，insert、update和delete的相关代码指令都会调用到Tianmu::dbhandler::TianmuHandler 类中各自功能的函数，而 TianmuHandler 继承自 handler，MySQL 以 handler 为基类，各个引擎的 handler 类为子类，利用多态的原理实现对不同引擎的调用。

如果要实现Tianmu的单表 delete 功能，就需要在 TianmuHandler :: delete_row() 中进行实现。同时 handler 类还提供了删除所有行的虚函数 delete_all_rows() 如需支持删除所有行的数据，可在TianmuHandler :: delete_all_rows() 中进行实现。

Tianmu 引擎删除数据的过程

由此，我们便可以对 Tianmu 的delete功能进行设计和研发了。下面是我调研实现 delete 功能的流程图：

单表 delete all 功能：

目前我们是支持 truncate 功能的，单表 delete all 的功能就直接复用 truncate 的逻辑。

条件 delete 功能：

条件 delete 这里我们采用标记删除的策略。列式数据库的存储结构决定了对真实的数据进行删除时必须要对整个表的数据进行重新移动整理，因为除了删除无用的行，还需要合并数据块。这样的话，在数据量非常多的情况下，对真实的数据进行删除将会是非常大的动作，不仅会消耗机器大量的IO资源和CPU资源，同时删除的速度也会比较慢。这也是目前主流支持列式数据库的厂商都使用标记删除的原因。

注意看上面的执行流程图，我们会发现一个很重要的节点——Deletebitmap（Delete位图），这个 Delete 位图是什么呢？这里要重点讲解一下。

位图（bitmap）的实际存储形式是个 int32 类型的数组，原理是使用 int32 类型的值占用的 32 位空间使用 0 或 1 存储并记录这 32 个值的状态。位图中的比特总数等于包中的行的总数。数据在 pack 中的位置和位图中的位置是一一对应的，这样可以有效地节省空间。

那么 Delete 位图应该存放在哪个位置呢？一般有这么四种方案：

方案1.存放在pack里：

优点：进行标记删除的时候同时可对数据置空，可有效的释放字符串类型的空间，同时可优化 select ,insert ,update 带where子句的数据过滤场景。不需要修改上层逻辑。整体逻辑简单。修改面主要集中在pack层。

缺点：每次删除都需要对涉及的pack进行读取解压缩/压缩。（其他方案在修改数据时也需要对pack进行读取解压缩）

方案2.存放DPN里：

优点：删除不需要对 pack 进行读取保存，只需要修改数据即可，且 delete 位图大小是固定的。

缺点：delete 位图过大，一般是 8192 个字节，远远超过原本数据的大小，会极大的影响原 DPN 的读写效率。

方案3. RCAttr::hdr 中：

优点：
一个列中只需要维护一个delete位图即可，节省存储空间。

缺点：
因为列的数据数量是会随时变化的，不像 pack 和DPN 维护的单独一个包数据的数量是固定的，这就造成了，delete位图的大小也需要随时变化。

方案4. 为每列新增 deleteBitMap 文件：

在 DPN中增加 deletBitMap 索引，与 deleteBitMap 文件中的 deleteBitMap 对应，如下图：

优点：
可以与 DPN 一一对应，且 delete 位图大小固定。

缺点：
需要新增一个文件专门维护 delete bitmap ,读取 DPN 文件的同时也需要读取 delelte bitmap 文件，会增加一次 IO。

我们最后的选择

最后，经过综合考量，我们这里使用了方案 1 进行了把 delete 位图放到 pack 里进行标记 delete 功能的开发。

数据过滤的流程和涉及逻辑的改造

经过上述的思路梳理，我们应该大致能清晰地了解到增加 Delete 功能的流程，因为涉及的东西比较多，我这里做了一个脑图，具体的代码，大家可以访问我们的Github 代码仓库进行了解：https://github.com/stoneatom/stonedb

其中Tianmu引擎存储的数据和pack数据是支持多版本的，这样可以保障数据的原子性，而且可以支持并发的读取数据，也就是说，在执行delete时并不会堵塞select，用户访问的数据是最终确定的版本。关于多版本和并发访问控制会在以后单独出文章进行详细的讲解。

好了，以上就是目前 StoneDB 自研列式引擎 Tianmu 对 Delete的实现思路，希望这两期分享能给大家带来帮助。当然，由于是文章，里面很多图片的细节，我们没有展开描述，之前我们有开展过技术分享公开课，大家也可以前往B站观看这两期视频：

【StoneDB每日讲】Tianmu 引擎 Delete 方案的调研-第一讲

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

【StoneDB每日讲】Tianmu 引擎 Delete 功能的诞生-第二讲

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

本周四，StoneDB启航计划的源码解读活动，李红建老师也会带大家深入理解一下Tinamu 引擎工具类模块的源码，欢迎大家关注收看：

StoneDB 开源地址：https://github.com/stoneatom/stonedb

StoneDB 社区官网：https://stonedb.io

添加小助手，加入社区交流群

与数百位资深数据库从业人员深度交流

子查询优化之 Semi-join 优化 | StoneDB 研发分享 #2

HTAP 的下一步？SoTP 初探（下）：解读 Serving over TP 和其典型案例场景

2023 年十大战略技术趋势中哪一项最需要 HTAP ？

HTAP 的下一步？SoTP初探(上)：数据分析从“大”数据转向“小”而“宽”数据

存算一体 VS 存算分离，IT发展下的技术迭代

没有HTAP，机器学习和人工智能都是不切实际的

面向场景，HTAP到底是刚需还是炒作？

StoneDB 团队成员与 MySQL 之父 Monty 会面，共话未来数据库形态

实现HTAP的关键技术有哪些？

解读《Benchmarking Hybrid OLTP&OLAP Database Systems》

深度干货！一篇Paper带您读懂HTAP

摘要：随着各领域加快向数字化、移动化、互联网化的发展，企业信息环境变得庞大复杂，身份和权限管理面临巨大的挑战。

本文分享自华为云社区《面对庞大复杂的身份和权限管理，企业该怎么办？》，作者：华为云PaaS服务小智。

随着各领域加快向数字化、移动化、互联网化的发展，企业信息环境变得庞大复杂，身份和权限管理面临巨大的挑战：

应用规模快速增长，存在信息孤岛。各个应用系统的访问入口和帐号孤立分散在各自系统中，缺乏统一的用户管理体系，造成在流程效率、信息安全、风控管理方面存在诸多风险问题。
用户数快速增长，用户维度扩大。用户、组织生命周期管理无统一的IT工具，人工管理低效易错。
用户身份和权限，缺乏统一管理平台。人员流动（离职、转岗等）后帐号和权限无法自动更新状态，造成帐号泄密；无审计日志，帐号操作无法追溯。
信息化发展，认证要求提高。传统的应用系统仅支持静态密码一种认证方式，无法兼顾易用和不同等级应用的安全性。

面对以上挑战，传统的身份和权限管理系统已无法应对，我们可以怎么做呢？这里先给大家介绍IAM和IDaaS，这两个与身份和权限管理系统息息相关的概念。

什么是IAM和IDaaS

IAM（Identity and Access Management的缩写），即“身份与访问管理”，它提供单点登录、认证管理、集中的授权和审计，帮助企业安全、高效地管理IT系统的帐号和资源权限，传统的IAM服务虽然解决了部分身份问题，但是开发效率低，成本浪费严重。

IDaaS（Identity As a Service的缩写），即“身份即服务”，IDaaS=IAM+SaaS，是云计算时代、SaaS服务兴起的产物，是一种云化的身份与访问管理服务，由第三方云服务厂商构建并维护。与传统IAM相比，IDaaS为身份认证带来了SaaS的成本优势，且适配性更强、安全性更高，可处理更大规模、更加复杂的数据。

华为云应用身份管理服务OneAccess

OneAccess是华为云提供的IDaaS服务，是贯穿企业业务流程的身份访问管理系统。提供集中式的身份管理、认证、授权、监控和审计平台，保证合法的用户、以适当的权限访问受信任的的应用系统，并对异常访问行为进行实时预警和有效防范，为企业构建“零信任”的安全架构提供身份基础设施，提供的核心能力如下：

| 多源身份管理

融合客户多个身份源，为上层应用提供一致的身份服务；为帐号提供从注册到注销的全生命周期管理；管理企业内部的组织架构、用户身份，真正实现人与帐号一一对应。

| 多维度多粒度的权限管理

提供4种粒度权限管理模型（平台级、大门级、应用预置级和细粒度）。其中：平台级提供管理员的分权分域管理后台；大门级为普通用户提供访问应用系统的常用权限管理；应用预置级提供应用内置角色的控制能力；细粒度提供应用系统精确到菜单、按钮的控制能力。

| 融合认证能力

支持密码、动态密码OTP、短信验证码、二维码、图形码能力，支持对接指纹、人脸等生物认证系统、CA数字证书；除单一认证方式外，还支持双因素、多因素MFA认证。

| 标准化SSO单点登录

提供行业主流的OAuth、SAML、CAS、OIDC标准协议，同时支持插件代填的方式实现对无接口应用系统的集成。

| 国内领先的预集成能力

支持4种行业标准SSO协议（OAuth、SAML、OIDC、CAS），预集成1050+行业应用，17类社交认证源（含Welink、钉钉、微信、支付宝和等），9个行业身份源（含AD、飞书、SAP等），极大缩短客户的上线时间。

| 提供跨越企业内网的专属通道云桥

云桥是一个应用级安全代理，其目的是在企业内网和OneAccess服务之间建立起一条安全通道，支持OneAccess对接企业内的身份和认证资源（例如：Windows AD），核心优势包括数据安全性、高有用和请求专有性。

OneAccess应用场景

OneAccess支持云办公、智慧园区、智慧城市、智慧交通、金融和教育等多个解决方案和典型行业，下面以云办公场景为例。

云办公场景下企业往往会面临很多典型问题：

人事事件无法业务协同，安全性差：在每次员工入职、离职、调岗等人事事件发生时，各个应用管理员需分别在各个系统中开通帐号或维护帐号。
缺少统一的企业自认证，安全性差：员工使用云办公系统帐号登录后，缺少统一的企业二次认证能力，信息安全得不到保障。
应用多样，员工使用不便：日常工作中使用了多套应用系统，每人有多个应用系统帐号，既有公有云的SaaS应用，也有本地部署的应用，需要在云办公系统和应用之间来回切换登录。

OneAccess身份访问管理方案是如何解决上述问题的呢？

| 身份全生命周期管理，保障企业信息安全

人员入职、离职、转岗等人事变动，客户只需要维护身份源系统（例如：Windows AD、LDAP等）的人员变化，OneAccess定期同步身份源系统的用户信息，保证人员信息时刻准确，简化企业对人员的管理：

效果示例：

| 通过认证协议对接云办公系统，支持企业员工完成二次认证

企业员工变动频繁，如若不及时更新各个应用系统的帐号，离职人员访问企业内部系统，会造成信息泄露。企业员工登陆云办公系统后，可使用已有的身份源帐号进行企业二次认证，OneAccess支持通过OAuth 2.0等协议与云办公系统完成认证：

以国内某大型电子科技企业案例为例, OneAccess与华为云办公会议系统Welink集成，解决客户基础业务能力，包括身份管理、应用集成、单点登录、云办公等服务，效果如下：

| 提供单点登录，串接所有应用系统，统一应用权限管理

企业应用系统通过标准SSO协议集成到OneAccess，利用OneAccess的单点登录能力，做到一个帐号，一次认证，登录所有应用系统；将云办公系统作为认证源集成到OneAccess后，员工就可以在云办公系统中免密登录所有企业应用系统；利用OneAccess的应用权限管理，自动控制员工对应用系统的访问权限，减少企业管理员的维护成本：

以上述大型电子科技企业客户为例，效果如下：

OneAccess已助力多个客户完成了身份访问管理、云办公的建设，帮助客户实现了降本增效，同时保证了企业身份安全性以及办公效率，有助于客户品牌形象的进一步提升，推动企业数字化转型以及信息安全。

目前OneAccess已上架华为云国内站，想了解更多信息，链接，立即体验！

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

摘要：介绍Python和OpenGL的入门知识，包括安装、语法、基本图形绘制等。

本文分享自华为云社区《[Python图像处理] 二十七.OpenGL入门及绘制基本图形（一）》，作者：eastmount。

一.OpenGL入门知识

1.什么是OpenGL

OpenGL(Open Graphics Library，译为“开放式图形库”) 是用于渲染2D、3D矢量图形的跨语言、跨平台的应用程序编程接口（API）。这个接口由近350个不同的函数调用组成，用来绘制从简单的图形件到复杂的三维景象。OpenGL常用于CAD、虚拟现实、科学可视化程序和电子游戏开发。

OpenGL可用于设置所需的对象、图像和操作，以便开发交互式的3维计算机图形应用程序。OpenGL被设计为一个现代化的、硬件无关的接口，因此我们可以在不考虑计算机操作系统或窗口系统的前提下，在多种不同的图形硬件系统上，或者完全通过软件的方式实现OpenGL的接口。OpenGL的高效实现（利用了图形加速硬件）存在于Windows，部分UNIX平台和Mac OS。这些实现一般由显示设备厂商提供，而且非常依赖于该厂商提供的硬件。

OpenGL规范由1992年成立的OpenGL架构评审委员会（ARB）维护。ARB由一些对创建一个统一的、普遍可用的API特别感兴趣的公司组成。到了今天已经发布了非常多的OpenGL版本，以及大量构建于OpenGL之上以简化应用程序开发过程的软件库。这些软件库大量用于视频游戏、科学可视化和医学软件的开发，或者只是用来显示图像。

一个用来渲染图像的OpenGL程序需要执行的主要操作如下：

从OpenGL的几何图中设置数据，用于构建形状
使用不同的着色器（shader）对输入的图数据执行计算操作，判断它们的位置、颜色，以及其他渲染属性
将输入图的数学描述转换为与屏幕位置对应的像素片（fragment），这一步也称作光栅化（rasterization）
最后，针对光栅化过程产生的每个片，执行片着色器（fragment shader），从而决定这个片的最终颜色和位置
如果有必要，还需要对每个片执行一些额外的操作，例如判断片对应的对象是否可见，或者将片的颜色与当前屏幕位置的颜色进行融合

2.OpenGL安装

作者的电脑环境为Win10+Python3.7，打开CMD调用pip工具进行安装，如下图所示。

但通常安装成功之后，运行代码会报错“OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInit, check for bool(glutInit) before calling”。

据说是pip默认安装的是32位版本的pyopengl，而作者的操作系统是64位。网上很多大牛会去 “https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl” 网站下载适合自己的版本。比如Python3.7且64位操作系统。

安装流程如下所示：

写到这里，我们Python的OpenGL库就安装成功了！

二.OpenGL入门程序

我们首先介绍两个入门代码，然后再进行深入的讲解。

1.OpenGL绘制正方形

完整代码如下：

运行结果如下图所示：

核心步骤如下：

主函数使用glut库初始化OpenGL
glutInit()
设置显示模式并初始化glut窗口（画布）
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA)
glutInitWindowSize(400, 400)
glutCreateWindow(“eastmount”)
注册绘制图像的回调函数，如display()
glutDisplayFunc(display)
绘制图像display函数，包括清除画布、设置颜色、绘制图、设置定点、结束绘制、刷新执行
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)
glColor3f(1.0, 0.0, 0.0)
glBegin(GL_QUADS)
glVertex3f(-0.5, -0.5, 0.0)
glVertex3f(0.5, -0.5, 0.0)
glVertex3f(0.5, 0.5, 0.0)
glVertex3f(-0.5, 0.5, 0.0)
glEnd()
glFlush()
进入glut主循环
glutMainLoop()

2.OpenGL绘制水壶

接着补充一段经典的水壶代码，所有计算机试卷、计算机图形学、3D图像领域都会绘制它。

运行结果如下图所示，它主要调用glutSolidTeapot(0.5)函数绘制实现实心茶壶，glutWireTeapot(0.5)函数绘制线框茶壶。

注意，glut提供了一些现成的绘制立体的API，如glutWireSphere绘制球、glutWireCone绘制椎体、glutWireCube绘制立体、glutWireTorus绘制甜圈、glutWireTeapot绘制茶壶、glutWireOctahedron绘制八面体，请读者自行提升。

3.OpenGL绘制多个图形

接下来绘制一个坐标系，并分别绘制四个图形，设置不同颜色，代码如下所示。

输出结果如下图所示：

4.OpenGL绘图代码及原理详解

该部分将详细讲解上面三段代码的核心知识，帮助大家巩固基础。作者让大家先看代码及其运行效果，从而提升OpenGL编程兴趣，再深入分析其原理，这种倒叙的方式希望您们喜欢。

(1) 核心函数

上述代码中，以glut开头的函数都是GLUT工具包所提供的函数。

glutInit()：对GLUT进行初始化，该函数必须在其它的GLUT使用之前调用一次。其格式比较死板，一般glutInit()直接调用即可。
glutInitDisplayMode()：设置显示方式，其中GLUT_RGB表示使用RGB颜色，与之对应的是GLUT_INDEX（表示使用索引颜色）；GLUT_SINGLE表示使用单缓冲，与之对应的是GLUT_DOUBLE（表示使用双缓冲）。更多参数请读者阅读官方网站或Google。
glutInitWindowPosition()：设置窗口在屏幕中的位置。
glutInitWindowSize()：设置窗口的大小，两个参数表示长度和宽度。
glutCreateWindow()：根据当前设置的信息创建窗口，参数将作为窗口的标题。需要注意的是，当窗口被创建后，并不是立即显示到屏幕上，需要调用glutMainLoop()才能看到窗口。
glutDisplayFunc()：设置一个函数，当需要进行画图时，这个函数就会被调用，通常用来调用绘制图形函数。
glutMainLoop()：进行一个消息循环，大家需要知道这个函数可以显示窗口，并且等待窗口关闭后才会返回。

以gl开头的函数都是OpenGL的标准函数。

glClear()：清除，其中参数GL_COLOR_BUFFER_BIT表示清除颜色，GL_DEPTH_BUFFER_BIT表示清除深度。
glRectf()：画一个矩形，四个参数分别表示位于对角线上的两个点的横、纵坐标。
glFlush()：刷新显示图像，保证前面的OpenGL命令立即执行，而不是让它们在缓冲区中等待。
OpenGL要求指定顶点的命令（glVertex2f）必须包含在glBegin()函数和glEnd()函数之间执行。

(2) 绘制顶点

顶点（vertex）是 OpengGL 中非常重要的概念，描述线段、多边形都离不开顶点。它们都是以glVertex开头，后面跟一个数字和1~2个字母，比如：

glVertex2d
glVertex2f
glVertex3f
glVertex3fv

数字表示参数的个数，2表示有2个参数（xy坐标），3表示三个（xyz坐标），4表示四个（齐次坐标 w）。字母表示参数的类型，s表示16位整数（OpenGL中将这个类型定义为GLshort），i表示32位整数（OpenGL中将这个类型定义为GLint和GLsizei），f表示32为浮点数（OpenGL中将这个类型定义为GLfloat和GLclampf），d表示64位浮点数（OpenGL中将这个类型定义为GLdouble和GLclampd）。例如：

glVertex2i(1, 3)
glVertex2f(1.0, 3.0)
glVertex3f(1.0, 3.0, 1.0)
glVertex4f(1.0, 3.0, 0.0, 1.0)

注意，OpenGL中很多函数都采用这种形式命名。

(3) 设置颜色

在OpenGL中，设置颜色函数以glColor开头，后面跟着参数个数和参数类型。参数可以是0到255之间的无符号整数，也可以是0到1之间的浮点数。三个参数分别表示RGB分量，第四个参数表示透明度（其实叫不透明度更恰当）。以下最常用的两个设置颜色的方法：

glColor3f(1.0，0.0，0.0) #红色
glColor3f(0.0，1.0，0.0) #绿色
glColor3f(0.0，0.0，1.0) #蓝色
glColor3f(1.0，1.0，1.0) #白色
glColor4f(0.0，1.0，0.0，0.0) #红色且不透明度
glColor3ub(255, 0, 0) #红色

注意，OpenGL是使用状态机模式，颜色是一个状态变量，设置颜色就是改变这个状态变量并一直生效，直到再次调用设置颜色的函数。除了颜色，OpenGL 还有很多的状态变量或模式。

(4) 绘制基本图形

前面我们介绍了各种图像，下表展示了常见的图像件。

GL_POINTS：绘制顶点
GL_LINES：绘制线段
GL_LINE_STRIP：绘制连续线段
GL_LINE_LOOP：绘制闭合的线段
GL_POLYGON：绘制多边形
GL_TRIANGLES：绘制三角形
GL_TRIANGLE_STRIP：绘制连续三角形
GL_TRIANGLE_FAN：绘制多个三角形组成的扇形
GL_QUADS：绘制四边形
GL_QUAD_STRIP：绘制连续四边形

详见下图所示。

三.OpenGL基础知识

在深入学习OpenGL之前，我们有必要了解一些最常用的图形学名词、OpenGL原理和语法。

1.OpenGL语法

OpenGL程序的基本结构通常包括——初始化物体渲染所对应的状态、设置需要渲染的物体。渲染（render）表示计算机从模型创建最终图像的过程，OpenGL只是其中一种渲染系统。模型（model）或者场景对象是通过几何图，比如点、线和三角形来构建的，而图与模型的顶点（vertex）也存在着各种对应的关系。

OpenGL另一个最本质的概念叫着色器，它是图形硬件设备所执行的一类特色函数。可以将着色器理解为专为图形处理单（GPU）编译的一种小型程序。在OpenGL中，会用到始终不同的着色阶段（shader stage），最常用的包括顶点着色器（vertex shader）以及片着色器，前者用于处理顶点数据，后者用于处理光栅化后的片数据。所有的OpenGL程序都需要用到这两类着色器。最终生成的图像包含了屏幕上绘制的所有像素点。像素（pixel）是显示器上最小的可见单。计算机系统将所有的像素保存到帧缓存（framebuffer）当中，后者是由图形硬件设备管理的一块独立内存区域，可以直接映射到最终的显示设备上。

正如前面您看到的，OpenGL库中所有的函数都会以字符“gl”作为前缀，然后是一个或者多个大写字母开头的词组，以此来命令一个完整的函数（例如glBindVertexArray()）。OpenGL的所有函数都是这种格式，上面看到的“glut”开头的函数，它们来自第三方库OpenGL Utility Toolkit（GLUT），可以用来显示窗口、管理用户输入以及执行其他一些操作。

与函数命名约定类似，OpenGL库中定义的常量也是GL_COLOR_BUFFER_BIT的形式，常量以GL_作为前缀，并且使用下划线来分割单词。这些常量的定义是通过#define来完成的，它们基本可以在OpenGL的头文件glcorearb.h和glext.h中找到。

为了能够方便地在不同的操作系统之间移植OpenGL程序，它还为函数定义了不同的数据类型，例如GLfloat是浮点数类型。此外，比如glVertex*()的函数，它有多种变化形式，如glVertex2d、glVertex2f。在函数名称的“核心”部分之后，通过后缀的变化来提示函数应当传入的参数，通常由一个数字和1~2个字母组成。glVertex2f()中的“2”表示需要传入2个参数，f表示浮点数。

2.老式OpenGL vs 现代OpenGL

(1) 老式OpenGL

在大多数计算机图形系统中，绘图的方式是将一些顶点发送给处理管线，管线由一系列功能模块互相连接而成。最近，OpenGL应用编程接口（API）从固定功能的图形管线转换为可编程的图形管线。

如下图绘制正方形的代码，它使用的是老式OpenGL，要为三维图（在这个代码中，是一个GL_QUADS即矩形）指定各个顶点，但随后每个顶点需要被分别发送到GPU，这是低效的方式。 这种老式编程模式伸缩性不好，如果几何图形变得复杂，程序就会很慢。对于屏幕上的顶点和像素如何变换，它只提供了有限的控制。

后续我们将专注于现代的OpenGL，但是网络上也会有老式OpenGL的例子。

(2) 现代OpenGL

现代OpenGL利用一系列的操作，即通过“三维图形管线”绘制图形，其基本流程如下图所示。

简化三维图形管线分为6步：

三维几何图形定义（VBO等）。 在第一步，通过定义在三维空间中的三角形的顶点，并指定每个顶点相关联的颜色，我们定义了三维几何图形。
顶点着色器。 接下来，变换这些顶点：第一次变换将这些顶点放在三维空间中，第二次变换将三维坐标投影到二维空间。根据照明等因素，对应顶点的颜色值也在这一步中计算，这在代码中通常称为“顶点着色器”。
光栅化。 将几何图形“光栅化”（从几何物体转换为像素）。
片段着色器。 针对每个像素，执行另一个名为“片段着色器”的代码块。正如顶点着色器作用于三维顶点，片段着色器作用于光栅化后的二维像素。
帧缓冲区操作（深度测试、混合等）。 最后，像素经过一系列帧缓冲区操作，其中，它经过“深度缓冲区检验”（检查一个片段是否遮挡另一个）、“混合”（用透明度混合两个片段）以及其他操作，其当前的颜色与帧缓冲区中该位置已有的颜色结合。
帧缓冲区。 这些变化最终体现在最后的帧缓冲区上，通常显示在屏幕上。

PS：该部分参考Mahesh Venkitachalam大神编写的《Python极客项目编程》，代码可以查看：https://github.com/electronut/pp

3.OpenGL绘制时钟

最后补充“xiaoge2016老师”的一段趣味代码，通过OpenGL绘制时钟，注意它是跳动的。

其运行结果如下图所示：

四.总结

本篇文章主要讲解Python和OpenGL基础知识，包括安装、基础语法、绘制图形等。希望对读者有一定帮助，也希望这些知识点为读者从事Python图像处理相关项目实践或科学研究提供一定基础。

参考文献：

[1] 《OpenGL编程指南（第8版）》作者：Dave Shreiner Granham Sellers等，王锐译
[2] 《Python极客项目编程》作者：Mahesh Venkitachalam，王海鹏译
[3] 《OpenGL编程精粹》杨柏林陈根浪徐静编著
[4] 写给 python 程序员的 OpenGL 教程 – 许老师(天浪子)
[5] Python之OpenGL笔记(2)：现代OpenGL编程常用的几个通用函数 – 大龙老师
[6] python3+OpenGL环境配置 – GraceSkyer老师
[7] VS2012下基于Glut OpenGL显示一些立体图形示例程序 – yearafteryear老师
[8] Python——OpenGL – 白季飞龙老师
[9] python+opengl显示三维模型小程序 – xiaoge2016
[10] https://github.com/electronut/pp

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

通过或者在配置文件设置 Redis 内存占用限制。当达到内存最大值值，会触发内存淘汰策略删除数据。

除此之外，当 key 达到过期时间，Redis 会有以下两种删除过期数据的策略：

后台定时任务选取部分数据删除；
惰性删除。

具体原理请移步《Redis 的过期数据删除那些事》。

假设 Redis 实例保存了 5GB 的数据，现在删除了 2GB 数据，Redis 进程占用的内存一定会降低么？（也叫做 RSS，进程消耗内存页数）。

答案是：可能依然占用了大约 5GB 的内存，即使 Redis 的数据只占用了 3GB 左右。

大家一定要设置，否则 Redis 会继续为新写入的数据分配内存，无法分配就会导致应用程序报错，当然不会导致宕机。

释放的内存去哪了

明明删除了数据，使用 top 命令查看，为何还是占用了那么多内存？

内存都去哪了？使用命令获取 Redis 内存相关指标，我列举了几个重要的数据：

Redis 进程内存消耗主要由以下部分组成：

Redis 自身启动所占用的内存；
存储对象数据内存；
缓冲区内存：主要由 client-output-buffer-limit 客户端输出缓冲区、复制积压缓冲区、AOF 缓冲区。
内存碎片。

Redis 自身空进程占用的内存很小可以忽略不计，对象内存是占比对打的一块，里面存储着所有的数据。

缓冲区内存在大流量场景容易失控，造成 Redis 内存不稳定，需要重点关注。

内存碎片过大会导致明明有空间可用，但是却无法存储数据。

碎片 = used_memory_rss 实际使用的物理内存（RSS 值）除以 used_memory 实际存储数据内存。

什么是内存碎片

内存碎片会造成明明有内存空间空闲，可是却无法存储数据。举个例子，你跟漂亮小姐姐去电影院看电影，肯定想连在一块坐。

假设现在有 8 个座位，已经卖出了 4 张票，还有 4 张可以买。可是好巧不巧，买票的人很奇葩，分别间隔一个座位买票。

即使还有 4 个座位空闲，可是你却买不到两个座位连在一块的票，厚礼蟹！

内存碎片形成原因

内存碎片是什么原因导致呢？

主要有两个原因：

内存分配器的分配策略。
键值对的大小不一样和删改操作：Redis 频繁做更新操作、大量过期数据删除，释放的空间（不够连续）无法得到复用，导致碎片率上升。

接下来我分别探讨实际发生的原因……

内存分配器的分配策略

Redis 默认的内存分配器采用 jemalloc，可选的分配器还有：glibc、tcmalloc。

内存分配器并不能做到按需分配，而是采用固定范围的内存块进行分配。

例如 8 字节、16 字节…..，2 KB，4KB，当申请内存最近接某个固定值的时候，jemalloc 会给它分配最接近固定值大小的空间。

这样就会出现内存碎片，比如程序只需要 1.5 KB，内存分配器会分配 2KB 空间，那么这 0.5KB 就是碎片。

这么做的目的是减少内存分配次数，比如申请 22 字节的空间保存数据，jemalloc 就会分配 32 字节，如果后边还要写入 10 字节，就不需要再向操作系统申请空间了，可以使用之前申请的 32 字节。

删除 key 的时候，Redis 并不会立马把内存归还给操作系统，出现这个情况是因为底层内存分配器管理导致，比如大多数已经删除的 key 依然与其他有效的 key分配在同一个内存页中。

另外，分配器为了复用空闲的内存块，原有 5GB 的数据中删除了 2 GB 后，当再次添加数据到实例中，Redis 的 RSS 会保持稳定，不会增长太多。

因为内存分配器基本上复用了之前删除释放出来的 2GB 内存。

键值对大小不一样和删改操作

由于内存分配器是按照固定大小分配内存，所以通常分配的内存空间比实际数据占用的大小多一些，会造成碎片，降低内存的存储效率。

另外，键值对的频繁修改和删除，导致内存空间的扩容和释放，比如原本占用 32 字节的字符串，现在修改为占用 20 字节的字符串，那么释放出的 12 字节就是空闲空间。

如果下一个数据存储请求需要申请 13 字节的字符串，那么刚刚释放的 12 字节空间无法使用，导致碎片。

碎片最大的问题：空间总量足够大，但是这些内存不是连续的，可能大致无法存储数据。

内存碎片解决之道

那该如何解决呢？

首先要确定是否发生了内存碎片，重点关注前面命令提示的指标，表示内存碎片率：

如果 1 < 碎片率 < 1.5，可以认为是合理的，而大于 1.5 说明碎片已经超过 50%，我们需要采取一些手段解决碎片率过大的问题。

重启大法

最简单粗暴的方式就是重启，如果没有开启持久化，数据会丢失。

开启持久化的话，需要使用 RDB 或者 AOF 恢复数据，如果只有一个实例，数据大的话会导致恢复阶段长时间无法提供服务，高可用大打折扣。

咋办呢？码哥靓仔

自动清理内存碎片

既然你都叫我靓仔了，就倾囊相助告诉你终极杀招：Redis 4.0 版本后，自身提供了一种内存碎片清理机制。

怎么清理呢？

很简单，还是上面的例子，想要买两张连在一块的电影票。与与别人沟通调换下位置，就实现了。

对于 Redis 来说，当一块连续的内存空间被划分为好几块不连续的空间的时候，操作系统先把数据以依次挪动拼接在一块，并释放原来数据占据的空间，形成一块连续空闲内存空间。。

如下图所示：

自动清理内存碎片的代价

自动清理虽好，可不要肆意妄为，操作系统把数据移动到新位置，再把原有空间释放是需要消耗资源的。

Redis 操作数据的指令是单线程，所以在数据复制移动的时候，只能等待清理碎片完成才能处理请求，造成性能损耗。

如何避免清理碎片对性能的影响又能实现自动清理呢？

好问题，通过以下两个参数来控制内存碎片清理和结束时机，避免占用 CPU 过多，减少清理碎片对 Redis 处理请求的性能影响。

开启自动内存碎片清理

这只是开启自动清理，何时清理要同时满足以下两个条件才会触发清理操作。

清理的条件

：内存碎片占用的内存达到 200MB，开始清理；

：内存碎片的空间占惭怍系统分配给 Redis 空间的 20% ，开始清理。

避免对性能造成影响

清理时间有了，还需要控制清理对性能的影响。由一项两个设置先分配清理碎片占用的 CPU 资源，保证既能正常清理碎片，又能避免对 Redis 处理请求的性能影响。

：自动清理过程中，占用 CPU 时间的比例不低于 20%，从而保证能正常展开清理任务。

：自动清理过程占用的 CPU 时间比例不能高于 75%，超过的话就立刻停止清理，避免对 Redis 的阻塞，造成高延迟。

总结

如果你发现明明 Redis 存储数据的内存占用远小于操作系统分配给 Redis 的内存，而又无法保存数据，那可能出现大量内存碎片了。

通过命令，看下内存碎片指标是否正常。

那么我们就开启自动清理并合理设置清理时机和 CPU 资源占用，该机制涉及到内存拷贝，会对 Redis 性能造成潜在风险。

如果遇到 Redis 性能变慢，排查下是否由于清理碎片导致，如果是，那就调小的值。

码哥创建了技术群摸鱼群，想要与各个城市的程序员一起摸鱼打屁聊人生学技术就加群吧。

最后，可以我叫我一声靓仔么？你有什么问题想对码哥说么？在留言区留言吧，知无不言。

点赞、收藏、分享走起！

参考

[1].Redis 核心技术与实战

[2].https://juejin.cn/post/#heading-4

[3].https://redis.io/docs/reference/optimization/memory-optimization/#memory-allocation

作为云平台用户，我们都希望购买的服务器物尽其用，能够达到最大利用率。然而要达到理论上的节点负载目标是很的，计算节点总是存在一些装箱碎片和低负载导致的闲置资源。下图展示了某个生产系统的CPU资源现状，从图中可以看出，浪费主要来自以下几个方面：

业务需求与节点可调度资源很难完全匹配，因此在每个节点上都可能剩余一些碎片资源无法被分配出去。
业务通常为了绝对稳定，会申请超出自身需求的资源，这会导致业务锁定了资源但事实上未能有效利用。
资源用量存在波峰波谷，很多在线业务都是有着规律性的服务高峰和低峰的，如通常白天负载较高，资源用量较大，而夜间在线访问降低，资源用量也会跌入低谷。

Crane提供了Request推荐、副本数推荐、HPA推荐以及EPA等业务优化能力，能辅助业务自动化决策进行资源配置优化。然而在较大的组织中，业务改需要所有业务组件负责人的支持和配合，周期长、见效慢。如何在不改造业务的前提下，迅速提升集群资源利用率，在提升部署密度的同时保证延迟敏感和高优业务的稳定性和服务质量不受干扰，Crane混部能力给出了答案。

Crane提供了高优敏感业务与低优批处理业务的混部能力，能将集群利用率提升3倍！

混部的核心挑战

所谓混部，就是将不同优先级的工作负载混合部署到相同集群中。一般来说，支撑在线服务的延迟敏感型（Latency Sensitive）业务优先级较高，支撑离线计算的高吞吐型（Batch）业务优先级通常较低。

看起来将这些不同类型的业务部署在相同集群，复用计算资源，就可以有效提升资源利用率，那么为什么混部只有在顶尖科技公司才有大规模应用呢？理想很美好，现实很骨感，如果只是简单的将不同业务类型部署到一起，而不进行任何层面的资源隔离，那么在线业务服务质量必然会被影响，这也是为什么混部难以落地的核心原因。

干扰的来源

Kubernetes将计算资源分为不可压缩资源和可压缩资源。不可压缩资源是指物理内存等被应用程序独占的资源，在某个时刻一旦分配给某个进程，就不可以再被重新分配；可压缩资源是指比如可以分时复用的CPU资源，多个进程可以共享同一CPU核，虽然在CPU在某个时钟周期只为单一任务服务，但从宏观时间维度，CPU是可以同时服务于多个进程的。当多个进程都有CPU需求时，这些需求交给操作系统统一分配和调度。当多个进程争抢资源时，可能会导致应用性能下降，这便是我们所说的干扰。

USE方法（Utilization，Saturation，Errors）是性能测试领域中广泛采用的指导理论。在评估系统性能时，通过资源利用率，饱和度和错误率，来迅速的定位资源的瓶颈和错误所在。如下图所示，针对不同资源都可以通过USE方法指导我们如何进行干扰检测。

首先从资源维度，干扰可能发生在任何一个资源维度，比如常见的CPU以及CPU相关的L1,、L2、LLC缓存、内存带宽、磁盘IO、网络IO等。其次从干扰发生的层级来看，干扰可能发生在应用代码、操作系统、硬件等不同层级。

对于应用而言，任何一环都可能成为干扰的来源；同时这些因素之间也会互相关联，例如应用网络流量上升，不仅会造成带宽的抢占，通常还会导致CPU资源消耗上升；又比如一个应用虽然计算逻辑简单，但需要频繁访问内存数据，如果此时缓存失效，则应用需要访问物理内存，而CPU负载会因为忙等而上升。

因此判断干扰是否发生，进一步寻找干扰源，并通过技术手段避免干扰是复杂的，这是干扰检测自动化门槛高的核心原因，如何能在关联的因素中识别干扰以及绕过表象找到真实的干扰源是混部需要解决的核心问题。

Crane的混部方案

Crane为混部场景提供了一套开箱即用的解决方案，借助Kubernetes CRD，该方案可灵活适配于多优先级的在线混部场景以及在离线混部场景，混部方案的能力概览如下：

节点负载画像与弹性资源回收 Crane实时采集节点利用率数据，并基于多种预测算法计算出未来的闲置资源，为节点构建画像，并将其以扩展资源形式更新成节点可调度资源。弹性资源的多少随高优业务真实用量变化，高优业务用量上升，弹性资源减少。
弹性资源再分配低优业务使用弹性资源，调度器确保低优业务首次调度时有足够弹性资源可用，防止节点过载。
基于自定义水位线的干扰检测和主动回避能力
- NodeQoS API允许集群运维定义节点水位，包括总CPU水位，或者弹性资源分配率、弹性资源水位等，并定义当真实用量达到水位时的回避动作。
- PodQoS API 定义不同类型工作负载的资源隔离策略，如CPU调度优先级，磁盘IO等，同时定义该类型业务允许的回避动作。
- AvoidanceAction定义调度禁止、压制、驱逐等动作参数，当节点水位被触发，只有允许某个动作的业务Pod才可以执行该操作。
基于内核隔离的增强QoS能力 Crane的开源方案中，可以通过动态调节CGroup压制干扰源资源上限。同时，为支撑大规模生产系统的的隔离需求，Crane基于腾讯RUE内核，通过多级CPU调度优先级，以及绝对抢占等特性，保证高优业务不受低优业务的影响。
支持模拟调度的优雅驱逐等增强的重调度能力当压制不足以抑制干扰时，就需要从节点中驱逐低优Pod以确保高优业务的服务质量。Crane支持模拟调度的优雅驱逐重调度能力能够借助集群全局视角和预调度能力降低重调度对应用的影响。

闲置资源回收

虽然Kubernetes提供了集群自动扩缩容能力，能够让云用户在业务负载降低时缩小集群规模，节省成本。然而集群扩缩容效率依赖基础架构和资源供给等因素约束，通常不是一个高频操作，绝大多数云用户的业务还运行在采用包年包月的固定节点池。

混部的第一步是从集群中识别出闲置资源并转换成可被临时借用的弹性算力，并更新成为节点可分配资源。Crane借助资源预测和本地实时检测两种手段计算节点可用弹性资源。

Crane Agent启动时会自动依据如下的默认模版为节点创建TSP对象，Craned中的资源预测组件获取该TSP对象以后立即读取节点资源用量历史，通过内置预测算法进行预测，并将预测结果更新至TSP.Status。

Crane Agent中的Node Resource Controller组件周期性检测该节点的实时负载信息，并按如下公式计算实时弹性CPU：

节点可分配CPU：节点可分配CPU，即Node.Status.Allocatable.CPU
预留比例：保证始终有一定的空闲资源不能被复用，保证集群的稳定
节点实际CPU用量：节点实际的CPU用量，即node_cpu_seconds_total
弹性资源用量：节点实际用量包含了使用弹性资源的部分业务，而这部分开销是是弹性资源，因此需要算入弹性CPU中
绑核业务独占的CPU：被业务绑定的CPU不可二次分配，因此需要再弹性CPU中扣除

Node Resource Controller 同时监听节点TSP对象变化，当读取到TSP对象的状态变化时，同时参考本地实时可回收弹性资源以及预测结果，并取其中较小的值更新为节点弹性资源gocrane.io/cpu。内存等其他资源原理与CPU一致。

弹性资源使用

弹性资源更新成为节点Allocatable Resource以后，低优业务即可通过资源声明将弹性资源利用起来，Kubernetes调度器确保节点弹性资源能够满足业务需求才能成功调度。

干扰检测与主动回避

弹性资源再分配能有效提升单节点业务部署密度，而更高的部署密度意味着业务面临的资源竞争的可能性更大。Crane实时对节点和应用进行多维度的指标检测，通过灵活可配的异常定义规则和筛选策略，判断干扰是否发生，并且在干扰发生时牺牲低优Pod以确保高优业务的服务等级不变。

全维度指标采集

Crane Agent通过多种手段收集全维度指标，将这些指标统一保存在stateMap中，用于资源回收和干扰检测。

基于多种手段：通过解析系统文件、调用cAdvisor接口、eBPF Hook等多种手段，采集包括CPU 利用率、CPI、虚拟机CPU Steal Time、内存利用率、进出网络流量和磁盘读写IO等指标，Crane用户也可以编写插件采集自定义指标。完整的指标检测有助于干扰的分析，为之后更为完善的应用画像，应用特性分析，应用之间的干扰情况提供充分的依据。

干扰判断

下图展示了Crane Agent的核心组件，在State Collector定期采集全维度指标以后，stateMap会交由Analyzer进行干扰判断。当前的干扰判断规则沿用了Kubernetes健康检查的判断逻辑，用户可基于NodeQOS对象定义干扰判断规则。该对象可定义指标采集规则，干扰判断所依赖的指标名称以及其对应的干扰水位线等，同时通过AvoidanceAction定义干扰发生时需要执行的回避动作，详情参见下面的配置示例：

NodeQOS中的actionName属性关联了回避动作的名称，需要创建AvoidanceAction对象完成回避动作的完整参数配置，当前支持 Scheduling Disable（关闭节点调度）、Throttle（通过Cgroup调节Pod的可用资源上限）, Eviction（驱逐Pod）三类操作操作；同时，如果节点干扰消失，Crane Agent也会自行执行逆操作，恢复节点和业务的资源配置状态。

下面的AvoidanceAction示例展示了如何通过调节CGroup对Pod的可用资源进行压制：

压制目标的选择

NodeQOS定义了干扰判断规则以及当干扰发生时需要执行的回避动作，那么回避动作会应用在哪些对象上呢？

Crane针对Kubelet内置驱逐规则做了一定程度的扩展，这些内置规则包括：

是否使用了弹性资源
比较优先级与QOSClass
比较CPU/内存用量的绝对值
比较实际用量与弹性资源上限的比值
运行时间等

Crane用户也可以针对自定义水位线指标实现特定的驱逐选择规则。

除此之外，Crane用户可以通过定义PodQOS来定义特定Namespace、特定优先级、特定标签的Pod允许执行特定的驱逐动作。如下面的例子，为有preemptible_job: “true”标签的离线BestEffort Pod配置可被压制操作。通过PodQOS的精细化管控，我们实现了业务侧的个性化需求：比如 logstash服务的负责人希望这类业务接受驱逐但不接受压制；而运行了数个星期的AI训练任务宁愿被压制而不是被驱逐。

支持优雅驱逐的重调度器

Crane Agent是运行在每个节点的Daemonset Pod，它所做的决策都是基于节点而缺乏全局视角。当多个节点同时发生干扰，Agent需要对某低优业务进行驱逐时，若无PDB对最大可用副本数进行保护，很可能会导致该业务的多个Pod同时被驱逐，进而造成服务质量下降。 Crane Agent支持与中心化部署的重调度器联动，由Crane Agent为待驱逐Pod打上标签，并交由重调度器统一进行驱逐。 Crane增强的Descheduler支持优雅驱逐能力，包括：

支持模拟调度，集群资源不足时可停止驱逐，该过程模拟Filter，PreFilter过程，不仅包含了Scheduler默认包含的插件，同时支持调度器扩展插件，模拟实际调度过程
有全局视图，在多Workload并行，同一Workload内串行驱逐，适用于固定时间窗口腾空节点和基于特定标签批量驱逐Pod/Workload/母机的场景
可以通过先扩容后缩容的方式实现无感驱逐，保证Workload可用性

RUE内核提供混部的稳定底座

如意，TencentOS RUE(Resource Utilization Enhancement)，是 TencentOS 产品矩阵中一款专为云原生场景下服务器资源 QoS 设计，提升资源利用率，降低运营成本的产品。如意统一调度分配云上机器的 CPU、IO、网络、内存等资源，相比传统的服务器资源管理方案，如意更适用于云场景，能够显著提升云上机器的资源使用效率，降低云上客户的运营成本，为公有云、混合云、私有云等客户提供资源增值服务。如意的核心技术能做到不同优先级的业务之间不互相干扰，实现资源利用率、资源隔离性能、资源服务质量的高效统一。相比传统的资源管理方案，如意具有以下特点:

为云而生:对接 K8S 等主流资源管理平台，以容器为对象进行资源调度。
多优先级:支持三档基础优先级，支持更多优先级扩展。
多种资源:对CPU、IO、网络、内存等服务器资源进行全面统一调度。
资源隔离:低优先级器可以使用空闲资源，不会对高优先级容器造成影响。
稳定有效:在腾讯云百万级别数据中心上验证，服务众多客户。

以干扰最容易发生的CPU资源为例，如意CPU QoS 允许用户将服务器上的容器划分成不同优先级，根据优先级分配 CPU 资源，保障低优先级容器不会对高优先级容器造成干扰(包括调度时延，CPU 使用时间等)，同时允许低优先级容器使用空闲 CPU 资源，从而提升 CPU 利用率，降低计算成本。 Crane涵盖了RUE的大部分功能，涉及CPU，内存，IO，网络等多个维度，通过PodQOS和NodeQOS为应用提供批量化的RUE隔离能力，使得用户无需关注复杂的CGroup配置便能轻松实现内核层面的资源隔离和保障。

最佳实践

安装配置

参考教程部分，即可安装Crane-Agent和Crane，其中NodeResource作为FeatureGate控制弹性资源复用功能的开启，目前默认开启，用户无需配置；如需使用到节点弹性资源TSP预测，需要同时部署监控组件，参考教程部分，CraneTimeSeriesPrediction作为FeatureGate控制预测功能的开启，默认开启，用户无需再做配置。

Crane-Agent支持Docker和Containerd，自动探测无需用户配置；支持cgroupfs，systemd两种cgroup-driver，默认使用cgroupfs，如需更改，command添加–cgroup-driver=”systemd”即可。

下面以将业务分为高低两个优先级为例说明如何配置使用；

通过PodQOS支持的scopeSelector为业务做区分和分级；同时配置低优先级的资源配置使用弹性资源，如gocrane.io/cpu
为每级业务创建对应的PodQOS，指定其对应范围和允许的回避动作以及资源隔离策略
创建NodeQOS指定一条或多条水位线和对应的回避操作，比如60%时开始压制，70%时开始驱逐等

Housekeeper

随着 Housekeeper（腾讯云原生运维新范式）的推出，QoS Agent 已经结合原生节点的能力提供了可抢占式 Job 的能力。该类型 Job 使用的资源是集群中的闲置资源，不占用集群/节点真实的剩余可调度量，在发生资源竞争时，该部分资源会被优先回收，保证正常使用节点资源的业务的稳定性。更多请参考：可抢占式Job（https://sigusoft.com/document/product/457/81751）

扩展阅读

混部在离线作业调度时应优先选择满足弹性资源用量中真实负载较低的节点进行部署，避免节点负载不均；同时，需保障高优和延迟敏感业务的资源诉求，如调度到资源宽裕的节点，满足NUMA拓扑的绑核需求等。Crane通过真实负载调度和CPU拓扑感知调度满足了如上需求，具体可参考Crane-Scheduler和CPU拓扑感知调度。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！

ShopWind 是一款基于 Yii2.0 框架深度重构的 B2B2C、O2O 行业的电商系统软件，您可以轻松创建和发布属于自己品牌的专业的电商平台，进行全方位的品牌宣传和产品推广。ShopWind v3.x 标准版开始走向开源，打造一款完全开源的电商系统，可以免费用于商业运营或者二次开发，免于商业版权的烦恼。v3.x 商业版包含 PC、手机 H5、微商城、APP 客户端（Andorid+iOS）、微信小程序、今日头条小程序等多端，其中 PC 端为开源免费项目，移动端为增值项目。ShopWind 提供专业、快速、安全的底层软件设计和免费的更新升级服务，做好完善的开发文档和接口文档方便开发者在底层软件的基础上开发各种应用、模板、或者插件。新版本新增优化了客服系统，跟商户沟通聊天方便快捷。

官网网址：https://www.shopwind.net
开发文档：https://developer.shopwind.net
API 接口文档：http://docs.shopwind.net
开发者社区：https://forum.shopwind.net

PC 体验

前台体验： http://test.shopwind.net 买家测试账号：buyer 密码：支付密码：
后台体验： http://test.shopwind.net/admin 平台管理员账号：admin 密码：
商家体验： http://test.shopwind.net/seller/login.html 商家测试账号：seller 密码：

移动端扫描体验

webIM 功能预览

更新内容

【新增】webIM 移动端和 PC 端
【新增】API 接口绑定微信 / / 支付宝登录
【新增】API 接口解绑微信 / / 支付宝登录
【新增】API 接口（获取优惠券）接口增加订单号、是否可用、关键词查询条件
【新增】API 接口（获取积分记录）接口增加订单号查询条件
【新增】API 接口（支付状态查询接口）
【新增】API 接口（获取我的退款列表接口）增加退款编号、交易号、商户订单号查询条件
【优化】API 接口（更新店铺信息接口）新增图片轮播（swiper）入参
【优化】 API 接口（更新店铺信息接口）新增店铺介绍（description）入参
【优化】优化 WebIM 客服模块
【优化】优化搭配购模块
【修复】【手机专享价】价格显示有误问题
【修复】后台店铺等级数据显示有误的问题
【修复】后台门店自提列表无法批量删除的问题
【修复】卖家中心多页订单打印显示不全的问题
【修复】数据采集插件一次采集重复导入商品的问题

OAuthApp 是一个前端发布工具，用于快速开发前端网页项目，并发布到服务器。

具有引入脚本库就能使用服务端API在线发布H5，数据独立存储的特性

更新内容：
1，新增统计分析页面，可查看应用新增用户、接口用量分析，接口日志
2，修复排行榜、消息接口上传文件返回路径错误问题
3，新增文件存储空间用量展示
4，修复了文件存储页面，系统文件夹也显示重命名按钮、删除按钮

部分截图：

相关链接：
网址：https://www.oauthapp.com/
文档：https://web.oauthapp.com/4/docs

漏洞描述

ThinkPHP 是一套基于PHP的、开源的、轻量级Web应用程序开发框架。

ThinkPHP 受影响版本在开启多语言功能时，能通过 get 参数、header、cookie 等位置传入恶意参数，实现目录穿越和文件包含，当用 pearcmd 文件包含我们传入的参数，就可以实现命令执行。

漏洞名称 ThinPHP <6.0.14 远程命令执行漏洞漏洞类型命令注入发现时间 2022-12-09 漏洞影响广度广 MPS编号 MPS-2022-67281 CVE编号 – CNVD编号 –

影响范围

topthink/framework@(-∞, 6.0.14)

修复方案

将组件 topthink/framework 升级至 6.0.14 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-67281

Commit

POC

情报订阅

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

具体订阅方式详见：

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

Eclipse Vert.x 是一个微服务开发框架，基于事件和异步，依托于全异步 Java 服务器 Netty，并扩展了很多其他特性，以其轻量、高性能、支持多语言开发而备受开发者青睐。

Vert.x 4.3.6 现已发布，此版本主要是修复在 4.3.5 中发现的错误。

vert.x

将 HTTP headers 和 response body 添加到 WebSocket upgrade rejected exception
支持服务器上 server name indication (sni) 的 SSL handshake 超时
链接 Graphql java 文档

vertx-service-proxy

将 classifier 处理器添加到 maven vertx-codegen

vertx-sql-client

为 Tuple.of 添加类型检测

vertx-web

Cherrypick/issues/allow 支持多个正则表达式
支持 CORS 中的多个正则表达式以允许下游项目保留其配置
尝试在 cors 中允许多个正则表达式

vertx-hazelcast

升级到 Hazelcast 4.2.6

vertx-tracing

支持在 Vertx 中采样

Eclipse Vert.x 从 4.3.4 开始已支持最新 Java 19 早期测试特性：虚拟线程。而 Vert.x 4 事件总线 JavaScript 客户端库现在可以独立使用，也可以方便地与任何前端构建工具集成。

详情查看 Release Notes。

Matomo 是一套基于 PHP + MySQL 技术构建的开源网站访问统计系统，能够提供详细的统计信息，比如网页浏览人数、访问最多的页面、搜索引擎关键词等等流量分析功能。

Matomo 4.13 正式发布，这是另一个维护版本，改善了 Matomo 的可靠性和稳定性。在这些修复和改进的基础上，还为从 Google Analytics 过渡的网站增加了有用的指南。

在 Tag Manager 中，现在增加了对翻译的支持。许多文本以前只有英文，但现在随着社区贡献的翻译，可以逐渐增加对其他语言的支持。

平台变化

在这个 4.13.0 版本中，有一个新的配置设置，对多租户安装很有用。

注意：Marketplace 展示了超过 90 个已经与 Matomo 兼容的插件。

新的和更新的 SDK

Matomo 团队提供官方 SDK（Tracking API Clients），用于监测你的移动应用程序和任何其他类型的应用程序。

iOS SDK
Android SDK

其他

#19917 在 logme 方法中加强对有效重定向 url 的检查
#19887 确保更新时运行 Tag Manager 的更新
#19957 在安装过程中检测 GA3、GA4 或 GTM 并提出迁移指南
#19903 防止在检索前一数据行的列时出现异常
#19909 为 Twig 导航菜单模板中的子类别添加帮助图标功能
#18550 修复由于参数不正确导致的 SQL 语法错误
#19512 改进/修复目标概览中最佳转换页面的处理
#19867 在 API 请求中分组前添加无效限制的异常
#19879 修复页面加载时选择退出的切换和不正确的默认状态
……

更多详情可查看：https://matomo.org/changelog/matomo-4-13-0/

Wireshark 是世界上最流行的网络协议分析器。它被用于故障排除、分析、开发和教育。Wireshark 不再为 4.0 及以后的版本提供官方的 32 位 Windows 软件包。如果你需要在该平台上使用 Wireshark，建议使用 3.x 版本中最新的 3.6 版本。

修复

以下漏洞已被修复：

wnpa-sec-2022-09：多重剖析器无限循环
wnpa-sec-2022-10：Kafka dissector 内存耗尽

以下错误已被修复：

EVS Header-Full 格式填充问题
Wireshark 4.0.0 VOIP 播放没有声音，暂停后无法继续
在 macOS 上导出配置文件时，如果没有扩展，Wireshark 会崩溃
EVS dissector 缺少值描述
Qt 6 字体描述与 Qt 5 不向后兼容
在 Windows 上编辑带有非 ASCII 字符的数据包注释，将其保存在本地代码页，而不是 UTF-8
在没有 nghttp2 的情况下，HTTP2 测试失败
……

更新的协议支持

ASN.1 PER、ASTERIX、BGP、BPv6、DTLS、EVS、GOOSE、GSM Osmux、IPv6、Kafka、Locamation IM、MONGO、NXP 802.15.4、OpenFlow v6、PCAP、Protobuf、RTP、S1AP、SKINNY、TCP 和 WASSP

获取

Wireshark 源代码和安装包可从 https://www.wireshark.org/download.html 获取

更多详情可查看：https://www.wireshark.org/docs/relnotes/wireshark-4.0.2.html

关注公众号

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

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

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

Helix 是一个模态文本编辑器，内置支持多选、语言服务器协议 (LSP)、tree-sitter 以及对调试适配器协议 (DAP) 的实验性支持。目前 Helix 22.12 版本已发布，这是一个功能丰富的版本，带来如下内容：

Git diff gutter

新的 git diff gutter 跟踪当前缓冲区中与 git 索引相比的变化。与签入到 git 的文件相比，装订线中的标记表示添加、修改和删除。

默认情况下启用 git diff gutter。

下划线样式和颜色

支持扩展下划线的终端可以呈现彩色波浪线或点等样式的下划线，扩展的下划线可用于改进 LSP 诊断的显示。

终端失去焦点时自动保存

支持焦点事件的终端可以在切换到新窗口时自动保存当前文件。

幕后的性能改进：

用于写入文件的代码路径已经过全面检查，修复了一些围绕写入大文件和写入失败的边缘情况。
tree-sitter 解析、查询和注入处理的性能得到了改进，这对于大型 Markdown 文件来说是一个明显的速度提升，特别是因为 Markdown 广泛使用注入。
LSP 代码路径中的故障处理已得到改进， Helix 现在可以优雅地处理语言服务器不支持功能和语言服务器意外崩溃等情况。
:reload 命令的速度和内存使用得到了极大的改进，该改进来自 imara-diff 的创建，这是一种新的 diffing 实现，比 git 内部使用的更快。

更新公告：https://helix-editor.com/news/release-22-12-highlights/

PipeWire 是用于处理多媒体管道的服务器和用户空间 API 的多媒体处理工具，包括提供视频源（例如来自捕获设备或应用程序提供的流）并将其与客户端复用、访问视频源进行消费、生成用于音频和视频处理的图形。

目前 PipeWire 0.3.62 已发布，此版本正式支持蓝牙卸载，蓝牙卸载支持允许蓝牙接收、解码和播放完全在硬件内进行。这种为提高 CPU 效率而提供的蓝牙卸载支持同时也需要 WirePlumber 的支持，来处理卸载以及硬件兼容性。

PipeWire 0.3.62 还修复了由激活链接和驱动程序节点时的竞争引起的屏幕共享问题，此外还添加了视频转换数据，以便摄像机和屏幕共享可以报告其视频方向和转换事件，除此之外，此版本还添加了对 PulseAudio module-gsetting 的支持，以实现 paprefs 兼容性。

此版本还有一些修复项，可以在发行公告中细阅。

作者 | 任雪龙

导读

网络直播功能作为一项互联网基本能力已经越来越重要，手机中的直播功能也越来越完善，电商直播、新闻直播、娱乐直播等多种直播类型为用户提供了丰富的直播内容。随着直播的普及，为用户提供极速、流畅的直播观看体验也越来越重要。

全文6657字，预计阅读时间17分钟。

01 背景

02 现状

03 目标

△起播链路

04 难点

05 解决方案

5.1 设计新报表，定位耗时点

△一跳有起播地址时起播链路简图

按照上面的思路开发新报表后，上面的链路各阶段耗时也就比较清晰了，见下图，这样我们就可以针对不同阶段逐个击破。

△关键节点间耗时

5.2 一跳使用一级插件起播

5.2.1 一跳全部使用一级插件起播

5.2.2 提前请求接口

5.3 播放器Activity外预起播

通过提前起播功能，实验期命中提前起播逻辑较不进行提前起播逻辑，整体起播耗时 80 分位优化均值：450ms+。

5.4直播间任务打散

△内核首帧分发耗时

5.5 内核子线程分发首帧

通过直播内核首帧消息在主线程任务队列前插和业务关键节点增加是否可上屏判断，就可以较快处理首帧通知，降低首帧分发对起播时长影响。

5.6 起播与完载指标平衡

△页面启动耗时示意图

06 收益

△2022 Android 端起播耗时走势

07 展望

——END——

系统框架

Laminas （Zendframework 3）
Doctrine 2

环境要求

服务器系统 Linux、Unix、Mac、Windows、其他

web 服务器 Apache、Nginx、IIS、其他

MySQL 版本 >= 5.6

PHP 版本 >= 7.2

PHP 扩展 | 库

PDO
SSL（openssl）
Fileinfo
intl
Curl
GD2

系统空间 >= 500M

更新日志：
新增聚合标签功能
新增线下支付
优化预售插件的适配
优化阿里云短信

在线文档地址：https://docs.loongdom.com.cn/

前台演示地址：http://v3.dbshop.net
后台演示地址：http://v3.dbshop.net/admin
后台登录账号：dbshop
后台登录密码：

下载地址： https://download.loongdom.com.cn/dbshop/V3.2/DBShopV3.2_Release.tar.gz

DBCart 企业级开源 (多语言) 商城系统，使用 PHP 语言基于 Laminas + Doctrine 2 组合框架开发完成。可定制、多终端、多场景、多支付、多语言、多货币等特性。

严谨的安全机制，可靠稳定；
方便的操作管理，节约时间；
清晰的权限分配，责任分明；
便捷的更新处理，一键搞定；
丰富的插件市场，扩展无限。

默认支持：简体中文、繁体中文、英文、日文、韩文。
后台配置好智能翻译，可以方便的在后台输入框翻译成对应语言内容，再优化修改。省时省力。
前台可任意切换不同语言内容。

系统框架

Laminas （Zendframework 3）
Doctrine 2

环境要求

服务器系统 Linux、Unix、Mac、Windows、其他

web 服务器 Apache、Nginx、IIS、其他

MySQL 版本 >= 5.6

PHP 版本 >= 7.4

PHP 扩展 | 库

PDO
SSL（openssl）
Fileinfo
intl
Curl
GD2

系统空间 >= 500M

更新日志：
新增聚合标签功能
优化后台商品分类列表的复制按钮文字
优化将等待预定商品发货修改为等待支付尾款
优化预售插件的前台显示
优化前台添加对在线支付的开启判断，自提里提供线下支付方式选择
优化阿里云短信
优化后台帮助链接

在线文档地址：https://docs-dbcart.loongdom.com.cn/
前台演示地址：http://demo.dbcart.loongdom.cn/

下载地址：https://download.loongdom.com.cn/dbcart/V3.1/DBCartV3.1_RC.tar.gz

Go 语言通用代码生成器仙童尝鲜版十一，发布最新介绍视频

Go 语言通用代码生成器仙童尝鲜版十一，发布最新介绍视频。请见：
https://www.bilibili.com/video/BV1ce411P7qU/

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 前端图形报表

柱状图：

折线图：

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

后端内页：

漏洞描述

TinyMCE 是一个开源的富文本编辑器。

TinyMCE 的受影响版本中由于未正确清理“WindowManager.alert”和“WindowManager.confirm” API 消息中的 HTML 从而存在 XSS 漏洞。攻击者可利用此漏洞向警报和确认对话框中提供恶意的 HTML 内容，当 TinyMCE UI 弹出报警或错误对话框时执行攻击者可控的恶意 Javascript 代码。

用户可参考 images _ load _ Handler 文档确保 images _ load _ Handler 返回始终有效值缓解此漏洞。

漏洞名称 TinyMCE 存在反射型跨站脚本漏洞漏洞类型 XSS 发现时间 2022-12-09 漏洞影响广度小 MPS编号 MPS-2022-1921 CVE编号 CVE-2022-23494 CNVD编号 –

影响范围

tinymce@[6.0.0, 6.3.1)

tinymce@(-∞, 5.10.7)

tinymce/tinymce@[6.0.0, 6.3.1)

tinymce/tinymce@(-∞, 5.10.7)

tinymce@[6.0.0, 6.3.1)

修复方案

将组件 tinymce 升级至 6.3.1 及以上版本

将组件 tinymce 升级至 5.10.7 及以上版本

将组件 tinymce/tinymce 升级至 6.3.1 及以上版本

将组件 tinymce/tinymce 升级至 5.10.7 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1921

https://nvd.nist.gov/vuln/detail/CVE-2022-23494

https://github.com/tinymce/tinymce/security/advisories/GHSA-gg8r-xjwq-4w92

https://github.com/tinymce/tinymce/commit/6923d85eba6de3e08ebc9c5a387b5abdaa21150e

https://github.com/tinymce/tinymce/commit/8bb2d2646d4e1a718fce61a775fa22e9d317b32d

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Containous Traefik是美国Containous公司的一款反向代理和负载平衡器。Containous Traefik 2.9.6之前的版本存在信息泄露漏洞，该漏洞源于其调试日志中显示授权标头。

漏洞名称 Containous Traefik 授权标头泄露漏洞漏洞类型信息暴露发现时间 2022-12-09 漏洞影响广度小 MPS编号 MPS-2022-1896 CVE编号 CVE-2022-23469 CNVD编号 –

影响范围

github.com/traefik/traefik/v2@(-∞, 2.9.6)

修复方案

将组件 github.com/traefik/traefik/v2 升级至 2.9.6 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1896

https://nvd.nist.gov/vuln/detail/CVE-2022-23469

情报订阅

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

具体订阅方式详见：

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

漏洞描述

cube-js 是一个商业智能平台，帮助数据工程师和应用程序开发人员从现代数据存储中访问数据，将其组织成一致的定义，并将其交付给每个应用程序。

cube-js v0.31.23版本中，所有经过身份验证的 Cube 客户端都可以绕过 SQL row-level 安全性并通过新引入的 /v1/sql-runner 端点运行任意 SQL，攻击者可通过构造恶意 sql 获取 cube 数据源中的敏感信息。此问题已在版本 0.31.24 中得到解决，建议用户升级到 0.31.24 或降级到 0.31.22。

漏洞名称 cube-js v0.31.23存在 sql 注入漏洞漏洞类型 SQL注入发现时间 2022-12-10 漏洞影响广度一般 MPS编号 MPS-2022-1937 CVE编号 CVE-2022-23510 CNVD编号 –

影响范围

@cubejs-backend/api-gateway@[0.31.23, 0.31.24)

修复方案

升级@cubejs-backend/api-gateway到 0.31.24 或更高版本

降级@cubejs-backend/api-gateway到 0.31.23 或更低版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1937

https://nvd.nist.gov/vuln/detail/CVE-2022-23510

https://github.com/cube-js/cube.js/security/advisories/GHSA-6jqm-3c9g-pch7

https://github.com/cube-js/cube.js/commit/3cfed6ca17df08bbba8c835ef

https://github.com/cube-js/cube.js/commit/f1140de508eac82b50bae1c4bf152f6041

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Spring Boot admins 是一个用于管理 Spring Boot 应用程序的开源管理用户界面。

Spring Boot admins 的 notifiers 通知模块由于没有对用户输入进行有效过滤，所有运行 Spring Boot Admin Server、启用通知程序（例如 Teams-Notifier）并通过 UI 写入环境变量的用户都会受到代码注入的影响。攻击者可利用此漏洞通过向 Spring Boot Admin Server 的执行器端点发送包含恶意代码的 POST 请求远程执行恶意代码。建议用户升级到最新版本的 Spring Boot Admin 2.6.10 和 2.7.8 以上版本，无法升级的用户可以禁用任何通知程序或禁用执行器端点上的写访问（POST 请求）缓解此漏洞。

漏洞名称 Spring Boot admins 存在代码注入漏洞漏洞类型代码注入发现时间 2022-12-10 漏洞影响广度一般 MPS编号 MPS-2022-65559 CVE编号 CVE-2022-46166 CNVD编号 –

影响范围

de.codecentric:spring-boot-admin@[2.7.0, 2.7.8)

de.codecentric:spring-boot-admin@[3.0.0-m1, 3.0.0-m6)

de.codecentric:spring-boot-admin@(-∞, 2.6.10)

修复方案

将组件 de.codecentric:spring-boot-admin 升级至 2.6.10 及以上版本

将组件 de.codecentric:spring-boot-admin 升级至 2.7.8 及以上版本

将组件 de.codecentric:spring-boot-admin 升级至 3.0.0-m6 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65559

https://nvd.nist.gov/vuln/detail/CVE-2022-46166

https://github.com/codecentric/spring-boot-admin/security/advisories/GHSA-w3x5-427h-wfq6

https://github.com/codecentric/spring-boot-admin/commit/c14c3ec12533f71f84de9ce3ce5cebf75

情报订阅

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

具体订阅方式详见：

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

关注公众号

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

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

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

漏洞描述

Sentry 是一个开源的错误跟踪和性能监控平台。

sentry 22.11.0之前版本中存在权限管理不当漏洞，具有有效（尚未接受或过期）邀请链接的用户可以通过操纵 cookie 在加入组织时在多个帐户上重复使用同一个邀请链接，攻击者可利用此漏洞创建多个用户并加入生成邀请链接的组织。Sentry 的子托管服务可通过禁用邀请（invite）功能缓解此漏洞。

漏洞名称 Sentry <22.11.0 存在权限管理不当漏洞漏洞类型 – 发现时间 2022-12-10 漏洞影响广度一般 MPS编号 MPS-2022-1912 CVE编号 CVE-2022-23485 CNVD编号 –

影响范围

sentry@[20.6.0, 22.11.0)

修复方案

将组件 sentry 升级至 22.11.0 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-1912

https://nvd.nist.gov/vuln/detail/CVE-2022-23485

https://github.com/getsentry/sentry/security/advisories/GHSA-jv85-mqxj-3f9j

情报订阅

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

具体订阅方式详见：

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

现代管理学之父德鲁克在其经典著作《卓有成效的管理者》中对时间有一段精妙的论述，其要点如下：

时间是一项限制因素，任何生产程序的产出量，都会受到最稀有资源的制约，而时间就是其中的资源。
时间也是的一项资源，资金可以筹集，人力也总可以雇到，只有时间是我们租不到、借不到，也买不到，更不能以其他手段来获得的。
时间的供给，丝毫没有弹性，不管时间的需求有多大，供给。
时间稍纵即逝，根本无法贮存，时间永远是的。
时间也完全，我们可以增加知识，也可以增加人力，但没有任何东西可以替代已失去的时间。
做任何事情都少不了时间，时间是的一个条件，任何工作都是在时间中进行的，都需要耗用时间。

1 如何将时间沉淀下来

虽然时间是无形的，看不见、摸不着，也无法贮存，但却可以通过有形的东西沉淀下来。

当你花时间写完一篇文章，时间就沉淀到文字中
当你录制了一个有趣的视频，时间就沉淀到视频里
当你花了一整天的时间整理房间，时间就沉淀到你每天的起居环境里
当你去健身房撸铁，时间就沉淀到每一块结实的肌肉里
当你种了一盆花，时间就沉淀到绽放的每一朵鲜花中

如果你创建了一个开源项目，时间就：

沉淀到你写的每一行代码里
沉淀到你为项目编写的每一篇文档里
沉淀到你提交或解决的每条 Issue / PR 里
沉淀到你的每一次代码检视意见和讨论里（图1）
沉淀到你组织的每一次会议中（图2）
沉淀到你与社区成员的每一次互动中

图1：代码检视

图2：开源社区会议

2 开源：将时间沉淀到代码里

2022年大部分时间都投入到了 Vue DevUI 开源项目的建设中，并于今年9月1日发布了1.0版本。

2.1 过程

从过程上来看，我个人的贡献主要如下：

贡献多行代码（除去等无效代码提交）
提交多个PR
报告多个Issue
提出多条代码检视意见
发布多个版本
撰写篇推广文章
组织多场线上沟通会
参加场线下开源会议分享

图3：Commits

图4：PR

Vue DevUI 推广文章：

👍：点赞<br> 🔖：阅读

295👍34526🔖 Vue DevUI 1.0 正式发布
173👍33991🔖 Vue DevUI：100多位贡献者持续530多天，写了近60000行代码，这个新鲜出炉的 Vue3 组件库你不想尝试下吗？
42👍10162🔖 20行代码，给你的项目增加 DevUI 主题切换能力
25👍1612🔖 探索开源社区开发模式：vue-devui 组件库 1.0 版本公开测试
10👍987🔖 请收下这份《Vue DevUI 公开测试参考指南》
11👍889🔖 DevUI 开源社区 Issue / PR 周报第2期：本周迎来贡献的超级大爆发，共10位贡献者提交26个PR
9👍1028🔖 DevUI 开源社区 Issue / PR 周报第1期
8👍1094🔖 如何在1分钟之内创建一个符合规范的DevUI组件

2.2 成果

从结果上来看，通过积极的社区运营：

增加位贡献者
增加颗Star
增加个PR
增加个Issue
微信社群增加多名成员
掘金增加多关注者
掘金增加近阅读
掘金增加个点赞

图5：Star trends

图6：GitHub card

图7：掘金数据

以下是我个人2022年的 GitHub 贡献图：

图8：Contributions

以下是我在中国开源年会现场的分享：

图9：Kagol 在中国开源年会现场的分享

2.3 社区 > 代码

Vue DevUI 取得的小小成绩主要依赖于社区的朋友们，我只是起到一个将大家团结在一起的角色，通过 Vue DevUI 这个开源项目，我认识了很多社区的优秀开发者，并跟他们建立了很好的关系。

我觉得这应该就是开源社区应有的样子：

一群来自全国各地（甚至全球各地）的开发者，因为有着同样的兴趣和志向聚集在一起，一起开发一个有价值的开源项目，大家真诚地相互交流、分享和协作，一起集思广益解决问题，一起享受成功的喜悦，也一起分担失败的痛苦。

以前我觉得自己做的开源项目一定要要有很多 Star，要有很多下载量，这样才有意义、才有价值，现在我觉得做开源本身就是意义，通过做开源项目收获的友谊、获得的成长，这本身就是价值。

旅行并不是达到目的地才是旅行，从你出门的那一刻起，风景就已经出现！

图10：Contributors

3 写作：将时间沉淀到文字中

除了做开源项目可以将时间沉淀下来，写文章也可以。

写技术文章是一个很好的和的方式，我很喜欢写作，当初有机会负责开源运营，可能也是领导看我写作能力还可以，当时在自己的个人公众号（）上发布了几篇解析 Quill 原理的文章。

今年写的技术文章比较少，技术文章写了10篇，推广文章写了10多篇，开源运营的文章也写了3篇（以前没怎么写过，现在慢慢积累了一些开源社区运营的经验，所以慢慢地也会给大家进行分享）。

技术文章主要写了一个迷你的组件设计系列，给大家分享了我自己的组件设计观：

72👍6297🔖 前端开发的积木理论——像搭积木一样做前端开发
49👍3934🔖 用积木理论设计一个灵活好用的Carousel走马灯组件
13👍2706🔖 CarouseIndicator 组件应用：0行JS代码实现好看的手风琴式折叠卡片效果
21👍2003🔖 用积木理论设计的Carousel组件都有哪些有趣的玩法？

另外也写了几篇零散的文章：

11👍1560🔖 从 CDK Tree 源码学习如何开发一个UI无关的 Tree 组件
288👍23484🔖 前端Vuer，请收下这份《Vue3中使用JSX简明语法》
81👍4043🔖 前端Vuer，请给你的项目加上 ESLint
19👍1711🔖 DEVUI蓝掘金主题上线啦🎉

还有三篇分享我对开源运营的一些思考：

20👍1314🔖 DevUI 开源经验：从启动开源项目到运营开源社区
8👍3083🔖 从0到1开始运营你的开源项目——华为云DevUI成长经验分享
28👍1325🔖 运营一个开源社区究竟意味着什么？

有三篇发在我个人的掘金账号（因为是刚刚开始运营的个人掘金账号，数据非常惨淡就不贴出来），大家多多支持下我的个人掘金账号呀，后续我也会持续分享一些前端和开源方面的经验。

React DevUI 18.0 正式发布🎉
好慌，我代码没了！不会是变基变出问题了吧？
老板：你为什么要选择 Vue？

写作方面今年做得不够，明年加油吧！

除了我自己写的文章，DevUI团队账号中有不少是社区朋友们的投稿，非常感谢朋友们对DevUI和我的大力支持，尤其是ErKeLost同学，给我们投稿了三篇高质量技术文章，以下是他们的投稿文章：

58👍1381🔖 手把手教你开发一个快速、高性能、高质量压缩图片的 Vite 插件 – ErKeLost
249👍11787🔖 🚀Turborepo：发布当月就激增 3.8k Star，这款超神的新兴 Monorepo 方案，你不打算尝试下吗？ – ErKeLost
53👍2655🔖 Ripple：这个广受好评的水波纹组件，你不打算了解下怎么实现的吗？ – ErKeLost
31👍3053🔖 骨架屏优化——细粒度模式的实现 – ivestszheng
47👍3406🔖 手把手教你实现 Tree 组件搜索过滤功能，干货满满！ – daviForevel

另外也要感谢我们团队成员的大力支持，特别是和同学，以下是他们的投稿文章：

25👍2157🔖 Angular依赖注入模式的应用和玩法案例 – rhlin
92👍5695🔖 如何使用 Monaco Editor 做一个在线的网页代码编辑器 – 汤汤Tang
15👍1413🔖 Angular PWA 渐进式 Web 应用 – 汤汤Tang
16👍1156🔖 TypeScript AST (抽象语法树) 结合 Angular Schematics 的应用 – 汤汤Tang

4 2023 年展望：将时间沉淀到自己的热爱里

2023年我依然会将主要精力投入开源和写作上，另外也会尝试：

运营自己的个人公众号（欢迎关注我：）和掘金账号，分享自己在前端和开源两个方向上的经验，欢迎大家关注我
参加一些内外部的分享，锻炼自己的演讲能力，增加个人影响力
尝试写一本掘金小册（惭愧，2021年立的 flag 到现在还没实现）

最后给大家推荐一部非常治愈的纪录片：《人生果实》。

— END —

我是 Kagol，如果你喜欢我的文章，可以给我点个赞，关注我的公众号，一起交流前端技术、一起做开源！

关注公众号

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

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

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

Docker v23.0.0-beta.1 现已发布，这是即将发布的 23.0.0 版本的预发布版本。预发布旨在测试新版本：仅在测试环境中安装。

 curl -fsSL https://get.docker.com -o get-docker.sh sudo CHANNEL=test sh get-docker.sh

公告指出，从 23.0.0 版本开始将不再使用 CalVer 版本控制，而是使用使用 SemVer 格式的版本控制。更改版本格式是实现 go 模块兼容性的一个步骤，但存储库尚未使用 go-modules，仍然需要使用“+incompatible”版本；开发团队将在未来的版本中努力实现 go 模块兼容。

Known issues：

目前还没有更新日志；可以在 GitHub 上找到此版本中包含的拉取请求的概述：
- docker cli：23.0.0 的所有拉取请求/23.0.0 的所有“changelog”拉取请求
- docker engine：23.0.0 的所有拉取请求/23.0.0 的所有“changelog”拉取请求
静态二进制文件 ( ) 不再包含 cli 插件；使用 deb/rpm 包，或来自 buildx github 存储库和 docker compose github 存储库的手动安装说明
二进制文件未静态链接到静态包中
目前还没有适用于 s390x 和 ppc64le 架构的软件包
可能有 bug

可以在这些问题跟踪器中报告错误和回归：

CLI相关：https ://github.com/docker/cli/issues
Docker Engine 相关 https://github.com/moby/moby/issues

详情可查看更新说明。

Wine 8.0 的第一个候选版本已发布，这标志着年度代码冻结期的开始，此版本中的新功能：

捆绑的 vkd3d 升级到 1.6 版。
Vulkan 和 OpenGL thunking 优化。
对打印处理器的更多支持。
改进的操纵杆控制面板。
Long 类型的 printf 格式转换完成。
各种错误修复。

此外，Wine 8.0-rc1 有 52 个已知的错误修复，包含从加密修复到各种游戏修复、崩溃修复，以及对一些之前性能不佳的软件的改进。

详细的修复项可以在更新公告中查看。

Wine（Wine Is Not an Emulator）是一个能够在多种兼容 POSIX 接口的操作系统（诸如 Linux、macOS 与 BSD 等）上运行 Windows 应用的兼容层。它不是像虚拟机或者模拟器一样模仿内部的 Windows 逻辑，而是将 Windows API 调用翻译成为动态的 POSIX 调用，免除了性能和其它一些行为的内存占用，让你能够干净地整合 Windows 应用到你的桌面。

CUDA（Compute Unified Device Architecture），是显卡厂商 NVIDIA 推出的运算平台。作为一种通用并行计算架构，CUDA 使 GPU 能够解决复杂的计算问题。它包含了 CUDA 指令集架构（ISA）以及 GPU 内部的并行计算引擎。

目前，NVIDIA CUDA 12.0 发布了，CUDA 12.0 带来了许多变化，包括最新 Hopper 和 Ada Lovelace GPU 的新功能、更新 C++ 方言、使 JIT LTO 支持官方、新的和改进的 API，以及各种其他功能。

CUDA 12.0 为 NVIDIA 的 Hopper 和 Ada Lovelace 架构的许多特性公开了可编程功能。
支持将虚拟内存管理 API 与标记为 CUDA_VISIBLE_DEVICES 的 GPU 一起使用。
应用程序和库开发人员可以通过编程方式更新 CUDA 流的优先级。
改进了 CUDA 动态并行 API，与之前的 API 相比具有“实质性”的性能改进。
现在通过 nvJitLink 库正式支持即时链接时间优化 (JIT LTO)。
GCC 12.1 主机编译器支持。
NVCC 和 NVRTC 支持 C++20 方言。
NVRTC 将其默认 C++ 方言从 C++14 更新为 C++17。

有关 CUDA 12 的更多详细信息，可查看发行说明。

随着 Mesa 22.3 稳定，Mesa 22.2 系列即将停产。Dylan Baker 发布了最新的 Mesa 22.2.5 版本，作为最后一个 Mesa 22.2 版本。

Mesa 22.2.5 为那些仍然依赖 22.2 版本的用户修复了最后一批 Bug，包含：

对 Panfrost Gallium3D 驱动程序进行了一些修复
一些 RADV Vulkan 驱动程序修复
各种 Intel 驱动程序解决方法和修复
支持使用 Clang 6 构建 R600g NIR 代码，以实现 Android 9 兼容性
用于解决 Valve Source Engine 游戏
其他随机修复程序的错误检测

完整修复列表可查看发布公告。

Mesa 鼓励用户转向 22.3 系列，新版本引入了 Rusticl、新的/改进的硬件支持、Zink 处于更好的状态，并且在整个开源 OpenGL/Vulkan 驱动程序集合中进行了大量改进。

关注公众号

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

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

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

一、0xcc开篇

CAT 作为国人主导的开源系统，其本地化工作也是做得非常到位，而凭借着架构简单，开箱即用的特点，CAT 也是我们得物使用的第一个应用监控系统。

二、 0x01 第一阶段

从0～1基于CAT的实时应用监控

CAT 拥有指标分钟级别的聚合统计的能力，从 UI 上不难看出，它拥有丰富的报表统计能力和问题排障能力。

但随着公司业务规模逐步扩大，微服务粒度也不可避免地变小，我们发现，CAT 已经逐步无法满足我们的使用场景了：

无法直观呈现全链路视图：

缺少图表定制化能力：

三、 0x02 第二阶段

持续创造基于OpenTracing全链路采样监控

在当时， OpenTracing 相关的开源社区也是异常活跃，它使用 Jaeger 来解决数据的收集，调用链则使用了甘特图展示：

吞吐量：如每秒请求数，通常的实现方式是，设定一个计数器，每完成一次请求将自增。通过计算时间窗口内的变化率来计算出每秒的吞吐量。

延迟：处理请求的耗时。

错误率/错误数：如 HTTP 500 错误。当然，有些即便是 HTTP 200 状态也需要根据特定业务逻辑来区分当前请求是否属于“错误”请求。

饱和度：类似服务器硬件资源如CPU,内存,网络的使用率等等。

3.1 使用 Endpoint 贯穿指标埋点帮助性能分析

RPC 调用排障，调用方除了拥有下游接口信息，也可溯源自身触发该调用的接口。

接口高耗时分析，根据指标，可还原出单位时间窗口的耗时分解图快速查看耗时组件。

3.2 关于选型的疑问

3.3 架构特点

体验层面
- 指标：覆盖面广，维度细，能清晰地根据各模块各维度来统计分析，基本做到了监控灵活的图表配置需求。但不可否认它是一种时序聚合数据，无法细化为个体。假如在某个时间点发生过几次高耗时操作，当吞吐量达到一定时，平均耗时指标曲线仍然趋于平稳，没有明显的突出点，导致问题发现能力降低。

- 链路：1%的采样率使得业务服务基本不会因调用链发送量大而导致性能问题，但同时也往往无法从错误，高耗时的场景中找到正好采样的链路。期间，我们曾经考虑将头部采样策略改为尾部采样，但面临着非常高昂的 SDK 改造成本和复杂调用情况下（如异步）采样策略的回溯，且无法保证发生每个高耗时，错误操作时能还原整个完整的调用链路。‍
- 集成方式：业务和基础框架均采用 Maven 来构建项目，使用 Spring Boot Starter “all in one”开箱即用方式集成，极大降低了集成成本的同时，也给依赖冲突问题埋下了隐患。‍
项目迭代层面

数据治理层面

稳定性层面

相关预案依托于 Spring 框架 Bean 的自动装配逻辑，业务方理解成本低，便于变更，但缺少细粒度的预案，比如运行时期间特定逻辑降级等等。

2021 年下半年开始，为了充分平衡以上的收益与风险，我们决定将监控采集端与基础框架解耦，独立迭代。在此之前，在 CNCF（云原生计算基金会）的推动下，OpenTracing 也与 OpenCensus 合并成为了一个新项目 OpenTelemetry。

四、 0x03 第三阶段

向前一步基于OpenTelemetry全链路应用性能监控

OpenTelemetry架构（图源自 opentelemetry.io）

4.1 迈入 Trace2.0 时代

OpenMetrics 是建立在 Prometheus 格式之上的规范，做了更细粒度的调整，且基本向后兼容 Prometheus 格式。

Exemplar 数据在直方图度量格式末尾会追加当前上下文中的 Trace ID,Span ID 信息，如下：

分位线统计与Exemplar 数据关联UI示意图

得益于 OpenTelemetry 整体的可插拔式 API 设计，我们二次开发了 OpenTelemetry Java Instrumentation 项目 Shadower Java，扩展了诸多功能特性：

4.2 引入控制平面管理客户端采集行

使用控制平面，通过客户端监听机制来确保配置项的下发动作，包括：

实时动态采样控制
诊断工具 Arthas 行为控制
实时全局降级预案
遥测组件运行时开关
实时 RPC 组件出入参收集开关
实时高基数指标标签的降级控制
按探针版本的预案管理
基于授权数的灰度接入策略。

… …

控制平面的引入，弥补了无降级预案的空白，也提供了更加灵活的配置，支持了不同流量场景下快速变更数据采集方案：

4.3 独立的启动模块

4.4 基于 Otel API 的扩展

4.4.1 丰富的组件度量

部分自监控面板

4.4.2 扩展链路透传协

引入RPC ID

该字段拥有以下作用：

支持提供精简化的调用链路视图，查询臃肿链路（如那些涉及缓存，DB调用大于 2000 Span的链路）时只提供 RPC 调用节点和调用层次关系。

自定义 Trace ID

为了实现链路详情页高效的检索效率，我们扩展 TraceID 生成逻辑，ID的前8位使用实例IP，中8位使用当前时间戳，后16位采用随机数生成。

这样的好处有两点：

通过 TraceID 反向解析时间戳，锁定时间范围，有助于提高存储库 Clickhouse 的检索效率，此外也能帮助决定当前的 Trace 应该查询热库还是冷库。

绑定实例 IP，有助于关联当前 Trace 流量入口所属的实例，在某些极端场景，当链路上的节点检索不到时，也能通过实例和时间两个要素来做溯源。

异步调用识别

4.4.3 更清晰的调用链结构

RPC调用关键内部事件

DB 调用连接获取事件

4.4.4 profiling 的支持

关于性能诊断相关的运用，请期待后续诊断专题。

五、 0xff 结语

六、关于我们

参考文章：

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更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

关注公众号

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

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

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

上周，在 OpenAI 推出的 AI 对话模型 ChatGPT 风靡全网之际，Stack Overflow 曾宣布了一项临时规则：禁止使用 ChatGPT 生成的内容来回答 Stack Overflow 上的问题。现如今，Stack Overflow 已正式将这一规则更新为其最新政策。

并就“为什么目前不接受发布 GPT 和 ChatGPT 生成的答案”的举措做出了解释称：

Stack Overflow 是一个建立在信任基础上的社区。社区相信用户提交的答案反映了他们实际知道的准确信息，而且他们和他们的同伴有知识和技能来验证和确认这些答案。该系统依赖于用户使用我们提供的工具来验证和确认其他用户的贡献，包括负责任地使用赞成票和反对票。

而目前，由 GPT 生成的贡献通常不符合这些标准，因此不会为可信赖的环境做出贡献。当用户在不验证 GPT 提供的答案是否正确的情况下将信息复制并粘贴到答案中，没有确保答案中使用的来源被正确引用（GPT 不提供这种服务），也没有验证 GPT 提供的答案是否清楚和简洁地回答了所问的问题时，这种信任就被打破了。

Stack Overflow 上内容的客观性意味着，如果一个答案的任意部分是错误的，那么答案在客观上就是错误的。为了让 Stack Overflow 保持作为正确和经过验证信息的可靠来源的强大标准，必须编辑或替换此类答案。但是，由于 GPT 足以让网站用户相信答案有价值，社区通常用来确定其同行贡献合法性的信号经常无法检测到 GPT 生成的答案存在严重问题。结果，客观上错误的信息进入了网站。在目前的状态下，GPT 可能会破坏读者对我们网站提供由主题专家撰写的答案的信任。

鉴于此，政策指出，版主有权（自行决定）在没有事先通知或警告的情况下，对将 GPT 内容复制并粘贴到网站上的用户进行最多 30 天的账号暂停。

Reddit 上的一条热评也指出，自己曾使用了 ChatGPT 来回答一些 C++ 技术问题，它也快速的给出了非常明确的答案，并且完全按照他所希望的那样解决了他的问题。但不幸的是，后来事实证明，尽管 ChatGPT 的答案非常清晰明确，但它也是完全错误的。

“所以我很高兴它被 StackOverflow 禁止了。我可以想象它会因其清晰和权威的写作风格而迅速吸引大量赞成票和最终接受 – 但它不能被信任。”

微软计划在 2022 年 1 月 10 日结束对 Windows 7 和 8.1 的支持。支持结束后，使用这两个 Windows 版本的设备将不再接收更新，且某些程序（如 Chrome 或 Microsoft Edge）也无法接收版本更新。

Windows 7 和 8.1 在 Windows 市场份额中占有相当大的份额。据数据统计公司 Statcounter 的记录，截止到 2022 年 11 月，Windows 7 的市场份额为 10.25%，Windows 8.1 的市场份额为 2.53%。而微软最新的 Windows 11 操作系统也仅有 16.13% 的市场份额。也就是说，整个 Windows 用户群中，有 12% 的人在 2023 年 1 月面临系统支持终止的情况。

终结支持后，Windows 7 / 8.1 用户有以下几种选择：

用户可以选择继续使用 Windows 7 或 8.1 ，短期内不会出问题，但由于无法接受系统补丁和应用程序补丁，在出现一些较为严重的漏洞时会比较危险。
此外，用户可以选择升级到 Windows 10，而且不需要购买 Windows 10 许可证，因为旧的产品密钥允许用户免费升级到 Windows 10。Windows 10 在 2015 年发布，支持到 2025 年。微软很有可能在 2025 年延长支持，因为很多运行 Windows 10 的设备与 Windows 11 不兼容。
用户还可以选择升级到 Windows 11 ，但 Windows 11 比较新，运行 Windows 7 或 8.1 的老设备可能会出现一些兼容性问题，而且升级到 Windows 11 需要购买新的许可证，不太推荐。

当然还有一种选择，就是进入 Linux 世界！有些现代 Linux 发行版具备非常友好的图形化桌面环境，不需要 Linux 知识也能轻松使用，比如 Zorin OS ，它的界面和各项操作习惯都和 Windows 系统非常像…

1 如何将时间沉淀下来

虽然时间是无形的，看不见、摸不着，也无法贮存，但却可以通过有形的东西沉淀下来。

当你花时间写完一篇文章，时间就沉淀到文字中
当你录制了一个有趣的视频，时间就沉淀到视频里
当你花了一整天的时间整理房间，时间就沉淀到你每天的起居环境里
当你去健身房撸铁，时间就沉淀到每一块结实的肌肉里
当你种了一盆花，时间就沉淀到绽放的每一朵鲜花中

如果你创建了一个开源项目，时间就：

沉淀到你写的每一行代码里
沉淀到你为项目编写的每一篇文档里
沉淀到你提交或解决的每条 Issue / PR 里
沉淀到你的每一次代码检视意见和讨论里（图1）
沉淀到你组织的每一次会议中（图2）
沉淀到你与社区成员的每一次互动中

图1：代码检视

图2：开源社区会议

2 开源：将时间沉淀到代码里

2022年大部分时间都投入到了 Vue DevUI 开源项目的建设中，并于今年9月1日发布了1.0版本。

2.1 过程

从过程上来看，我个人的贡献主要如下：

贡献多行代码（除去等无效代码提交）
提交多个PR
报告多个Issue
提出多条代码检视意见
发布多个版本
撰写篇推广文章
组织多场线上沟通会
参加场线下开源会议分享

图3：Commits

图4：PR

Vue DevUI 推广文章：

👍：点赞<br> 🔖：阅读

295👍34526🔖 Vue DevUI 1.0 正式发布
173👍33991🔖 Vue DevUI：100多位贡献者持续530多天，写了近60000行代码，这个新鲜出炉的 Vue3 组件库你不想尝试下吗？
42👍10162🔖 20行代码，给你的项目增加 DevUI 主题切换能力
25👍1612🔖 探索开源社区开发模式：vue-devui 组件库 1.0 版本公开测试
10👍987🔖 请收下这份《Vue DevUI 公开测试参考指南》
11👍889🔖 DevUI 开源社区 Issue / PR 周报第2期：本周迎来贡献的超级大爆发，共10位贡献者提交26个PR
9👍1028🔖 DevUI 开源社区 Issue / PR 周报第1期
8👍1094🔖 如何在1分钟之内创建一个符合规范的DevUI组件

2.2 成果

从结果上来看，通过积极的社区运营：

增加位贡献者
增加颗Star
增加个PR
增加个Issue
微信社群增加多名成员
掘金增加多关注者
掘金增加近阅读
掘金增加个点赞

图5：Star trends

图6：GitHub card

图7：掘金数据

以下是我个人2022年的 GitHub 贡献图：

图8：Contributions

以下是我在中国开源年会现场的分享：

图9：Kagol 在中国开源年会现场的分享

2.3 社区 > 代码

我觉得这应该就是开源社区应有的样子：

一群来自全国各地（甚至全球各地）的开发者，因为有着同样的兴趣和志向聚集在一起，一起开发一个有价值的开源项目，大家真诚地相互交流、分享和协作，一起集思广益解决问题，一起享受成功的喜悦，也一起分担失败的痛苦。

旅行并不是达到目的地才是旅行，从你出门的那一刻起，风景就已经出现！

图10：Contributors

3 写作：将时间沉淀到文字中

除了做开源项目可以将时间沉淀下来，写文章也可以。

技术文章主要写了一个迷你的组件设计系列，给大家分享了我自己的组件设计观：

72👍6297🔖 前端开发的积木理论——像搭积木一样做前端开发
49👍3934🔖 用积木理论设计一个灵活好用的Carousel走马灯组件
13👍2706🔖 CarouseIndicator 组件应用：0行JS代码实现好看的手风琴式折叠卡片效果
21👍2003🔖 用积木理论设计的Carousel组件都有哪些有趣的玩法？

另外也写了几篇零散的文章：

11👍1560🔖 从 CDK Tree 源码学习如何开发一个UI无关的 Tree 组件
288👍23484🔖 前端Vuer，请收下这份《Vue3中使用JSX简明语法》
81👍4043🔖 前端Vuer，请给你的项目加上 ESLint
19👍1711🔖 DEVUI蓝掘金主题上线啦🎉

还有三篇分享我对开源运营的一些思考：

20👍1314🔖 DevUI 开源经验：从启动开源项目到运营开源社区
8👍3083🔖 从0到1开始运营你的开源项目——华为云DevUI成长经验分享
28👍1325🔖 运营一个开源社区究竟意味着什么？

React DevUI 18.0 正式发布🎉
好慌，我代码没了！不会是变基变出问题了吧？
老板：你为什么要选择 Vue？

写作方面今年做得不够，明年加油吧！

58👍1381🔖 手把手教你开发一个快速、高性能、高质量压缩图片的 Vite 插件 – ErKeLost
249👍11787🔖 🚀Turborepo：发布当月就激增 3.8k Star，这款超神的新兴 Monorepo 方案，你不打算尝试下吗？ – ErKeLost
53👍2655🔖 Ripple：这个广受好评的水波纹组件，你不打算了解下怎么实现的吗？ – ErKeLost
31👍3053🔖 骨架屏优化——细粒度模式的实现 – ivestszheng
47👍3406🔖 手把手教你实现 Tree 组件搜索过滤功能，干货满满！ – daviForevel

另外也要感谢我们团队成员的大力支持，特别是和同学，以下是他们的投稿文章：

25👍2157🔖 Angular依赖注入模式的应用和玩法案例 – rhlin
92👍5695🔖 如何使用 Monaco Editor 做一个在线的网页代码编辑器 – 汤汤Tang
15👍1413🔖 Angular PWA 渐进式 Web 应用 – 汤汤Tang
16👍1156🔖 TypeScript AST (抽象语法树) 结合 Angular Schematics 的应用 – 汤汤Tang

4 2023 年展望：将时间沉淀到自己的热爱里

2023年我依然会将主要精力投入开源和写作上，另外也会尝试：

运营自己的个人公众号（欢迎关注我：）和掘金账号，分享自己在前端和开源两个方向上的经验，欢迎大家关注我
参加一些内外部的分享，锻炼自己的演讲能力，增加个人影响力
尝试写一本掘金小册（惭愧，2021年立的 flag 到现在还没实现）

最后给大家推荐一部非常治愈的纪录片：《人生果实》。

— END —

我是 Kagol，如果你喜欢我的文章，可以给我点个赞，关注我的公众号，一起交流前端技术、一起做开源！

关注公众号

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

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

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

建木是一个面向DevOps领域的极易扩展的开源无代码(图形化)/低代码(GitOps)工具。可以帮助用户轻松编排各种DevOps流程并分发到不同平台执行。

建木v2.6.1现已发布

主要更新：增强功能、修复若干已知bug

enhancement:

与Git平台集成登录时可限定用户或组织

application.yml配置示例：

docker-compose.yml配置示例：

fixed:

建木HA部署后，cron任务会重复执行
不同场景下，Server小概率报CannotAcquireLockException/DeadlockLoserDataAccessException异常
超过worker调度限额时，节点的排队中状态未生效
终止流程时，排队中的任务失败后，仍可被Worker确认
流程实例手动终止时，会重复创建end任务
HA部署时，webhook并发会导致流程实例序号重复

官方示例

建木文档

建木官网

漏洞描述

Linux kernel 是一种开源的类 Unix 操作系统内核。

Linux kernel 的受影响版本中的 __do_proc_dointvec 函数由于未对用户输入进行有效限制从而存在基于栈的缓冲区溢出漏洞。漏洞源于攻击者对该函数中表示缓冲区大小的 “buffer”和“p”参数可控，它可以包含多于 1 页的数据，攻击者可通过构造以 NULL 结尾的恶意字符串触发此漏洞，从而造成程序拒绝服务。

漏洞名称 Linux kernel 基于栈的缓冲区溢出漏洞漏洞类型栈缓冲区溢出发现时间 2022-12-11 漏洞影响广度广 MPS编号 MPS-2022-67280 CVE编号 CVE-2022-4378 CNVD编号 –

影响范围

Linux kernel@[6.0, 6.0.12)

Linux kernel@[5.15, 5.15.82)

Linux kernel@[5.10, 5.10.158)

Linux kernel@[5.4, 5.4.226)

Linux kernel@[4.14, 4.14.301)

Linux kernel@[4.9, 4.9.335)

Linux kernel@[4.19, 4.19.268)

修复方案

升级Linux kernel到 4.9.335 或 4.14.301 或 4.19.268 或 5.4.226 或 5.10.158 或 5.15.82 或 6.0.12 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-67280

https://nvd.nist.gov/vuln/detail/CVE-2022-4378

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcebd677d83b19dad555a0e73

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6cfaf34be9fcd1a8285a294e18986bfc41a409c

情报订阅

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

具体订阅方式详见：

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

Puppy Linux 的开发人员发布了一个基于 Slackware 的 Puppy Linux 版本 “S15Pup”。它与 Slackware Linux 15.0 和 Salix 软件存储库兼容。

“S15Pup” 从名为 woof-CE 的“Puppy 构建器”系统构建，使用 woof-CE 可以从任何其他发行版的二进制包构建 Puppy Linux 发行版。Woof-CE 构建的每个“Puppy 发行版”本身就是一个独特的发行版，具有独特的功能。

S15Pup 是从 Slackware-15.0 二进制 TXZ 包构建的，因此与 Slackware 具有二进制兼容性并可以访问 Slackware 和 Salix 存储库。它有 64 位和 32 位版本。

功能包括：

“传统的”Puppy Linux 外观和功能。
来自 5 系列 LTS 分支的内核 – 5.15 用于 64 位，5.10 用于 32 位。
Abiword 和 Gnumeric 文字处理和电子表格。
Ffmpeg 和支持程序包括 Pmusic 和 Mplayer。
Joe 的窗口管理器 2.4.3 ( JWM )。
ydrv 的 LXDE 插件。
adrv 中的轻量级网络浏览器。
用于 Chromium、Firefox 和 Palemoon 等重量级浏览器的浏览器安装程序。
Samba，用于与 Windows 共享文件。
Evince pdf 查看器。

发布公告：https://distro.ibiblio.org/puppylinux/puppy-s15pup/release-S15Pup-22.12.htm

OpenShot 3.0 现已发布，此版本包含了 12 个月以来的 1000 多项改进。OpenShot 是跨平台的开源视频剪辑软件，该项目在 2008 年 8 月由 Jonathan Thomas 发起，其目标是提供稳定、自由且易于使用的视频编辑器。OpenShot 的核心视频编辑功能是以 C++ 库实现，称之为 libopenshot。

一些更新亮点包括：

改进的稳定性和内存使用
增强的实时视频播放性能。

OpenShot 3.0 最大和最显着的变化之一是改进了视频预览，使视频预览更流畅，预览期间的卡顿和暂停更少。开发团队重新设计了解码器，使其能够更好地应对丢失的数据包、丢失的时间戳，并更好地理解何时丢失视频或音频数据，因此可以继续前进而不会暂停。

数十项错误修复和相关改进也帮助OpenShot 3.0扩大了对更多视频格式和编解码器的兼容性，特别是较新的视频格式，它们往往更依赖多线程解码，如AV1。此外，许多与EOF (end of file) 检测和文件持续时间检测有关的改进进一步扩大了兼容性，甚至对那些缺少时间戳和不正确持续时间的不良编码文件（这在JavaScript编码的视频和某些类型的视频捕获文件中非常常见）。

视频缓存也经过大量重构和改进，以提供新功能和更多优化。OpenShot 利用缓存后台线程，在需要之前准备好即将到来的帧。此缓存算法已得到改进，可以以不同的速度（1X、2X、4X）以及向前和向后的方向运行。它现在还包括一个 pre-roll，用于在播放开始之前构建视频帧，提供更流畅的播放体验。

时间轴和可用性改进（捕捉、关键帧、波形、默认文件夹等）

捕捉精度已显着提高（同时修剪和移动剪辑/过渡）。按住 SHIFT 将使播放头线与剪辑的边缘对齐。使用 razor 工具切片剪辑现在更快（需要更少的 CPU）。关键帧图标得到了非常需要的 face lift，并且也更准确（即位置）。关键帧图标现在代表插值模式（圆形代表贝塞尔曲线，菱形代表线性，方形代表常量），并且可以和过滤。视频效果现在每种效果都有独特的颜色。过渡现在根据放置位置设置自己的方向（即淡入与淡出）。

对于那些喜欢使用音频波形的用户，此功能在 OpenShot 3.0 中也得到了极大的扩展和优化。

能够同时导出多个剪辑和视频
改进的用户指南/文档/帮助手册
更新的语言翻译和翻译系统
支持扩展的视频格式
支持 Blender 3.3
4K display | monitor 支持（高 DPI）

更多详情可查看官方博客。

KaOS Linux 开发团队近日发布了 KaOS Linux 2022.12 ，KaOS Linux 2022.12 搭载 Linux 6.0 内核系列、最新的 KDE Plasma 5.26.4 桌面环境，搭配最近发布的 KDE Gear 22.12 和 KDE Frameworks 5.101 开源软件套件，以上全部基于Qt 5.15.7+构建。

软件方面，Kjournald 得到了精美的 GUI，用于查看 systemd 日志，左侧窗格中有各种过滤器选项。

改进的 Calamares 安装程序，现在可以更好地支持 ZFS 文件系统。此版本还添加了新的应用程序 Ghostwriter，一个专用的 Markdown 编辑器。

另外，此前 KDE 项目宣布 KDE Plasma 5.27 将是 5.x 系列的最后一次更新，开发团队已经在开发 KDE Plasma 6 系列，该系列将完全移植到最新的 Qt 6 框架。

KaOS Linux 可能是最快搭载 KDE Plasma 6 桌面环境系列的发行版之一。

更多详情查看更新公告：https://kaosx.us/news/2022/kaos12/。

Linus Torvalds 宣布 Linux 6.1 内核系列正式发布！

Linux 6.1 内核系列集成了改进的页面回收代码的多代 LRU (MGLRU) 、初始的 Rust 语言支持（仍在构建中）、新的 AMD 平台管理框架、各种开源图形驱动程序改进、Btrfs 性能优化、Kernel Memory Sanitizer、Maple Tree 数据结构的引入以及许多其他硬件驱动程序工作。

有关每项 Linux 6.1 新功能的细节，请查看咱们 OSC 对应的报道：

初始的 Rust 基础设施已被合并到 Linux 6.1
Linux 6.1 内核合并面向 LoongArch 架构的 CPU 特性
Linux 6.1 将迎来 MGLRU 和 Maple Tree 支持
Linux 6.1 迎来 Btrfs 异步缓冲写入补丁，吞吐量翻倍
Linux 6.1 引入新功能，更容易辨认出故障的 CPU
Linux 6.1 引入 VirtIO 块“安全擦除”、vDPA 功能配置
Linux 6.1 Perf 新增 AMD CPU 内存报告和 Cache-To-Cache 功能

此外，公告中并没有提及 Linux 6.1 是否是 LTS 版本。按照 Linux 内核维护者 Greg Kroah-Hartman 的说法，Linux 内核的 LTS 通常会选取每年的最后一个内核版本（last kernel of the year），如今 Linux 6.1 赶在年末发布了，按照规矩它将会是 LTS 版本。

但 Carl Dasantas 提出了不同的看法，他表示 Linux 6.0 或 5.19 更合适作为 LTS 版本。因为 Linux 6.1 有 Rust，很多社区都对 Rust 犹豫不决，如果有一个除了 5.15 之外不支持 Rust 的 LTS 会更好，可以让 LTS 过渡更加顺利。

但目前尚不清楚最后会选择哪一个， kernel.org 上的 longterm （LTS）版本也还没有更新。

Kubernetes 1.26 已正式发布。此版本总共包含 37 项功能变化，其中：11 项增强功能正在升级到 stable 阶段，10 项增强功能正在升级到 beta 阶段，16 项增强功能正在进入 alpha 阶段，此外还有 12 项功能已被标记为弃用或删除。

Kubernetes v1.26 的主题是 Electrifying。团队希望通过此版本认识到 Kubernetes 赖以开发和使用的所有这些构建块的重要性，同时提高人们对考虑能源消耗足迹的重要性的认识：“环境的可持续性是任何软件解决方案的创造者和使用者不可回避的问题，而像 Kubernetes 这样的软件的环境足迹，我们相信会在未来的版本中发挥重要作用。”

主要变化：

容器镜像注册表的更改

在之前的版本中，Kubernetes 改变了容器注册表，允许将负载分散到多个 Cloud Provider 和 Region 中，这一改变减少了对单个实体的依赖，并为大量用户提供了更快的下载体验。

此版本的 Kubernetes 是第一个专门在新的容器镜像注册表中独家发布的版本。在（现在是遗留的）镜像注册表中，不会发布 v1.26 的容器镜像标签，只会继续更新 v1.26 之前版本的标签。有关这一重大变化的动机、优势和影响的更多信息，可参阅 registry.k8s.io：更快、更便宜和普遍可用。

移除 CRI v1alpha2

随着容器运行时接口 (CRI) 的采用和 dockershim 在 v1.24 中的移除，CRI 是 Kubernetes 与不同容器运行时交互的唯一受支持和记录的方式。每个kubelet都要与该节点上的容器运行时协商使用哪个版本的CRI。

在之前的版本中，Kubernetes 项目建议使用 CRI 版本，但 kubelet 仍然可以协商使用 CRI ，该版本已被弃用。

Kubernetes v1.26 放弃了对 CRI 的支持。这意味着Kubernetes 1.26中不支持containerd次要版本1.5和更早的版本；如果你使用containerd，你需要在将该节点升级到Kubernetes v1.26之前升级到containerd版本1.6.0或更高版本。这同样适用于任何其他只支持v1alpha2的容器运行时：如果这对你有影响，你应该联系容器运行时供应商寻求建议，或者查看他们的网站，了解如何前进的额外指示。

Storage 改进

这个版本继续添加（和删除）符合迁移目标的功能，以及对 Kubernetes 存储的其他改进。

Azure File 和 vSphere 的 CSI 迁移升级到 stable
Delegate FSGroup to CSI Driver 升级到 stable
In-tree GlusterFS 驱动程序删除
In-tree OpenStack Cinder 驱动程序删除

Signing Kubernetes 发布工件升级到 beta

该功能在 Kubernetes v1.24 中引入，是提高 Kubernetes 发布过程安全性的重要里程碑。所有发布的工件都使用 cosign 进行了无密钥签名，二进制工件和图像都可以得到验证。

对 Windows 特权容器的支持升级到 stable

特权容器支持允许容器以类似于直接在主机上运行的进程的权限运行。在 Windows 节点中支持此功能，称为 HostProcess containers，现在将升级为 Stable，实现从特权容器访问主机资源（包括网络资源）。

更多详情可查看官方公告。

作者：谢泽华

背景

架构

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. 迁移索引

以下提供创建索引的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

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中，由此问题得以解决。

示例：

Rubik是一套解决Android平台组件化的综合方案，提供gradle project之间的路由通讯能力，以及对gradle project的组件定义、版本控制、maven发布、aar/jar与源码之间的切换以及组件的自由组合等能力。

English Readme

Rubik由两部分组成：

Rubik Router ：即Rubik的函数级路由能力，与一般的页面路由不同，Rubik Router允许把Uri及参数，导航到工程内部，任意的一个公开的JVM语言（Java/Kotlin）函数的执行上，以便于更灵活的进行gradle project之间不基于代码调用的通讯。
Rubik 工具链：提供组件上下文的定义、版本控制、maven发布、aar/jar与源码之间的切换等能力，包括4个gradle plugin:
- rubik：
  - 提供全局定义组件的能力，并根据全局定义自动启用rubik-context、rubik-root等插件
- rubik-context：
  - 提供task，自动生成镜像函数等中间代码，并把中间代码打包成context.jar ,按版本号发布到maven
  - 提供task，把业务代码按flavor、版本号编译成aar (包括代码、资源、内置SDK)发布到maven
  - 通过全局定义的组件，为组件所在子工程自动添加其他context.jar的依赖
- rubik-root：
  - 给壳工程提供筛选组件等能力，根据flavor、版本号筛选要打包进apk的业务组件
  - 提供组件的源码工程和aar切换的能力
- rubik-test:
  - 给工程提供单测试环境

快速开始

1. 工程创建和组件声明：

(1) 创建或使用已有的一个或多个android library module，作为”组件工程”（如demo代码中的demo_component_detail、demo_component_home等），用于开发真正的业务逻辑。

(2) 在最外层工程（gradle root project)的build.gradle或gradle.properties文件中配置Rubik版本号等初始化参数，并在最外层工程中启用rubik插件：

(3) 在最外层工程的build.gradle文件或同级目录下的rubik-*.gradle文件中，配置组件信息：

2. 让组件之间互相通信：

(1). 在接口提供者工程内，通过注解定义路由路径，作为组件暴露给其他组件的通信接口：

通过RFunction注解声明函数路由:

通过RPage注解声明页面路由:

(2). 执行接口提供者工程对应的”publishRubikXxxRContextLib”任务，发布组件上下文到云端或本地maven仓库。

(3). 执行接口提供者工程对应的”publishRubikXxxRComponent”任务，发布组件aar到云端或本地maven仓库。

(4). 在接口调用者工程内，调用上述接口提供者所提供的接口，可以选择两种方式：

通过Kotlin DSL：

通过自动生成的镜像函数：

3. 筛选要打包的组件

(1). 创建或使用已有的android application project，作为”壳工程”（如demo代码中的demo_root_app），用于把组件组装并编译成Apk。

(2). 在”壳工程”的的build.gradle文件或同级目录下的rubik-*.gradle文件中，指定”壳工程”最终要将哪些组件，以哪种方式引入，并打包到最终的编译产物之中：

测试

通过rubik-test插件，给当前工程的androidTest variant添加全部可pick组件的context.jar依赖，便于写测试用例。

谷歌方面已经按照原定的计划，实现了在 Chrome/Chromium 110 中取消对 JPEG-XL 支持的决定。目前相关代码已经完成合并，从 Chromium/Chrome 网络浏览器代码库中删除了 JPEG-XL 支持。

在相关消息于今年 10 月份刚被曝出时，就有一些用户和开发者表达了对 JPEG-XL 的支持；并试图促使谷歌改变他们对取消 JPEG-XL 支持的立场，但事实证明他们并没有成功。谷歌方面曾解释称，他们作出这一决定的原因在于：

处于实验性阶段的 flag 和代码不应无限期地保留
整体生态对 JPEG-XL 格式缺乏兴趣，难以继续推动试验
与现有的格式相比，新的图像格式并没有带来足够的增量收益，因此没有理由默认启用它
通过移除相关代码可以减轻维护负担，帮助开发者专注于改进 Chrome 中的现有格式

且谷歌也对 WebP 和 AVIF 等替代格式更感兴趣。谷歌/AVIF 团队近日还分享一份基准测试结果，将 AVIF 图像格式与 WebP、JPEG 和 JPEG XL 图像格式进行了比较。

JPEG XL 基于 Google 的 PIK 格式和 Cloudinary 的 FUIF 格式（该格式基于 FLIF），它的默认设置能在实现接近无损的视觉效果的同时，提供良好的压缩效果，这一项目希望成为其他光栅有损和无损图像格式的通用替代品。

JPEG 是指联合影像专家小组，它是设计该格式的委员会。

X 是指自 2000 年以来的几个 JPEG 标准的名称的一部分： JPEG XT 、 JPEG XR 、JPEG XS 。

L 代表长期，因为创建这种格式的意图是替换旧的 JPEG 文件格式并能被使用同样长的时间。

JPEG-XL 比特流格式于 2021 年底完成，并开始被各种开源和闭源应用程序采用。JPEG-XL 的目标是免版税，不过今年早些时候微软获得了有关 JPEG-XL 使用的 “rANS”（范围非对称数字系统）数据压缩的专利，这引起了一些担忧。

Linux 6.1 合并了最初的 Rust 基础设施，但如今 Linux 6.1 已作为稳定版发布，其 Rust 支持仍处于初级阶段，没有任何面向最终用户的 Rust 功能。

Linux 6.2 仍在补充 Rust 代码，据外媒 Phoronix 报道，负责 Rust For Linux 部分的内核开发者 Miguel Ojeda 已经向 Linux 6.2 合并窗口发出了一个新 PR，提供一批新的 Rust 基础代码。

与 Linux 6.1 中的 Rust 支持类似，Linux 6.2 的 Rust 代码继续对 Rust 的内核构建提供更多功能，尚未引入任何新的 Rust 编写的硬件驱动程序，因此它对内核开发人员更有用。最新的 Rust for Linux 6.2 的补丁包括以下内容：

字符串和格式：新类型 `CString`、`CStr`、`BStr` 和 `Formatter`；新宏“c_str!”、“b_str!” 和 “fmt!”。
错误：来自 errno-base.h 的其余错误代码，以及 Error 类型的一些 From 特性实现。
Printing：其余的级别和后续的，以及一个新样本。
`alloc` crate:：和的新构造函数和。
程序宏：新宏和，以及为用户提供更好的人体工程学。
断言：新宏、和，以及支持它们的新 crate 。
Vocabulary 类型：新类型和。
调试：新宏。

有关 Rust 补丁的完整细节，请参阅内核中的 Rust PR 邮件。

导读：随着营销3.0时代的到来，企业愈发需要依托强大CDP能力解决其严重的数据孤岛问题，帮助企业加温线索、促活客户。但什么是CDP、好的CDP应该具备哪些关键特征？本文在回答此问题的同时，详细讲述了爱番番租户级实时CDP建设实践，既有先进架构目标下的组件选择，也有平台架构、核心模块关键实现的介绍。

本文系百度爱番番技术团队撰写，首发于#百度Geek说#公众号

一、CDP是什么

1.1 CDP由来

CDP（Customer Data Platform）是近些年时兴的一个概念。随着时代发展、大环境变化，企业在自有媒体增多的同时，客户管理、营销变难，数据孤岛问题也愈发严重，为了更好的营销客户CDP诞生了。纵向来看，CDP出现之前主要经历了两个阶段。CRM时代，企业通过电话、短信、email与现有客户和潜在客户的互动，以及执行数据分析，从而帮助推动保留和销售；DMP阶段，企业通过管理各大互联网平台进行广告投放和执行媒体宣传活动。

CRM、DMP、CDP三个平台核心作用不同，但纵向来对比，更容易理解CDP。三者之间在数据属性、数据存储、数据用途等方面都较大差异。

有几个关键区别如下：

CRM vs CDP
- 客户管理：CRM侧重于销售跟单；CDP更加侧重于营销。
- 触点：CRM的客户主要是电话、、邮箱等；CDP还包含租户的自有媒体关联的用户账号（例如，企业自己的网站、App、公众号、小程序）。
DMP vs CDP
- 数据类型：DMP是匿名数据为主；CDP以实名数据为主。
- 数据存储：DMP数据只是短期存储；CDP数据长期存储。

1.2 CDP定义

2013年MarTech分析师 David Raab首次提出CDP这个概念，后来其发起的CDP Institute给出权威定义：packaged software that creates a persistent, unified customer database that is accessible to other systems。

这里面主要包含三个层面：

Packaged software：基于企业自身资源部署，使用统一软件包部署、升级平台，不做定制开发。
Persistent, unified customer database：抽取企业多类业务系统数据，基于数据某些标识形成客户的统一视图，长期存储，并且可以基于客户行为进行个性化营销。
Accessible to other systems：企业可以使用CDP数据分析、管理客户，并且可以通过多种形式取走重组、加工的客户数据。

1.3 CDP分类

CDP本身的C（Customer）是指all customer-related functions, not just marketing。面向不同场景也对应不同类型的CDP，不同类别的CDP主要是功能范围不同，但是类别之间是递进关系。

主要分为四类：

Data CDPs：主要是客户数据管理，包括多源数据采集、身份识别，以及统一的客户存储、访问控制等。
Analytics CDPs：在包含Data CDPs相关功能的同时，还包括客户细分，有时也扩展到机器学习、预测建模、收入归因分析等。
Campaign CDPs：在包含Analytics CDPs相关功能的同时，还包括跨渠道的客户策略（Customer Treatments），比如个性化营销、内容推荐等实时交互动作。
Delivery CDPs：在包括Campaign CDPs相关功能的同时，还包括信息触达（Message Delivery），比如邮件、站点、App、广告等。

Campaign CDPs、Delivery CDPs两类较Analytics CDPs多出的功能，在国内更贴近MA（Marketing Automation，营销自动化）。本文所讲的CDP从提供的功能范围来说，属于Analytics CDPs。在爱番番也有专门的MA系统，本文的CDP为其提供数据支撑。

二、挑战与目标

2.1 面临挑战

随着营销3.0时代的到来，以爱番番私域产品来说，主要是借助强大的CDP为企业提供线上、线下数据的打通管理的同时，企业可以使用精细化的客户分群，进行多场景的增育活动（比如自动化营销的手段，节假日促销通知，生日祝福短信，直播活动等等）。更重要的是，企业可以基于纯实时的用户行为进行更加个性、准确、及时的二次实时营销，帮助企业加温线索、促活客户，提升私域营销转化效果。那如何做好实时CDP（Real-Time CDP，缩写为RT-CDP）驱动上层营销业务，面临诸多挑战。

【业务层面】

1.企业数据渠道多，数据形态各异

一个企业除了官网、文件、App、自有系统，还包括目前众多的企业自有媒体（比如微信公众号、抖音企业号、百家号、各类小程序等）等各种场景的数据结构不统一，如何高效接入企业数据到RT-CDP？这也是成千上万的企业主们在客户数据融合的课题上亟需解决的系统化问题。

2.不同生态无法打通，无法360度洞察用户

数据分散导致难以识别唯一用户身份，无法建立全面且持续更新的用户画像，导致对用户的认知碎片化片面化，洞察不足。比如在实际营销场景下，企业期望对同时访问官网和其小程序的同一用户发放优惠券促活时，但因为一个人的行为以不同标识分散在各渠道数据中，无法进行跨渠道用户行为分析，也就无法实现企业诉求。

3.人群划分规则复杂

我们不同企业的业务是不同的，所以我们可以根据业务特点，为不同的客户打上个性化的标签，比如企业进行营销活动时，想给经过迭代旅程节点的用户、参与某个直播等等的打上不同场景的标签，这样才能对不同的人群进行细分，做更精细化的营销。

4.如何用一个平台服务好B2B2C、B2C两类企业，行业可借鉴经验少

爱番番的客户涉及多类行业，有的B2C的也有B2B2C的。相对于B2C，B2B2C的业务场景复杂度是指数级上升。在管理好B、C画像的同时，还要兼顾上层服务的逻辑，比如身份融合策略、基于行为的圈选等。另外，在许多业务场景也存在很多业务边界不清晰的问题。

【技术层面】

1.全渠道实时精准识别要求高

当今时代一个客户行为跨源跨设备跨媒体，行为轨迹碎片化严重。如果企业想营销效果好，精准、实时识别客户、串联客户行为轨迹是重要前提。那如何在多源多身份中做到高性能的实时识别也是个很大挑战。

2.需要具有实时、低延迟处理海量数据的能力

现在客户可选择性多，意向度不明确，基于客户行为实时营销，以及基于客户反馈的实时二次交互是提高营销效果的关键，比如企业营销部门群发一个活动短信，客户点没点，点了有什么样进一步的动作，代表着客户不同的意向程度，企业营销、销售人员需要根据客户动作进行及时进一步的跟进。只有实时把握这些变化，才能更高效地促进营销活动的转化。如何实时处理海量数据驱动业务？

3.需要可扩展的架构

在多租户背景下，爱番番管理数千、万中小企业的海量数据。随着服务企业数量的不断增加，如何快速不断提升平台的服务能力，需要设计一个先进的技术架构。另外，如何做到高性能、低延迟、可伸缩、高容错，也是很大的技术挑战。

4.多租户特性、性能如何兼顾

爱番番私域产品是以Saas服务形式服务于中小企业，那一个具备多租户特性的CDP是一个基本能力。虽然中小企业客户一般十万、百万量级不等，但随着企业进行的营销活动的累增，企业的数据体量也会线性增长。对于中大企业来说，其客户量级决定了其数据体量增长速度更快。另外，不同企业对于数据查询的维度各异很难做模型预热。在此前提下，如何兼顾可扩展性、服务性能是个难题。

5.多样部署扩展性

CDP目前主要以Saas服务服务于中小企业，但不排除后续支持大客户OP部署（On-Premise，本地化部署）的需求，如何做好组件选型支持两类服务方式？

2.2 RT-CDP建设目标

2.2.1 关键业务能力

经过分析和业务抽象，我们觉得，一个真正好的RT-CDP需要做到如下几个关键特征：

灵活的数据对接能力：可以对接客户各种数据结构多类数据源的客户系统。另外，数据可以被随时访问。
同时支持 B2C和B2B两类数据模型：面向不同的行业客户，用一套服务支撑。
统一的用户、企业画像：包含属性、行为、标签（静态、动态（规则）标签、预测标签）、智能评分、偏好模型等等。
实时的全渠道身份识别、管理：为了打破数据孤岛，打通多渠道身份，是提供统一用户的关键，也是为了进行跨渠道用户营销的前提。
强大的用户细分能力（用户分群）：企业可以根据用户属性特征、行为、身份、标签等进行多维度多窗口组合的用户划分，进行精准的用户营销。
用户的实时交互、激活：面对用户习惯变化快，实时感知用户行为进行实时自动化营销能力尤为重要。
安全的用户数据管理：数据长期、安全存储是数据管理平台的基本要求。

2.2.2 先进技术架构

明确平台业务目标的同时，一个先进的技术架构也是平台建设的目标。如何做到平台架构，我们有如下几个核心目标：

1.流数据驱动

在传统数据库、数据处理上，还主要是『数据被动，查询主动』。数据在数据库中处于静止状态，直到用户发出查询请求。即使数据发生变化，也必须用户主动重新发出相同的查询以获得更新的结果。但现在数据量越来越大、数据变化及时感知要求越来越高，这种方法已无法满足我们与数据交互的整个范式。

现在系统架构设计如下图，更倾向于主动驱动其他系统的架构，比如领域事件驱动业务。数据处理亦是需要如此：『数据主动、查询被动』。

举个例子，企业想找到访问过企业小程序的用户进行发短信时，两种分别如何做？

传统方式：先将用户数据存入存储引擎，在企业发短信之前再将查询条件转换成sql，然后去海量数据中筛选符合条件的用户。

现代方式：在用户数据流入数据系统时，进行用户画像丰富，然后基于此用户画像进行符不符合企业查询条件的判断。它只是对单个用户数据的规则判断，而不是从海量数据筛选。

2.流计算处理

传统的数据处理更多是离线计算、批量计算。离线计算就是Data at rest，Query in motion；批量计算是将数据积累到一定程度，再基于特定逻辑进行加工处理。虽然两者在数据处理数据方式也有所不同，但是从根本上来说都是批量处理，天然也就有了延迟了。

流式计算则是彻底去掉批的概念，对流数据实时处理。也就是针对无界的、动态的数据进行持续计算，可以做到毫秒级延迟。在海量数据时代竞争激烈的今天，对企业洞察来说尤为如此，越快挖掘的数据业务价值越高。

3.一体化实践

【批流一体】

在大数据处理领域，存在两个典型的架构（Lamda、Kappa、Kappa+）。Lamda架构就是批计算、实时计算走两套计算架构，导致有时候有的相同逻辑开发两套代码，容易出现数据指标不一致，也带来了维护困难。Kappa、Kappa+架构是旨在简化分布式计算架构，以实时事件处理架构为核心兼顾批流两种场景。在大多数企业实际生产架构中还是两者混合较多，因为彻底的实时架构存在很多难点，比如数据存储、某些批计算更易处理的大窗口聚合计算等。

【统一编程】

在实际业务场景中，批、流处理依然是同时存在的。考虑到随着分布式数据处理计算发展，分布式处理框架也会推陈出新，虽然Apache Flink在批流一体支持上很活跃，但还不太成熟。另外，在各个公司多个计算框架并用的情况还是普遍存在。所以统一数据处理编程范式是一个重要的编程选择，可以提高编程灵活性，做到支持批、流场景数据处理作业开发，做到一套处理程序可以执行在任意的计算框架上，这样也利于后续平台切换更优秀的计算引擎。

4.可扩展为前提

这里主要是指架构的扩展性，一个具有扩展性的架构可以在稳定服务业务的同时合理控制资源成本，才能可持续支撑业务的快速发展。

【算存分离】

在如今海量数据的大数据时代，在不同场景下有时仅需要高处理能力，有时仅需要海量数据存储。传统存算一体架构，如果要满足两种场景，就需要高配置（多核、多内存、高性能本地盘等）服务节点，显然存在资源利用不合理，也会引发集群稳定性问题，比如节点过多导致数据分散，引发数据一致性降低等。算存分离的架构才符合分布式架构的思想，针对业务场景进行计算资源、存储资源的分别控制，实现资源合理分配。也利于集群数据一致性、可靠性、扩展性、稳定性等方面的能力保证。

【动态伸缩】

动态伸缩主要为了提高资源利用率，降低企业成本。实际业务中，有时候平台需要应对在业务平稳期短时间段内的流量（实时消息量）波峰波谷需要短期扩容，比如在各个重要节日大量企业同时需要做很多营销活动，导致消息量陡升；有时候随着爱番番服务的企业量不断增长，也会导致消息量线性增加，进而需要长期扩容。针对前者，一方面不好预见，另一方面也存在很高的运维成本。所以一个可以基于时间、负载等组合规则动态扩缩容的集群资源管理能力也是架构建设的重要考虑。

三、技术选型

没有万能的框架，只有合适的取舍。需要结合自身业务特点和架构目标进行合理选型。结合RT-CDP建设目标，我们做了如下几个核心场景的组件调研、确定。

3.1 身份关系存储新尝试

在CDP中跨渠道身份打通（ID Mapping）是数据流渠道业务的核心，需要做到数据一致、实时、高性能。

传统的idmapping是怎么做？

1.使用关系型数据库存储身份关系一般是将身份关系存成多表、多行进行管理。该方案存在两个问题：

数据高并发实时写入能力有限；

一般身份识别都需要多跳数据关系查询，关系型数据库要查出来期望数据就需要多次Join，查询性能很低。

2.使用Spark GraphX进行定时计算一般是将用户行为存入Graph或者Hive，使用Spark定时将用户行为中身份信息一次性加载到内存，然后使用GraphX根据交叉关系进行用户连通性计算。该方案也存在两个问题：

不实时。之前更多场景是离线聚合、定时对用户做动作；

随着数据量增加计算耗时会越来越高，数据结果延迟也会越来越高。

我们怎么做？

随着近几年图技术的发展，基于图解决业务问题的案例越来越多，开源图框架的产品能力、生态集成越来越完善，社区活跃度也越来越高。所以我们尝鲜基于图进行身份关系建模，借助图自然的多度查询能力进行实时身份判断、融合。

图框架对比

大家也可以结合最新的图数据库的排名走势，进行重点调研。另外，关于主流图库对比案例也越来越多，可以自行参考。在分布式、开源图数据库中主要是HugeGraph、DGraph和NebulaGraph。我们在生产环境主要使用了DGraph和NebulaGraph。因为爱番番服务都是基于云原生建设，平台建设前期选择了DGraph，但后来发现水平扩展受限，不得不从DGraph迁移到NebulaGraph（关于DGraph到NebulaGraph的迁移，坑还是挺多的，后续会有专门文章介绍，敬请期待）。

网上对 DGraph 和 NebulaGraph 对比很少，这里简单说一下区别：

集群架构：DGraph是算存一体的，其存储是BadgerDB，go实现的对外透明；NebulaGraph读写分离，但默认是RocksDB存储（除非基于源码更换存储引擎，也有公司在这么搞），存在读写放大问题；
数据切分：DGraph是基于谓词切分（可以理解为点类型），容易出现数据热点，想支持多租户场景，就需要动态创建租户粒度谓词来让数据分布尽量均匀（DGraph企业版也支持了多租户特性，但收费且依然没考虑热点问题）；NebulaGraph基于边切分，基于vid进行partition，不存在热点问题，但图空间创建时需要预算好分区个数，不然不好修改分区数。
全文检索：DGraph支持；NebulaGraph提供listener可以对接ES。
Query语法：DGraph是自己的一个查询语法；NebulaGraph有自身查询语法之外，还支持了Cypher语法（Neo4j的图形查询语言），更符合图逻辑表达。
事务支持：DGraph基于MVCC支持事务；NebulaGraph不支持，其边的写事务也是最新版才支持的（2.6.1）。
同步写：DGraph、NebulaGraph均支持异步、同步写。
集群稳定性：DGraph集群更稳定；NebulaGraph的稳定性还有待提升，存在特定运算下偶发Crash的情况。
生态集群：DGraph在生态集成更成熟，比如与云原生的集成；NebulaGraph在生态集成范围上更多样一些，比如nebula-flink-connector、nebula-spark-connector等，但在各类集成的成熟度上还有待提升。

3.2 流式计算引擎选择

对于主流计算框架的对比，比如Apache Flink、Blink、Spark Streaming、Storm，网上有很多资料，大家也请自行调研就好，比如如下，详见链接： https://blog.csdn.net/weixin_/article/details/

选择Apache Flink做为流批计算引擎

使用广泛的Spark还是以微批的方式进行流计算。而Flink是流的方式。Apache Flink是近几年发展很快的一个用于分布式流、批处理数据处理的开源平台。它是最贴合DataFlow模型实现的分布式计算框架。基于流计算进行高性能计算，具有良好的容错、状态管理机制和高可用能力；其他组件与Flink的集成也越来越多、也日趋成熟；所以选择我们Apache Flink作为我们的流批计算引擎。

选择Apache Beam作为编程框架

分布式数据处理技术不断发展，优秀的分布式数据处理框架也会层出不穷。Apache Beam是Google在2016年贡献给Apache基金会的孵化项目，它的目标是统一批处理和流处理的编程范式，做到企业开发的数据处理程序可以执行在任意的分布式计算引擎上。Beam在统一编程范式的同时也提供了强大的扩展能力，对新版本计算框架的支持也很及时。所以我们选择Apache Beam作为我们的编程框架。

3.3 海量存储引擎取舍

在Hadoop 生态系统存储组件中，一般用HDFS支持高吞吐的批处理场景、用HBase支持低延迟，有随机读写需求的场景，但很难只使用一种组件来做到这两方面能力。另外，如何做到流式计算下的数据实时更新，也影响存储组件的选择。Apache Kudu 是 Cloudera 开源的列式存储引擎，是一种典型的HTAP(在线事务处理/在线分析处理混合模式)。在探索HTAP的方向上，TiDB、Oceanbase均在此行列，只是大家起初侧重的场景不同而已，大家也可以对比一下。ApacheKudu的愿景是fast analytics on fast and changing data。从Apache Kudu的定位，如下图可见一斑：

结合我们的平台建设理念，实时、高吞吐的数据存储、更新是核心目标，在数据复杂查询、数据应用的QPS上不高（因为核心的业务场景是基于实时流的实时客户处理），再加上Cloudera Impala无缝集成Kudu，我们最终确定Impala+Kudu作为平台的数据存储、查询引擎。

分析增强：Doris

基于Impala+Kudu的选型，在支持OP部署时是完全没有问题的，因为各个企业的数据体量、数据查询QPS都有限。这样企业只需要很简单的架构就可以支持其数据管理需求，提高了平台稳定性、可靠性，同时也可以降低企业运维、资源成本。但由于Impala并发能力有限（当然在Impala4.0开始引入多线程，并发处理能力提升不少），爱番番的私域服务目前还是以Saas服务为重，想在Saas场景下做到高并发下的毫秒级数据分析，这种架构性能很难达标，所以我们在分析场景引入了分析引擎Doris。之所以选择Doris，基于 MPP 架构的 OLAP 引擎。相对于Druid、ClickHouse等开源分析引擎，Doris具有如下特点：l支持多种数据模型，包括聚合模型、Uniq模型、Duplicate模型；l支持Rollup、物化视图；l在单表、多表上的查询性能都表现很好；l支持MySQL协议，接入、学习成本低；l无需集成Hadoop生态，集群运维成本也低很多。

3.4 规则引擎调研

实时规则引擎主要用于客户分群，结合美团的规则对比，几个引擎（当然还有一些其他的URule、Easy Rules等）特点如下：

RT-CDP中客户分群规则分类、组合多，规则计算复杂、算子多，时间窗口跨度大、甚至无窗口，业内没有一个能很好满足业务需求的开源规则引擎，所以我们选择了自研。

四、平台架构

4.1 整体架构

在爱番番私域产品中，主要分为两部分：RT-CDP和MA，两者叠加近似等同于Deliver CDP所包含的功能范围。本文所讲的RT-CDP所包含的功能范围等同于Analytics CDPs，简单来讲，主要就是客户数据管理、数据分析洞察。

RT-CDP也是就两部分功能进行拆分，主要包含五部分：数据源、数据采集、实时数仓，数据应用和公共组件，除公共组件部分是横向支撑外，其他四部分就是标准的数据对接到数据应用的四个阶段：

数据源：这里的数据源不仅包含客户私有数据，也包括在各个生态上的自有媒体数据，比如微信公众号、微信小程序、企微线索、百度小程序、抖音企业号、第三方生态行为数据等。
数据采集：大多中小企业没有研发能力或者很薄弱，如何帮助快速将自有系统对接到爱番番RT-CDP是这层需要重点考虑的，为此我们封装了通用的采集SDK来简化企业的数据采集成本，并且兼容uni-app等优秀前端开发框架。另外，由于数据源多种多样、数据结构不一，为了简化不断接入的新数据源，我们建设了统一的采集服务，负责管理不断新增的数据通道，以及数据加解密、清洗、数据转换等数据加工，这个服务主要是为了提供灵活的数据接入能力，来降低数据对接成本。
实时算存：在采集到数据后就是进行跨渠道数据身份识别，然后转换成结构化的客户统一画像。就数据管理来说，这层也包含企业接入到CDP中的碎片客户数据，为了后续企业客户分析。经过这层处理，会形成跨渠道的客户身份关系图、统一画像，然后再通过统一视图为上层数据接口。另外，就是数仓常规的数据质量、资源管理、作业管理、数据安全等功能。
数据应用：这层主要是为企业提供客户管理、分析洞察等产品功能，比如丰富的潜客画像、规则自由组合的客户分群和灵活的客户分析等。也提供了多种数据输出方式，方便各个其他系统使用。
公共组件：RT-CDP服务依托爱番番先进的基础设施，基于云原生理念管理服务，也借助爱番番强大的日志平台、链路追踪进行服务运维、监控。另外，也基于完备的CICD能力进行CDP能力的快速迭代，从开发到部署都是在敏捷机制下，持续集成、持续交付。

4.2 核心模块

简单来说，RT-CDP实现的功能就是多渠道数据的实时、定时采集，然后经过数据中身份的识别Identity服务，再进行数据处理、数据进行数据映射、加工（比如维度Join、数据聚合、数据分层等），然后进行结构化持久化，最后对外实时输出。

RT-CDP主要划分为六大模块：采集服务、Connectors、Identity Service、实时计算、统一画像和实时规则引擎。上图就是从数据交互形式和数据流向的角度描绘了RT-CDP核心模块之间的交互。从左到右是数据的主流向，代表了数据进入平台到数据输出到和平台交互的外部系统；中间上侧是实时计算和Identity Service、实时规则引擎和统一画像的双向数据交互。

下面结合数据处理阶段进行各个核心模块的功能说明：

1.数据源&采集

从数据源和RT-CDP数据交互方式上，主要分为实时流入和批次拉取。针对两种场景，我们抽象了两个模块：实时采集服务和Connectors。

实时采集服务：该模块主要是对接企业已有的自有媒体数据源，爱番番业务系统领域事件以及爱番番合作的第三方平台。这层主要存在不同媒体平台API协议、场景化行为串联时的业务参数填充、用户事件不断增加等问题，我们在该模块抽象了数据Processor&自定义Processor Plugin等来减少新场景的人工干预。
Connectors ：该模块主要是对接企业的自有业务系统的数据源，比如MySQL、Oracle、PG等业务库，这部分不需要实时接入，只需按批次定时调度即可。这里需要解决的主要是多不同数据源类型的支持，为此我们也抽象了Connector和扩展能力，以及通用的调度能力来支持。针对两种场景下，存在同一个问题：如何应对多样数据结构的数据快读快速接入？为此，我们抽象了数据定义模型（Schema），后面会详细介绍。

2.数据处理

Identity Service：该模块提供跨渠道的客户识别能力，是一种精准化的ID Mapping,用于实时打通进入RT-CDP的客户数据。该服务持久化了客户身份相关关系图放在NebulaGraph中，会根据实时数据、身份融合策略进行实时、同步更新NebulaGraph，然后将识别结果填充到实时消息。进入CDP数据只有经过Identity Service识别后才继续往后走，它决定了营销旅程的客户交互是否符合预期，也决定了RT-CDP的吞吐上限。
实时计算：该模块包含了所有数据处理、加工、分发等批流作业。目前抽象了基于Apache Beam的作业开发框架，尝试批流都在Flink上做，但有些运维Job还用了Spark，会逐渐去除。
统一画像：该模块主要是持久化海量的潜客画像，对于热数据存储在Kudu中，对于温、冷的时序数据定时转存到Parquet中。潜客画像包括客户属性、行为、标签、所属客群、以及聚合的客户扩展数据等。虽然标签、客群是单独存在的聚合根，但是在存储层面是一致的存储机制。另外，标准RT-CDP还应该管理客户碎片数据，所以统一画像和数据湖数据如何交互是后续建设的重点。
统一查询服务：在RT-CDP中，客户数据分散在图数据库、Kudu、增强的分析引擎和数据湖，但对用户来说只有属性、行为、标签、客群等业务对象，如何支持产品上透明使用？我们通过统一视图、跨源查询建设了此统一查询服务，该服务支持了Impala、Doris、MySQL、Presto、ES等查询存储引擎以及API的跨源访问。
实时规则引擎：该模块主要是基于Flink提供实时规则判断，来支持圈群、基于规则的静态打标、规则标签等业务场景。

3.数据输出

数据输出已经支持多种方式，包括OpenAPI、Webhook、消息订阅等。一方面，也方便企业获取CDP融合后的潜客的实时行为，然后与自有的下游业务系统进行用户全链管理。另一方面为上层的MA提供实时行为流驱动营销环路。这里特殊说明说明一下， MA的旅程节点中也需要很多实时规则判断，判断口径多样，有些在节点上做内存实现困难，所以RT-CDP也实现了可以为MA提供实时判断结果的数据输出。

4.3 关键实现

4.3.1 数据定义模型

为什么需要Schema？

前面提到企业的多个渠道的数据特征结构各异。再加上不同租户业务特点不同，企业需要数据自定义的扩展性。RT-CDP为了两类问题需要具备数据结构灵活定义的能力来对接企业数据。

另外，RT-CDP本身管理两类数据：碎片化客户数据和用户统一画像。对于前者来说，不需要关系数据内容本身，利用数据湖等技术即可为企业提供数据存储、查询、分析能力，是偏Schemaless的数据管理；对于后者来说，更多需要按不同维度组合查询、圈群、分析，本身需要结构化的数据管理。后者能否通过Schemaless的方式提供服务呢？罗列增删改查的场景，反证一下局限明显。

Schema是什么？

Schema是一个数据结构的描述，Schema可以相互引用，可以对数据中字段以及字段类型、值进行约束，也可以自定义字段。企业可以用一个统一的规范快速接入、灵活管理自己的数据，比如企业可以根据自己的行业特性，抽象不同的业务实体、属性，再给不同的业务实体定义不同的Schema。企业可以对业务实体有交集的信息抽离新Schema，然后多个Schema引用这个新Schema；也可以对每个Schema自定义自己的业务字段。企业只需要按相应的Schema结构接入数据，就可以按特定的标准使用这些数据。

从这几个实体来说明Schema的特点，如下图：

Field：字段是最基本的数据单，是组成Schema的最小粒度素。
Schema：是一组字段、Schema的集合，它本身可以包含多个字段（Field），字段可以自定义，比如字段名、类型、值列表等；也可以引用一个或多个其他Schema，引用时也可以以数组的形式承载，比如一个Schema里面可以包含多个Identity结构的数据。
Behavior：是潜客或企业的不同行为，本身也是通过Schema承载，不同的Behavior也可以自定义其特有的Field。

在上图所示，爱番番RT-CDP在进行行业抽象后，已经内置了很多行业通用的Schema，包括常见的Identity、Profile、Behavior等多类Schema。在爱番番RT-CDP管理的统一潜客画像中，Identity、Profile、Tag、Segment等都业务聚合根。为了支持好B、C两种数据模型还有一些B粒度聚合根存在。

Schema如何简化数据接入？

这里需要先说一个Dataset的概念。Dataset是通过Schema定义结构的一个数据集，企业对不同的数据源定义成不同的数据集。在数据源管理时，企业可以根据不同的数据集结构化导入的数据，一个数据集可以对应多个数据源，也可以对应一个数据源中的一类数据，一般后者使用较多。另外，一个数据集也可以包含多批次的数据，也就是企业可以周期性的按批次导入同一数据集数据。在数据接入时，如下图，针对不同的Dataset，企业可以绑定不同的Schema，每个Schema可以引用、复用其他子Schema，然后经过RT-CDP的Schema解析，自动将数据持久化到存储引擎，根据数据的定义不同，会持久化到不同数据表中。对应实时的客户行为也是通过定义不同的Schema来定义数据结构，然后进行持续的数据接入。

扩展1：借助字段映射解决多租户无限扩列问题

存在的问题是什么？

爱番番RT-CDP是一个支持多租户的平台，但在多租户下，每个企业都有自己的业务数据，一般中小企业可能有几百上千个潜客的数据字段，对于KA字段量更多。CDP作为Saas服务，如何在一个模型中支持如此多的字段存储、分析。一般可以无限扩列的引擎可以直接按租户+字段的方式打平。为了进行结构化实时存储，爱番番CDP选择了Kudu，Kudu官方建议单表不超过300列，最多也就支持上千列，那刚才的方式无法解决。

我们的解决方案是什么？

我们在租户隔离的前提下，采用字段复用的方式解决该问题。在介绍Schema模型时图里也有体现，在实际的Profile、Event表里都是attr字段。关键点就是：

事实表只做无业务含义的字段；
在数据接入、查询时通过业务字段（逻辑字段）和事实字段的映射关系进行数据转换后与前端、租户交互。

4.3.2 Identity Service

这个服务也可以称之为ID Mapping。但相对于传统的ID Mapping来说，因为业务场景的不同，功能侧重也有所不同。传统意义的ID Mapping更多是广告场景的匿名数据的，基于复杂模型的离线和预测识别；CDP中的ID Mapping是基于更精准的数据身份标识，进行更精准打通，更加要求打通率和实时性。

为此，我们设计了支持B2B2C、B2C两种业务的身份关系模型。在标准化租户数据接入后，基于不断接入的数据新增持续的身份关系图谱裂变。在功能层面，我们支持自定义身份类型以及身份权重，也支持针对不同身份租户自定义身份融合动作。另外，根据我们对行业分析，内置了常见的身份及融合策略，方便租户直接使用。

从架构层面，Identity Service（ID Mapping）基于云原生+NebulaGraph搭建，做到了租户数据隔离、实时读写、高性能读写以及水平扩缩容。

1.云原生+NebulaGraph

将NebulaGraph部署到K8s下，降低运维成本。我们主要是：

使用Nebula Operator自动化运维我们k8s下的NebulaGraph集群；
使用Statefulset管理NebulaGraph相关有状态的节点Pod；
每个节点都是使用本地SSD盘来保证图存储服务性能。

2.优化读写

Identity Service整体来说是一个读多写少的常见，但在新租户、拉新场景场景也都需要很高的写能力，读写性能需要兼顾。需要在做好并发锁的前提下优化读写：

设计好数据模型，尽量减少NebulaGraph内部IO次数；
合理利用NebulaGraph语法，避免Graphd多余内存操作；
查询上，尽量减少深度查询；更新上，控制好写粒度、降低无事务对业务的影响。

扩展1：如何解决未登录时潜客打通问题

针对一个人多设备场景，单设备被多人使用的场景，我们采用离线矫正的方式进行打通。

4.3.3 实时存算

4.3.3.1 流计算

爱番番RT-CDP核心能力都是依托Apache Flink+Kafka实现。在实时流之上进行的流计算，做到毫秒的数据延迟。

核心数据流如上图，简化后主要包含如下几部分：

主要采集和格式化的数据，会统一发到cdp-ingest的topic；
RT-CDP有个统一的入口Job（Entrance Job）负责数据的清洗、校验、Schema解析以及身份识别等，然后根据租户属性进行数据分发。因为这是RT-CDP入口Job，需要支持横向扩缩，所以这个作业是无状态Job。
经过数据分发，会有不同的Job群进行分别的数据处理、持久化，以及数据聚合等数据加工逻辑，一方面丰富潜客画像，另一方面为更多维度的潜客圈群提供数据基础。
最后会将打通的数据分发到下游，下游包括外部系统、数据分析、实时规则引擎、策略模型等多类业务模块，以便进行更多的实时驱动。

扩展1：数据路由

为什么要做路由？

爱番番RT-CDP作为基础数据平台，不仅服务于百度之外的租户，也服务于百度内部甚至爱番番自己；不仅服务于中小企业，也服务于中大企业。对于前者，服务稳定性要求级别不同，如何避免内外部之间服务能力不相互影响？对于后者，不同规模企业潜客量不同，使用RT-CDP圈人群等耗时的资源也不同，如何避免资源不公平分配？

我们怎么做的？

针对上述问题，我们通过数据路由的机制解决。我们维护了一张租户和数据流Topic的映射关系，可以根据租户特性进行分流，也可以根据租户需求动态调整。然后在Entrance Job根据租户的映射关系进行数据分流，分发到不同资源配比的Job群进行分别的数据处理。做到了内外部分离，也可以根据租户个性化需求进行资源控制。

扩展2：自定义Trigger批量写

在随机读写上，Kudu的表现相对于HBase等还是相对差一些。为了做到数十万TPS的写能力，我们对Kudu写也做了一定逻辑优化。主要是自定义了Trigger（数量+时间窗口两种触发），在做到毫秒级延迟的前提将单条写改为一次策略的批量。

具体方案：在在批量数据满足>N条、或者时间窗口>M毫秒时，再触发写操作。

一般租户的一次营销活动，会集中产生一大批潜客行为，这其中包括系统事件、用户实时行为等，这种批量写的方式，可以有效提高吞吐。

4.3.3.2 实时存储

在RT-CDP主要包括三部分的数据：碎片化的租户数据、统一的潜客画像和离线分析数据。我们主要分类两个集群进行数据存储，一个集群存储潜客统一画像和具有时序属性的热数据，另一个集群存储冷数据和用于离线计算的数据。每个集群都集成了数据湖的能力。然后我们研发了统一的Query Engine，支持跨源、跨集群的数据查询，对底层存储引擎透明。

扩展1：基于数据分层增强存储

为什么需要分层？

完全基于Kudu存储数据的话，一方面成本较高（Kudu集群都要基于SSD盘搭建才能有比较好的性能表现）；另一方面在营销场景下更关注短时间段（比如近一个月、三个月、半年等）客户的实时行为变化，对于时间较久的历史数据使用频次很低。

分层机制

综合考量，也从节约资源成本角度，我们选择Parquet作为扩展存储，针对存储符合时间序列的海量数据做冷热分层存储。

根据数据使用频率，我们将数据分为热、温、冷三层。热数据，表示租户经常使用的数据，时间范围为三个月内；温数据，表示使用频率较低的数据，一般只用于个别客群的圈选，时间范围为三个月外到一年；冷数据，租户基本不使用的数据，时间范围为一年之外。为了平衡性能，我们将热、温数据存放在同一个集群，将冷数据放在另外集群（和提供给策略模型的集群放在一个集群）。

具体方案：

在热、温、冷之上建立统一视图，上层根据视图进行数据查询。
然后每天定时进行热到温、温到冷的顺序性的分别离线迁移，在分别迁移后会分别进行视图的实时更新。

扩展2：基于潜客融合路径的映射关系管理解决数据迁移问题

为什么需要管理映射？

潜客画像行为数据很多，也可能存在频繁融合的情况，如果在潜客融合时，每次都迁移数据，一方面数据迁移成本很高，另一方面，当潜客行为涉及温冷数据时，是无法进行删除操作的。业内针对类似情况，更多会有所取舍，比如只迁移用户仅一段时间的热数据，再往前的历史不做处理。这种解决方案并不理想。

映射管理机制

为此，我们换了种思路，通过维护潜客融合路径的方式方式解决该问题。

具体方案：

新增一张潜客融合关系表（user_change_rela）维护映射关系；
在融合关系表和时序表（比如event）之上创建视图，做到对业务层透明。

针对融合关系表，我们做了一定的策略优化：不维护路径上的过程关系，而是只维护路径所有过程点到终点的直接关系。这样即便在潜客融合路径涉及过多潜客时，也不会过多增加关系查询的性能。

举个例子潜客发生两次融合（affId=1001先融合到1002上，再融合到1003上）时的user_change_rela的数据变化情况，如下图：

4.3.3.3 分析增强

我们选择百度开源的Apache Doris作为数据增强的分析引擎，为爱番番拓客版提供客户洞察能力，比如旅程分析、人群、营销效果分析、裂变分析、直播分析等。

为了方便后续OP部署时可灵活去除，我们将CDP输出的数据作为增强分析的数据源，然后基于Flink Job做逻辑处理，比如清洗、维度Join、数据打平等，最后采用Apache Doris贡献的flink-doris-connector将数据写入Doris。

使用connector方式直接写Doris有两个好处：

使用flink-doris-connector往Doris写数据，比使用Routine Load方式少一次Kafka。
使用flink-doris-connector比Routine Load方式在数据处理上，也能更加灵活。

Flink-doris-connector是基于Doris的Stream Load方式实现，通过FE redirect到BE进行数据导入处理。我们实际使用flink-doris-connector时，是按10s进行一次Flush、每批次最大可提交百万行数据的配置进行写操作。对于 DorisDB 来说，对单次导入大量数据比小批量 flush多次导入数据更友好。

如果想了解更多Doris在爱番番中的实践，可以阅读『百度爱番番数据分析体系的架构与实践』。

扩展1：RoutineLoad和Stream Load区别

Routine Load方式

它是提交一个常驻Doris的导入任务，通过不断的订阅并消费Kafka中的JSON格式消息，将数据写入到Doris中。

从实现角度来说，是FE负责管理导入Task，Task在BE上通过Stream Load方式进行数据导入。

Stream Load方式

它利用流数据计算框架Flink 消费Kafka的业务数据，使用Stream Load 方式，以HTTP协议向Doris写入。

从实现角度来说，这种方式是框架直接通过BE将数据同步写入Doris，写入成功后由Coordinator BE直接返回导入状态。另外，在导入时，同一批次数据最好使用相同的 label，这样同一批次数据的重复请求只会被接受一次，可以保证了At-Most-Once。

4.3.4 实时规则引擎

在爱番番私域产品中，灵活的圈群能力是一个重要产品能力，如何基于潜客属性、身份、客户行为等维度进行复杂、灵活规则的实时分群？此处的实时规则引擎就是为此而生。就此功能本身来说，并不新颖，在DMP中就有类似能力。很多CDP和客户管理平台都也有类似能力，但如何在多租户、海量数据情况下，做到实时、高吞吐的规则判断是一个挑战。

在爱番番RT-CDP中，一方面租户数量大，Saas服务前提如何支持多租户的高性能分群？另一方面，爱番番RT-CDP期望做到真正基于实时流的实时判断。因此，我们自研了基于多层数据的实时规则引擎。这里简单讲一下，后续会有单独文章介绍。

面临的问题是什么？

传统的实现方案主要是当租户实时或定时触发分群请求时，将规则翻译成一个复杂SQL，临时从租户的潜客数据池中进行SQL查询。另外，一般都会在潜客上做一层倒排索引，在租户少或者OP部署时，数据查询速度也尚可接受。但在基于实时流实现规则引擎需要解决如下几个问题：

海量数据实时判断
窗口粒度数据聚合的内存占用问题
滑动窗口下的窗口风暴
无窗口规则的数据聚合问题
潜客数据变更后的窗口数据更新
实时规则引擎实现

和很多产品类似，爱番番的规则圈群也主要是两层And/Or的规则组合。结合规则的特点，我们主要分为如下图的几类规则：普通的属性运算（P1、P2）、普通身份运算（I1）、小窗口的行为判断（E1）、大窗口的行为判断（E2）和无窗口的行为判断（E3）。

为了规则灵活度和高效的数据处理能力，我们定义了一套规则解析算法。然后借助Flink强大的分布式计算能力和状态管理能力驱动实时规则引擎计算。上面已经说了流数据理念，这里结合一条潜客行为进来到实时规则判断来更直观说明数据在流中的实时填充，如下图：数据进来之后，先经过Identity Service补充身份Ids，再经过数据Job补充潜客对应的属性信息，最后基于一个完整的潜客数据进行实时规则判断，最后将负责规则的潜客落入Segment表。

另外，规则引擎是一个独立于Segment等业务对象的服务，可以支持圈群、打标签、MA旅程节点等各个规则相关的业务场景。

4.3.5 扩展

4.3.5.1 弹性集群

爱番番RT-CDP的计算、存储集群基于百度云搭建，借助云上能力，很好实现了资源的存算分离和动态伸缩。我们可以自定义灵活的资源扩缩策略，根据消息量情况进行资源增减，做到波峰时实时加大集群规模提供计算能力，波谷时缩减集群做到及时降本。图片

我们的集群主要分为四类节点：Master、Core、Task、Client。具体如上图。

Master节点：集群管理节点，部署 NameNode、ResourceManager等进程，并且做到组件故障时的自动迁移；
Core节点：计算及数据存储节点，部署 DataNode、NodeManager等进程；
Task节点：计算节点，用来补充core节点的算力，部署 NodeManger等进程，该节点一般不用来存储数据，支持按需动态扩容和缩容操作；
Client节点：独立的集群管控节点及作业提交节点。

4.3.5.2 全链监控

RT-CDP在建设了完整的链路监控能力，能够实时发现集群、数据流问题，方便及时干预、处理，为租户提供更好的数据服务能力提供保证。也建设了全链的日志收集、分析能力，极大简化了服务问题排查成本。

具体如上图，我们依托爱番番强大的技术服务能力完成了跨平台的日志采集&报警和全链路的延时监控：

日志采集：基于爱番番贡献给Skywalking的Satellite收集全链路服务日志，支持了K8s下微服务的日志收集，也支持了Flink Job的日志采集，做到一个日志平台，汇集全链服务日志。然后通过Grafana进行日志查询、分析；
服务指标采集：我们通过PushGateway将各个微服务，Apache Flink、Impala、Kudu等算存集群指标统一采集到爱番番Prometheus，做到服务实时监控&报警。
全链路延时监控：我们也通过Skywalking Satellite采集RT-CDP全链路的数据埋点，然后通过自研的打点分析平台进行延时分析，做到全链路数据延时可视化和阈值报警。

五、平台成果

5.1 资产数据化

基于RT-CDP解决企业数据孤岛问题，帮助企业将数据资产数字化、多方化、智能化、安全化。

多方化：集成一方数据，打通二方数据，利用三方数据，通过多方数据打通，实现更精准、深度的客户洞察。
数字化：通过自定义属性、标签、模型属性等将客户信息全面数字化管理。
安全化：通过数据加密、隐私计算、多方计算实现数据安全和隐私保护，保护企业数据资产。
智能化：通过智能模型不断丰富客户画像，服务更多营销场景。

5.2 高效支撑业务

1.灵活的数据定义能力

RT-CDP在业务层面具备了灵活的数据定义能力，来满足企业的个性化需求：

丰富的自定义API，用于可以自定义Schema、属性、事件等不同场景的数据上报结构；
支持了身份类型自定义，方便企业根据自身数据特定指定潜客标识；
针对不同企业的不同结构的数据可以做到零开发成本接入。

2.服务于不同行业企业的多样营销

依托RT-CDP强大数据管理能力，爱番番营销产品已服务于法律、商务服务、教育培训、电子电工、机械设备、金融、健康美容、生活服务、房产家居、建筑建材、印刷包装、农林牧渔、物流运输、餐饮食品等数十个行业的数千家企业，帮助企业解决了很多营销难题。成功的企业案例不胜枚举。

5.3 架构先进

目前我们完成RT-CDP1.0的建设，并且在一些核心指标上都取得了不错的效果：

5.3.1 实时高吞吐

Identity Service做到数十万QPS的关系查询，支持上万TPS的身份裂变。
实时计算做到了数十万TPS的实时处理、实时持久化，做到毫秒级延迟。
支持企业海量数据、高并发下毫秒级实时分析。
真正基于实时流数据实现规则判断，支撑了私域打标、实时规则判断、圈群等多个实时业务场景，让营销毫秒触达。

5.3.2 高扩展性

平台架构存算分离，可水平扩展：

基于云原生+NebulaGraph搭建了，可动态伸缩的图存储集群；
借助百度云原生CCE、BMR等云上能力，搭建了存算分离的弹性伸缩的存算集群；
计算集群动态伸缩，节约企业资源成本。

5.3.3 高稳定性

各个模块、各个集群稳定性指标长期维持在99.99%以上。

六、未来展望

1.【业务层面】更多贴近行业的中台能力

平台目前在业务支撑上已经具备了比较好的定义能力。下一步将结合重点服务的企业行业，内置更多行业业务对象，进一步简化企业数据接入成本。

在B2B2C数据模型上做更多业务尝试，更好服务ToB企业。

2.【业务层面】更丰富的AI模型

RT-CDP已经为企业提供了智能化的潜客评分能力，支持企业灵活定义评分规则。在AI时代，我们将继续丰富更多的AI模型来帮助企业管理、洞察、营销客户。

3.【架构层面】更智能化的治理、运维

目前Flink作业还是基于Yarn管理资源、基于API、脚本方式流程化操作（比如涉及到CK的操作）作业监控通过如流、短信、电话报警。后续我们将作业管理、运维上做更多尝试，比如基于K8s管理Flink作业、结合如流的Webhook能力完善作业运维能力等。

在流数据驱动下，数据处理机制的变化让数据治理、数据检查变得更有挑战。为了提供更可靠的数据服务，还有很多工作要做。

4.【架构层面】湖仓一体到智能湖仓

国内互联网公司已经有不少数据湖技术实践案例，确实可以解决一些原有数仓架构的痛点，比如数据不支持更新操作，无法做到准实时的数据查询。我们目前也在做Flink 和 Iceberg/Hudi 集成的一些尝试，后续会逐步落地。

七、作者

Jimmy：带着团队为爱番番奔走的资深工程师。

谢谢你读完本文 (///▽///)

火了一周的 ChatGPT，HG 不允许还有小伙伴不知道这个东西是什么？简单来说就是，你可以让它扮演任何事物，据说已经有人用它开始了颜色文学创作。因为它太火了，所以，本周特推在几十个带有“chatgpt”的项目中选取了两个有代表性的项目，希望你能玩好这个新玩具。

除了很火的 ChatGPT，本周还有搞 Python 编译速度贼快的 codon，搞监控很潮的 uptime-kuma，井井有条管理微服务的 conductor，简化你操作、低资源消耗生成文本图片的 InvokeAI，以及专注中间人攻击的 bettercap。

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

本文目录
- 1. 本周特推
  - 1.1 最佳实践：awesome-chatgpt-prompts
  - 1.2 ChatGPT + 微信：wechat-chatgpt
- 2. GitHub Trending 周榜
  - 2.1 Python 编译器：codon
  - 2.2 酷监控：uptime-kuma
  - 2.3 微服务编排：conductor
  - 2.4 简化图片生成：InvokeAI
  - 2.5 中间人攻击：bettercap
- 3. 往期回顾

1. 本周特推

上上周五发布的 ChatGPT 果然在本周火了一把，各种文章层出不穷，HG 也发了一篇它是否会开源的文章《ChatGPT 会开源吗？》。一周过去了，它的热度不减，几乎屠版了 GitHub 各大编程榜。这不，本周特推就分享两个它相关的项目。

1.1 最佳实践：awesome-chatgpt-prompts

如何让 ChatGTP 乖乖地按照你的指示来行事，大概你需要知道“前辈”们是如何训练它的。awesome-chatgpt-prompts 收录大量 ChatGPT 指示，比如：扮演 Linux 终端、英文翻译、面试官。掌握了这些角色扮演触发方式，相信你和 ChatGPT 有更多的有趣故事发生。

GitHub 地址→https://github.com/f/awesome-chatgpt-prompts

1.2 ChatGPT + 微信：wechat-chatgpt

主语言：TypeScript

在应用中掌握某种技术，是常见的学习方法。现在轮到 ChatGPT 了，在微信上迅速接入 ChatGPT，让它成为你最好的助手试试。这个项目实现的如下功能：

通过 wechaty，将 ChatGPT 接入微信
创建 OpenAI 的账户池
支持通过代理登陆 OpenAI
加入了持续对话的功能（每一个微信用户都保持自己的对话上下文）
加入 Dockerfile
发布到 Docker.hub
通过 Railway 进行部署
实现 OpenAI 账户池的热加载
当 OpenAI 返回码为 429/503 时自动重试

GitHub 地址→https://github.com/fuergaosi233/wechat-chatgpt

2. GitHub Trending 周榜

2.1 Python 编译器：codon

本周 star 增长数：1,800+，主语言：C++、Python

一个用 LLVM 实现的高性能、零开销、可扩展的 Python 编译器，无需任何 runtime 开销它就能将 Python 代码编译为原生机器码。此外，单线程的话 Python 的速率将能提升 10-100 倍，或者更多；而它的编译性能可以和 C/C++ 近似。与 Python 不同的是，Codon 支持原生多线程，这可以使编译速度更快。

Codon 是与 Python 兼容的，任何 Python 代码几乎可以不做修改便可以在 Codon 运行，像是下面这样：

GitHub 地址→https://github.com/exaloop/codon

2.2 酷监控：uptime-kuma

本周 star 增长数：950+，主语言：JavaScript

一个神奇的监控工具，有着好看的 UI 界面。不只是颜值，它还有：

监视 HTTP(s)、Ping、DNS Record、Docker 容器等服务的正常运行时；
响应式、灵敏的 UI/UX；
集成多种通知方式，比如：Telegram、Discord、Slack、Email 等等 90+ 通知服务；
支持多语言、多种状态界面；
2FA 可用；

GitHub 地址→https://github.com/louislam/uptime-kuma

2.3 微服务编排：conductor

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

Netflix 开源的微服务编排工具，用来协调微服务的工作流，项目采用了 Java 编写，需要 JDK 11 以上版本，UI 部分需要 Node.js 14 以上。

GitHub 地址→https://github.com/Netflix/conductor

2.4 简化图片生成：InvokeAI

本周 star 增长数：1,300+，主语言：Jupyter Notebook

大名鼎鼎的 DALL-E 和 ChatGPT 是师出同门，DALL-E 是文本生成图片领域的知名项目，InvokeAI 也是。不过，相较于其他项目，InvokeAI 更加轻量，它简化了图片生成的过程，通过各类选项帮助生成对应图片。此外，它能运行在 Windows、macOS、Linux 等主流操作系统，只要你有个 GPU 以及 4GB 的内存，就能用。比如，下图便是一个“草莓寿司”文本生成的图片。

GitHub 地址→https://github.com/invoke-ai/InvokeAI

2.5 中间人攻击：bettercap

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

网络安全从业人员的瑞士军刀，一个适用 802.11、BLE、IPv4 和 IPv6 的中间人攻击框架，可主动/被动探测 IP 网络情况。部分特性：

Wi-Fi 扫描，绕开验证攻击、无客户端 PMKID 关联攻击、自动的 WPA / WPA2 客户端握手捕获；
数据包、TCP、HTTP / HTTPS 级别的代理脚本，可方便集成 JS 插件；
强大的网络嗅探器，可获取凭证，也可以作为网络协议 fuzzer；
端口快扫；
有个强大的 REST API 支持 WebSocket 上的异步事件通知，从而轻松协调攻击；
便捷的 Web UI；

GitHub 地址→https://github.com/bettercap/bettercap

3. 往期回顾

往期回顾：

GitHub 开源了多款字体「GitHub 热点速览 v.22.48」
快速绘制流程图「GitHub 热点速览 v.22.47」

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

关注公众号

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

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

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

NPU 转换部署 YOLO V5 模型

本文以 YOLO v5s 模型为例，详述 ONNX 模型在 V853 平台的转换与部署的流程。

模型的准备

YOLO v5 目前开源于 Github，链接【GitHub – ultralytics/yolov5: YOLOv5 🚀 in PyTorch > ONNX > CoreML > TFLite】

我们可以在 Release 页面找到预先训练好的各式各样的开源 YOLO V5 模型

我们选择 v6.0 版本的 yolov5s.onnx 模型作为示例，下载下来。

可以用开源的 Netron 工具打开模型查看模型的结构

模型预处理

由于下载的模型是动态 Shape 的，不限制输入图片的大小，对于 NPU 来说会增加处理工序，所以这里我们需要转换为静态 Shape 的模型。可以先安装工具，然后使用这条命令转换：

这里我们将输入固定为了，减少了 NPU 的预处理量。转换后的模型可以用 Netron 查看变化

可以看到，输入已经被固定了。

检查预处理情况

转换后的模型不一定可以用，需要验证一下。这里就使用 YOLOv5 源码提供的测试转换后的 onnx 模型

可以看到输出结果还是非常精确的，模型确认没有问题。

检查输出节点

我们使用 Netron 打开模型

可看到模型有 4 个输出节点，其中 ouput 节点为后处理解析后的节点；在实际测试的过程中，发现 NPU 量化操作后对后处理的运算非常不友好，输出数据偏差较大，所以我们可以将后处理部分放在 CPU 运行；因此保留，，三个后处理解析前的输出节点即可，后文会说明如何修改输出节点。

模型的转换

导入模型

我们先准备下需要的文件，与前文 YOLO v3 的类似，dataset 文件夹存放量化所需要的图片，从训练数据集里拿就ok，一个定义图片位置。还有我们的模型。

运行下列命令导入模型，指定输出的节点。

导入生成两个文件，分别是是和文件，他们是 YOLO V5 网络对应的芯原内部格式表示文件，文件储存权重，文件储存模型。

生成 YML 文件

与上文一样，生成 YML 配置文件

同样的，修改文件中的的参数为，目的是对输入进行归一化，和网络进行训练的时候是对应的。

量化

生成量化表文件，使用非对称量化，uint8，修改参数为你的里提供的图片数量。

预推理

利用前文的量化表执行预推理，得到推理

输出了三个，把他拷贝出来，之后上传到开发板部署验证。

验证预推理

可在开发板上将输出 tensor 结合 Python 或 C++ 后处理代码解析出算法输出结果，也可以在 PC 上导入上一步预推理输出的来验证仿真推理输出是否正确。这里就采用在 Linux PC 端结合 C++ 编写的后处理代码验证仿真的推理输出。

后处理代码如下，使用 C++ 与 OpenCV 编写。这套后处理代码也可以部署到开发板使用。包括了输出的分析，图像的处理，打框打标等操作：

编译运行后结果输出如下：

可以看到，量化后精度有所损失，不过大体上没什么问题。

导出模板代码与模型

输出的模型可以在文件夹中找到。

开发板部署测试

测试部署可以参照【NPU Demo 使用说明 – V853】中提供的的方法集成输出的模板代码到 Tina Linux 里，来生成文件。

运行结果如下，准确率还是比较高的。

开发板输出打框后图像如下

原贴链接：https://v853.docs.aw-ol.com/npu/npu_yolov5/

关注全志在线微信公众号，获取更多技术资源

在本次 HDC 大会期间，华为发布了全新的七大鸿蒙开发工具，HarmonyOS 系统迎来了全新升级。

为了解决目前移动应用开发生态普遍存在的入门门槛高、技术交流渠道窄和应用多端适配工作繁琐的问题，华为开发者联盟也推出了一系列举措赋能开发者，力争为独立开发者带来全方位、一站式的助力提升。

那么现在就请跟随笔者的脚步，一起来探索、分析华为开发者联盟的一系列举措，究竟能够为当下开发者的技术生涯带来哪些方面的提升和改变。

当下开发者的困境

尽管我国有着全球领先的移动互联网市场体系，但是不可否认，支撑这套商业体系的底层技术生态圈却长期处于空中楼阁的状态。

除了受限于时代发展的原因，我国编程技术生态的资源和内容短缺，也对这一现状有着重要的影响。

首先，虽然如今中文互联网上的编程课程多如牛毛，但是实际真正能够起到培养软件工程师作用的课程寥寥无几。

不仅因为视频制作者水平参差不齐，导致编程课程的质量难以保证，因此误导了一大批初学编程的小白。

而且课程的时效性往往也得不到保证，毕竟编程技术的迭代突飞猛进，每一代语法可能都会出现极大的变化。

其次，众所周知如今移动互联网市场已经从蓝海变成了红海，市场竞争程度空前激烈，单打独斗的独立开发者，战胜体系化的竞争对手也已经变得越来越不可能。

毕竟即便是在几年前，独立开发者想要一个人兼顾应用的开发、分发和运营三方面工作，也是基本不可能的事情。

然而不知为何，这样的现状却一直遭到头部生态平台方的忽视，因此在如此艰难的境遇之下，越来越多的独立开发者选择了放弃。

想要在独立开发领域有所作为的新手小白，也望而却步，让我国的移动互联网生态逐渐出现了开发人员断层。

鸿蒙赋能体系，一站式服务中心

结合目前国内开发者遭遇的困境来看，华为想要从无到有地打造出一个成熟的移动应用生态，其难度之高是不言而喻的。

但是华为开发者联盟却并没有就此选择放弃，而是义无反顾地为开发者提供了支持力度高到前所未有的一系列重磅举措，携手开发者共建鸿蒙生态。

基于开发者对提升自身技术水平、得到权威技术认证证书的实际需求，华为开发者联盟推出了一站式生态赋能中心，使得开发者能够获得由华为官方提供的学习、认证、开发实践的全流程服务。

依照该理念推出的华为开发者联盟学堂，面向全体开发者提供最新、最全且最权威的鸿蒙技术开发课程，让开发者不必再因为网上教程参差不齐而白白耗费心力。

比如根据官方透露，HarmonyOS 3.1 版本的最新课程（包括鸿蒙 eTS 语言介绍、如何给用户更好的跨设备体验等等）将会在 11 月份依次上线，而且配套的 Codelabs 等资源也会同步上线，全面满足开发者的学习诉求。

最重要的是开发者完成了对应内容的学习后，能够得到由华为官方提供的 HarmonyOS 应用开发者能力认证证书，为开发者日后的鸿蒙技术生涯打好基础，让所有的付出都能有所回响！

不仅于此，开发者还可以在华为开发者联盟学堂中，借助向导式学习路径由浅入深地了解鸿蒙技术体系，不再因为自学而缺失体系化的技术积累，让技术学习也可以做到事半功倍，大幅提升学习效率。

在开发者成功掌握鸿蒙应用开发技术后，华为开发者联盟准备的全方位服务支持也将随之给予开发者。

对于独立开发者普遍觉得困难的应用开发、分发和运营三方面工作，华为开发者联盟都能够给开发者提供帮助和支持。

在开发环节，HUAWEI AppGallery Connect Serverless 和 HarmonyOS DevEco Studio 等 IDE 开发工具深度集成。

开发者在 DevEco Studio 中，可同时进行 HarmonyOS 应用/原子化服务和云侧服务的开发。

云开发采用 TS 作为开发语言，前端开发人员轻松化身全栈工程师。一套IDE就能轻松搞定端云代码的端到端调试，效率加倍！

此外，HUAWEI AppGallery Connect 全新升级，成为覆盖包含鸿蒙应用、原子化服务、快应用等各类移动应用的全生命周期服务平台，开发者可以在平台使用包含 HarmonyOS 应用和原子化服务的分发、运营、分析、增长等全流程服务。

另外，华为开发者联盟还提供耀星激励计划和生态市场等生态扶持平台，持续面向全球激励开发者创新，希望越来越多的开发者可以加入加入鸿蒙生态，为用户提供更优质的全场景智慧化生活体验。

因此毫不夸张地说，在华为开发者联盟的支持之下，所有的鸿蒙开发者都能够在当下这个时代，依然拥有单打独斗也可以实现生态商业闭环的可能。

面向未来的鸿蒙人才生态建设体系

为了能够让鸿蒙生态有源源不断的新鲜血液涌入，华为开发者联盟也推出了鸿蒙开发者大赛，希望不同赛道的开发者使鸿蒙生态能够汇聚全球的创新力量，成为计算机生态中的常青藤。

在中国、欧洲、亚太、拉美和中东非分别设有赛区的全球应用创新赛道，总奖金高达 100 万美，获奖应用能够得到全球推广的机会。

全球校园 AI 算法精英赛道汇聚了全球算法精英和 AI 领域权威专家，总奖金也高达 21 万美，让仍处于校园的精英学子能够拥有和前沿专家进行思维碰撞的机会。

累计已经有 4000 多支参赛队伍的 HarmonyOS 开发者创新赛道，更是通过百万奖金激励开发者智慧创新，已经打造出超过 500 款优秀作品，让世界看到了 HarmonyOS 开发者的创新力量。

除此之外，华为开发者联盟在产学合作领域也始终走在行业前沿。

今年 6 月，以 Severless 技术为主题的百校公开课在全国 20 多个城市站、院校分会场同步举行，让高校学生亲自感受 Severless 端云一体化的技术魅力，为培养我国未来云计算领域的高水平研究员做出了不容忽视的贡献。

HUAWEI Student Developers（HSD）则致力于帮助高校开发者探索最前沿的技术，与校园极客一起打造出最具创新性的项目。

为了更加深入全面地理解 Serverless 技术，华为还将与高校合作产学研究项目，进一步提高选课学生的学习与实践能力，以重点培养我国未来云计算领域的高水平研究者、设计者和制造者，同时也期待未来可以与更多的高校学子一起构建鸿蒙人才生态。

据了解，本次HDC华为开发者联盟就邀请了多个城市站和高校站一起观看直播进行联动。

所以不仅是在吸引外部开发者加入鸿蒙生态，或者是帮助高校学生提前参与到鸿蒙生态的建设工作，华为开发者联盟都是其中不可缺少的主要组织者，它所做出的这些努力和投入，未来也必然会对鸿蒙生态的发展起到极其重要的推动作用。

结语

回望计算机几十年的发展历程，任何一个新的生态系统的建立都是极其艰难、坎坷的，即使是有着华为光环加持的鸿蒙生态系统依旧如此。

但是相较于此前并不重视开发者个人成长、生态基础设施建设的系统生态，鸿蒙生态在这些方面有着显著的优势。

而这都得益于华为开发者联盟全心全意的投入，使得初入鸿蒙生态的开发者能够不走弯路、事半功倍地在短时间内提升自身的技术水平。

一系列的鸿蒙技术赛道，吸引了一批又一批的开发者参与到鸿蒙生态的建设当中；高校学生也因此可以在校园内就深入了解到鸿蒙的技术体系，为日后加入到鸿蒙生态的建设打好基础。

因此不管你是否有兴趣成为一名开发者，笔者都由衷地邀请你前往华为开发者联盟的官方网站，获取鸿蒙生态的第一手资料，了解鸿蒙生态的发展路线，说不定你也能有机会成为鸿蒙生态的一份子。

本文为华为开发者联盟x科技狐合作文章

作者：董子龙

前言

前段时间一直想参照lombok的实现原理写一篇可以生成业务单据修改记录插件的专利，再查阅资料的过程中，偶然了解到了字节码增强工具-byteBuddy。但是由于当时时间紧促，所以没有深入的对该组件进行了解。其实再我们的日常开发中，字节码增强组件的身影无处不在，例如spring-aop和mybatis。本着知其然也要知其所以然的精神，我决定沉下心来，对字节码增强技术做一个深入的学习和总结，本文作为该系列的开篇，主要是对字节码做一下简单的介绍，为我们后面的深入学习打下一个好的基础。

一、字节码简述

字节码是一种中间状态的二进制文件，是由源码编译过来的，可读性没有源码的高。cpu并不能直接读取字节码，在java中，字节码需要经过JVM转译成机械码之后，cpu才能读取并运行。

使用字节码的好处：一处编译，到处运行。java就是典型的使用字节码作为中间语言，在一个地方编译了源码，拿着.class文件就可以在各种计算机运行。

二、字节码增强的使用场景

如果我们不想修改源码，但是又想加入新功能，让程序按照我们的预期去运行，可以通过编译过程和加载过程中去做相应的操作，简单来讲就是：将生成的.class文件修改或者替换称为我们需要的目标.class文件。

由于字节码增强可以在完全不侵入业务代码的情况下植入代码逻辑，所以可以用它来做一些酷酷的事，比如下面的几种常见场景：

1、动态代理

2、热部署

3、调用链跟踪埋点

4、动态插入log(性能监控)

5、测试代码覆盖率跟踪

…

三、字节码增强的实现方式

字节码工具
类创建
实现接口
方法调用
类扩展
父类方法调用
优点
缺点
常见使用
学习成本
java-proxy
支持
支持
支持
不支持
不支持
简单动态代理首选
功能有限，不支持扩展
spring-aop,MyBatis
1星
asm
支持
支持
支持
支持
支持
任意字节码插入，几乎不受限制
学习难度大，编写代码多
cglib
5星
javaassit
支持
支持
支持
支持
支持
java原始语法，字符串形式插入，写入直观
不支持jdk1.5以上的语法，如泛型，增强for
Fastjson,MyBatis
2星
cglib
支持
支持
支持
支持
支持
与bytebuddy看起来差不多
正在被bytebuddy淘汰
EasyMock，jackson-databind
3星
bytebuddy
支持
支持
支持
支持
支持
支持任意维度的拦截，可以获取原始类、方法，以及代理类和全部参数
不太直观，学习理解有些成本，API非常多
SkyWalking，Mockito，Hibernate，powermock
3星

四、简单示例

AOP是我们在日常开发中常用的架构设计思想，AOP的主要的实现有cglib，Aspectj，Javassist，java proxy等。接下来，我们就以我们日常开发中会遇到的在方法执行前后打印日志为切入点，手动用字节码来实现一下AOP。

定义目标接口与实现

定义了类SayService，再执行say方法之前，我们会打印方法开始执行start,方法执行之后，我们会打印方法执行结束end

ASM实现AOP

4.1.1、引入jar包

4.1.2、AOP具体实现

4.1.3、测试类输出结果

Javassist实现AOP

4.2.1、引入jar包

4.2.2、AOP具体实现

4.2.3、测试类输出结果

五、总结

作为字节码增强系列文章的开篇，只是简单的介绍了一下字节码的定义、字节码的实现方式，最后通过具体示例向大家展示了如何对字节码进行增强。再后续的文章中，会对相关框架的原理及具体应用做一个细化的总结，欢迎各位大佬的批评与指正。

作者：胡骏

一、背景现状

软件开发从传统的瀑布流方式到敏捷开发，将软件交付过程中开发和测试形成快速的迭代交付，但在软件交付客户之前或者使用过程中，还包括集成、部署、运维等环节需要进一步优化交付效率。因此Devops的产生将敏捷的相关理念扩展到运维侧，从而将产品、设计、开发、测试、运维团队更紧密的结合在一起。而从交付给客户产品视角看，前端研发通常又是在整个产品设计开发链条的最终节点，意味着前端团队受到上游变更的影响是最大的，并且从经营理念效率出发，提升前端交付效率是至关重要的。那么如何提升交付效率呢，主要面临以下问题：

交付效率：

1.敏态需求增加，即迭代性工作增加：软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求。近些年项目的迭代性需求不断递增，这就要求前端开发者能够具备从开发到测试并且快速发布上线的能力，也需要团队完成由稳态到敏态的转变。

2.前端研发效能瓶颈，达成双周交付面临挑战：敏捷迭代过程中，研发周期缩减并行需求增加，研发团队难以做到开发到测试和上线的过程中，全方位保证代码的高质量输出。

3.研发过程中不必要的浪费降低交付效率：重复劳动、过度沟通、环节等待、通知不及时等。

质量&体验：

1.质量安全把控不到位：研发团队大多关注代码和架构，对于项目如何能在生产环境稳定运行，需要考虑哪些安全性和可持续性的因素并不是很了解。

2.研发流程标准不同，协同开发容易出错：开发者的编码风格不同，提测上线的流程不一致，关键流程环节的疏漏，风险行为难以约束，导致上线事故率增加。

3.不同种类的应用服务的部署方式不一致：涉及到一些应用系统的调整、部署、扩展等，需要从新熟悉应用部署和构建环境的使用，使团队对发布没有信心。新的服务或者应用的构建，很难快速上线，被卡在了生产环境部署阶段。

二、问题分析

下图是我们团队之前的开发流程，黄色为关键流程，绿色为必备环节。

我们对各个流程环节逐一分析：

行云评审

评审中存在过度沟通，需求规范不统一，排期定不下来

需求确认

缺少与上级沟通，私自承接确认需求

关联分支

缺乏行为约束，主干开发易造成代码污染，无法约束开发者按照需求进行分支开发

代码开发

缺乏标准，开发架构不同，编码风格不统一，打包部署命令不一致，多人协作困难

代码评审

缺乏流程卡点，开发者经常跳过代码评审环节，代码问题难以暴露，线上风险增加

代码检测

缺乏流程卡点，易忽略检测流程，切换多个平台进行代码检测造成时间浪费

提交测试

缺乏沟通，通知测试人员不及时，提测内容不健全，行云卡片忘记变更到测试阶段

提交代码

缺乏质量卡点，缺乏行为约束，人工操作代码提交，易造成不确定问题增加发布风险

项目上线

缺乏风险检测，易忽略上线前的回归测试和性能优化，存在审批发布等待时间的浪费

通过对这些问题和各个团队的反馈深入分析，发现其中最大的瓶颈在于研发协作之间的沟通壁垒、流程环节的疏漏和质量把控的不到位，而这些又是解决大多数问题的前提。

经过调研，我们发现DevOps恰恰是为这些问题而生，打造高效的交付流程成为我们破局的关键。

三、DevOps流水线引入

1）DevOps流水线简介：

DevOps流水线聚焦于将项目的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化来实现敏捷开发、持续交付和应用运营的无缝集成。

2）DevOps流水线与前端开发

定位：将前端业务中多且复杂的构建流程进行整合，使其成为一条可以覆盖前端多业务场景的流水线，为前端开发者提供服务。

使命：减少前端开发者在复杂构建流程中所消耗的时间和精力，整体提高前端开发者的工作效率。

四、DevOps流水线设计

1）架构设计

行云流水线采用了平台化管理+原子化设计+自定义开发模式，平台提供基础服务，能力可以通过原子化形式和自定义开发模式无限扩展，即兼顾了平台的稳定性，又大大减低了现有工具平台的接入成本。既有工具平台可独立对用户提供服务，也可以通过标准化方式输出插件化原子能力，作为持续交付平台的一环，纳入软件交付流程中，实现互利共赢，完美对接，减少重复建设，共建平台。

行云流水线提供了良好的环境基础和丰富的原子准备，让我们在构建自动化流水线时更加的方便快捷，也大大提升了我们的开发时间。我们团队的前端DevOps流水线即是基于行云流水线搭建。

2）流程设计

下图是我们为团队设计的前端DevOps自动化流水线，目的是打破开发、测试、产品、运营等不同岗位人员的沟通壁垒，让研发团队人员同时具备不同研发环节的能力，从而实现项目研发全流程的无缝集成。

我们来看看给前端DevOps流水线赋予了哪些能力：

1.项目流程管理的全局视角：我们将整个项目研发周期拆解为：需求阶段、开发阶段、测试阶段、预上线和发布上线。每个阶段以流程节点串联的方式自动化运行，同时以行云卡片作为媒介显示当前所处的流程阶段。

2.精细化的代码质量和风险管控：通过实现代码和需求的关联，我们设计了更细粒度的质量卡点和风险管控策略。在关键节点约束研发操作行为，设置流程卡点并制定不同的质量检测机制，以便在早期的质量预防、中期的风险发现和后期的问题复盘都可以很大程度上减少成本投入。

3.自动化的流程触发和行云卡片流转：通过约定式代码提交，自动触发测试流程和上线流程，解放研发在流程流转中的额外操作和关注耗时。同时，行云卡片会伴随着项目阶段的变更自动流转，用于更精准的统计不同阶段的投入成本。并且，高度的自动化流程也为项目带来更高的品质和稳定性。

4.即时的消息触达和流程提醒：关键流程节点达成，会通过咚咚和邮件的方式即时同步给相关人员，进一步降低项目研发过程中的沟通成本，消息信息也可作为备忘代办和存档记录，时刻关注流程中的关键节点。

五、实践过程

整体的实践过程分为：

1.需求阶段：制定工作流->需求创建->评审约束->关联代码分支。

2.开发阶段：vscode可视化搭建（模板、调试、提测、预上线）。

3.测试阶段：代码比对->编译打包->图片压缩->发布测试->性能检测->咚咚邮件通知。

4.上线阶段：代码评审->代码合并->代码比对->编译打包->走查检测->图片压缩->JDOS部署->性能检测->咚咚邮件通知->回归测试->发布上线->行云验收。

1）需求阶段

行云团队空间设置里，我们将工作流设置为阶段串联且不可跳过阶段和回撤，这样的好处是便于我们约束研发流程的各个阶段逐一流转，并有效地计算各阶段的投入成本。

为了防止员工私自承接确认需求，我们规范了评审流程，设置了评审约束。需求来源为业务和产品的需求必须经过项目管理者，在需求评审阶段评审通过后才能进入到后续的开发阶段，并可记录详细的评审信息。

为了达到精细化的代码质量和风险管控，我们规定需求须和代码分支做关联，因此在工作流的开发阶段前置校验中设置了“检测关联代码分支”的流程卡点。

工作流转到开发阶段，未关联代码分支会进行弹窗提示去关联代码分支，不关联将无法进入开发阶段。

关联代码分支后，项目正式进入到开发阶段。

2）开发阶段

我们开发了一套VSCode代码编辑器的插件，集成了模板，调试，提测，预发布等功能。让前端开发者更关注代码实现而简化项目初始化和项目进程流转。

我们可以通过此插件直接触发提测流水线和预发布流水线，也可以通过流水线的Coding代码约定式提交触发相应的流程。如上图所示，提交关键词“发布提测”触发提测流水线，进入到测试阶段。

3）测试阶段

触发提测流水线后，流水线中的功能（代码差异比对、编译打包、图片压缩、上传测试页面、性能检测等）会自动执行，执行成功后会给相关人员发送咚咚提醒和邮件通知。

咚咚提醒：

邮件通知：

4）上线阶段

当测试通过需要上线时，我们制定了一个预上线的流程，目的是作为上线前的最后一次回归测试和质量风险管控。

4.1 触发预上线流水线

与提测流程一样，我们可以在VSCode预发布按钮触发预上线流水线，也可以通过Coding提交关键词“发布预上线”来触发。

4.2 分支代码合并

触发预上线流水线后，会自动执行分支代码合并主干的操作。因为之后的上线是主干上线，所以分支合并主干的操作具有关键必要性。

注意：未经过评审通过，分支合并将会失败，咚咚邮件会提示进行代码评审。

4.3 代码评审

为进一步提高代码质量，降低潜在风险，我们在Coding平台制定了评审策略，只有代码评审通过才可以进行合并主干的操作，如下图所配置。

当分支代码没有进行评审时，评审人员会收到代码评审的咚咚和邮件通知，以此提高代码质量的管控，进一步降低沟通成本。

评审人员收到的咚咚通知：

评审人员收到的邮件通知：

代码评审信息：

4.4 评审通过自动合并主干

采用Coding系统的自动合并主干策略，规避人工合并带来的不确定性风险错误，如下图所示。

4.5 自动触发预上线部署流水线

为避免评审过程中的等待时间浪费，当评审通过分支合并成功后，自动触发预上线部署的流水线。此自动化触发机制来源于流水线的触发设置，如下图所示。

4.6 自动执行预上线部署流程

预上线部署流程分为两个阶段串联：

阶段一：

阶段二：

阶段一进行编译打包后，我们设置了一个代码自测（CheckList）的流程卡点，目的是提醒前端开发者最后检查一些风险事项，并确认提交，如下图所示。

全部勾选确认后，自动执行预上线部署流程的阶段二，并推送咚咚通知。

4.7 JDOS部署和性能安全检测

预上线部署流水线已经打通了JDOS的构建部署功能，并加入了Scan性能检测和烛龙安全扫描，为预上线的页面进行全方位的质量风险把控。

4.8 回归测试并发布上线

预上线部署流程完成后，项目相关人员会收到咚咚邮件通知。

现在，项目人员可以打开预发机器提供的链接，进行全回归测试。测试无误后，前往JDOS平台“上线申请”即可发布上线。

4.9 上线完成发起验收

至此，整个项目研发流程结束并发起行云卡片验收。

作者：汪诚愚、段忠杰、朱祥茹、黄俊

导读

近年来，随着海量多模态数据在互联网的爆炸性增长和训练深度学习大模型的算力大幅提升，AI生成内容（AI Generated Content，AIGC）的应用呈现出爆发性增长趋势。其中，文图生成（Text-to-image Generation）任务是最流行的AIGC任务之一，旨在生成与给定文本对应的图像。典型的文图模型例如OpenAI开发的DALL-E和DALL-E2、Google提出的Parti和Imagen、基于扩散模型的Stable Diffusion和Stable Diffusion2.0等。

然而，上述模型一般不能用于处理中文的文图生成需求，而且上述模型的参数量庞大，很难被开源社区的广大用户直接使用。在先前文图生成模型（看这里）工作积累之上，阿里云机器学习（PAI）团队进一步开源了PAI-Diffusion系列模型，包括一系列通用场景和特定场景的文图生成模型，例如古诗配图、二次动漫、魔幻现实等。这些模型的Pipeline除了包括标准的Latent Diffusion Model，还集成了PAI团队先前提出了中文CLIP跨模态对齐模型（看这里），及图像超分模型，使得模型可以生成符合中文文本描述的、各种场景下的高清大图。

本⽂简要介绍PAI-Diffusion模型及其体验方式。

Diffusion技术概述

我们的模型是基于一个基于隐式扩散模型（Latent Diffusion Model, LDM）的文图生成模型。接下来，我们简要地介绍LDM的原理以及技术改进。

Latent Diffusion Model原理

扩散模型有两个过程，分别为扩散过程和逆扩散过程。如下图，扩散过程为从左到右的过程（( Data→Noise) ），表示对图片逐步增加噪声。逆扩散过程为从右到左的过程（ (Noise→Data)），表示从高斯噪声中逐步去噪，复原出原图。

扩散模型中的噪声是在像素空间进行的计算的，维度与图像一致，由此导致加噪和去噪过程的时间和内存消耗会非常大。Latent Diffusion Model利用自动编码器（Auto Encoder）将图像数据从高维像素空间表示（ (x) ）转换到低维潜空间表示（ (z) ），之后在低维空间进行去噪生成，大大降低时间和内存消耗。

文本引导的Diffusion模型主要包含两部分：文本编码器(Text Encoder)和U-Net；其中U-Net用于模拟噪声的分布，文本编码器把输入文本转换成U-Net可以理解的空间编码，引导噪声的采样以生成符合文本描述的图片。文本作为条件 (τθ) 输入，和时间步长 (t) 一起，以简单连接或者交叉注意力的方式，指导 (z) 的去噪。推理时，由Auto Encoder将 (T)时刻生成的表示 (z) 转换为像素空间的表示 (x) ，即可得到像素级别的图片。

StableDiffusion

StableDiffusion是在LAION-5B数据集子集上训练的一个LDM，可以在消费级GPU运行，生成(512×512)的图像仅需要几秒。目前StableDiffusion公布了v1和v2两个版本。StableDiffusion1.0主要支持文本引导的图像生成（text-to-img)、草图引导的图像生成(sketch-to-img)。最近发布的StableDiffusion2.0改进了文本编码器，并且默认生成的图像分辨率也提升至(768×768)，可支持(2048×2048)或更高。此外，StableDiffusion2.0增加了新的特性，支持深度图引导的图像生成(depth-to-img)和文本引导的图像编辑(text guided inpainting)。

PAI-Diffusion模型详解

由于现有Diffusion模型主要使用英文数据进行训练，如果直接使用机器翻译将英文数据翻译成中文进行模型训练，因为中英文在文化和表达上具有很大的差异性，产出的模型通常无法建模中文特有的现象。此外，通用的StableDiffusion模型由于数据源的限制，很难用于生成特定领域、特定场景下的高清图片。PAI-Diffusion系列模型由阿里云机器学习（PAI）团队发布并开源，除了可以用于通用文图生成场景，还具有一系列特定场景的定制化中文Diffusion模型，包括古诗配图、二次动漫、魔幻现实等。在下文中，我们首先介绍PAI-Diffusion的模型Pipeline架构，包括中文CLIP模型、Diffusion模型、图像超分模型等。

模型Pipeline架构

PAI-Diffusion模型Pipeline如上所示，分为四部分：

Text Encoder：把中文文本输入转化成 Embedding 向量，我们采用EasyNLP中文CLIP跨模态对齐模型（看这里）的Text Transformer作为Text Encoder；
Latent Diffusion Model：在 Latent 空间中根据文本输入处理随机生成的噪声；
Auto Encoder：将 Latent 空间中的张量还原为图片；
Super Resolution Model：提升图片分辨率，这里我们使用ESRGAN作为图像超分模型。

我们在使用Wukong数据集中的两千万中文图文数据对 Latent Diffusion Model部分进行了约 20 天的预训练，随后在多个下游数据集中进行了微调。

多场景艺术画鉴赏

下面我们展示几个不同场景下PAI-Diffusion模型的艺术画生成效果。

通用场景

古诗配图

二次动漫

艺术画

魔幻现实

真实业务场景示例

除了艺术画生成，PAI-Diffusion模型也能广泛地应用在各个真实业务场景中，以下我们给出在电商和美食场景下的文图生成效果。

电商商品

世界美食

轻松体验PAI-Diffusion模型

PAI-Diffusion模型可以通过多个途径进行体验。我们在阿里云机器学习AI能力中心上展示了更多不同场景下模型生成的高清大图。阿里云机器学习产品PAI-DSW（Data Science Workshop）提供了交互式的开发体验，方便用户通过调用Python API访问这些模型。此外，为了方便开源社区用户的体验，我们也在HuggingFace Space上展示了多个PAI-Diffusion模型的应用。

阿里云机器学习AI能力中心

阿里云机器学习AI能力中心提供了场景多样的AI实操案例，包括图像智能、自然语言处理、视频智能、多模态等各个领域的案例。我们也上架了PAI-Diffusion模型文图生成的功能，提供了更多不同场景下模型生成的高清大图。用户可以在这里体验AI能力中心的文图生成功能，示例参见下图。

阿里云机器学习PAI-DSW

PAI-DSW（Data Science Workshop）是阿里云机器学习平台PAI开发的云上IDE，面向不同水平的开发者，提供了交互式的编程环境（文档）。在DSW Gallery中，提供了各种Notebook示例，方便用户轻松上手DSW，搭建各种机器学习应用。我们也在DSW Gallery中上架了使用PAI-Diffusion模型进行中文文图生成的Sample Notebook，欢迎大家体验！

HuggingFace Space

为了方便开源社区用户的体验，我们在HuggingFace Space上展示了多个PAI-Diffusion模型的文图生成应用。以世界美食为例（https://huggingface.co/spaces/alibaba-pai/pai-diffusion-food-large-zh），用户只需要输入或者选择菜品名称作为输入，就可以得到模型生成的高清大图，示例参见下图。

未来展望

在这一期的工作中，我们公开了一系列PAI-Diffusion模型，支持各种场景下的中文文图生成功能。在未来，我们计划在EasyNLP框架（https://github.com/alibaba/EasyNLP）中集成这些模型的Checkpoint，并且提供简洁高效的训练接口，方便开源社区用户在资源有限情况下进行少量领域相关的微调，进行各种艺术创作，敬请期待。我们也将致力于PAI-Diffusion模型的优化策略，包括模型推理速度优化、生成图片质量提升和支持更为复杂的图像编辑功能。此外，阿里云机器学习PAI团队也在持续推进中文多模态模型的自研工作，欢迎用户持续关注我们，也欢迎加入我们的开源社区，共建中文NLP和多模态算法库！

Github地址：https://github.com/alibaba/EasyNLP

Reference

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
Robin Rombach, Andreas Blattmann, Dominik Lorenz, Patrick Esser, Björn Ommer. High-Resolution Image Synthesis with Latent Diffusion Models. CVPR 2022
Alec Radford, Jong Wook Kim, Chris Hallacy, Aditya Ramesh, Gabriel Goh, Sandhini Agarwal, Girish Sastry, Amanda Askell, Pamela Mishkin, Jack Clark, Gretchen Krueger, Ilya Sutskever. Learning Transferable Visual Models From Natural Language Supervision. ICML 2021
Jiaxi Gu, Xiaojun Meng, Guansong Lu, Lu Hou, Minzhe Niu, Xiaodan Liang, Lewei Yao, Runhui Huang, Wei Zhang, Xin Jiang, Chunjing Xu, Hang Xu. Wukong: 100 Million Large-scale Chinese Cross-modal Pre-training Dataset and A Foundation Framework. arXiv
Ling Yang, Zhilong Zhang, Yang Song, Shenda Hong, Runsheng Xu, Yue Zhao, Yingxia Shao, Wentao Zhang, Bin Cui, Ming-Hsuan Yang. Diffusion models: A comprehensive survey of methods and applications. arXiv

EasyNLP阿里灵杰回顾

阿里灵杰：阿里云机器学习PAI开源中文NLP算法框架EasyNLP，助力NLP大模型落地
阿里灵杰：预训练知识度量比赛夺冠！阿里云PAI发布知识预训练工具
阿里灵杰：EasyNLP带你玩转CLIP图文检索
阿里灵杰：EasyNLP中文文图生成模型带你秒变艺术家
阿里灵杰：EasyNLP集成K-BERT算法，借助知识图谱实现更优Finetune
阿里灵杰：中文稀疏GPT大模型落地 — 通往低成本&高性能多任务通用自然语言理解的关键里程碑
阿里灵杰：EasyNLP玩转文本摘要（新闻标题）生成
阿里灵杰：跨模态学习能力再升级，EasyNLP电商文图检索效果刷新SOTA
阿里灵杰：EasyNLP带你实现中英文机器阅读理解
阿里灵杰：EasyNLP发布融合语言学和事实知识的中文预训练模型CKBERT
阿里灵杰：当大火的文图生成模型遇见知识图谱，AI画像趋近于真实世界

1. String

字符串是 Redis 最基本的数据类型，不仅所有 key 都是字符串类型，其它几种数据类型构成的素也是字符串。注意字符串的长度不能超过 512M。

1.1 编码方式（encoding）

字符串对象的编码可以是 int ，raw 或者 embstr 。

int 编码：保存的是可以用 long 类型表示的整数值。
embstr 编码：保存长度小于 44 字节的字符串（redis3.2 版本之前是 39 字节，之后是 44 字节）。
raw 编码：保存长度大于 44 字节的字符串（redis3.2 版本之前是 39 字节，之后是 44 字节）。

int 编码是用来保存整数值，而 embstr 是用来保存短字符串，raw 编码是用来保存长字符串。

1.2 raw 编码

*ptr 指向实际 SDS 存储位置。内存不连续

1.3 embstr 编码

内存连续，意味着 redis 在申请内存空间时只需要调用一次申请内存函数，减少用户态内核态交换，效率高。

1.4 int 编码

如果存储的字符串是整数值，并且大小在 LONG_MAX 范围内，则会采用 INT 编码：直接将数据保存在 RedisObject 的 ptr 指针位置（刚好 8 字节），不再需要 SDS 了。

1.5 总结

2. List

list 列表，它是简单的字符串列表，按照插入顺序排序，你可以添加一个素到列表的头部（左边）或者尾部（右边），它的底层实际上是个链表结构。

2.1 编码方式（encoding）

列表对象的编码是 quicklist。 (之前版本中有 linkedList 和 ziplist 这两种编码。进一步的，目前 Redis 定义的 10 个对象编码方式宏名中，有两个被完全闲置了，分别是: OBJ_ENCODING_ZIPMAP 与 OBJ_ENCODING_LINKEDLIST。从 Redis 的演进历史上来看，前者是后续可能会得到支持的编码值（代码还在）, 后者则应该是被彻底淘汰了)

2.2 内存布局

3. Set

集合对象 set 是 string 类型（整数也会转换成 string 类型进行存储）的无序集合。注意集合和列表的区别：集合中的素是无序的，因此不能通过索引来操作素；集合中的素不能有重复。

3.1 编码方式（encoding）

集合对象的编码可以是 intset 或者 hashtable; 底层实现有两种，分别是 intset 和 dict 。显然当使用 intset 作为底层实现的数据结构时，集合中存储的只能是数值数据，且必须是整数；而当使用 dict 作为集合对象的底层实现时，是将数据全部存储于 dict 的键中，值字段闲置不用.

3.2 内存布局

3.3 编码转换

当集合同时满足以下两个条件时，使用 intset 编码：

集合对象中所有素都是整数
集合对象所有素数量不超过 512

不能满足这两个条件的就使用 hashtable 编码。第二个条件可以通过配置文件的 set-max-intset-entries 进行配置。

4. Zset

和上面的集合对象相比，有序集合对象是有序的。与列表使用索引下标作为排序依据不同，有序集合为每个素设置一个分数（score）作为排序依据。

4.1 编码方式（encoding）

SkipList & HT（Dict）：SkipList 可以排序，并且可以同时存储 score 和 ele 值（member）;HT 可以键值存储，并且可以根据 key 找 value
ZipList ：当节点 entry 数量小于 128 并且每个节点大小小于 64kb 时采用

4.2 内存结构

SkipList & HT（Dict）

ZipList

当素数量不多时，HT 和 SkipList 的优势不明显，而且更耗内存。因此 zset 还会采用 ZipList 结构来节省内存，不过需要同时满足两个条件：

素数量小于 zset_max_ziplist_entries，默认值 128
每个素都小于 zset_max_ziplist_value 字节，默认值 64

ziplist 本身没有排序功能，而且没有键值对的概念，因此需要有 zset 通过编码实现：

ZipList 是连续内存，因此 score 和 element 是紧挨在一起的两个 entry， element 在前，score 在后
score 越小越接近队首，score 越大越接近队尾，按照 score 值升序排列

5. Hash

哈希对象的键是一个字符串类型，值是一个键值对集合。

5.1 编码方式（encoding）

哈希对象的编码可以是 ziplist 或者 hashtable；对应的底层实现有两种，一种是 ziplist, 一种是 dict。

5.2 内存布局

Hash 结构与 Redis 中的 Zset 非常类似：

都是键值存储
都需求根据键获取值
键必须唯一

区别如下：

zset 的键是 member，值是 score；hash 的键和值都是任意值
zset 要根据 score 排序；hash 则无需排序

当 Hash 中数据项比较少的情况下，Hash 底层才⽤压缩列表 ziplist 进⾏存储数据，随着数据的增加，底层的 ziplist 就可能会转成 dict，具体配置如下：

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

本文由教研团队发布。

如果本文对您有帮助，欢迎和；如果您有任何建议也可或，您的支持是我坚持创作的动力。

转载请注明出处！

作者：崔雄华

1 Elasticsearch Head是什么

ElasticSearch head就是一款能连接ElasticSearch搜索引擎，并提供可视化的操作页面对ElasticSearch搜索引擎进行各种设置和数据检索功能的管理插件，如在head插件页面编写RESTful接口风格的请求，就可以对ElasticSearch中的数据进行增删改查、创建或者删除索引等操作。类似于使用navicat工具连接MySQL这种关系型数据库，对数据库做操作。

2 本地安装

下面简单介绍下ES环境安装和Elasticsearch Head在chrome浏览器中插件安装。

2.1 ES安装

安装链接：https://www.elastic.co/cn/webinars/getting-started-elasticsearch?elektra=what-is-elasticsearch&storm=hero-banner-cta&rogue=gs-with-elasticsearch-webinar
1.双击运行

2.启动成功日志

3.查看版本信息
访问地址：http://localhost:9200/ 出现如下信息：

2.2 head插件安装

安装链接：https://chrome.google.com/webstore/detail/multi-elasticsearch-head/cpmmilfkofbeimbmgiclohpodggeheim?hl=zh-CN
git地址：https://github.com/mobz/elasticsearch-head
1.打开head后效果

重要信息，集群健康值。Elasticsearch 中其实有专门的衡量索引健康状况的标志，分为三个等级：

green，绿色。这代表所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
yellow，黄色。所有的主分片已经分片了，但至少还有一个副本是缺失的。
red，红色。至少一个主分片以及它的全部副本都在缺失中。

3 基本查询

3.1 检索关键字

1.must子句
文档必须匹配must所有子句查询

2.should子句
文档应该匹配should子句查询的至少一个

3.must_not子句
文档不能匹配该查询条件，相当于“！=”

3.2 检索条件

match：分词匹配
term：表示精确匹配
wildcard：通配符匹配
prefix：前缀匹配
range：区间查询
query_string：允许在单个查询字符串中指定AND
text：文本
missing：无值（类似于sql中IS NULL）

4 复合查询

ES以RESTful接口风格的请求，使用json进行复杂的查询。请求格式：http://ip:port/索引/类型/文档Id

4.1 查询数据（GET）

user/user/BmH494EB0DXGzMoya1Bu

查询官方文档：https://www.elastic.co/guide/cn/elasticsearch/guide/current/query-dsl-intro.html

4.2 插入数据（PUT、POST）

PUT方法需要指明id

POST方法自动生成id

4.3 更新数据（PUT）

4.4 删除数据（DELETE）

4.5 给索引添加字段

user/user/_mapping也可以添加成功

5 具体实践

纯配ECLP运单数据除了落mysql数据库同时也会存储ES，商家工作台导出、运单列表功能就是查询ES数据。
例如下面就是根据运单号查询运单数据：

工作中需要在运单扩展表上增加字段，除了mysql数据表需要增加字段外，ES也要增加字段。lwb_main就是运单数据索引，给lwb_main索引增加字段执行语句如下：lwb_main/_mapping/lwb_main?pretty，pretty主要做美化作用，也可不要。

6 总结

Elasticsearch Head插件直接在chrome浏览器安装后就可以使用，非常方便，对于初学者大有益处，使用head插件可以快速实现ES索引数据的增删改查、创建或者删除索引等操作。

作者简介：Patrick Yu，携程云原生研发专家，关注非关系型分布式数据存储及相关技术。

背景

随着互联网世界产生的数据越来越多，数据之间的联系越来越复杂层次越来越深，人们希望从这些纷乱复杂的数据中探索各种关联的需求也在与日递增。为了更有效地应对这类场景，图技术受到了越来越多的关注及运用。

在携程，很早就有一些业务尝试了图技术，并将其运用到生产中，以 Neo4j 和 JanusGraph 为主。2021 年开始，我们期望规范业务的使用，并适配携程已有的各种系统，更好地服务业务方。经过调研，我们选择分布式图数据库 NebulaGraph 作为管理的对象，主要基于以下几个因素考虑：

NebulaGraph 开源版本即拥有横向扩展能力，为大规模部署提供了基本条件；
使用自研的原生存储层，相比 JanusGraph 这类构建在第三方存储系统上的图数据库，性能和资源使用效率上具有优势；
支持两种语言，尤其是兼容主流的图技术语言 openCypher，有助于用户从其他使用 Cypher 语言的图数据库（例如 Neo4j）中迁移；
拥有后发优势（2019 年起开源），社区活跃，且主流的互联网公司都有参与（腾讯，快手，美团，网易等）；
使用技术主流，代码清晰，技术债较少，适合二次开发；

NebulaGraph 架构及集群部署

NebulaGraph 是一个分布式的计算存储分离架构，如下图：

其主要由 graphd，metad 和 storaged 三部分服务组成，分别负责计算，数据存取，图数据（点，边，标签等数据）的存取。在携程的网络环境中，我们提供了三种部署方式来支撑业务，分别是：三机房部署、单机房部署和蓝绿双活部署。

三机房部署

用于满足一致性和容灾的要求，优点是任意一个机房发生机房级别故障，集群仍然可以使用，适用于核心应用。但缺点也是比较明显的，数据通过 raft 协议进行同步的时候，会遇到跨机房问题，性能会受到影响。

单机房部署

集群所有节点都在一个机房中，节点之间通讯可以避免跨机房问题（应用端与服务端之间仍然会存在跨机房调用），由于机房整体出现问题时该部署模式的系统将无法使用，所以适用于非核心应用进行访问。

蓝绿双活部署

在实际使用中，以上两种常规部署方式并不能满足一些业务方的需求，比如：性能要求较高的核心应用，三机房的部署方式所带来的网络损耗可能会超出预期。根据携程酒店某个业务场景真实测试数据来看，本地三机房的部署方式延迟要比单机房高 50%+，但单机房部署无法抵抗单个 IDC 故障。此外，还有用户希望能存在类似数据回滚的能力，以应对应用发布，集群版本升级可能导致的错误。

考虑到使用图数据库的业务大多数据来自离线系统，通过离线作业将数据导入到图数据库中，数据一致的要求并不高，在这种条件下使用蓝绿部署能够在灾备和性能上得到很好的满足。

与此同时我们还增加了一些配套的辅助功能，比如：

分流：可以按比例分配机房的访问，也可以主动切断对某个机房的流量访问
灾备：在发生机房级故障时，可自动切换读访问的流量，写访问的流量切换则通过人工进行操作

蓝绿双活方式是在性能、可用性、一致性上的一个折中的选择，使用此方案时应用端架构也需要有更多的调整以配合数据的存取。

生产上的一个例子：

上图为三机房情况，下图为蓝绿部署情况：

中间件及运维管理

我们基于 K8s CRD 和 Operator 来进行 NebulaGraph 的部署，同时通过服务集成到现有的部署配置页面和运维管理页面，来获得对 Pod 的执行和迁移的控制能力。基于模式监控、收集 NebulaGraph 的核心指标并通过 Telegraf 发送到携程自研的 Hickwall 集中展示，并设置告警等一系列相关工作。

此外，我们集成了跨机房的域名分配功能，为节点自动分配域名用于内部访问（域名只用于集群内部，集群与外部连通是通过 IP 直连的），这样做是为了避免节点漂移造成 IP 变更，影响集群的可用性。

在客户端上，相比原生客户端，我们主要做了以下几个改进和优化：

Session 管理功能

原生客户端 Session 管理比较弱，尤其是 v2.x 早期几个版本，多线程访问 Session 并不是线程安全的，Session 过期或者失效都需要调用方来处理，不适合大规模使用。同时，虽然官方客户端创建的 Session 是可以复用的，并不需要 release，官方也鼓励用户复用，但是却没有提供统一的 Session 管理功能来帮助用户复用。因此，我们增加了 Session Pool 的概念来实现复用。

其本质上是管理一个或多个 Session Object Queue，通过的方式（下图），确保了一个 Session 在同一时间只会由一个执行器在使用，避免了共用 Session 产生的问题。同时通过对队列的管理，我们可以进行 Session 数量和版本的管理，比如：预生成一定量的 Session，或者在管理中心发出消息之后变更 Session 的数量或者访问的路由。

蓝绿部署（包括读写分离）

上面章节中介绍了蓝绿部署，相应的客户端也需要改造以支持访问 2 个集群。由于生产中，读和写的逻辑往往不同，比如：读操作希望可以由 2 个集群共同提供数据，而写的时候只希望影响单边，所以我们在进行蓝绿处理的时候也增加了读写分离（下图）。

流量分配

如果要考虑到单边切换以及读写不同的路由策略，就需要增加流量分配功能。我们没有采用携程内广泛使用的 Virtual IP 作为访问路由，希望有更为强大的定制管理能力及更好的性能。

通过直连而不是 Virtual IP 中转可以减少一次转发的损耗；
在维持长连接的同时也能实现每次请求使用不同的链路，平摊 graphd 的访问压力；
完全自主控制路由，可以实现更为灵活的路由方案；
当存在节点无法访问的时候，客户端可以自动临时排除有问题的 IP，在短时间内避免再次使用。而如果使用 Virtual IP 的话，由于一个 Virtual IP 会对应多个物理 IP，就没有办法直接这样操作。

通过构造面向不同 IDC 的 Session Pool，并根据配置进行权重轮询，就可以达到按比例分配访问流量的目的（下图）。

将流量分配集成进蓝绿模式，就基本实现了基本的客户端改造（下图）。

结构化语句查询

图 DSL 目前主流的有两种，Gremlin 和 Cypher，前者是过程式语言而后者是声明式语言。NebulaGraph 支持了 openCypher（Cypher 的开源项目）语法和自己设计的 nGQL 原生语法，这两种都是声明式语言，在风格上比较类似 SQL。尽管如此，对于一些较为简单的语句，类似 Gremlin 风格的过程式语法对用户会更为友好，并且有利用监控埋点。基于这个原因，我们封装了一个过程式的语句生成器。

例如：

系统调优实践

由于建模，使用场景，业务需求的差异，使用Nebula Graph的过程中所遇到的问题很可能会完全不同，以下以携程酒店信息图谱线上具体的例子进行说明，在整个落地过程我们遇到的问题及处理过程（文中以下内容是基于Nebula Graph 2.6.1进行的）。

关于酒店该业务的更多细节，可以阅读《信息图谱在携程酒店的应用》这篇文章。

酒店集群不稳定

起因是酒店应用上线后发生了一次故障，大量的访问超时，并伴随着这样的错误信息。稍加排查，我们发现 metad 集群有问题，metad0 的 local ip 和 metad_server_address 的配置不一致，所以 metad0 实际上一直没有工作。

但这本身并不会导致系统问题，因为 3 节点部署，只需要 2 个节点工作即可。后来 metad1 容器又意外被漂移了，导致 IP 变更，这个时候实际上 metad 集群已经无法工作（下图），导致整个集群都受到了影响。

在处理完以上故障并重启之后，整个系统却并没有恢复正常，CPU 的使用率很高。此时，外部应用并没有将流量接入进来，但整个 metad 集群内部网络流量却很大，如下图所示：

监控显示 metad 磁盘空间使用量很大，检查下来 WAL 在不断增加，说明这些流量主要是数据的写入操作。我们打开 WAL 数据的某几个文件，其大部分都是 Session 的数据，因为 Session 信息是会在 NebulaGraph 集群内持久化的，所以考虑问题可能出在这里。通过阅读源码我们注意到，graphd 会从 metad 中同步所有的 Session 信息，并在修改之后将数据再全部回写到 metad 中，所以如果流量都是 session 信息的话，那么问题就可能：

Session 没有过期
创建了太多的 Session

检查发现该集群没有配置 Session 超时时间，所以我们修改以下配置来处理这个问题：

修改之后，metad 的磁盘空间占用下降，同时通信流量和磁盘读写也明显下降（下图）：

系统逐步恢复正常，但是还有一个问题没有解决，就是为什么有如此之多的 Session 数据？查看应用端日志，我们注意到 Session 创建次数超乎寻常，如下图所示：

通过日志发现是我们自己开发的客户端中的 bug 造成的。我们会在报错时让客户端释放对应的 Session，并重新创建。但，由于系统抖动，这个行为造成了比较多的超时，导致更多的 Session 被释放并重建，引起了恶性循环。针对这个问题，对客户端进行了如下优化：

序号修改 1 将创建 session 行为由并发改为串行，每次只允许一个线程进行创建工作，不参与创建的线程监听 session pool 2 进一步增强 session 的复用，当 session 执行失败的时候，根据失败原因来决定是否需要 release。原有的逻辑是一旦执行失败就 release 当前 session，但有些时候并非是 session 本身的问题，比如超时时间过短，nGQL 有错误这些应用层的情况也会导致执行失败，这个时候如果直接 release，会导致 session 数量大幅度下降从而造成大量 session 创建。根据问题合理的划分错误情况来进行处理，可以最大程度保持 session 状况的稳定 3 增加预热功能，根据配置提前创建好指定数量的 session，以避免启动时集中创建 session 导致超时

酒店集群存储服务 CPU 使用率过高

酒店业务方在增加访问量的时候，每次到 80% 的时候集群中就有少数 storaged 不稳定，CPU 使用率突然暴涨，导致整个集群响应增加，从而应用端产生大量超时报错，如下图所示：

和酒店方排查下来初步怀疑是存在稠密点问题（在图论中，稠密点是指一个点有着极多的相邻边，相邻边可以是出边或者是入边），部分 storaged 被集中访问引起系统不稳定。由于业务方强调稠密点是其业务场景难以避免的情况，我们决定采取一些调优手段来缓解这个问题。

优化稠密点之尝试通过 Balance 来分摊访问压力

回忆之前的官方架构图，数据在 storaged 中是分片的，且 raft 协议中只有 leader 才会处理请求，所以，重新进行数据平衡操作，是有可能将多个稠密点分摊到不同的服务上以减轻单一服务的压力。同时，我们对整个集群进行 Compaction 操作（由于 storaged 内部使用了 RocksDB 作为存储引擎，数据是通过追加来进行修改的，Compaction 可以清楚过时的数据，提高访问效率）。

操作之后集群的整体 CPU 是有一定的下降，同时服务的响应速度也有小幅的提升，如下图。

但在运行一段时间之后仍然遇到了 CPU 突然增加的情况，稠密点显然没有被平衡掉，也说明在分片这个层面是没法缓解稠密点带来的访问压力的。

优化稠密点之尝试通过配置缓解锁竞争

进一步调研出现问题的 storaged 的 CPU 的使用率，可以看到当流量增加的时候，内核占用的 CPU 非常高，如下图所示：

抓取 perf 看到，锁竞争比较激烈，即使在“正常”情况下，锁的占比也很大，而在竞争激烈的时候，出问题的 storaged 服务上这个比例超过了 50%。如下图所示：

所以我们从减少冲突入手，对 NebulaGraph 集群主要做了如下改动：

重新上线之后，整个集群服务变得比较平滑，CPU 的负载也比较低，正常情况下锁竞争也下降不少（下图），酒店也成功地将流量推送到了 100%。

但运行了一段时间之后，我们仍然遇到了服务响应突然变慢的情况，热点访问带来的压力的确超过了优化带来的提升。

优化稠密点之尝试减小锁的颗粒度

考虑到在分片级别的 balance 不起作用，而 CPU 的上升主要是因为锁竞争造成的，那我们想到如果减小锁的颗粒度，是不是就可以尽可能减小竞争？RocksDB 的 LRUCache 允许调整 shared 数量，我们对此进行了修改：

版本 LRUCache 默认分片数方式 v2.5.0 2^8 修改代码，将分片改成 2^10 v2.6.1及以上 2^8 通过配置，将分片数改为 2^10

观察下来效果不明显，无法解决热点竞争导致的雪崩问题。其本质同 balance 操作一样，只是粒度的大小的区别，在热点非常集中的情况下，在数据层面进行处理是走不通的。

优化稠密点之尝试使用 ClockCache

竞争的锁来源是 block cache 造成的。NebulaGraph storaged 使用 RocksDB 作为存储，其使用的是 LRUCache 作为 block cache 等一系列 cache 的存储模块，LRUCache 在任何类型的访问的时候需要需要加锁操作，以进行一些 LRU 信息的更新，排序的调整及数据的淘汰，存在吞吐量的限制。

由于我们主要面临的就是锁竞争，在业务数据没法变更的情况下，我们希望其他 cache 模块来提升访问的吞吐。按照 RocksDB 官方介绍，其还支持一种 cache 类型 ClockCache，特点是在查询时不需要加锁，只有在插入时才需要加锁，会有更大的访问吞吐，考虑到我们主要是读操作，看起来 ClockCache 会比较合适。

LRU cache和Clock cache的区别：https://rocksdb.org.cn/doc/Block-Cache.html

经过修改源码和重新编译，我们将缓存模块改成了 ClockCache，如下图所示：

但集群使用时没几分钟就 core，查找资料我们发现目前 ClockCache 支持还存在问题（https://github.com/facebook/rocksdb/pull/8261），此方案目前无法使用。

优化稠密点之限制线程使用

可以看到整个系统在当前配置下，是存在非常多的线程的，如下图所示。

如果是单线程，就必然不会存在锁竞争。但作为一个图服务，每次访问几乎会解析成多个执行器来并发访问，强行改为单线程必然会造成访问堆积。

所以我们考虑将原有的线程池中的进程调小，以避免太多的线程进行同步等待带来的线程切换，以减小系统对 CPU 的占用。

调整之后整个系统 CPU 非常平稳，绝大部分物理机 CPU 在 20% 以内，且没有之前遇到的突然上下大幅波动的情况（瞬时激烈锁竞争会大幅度提升 CPU 的使用率），说明这个调整对当前业务来说是有一定效果的。

随之又遇到了下列问题，前端服务突然发现 NebulaGraph 的访问大幅度超时，而从系统监控的角度却毫无波动（下图 24，19:53 系统其实已经响应出现问题了，但 CPU 没有任何波动）。

原因是在于，限制了 thread 确实有效果，减少了竞争，但随着压力的正大，线程吞吐到达极限。但如果增加线程，资源的竞争又会加剧，无法找到平衡点。

优化稠密点之关闭数据压缩，关闭 block cache

在没有特别好的方式避免锁竞争的情况，我们重新回顾了锁竞争的整个发生过程，锁产生本身就是由 cache 自身的结构带来的，尤其是在读操作的时候，我们并不希望存在什么锁的行为。

使用 block cache，是为了在合理的缓存空间中尽可能的提高缓存命中率，以提高缓存的效率。但如果缓存空间非常充足，且命中长期的数据长期处于特定的范围内，实际上并没有观察到大量的缓存淘汰的情况，且当前服务的缓存实际上也并没有用满，所以想到，是不是可以通过关闭 block cache，而直接访问 page cache 来避免读操作时的加锁行为。

除了 block cache，存储端还有一大类内存使用是 indexes and filter blocks，与此有关的设置在 RocksDB 中是。当这个设置为 true 的时候，数据会缓存到 block cache 中，所以如果关闭了 block cache，我们就需要同样关闭（在 NebulaGraph 中，通过配置项替代直接修改 RocksDB 的）。

但仅仅修改这些并没有解决问题，实际上观察 perf 我们仍然看到锁的竞争造成的阻塞（下图）：

这是因为当为 false 的时候，并不代表 index 和 filter 数据不会被加载到内存中，这些数据其实会被放进 table cache 里，仍然需要通过 LRU 来维护哪些文件的信息需要淘汰，所以 LRU 带来的问题并没有完全解决。处理的方式是将设置为 -1，以提供给系统无限制的 table cache 的使用，在这种情况下，由于没有文件信息需要置换出去，算法逻辑被关闭。

总结下来核心修改如下表：

避免文件被 table cache 淘汰，避免文件描述符被关闭，加快文件的读取

关闭了 block cache 后，整个系统进入了一个非常稳定的状态，线上集群在访问量增加一倍以上的情况下，系统的 CPU 峰值反而稳定在 30% 以下，且绝大部分时间都在 10% 以内（下图）。

需要说明的是，酒店场景中关闭 block cache 是一个非常有效的手段，能够对其特定情况下的热点访问起到比较好的效果，但这并非是一个常规方式，我们在其他业务方的 NebulaGraph 集群中并没有关闭 block cache。

数据写入时服务 down 机

起因酒店业务在全量写入的时候，即使量不算很大（4~5w/s），在不特定的时间就会导致整个 graphd 集群完全 down 机。由于 graphd 集群都是无状态的，且互相之间没有关系，如此统一的在某个时刻集体 down 机，我们猜测是由于访问请求造成。通过查看堆栈发现了明显的异常（下图）：

可以看到上图中的三行语句被反复执行，很显然这里存在递归调用，并且无法在合理的区间内退出，猜测为堆栈已满。在增加了堆栈大小之后，整个执行没有任何好转，说明递归不仅层次很深，且可能存在指数级的增加的情况。同时观察 down 机时的业务请求日志，失败瞬间大量执行失败，但有一些执行失败显示为 null 引用错误，如下图所示：

这是因为返回了报错，但没有 error message，导致发生了空引用（空引用现象是客户端未合理处理这种情况，也是我们客户端的 bug），但这种情况很奇怪，为什么会没有 error message，检查其 trace 日志，发现这些请求执行 NebulaGraph 时间都很长，且存在非常大段的语句。如下图所示：

预感是这些语句导致了 graphd 的 down 机，由于执行被切断导致客户端生成了一个 null 值。将这些语句进行重试，可以必现 down 机的场景。检查这样的请求发现其是由 500 条语句组成（业务方语句拼接上限 500），并没有超过配置设置的最大执行语句数量（512）。

看起来这是一个 NebulaGraph 官方的 bug，我们已经将此问题提交给官方。同时，业务方语句拼接限制从 500 降为 200 后顺利避免该问题导致的 down 机，该 bug 已在新版中修复。

NebulaGraph 二次开发

当前我们对 NebulaGraph 的修改主要集中的几个运维相关的环节上，比如新增了命令来指定迁移 storaged 中的分片，以及将 leader 迁移到指定的实例上（下图）。

未来规划

与携程大数据平台整合，充分利用 Spark 或者 Flink 来实现数据的传输和 ETL，提高异构集群间数据的迁移能力。
提供 Slowlog 检查功能，抓取造成 slowlog 的具体语句。
参数化查询功能，避免依赖注入。
增强可视化能力，增加定制化功能。

谢谢你读完本文 (///▽///)

PhpStorm激活2022.3.1如果你想尝鲜图数据库 NebulaGraph，体验云上图数据库一键服务你的业务 ->☆白嫖 NebulaGraph 云服务；NebulaGraph 也是一款开源的图数据库，上 GitHub 看代码、(^з^)-☆ star 它 -> GitHub；和其他的 NebulaGraphPhpStorm激活2022.3.1 用户一起交流图数据库技术和应用技能，留下「你的名片」一起玩耍呀~

PhpStorm激活2022.3.1(PhpStorm 2022.3 发布，带来完整的 PHP 8.2 支持)

改进的快速文档

🍈项目介绍

🛠️本次功能更新

🚅 路线图

🥞功能截图

漏洞描述

影响范围

修复方案

参考链接

情报订阅

漏洞描述

影响范围

修复方案

参考链接

情报订阅

漏洞描述

影响范围

修复方案

参考链接

情报订阅

业务背景

数据平台架构

报告查询基于明细

字段查询热度分层分布

实验组 ID 匹配效率低

进组人数计算有待改进

数据优化方案

选取高频使用维度聚合

使用物化视图

精确匹配取代 LIKE 查询

使用 BITMAP 去重代替 COUNT DISTINCT

优化效果

SQL视角

集群视角

小技巧

结束语

在遭遇异常流量高峰时，如何处理？

解决方案：

我们今天介绍的自治限流功能是如何应对这一潜在风险呢？

分库、分用户设置限流范围

设置限流时间：

设置限流策略

一、自动驾驶商业化落地加速，研发业务面临 4 大挑战

二、基于Ploto构建自动驾驶平台

三、乐高式、开放化——高效构建自动驾驶研发平台的行业新解

模式 1：模块按需构建

模式 2：E2E 快速构建

模式 3：自有专业软件服务商集成

对策:

原始模型数据准备

以TensorFlow为例

NPU模型数据准备

以推理场景为例

以训练场景为例

精度对比工具使用方法

创建对比任务

整网对比结果

单算子对比

总结

前言

场景

代码详解

1、go-zero 默认集成

2、本地方法

3、mq 的 producer 到 mq 的 consumer

项目地址

微信交流群

一

二

三

四

五

六

背景

如何进行精准分析

精准分析实现

应用

引言

事务理论介绍