优化可扩展的拜占庭容错共识算法韩嗣诚, 朱晓荣, 张秀贤南京邮电大学通信与信息工程学院，江苏 南京 210003摘要区块链是一个去中心化的账本，可为交易中互不信任的双方提供信任，其最初作为支撑比特币的底层框架，近年来逐渐成为具有颠覆价值的新兴技术。共识算法是区块链的核心技术之一，没有共识算法就无法实现分布式节点间的状态一致。简单介绍了一种目前联盟链中常用的共识算法——实用拜占庭容错（PBFT,practical Byzantine fault tolerance）算法，并在其基础上优化算法机制，增加可扩展性，提出了一种改进的算法。经改进后，降低了算法的复杂度，并且允许共识节点加入和退出系统。仿真结果表明，改进后的算法可显著减少交易共识完成的时间和节点间的通信次数，从而在支持更多节点、减少系统通信开销和 CPU 计算资源消耗的同时，增大了整个系统的吞吐量。关键词： 区块链 ; 共识算法 ; 拜占庭容错 ; 可扩展1 引言区块链是一个由分布式对等网络、数据加密、共识算法等技术组合而成的去中心化账本或数据库。区块链运用技术手段为用户提供了对彼此的信任，使得他们可以在相互之间无信任基础的前提下完成交易，且其去中心化的存储方式配合共识机制使得交易的记录无法被篡改。区块链最初诞生于比特币[1]中，作为服务交易的底层架构，逐渐扩展到各式各样的“数字货币”甚至金融业务中。随后，对架构和共识机制做了一定改变的联盟链被认为可以超越金融领域，用于数字资产认证、供应链溯源等商业化领域。共识算法是区块链非常重要的一部分，也是其去中心化和信任机制建立的基础。具体来说，在分布式状态机构成的异步网络中，需要有一种办法保证每个状态机最终达成一个一致的状态，这种方法被称为共识算法。共识算法在区块链中的具体作用是保证每个节点中记录的区块信息以及区块中的交易或请求信息都是相同的，这样才能达到“共同维护”的效果。比特币中的工作量证明（PoW,proof of work）是最早使用的共识算法，其核心是通过算力来竞争记账权，也就是创建新区块的权利。算力体现在给定一个字符串，在其后连接一个整数值串，然后对连接后的整个字符串进行 SHA256 哈希运算，如果运算后得到的字符串是以若干个0开头则验证通过，最先算出这个字符串的节点可以创建新区块，并得到一定数量比特币的奖励。这种算法非常耗费资源，除了最终胜出的节点，其他节点都在不停地计算却一无所获。以太坊出于对优化资源的考虑，设计了一种相对简单的共识算法，即权益证明（PoS,proof of stake）[2]。该机制引入了币龄的概念，通过一种与币龄相关的方式来决定创建新区块的权利，拥有币龄越大的节点获得区块创建权的可能性越高。PoW和PoS适用于参与节点众多的公有链，但却不适合节点数较少、节点间存在一定信任度的联盟链和私有链。联盟链和私有链常用的算法是基于消息传递的共识算法，如实用拜占庭容错（PBFT,practical Byzantine fault tolerance）算法[3]、Paxos算法[4]和Raft算法[5]等。其中，PBFT算法是一种主要用于联盟链的、可以解决拜占庭错误的算法，本文将在第2节进行介绍；而Paxos算法和基于其改进的 Raft 算法则主要用于不存在拜占庭错误的私有链中。Raft算法不考虑拜占庭错误，节点仅可能因为故障而宕机，Raft算法将节点分为集群，每个集群通常包含 5 个节点（服务器），允许最多有两个节点（服务器）发生故障。除了上述已经成熟且投入应用的算法，近年也出现了一些新算法，如 Ripple 算法[6]和小蚁算法[7]等。区块链的高热度促使很多研究者对这些算法做了不同程度的改进。文献[8]将PoW和PoS结合，提出了一种双跳的共识算法。文献[9]提出了一种基于投票证明（proof of vote）的算法，为参与者建立不同的安全身份，再根据安全身份进行投票，来决定交易的提交和区块的创建。文献[10]提出了轻量化、动态化的Raft算法为Pirogue算法，其核心在于有节点发生故障后，剩余无故障节点可根据新的投票规则继续对交易进行共识，直到故障节点数量达到上限。文献[11]为 PBFT 算法增加了数据同步机制。本文的主要贡献和成果如下。1) 对PBFT算法进行改进，在确保共识机制可靠的前提下降低了算法复杂度，提升了共识效率，降低了计算资源消耗，提升了系统吞吐量。2) 允许共识节点自由地加入和退出共识系统，并设计了加入和退出机制，使得算法能够更好地适用于实际的区块链系统。2 结束语本文介绍了常用的共识算法，从联盟链目前相对成熟的PBFT算法着手研究，对其进行改进，提出了OSBFT算法。OSBFT算法减少了共识步骤，增加了节点加入和退出机制，使得共识节点数量可变化。最后，本文对 OSBFT 算法进行性能分析。分析结果表明，改进后的算法可显著减少交易共识完成的时间和节点间的通信次数，从而在支持更多节点、减少系统通信开销和 CPU 计算资源消耗的同时，增大了整个系统的吞吐量。The authors have declared that no competing interests exist.作者已声明无竞争性利益关系。3 原文链接http://www.infocomm-journal.com/wlw/article/2020/2096-3750/2096-3750-4-2-00018.shtml

基于分布式光纤振动传感器的铁路安全监测算法陈复扬1,2, 姜斌1,2, 沙宇11 南京航空航天大学自动化学院，江苏 南京 2111062 物联网与控制技术江苏省高校重点实验室，江苏 南京 211106摘要针对铁路沿线存在人员攀爬栅栏网这一问题，将分布式光纤传感技术和信号分析技术相结合，提出了一种基于分布式光纤振动传感器的铁路安全监测算法。通过沿铁路周界栅栏网敷设的光缆感知并传导信号，搭建铁路与监测算法的物联网连接，实现对攀爬行为的智能化监测。针对铁路周围环境较复杂、干扰较多的情况，采用海明窗分帧加小波阈值去噪的方法对每帧信号进行滤波，提高了振动信号的信噪比。在特征选择上，从时域和频域上分别提取信号的功率和短时过电平率作为联合特征，对是否存在攀爬行为进行判别。因为攀爬行为具有空间上的连续性，在监测过程中设置最小报警范围滤除范围过小的报警，提高了监测系统的准确性。关键词： 分布式光纤振动传感器 ; 铁路沿线 ; 信号处理 ; 入侵 ; 物联网1 引言随着中国铁路交通的迅速发展，铁路里程逐渐增加，铁路周界的安全问题也越来越重要。为了保证铁路运行的畅通和人员的安全，铁轨旁会有栅栏网进行隔离，但人员私自攀爬栅栏网进入轨道而造成的惨案还是时有发生。因此，对铁路周边环境进行监测并及时对人员的攀爬行为做出识别和处理尤为重要。现有的分布式光纤振动传感器具有灵敏度高、抗电磁干扰能力强、耐腐蚀等特点，可以在铁轨周围的复杂环境中进行工作[3,4]，可以实现连续性测量，从而更好地反映铁轨周围的情况。本文将物联网传感技术引入轨道交通的监测系统。利用分布式光纤振动传感器可以实现连续和实时测量的特性对振动信号进行监测和识别，通过分析振动信号判断铁路周界是否存在入侵行为，对于存在入侵行为的情况，实时地给出入侵行为发生的位置。在判别入侵行为时，存在两个关键问题。一方面，光纤敷设条件较复杂，存在列车运行带来的干扰和自然环境的影响，因此，采集的振动信号中存在较多干扰，造成后续的信号分析困难；另一方面，在进行入侵行为判别时，单一的特征较容易造成误报，所以要寻找合适的联合特征进行判别。基于以上讨论，本文首先滤除了列车和环境因素造成的干扰，其次选取了对攀爬信号响应较明显的两个特征构建联合特征，对入侵行为进行判别，本文的主要工作如下。1) 对振动信号进行分帧，采用形状系数调节的软阈值去噪法去除列车及环境的干扰。2) 选取过电平率和信号的功率构建联合特征，采用K-means方法训练正常情况和存在入侵行为时特征空间的簇心。3) 建立归一化0-1矩阵，利用入侵行为在空间上具有连续性的特点，滤除部分不连续或影响范围过小的报警。2 结束语本文从工程应用角度出发，研究了分布式光纤振动传感器在保障轨道运输安全上的应用，提出了一种基于分布式光纤振动传感器的铁路安全监测算法。利用攀爬信号和环境噪声信号在波动频率、能量和影响范围等多尺度上的差异性对入侵行为进行判别，避免了用单一特征进行判别，使得判断结果更准确。对所有采样点进行归一化处理，使得监测振动带的过程更便利。为了增强该监测算法的适用性，在背景数据集的选择方面，本文添加了 4 级及以下风干扰和小雨干扰场景，使得场景更丰富，提高了算法的环境适应性。本文采用实际攀爬时的信号和实际的环境噪声信号进行训练和测试，保证了该方法的工程性，测试结果证明了该方法的有效性。The authors have declared that no competing interests exist.作者已声明无竞争性利益关系。3 原文链接http://www.infocomm-journal.com/wlw/article/2020/2096-3750/2096-3750-4-3-00106.shtml

节点Citus 是一种 PostgreSQL 扩展，它允许数据库服务器(称为节点)在“无共享(shared nothing)”架构中相互协调。这些节点形成一个集群，允许 PostgreSQL 保存比单台计算机上更多的数据和使用更多的 CPU 内核。这种架构还允许通过简单地向集群添加更多节点来扩容数据库。扩展https://www.postgresql.org/docs/current/external-extensions.htmlCoordinator 与 Worker每个 cluster 都有一个称为 coordinator(协调器) 的特殊节点(其他节点称为 worker 节点)。应用程序将它们的查询发送到 coordinator 节点，coordinator 节点将其转发给相关的 worker 并累积结果。对于每个查询，coordinator 要么将其路由到单个 worker 节点，要么将其并行化到多个节点，具体取决于所需数据是位于单个节点上还是多个节点上。coordinator 通过查阅其元数据表知道如何做到这一点。这些 Citus 特定表跟踪 worker 节点的 DNS 名称和运行状况，以及跨节点数据的分布情况。分布式数据表类型Citus 集群中有三种类型的表，每种表都以不同方式存储在节点中，并且用于不同的目的。类型 1：分布式表第一种类型，也是最常见的，是分布式表。对于 SQL 语句而言，它们看似是普通的表，但在 worker 节点之间水平分区。这里 table 的行存储在 worker 的表 table_1001、table_1002 等中。组件 worker 表称为分片(shards)。分布列Citus 使用使用分片算法将行分配到分片。基于表列(称为分布列(distribution column))的值执行分配，此分配具有确定性。集群管理员在分布表时必须指定此列。做出正确的选择，这一点对于性能和功能有重要影响。类型 2：引用表引用表 是一种分布式表，其全部内容都集中到单个分片中，并在每个 worker 上复制。因此，对任何 worker 的查询都可以在本地访问 引用 信息，无需从另一个节点请求行，因此也不会产生此类网络开销。引用表没有分布列，因为无需区分每行的各个分片。引用表 通常很小，用于存储与在任何工作节点上运行的查询相关的数据。例如，订单状态或产品类别等枚举值。当与 引用表 交互时，我们会自动对事务执行两阶段提交 (2PC)。这意味着 Citus 确保您的数据始终处于一致状态，无论您是在写入、修改还是删除它。2PChttps://en.wikipedia.org/wiki/Two-phase_commit_protocol类型 3：本地表当您使用 Citus 时，您连接并与之交互的 coordinator 节点是安装了 Citus 扩展的常规 PostgreSQL 数据库。因此，您可以创建普通表并选择不对其进行分片。这对于不参与连接查询的小型管理表很有用。一个示例是用于应用程序登录和身份验证的用户表。创建标准 PostgreSQL 表很容易，因为它是默认值。这是你运行 CREATE TABLE 时得到的。在几乎每个 Citus 部署中，我们都会看到标准 PostgreSQL 表与 distributed 和 reference 表共存。事实上，如前所述，Citus 本身使用本地表来保存集群元数据。Shards上一节将分片描述为在 worker 节点内的较小表中包含分布式表的行的子集。本节详细介绍了技术细节。协调器上的 pg_dist_shard 元数据表包含系统中每个分布式表的每个分片的行。该行与分片 ID 相匹配，分片 ID 的范围是一组哈希整数 (shardminvalue, shardmaxvalue)。SELECT * from pg_dist_shard; logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue ---------------+---------+--------------+---------------+--------------- github_events | 102026 | t | 268435456 | 402653183 github_events | 102027 | t | 402653184 | 536870911 github_events | 102028 | t | 536870912 | 671088639 github_events | 102029 | t | 671088640 | 805306367 (4 rows)如果 coordinator 节点要确定哪个分片包含 github_events 行，它将对行中分布列的值执行哈希算法。然后此节点检查哪个分片的范围包含此哈希值。定义范围后，哈希函数的image(图像)就是两者的并查。分片放置假设分片 102027 与相应的行关联。在某个 worker 中的 github_events_102027 表中读取或写入此行。是哪个 worker?这完全由元数据表确定。分片映射到 worker 的过程称为分片放置(shard placement)。coordinator 节点将查询重写为引用特定表(例如 github_events_102027)的片段，并对相应 worker 运行这些片段。下面的查询示例在后台运行，旨在查找分片 ID 为 102027 的节点。SELECT shardid, node.nodename, node.nodeport FROM pg_dist_placement placement JOIN pg_dist_node node ON placement.groupid = node.groupid AND node.noderole = 'primary'::noderole WHERE shardid = 102027; ┌─────────┬───────────┬──────────┐ │ shardid │ nodename │ nodeport │ ├─────────┼───────────┼──────────┤ │ 102027 │ localhost │ 5433 │ └─────────┴───────────┴──────────┘在 github_events 示例中，有四个分片。每个表的分片数量在其在集群中分布时是可配置的。最后请注意，Citus 允许复制分片以防止数据丢失。有两种复制“模式”：Citus 复制和流复制。前者创建额外的备份分片放置并针对所有更新它们的所有它们运行查询。后者效率更高，利用 PostgreSQL 的流式复制将每个节点的整个数据库备份到一个 follower 数据库。这是透明的，不需要 Citus 元数据表的参与。共置由于可以根据需要将分片及其副本放置在节点上，因此将包含相关表的相关行的分片放在同一节点上是有意义的。这样，它们之间的连接查询可以避免通过网络发送尽可能多的信息，并且可以在单个 Citus 节点内执行。一个示例是包含商店、产品和购买的数据库。如果所有三个表都包含 - 并且由 - store_id 列分布，那么限制在单个存储中的所有查询都可以在单个工作节点上高效运行。即使查询涉及这些表的任意组合也是如此。并行性跨多台机器分散查询允许一次运行更多查询，并允许通过向集群添加新机器来扩展处理速度。此外，如上一节所述，将单个查询拆分为片段可以提高专用于它的处理能力。后一种情况实现了最大的并行性，这意味着 CPU 内核的利用率。读取或影响均匀分布在多个节点上的分片的查询能够以“实时”速度运行。请注意，查询的结果仍然需要通过协调器节点传回，因此当最终结果紧凑时(例如计数和描述性统计等聚合函数)，加速效果最为明显。查询执行在执行多分片查询时，Citus 必须平衡并行性的收益与数据库连接的开销(网络延迟和工作节点资源使用)。要配置 Citus 的查询执行以获得最佳的数据库工作负载结果，它有助于了解 Citus 如何管理和保存协调节点和工作节点之间的数据库连接。Citus 将每个传入的多分片查询会话转换为称为任务的每个分片查询。它将任务排队，并在能够获得与相关工作节点的连接时运行它们。对于分布式表 foo 和 bar 的查询，下面是连接管理图：coordinator 节点为每个会话都有一个连接池。每个查询(例如图中的 SELECT * FROM foo)仅限于为每个 worker 的任务打开最多 citus.max_adaptive_executor_pool_size(整数)个同时连接。该设置可在会话级别进行配置，以进行优先级管理。在同一连接上按顺序执行短任务比为它们并行建立新连接更快。另一方面，长时间运行的任务受益于更直接的并行性。为了平衡短任务和长任务的需求，Citus 使用 citus.executor_slow_start_interval(整数)。该设置指定多分片查询中任务的连接尝试之间的延迟。当查询首先对任务进行排队时，这些任务只能获取一个连接。在每个有待处理连接的时间间隔结束时，Citus 会增加它将打开的同时连接数。通过将 GUC 设置为 0，可以完全禁用慢启动行为。当任务完成使用连接时，会话池将保持连接打开以供以后使用。缓存连接避免了 coordinator 和 worker 之间重新建立连接的开销。但是，每个池一次打开的空闲连接不超过 citus.max_cached_conns_per_worker(整数)个，以限制 worker 中空闲连接资源的使用。最后，设置 citus.max_shared_pool_size (integer) 充当故障保险。它限制了所有任务之间每个 worker 的总连接数。

衣公子的剑——做爱读的商业评论01 逆袭鲁宾先是在苹果打工。离职创业，被微软收购。从微软离职，再创业Danger手机，结果又被微软收购。拒绝回微软，继续捣鼓一个叫作Android的创业项目。又被Google收购。拉里·佩奇待鲁宾好，给钱给资源，打战的感觉。搜索引擎Google要做手机了。鲁宾士为知己者死，带着团队干了15个月，每周工作60－80小时。结果2007年1月9日，iPhone发布，鲁宾自惭形秽，觉得自己做的简直是垃圾。在佩奇的支持下，扔掉重来，再做一年，终于上市了。但是乔布斯发火了。把佩奇和鲁宾，叫到自己办公室。严厉训斥。乔布斯极度看不上鲁宾，不仅说他“借鉴”太多iPhone，而且讽刺鲁宾连眼镜、衣着、发型都在模仿自己。这就过分了。大家都是硅谷工程师，产品上有争议很常见，但是你乔布斯把头发扯进来，这难道不是人身攻击？！图：Andrew Rubin鲁宾吃了一肚子窝火。是的，他又想辞职了。是啊，你看。iPhone已经跑了一年多，广受好评，吃了乔布斯的下马威，Android士气极度低迷。另外，还有垄断PC操作系统的微软，布局移动端十年，此时在智能移动设备操作系统的市占率高达40％。算上诺基亚、三星……站在2008年正常人肯定看好苹果、微软、诺基亚、三星。Google一没做过手机，二没做过操作系统，怎么看都像是陪跑的。但是，佩奇好言相劝，鲁宾再坚持一下，有一个方向很有价值——开源。全世界开发者联合起来！鲁宾的工作绝不仅仅是宅在办公室撸代码，还要嘴甜腿勤到处跑，吃饭喝酒交朋友。2007年11月，Google联合84家硬件制造商、软件开发商及电信营运商，宣布对Android系统开源共建。举个小细节。为了把参与共建的开发者服务好，鲁宾发现，当时Java程序员居多，为此在框架上做了创新，把Android应用层和底层驱动层耦合起来，从而Java程序可以直接在上面独立开发，大大便利了程序员的工作。类似的例子比比皆是。最终，鲁宾是扬眉吐气的，把市场普遍看好的微软踹下马，凭Android和苹果iOS分庭抗礼。02 新的战役十几年过去，人类翻过智能手机的篇章，进入万物互联的时代。一个叫做OpenHarmony的开源分布式操作系统，踏上了舞台。当初，华为完成鸿蒙操作系统开发，但深知靠一己之力难以成事，于是分两次将基础能力代码捐赠给了开放原子开源基金会（OpenAtom Foundation）。后者在接受代码后选择开源。这款泛智能终端操作系统，取名OpenAtom OpenHarmony，简称OpenHarmony。所谓泛智能终端，意思是，这个操作系统不仅用在你常见的手机等消费电子上，而且要应用在家居、出行、运动健康、娱乐、办公、教育、社交购物、工业生产等等场景。优势是有自己的独特技术——华为贡献了鸿蒙独特的分布式技术，包括分布式软总线、分布式数据管理、分布式任务调度以及设备虚拟化能力。全部开源，开发者自取。但是，难点也很清晰。目标也太大了，涵盖个人消费、医疗、金融、能源、工业、交通……中国基础软件很薄弱。工程师是就业市场的香饽饽，首先选择的是非常赚钱的游戏、电商、数字广告，而需要坐十年冷板凳的基础软件，太难吸引到人才。这样一个大环境，任何大厂妄图关起门来，一家公司搞定覆盖面如此广的操作系统开发，压根办不到。开源，是实事求是的好选择，同时，也有显而易见的好处。操作系统的迁移成本极高。OpenHarmony要做千行百业的数字底座，不仅有手机，还有、工业、交通……手机的迁移成本倒是很小，比如我今天用iPhone，明天换成华为或者小米，很快就能上手。但是所有to B领域，比如工业生产、城市管理，一旦装了某个操作系统，绝对不愿意换。开源的好处就来了。每一次迭代，代码是公开的，所有人都能测试，发现漏洞解决漏洞。安全性，公开透明，逐渐深入人心。另外，开源就意味着很多企业参与开发，好比先谈几年恋爱再结婚，一路知根知底。等到时机成熟，换上OpenHarmony，一句话的事。不知不觉间OpenHarmony开源版本已经迭代到3．1 Release版。很多企业早就开始围绕OpenHarmony做商业化落地。评估操作系统发展得怎么样，专业上大概看这样几个方面：芯片适配、应用开发，以及开发工具。OpenHarmony目前已有11款主流芯片进主干的支持，基本满足了轻量、小型和标准系统基础功能开发。举个例子，中国家电。如何配网，家电业长期在Zigbee、蓝牙、WiFi之间徘徊和困恼。OpenHarmony一问世，高效配网、分布式等技术优势很明显，美的就参与了进来，两年多时间里已经做出来260款OpenHarmony家电产品，并于去年10月发布了基于OpenHarmony的美的操作系统1．0。截止目前，OpenHarmony已有1700＋社区代码贡献者，PR合入17189。3．1版本，除了系统能力提升，还有社区配套开发工具—— DevEco Studio 3．0  Beta3和DevEco Device Tool 3．0 Release。SDK也同步更新到了 Ohos＿sdk 3．1 Release（API Version 8）版本。03 使能作为一款崭新的操作系统，OpenHarmony已经完成了技术准备。万里长征走好了第一步，现在要走第二步——商业化。早在去年12月，润和已经发布了基于OpenHarmony打造的商业发行版HiHopeOS1．0；今年3月深开鸿也发布了面向金融行业的发行版KaihongOS。这些都是几家公司基于OpenHarmony独立开发的好产品。势头不错。为了让进程再快一点，共建单位华为参与进来做使能。2022年4月15日，首届OpenAtom OpenHarmony生态使能签约仪式成功举办，在OpenHarmony工作委员会的指导下，华为与奥思维、鸿湖万联、开鸿智谷、润和软件、深开鸿、统信软件等6家发行版厂商完成了首批OpenHarmony生态使能合作协议的签约。所谓“使能”，就是开放华为在操作系统开发领域的技术积累和丰富经验，帮助伙伴开发基于OpenHarmony的行业发行版，为社区贡献OpenHarmony装机量。OpenHarmony，消费端大家已经很熟悉，我的手机、平板、手表、划船机，以及试驾过的AITO汽车，利用分布式技术带来万物智联的体验，很新颖有趣。但消费电子只是开始，作为数字底座，OpenHarmony正在进军金融、出行、工业、智慧城市……那么怎么部署在摄像头、小商家的POS机等终端上部署，从而带来新的人机交互体验？要支持专业的人做专业的事，再算上华为在一旁做使能，开发进程开始加速。04 幸运不禁想起一桩往事。PC时代，也有一批中国企业家想做芯片和操作系统，产品都做了出来，但是，最后全输了，彻底消失。总结历史，最大的困难，不是技术，而是商业化——比如，方舟能集中力量搞一个芯片出来，但是接下来围绕这块芯片的软件移植、适配、二次开发、soc能力、集成……这个庞大的工程，需要千千万万企业一起参与。方舟们找了不少企业、院校一家家谈，很多企业、院校能看到当中的价值，但是苦于自己压根没技术实力——90年代一家公司没几个工程师，这仗打不了，于是作罢。在过去的20多年里，要感谢全社会重视教育，尊重科学，以至于每年这片土地诞生全球最多的工程师人才。还有20多年的市场经济，催生出那么多靠技术和创新成功的企业，以及雨后春笋般的创业者。因为这些，开源共建有了土壤。于是，我们才能谈开源的好处，第一安全放心，第二没有授权费成本低，第三参与共建可以给自己的产品带来差异化。只管踏踏实实干就行了，OpenHarmony是幸运的。       原文标题 : 开源，真有源头活水来吗？ | 衣公子

波澜壮阔的大海、四季常绿的气候，让广州花团锦簇，独特的历史沉淀和文化底蕴，更是打磨出完全不一样的城市特质。广州作为中国最重要的商业门户，除了经济发展繁荣向上，生活更是温暖舒适。如今，产业的快速发展和国家的大力支持，备受瞩目，也与广东的发展极其匹配，再加上无数弄潮儿齐聚，将会给广东的经济发展赋予更多的低碳化和可持续性。5月27日，2022广东发展论坛在广州·中国大酒店举行，光伏产业链不同领域的优秀专家，企业和从业者汇聚一堂，探讨广东省光伏行业的发展趋势，助力广东省光伏行业的发展。禾望电气受邀参加此次盛会，进行了专题的光伏分享，以及重磅展示110kW工商业产品，备受现场关注。广东作为全国第一经济大省，光照丰富，工业制造业发达，具有发展分布式的产业环境和屋顶资源。国家能源局公布的2021年建设运行数据显示，2021年广东省光伏发电新增装机2.26GW，分布式光伏新增装机1.27GW，占比超过56%；截止2021年底，广东省光伏发电累计装机10.20GW，其中分布式光伏累计装机5.12GW，占比超过50%；分布式光伏已成为广东光伏发展的主力军。众所周知，分布式光伏具有短平快的特点，即建设快，周期短、手续简单，因此电站业主或投资者非常注重其发电量所带来的收益。基于此，在会议现场，禾望重点介绍了大电流解决方案如何更好助力分布式光伏的发展，其针对户用、工商业、电站型等不同的分布式光伏场景所面临的挑战，提供了更具竞争力的产品和服务，从而保障业主或投资者的最佳收益。禾望的光伏不仅产品系列齐全，包含5kW—8kW/220V单相户用、8kW—50kW/400V三相户用、60kW—110kW/400V商用大功率、50kW—225kW中高压电站型等，完美匹配各种场景。而且产品性能优异，具有智能风冷散热、45度不降额，支持容配比优化设计、降低LCOE，支持大电流组件（最大20A），全方位监控系统，支持第三方监控平台接入等特点，备受客户肯定。截止目前，禾望分布式光伏解决方案已在惠州、肇庆、广州、东莞、梅州等地成功应用，为广东分布式光伏发展提供高效稳定的逆变器产品与优质快捷的售后服务。作为全球光伏20强蝉联前十的企业，禾望光伏一直以创新的技术和独特的产品，构建分布式光伏场景解决方案，为世界创造清洁高效的绿色能源，让人们享受更加温暖美好的生活，为此，我们一直探索不止。

2021年12月，墨天轮社区发布了由CCF数据库专委会、清华大学和墨天轮社区共同撰写的《数据库系统的分类和评测研究》，这个报告的初衷是希望通过对数据库产品的分类、评测、发展等方向的研究，为行业提供参考和促进。以下是对报告的摘要分享一、数据库分类概要数据库系统是按照特定数据结构组织，存储和管理数据的基础软件。对数据库的分类有很多角度，同一个数据库，分类角度不同，会被归类为不同的类型。下面从常用的角度来对数据库进行分类。数据模型:关系型和非关系型;架构模型:单机、集中式、分布式;集中式分为一主多备、一写多读、多写;分布式分为分布式中间件和分布式数据库。部署模型:本地化部署(on-premises)和云部署(cloud);二、数据模型分类法按数据模型分类，数据库分为关系型数据库(SQL)和非关系型数据库(NoSQL)。 关系型数据库以关系代数为基础，按照二维数据表格为方式，对数据表格之间的关系进行抽象和建模。按业务负载特征进行分类，关系型数据库又可分为交易型数据库(OLTP)、分析型数据库(OLAP)和混合负载数据库(HTAP)。 非关系型数据库种类繁多，根据数据的组织形式和结构特点可以分为: 键值数据库、文档数据库、列簇式数据库、图数据库、时序数据库、空间数据库。三、HTAP 混合负载数据库HTAP是指能同时提供OLTP和OLAP的混合关系型数据库，称之为HTAP (Hybrid transaction and analysis processing)。广义的HTAP数据库，能够在关系数据模型上进行OLTP时具有强一致性保证，并且融合了分布式能力从而同时具有高扩展性 。狭义的HTAP数据库指的是采用行列混存或者行列转化技术来同时支持事务能力和分析功能。 以Oracle为例，最初的设计面向OLTP服务，而随着OLAP日趋发展，开始同时支持OLAP服务，所以成为了广义上的HTAP数据库。四、分布式数据库分布式数据库是分布在计算机网络上，逻辑上相互关联的数据库。分布式数据库可以分散在多个位置，不同位置的计算机中存有数据库管理系统的一份完整拷贝副本或部分拷贝副本，通过网络互相连接，共同组成一个逻辑上集中、物理上分散的大型数据库。分布式(with data sharding):将数据从物理上分割，并分配给多台服务器(或多个实例)，例如通过哈希进行数据划分，或者通过范围进行划分，或者通过列表进行划分(例如北京、上海数据分配到一个节点)。每台服务器可以独立工作，具备共同的schema。分布式中间件:基于单机数据库、分库分表中间件划分数据，中间件实现数据的划分、查询下发、结果收集，进而实现数据库的可扩展性。适合数据能够完美分片到各个节点，节点间没有数据交互的场景。分布式数据库:对数据进行分片(sharding)，通过全局事务处理模块和分布式查询处理模块支持原生支持分布式事务和全局复杂查询。五、分布式OLTP数据库为了能够完全扩展读写服务，支持大规模的OLTP应用，分布式中间件和分布式数据库应用而生。目前有两种方案来解决数据库的可扩展问题:分布式中间件：在多个传统单点数据库系统上的中间层解决方案，通过将数据分拆到不同的数据库节点上，利用中间件来管理和访问各个数据库中的数据。中间件负责分发查询和收集结果，但很难满足数据库的性能和分布式事务的一致性。而且它通常需要用户参与到数据分拆和节点管理过程中。分布式数据库：通过数据分片的方式，每个节点来管理一个数据分片，可以通过增加分片来支撑数据的增长，不仅可以提升数据库的可扩展性，而且能够为客户带来更多业务价值。分布式数据库的优点是将复杂的分布式事务处理(GTM–Global Transaction Manager)和分布式查询优化(Distributed Optimizer)交给数据库，保证数据的一致性和查询高效性。分布式关系数据库，需要对数据库SQL引擎、执行引擎、存储引擎原生技术开发，通过计算节点状态解耦、多副本、高精度时钟等技术解决高可用问题。分布式的事务管理机制, 不存在中心化的事务管理模块, 实现了真正的分布式事务。分布式数据库在数据可靠性、副本同步、查询性能、数据一致性、服务可用性等方面都优于分布式中间件，在分布式事务处理、分布式查询优化、智能化数据管理、 全密态数据管理等方面都有创新。六、数据库竞争力维度及其评测指标随着数据库应用市场蓬勃发展，需求和产品多样化，用户选择合适的数据库变得越来越难。如何能够客观全面评价数据库产品，成为研发和使用数据库的重要内容之一。 通过以下六个维度，可以比较数据库拥有的竞争力。高性能：主要评价数据库的性能，例如QPS(query per second)、TPS(transactions per second)，以及TPC标准测试中的tpmC。高可用：主要评价数据库的可用性和可靠性，例如Recovery Point Objective (RPO)、Recovery Time Objective (RTO) 。扩展性：主要评价数据库的扩展性，例如扩展比。混合负载:主要评价数据库支持各种负载的能力，例如事务处理和复杂分析。安全性:主要评价数据库的安全性，包括身份认证、权限控制、审计、查询注入、自身安 全漏洞、数据安全;智能化:主要评价数据库的易用性、自动化和智能化，包括数据库的自动升级、备份、恢 复，以及数据库的自调优(参数自调优、索引/视图自推荐、慢SQL诊断等)、自监控、 自恢复等。七、数据库的比较与选择随着数据库领域的蓬勃发展，当前数据库产品种类繁多，各具优势。选择合适的数据库产品，变得越来越重要。综合上述数据库分类方法，以及相关介绍，我们认为，可以从数据模型、数据量和计算资源情况、业务需求等方面考量，选择合适的数据库产品，如图所示：来源：https://www.modb.pro/doc/52857

物联网中多现象观测的压缩感知通信一体化方法韩成成, 陈力, 王卫东中国科学技术大学，安徽 合肥 230022摘要观测多现象的大规模物联网采用正交多址接入（OMA, orthogonal multiple access）机制传输分布式节点的观测数据，会造成极大的传输时延，导致数据失去时效性。针对这一问题，研究了基于压缩感知（CS, compressed sensing）通信一体化的数据传输方法，该方法将物联网中分布式节点按照观测现象分为多节点簇，不同节点簇在不同分配时隙内传输观测数据。具体来说，在分配的数据传输时隙内，各簇节点利用随机信道作为CS观测矩阵，以相干传输方式将观测数据传至融合中心（FC, fusion center）形成CS观测值，然后FC利用CS算法从CS观测值中恢复观测数据。通过推导可达速率，发现可达性能与节点簇时隙分配密切相关。为实现最优性能，分别在最大总速率和保证观测公平性两个目标下，研究了物联网中节点簇时隙分配问题。最后，通过数值仿真进行性能验证和分析，仿真结果表明，与现有OMA数据传输机制相比，压缩感知通信一体化方法明显提高了物联网的观测数据速率。关键词： 大规模物联网 ; 多现象观测 ; 压缩感知通信一体化1 引言在新兴无线通信技术的推动下，物联网应用得到了快速发展，为人类社会生产活动提供了物质和技术支持[1,2,3]。典型物联网的网络边缘部署了大量分布式节点，物联网依靠这些节点监测人们生活和工作中需要关注的物理现象，其中分布式节点需要对现象进行数据采集并将观测数据传送至FC， FC利用收集的观测数据进行数据分析和判断，为用户提供高质量服务[4]。未来物联网的分布式节点部署规模预计将达百万级[5]，如此规模庞大的节点将产生海量的观测数据，如何满足其数据传输需求是物联网即将面临的巨大挑战[6]。一般而言，基于 OMA 数据传输机制的通信网络能够负载的数据传输量与其所获取的通信资源（时间、频带、射频链路）成正比。在大规模物联网中，频谱资源有限且 FC 射频链路数远少于分布式节点数，若采用OMA机制传输海量的分布式节点观测数据，必将造成极大的数据传输时延，导致数据失去时效性，进而影响物联网应用的服务质量。为应对上述挑战，利用物联网中分布式节点观测数据在时间和空间上的相关性[7]来加快数据速率或降低待传输数据量是较有效的策略，其中最有可行性的方案是利用数据相关性找到某一变换域，观测数据可通过此变换域的线性映射变为具有稀疏性特征的数据[8,9,10]。在此基础上，通过引入CS技术， FC只需要收集少量CS观测值，就可以准确恢复原始观测数据。利用观测数据稀疏性，在分布式节点处采用CS技术来减少待发送数据量的方法已经得到广泛研究[11-15]。为验证CS技术在物联网中应用的可行性，研究人员建立了物联网系统的能量开销模型，对物联网边缘处的分布式节点的能量消耗做了定量分析，分析结果表明，引入 CS 能够提高分布式节点的能量利用效率[11]。在上述研究基础上，提出了应用 CS 技术的通信网络统一框架，其要求每个分布式节点首先与 FC 通信生成一个随机基底作为 CS观测矩阵，再将其观测数据投影到感知矩阵上得到CS观测值，最后将CS观测值传输至FC来恢复原始观测数据[12]。在不引入复杂传输控制的前提下，上述 CS 通信网络统一框架被扩展至大规模物联网，其中路由路径上的节点将 CS 编码数据以加权和的方式生成CS观测值并传输至FC[13]。大规模物联网的路由路径和观测矩阵需要联合设计，保证恢复数据质量的同时最小化能量开销，这延长了物联网分布式节点的寿命[14]。在CS观测值的传输过程中，由于衰落信道的影响可能导致部分数据无法正常传输，这将会影响物联网数据恢复性能。考虑路由路径中可能存在断链，研究了断链对 CS 物联网数据恢复性能的影响[15]。在上述应用CS的物联网中，分布式节点需要在每一次数据传输前与 FC 通信来生成观测矩阵，这增加了节点的通信成本，影响了网络性能。为避免分布式节点生成观测矩阵，研究人员提出了压缩感知通信一体化方法，其利用节点与 FC之间的随机信道实现 CS 观测[16-19]。在理想信道假设下，利用压缩感知通信一体化方法可以在 FC 处实现分布式节点观测数据的 CS 观测，其中各节点需要将观测数据与 CS 感知因子相乘进行编码，然后向 FC 并行传输已编码数据[16]。对压缩感知通信一体化物联网性能进行进一步研究，其研究结果揭示了物联网的功耗、失真度、时延与节点数的关系[17-18]。此外，为进一步改进压缩感知通信一体化方法，研究人员又提出了新的机制，其中分布式节点利用随机性信道作为观测矩阵，避免了分布式节点对观测数据的CS编码[19]。在上述压缩感知通信一体化物联网中，分布式节点只观测单一物理现象。为避免观测不同现象的物联网之间相互干扰，观测多现象物联网成为未来的发展趋势。为提升观测多现象物联网的性能，本文提出一种可以观测多现象的压缩感知通信一体化方法，其将分布式节点划分成多簇，每簇节点独立观测某一现象，并在所分配时隙内以相干传输方式将观测数据发送至 FC 来实现 CS 观测和恢复。为评估所提的压缩感知通信一体化物联网的性能，推导了观测数据速率，并将其与基于OMA机制物联网进行比较。比较结果显示，压缩感知通信一体化物联网的观测数据速率远大于基于OMA机制物联网的观测数据速率。此外，在应用观测多现象的压缩感知通信一体化方法物联网中，如何为不同节点簇分配时间资源以实现物联网的最优性能，是需要研究的重点。由于物联网对多现象的观测有不同的目标，分别在追求网络速率最大化和考虑不同现象观测公平性两种情况下，研究了关于物联网时隙分配的优化问题，并给出最优解。最后，给出了压缩感知通信一体化物联网的性能仿真，其结果验证了所提方法的优越性能。2 结束语本文研究了观测多现象的大规模物联网的分布式节点数据收集问题，设计了利用压缩感知通信一体化方法实现分布式节点观测数据实时收集机制。为评估压缩感知通信一体化物联网性能，推导了物联网观测的各个现象的 CS 观测速率和对应的观测数据速率。通过将观测数据速率与基于OMA机制物联网的观测数据速率相比较，证明了压缩感知通信一体化物联网的优越性能。为了实现最优性能，分别在最大总速率和保证观测公平性两个目标下，通过研究各节点簇时隙分配的优化问题，给出了可以实现物联网最优性能的时隙分配方案。最后通过蒙特卡洛仿真验证了理论推导和性能优化的正确性，并且进一步讨论了各因素对物联网观测性能的影响。本文所提机制基本解决了观测多现象的物联网数据收集问题，但是未利用各物理现象观测值的联合稀疏性，如何利用这种联合稀疏性来进一步提升性能值得进一步研究。此外，随着感知技术的进步，可以同时观测多种现象的多功能物联网节点已经出现，在这种情景下，分布式节点如何联合设计观测和编码机制以协调观测多物理现象也值得研究。The authors have declared that no competing interests exist.作者已声明无竞争性利益关系。3 原文链接http://www.infocomm-journal.com/wlw/article/2021/2096-3750/2096-3750-5-1-00053.shtml

【功能模块】MindSpore提供的Bert训练脚本(https://gitee.com/mindspore/models/tree/master/official/nlp/bert)GPU分布式训练MindSpore的Profiler工具【操作步骤&问题现象】1、在单机四卡环境下，使用官方提供的脚本进行训练，参数配置未改变2、在run_pretrain.py文件中调用Profiler工具记录性能数据（代码中第24，25行）3、发现训练过程卡死不动，程序未报错退出，此时GPU利用率为0，CPU利用率很高4、相关环境为python 3.8.13, mindspore 1.7.0, mindinsight 1.7.0cuda 11.1, nccl 2.7.8, cudnn 8.0.4单机四卡训练【截图信息】卡死时状态【日志信息】（可选，上传日志内容或者附件）

1.大数据的背景背景：2010年物联网迅速发展，大量底层数据。大数据的发展历程时间    阶段上世纪90年代至上世纪末期    萌芽阶段本世纪前十年    成熟期2010年以后    大规模应用期2.大数据的概念和影响特性“4V”数据分结构化和结构化数据（非结构化较多）及时性，秒级查询价值密度低，商业价值高新的模式（未来可能以数据为驱动）        全样而非抽样（以前是抽样数据分析，现在可以全面分析）        相关而非因果3.大数据的应用        影视作品的投拍有风险（大数据投拍——美国《纸牌屋》）        传统流感预测方式（用户数据）        ……4.大数据的关键技术数据存储管理数据处理与分析        分布式存储        分布式处理计算模式        批处理mapreduce、spark        流计算（实时性）        图计算Google Pregel        查询分析计算大数据计算模式    解决问题    代表产品批处理计算    大规模数据批量处理    MapReduce、Spark…… 流计算    针对流数据的实时计算    storm、s4、Flume、Streams、Puma、DStream、Super Mario、银河流数据处理平台……图计算    针对大规模图结构数据的处理    Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrd……查询分析计算    大规模数据的存储管理和查询分析    Dremel、Hive、Clasandra、lmpala……大数据、云计算、物联网的关系5.云计算云计算：解决两大问题：分布式存储和分布式处理特点：虚拟化、多用户通过网络服务提供廉价的服务公有云、私有云、混合云IaaS：基础设施即服务PaaS：平台即服务SaaS：软件即服务；salesforce虚拟化、多用户、分布式存储、分布式储存HadoopLinux虚拟机Windows硬件云计算的数据中心类似你丢百度云，在百度的各地数据中心（一个30/50亿）。数据中心耗能非常大，一天30万电费55%空调制冷……45%设备45%设备的70%内部风扇……30%cpu30%cpu的90%闲置……10%计算政务云……6.物联网应用层    智能应用处理层    数据处理平台网络层    各类网络，信息传输通道作用感知层    摄像头，传感器实例：智能公交……关键技术：识别技术、感知技术识别：给物体贴标签，条形码，二维码（矩阵）RFID：切割磁线产生电流……大数据前身云计算云计算为大数据提供技术支持大数据为云计算提供用武之地云计算为物联网提供海量数据存储能力物联网为云计算技术提供广阔的应用空间物联网是大数据的重要来源大数据技术为物联网数据分析提供支撑第二章Hadoop1.Hadoop简介Apache的开源项目，hadoop是java语言开发的，具有良好跨平台的特性。hadoop具有高扩展性，多副本机制，低成本机器集群，各种低端机，构建集群，应用于linux平台，支持多种语言开发应用现状：facebook……数据源+HDFS分布式文件存储+分析MR（Hive、Pig）、查询Hbase（Solr、Redis）、挖掘Mahouthadoop的版本阿帕奇版本版本1.02.0 YARN  HDFS缺陷：扩展性差，NN Federation解决、HAclodera、HortonworksMapR、星环……很多版本如何选择：是否开源、是否免费、是否有实践检验、是否有社区支持、性能……Hadoop生态圈hadoop的项目结构框架名称    功能HDFS    分布式文件系统YARN    资源管理和框架调度MapReduce    离线计算（基于磁盘）Tez    DAG计算（有向无环图）Spark    内存计算Hive    数据仓库Pig    流数据处理，提供类似于SQL的查询语言Pig Latin（轻量化）Oozie    作业流调度系统Zookeeper    分布式功能协调调度HBASE    非关系型分布式数据库,实时应用Flume    日志收集Sqoop    数据转换（如：SQL数据转换到Hadoop平台；反之亦然），HDFS、HBase、Hive数据互导Ambari    安装部署工具

大家好！我是酷哥，数据库相关资讯，带您速览，欢迎大家阅读。 ------------------------------------------------ **本期精选** ------------------------------------------------ - 分布式数据库的高可用性简史 - 沙利文发布《2021年中国数据库市场报告》：中国分布式数据库2021专利占全球76% - 《2022分布式存储市场调研报告》发布，中国市场潜力巨大 - 易鲸捷攻克分布式数据库技术难题，打造中国金融核心交易数据库标杆 - 《2022 MongoDB 数据与创新报告》发布：复杂基础架构阻碍企业创新，数据成最大痛点 - 暴露数据库数量创新高，中美占比最多，Redis 排第一 - 我们距离DataOps还有多远？ ------------------------------------------------ **资讯摘要** ------------------------------------------------ - 分布式数据库的高可用性简史 **摘要：** 电脑可以没日没夜地运行，但早先的网站却做不到24*7小时的运营。现在看来我们都不可思议。然而，在互联网出现之前，24*7的高可用性这个提法并不存在。 那时我们对可用性是有期待，但我们却压根不会认为这是我们有权要求获得的东西。我们只在需要时使用计算机；更多的时候我们其实本来就不太有机会使用它，自然也很少会让计算机一直开着以便它可以随时响应我们。随着互联网的发展，那些以前在当地时间凌晨 3 点不常见的请求变得越来越多，也让这个时间段在全球各地都变成了黄金营业时间，因此确保计算机能够服务这些请求变得非常重要。 然而，许多系统仅依靠一台计算机来处理这些请求——单点故障——我们都知道这是个很糟糕的事实。为了保持正常运行，我们需要在多台可以满足我们需求的计算机之间分配负载。然而，分布式计算有着非常明显的优势：特别是同步和容忍系统内的部分故障（容错）。每一代工程师都在迭代这些解决方案，以满足这个时代的需求。 数据库领域是如何引入分布式的，这件事很多人并不清楚前因后果，因为这本身就是一个比其他领域发展缓慢得多的难题。当然，软件在本地数据库中会记录一些分布式计算的结果，但数据库本身的状态只能保存在单台机器上。为什么？因为跨机器的状态复制是非常困难的。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187354](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187354) - 沙利文发布《2021年中国数据库市场报告》：中国分布式数据库2021专利占全球76% **摘要：** 5月10日，弗若斯特沙利文（Frost & Sullivan，简称“沙利文”）联合头豹研究院发布《2021年中国分布式数据库市场报告》。报告显示，在中国市场，分布式数据库发展正处于“爆发期”。从专利申请的数据角度出发，中国的分布式数据库相关专利申请量从2012年的全球占比22%爬升至2021年的76%，中国已经成为了全球分布式数据库的技术创新中心。 通过对2021年数据库市场进行持续跟踪和调研，沙利文指出，数据库作为大多数信息系统的基础设施，向下发挥硬件算力，向上承接上层应用，各式各样的数据库产品分别满足不同的业务需求。数据库的速度、易用性、稳定性、扩展性、成本都对企业的基础业务与增长弹性至关重要。 对于数据库行业的发展趋势，沙利文认为，在云上建设数据库服务，设计出以基础云先行，全线适应云特点的云原生数据库尤为重要。腾讯云自主研发了新一代高性能、高可用数据库TDSQL-C，100%兼容MySQL和PostgreSQL，实现超百万级QPS的吞吐能力。 展望未来，数据库的发展动力依然来自数据存储规模和性能要求，以及硬件的发展，未来的数据库技术还将满足AI对数据管理的需求。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187420](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187420) - 《2022分布式存储市场调研报告》发布，中国市场潜力巨大 **摘要：** 日前，百易存储研究院、中国计算机学会信息存储专委会、中国计算机行业协会信息存储与安全专委会、DOIT 正式发布《2022分布式存储市场调研报告》。报告指出，中国分布式存储市场规模虽然无法准确回答，但市场发展的趋势是明确和清晰的，未来市场潜力巨大。 事实上，分布式存储发展至今，市场上并没有一个能够被广泛接受并引用的定义。百易存储研究院认为用传统存储、传统阵列或者传统磁盘阵列的表述更为便于理解。 对于中国分布式存储市场规模有多大？报告指出，这其实也是一个很难准确回答的问题。 “一来分布式存储市场参与的厂商很多，其中很多厂商不是上市企业，没有办法获得销售数据；二来分布式存储没有一个市场可以普遍接纳的定义和分类，会导致数据统计口径混乱，例如分布式存储是否包括去中心化存储、是否包括超融合、是否包括云存储、内涵与界定的不同，市场规模自然也不一样。” **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187418](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187418) - 易鲸捷攻克分布式数据库技术难题，打造中国金融核心交易数据库标杆 **摘要：** 近日，从贵州易鲸捷信息技术有限公司(以下简称“贵州易鲸捷”)官网获悉，该公司于近日获得了由**商标专利局授权的关于“混合乐观锁和悲观锁的数据库事务并发控制方法”的发明专利，此专利技术由贵州易鲸捷中国团队自主研发，并获得了国际权威机构认可。 据悉，现有数据库技术中，悲观锁和乐观锁是互斥的两种并发控制技术，采用了悲观锁实现的数据库，便不能同时使用乐观锁机制，反之亦然。而此次贵州易鲸捷获得的这项专利，是基于乐观锁机制，融合了悲观锁功能，很大程度上解决了各种场景下并发控制的性能问题。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187365 ](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187365) - 《2022 MongoDB 数据与创新报告》发布：复杂基础架构阻碍企业创新，数据成最大痛点 **摘要：** 近日，通用数据库平台 MongoDB 发布了《2022 MongoDB 数据与创新报告》，该调查报告是一项针对亚太地区 2,000 余名（包括中国 400 余名）开发者、IT 决策者等专业技术人士的详尽调研，展示了创新的重要性，以及阻碍创新的隐性负担。 该调查报告得出的结论主要包括：创新的首要任务是提高内部效率/生产力；造成数据复杂性的最大因素是开发新产品或新功能的压力；最大的技术挑战是处理不同格式的海量数据。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187503](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187503) - 暴露数据库数量创新高，中美占比最多，Redis 排第一 **摘要：** BleepingComputer 网站消息，威胁**和研究公司 Group-IB 共享的一份报告中显示，公开暴露在互联网上的数据库数量近期有所增加 ，从 2021 年的 308000 个持续增长，截至 2022 年第一季度，暴露的数据库峰值数量已达 91200 个，创造了历史记录。 在大多数情况下，数据库被公开至网络是由于配置错误的原因造成，黑客常常使用可从开放网络访问的搜索引擎索引系统来寻找这些数据库，以窃取内容或进行金融勒索。 Group-IB 的 Bobak 指出，大多数困扰数据库安全的问题都可以轻松预防，如下特定关键措施：如无必要，确保数据库不公开；使数据库管理系统保持最新版本，以减少可利用的缺陷；使用强用户身份验证；为所有存储的信息部署强大的数据加密协议；使用采用数据包过滤器、数据包检查和代理的数据库和 Web 应用程序防火墙；使用实时数据库监控；避免使用将数据库暴露给恶意扫描的默认网络端口；尽可能遵循服务器分段做法；以加密形式对数据进行离线备份。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187619](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187619) - 我们距离DataOps还有多远？ **摘要：** 2022年，中国信通院联合各行业组织机构对DataOps定义为一种由价值运营、工具、组织管理和安全加持下的最佳实践，并突出了一体化、敏捷化、精益化、自动化、智能化和价值显性化的特征。 从实施上来看，尽管Gartner的预测与实际发展变化难以完全契合，但从2018~2021年连续的报告上来看，DataOps长期处于“萌芽期”的位置，这也一定程度上反映了国内外组织对DataOps的实践还依然处于摸索尝试的阶段，鲜有组织明确的宣传自己的“成功”案例。 2022年4月，中国信通院联合工商银行、招商银行、农业银行、平安银行、浦发银行、南京银行、阿里云、腾讯云、新炬网络、深算院等20余家单位对DataOps的定义、标准框架、能力特征等细节进行了深入的交流和探讨并达成了一致。未来我们将结合中国的数据发展情况，打造一套适合我国数据行业发展的DataOps体系。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187254](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=187254) [上一期：【技术之声】第十八期（20220509）数据库资讯精选](https://bbs.huaweicloud.com/forum/thread-187320-1-1.html) *声明：文章源于第三方公开的信息，如果存在侵权或信息不实时，请及时联系处理。* 整理者：酷哥

使用系统：CPU平台Windows环境版本号：1.6.1网络调试：这里使用PyNative的方式进行调试也称动态图模式，将神经网络中的各个算子逐一下发执行，方便用户编写和调试神经网络模型。PyNative模式支持执行单算子、普通函数和网络，以及单独求梯度的操作。在PyNative模式下，可以方便地设置断点，获取网络执行的中间结果。设置模式context.set_context(mode=context.PYNATIVE_MODE)执行单算子import numpy as np import mindspore.ops as ops from mindspore import context, Tensor context.set_context(mode=context.PYNATIVE_MODE, device_target="CPU") x = Tensor(np.ones([1, 3, 5, 5]).astype(np.float32)) y = Tensor(np.ones([1, 3, 5, 5]).astype(np.float32)) z = ops.add(x, y) print(z.asnumpy())执行函数import numpy as np from mindspore import context, Tensor import mindspore.ops as ops context.set_context(mode=context.PYNATIVE_MODE, device_target="CPU") def add_func(x, y): z = ops.add(x, y) z = ops.add(z, x) return z x = Tensor(np.ones([3, 3], dtype=np.float32)) y = Tensor(np.ones([3, 3], dtype=np.float32)) output = add_func(x, y) print(output.asnumpy())执行网络import numpy as np import mindspore.nn as nn import mindspore.ops as ops from mindspore import context, Tensor context.set_context(mode=context.PYNATIVE_MODE, device_target="CPU") class Net(nn.Cell): def __init__(self): super(Net, self).__init__() self.mul = ops.Mul() def construct(self, x, y): return self.mul(x, y) x = Tensor(np.array([1.0, 2.0, 3.0]).astype(np.float32)) y = Tensor(np.array([4.0, 5.0, 6.0]).astype(np.float32)) net = Net() print(net(x, y))构建网络import mindspore.nn as nn from mindspore.common.initializer import Normal class LeNet5(nn.Cell): def __init__(self, num_class=10, num_channel=1, include_top=True): super(LeNet5, self).__init__() self.conv1 = nn.Conv2d(num_channel, 6, 5, pad_mode='valid') self.conv2 = nn.Conv2d(6, 16, 5, pad_mode='valid') self.relu = nn.ReLU() self.max_pool2d = nn.MaxPool2d(kernel_size=2, stride=2) self.include_top = include_top if self.include_top: self.flatten = nn.Flatten() self.fc1 = nn.Dense(16 * 5 * 5, 120, weight_init=Normal(0.02)) self.fc2 = nn.Dense(120, 84, weight_init=Normal(0.02)) self.fc3 = nn.Dense(84, num_class, weight_init=Normal(0.02)) def construct(self, x): x = self.conv1(x) x = self.relu(x) x = self.max_pool2d(x) x = self.conv2(x) x = self.relu(x) x = self.max_pool2d(x) if not self.include_top: return x x = self.flatten(x) x = self.relu(self.fc1(x)) x = self.relu(self.fc2(x)) x = self.fc3(x) return x设置Loss函数及优化器net_loss = nn.SoftmaxCrossEntropyWithLogits(sparse=True, reduction="mean") net_opt = nn.Momentum(network.trainable_params(), config.lr, config.momentum)保存模型参数config_ck = CheckpointConfig(save_checkpoint_steps=config.save_checkpoint_steps, keep_checkpoint_max=config.keep_checkpoint_max) ckpoint_cb = ModelCheckpoint(prefix="checkpoint_lenet", directory=config.ckpt_path, config=config_ck)训练模型完整的运行代码可以到ModelZoo下载lenet，在train.py中修改为context.set_context(mode=context.PYNATIVE_MODE, device_target=config.device_target)。分布式并行训练完整的代码如下：代码门邮箱lricxanxus66@163.com

本文分享自华为云社区《[【新作】分布式系统韧性架构压舱石OpenChaos](https://blog.csdn.net/devcloud/article/details/124681564?spm=1001.2014.3001.5501)》，作者： 华为云开发者社区。 # 背景 随着Serverless，微服务（含服务网格）与越来越多的容器化架构应用的出现，我们构建、交付与运维系统的方式变的越发复杂。这种复杂性增加了系统状态可观测性的难度。在已有的生产环境中，我们有不同的方式来获取信息，增强系统的可观测性。 起始的时候，可能是非常简单地给定一个特定的条件，产生一个特定的指标输出。进一步的，使用结构化和关联日志，或进行分布式跟踪，引入事件总线如Apache EventMesh、EventGrid等。随着Codeless组合式应用快速发展，Serverless设计理念也在不断被一些分布式系统设计者逐步接受。免运维，按需付费，极致弹性，多租共池等等无不在逼迫我们重新审视老式架构的合理性，催生新架构的不断演进。 融合架构是这几年被提得最多的一个词，以往支撑在线/离线系统的复杂架构不断被融合，通过可分可合的设计与部署方式去适配各种业务场景。在这样的背景下，我们开始认真审视并思考，是否有一种更为现代化的工具，能够帮助发现并应对分布式云这种底座对架构设计以及上层应用带来的诸如可靠，安全，弹性等一系列韧性架构的挑战。 混沌工程思想给我们带来了一定程度的启发。Netflix最初为了搬迁基础设施上云创建了 Chaos Monkey，由此拉开了混沌工程学的序幕。再到后来，CNCF成立了专门的兴趣小组，希望能够推动这一领域的标准诞生。OpenChaos创始团队早期也和这些社区的先行者进行过多轮交流。可惜的是，2019年随着该兴趣组并入App Delivery SIG后再无太大动静。 这几年在国家政策大力引导下，企业的数字化升级不断加快，越来越多的CIO、CTO甚至包括CEO开始重视并投入到混沌工程实践中。国内由中国信通院牵头的混沌工程实验室也在如火如荼地推动该领域的飞速发展，从全链路压测，混沌故障引入到催生未来架构变革的多云多活参考架构的制定。这些无不昭示着这一产业在飞速发展。 >根据国内外科技媒体调研统计，到2025年，80%的组织将实施混沌工程实践。通过全链路压测，混沌故障，以及多云多活架构等策略的整体导入，可以将意外停机时间减少50%，实现真正意义上的秒级RTO/RPO。让应用、业务创新更加专注。 # 良药虽好，但也有局限 混沌工程的最基本流程是在生产环境小规模定期自动化执行试验，为系统随机地注入故障，来观察 “系统边界”。它主要关注系统面对故障所展现出的容错能力，可靠性。目前市面上绝大部分混沌工程工具，倾向于构造以黑盒随机为主的故障类型，对底层基础设施（硬件，操作系统，数据库与中间件）理解与洞察较少。缺少统一的框架标准、成熟的specific度量指标。同时，分析反馈较弱，无法给出全面彻底的诊断建议，尤其通过强化学习，生成式AI等能力可以进一步解决目前随机故障注入，进行自愈风险分析与优化建议。 面向有更多复杂特性的分布式系统，仅通过观察系统应对故障的表现是有局限的，并且依赖于观察是极其主观的，很难形成统一的评测标准，也较难针对表现分析系统缺陷。系统的可观测性，不仅需要模型的全面覆盖，还需要完备的监测系统，并提供全面的结果报告，甚至智能预测，来指导架构提升自身的韧性能力。分布式领域资深技术专家，开源顶级项目Apache RocketMQ，OpenMessaging最初的创始人冯嘉曾表示：“云原生分布式架构的演进正在朝着组装式架构，韧性架构进一步发展”。在这样的背景下，他提出并带领团队创造了OpenChaos这一新兴项目。 # OpenChaos 需要解决的本质问题 韧性架构，覆盖高靠性、安全、弹性、不可变基础设施等特性。实现真正的韧性架构毫无疑问是现代分布式系统的演进方向。针对分布式系统韧性能力，OpenChaos借助混沌工程思想，对其定义进行延伸扩展。针对一些分布式系统特有属性，如Pub/Sub系统的投递语义与推送效率，调度编排系统的精准调度、弹性伸缩与冷启效率，streaming系统的流批实时性、反压效率，检索系统的查全率与查准率，分布式系统共识组件的一致性等，设置专用的检测模型。OpenChaos 内置可扩展的模型支持，以便验证在大规模数据请求以及各种故障冲击下的韧性表现，并为架构演进提供进一步优化建议。 # 架构与案例分析  图1 **整体架构** OpenChaos的工作原理是这样的：控制面对整个流程进行控制，负责使集群节点组成一个待测试的分布式集群。并会根据需要测试的分布式基础设施找到对应的Driver组件并载入，根据设置的并发数建立相应个数的客户端。控制节点根据 Model 组件定义的执行流程控制客户端对集群进行操作。演练过程中，Detection Model 会对集群节点根据不同的观测特性引入对应的事件。Metrics 模块会在实验中监测被测集群的表现。演练结束后，Checker组件会对实验中的业务和非业务数据进行自动化分析，得出测试结果并输出可视化图表。 如图1所示，OpenChaos的整体架构可以分为管理层，执行层与被测组件层。 最上层为管理层，它包含了用户界面和控制器（Control），控制器负责调度引擎层的组件进行工作。最下层为被测组件，它可以是自部署的分布式系统集群，也可以是容器或者云厂商承载的分布式系统。 中间层是执行层，也是OpenChaos强大能力的秘密所在。模型（Model）是执行的流程的基本单元，它定义了对分布式系统进行操作的基本形式。控制器在模型中载入需要测试的分布式系统的驱动（Driver），并根据配置的并发数创建相应的客户端（Client），最终使用客户端对分布式系统执行操作。检测模型（Detection Model）会根据用户关注的不同观测特性引入对应的事件，比如引入故障或者系统的扩缩容。Metrics 模块会在实验中监测被测集群的表现。演练结束后，度量模型（Measurement Model）组件会对实验中的业务和非业务数据进行自动化分析，得出测试结果并输出可视化图表。 # 检测模型与度量模型 **检测模型** 传统混沌工程主要关注系统的稳定性，它们的普遍实现是通过黑盒的故障注入来模拟一些常见的通用故障。OpenChaos中的检测模型关注更高维度的属性——韧性，它包含可靠性，还包含如弹性、安全性等特性的检测模型。相较于传统混沌工程，OpenChaos不仅支持普遍的黑盒故障注入，还可恶意针对分布式基础软件如消息或缓存等的主备倒换，网络分区导致的脑裂等问题做定制检测，以观察他们在这种情况下的表现。 **度量模型** 由于分布式系统的复杂性，对于分布式系统韧性的观测更需要一个简单直观的分析报告，来让人更方便地发现分布式系统可能存在的缺陷和不足。度量模型会对系统的表现进行分析，以统一的标准化计算输出结果与图表，方便使用者进行对比分析。以消息系统的稳定性评估为例，度量模型会根据实验中故障注入情况与系统表现，计算出系统的 RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）。输出集群的处理语义情况，如是否符合 at least once 或 exactly once；故障恢复情况，故障期间是否出现系统不可用，及不可用的恢复时间；故障下是否满足预期的分区顺序性；系统在整个实验过程中的响应时间等。 # 可靠性案例分析 我们使用OpenChaos对ETCD集群进行可靠性测试，发现在主节点网络断开，单独成为一个分区的场景下，ETCD客户端视角下，集群缺乏自动恢复能力。  图2 下面是利用 OpenChaos执行的一个实验结果示例，是一个3节点 ETCD 集群在主节点与从节点网络断开，单独成为一个分区时的表现，模拟的业务流量速率为1000 tps。  图3 从图中可以看出实验持续10分钟，共注入十次主节点网络分区故障，间隔为30秒，故障期间集群表现不一致。下图为更详细的实验结果。 在第1/3/6/8次故障期间，集群无法自行恢复；其他故障期间花费7秒会恢复集群为可用状态，但整个实验中没有出现数据丢失。  图4 通过查看实验过程信息，发现每次主节点被分区时，集群均可在故障期间自行转移主节点。通过分析源码 ，ETCD 客户端在面对ETCD内部错误时，不会进行重试连接其他节点。导致在客户端优先连接的节点为主节点，并发生不可用时，即便主节点已经成功转移，整体集群恢复为可用，业务仍处于未恢复状态。该问题我们也已经report给ETCD社区，等待进一步修复。 # 弹性案例分析 弹性也是分布式系统需要重点关注的能力，除可靠性外，OpenChaos支持对系统扩缩容能力的度量与评测。与可靠性不同，分布式系统的弹性能力不能通过编排固定频率的事件以触发检测。OpenChaos可以根据用户设置的操作系统指标或业务指标阈值来触发扩缩容。 例如，你可以指定集群CPU平均占用的预期值为 40%，或系统响应的预期时间为100ms。弹性检测模型会根据指定的预期值与当前系统表现，根据OpenChaos内置的算法来计算出要弹到的目标规模，来触发扩缩容动作。实验结束后，度量模型会计算出集群的“加速比效率”，与“扩缩代价”和对应规模下集群的性能。 >注：“加速比效率”和“扩缩代价”为OpenChaos中度量分布式系统弹性能力的指标，前者表示分布式系统并行化的性能和效果，后者表示系统伸缩的速率。 弹性的含义不仅包括实例节点的伸缩能力，同样也包含具体业务（应用）单元的伸缩能力。为了探索Kafka分区的最佳使用实践，我们设计了实验以探索单个topic分区的扩容能力。在实验中我们还会统计在不同分区个数下消息收发的吞吐量，以了解分区数量对消息吞吐量的影响和达到最大吞吐量的最优分区数数量。 图5为三节点集群上的一个 topic 的分区从 1 扩到 9000 时的 tps 和延迟情况。  图5 图6为各指标随着实验时间的变化情况。  图6 图7是具体的弹性评测结果部分截图，展示了在不同规模下，系统表现出的性能以及弹性变更的花销与效率。其中changeCost 和 resilienceEfficienty 为上文描述的扩缩代价与加速比效率结果。  图7 从上述结果能够看出，此实验规格下的 Kafka 集群，新增1个分区的平均时间约20ms。在分区数量达到 26 的时候性能达到最优，该情况下吞吐量达到130万，此时CPU 总体利用率达到 93%。在分区数达到450+时，性能明显下降。当分区数达到 1992 时，吞吐量降到 3.8万，CPU总体利用率达到 97%。 # 未来规划 目前 OpenChaos已支持接入大多数分布式系统，如Apache Kafka、Apache RocketMQ、DLedger、 Redis、ETCD等。随着开源之夏2022活动[1]的召开，我们开放了更多分布式系统接入的工作，供广大学生选择与参与。 与此同时，华为云与混沌工程实验室紧密合作，助力中国信通院发布了国内首个《分布式消息队列稳定性评估标准》，是该项标准的主要贡献者。另外，华为云中间件消息产品家族是唯一一个全面通过验收标准的应用服务。 面向未来，OpenChaos将推出更多通用的韧性标准和智能预测功能，以期不仅能评测出架构已有的能力，还能够基于系统的观测做出预测，避免出现超出系统本身韧性能力的异常发生。百尺竿头更进一步，我们会持续打磨该项目，通过生态合作方式集成更多分布式系统，努力将OpenChaos打造成分布式系统韧性架构的压舱石，从而推动云原生架构不断演进，关键时候方能“任凭风浪起，稳坐钓鱼船”。 [1] 开源之夏2022活动： https://summer-ospp.ac.cn/#/org/prodetail/221bf0008

L0设备3861基于3.1release分支的分布式软总线demo编译失败，报错为remove、mkdir等库函数未定义

L0设备3861基于3.1release分支的分布式软总线demo编译失败，报错为remove、mkdir等库函数未定义

背景随着Serverless，微服务（含服务网格）与越来越多的容器化架构应用的出现，我们构建、交付与运维系统的方式变的越发复杂。这种复杂性增加了系统状态可观测性的难度。在已有的生产环境中，我们有不同的方式来获取信息，增强系统的可观测性。起始的时候，可能是非常简单的给定一个特定的条件，产生一个特定的指标输出。进一步的，使用结构化和关联日志，或进行分布式跟踪，引入事件总线如Apache EventMesh、EventGrid等。随着Codeless组合式应用快速发展，Serverless设计理念也在不断被一些分布式系统设计者逐步接受。免运维，按需付费，极致弹性，多租共池等等无不在逼迫我们重新审视老式架构的合理性，催生新架构的不断演进。融合架构是这几年被提的最多的一个词，以往支撑在线/离线系统的复杂架构不断被融合，通过可分可合的设计与部署方式去适配各种业务场景。在这样的背景下，我们开始认真审视并思考，是否有一种更为现代化的工具，能够帮助发现并应对分布式云这种底座对架构设计以及上层应用带来的诸如可靠，安全，弹性等一系列韧性架构的挑战。混沌工程思想给我们带来了一定程度的启发。Netflix最初为了搬迁基础设施上云创建了 Chaos Monkey，由此拉开了混沌工程学的序幕。再到后来，CNCF成立了专门的兴趣小组，希望能够推动这一领域的标准诞生。OpenChaos创始团队早期也和这些社区的先行者进行过多轮交流。可惜的是，2019年随着该兴趣组并入App Delivery SIG后再无太大动静。这几年国家政策大力引导下，企业的数字化升级不断加快，越来越多的CIO、CTO甚至包括CEO开始重视并投入到混沌工程实践中。国内由中国信通院牵头的混沌工程实验室也在如火如荼地推动该领域的飞速发展，从全链路压测，混沌故障引入到催生未来架构变革的多云多活参考架构的制定。这些无不昭示着这一产业在飞速发展。根据国内外科技媒体调研统计，到2025年，80%的组织将实施混沌工程实践。通过全链路压测，混沌故障，以及多云多活架构等策略的整体导入，可以将意外停机时间减少50%，实现真正意义上的秒级RTO/RPO。让应用、业务创新更加专注。良药虽好，但也有局限混沌工程的最基本流程是在生产环境小规模定期自动化执行试验，为系统随机的注入故障，来观察 “系统边界”。它主要关注系统面对故障所展现出的容错能力，可靠性。目前市面上绝大部分混沌工程工具，倾向于构造以黑盒随机为主的故障类型，对底层基础设施（硬件，操作系统，数据库与中间件）理解与洞察较少。缺少统一的框架标准、成熟的specific度量指标。同时，分析反馈较弱，无法给出全面彻底的诊断建议，尤其通过强化学习，生成式AI等能力可以进一步解决目前随机故障注入，进行自愈风险分析与优化建议。面向有更多复杂特性的分布式系统，仅通过观察系统应对故障的表现是有局限的，并且依赖于观察是极其主观的，很难形成统一的评测标准，也较难针对表现分析系统缺陷。系统的可观测性，不仅需要模型的全面覆盖，还需要完备的监测系统，并提供全面的结果报告，甚至智能预测，来指导架构提升自身的韧性能力。分布式领域资深技术专家，开源顶级项目Apache RocketMQ，OpenMessaging最初的创始人冯嘉曾表示“云原生分布式架构的演进正在朝着组装式架构，韧性架构进一步发展”。在这样的背景下，他提出并带领团队创造了OpenChaos这一新兴项目。OpenChaos 需要解决的本质问题韧性架构，覆盖高靠性、安全、弹性、不可变基础设施等特性。实现真正的韧性架构毫无疑问是现代分布式系统的演进方向。针对分布式系统韧性能力，OpenChaos借助混沌工程思想，对其定义进行延伸扩展。针对一些分布式系统特有属性，如Pub/Sub系统的投递语义与推送效率，调度编排系统的精准调度、弹性伸缩与冷启效率，streaming系统的流批实时性、反压效率，检索系统的查全率与查准率，分布式系统共识组件的一致性等，设置专用的检测模型。OpenChaos 内置可扩展的模型支持，以便验证在大规模数据请求以及各种故障冲击下的韧性表现，并为架构演进提供进一步优化建议。架构与案例分析图1整体架构OpenChaos的工作原理是这样的：控制面对整个流程进行控制，负责使集群节点组成一个待测试的分布式集群。并会根据需要测试的分布式基础设施找到对应的Driver组件并载入，根据设置的并发数建立相应个数的客户端。控制节点根据 Model 组件定义的执行流程控制客户端对集群进行操作。演练过程中，Detection Model 会对集群节点根据不同的观测特性引入对应的事件。Metrics 模块会在实验中监测被测集群的表现。演练结束后，Checker组件会对实验中的业务和非业务数据进行自动化分析，得出测试结果并输出可视化图表。如图1所示，OpenChaos的整体架构可以分为管理层，执行层与被测组件层。最上层为管理层，它包含了用户界面和控制器（Control），控制器负责调度引擎层的组件进行工作。最下层为被测组件，它可以是自部署的分布式系统集群，也可以是容器或者云厂商承载的分布式系统。中间层是执行层，也是OpenChaos强大能力的秘密所在。模型（Model）是执行的流程的基本单元，它定义了对分布式系统进行操作的基本形式。控制器在模型中载入需要测试的分布式系统的驱动（Driver），并根据配置的并发数创建相应的客户端（Client），最终使用客户端对分布式系统执行操作。检测模型（Detection Model）会根据用户关注的不同观测特性引入对应的事件，比如引入故障或者系统的扩缩容。Metrics 模块会在实验中监测被测集群的表现。演练结束后，度量模型（Measurement Model）组件会对实验中的业务和非业务数据进行自动化分析，得出测试结果并输出可视化图表。检测模型与度量模型检测模型传统混沌工程主要关注系统的稳定性，它们的普遍实现是通过黑盒的故障注入来模拟一些常见的通用故障。OpenChaos中的检测模型关注更高维度的属性——韧性，它包含可靠性，还包含如弹性、安全性等特性的检测模型。相较于传统混沌工程，OpenChaos不仅支持普遍的黑盒故障注入，还可恶意针对分布式基础软件如消息或缓存等的主备倒换，网络分区导致的脑裂等问题做定制检测，以观察他们在这种情况下的表现。度量模型由于分布式系统的复杂性，对于分布式系统韧性的观测更需要一个简单直观的分析报告，来让人更方便地发现分布式系统可能存在的缺陷和不足。度量模型会对系统的表现进行分析，以统一的标准化计算输出结果与图表，方便使用者进行对比分析。以消息系统的稳定性评估为例，度量模型会根据实验中故障注入情况与系统表现，计算出系统的 RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）。输出集群的处理语义情况，如是否符合 at least once 或 exactly once；故障恢复情况，故障期间是否出现系统不可用，及不可用的恢复时间；故障下是否满足预期的分区顺序性；系统在整个实验过程中的响应时间等。可靠性案例分析我们使用OpenChaos对ETCD集群进行可靠性测试，发现在主节点网络断开，单独成为一个分区的场景下，ETCD客户端视角下，集群缺乏自动恢复能力。图2下面是利用 OpenChaos执行的一个实验结果示例，是一个3节点 ETCD 集群在主节点与从节点网络断开，单独成为一个分区时的表现，模拟的业务流量速率为1000 tps。图3从图中可以看出实验持续10分钟，共注入十次主节点网络分区故障，间隔为30秒，故障期间集群表现不一致。下图为更详细的实验结果。在第1/3/6/8次故障期间，集群无法自行恢复；其他故障期间花费7秒会恢复集群为可用状态，但整个实验中没有出现数据丢失。图4通过查看实验过程信息，发现每次主节点被分区时，集群均可在故障期间自行转移主节点。通过分析源码 ，ETCD 客户端在面对ETCD内部错误时，不会进行重试连接其他节点。导致在客户端优先连接的节点为主节点，并发生不可用时，即便主节点已经成功转移，整体集群恢复为可用，业务仍处于未恢复状态。该问题我们也已经report给ETCD社区，等待进一步修复。弹性案例分析弹性也是分布式系统需要重点关注的能力，除可靠性外，OpenChaos支持对系统扩缩容能力的度量与评测。与可靠性不同，分布式系统的弹性能力不能通过编排固定频率的事件以触发检测。OpenChaos可以根据用户设置的操作系统指标或业务指标阈值来触发扩缩容。例如，你可以指定集群CPU平均占用的预期值为 40%，或系统响应的预期时间为100ms。弹性检测模型会根据指定的预期值与当前系统表现，根据OpenChaos内置的算法来计算出要弹到的目标规模，来触发扩缩容动作。实验结束后，度量模型会计算出集群的“加速比效率”，与“扩缩代价”和对应规模下集群的性能。注：“加速比效率”和“扩缩代价”为OpenChaos中度量分布式系统弹性能力的指标，前者表示分布式系统并行化的性能和效果，后者表示系统伸缩的速率。弹性的含义不仅包括实例节点的伸缩能力，同样也包含具体业务（应用）单元的伸缩能力。为了探索Kafka分区的最佳使用实践，我们设计了实验以探索单个topic分区的扩容能力。在实验中我们还会统计在不同分区个数下消息收发的吞吐量，以了解分区数量对消息吞吐量的影响和达到最大吞吐量的最优分区数数量。图5为三节点集群上的一个 topic 的分区从 1 扩到 9000 时的 tps 和延迟情况。图5图6为各指标随着实验时间的变化情况。图6图7是具体的弹性评测结果部分截图，展示了在不同规模下，系统表现出的性能以及弹性变更的花销与效率。其中changeCost 和 resilienceEfficienty 为上文描述的扩缩代价与加速比效率结果。图7从上述结果能够看出，此实验规格下的 Kafka 集群，新增1个分区的平均时间约20ms。在分区数量达到 26 的时候性能达到最优，该情况下吞吐量达到130万，此时CPU 总体利用率达到 93%。在分区数达到450+时，性能明显下降。当分区数达到 1992 时，吞吐量降到 3.8万，CPU总体利用率达到 97%。未来规划目前 OpenChaos已支持接入大多数分布式系统，如Apache Kafka、Apache RocketMQ、DLedger、 Redis、ETCD等。随着开源之夏2022活动[1]的召开，我们开放了更多分布式系统接入的工作，供广大学生选择与参与。与此同时，华为云与混沌工程实验室紧密合作，助力中国信通院发布了国内首个《分布式消息队列稳定性评估标准》，是该项标准的主要贡献者。另外，华为云中间件消息产品家族是唯一一个全面通过验收标准的应用服务。面向未来，OpenChaos将推出更多通用的韧性标准和智能预测功能，以期不仅能评测出架构已有的能力，还能够基于系统的观测做出预测，避免出现超出系统本身韧性能力的异常发生。百尺竿头更进一步，我们会持续打磨该项目，通过生态合作方式集成更多分布式系统，努力将OpenChaos打造成分布式系统韧性架构的压舱石，从而推动云原生架构不断演进，关键时候方能“任凭风浪起，稳坐钓鱼船”。[1] 开源之夏2022活动：https://summer-ospp.ac.cn/#/org/prodetail/221bf0008链接：https://bbs.huaweicloud.com/blogs/352650