>摘要：NFT是Web3世界中标记数据资产独特性的标识，是数据权益的载体。 本文分享自华为云社区《[加密数字艺术NFT背后你关心的六个问题](https://bbs.huaweicloud.com/blogs/358470?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者： 薛腾飞 。 # Connect Wallet 这是Web3中非常流行的一句话，其实也是Web3的核心要义，即“**以用户为中心**”。将身份主权、数据主权、数据权益等都归还给用户，身份的解释、移植，数据的确权、授权、使用等都需要各个服务通过“链接”用户的“钱包”来完成。以区块链为基础设施构筑上层应用，是实现这一能力的重要保障。 # 什么是NFT？ 在我看来，**NFT是Web3世界中标记数据资产独特性的标识，是数据权益的载体**。不论是数字化的画作，桌椅、服装、汽车飞机等(有实物的)，还是数字化的身份凭证、产权、公司品牌等(逻辑产物)都可以是NFT。 **独特性的标识为什么这么重要呢**？因为它能将其指代的物品和其他同类物品区分开。 为了进一步理解，首先要明确，有些物品是非同质的(Non-Fungible)需要被区分开的，例如房屋产权和艺术作品。有些物品是同质的，不需要被区分开，例如人民币和app积分，尽管有不同的编码，但编码不影响互相替换，因为面值一样；其次要区分开标识和标的物，标的物可以是区块链上原生的数据或者本身是数字化的，也可以是物理世界实际存在的物品，标识则是标的物在数字世界中的映射。 在数字世界中，“标识”将完成“标的物”独特性的指代和“标的物”价值承载的使命。例如一个艺术家将数字作品发布在社交平台，其作品会很快被复制多份，每一幅作品逐渐趋于同质化，没有区别。画作的价值也会越来越低，且没有人会知道画作的原作者是谁。但在Web3中，艺术家就可以通过NFT低成本的保证作品的独特性和价值，NFT中会有作品铸造时间、创建者、和当前所有者。只要是晚于铸造时间发布的都为抄袭者，画作所有权每次流转都可以承载不同的价值属性，无论流转多次都知道原作者谁。  # NFT能用来做什么？ 海外市场NFT产业布局完善，行业竞争激烈。NFT以交易平台和时尚社交为主，NFT收藏、游戏、金融等同步发展。国内以数字藏品收藏和企业数字营销为主，逐步开始尝试数字人、游戏等。除此之外，NFT的应用场景还包括体育、文物和历史、音乐、票务等访问授权类。 ## 1.收藏品 稀缺性是收藏品的重要属性。区块链的不可篡改以及NFT本身的不可分割保证了数字藏品独特性。与球卡和邮票一样，数字收藏品的藏家会收藏他们认为有价值的数字产品以表示对某一公司、品牌或者游戏支持。有别于实物，无需运输时间，维护成本等开销。只需几秒完成转移，且永远不会折旧。CryptoPunks是以太坊上推出的最早的数字藏品NFT，类似的国内多家互联网平台联合博物馆、航天局等单位，发行了多款数字藏品，例如“故宫故苑”和“航天文创”。 ## 2.游戏 NFT是区块链游戏的基础，可以作为数字游戏世界中成就或游戏物品的所有权证书。移独一无二游戏物品(道具、头像、皮肤、角色等)归玩家所有，且无需托管，不受发行商控制。这些NFT的寿命会比游戏平台本身更长，一方面玩家可以永久收藏，另一方面也可以移植到游戏之外其他平台，实现游戏投入变现。 ## 3.数字营销 NFT“限量发行、独一无二”本身就是一种最好的饥饿营销手段，不定期的赋予每个NFT新的权益，发布新的玩法和活动也都是很好的营销策略。还可以基于NFT维护会员制度、增强用户粘性，完成破圈整合。国内有个很有趣、很有现实意义的的实践。福建省四坪村通过NFT吸引“云村民”并赋予权益，赋能乡村振兴。每一位数字藏品持有者可以作为村民享受多项权益，如享有家宴1次。不同时间不同事件还会解锁新的藏品及权益，丰富有趣。 ## 4.艺术品 在众多的艺术品中，我们以音乐为例，音乐产业是一个超级明星经济， 好的作品诞生涉及音乐人、唱片公司、娱乐公司、经纪人等。NFT可以帮助音乐人收益自主、拓宽收入来源；公平解决所有制作人员间的版税问题，交易中的数字所有权问题等。 除此之外，NFT音乐平台的用户运营，音乐演出的票务活动，知识产权保护等都已有很多创新项目在实践。 # 国内NFT技术产品有哪些？ 随着NFT的火热，国内数字藏品发行平台百花齐放。据统计，其中注册资本大于500万的平台超过100家。市场繁荣的背后是几大技术供应商在提供底层区块链和NFT管理等相关技术能力，以联盟链为主，公链为辅。  # NFT 背的技术是什么？ 知道了NFT是什么?能用来做什么?以及都有谁来参与之外，我们再来了解一下NFT背后的技术都有哪些。 ## 1.区块链 区块链是实现NFT的重要底座，赋予了NFT不可篡改、所有权明确、流转可追溯等特性。区块链融合了多种技术，包括密码学(加密算法、安全协议)、分布式共识算法(拜占庭或非拜占庭)、P2P网络通讯、智能合约、激励机制等。 应用的繁荣必将带动技术的生长。NFT应用的快速增长，大量用户接入区块链完成NFT的铸造发行、授权、流转等。这对传统的底层区块链提出了新的挑战和要求。 - 具备统一的链上用户身份标识，支持跨链、链跨应用的NFT所属权管理。 - 允许千级、万级节点接入，支持NFT平台发行方等加入链生态的构建与维护。 - 高吞吐，高并发的共识和记账能力，可以支撑NFT应用活动的峰值流量。 ## 2.智能合约协议 ERC（Ethereum Request for Common）“版本征求意见稿”是以太坊社区的开发者共同编写的，用来记录以太坊上应用级的各种开发标准和协议。其中一些技术标准和协议也逐渐成为了区块链应用的事实规范。 我们常提到的NFT就是在ERC-721标准提出后才开始普及流行的。ERC-721详细定义了NFT的所有权查看、授权管理、流转等。不同的数字藏品平台基于同样的协议完成设计，理论上就可以进行标准化的操作和解析。 随着对NFT的需求越来越丰富，社区也在不断提出新的标准来扩展NFT的使用场景和内涵：  ## 3. 去中心化存储 “一切皆可NFT”这句话从侧面表达了NFT对数字化数据的包容性。不论标的物是视频、音频、还是文字、图片、3D模型等各种数据格式，都可以在链上生成对应的唯一标识。标的物实际存储的位置通常有三种选择，NFT标识所在的业务区块链、去中心化存储系统、中心化的存储系统。  对于NFT而言，去中心化存储是最好的选择。它具有强隐私保护、低存储成本、高访问速度、数据冗余备份、开源等特点，可以充分的支撑Web3“以用户为中心”这一要义的表达。数据被加密并存储在多个位置或节点上，不依赖与中心化的存储节点和存储服务，下图可以极简的理解去中心化存储的工作原理。  值得关注和学习的几大去中心化存储产品有：  ## 4.应用生态 不难发现NFT发展背后的主要推动力就是用户对数据主权和数据价值自主控制意识的不断增强。构建完善的NFT应用生态，简单可以分为三层，身份协议层、 NFT合约协议层， 扩展应用协议层。 分布式数字身份真正具备身份的自主可控性、安全性、自解释性、可移植性、互操作性。在分布式场景下赋予每个用户自主控制和使用数字身份的能力，并针对身份数据等敏感信息进行隐私保护。基于分布式身份， NFT相关协议可以与多种扩展应用标准化集成。（详细了解可阅读《[区块链分布式身份技术解密——重新定义你的“身份”管理](https://bbs.huaweicloud.com/blogs/234838)》） 在标准化的身份协议层和NFT合约协议层之上，结合多样的业务场景定会生长出丰富的应用，例如可信数据交换、数据要素管理等。 # 如何发行自己的NFT 不论你是团队还是个人，想要发行自己的NFT都非常简单。 一种，是可以使用基于公链模式的数字自资产服务，支付手续费或者链使用费铸造发行NFT。例如支持多种公链的Opensea平台 另一种，可以使用基于联盟链模式的数字资产服务，订购服务通过集成SDK完成NFT的铸造发行及流转。例如[华为云的数字资产链服务](https://www.huaweicloud.com/product/bcs/dac.html)。

过去十年见证了分布式数据库的崛起不仅通过本地集群来实现负载均衡，并提供高可用性，还具有数据中心内的机架感知等属性。专为云而设计的分布式数据库，可以跨越可用性区域，通过编排技术，支持公有云、私有云、混合云部署。近年来，市面上出现了大量专为分布式数据库部署而设计的新数据库系统，以及在初始设计中添加了分布式架构组件的其他数据库系统。DB-Engines排名前100的数据库DB-Engines是数据库领域的权威排行榜，它保留了所有数据库的流行指数，使用一种算法进行加权，监测诸如网站上的提及次数和谷歌的搜索趋势，Stack Overflow上的讨论或推特中的评论，工作职位要求的技术技能，以及在LinkedIn个人资料中提到这些技术的数量。虽然DB-Engines收集了数百个不同的数据库（截至2022年5月共有394个）。但是本文我们缩小范围，只观察前100名数据库。在很大程度上，反映了市场现状。关系型数据库管理系统（RDBMS），传统的SQL系统，仍然是最大的类别，占列表的47%。另外，列表中有25%是NoSQL系统，涵盖了许多不同类型的数据库，像MongoDB文档数据库、Redis键值系统、ScyllaDB宽列数据库，以及Neo4j图数据库。还有11%的数据库被列为多模型数据库，包括在同一系统中支持SQL和NoSQL的混合数据库，如微软的Cosmos DB或ArangoDB，或者支持多种NoSQL数据模型的数据库，如DynamoDB，它将自己列为NoSQL键值系统和文档存储。最后，还有一些是由各种特殊用途的数据库组成，从搜索引擎到时间序列数据库，以及其他不容易归入简单的“SQL与NoSQL”区域的数据库。但是所有这些数据库都是分布式数据库吗？这个词到底是什么意思？分布式数据库的定义2016年12月14日，ISO/IEC发布了最新版本的数据库语言SQL标准（ISO/IEC9075:2016）。随着时间的推移，如何构建与SQL兼容的分布式RDBMS系统一直在发展。分布式SQL，如PostgreSQL或CockroachDB NewSQL系统。相反，没有ANSI或ISO或IETF或W3C定义什么是NoSQL数据库。每种数据库都使用自己的专有查询语言，比如用于宽列NoSQL数据库的Cassandra查询语言（CQL），用于图形数据库的Gremlin/Tinkerpop查询方法。然而，它们并没有定义数据如何在这些数据库中分布，查询语言也不能解决架构问题。因此，无论是SQL还是NoSQL，对于什么是分布式数据库，并没有标准、协议或共识。因此，我花了一些时间来写下我自己的定义。坦率地说，这更像是一个门外汉的实用主义观点，而不是计算机科学教授的见解。简而言之，你必须决定你如何定义集群，以及如何跨集群分配数据。接下来，你必须确定集群中每个节点的角色。每个节点都是对等的，还是有些节点处于更优越的领导地位，而其他节点则是跟随者。然后，基于这些角色，你如何处理故障转移？最后，你必须在此基础上，弄清楚你如何尽可能均匀和容易地复制和分片数据。而这并不试图做到详尽无遗，你可以添加自己的特定条件。简短的清单：感兴趣的系统考虑到这些，我在前100名数据库中，找到五个示例，看看它们在测量属性时是如何比较的。其中有两个SQL系统和三个NoSQL系统。Postgres和CockroachDB代表最好的分布式SQL。CockroachDB被称为 NewSQL，专为分布式数据库而设计。MongoDB、Redis和ScyllaDB是分布式NoSQL，分别是文档数据库，键值存储，宽列数据库（也被称为键值数据库）。在大多数情况下，适用于ScyllaDB的也同样适用于Apache Cassandra和其他与Cassandra兼容的系统。假定你拥有专业的经验，而且对SQL与NoSQL的区别相对了解。基本上，如果需要一个表JOIN，坚持使用SQL和RDBMS。如果你可以将数据反规范化，那么NoSQL可能是一个很好的选择。我们不打算讨论作为数据结构或查询语言，两者哪个“更好”。而是讨论作为一个分布式数据库，哪个更好。多数据中心集群我们的选项在集群方面是如何比较的？现在，它们都能够进行集群，甚至是多数据中心操作。但是在PostgreSQL、MongoDB和Redis中，它们最初设计于单数据中心本地集群，在多数据中心设计之前就已经成为一种架构要求。Postgres首次发布于1986年，完全早于云计算的概念。后来，它允许在其设计上，纳入这些技术和能力。作为NewSQL革命的一部分，CockroachDB从一开始就考虑到了全球分布。MongoDB是在公有云诞生之初发布的，最开始设计时考虑到了单数据中心集群，但现在已经增加了对许多不同拓扑结构的支持。通过MongoDB Atlas，可以轻松部署到多个地区。Redis，由于其低延迟的设计，通常被部署在单个数据中心，但它具有允许多数据中心部署的企业特性。ScyllaDB，像Cassandra一样，从一开始就考虑到了多数据中心的部署。集群管理如何进行复制和分片，取决于数据库架构的分层或同质化程度。例如，在MongoDB中，有一个主服务器，其余的是主服务器的副本。副本是只读的，你只能对这个数据库的主副本进行写操作，不能直接更新。相反，你写到主数据库，它就会更新副本。所以，节点是异质的，而不是同质的。这有助于在读取繁重的工作负载中分配流量，但在混合或写入工作负载中，对你没有一点好处，主服务器可能会成为一个瓶颈。同样，如果主服务器发生故障会怎样？你将不得不完全停止写操作，直到集群选出一个新的主服务器，并将写操作分流到它上面。相反，如果ScyllaDB或Cassandra，或任何其他无active-active的系统，客户可以从任何节点读取或写入。没有单一的故障点，节点的同质化程度要高得多。而且每个节点都可以更新集群中的任何数据副本。因此，如果你有三个节点，每个节点都会根据其他两个节点的任何写入进行更新。active-active在计算方面本身就比较困难，但是一旦解决了服务器保持彼此同步的问题，就会得到一个可以更好地平衡混合或写入大量工作负载的系统，因为每个节点都可以提供读取或写入服务。那么，我们的各种例子在主复本或active-active对等方面是如何叠加的？CockroachDB和ScyllaDB，以及Cassandra一开始就考虑了active-active的主动式设计。在Postgres中，有一些可选的方法可以做到这一点，但它不是内置的。此外，MongoDB没有正式支持active-active，但是已经有一些人在尝试如何做到这一点了。对于Redis来说，active-active模型在Redis企业中可以通过无冲突复制数据类型（CRDTs）实现。Postgres、MongoDB和Redis都默认使用主副本数据分布模型。复制分布式系统设计也会影响如何跨部署到不同机架或数据中心之间分配数据。例如，给定一个主副本系统，只具有主的数据中心可以为任何写入工作负载服务，其他数据中心只能作为只读副本。在一个支持多数据中心集群的点对点系统中，整个集群中的每个节点都可以接受读或写操作。通过ScyllaDB，你可以决定每个站点有相同或甚至不同的复制因素。这里我展示了在一个数据中心的三个副本，在另一个数据中心有两个副本的可能性。操作可以有不同级别的一致性。你可能在三个节点的数据中心进行本地数据的读或写，需要更新任一数据中心的节点才能成功执行操作。可调整的一致性，结合多数据中心的拓扑感知，为工作负载提供更多的灵活性。拓扑感知本地集群是分布式数据库开始的方式，允许多个系统共享负载。如果想让数据库在多个节点上进行分片，或者通过确保相同的数据在多个节点上可用来实现高可用性，那么这一点非常重要。如果所有节点都安装在同一个机架上，一旦这个机架发生故障，就会很棘手。因此，添加拓扑感知，以便你可以感知同一数据中心内的机架。确保将数据分散在数据中心的多个机架上，从而最大限度地减少电源或连接丢失到一个或另一个机架的中断。有些数据库做的很好，允许在不同的数据中心运行数据库的多个副本，并使用某种跨集群更新机制。每个数据库都是自主运行的，它们的同步机制可以是单向的，一个数据中心更新一个下游的副本，也可以是双向的或多向的。这种地理分布可以通过允许更靠近用户的连接，来减少延迟。跨可用性区域或地区的数据库，还可以确保单个数据中心灾难不会导致数据库的部分或全部丢失。去年我们的一个客户就发生了这种情况，但由于他们部署在三个不同的数据中心，所以数据损失为零。跨集群更新最初是在批量级别上实现的。确保你的数据中心每天至少有一次同步。这并没有持续多久，后面人们开始确保更活跃的事务级更新。如果你在运行强一致性数据库，就会受到基于光速的实时传播延迟的限制。因此，实现最终一致性是为了允许每个操作更新使用多数据中心，同时考虑到在短期内，要使所有数据中心的数据保持一致可能需要时间。那么，在拓扑感知方面，它是如何叠加的？所以，CockroachDB和ScyllaDB也是内置的。从2015年开始，拓扑感知也成为MongoDB的一部分，他们在这方面有着多年的经验。Postgres和Redis最初被设计为单数据中心解决方案，因此处理多数据中心的延迟对两者来说并非易事。现在，你可以添加拓扑感知，就像添加active-active系统功能一样，但它并不是开箱即用的。让我们回顾一下所讨论的内容，分别查看这些数据库的属性。▶︎ PostgreSQLPostgreSQL是世界上最流行的的开源数据库之一，它以可靠性和稳定性而著称,在处理复杂SQL方面也表现出了绝对的优势。然而，Postgres仍在研究其跨集群和多数据中心的集群。由于SQL基于强一致性事务模式，所以它不能很好地跨地域跨集群。在所有相关的数据中心之间，每个查询都将由于长时间的延迟而暂停。此外，Postgres依靠的是主副本模型。集群中的一个节点是领导者，而其他节点是副本。虽然有负载平衡器或active-active插件，但这些也超出了基本的服务范围。最后，Postgres的分片在大多数情况下仍然是手动的，尽管他们在开发自动分片方面取得了进展，但这也超出了基本产品的范围。▶︎ CockroachDBCockroachDB声称自己是“NewSQL”，一个专为分发而设计的SQL数据库。它可以水平扩展，在磁盘、机器、机架，甚至数据中心故障时都能生存下来，做到延迟最小，无需手动干预。值得一提的是，CockroachDB使用Postgres线协议，并大量借鉴了Postgres开创的许多概念，而且并不局限于Postgres的架构。多数据中心集群和点对点的拓扑结构从一开始就被内置。自动分片和数据复制也是如此。它还内置了数据中心感知功能，而且还可以添加机架感知功能。对CockroachDB来说，它要求所有的事务都有很强的一致性，你可以把它看作是一个优点或缺点。既没有最终一致性的灵活性，也没有可调的一致性。这将降低吞吐量，并在任何跨数据中心部署中要求较高的基线延迟。▶︎ MongoDBMongoDB是NoSQL领域的领导者。随着它的发展，大量的分布式数据库功能被添加。现如今，MongoDB能够支持多数据中心集群。在大多数情况下，它仍然遵循主副本模式，也有办法使其成为对等的active-active。▶︎ Redis接下来是Redis，一个旨在作为内存缓存或数据存储的键值存储。Redis的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。虽然持久化保存数据，但如果数据集不适合放在RAM中，它就会遭受巨大的性能损失。正因为如此，它在设计时考虑到了本地集群。如果你无法承受5毫秒的等待时间来从SSD上获取数据，您可能更无法等待145毫秒来完成从旧金山到伦敦的网络往返时间。然而，有一些企业特性允许多数据中心的Redis集群。Redis在大多数情况下是以主副本模式运行的。这适用于大量读取的缓存服务器。但这意味着，主节点是数据需要首先写入的地方，然后将这些数据分散到副本，以帮助平衡其缓存负载。有一个企业功能，允许对等的active-active集群。Redis可以自动分片和复制数据，但它的拓扑感知仅限于作为企业功能的机架感知。▶︎ ScyllaDBScyllaDB是按照Apache Cassandra中的分布式数据库模型设计的。因此，它默认是多数据中心集群。它可以自动分片，并且每个操作都有可调整的一致性，如果你想要更强的一致性，它甚至还支持轻量级事务来提供写入的线性化。就拓扑感知而言，ScyllaDB支持机架感知和数据中心意识，甚至支持标记感知和分片感知，不仅知道数据存储在哪个节点上，甚至可以知道与该数据关联的CPU。结论虽然对于什么是分布式数据库，还没有一个行业标准，但是我们可以看到，许多领先的SQL和NoSQL数据库，都在某种程度上支持一组核心功能或属性。其中有些功能是内置的，有些被认为是增值包或第三方选项。在本文分析的五个典型分布式数据库系统中，CockroachDB为SQL数据库提供了最全面的功能和特性，ScyllaDB为NoSQL系统提供了最全面的功能。该分析应被视为某个时间段的调查。鉴于下一个技术周期的需求，每一个数据库系统都在不断发展，这个行业并没有停滞不前。对用户来说，分布式数据库每年都在进步，变得更加灵活、性能更强、更具弹性和可扩展性。来源：今日头条

节点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 的总连接数。

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/