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

大家好！我是酷哥，数据库相关资讯，带您速览，欢迎大家阅读。 ------------------------------------------------ **本期精选** ------------------------------------------------ - 分布式数据库的高可用性简史 - 沙利文发布《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) *声明：文章源于第三方公开的信息，如果存在侵权或信息不实时，请及时联系处理。* 整理者：酷哥

本文分享自华为云社区《[【新作】分布式系统韧性架构压舱石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

5月10日，弗若斯特沙利文（Frost & Sullivan，简称“沙利文”）联合头豹研究院发布《2021年中国分布式数据库市场报告》。报告显示，在中国市场，分布式数据库发展正处于“爆发期”。从专利申请的数据角度出发，中国的分布式数据库相关专利申请量从2012年的全球占比22%爬升至2021年的76%，中国已经成为了全球分布式数据库的技术创新中心。通过对2021年数据库市场进行持续跟踪和调研，沙利文指出，数据库作为大多数信息系统的基础设施，向下发挥硬件算力，向上承接上层应用，各式各样的数据库产品分别满足不同的业务需求。数据库的速度、易用性、稳定性、扩展性、成本都对企业的基础业务与增长弹性至关重要。对于数据库行业的发展趋势，沙利文认为，在云上建设数据库服务，设计出以基础云先行，全线适应云特点的云原生数据库尤为重要。腾讯云自主研发了新一代高性能、高可用数据库TDSQL-C，100%兼容MySQL和PostgreSQL，实现超百万级QPS的吞吐能力。展望未来，数据库的发展动力依然来自数据存储规模和性能要求，以及硬件的发展，未来的数据库技术还将满足AI对数据管理的需求。《2021年中国分布式数据库市场报告》 下载  https://www.modb.pro/doc/60894文章来源：https://baijiahao.baidu.com/s?id=1732412452502027034&wfr=spider&for=pc

日前，百易存储研究院、中国计算机学会信息存储专委会、中国计算机行业协会信息存储与安全专委会、DOIT 正式发布《2022分布式存储市场调研报告》。报告指出，中国分布式存储市场规模虽然无法准确回答，但市场发展的趋势是明确和清晰的，未来市场潜力巨大。 事实上，分布式存储发展至今，市场上并没有一个能够被广泛接受并引用的定义。百易存储研究院认为用传统存储、传统阵列或者传统磁盘阵列的表述更为便于理解。对于中国分布式存储市场规模有多大？报告指出，这其实也是一个很难准确回答的问题。“一来分布式存储市场参与的厂商很多，其中很多厂商不是上市企业，没有办法获得销售数据；二来分布式存储没有一个市场可以普遍接纳的定义和分类，会导致数据统计口径混乱，例如分布式存储是否包括去中心化存储、是否包括超融合、是否包括云存储、内涵与界定的不同，市场规模自然也不一样。”IDC 给出的统计数据表明：2021年中国存储市场规模为42.9亿美元，其中，软件定义存储14亿美元，占比 26.1%；超融合为12亿美元，占比 20.3%。本报告中的分布式存储包括 SDS、HCI 两个部分，总体市场规模26亿美元，占比46.3%。配合本次调查报告的调查问卷中，受访者也对市场进行了估算，结果从10亿美元～ 1000亿人民币不等；超融合市场规模从30亿美元～300亿人民币不等；云存储市场的规模50亿（美元）～ 1800亿（人民币）规模不等。差距和出入非常大，体现了不同消费者的不同理解。目前百易存储研究院没有官方的渠道和数据对存储市场规模进行统计，但是可以肯定，随着数据量的快速增长，数据存储市场会呈现一种快速增长的趋势，IDC 给出的预计，市场增长速率为 54.2%，未来发展不会低于这个增速。在目前的情况下，分布式市场的规模也是仁者见仁、智者见智，但是无论如何，市场发展的趋势是明确和清晰的，未来市场潜力巨大。《2022分布式存储市场调研报告》下载 :https://www.modb.pro/doc/60979文章来源：C114通信网 https://g.pconline.com.cn/x/1500/15002204.html

电脑可以没日没夜地运行，但早先的网站却做不到24*7小时的运营。现在看来我们都不可思议。然而，在互联网出现之前，24*7的高可用性这个提法并不存在。那时我们对可用性是有期待，但我们却压根不会认为这是我们有权要求获得的东西。我们只在需要时使用计算机；更多的时候我们其实本来就不太有机会使用它，自然也很少会让计算机一直开着以便它可以随时响应我们。随着互联网的发展，那些以前在当地时间凌晨 3 点不常见的请求变得越来越多，也让这个时间段在全球各地都变成了黄金营业时间，因此确保计算机能够服务这些请求变得非常重要。然而，许多系统仅依靠一台计算机来处理这些请求——单点故障——我们都知道这是个很糟糕的事实。为了保持正常运行，我们需要在多台可以满足我们需求的计算机之间分配负载。然而，分布式计算有着非常明显的优势：特别是同步和容忍系统内的部分故障（容错）。每一代工程师都在迭代这些解决方案，以满足这个时代的需求。数据库领域是如何引入分布式的，这件事很多人并不清楚前因后果，因为这本身就是一个比其他领域发展缓慢得多的难题。当然，软件在本地数据库中会记录一些分布式计算的结果，但数据库本身的状态只能保存在单台机器上。为什么？因为跨机器的状态复制是非常困难的。在这篇文章中，我们来看看分布式数据库在历史上是如何处理容错的，以及高可用性是什么样子的。另外，我们还会介绍高可用性系统的几种不同类型。高可用性数据库有哪些类型?高可用性数据库一般情况下可分为两类，目前出现了第三类，而且变得越来越普遍：主-从数据库：数据库有一个主节点处理请求，另外一个是热备节点（即从节点），一旦主节点故障后就会投入使用主-主数据库：数据库具有多个主节点，这些节点将数据分片后分别对数据库进行写操作多主数据库：数据库具有至少三个主节点，这些节点都可以对集群中的任何数据执行读写操作而不会产生冲突。什么是主从可用性?主从可用性意味着数据库有一个主节点处理请求，另外一个是热备节点（即从节点），一旦主节点故障后就会投入使用。主从可用性模型基于两节点概念，即一个节点接收所有请求，然后再将数据复制到其追随者。在过去，数据库在单台机器上运行。它只有一个节点，处理所有的读写操作。没有所谓的“部分失败”；数据库不是成功启动就是失败停服。对互联网来说，单节点数据库的完全不可用是一个双重问题；首先，计算机全天候被访问，因此停机更有可能直接影响用户；其次，通过将计算机置于持续的访问请求之下，它们更有可能出现故障。很明显，这个问题的解决方案是使用多台计算机来共同处理请求，这也是分布式数据库起步的契机所在。生活在单节点世界中，最自然的解决方案是继续让单个节点提供读写服务，并将其状态简单地同步到辅助的备份机器上——因此，主从复制诞生了。主从模式是通过即时备份实现高可用性的早期步骤。在主节点发生故障的情况下，您可以简单地将流量引导到从节点，从而将其提升为主节点。只要有可能，您就会用一台新的备份机器替换停机的服务器（并希望主节点在此期间不会出现故障）。首先，从主节点到从节点的复制是一个同步过程，即在从节点确认之前，数据转换并不会被提交。但是，目前还不清楚如果从节点出现故障该怎么办。如果备份系统不可用，整个系统宕机当然没有意义——但是只要使用同步复制，就会发生这种情况。为了进一步提高可用性，可以改为异步复制数据。虽然它的架构看起来是一样的，但它能够处理主节点或从节点的宕机，而不会影响数据库的可用性。虽然异步主从模式是向前迈出的又一步，但仍然存在明显的缺点：当主节点宕机时，任何尚未复制到从节点的数据都可能丢失——即使客户端已经确认了数据完全提交。依靠单台机器来处理流量，仍然受限于单台机器的最大可用资源。对五个 9 的高可用性追求扩展到多台机器随着互联网的普及，业务需求的规模和复杂性都在增长。对于数据库来说，这意味着它们需要能够处理比任何单个节点都多的流量，并且提供“始终在线”的高可用性成为一项任务。鉴于现在大量工程师拥有从事其他分布式技术的经验，很显然，数据库可以超越单节点的主从模式，将数据库分布在多台机器上。分片同样，我们可以从调整现有的系统起步，我们的工程师通过开发分片将主动复制调整为更具可扩展性的架构。在此方案中，您按某个值（例如行数或主键中的唯一值）拆分集群的数据，并将这些段分布在多个实例，每个实例都有一套主从节点。然后，您在由这些实例组成的集群前添加某种路由技术，以将客户端请求引导到正确的实例来处理。分片允许您在将工作负载分配到多台机器上，从而提高吞吐量，并通过容忍更多的部分故障和消除单点故障来创建更大的弹性。尽管有这些好处，但对系统进行分片是复杂的，并且给团队带来了巨大的运维负担。特意对碎片进行的统计可能会变得非常繁琐，以至于路由最终会渗入应用程序的业务逻辑。更糟糕的是，如果您需要修改系统分片的方式（例如模式更改），通常需要明显的（甚至是巨大的）工程量来实现。单节点主从系统也提供了事务支持（即使不是强一致性）。然而，跨分片协调交易的难度是如此的琐碎和复杂，许多分片系统是决定彻底放弃它们的。什么是主主可用性?主主可用性意味着数据库至少有两个主节点，它们对数据进行分片并执行对数据库的写入。主主可用性代表了从主从的演变，通过让集群中的节点提供读写服务，使数据库能够扩展到单台机器之外。考虑到分片数据库难以管理且功能不全，工程师们开始开发至少可以解决其中一个问题的系统。这时候出现的是仍然不支持事务的系统，但管理起来已经非常容易。随着对应用程序正常运行时间的需求不断增加，帮助团队满足其 SLA 的决定是很明智的。这些系统背后的动机是每个实例节点都可以包含集群的部分（或全部）数据，并为其提供读取和写入服务。每当一个节点收到写入请求时，它都会将更改传播到所有其他需要它的副本的节点。为了处理两个节点对同一个键值写入的情况，任何一个节点的转换在提交之前都会被送入冲突解决算法。鉴于每个站点都是“活跃的”，因此被称为主主。因为每台服务器都可以对其所有数据进行读写，所以分片更容易在算法上实现，并使部署更易于管理。在可用性方面，主主非常出色。如果一个节点发生故障，客户端只需重定向到另一个确实包含数据的节点。只要数据的单个副本处于活动状态，就可以为其提供读取和写入服务。虽然这种方案在高可用性方面非常出色，但其设计在一致性和数据正确性方面存在根本性的问题。因为每个实例节点都可以处理键值的写入（在故障转移场景中也是如此），所以它在处理数据时保持数据完全同步是非常困难的。该方案通常是通过冲突解决算法来调解实例之间的冲突，而该算法对如何“消除”不一致性的决策是粗粒度的。由于该解决方案是事后完成的，是在客户端已经收到有关程序的响应之后——并且理论上已经根据该响应执行了其他业务逻辑——主主复制很容易在数据中生成异常。然而，考虑到正常运行时间的溢价，停机成本被认为大于潜在异常的成本，因此主主成为主要的复制类型。大规模正确性共识和多活可用性主主似乎解决了基础设施面临的主要问题——提供高可用性。但它只是通过放弃事务来做到这一点，这使得系统在强一致性需求的满足上并不那么可信。例如，谷歌在其广告业务中使用了一个庞大而复杂的 MySQL 分片系统，该系统严重依赖 SQL 的表达能力来任意查询数据库。因为这些查询通常依赖二级索引来提高性能，所以它们必须与它们所派生的数据保持完全一致。最终，这个系统变得足够大，开始导致分片 MySQL 出现问题，工程师开始设想如何解决这样的问题：既要有大规模可伸缩的系统，又要提供业务所需的强一致性。主主缺乏事务支持意味着它不应该是一个可选项，因此他们不得不设计一些新东西。最终，他们用这样的一个系统解决了问题，这是一个基于共识复制的系统，既能保证一致性，又能提供高可用性。使用共识复制，写入被提议到一个节点，然后被复制到一些其他节点。一旦大多数节点确认写入，就可以提交。共识和高可用性这里的关键概念是，共识复制是介于同步和异步复制之间的一种机制：您可以指定任意数量的节点来进行同步，但这些节点是哪些并不重要。这意味着集群可以容忍少数节点宕机，而不会影响系统的可用性。（处理被关机服务器流量等的注意事项）然而，共识的代价是它需要节点与其他节点进行通信以执行写入。虽然您可以采取一些措施来减少节点之间产生的延迟，例如将它们放在同一个可用区中，但这需要和高可用性一起权衡考虑。例如，如果所有节点都在同一个数据中心，它们之间的通信速度很快，但如果整个数据中心离线，你的服务也不会独活。将您的节点分散到多个数据中心可能会增加写入所需的延迟，但却可以提高你的可用性，就算整个数据中心都离线了，你的应用也仍然在线。什么是多主可用性？多主可用性要求数据库至少具有三个活动节点，每个活动节点都可以对集群中的任何数据进行读写而不产生冲突。CockroachDB 实现了Google Spanner 论文中的大部分内容（但值得注意的是，它不需要原子钟），包括那些超越共识复制之外的特性，这些特性使可用性变得更简单。为了描述其工作原理并将其与主主区分开来，我们创造了术语多主可用性。主主 vs. 多主主主通过允许集群中的任何节点为其键值提供读写服务来实现可用性，但只有在提交写之后才将其接受的更改传播给其他节点。另一方面，多主可用性允许任何节点提供读写服务，但确保大多数副本在写入时保持同步，并且仅提供来自最新版本副本的读取服务。在高可用性方面，主主只需要一个副本即可同时用于读写，而多主则需要大多数副本在线才能达成共识（这仍然允许系统内部出现部分故障）。显然这些数据库在可用性方面的不同表现源于系统在对一致性方面处理的差异。主主数据库在大多数情况下都会努力工作写入数据，但是不能保证客户端现在或将来能够读取到该数据。而多主数据库仅在可以保证以后可以以一致的方式读取数据时才接受写入。回顾与展望在过去的 30 年中，数据库复制和可用性取得了长足的进步，现在已经支持全球范围内部署，感觉就像它们永远不会不受欢迎。该领域的首次尝试通过主从复制奠定了重要的基础，但最终，我们需要更好的可用性和更大的规模。在这个领域，业界发展出了两种主要的数据库类型：其中主从用于满足那些主要关注快速写入的应用程序，而多主则服务于那些对一致性有需要的应用程序。我们都期待有一天，我们可以利用量子纠缠并转向下一代数据库类型：可管理的分布式数据库。原文链接：​​https://www.cockroachlabs.com/blog/brief-history-high-availability/​

根据DB-Engines官网消息，4月，DB-Engines图数据库类目数量新增1个至37个，新入选者为国产数据库品牌星环科技StellarDB，至此共5家国产图数据库上榜DB-Engines，分别为Nebula Graph、HugeGraph、GraphBase、 Galaxybase和StellarDB。1、Nebula Graph：简介：Nebula Graph 一款开源、分布式图数据库，擅长处理超大规模数据集。 Nebula Graph 采用存储计算分离架构，支持水平扩展，利用 RAFT 分布式 concensus 协议来实现金融级的高可用，类 SQL 查询语言降低了 SQL 程序员迁移成本。Nebula Graph 是一款开源的分布式图数据库，擅长处理千亿个顶点和万亿条边的超大规模数据集。提供高吞吐量、低延时的读写能力，内置 ACL 机制和用户鉴权，为用户提供安全的数据库访问方式。作为一款高性能高可靠的图数据库，Nebula Graph 提供了线性扩容的能力，支持快照方式实现数据恢复功能。在查询语言方面，开发团队完全自研开发查询语言——nGQL，并且后续会兼容 OpenCypher 接口，让 Neo4j 的用户可无缝衔接使用 Nebula Graph。2、HugeGraph简介：HugeGraph 是一款易用、高效、通用的开源图数据库系统（Graph Database）HugeGraph 是一款易用、高效、通用的开源图数据库系统（Graph Database）， 实现了 Apache TinkerPop3 框架及完全兼容 Gremlin 查询语言， 具备完善的工具链组件，助力用户轻松构建基于图数据库之上的应用和产品。HugeGraph 支持百亿以上的顶点和边快速导入，并提供毫秒级的关联关系查询能力（OLTP）， 并可与 Hadoop、Spark 等大数据平台集成以进行离线分析（OLAP）。HugeGraph 典型应用场景包括深度关系探索、关联分析、路径搜索、特征抽取、数据聚类、社区检测、 知识图谱等，适用业务领域有如网络安全、电信诈骗、金融风控、广告推荐、社交网络和智能机器人等。本系统的主要应用场景是解决百度安全事业部所面对的反欺诈、威胁情报、黑产打击等业务的图数据存储和建模分析需求，在此基础上逐步扩展及支持了更多的通用图应用。3、GraphBaseGraphBase是一个图形数据库管理系统 (Graph DBMS)，旨在简化复杂数据图的创建和维护。复杂且高度连接的结构是关系数据库管理系统 (RDBMS) 面临的挑战。图数据库提供了更好的建模实用程序、性能和可扩展性。借助GraphBase，我们的目标是简化复杂数据结构的管理，让您的数据变得更加丰富。它可以成为内识。我们通过重新定义应如何管理图形数据来实现这一点。在GraphBase中。您将获得与“行和表”范式等效的图形，它使关系数据库如此易于使用。图是一个事务单元。可以通过多种方式切割、组合和操作大型或小型整图。4、Galaxybase简介：Galaxybase是中国自主知识产权的通用商业化分布式图数据库，目前世界最快、延展性最好，性能超美国同类竞品百倍。Galaxybase改变了传统数据存储的方式，以一种更为灵活的基于“对象”和其间“关系”的图数据结构，将分散的不同种类的原始数据连接在一起形成一个关系网络，打通数据孤岛，通过自然语言处理、机器学习、图挖掘等人工智能算法，提供用户从关系角度分析问题的能力，帮助其完成实时决策。Galaxybase作为第三代图数据库技术的代表产品，是国内首个成熟、通用、全自主知识产权的商业化图数据库。得益于底层自研数据存储和分布式并行处理架构，解决了大规模关联数据高效存储、查询、计算的难题，较现存同类技术有百倍性能提升，为企业打通数据孤岛、建立以推理为基础的人工智能，提供了从数据迁移、数据建模、数据存储、数据查询、数据运算到数据分析的一站式解决方案。5、StellarDB简介：Transwarp StellarDB是星环科技推出的一款为企业级图应用而打造的分布式图数据库，用于快速查找数据间的关联关系，并提供强大的算法分析能力。StellarDB克服了海量关联图数据存储的难题，通过自定义图存储格式和集群化存储，实现了传统数据库无法提供的低延时多层关系查询，在社交网络、公安、金融领域都有巨大应用潜力。Transwarp StellarDB是星环科技推出的一款为企业级图应用而打造的分布式图数据库，用于快速查找数据间的关联关系，并提供强大的算法分析能力。StellarDB克服了万亿级关联图数据存储的难题，通过自定义图存储格式和集群化存储，实现了传统数据库无法提供的低延时多层关系查询，在社交网络、金融领域都有巨大应用潜力。

FastDFS是一个开源的轻量级分布式文件系统，纯C实现，目前提供了C、Java和PHP API。功能包括：文件存储，文件同步，文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务。Fast DFS系统有三个角色：跟踪服务器(Tracker Server)、存储服务器(Storage Server)和客户端(Client)。client请求Tracker server 进行文件上传、下载，通过Tracker server调度最终由Storage server完成文件上传和下载，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10。Tracker server：跟踪服务器，主要做调度工作，起到均衡的作用；负责管理所有的Storage server和group，每个storage在启动后会连接Tracker，告知自己所属group等信息，并保持周期性心跳。tracker上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数据，这样使得tracker非常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，cluster里每个tracker之间是完全对等的，所有的tracker都接受stroage的心跳信息，生成元数据信息来提供读写服务，tracker根据storage的心跳信息，建立group==>[storage server list]的映射表。Storage server：存储服务器，主要提供容量和备份服务；以group为单位，每个group内部可以有多台storage server，数据互为备份。客户端上传的文件最终存储在storage服务器上，Storage server没有实现自己的文件系统，而是利用操作系统的文件系统来管理文件，可以将storage称为存储服务器。storage可配置多个数据存储目录，比如有10块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这10个目录都配置为storage的数据存储目录。Client：客户端，上传下载数据的服务器，也就是我们自己的项目所部署在的服务器。FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用跟踪服务器和存储节点都可以由一台或多台服务器构成，跟踪服务器和存储节点均可以随时增加或者下线不会影响线上服务，其中跟踪服务器中所有服务器是对 等，可以根据服务器压力情况随时增加或减少文件的上传Storage server会连接集群中所有的Tracker server，定时向他们报告自己的状态，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。上传的内部机制如下：选择tracker server当集群中不止一个tracker server时，由于tracker之间是完全对等无状态的关系，当集群中不止一个tracker server时，由于tracker之间是完全对等的关系，客户端在upload文件时可以任意选择一个trakcer。 选择存储的group 当tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则：Round robin，所有的group间轮询Specified group，指定某一个确定的groupLoad balance，剩余存储空间多多group优先选择storage server当选定group后，tracker会在group内选择一个storage server给客户端，支持如下选择storage的规则：Round robin，在group内的所有storage间轮询First server ordered by ip，按ip排序First server ordered by priority，按优先级排序（优先级在storage上配置）选择storage path当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则：Round robin，多个存储目录间轮询剩余存储空间最多的优先生成Fileid选定存储目录之后，storage会为文件生一个Fileid，由storage server ip、文件创建时间、文件大小、文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串。 选择两级目录 当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件fileid进行两次hash（猜测），路由到其中一个子目录，然后将文件以fileid为文件名存储到该子目录下生成文件名当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由group、存储目录、两级子目录、fileid、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成文件的下载跟upload file一样，在download file时客户端可以选择任意tracker server。tracker发送download请求给某个tracker，必须带上文件名信息，tracke从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求。定位文件：客户端上传文件后存储服务器将文件ID返回给客户端，此文件ID用于以后访问该文件的索引信息。文件索引信息包括：组名，虚拟磁盘路径，数据两级目录，文件名。组名：文件上传后所在的storage组名称，在文件上传成功后有storage服务器返回，需要客户端自行保存。虚拟磁盘路径：storage配置的虚拟路径，与磁盘选项store_path*对应。如果配置了store_path0则是M00，如果配置了store_path1则是M01，以此类推。数据两级目录：storage服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。文件名：与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。知道FastDFS FID的组成后，我们来看看FastDFS是如何通过这个精巧的FID定位到需要访问的文件：通过组名tracker能够很快的定位到客户端需要访问的存储服务器组，并将选择合适的存储服务器提供客户端访问存储服务器根据“文件存储虚拟磁盘路径”和“数据文件两级目录”可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件同步时间管理当一个文件上传成功后，客户端马上发起对该文件下载请求（或删除请求）时，tracker是如何选定一个适用的存储服务器呢？ 其实每个存储服务器都需要定时将自身的信息上报给tracker，这些信息就包括了本地同步时间（即，同步到的最新文件的时间戳）。而tracker根据各个存储服务器的上报情况，就能够知道刚刚上传的文件，在该存储组中是否已完成了同步。同步信息上报如下图：写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server。每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。storage的同步进度会作为元数据的一部分汇报到tracker上，tracke在选择读storage的时候会以同步进度作为参考。 比如一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1以前写的文件都已经同步到B上了），B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1（即所有T1以前写的数据都已经同步到C上了）；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。集成NginxFastDFS通过Tracker服务器,将文件放在Storage服务器存储，但是同组存储服务器之间需要进入文件复制，有同步延迟的问题。假设Tracker服务器将文件上传到了192.168.4.125，上传成功后文件ID已经返回给客户端。此时FastDFS存储集群机制会将这个文件同步到同组存储192.168.4.126，在文件还没有复制完成的情况下，客户端如果用这个文件ID在192.168.4.126上取文件,就会出现文件无法访问的错误。而fastdfs-nginx-module可以重定向文件连接到文件上传时的源服务器取文件,避免客户端由于复制延迟导致的文件无法访问错误。另外，使用nginx反向代理后，后端可以以HTTP请求的方式来访问文件资源。访问nginx反向代理+上传文件时的IDMooseFS原理MooseFS 是一款具有冗余容错功能的分布式文件系统。它把数据分散在多台服务器上，确保一份数据多个备份副本，对外提供统一的结构。对于标准的文件操作，MooseFS 表现与其他类Unix文件系统一致。 支持的通过文件系统特性：层次结构（目录树）兼容 POSIX 文件属性支持特殊文件符号链接和硬链接基于 IP 地址和密码的访问控制高可靠性(数据的多个副本存储在不同服务器)容量动态扩展（添加新硬盘或者服务器）可以回收在制定时间内删除的文件，类似回收站功能可以对整个文件甚至是正在被写入的文件创建文件快照MooseFS架构中的四种角色管理服务器（Master Server）：也称为元数据服务器，负责管理各个数据存储服务器，调度文件读写，回收文件空间以及恢复多节点拷贝。目前MFS只支持一个元数据服务器master，这是一个单点故障，需要一个性能稳定的服务器来充当元数据日志服务器（Metalogger Server）：负责备份管理服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在管理服务器出问题时接替其进行工作。元数据日志服务器是mfs 1.6以后版本新增的服务，可以把元数据日志保留在管理服务器中，也可以单独存储在一台服务器中。为保证数据的安全性和可靠性，建议单独用一台服务器来存放元数据日志。需要注意的是，元数据日志守护进程跟管理服务器在同一个服务器上，备份元数据日志服务器作为它的客户端，从管理服务器取得日志文件进行备份数据存储服务器（Chunk Server）：数据存储服务器是真正存储用户数据的服务器，负责连接管理服务器，听从管理服务器调度，提供存储空间，并为客户提供数据传输。在存储文件时，首先把文件分成块，然后将这些块在数据存储服务器之间互相复制客户端（Client）：通过FUSE内核接口挂载远程管理服务器上所管理的数据存储服务器，使共享的文件系统和使用本地文件系统的效果看起来是一样的首先客户端（Client）访问主服务器（Master），获取文件实体的位置等相关信息主服务器（Master）查询缓存记录，把文件实体的位置等相关信息发给客户端（Client）客户端（Client）根据拿到的信息去访问对应的存储实体数据的服务器（Chunk Server）存储实体数据的服务器（Chunk Server）把对应的数据返回给客户端（Client）客户端（Client）访问主服务器（Master），请求写入数据主服务器（Master）查询缓存记录，如果是新文件，则联系后面的数据服务器（Chunk Server）创建对应的chunk对象准备存放文件数据服务器（Chunk Server）返回创建chunk对象成功的消息给主服务器（Master）主服务器（Master）把文件实体的位置等相关信息发给客户端（Client）客户端（Client）访问对应的数据服务器（Chunk Server）写数据数据服务器（Chunk Server）之间进行数据同步，互相确认成功数据服务器（Chunk Server）返回成功写入信息给客户端（Client）客户端（Client）回报给主服务器（Master）写入结束MooseFS VS FastDFS对比说明 / 文件系统FastDFSMooseFS开发语言Cperl性能很高相对较差易用性安装简单，社区相对活跃，不需要二次开发即可直接使用安装简单，官方文档多，且提供Web界面的方式进行管理与监控适用场景单集群的中小文件单集群的大中文件在线扩容支持支持冗余备份支持支持单点故障不存在存在跨集群同步部分支持不支持数据存储方式文件/块块FUSE挂载不支持支持访问接口不支持POSIX支持POSIXFUSE挂载：fuse解决了文件系统必须在内核态的的难题。实现了一个对文件系统访问的回调，它使无特权的用户能够无需编辑内核代码而创建自己的文件系统POSIX：表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），也就是Unix下应用程序共同遵循的一种规范。支持POSIX的应用程序意味着在各个Unix系统间提供了跨平台运行的支持。例如：#include <pthread.h> //在Linux下编写多线程程序需要包含的头文件POSIX线程（POSIX threads），简称Pthreads，是线程的POSIX标准。该标准定义了创建和操纵线程的一整套API。在类Unix操作系统（Unix、Linux、Mac OS X等）中，都使用Pthreads作为操作系统的线程。Windows操作系统也有其移植版pthreads-win32。作者：Minority链接：https://www.jianshu.com/p/1103971ffef8来源：简书

ZooKeeper 是 Apache 软件基金会的一个软件项目，它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。ZooKeeper 的架构通过冗余服务实现高可用性。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。谁适合阅读本教程？本教程是为专业的程序开发人员，通过本教程你可以一步一步了解 zookeeper 的应用。zookeeper 数据结构zookeeper 提供的名称空间非常类似于标准文件系统，key-value 的形式存储。名称 key 由斜线 / 分割的一系列路径元素，zookeeper 名称空间中的每个节点都是由一个路径标识。相关 CAP 理论CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择，zookeeper 保证的是 CP，对比 spring cloud 系统中的注册中心 eruka 实现的是 AP。BASE 理论BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。基本可用：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。最终一致性：data replications 经过一段时间达到一致性。BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。相关资源zookeeper 官网：https://zookeeper.apache.org/

随着各领域数字化转型的推进，数据系统的应用范围不断扩大，承载业务愈发关键，用户的高频访问成为常态，系统复杂性呈指数上升，这些因素显著增加了稳定性风险，传统系统稳定性保障方法论难以适应数字化发展需要，导致近年来全球范围内数据系统故障事件频发。 2022年4月27日，首届“全球数据系统稳定性峰会”以线上线下结合的形式召开。峰会由中国信息通信研究院和中国通信标准化协会指导，中国通信标准化协会大数据技术标准推进委员会（CCSA TC601）主办，会议得到了中国IDC圈、dbaplus社群的大力支持。大会旨在助力我国数字经济发展“又快又稳”，推动全球数据系统稳定性迈上新台阶。 中国工程院院士廖湘科、中央网信办信息化发展局副局长张望、中国通信标准化协会副理事长兼常务副秘书长代晓慧、中国信息通信研究院副院长魏亮等专家领导参会并致辞。廖湘科院士在致辞中指出，数据系统已经成为数字经济时代不可或缺的基础设施，大量关乎国计民生的关键数据系统已成为托举我国社会平稳运行、经济持续增长的重要底盘。廖院士强调，在系统稳定性方面，要坚持自主创新，强化服务支撑，加强稳定性保障相关人才培养力度。成果发布 中国信通院云计算与大数据研究所所长何宝宏对中国信通院数据系统稳定性工作体系进行了介绍。中国信通院于2021年启动稳定性相关工作，依托分布式系统稳定性实验室，面向供给侧机构、监管机构及应用侧机构，形成面向产品、工具、服务商、系统、灾备和保障体系等对象的“STAR”评估体系，助力我国各领域系统稳定性保障工作。 中国信通院云计算与大数据研究所副所长魏凯介绍了本批数据系统稳定性评估评测的总体情况，从保障能力、应用行业等角度对本批测试结果进行了深入的剖析，帮助读者全面理解系统稳定性的保障情况，总结了影响系统稳定性的四大关键因素。 分布式系统稳定性实验室成员/专家团亮相中国信通院分布式系统稳定性实验室自2021年成立以来，受到业内专家、企业的大力支持，目前实验室共有五十多个成员单位和23位资深专家。会上，中国信通院为分布式系统稳定性实验室成员单位和专家团成员举行了亮相仪式。 证书及案例发布 中国信通院向通过首批数据系统稳定性保障能力评估(STAR-A)的企业颁发了证书。“STAR-A评估”是由中国信通院分布式系统稳定性实验室推出首个针对系统稳定性保障体系的评估项目，旨在帮助参评企业全方位梳理系统稳定性保障体系，排除潜在风险点。经过严格评估，首批共筛选出涵盖金融、电信、政务、医疗、互联网等诸多行业的12个一线系统。 随后峰会颁布了“系统平稳运行优秀案例”。“系统平稳运行优秀案例”由中国信通院分布式系统稳定性实验室发起，旨在评选出高稳定性系统，树立行业标杆。该案例的评审采用拨测方式，模拟真实用户对系统进行访问，检测50余个大型系统半年的平均无故障时间，筛选故障时间最短的前14家企业，覆盖银行、证券、电信、互联网、交通、媒体等多个领域，展示了我国系统稳定性保障领域的领先成果。 主题演讲 大会邀请到了交通、电商、通信行业的嘉宾，就各自领域稳定性的实践探索进行了分享与探讨。 中国铁道科学研究院集团有限公司首席研究员、12306科创中心副主任单杏花就《铁路12306稳定性保障》主题进行演讲。 京东零售集团京东大促备战技术总架构师李军亮进行了主题为《京东大促稳定性保障经验分享》的演讲。 浙江移动SRE架构师史军艇以《运营商大型系统的稳定性经验分享》为题进行演讲。 蚂蚁集团数字科技事业群技术副总经理石世群以《支付宝双十一稳定性保障经验分享》为题进行演讲。 在下午的会议中，中国信通院王卓对《信息系统稳定性建设保障指南（1.0）》进行了解读，王超伦带来了分布式系统稳定性保障能力标准和首批评估结果解读。中国信通院杨佳星、田稼丰分别发布了《系统稳定性保障平台能力要求》及《数据系统灾备能力成熟度模型》。 大会还邀请到了新炬网络、数列科技、博睿数据、阿里云及京东科技的嘉宾，就各自领域的稳定性保障成果进行分享。从稳定性保障的各项技术到产品如何实现高稳定性，多角度展示了我国数据系统稳定性保障领域取得的成就。 来源：大数据技术标准推进委员会

4月23日，中国邮政储蓄银行新一代个人业务分布式核心系统全面投产上线。该系统是大型商业银行中首家同时采用企业级业务建模和分布式微服务架构，基于鲲鹏硬件底座、openGauss开源数据库与GaussDB分布式云数据库共同打造的全新个人业务核心系统，是中国银行业金融科技关键技术可控的重大实践。邮储银行新一代个人业务核心系统通过企业级业务建模实现化繁为简，重塑核心交易流程；组件化模型驱动业务敏捷，从容应对市场变化与客户需求；分布式单元化部署实现弹性扩展，实时支撑业务变化；在线迁移方式实现客户无感切换，保障业务连续性，降低切换风险，为客户带来了新体验。新感受，更加快速高效。改版界面、优化流程、减少人工依赖，大幅缩短客户业务办理时间；新功能，更加智能强大。依托线上触达渠道，重点着眼于客户需求复杂的查询类业务，满足客户长周期、多元化、个性化需求；新设计，更加安全、可靠。完善的实时反欺诈系统，提高操作风险管控能力，同时帮客户降低潜在欺诈风险。鲲鹏、openGauss开源数据库与GaussDB分布式云数据库作为邮储银行新一代个人业务核心系统IT数字化底座组成部分，在其中承担了先进算力平台和高性能企业级数据库的重要角色，系统上线后可支撑海量交易、弹性伸缩、金融核心级高可靠和高可用，可具备为全行6.37亿个人客户、4万个网点提供日均20亿笔，峰值6.7万笔/秒的交易处理能力。邮储银行新一代个人业务核心系统全面投产上线，使邮储银行科技金融再添一部新引擎，将为邮储银行提供源源不断的科技动能，加速建设“一流大型零售银行”。同时鲲鹏、openGauss开源数据库与GaussDB分布式云数据库将继续全力支持邮储银行数字化升级，共同为同业积累经验，探明路径，树立标杆。

一、全球计算产业趋势——数据中心的重新架构每隔数十年，新架构重塑数据中心上一次大规模的数据中心迁移发生在90年代，从 RISC处理器转移到了更低成本的PC衍生X86架构。 英特尔凭借着PC市场的规模效应颠覆了相对更高 端的竞争对手。 今天，ARM处理器正在利用移动生态系统的规 模来颠覆英特尔。将开源原理应用于硬件， RISC-V也正在凭借低成本侵蚀市场。 ARK Invest认为，ARM和RISC-V的组合将从 2020年的0%市场份额上升到2030年服务器市场 的的71%。英特尔的发展似乎陷入停滞作为曾经世界半导体制造业的领导者，英特尔似乎 已经失去了方向 ；英特尔将其10nm处理器推迟了4年，使其竞争对手 台积电和AMD的机会在2020年引领市场 ；截至2021年，英特尔仍然没有出货10nm服务器芯 片。而台积电正在大规模生产5nm处理器，比英特 尔领先了整整一代。到2030年,ARM可以为多数开发用PC提供足够的性能几乎所有的软件开发人员都在英特尔的x86电脑上编写 代码，运行Windows、Mac或Linux操作系统 ；苹果公司计划在未来两年内将每三个开发者中就有一个 使用的Mac从x86过渡到基于ARM的中央处理器（CPU） ；与此同时，微软正在加倍努力支持ARM处理器上的 Windows；根据ARK的研究，到2030年，大多数开发者的PC可能 由ARM CPU驱动，标志着英特尔x86 时代的结束。ARM可能成为云计算的新标准公共云(Public cloud)作为投放新应用程序的默 认平台， 在2020年全球收入达到1400亿美元 ；AWS--世界上最大的公共云供应商--在2020年 推出了Graviton 2 ARM CPU， 减少了其从英 特尔和AMD购买芯片的需求；AWS Graviton 2比英特尔CPU更便宜、更快、 每一美元的性能高出48% ；在未来，AWS可能会把其大部分服务器迁移 到基于ARM的处理器。到2030年ARM或将成为新的处理器标准采用ARM处理器的PC和服务器将创建第一个具有足够 规模、丰富工具和供应商支持的生态系统，来挑战英特 尔的x86架构 ；2020年，全球服务器市场约912亿美元，同比增长4.2%， 出货量约1218万台。中国服务器市场出货量为350万台， 同比增长9.8%，厂商收入达到227.5亿美元，同比增长 19.0%；ARM服务器的收入可以扩大100倍，从2020年不到10亿 美元到2030年的1000亿美元，甚至比今天的x86更高的 水平。同时，RISC-V也可以做出非常有意义的贡献；与大型处理机一样，安装X86的电脑市场规模可能会继 续扩大，但其收入可能相比现在会被削减一半。到2030年，硬件加速器（Accelerator)或将取代CPU成为主要的服务器计算引擎如GPU、张量处理单元（TPU）和现场可编程门 阵列（FPGA）等硬件加速器可以执行最大算量的 计算任务，包括人工智能（AI）、数据分析、药 物开发和云游戏。尽管竞争激烈，但我们相信GPU凭借其无可比拟 的可编程性和软件堆栈(Softwaare stack)，在未来 五年内仍将继续主导硬件加速器市场。二、全球软件产业趋势——开源软件正在改变IT行业开源软件正在改变 IT 行业开源是当今基础软件在全球范围内取得成功最优路径。全球软件应用的四次浪潮：IBM为代表的软硬件一体大型计算机系统；客户端/服务器端系统架构、软硬件分离牵引独立 商业软件迅猛崛起；云计算带来技术架构和软件商业模式变化，并催生一批SaaS、PaaS软件公司；开源带来生态巨大繁荣 和商业模式创新。过去10年，开源软件商业化能力得到市场正向反馈，企业估值持续高涨。开源软件项目纷纷成立开源软件公司，进入商 业化运营，开源软件开始更多侧重企业级商业化 应用 ；开源软件公司逐渐找到或者创新商业模式，并 被市场和用户所接受认可；庞大的用户基数和生态基础带来开源软件公司 营收的高速成长，叠加创新的商业模式，高成长 高估值。开源软件市场流行度逐渐超越商业软件。过去10年开源license数据库流行度（一定程度代表使用度）逐步接近商业license数据库。2013年，开源license数据 库流行度/受欢迎程度明显落后于商业license数据库，自2013年以来开源数据库受到市场持续关注追捧，流行度呈现 不断上升趋势。2021年，开源数据库流行度已经超过商业数据库。云计算也在加速改变软件行业SnowFlake做对了什么？技术选择：高性能和拓展性，Snowflake定位于云原生OLAP，并将OLAP传统架构的计算和存储分离，用户可以更灵 活地选择服务级别，而公有云部署方式能够根据需求快速增减节点数量商业模式：在Snowflake前，OLAP通常是公有云PaaS服务， 而Snowflake做成了支持多云的SaaS产品，简单易用。云 服务一般有两种收费模式：资源预留、包月包年与按量付费。与传统的SaaS公司不同，Snowflake是根据计算量*时长 计费定价的。销售方式：Snowflake总结自己的Go-To-Market (GTM) 就是针对大企业高层的direct sales，这种销售模式成本高，导致 它的销售占比是在SaaS公司中是最高的。SnowFlake营收持续增长SnowFlake上市以来，营收持续翻倍增长，2021Q1-Q3实现营收8.36亿美金，同比增长73.31%，预计今年全年收入达到11.3亿 美金，同比增长103%，公司整体毛利率74%。三、数据库行业演进基于提供者和数据存储单元位置/数量的发展路线数据库发展经历了三个时代：商业数据库时代（商业软件行业）→ 开源数据库时代（互联网）→ 云数据库时代（云企业和 轻型数字化企业）；从数据存储单元位置/数量发展路线演进：单机→集群部署→分布式→ 云原生。基于数据存储处理类型结构化数据（关系型/SQL）→ 非结构化数据（非关系型/NoSQL）→异构数据（大数据/多模数据）；图片、语音等非结构化数字的处理量增加带来的产品变化。云上&分布式数据库成为新秀从业务需求来讲，数据库是云上应用的关键 一环，数据库作为IaaS+PaaS的核心构件和服 务之一，必须能够满足自身业务和企业级云服 务要求；从技术能力和应用场景来看，互联网公司技 术外溢以及日益增长的高并发高吞吐应用场景， 能够持续拉动数据库系统的日益完善 ；从全球数据库产业格局来看，互联网厂商的 分布式交易型数据库成为产业最大黑马，Ama zon、Alibaba、Google市场份额进入TOP10， Tencent也进入全球TOP15。（报告来源：未来智库）四、国产数据库技术路线与发展国内数据库的四类技术路线目前来看，在商业数据库市场，我们相对看好基于开源代码重构和类Oracle模式的产品，其中阿里、TiDB主要是基于MySQL 等开源软件重构，华为基于PG（PostgreSQL）重构，头部互联网公司多数基于MySQL。开源协议限制条件存在差异，国内首个开源协议木兰诞生BSD因协议更为友好，选择PG为基础的商业数据库较多。MySQL适应互联网交易型分布式场景，也是互联网/分布式应 用的主流技术路线选择 ； 由北京大学牵头，联合华为、BAT和国内知名开源研发团队，众多开源社区与中国开源联盟共同研制而成的中国首个 开源协议“木兰”，也是中国首个国际通用的开源协议。国内数据库三类商业路径国内数据库市场，开源软件和商业软件并存，开源数据库越来越多，但是最终会走向收敛。国产数据库推进力：开源、分布式、云计算、国产化国内互联网快速发展推动国产数据库前进开源软件社区（PostgreSQL、MySQL、MongoDB、Hive、Impala等）的快速发展和繁荣，使得国产数据库发展具备了强 大的技术和生态基础；互联网、头部科技企业的高并发大吞吐业务场景，集群式架构无法满足，促使其自研分布式/云数据库产品以适应业务 高速发展需要，而事实也取得了成功（2019双11在线支付成功峰值达到54万）。伴随IT架构向分布式迁移以及国产化应用推动，国产分布式数据库中标和投产应用逐步起势。国产化需求发展推动国产数据库前进2014年，微众银行+TDSQL上线，成为分布式数据库在互联网银行核心交易系统的应用首例，1700+台x86服务器，3.46亿+ 日金融交易峰值 ；2018年，华为Gauss OLTP数据库在招商银行综合支付交易系统上线投产， 日均请求量高达8500万， 峰值TPS达到3500 ；2019年，张家港银行+TDSQL，成为分布式数据库在传统银行核心系统应用首例，同等TPS下，硬件成本仅为商业数据库1/5 ；2020年，国产数据库投产应用已经多点开花，基本集中在金融、电信和政务领域，且规模体量及核心业务系统开始增长。 传统数据库厂商受益于办公国产化开始全面推广，迎来了业绩翻倍式增长。国产数据库市占率持续提升关系型数据库市场，国内产品市占率从 2009 年的 4.2%提升至 2019 年的 18.9%。自 10 年前后提出“去 IOE”和 13 年棱镜 门事件影响后，我国一直在推动国产数据库持续扩张，近 3 年海外四巨头在国内市占率仍维持在 65%以上份额。从国内市场结构看，公有云厂商提供的云数据库产品及服务预计达到一半左右的市场份额。数据库——国产化应用中软件投资占比最高的单品服务器端软件生态链较短，对前端用户透明，云架构下对原有X86架构兼容使得服务器端国产化客观上阻力较小；2021年金融国产化投资中：服务器占据硬件36%的投资额；数据库占据软件57%的投资额。数据库是竞争最激烈的国产软件赛道数据库厂商将要面对的现实。 国产产品目录设置了围墙，最凶狠的一批玩家目前还没有进入，随着目录不断扩容、国产化走向深水区、用户关注 产品服务能力，从2022年开始国产数据库真正的战争将拉开大幕。 技术路线选择和坚持只是开始，随之而来的是交付实施（系统迁移工具、交付管理平台、产品版本迭代），而生态 和人才的培养是最大短板。 稳健是胜出的必要但不充分条件，纯商业市场竞争要求性能好、迁移快、系统稳、低成本和代表性案例。五、投资分析：未来5年是国产数据库的主战场云、开源数据库估值往往高于传统数据库市场对云数据库的估值溢价远高其他类型。以Snowflake为例，因其数据库具备数据共享、多云架构、运行效率高，毛利 率虽低于传统License的形式，但其高速成长性（100-200%的营收增速），高留存率（120%），市场给予近37-44X ps； 参考美国云计算公司估值水平，30%增速对应10X PS( 隐含条件 30%净利润率 30XPE), 50%增速对应 15X PS (30%净利 润率 50XPE），50%以上的增速则可以基于给予更高的估值。 以Lisence售卖+项目建设的数据公司，一般成长期的公司会根据PEG=1动态调整，成熟期的公司的PE水平多在25-30X；openGauss有望成为国内最主流的数据库技术路线，商业版公司有望脱颖而出目前openGauss社区合作伙伴主要有海量数据、神舟通用、云和恩墨、人大金仓等，60多家单位加入社区组织。 openGauss数据库在2020年6月开源至今，已有12家伙伴基于openGauss发布了商业发行版，其中海量数据、云和恩墨、神 舟通用等伙伴已经实现在政府、电力、制造、能源等行业的规模化应用，其中海量数据Vastbase G100、云和恩墨MogDB、 沐融科技MuDB三家公司推出的商业发行版产品通过了openGauss社区认证。达梦、金仓充分受益国产化红利，在办公国产化市场份额领先过去两年，数据库公司营收开始跃升。2019年之前，达梦数据库营收基本在2亿左右，从2019年办公国产化应用推广开 始，公司营收达到2.72亿，同比增长约30%。2020年办公国产化应用大规模启动，达梦收入创历史新高达到4.25亿，收入 规模效应也带来净利润释放，净利率达到30%；2021年预计达梦收入约7亿，净利润约2亿。2021H1达梦实现营收2.07亿元，同比增长245%，净利润0.89亿，相对去年同 期扭亏为盈，净利率高达45%。截止2021年9月底，达梦数据库出货量约1.4万套，全年预计出货达到2万套，我们预计 2021年达梦收入6-7亿。展望未来，办公应用的服务器需求小，随着电子政务、行业应用国产化带动，服务器端国产软件 将保持较高增长；人大金仓2020年收入同比增长183%达到2.41亿元。2019年，人大金仓营收0.85亿元。2020年伴随办公国产化市场推广， 公司营收达到2.41亿元。2021年随着市场规模扩大，预期公司收入3-4亿元，同时软件产品规模效应有望显现，预计公司 净利润有望达到1亿元。目前海量数据是华为openGauss社区唯一金牌合作伙伴，看好公司未来发展海量数据All-In openGauss战略：海量数据目前在openGauss开源社区中贡献度排第二，仅次于华为，是最深度参与开源 社区的发行版公司，也是华为openGauss唯一的金牌合作伙伴，凸显了公司的产品商业化和服务能力，而开源社区的发 展和成熟离不开发行版公司的深度和专业度投入；（报告来源：未来智库）华为加持：华为打造国家级根技术开源社区，将在研发方面支持openGauss商业发行版公司，市场销售端也将给予商业 版产品应用推广支持；唯一入围国产采购目录的openGauss商业版公司：海量数据自主研发的基于openGauss的商业版数据库软件Vastbase在 2021年中入围国产产品采购目录。我们预计2021-2023年公司自主数据库Vastbase软硬件收入分别达到1、3、5亿元，我们 参照国产软件公司当前估值，给予公司2023年20x PS估值，中长期看好公司发展。来源：未来智库