基于Raft分布式一致性协议实现的局限及其
对数据库的风险
普通服务器具有良好的性价比，因此在互联网等行业得到了广泛的应用。但普通服务器也不得不面对2%-4%的年故障率([1])，于是必须高可用的传统数据库只得很悲催地使用性价比低得可怜的高可靠服务器。
分布式一致性协议（distributed consensus protocol）是迄今为止最有效的解决服务器不可靠问题的途径，因为它使得一组服务器形成一个相互协同的系统，从而当其中部分服务器故障后，整个系统也能够继续工作。而Paxos协议([2])则几乎成了分布式一致性协议的代名词。
然而，Paxos协议的难以理解的名声似乎跟它本身一样出名。为此，Stanford大学的博士生Diego Ongaro甚至把对Paxos协议的研究作为了博士课题。他在2014年秋天正式发表了博士论文：“CONSENSUS: BRIDGING THEORY AND PRACTICE”，在这篇博士论文中，他们给出了分布式一致性协议的一个实现算法，即Raft。由于这篇博士论文很长（257页），可能是为了便于别人阅读和理解，他们在博士论文正式发表之前，即2014年初，把Raft相关的部分摘了出来，形成了一篇十多页的文章：“In Search of an Understandable Consensus Algorithm”，即人们俗称的Raft论文。
Raft算法给出了分布式一致性协议的一个比较简单的实现，到目前为止并没有人挑战这个算法的正确性。然而，OceanBase却没有采用Raft算法，这并非是OceanBase团队同学不懂Raft，而是Raft的一个根本性的局限对数据库的事务有很大的风险。
Raft有一个很强的假设是主（leader）和备（follower）都按顺序投票，为了便于阐述，以数据库事务为例：
1）主库按事务顺序发送事务日志
2）备库按事务顺序持久化事务和应答主库
3）主库按事务顺序提交事务
由于不同的事务可能被不同工作线程处理，事务日志可能被不同的网络线程发送和接收，因为网络抖动和Linux线程调度等原因，一个备库可能会出现接收到了事务日志#5-#9，但没有接收到事务#4，因此#5-#9的所有事务都需要hold住（在内存），不能持久化，也不能应答主库：
#1-#3为已经持久化和应答的事务日志
#5-#9为已经收到但却不能持久化和应答的事务日志
#4为未收到的事务日志。
顺序投票策略对于主库的负面影响比较严重：出于性能提升的原因，数据库的多版本并发控制（MVCC）使得不存在相互关联的事务得以并发处理，但上述顺序投票策略使得事务#5-#9可能被毫不相干的事务#4阻塞，且必须hold在内存。
顺序投票策略对于多表事务的影响很大：设想一个事务涉及到三张表A，B，C，其中一个事务被顺序投票策略阻塞了，那么表A、B、C上的其他单表和多表事务都会被阻塞，假如A又跟表C、表D有多表事务，B和表E、表F有多表事务，C和表D、表G有多表事务，那么很多表上的事务，包括单表和多表的事务，都会被阻塞，形成一个链式反应。
顺序投票策略对于跨服务器的多表事务（分布式事务）的影响极大：由于事务日志需要在多个表相关的多台服务器之间同步，日志发送与接收之间的顺序更加得不到保证，许多的单表和多表的事务都可能被阻塞，包括链式反应的阻塞甚至循环阻塞，不仅增加事务延迟，甚至可能导致内存耗尽。
顺序投票策略的另外一个负面作用是对故障恢复的影响。由于分布式一致性协议必须有多数派才能正常工作，所以一个参与者故障后，系统应该尽快补上一个参与者，确保系统不会因为下一个参与者故障致使多数派协议被破坏，从而导致已经应答了客户的事务数据的丢失等非常严重的问题。由于单台服务器通常服务成千上万的表格，对每个表格分别写事务日志（redo log）会导致很低的性能，而从混合在一起的事务日志中提取部分表格的日志有不小的工作量，从而导致新的参与者的延迟。
Raft的上述顺序投票策略，是Raft算法的基础之一，如果抛弃它，则Raft算法的正确性无法得到保证。对于数据库之外的场景，上述缺陷可能没有很大的影响，但对于高峰期每秒钟处理成千上万的事务的数据库，是一个无法忽视的潜在性能和稳定性风险。
[参考文献]
1. SCHROEDER, B., AND GIBSON, G. A. Disk failures in the real world: what does an
MTTF of 1,000,000 hours mean to you? In Proc. FAST’07, USENIX Conference on File and Storage Technologies (2007), USENIX, pp. 1–16.
2. LAMPORT, L. The part-time parliament. ACM Transactions on Computer Systems 16, 2(May 1998), 133–169.
分布式设计与开发（二）------几种必须了解的分布式算法 分布式设计与开发中有些疑难问题必须借助一些算法才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： ?Paxos算法 ?一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的Paxos Made Simple是学习paxos 最好的文档，它并没有像大多数算法文档那样搞一堆公式和数学符号在那里吓唬人，而是用人类语言让你搞清楚Paxos要解决什么问题，是如何解决的。这里也借机抨击一下那些学院派的研究者，要想让别人认可你的成果，首先要学会怎样让大多数人乐于阅读你的成果，而这个描述Paxos算法的文档就是我们学习的榜样。 言归正传，透过Paxos算法的各个步骤和约束，其实它就是一个分布式的选举算法，其目的就是要在一堆消息中通过选举，使得消息的接收者或者执行者能达成一致，按照一致的消息顺序来执行。其实，以最简单的想法来看，为了达到大伙执行相同序列的指令，完全可以通过串行来做，比如在分布式环境前加上一个FIFO 队列来接收所有指令，然后所有服务节点按照队列里的顺序来执行。这个方法当然可以解决一致性问题，但
２００７年第２４卷第１０期微电子学与计算机 １引言 分布式数据库系统在系统结构上的真正含义是指物理上分布、逻辑上集中的分布式数据库结构。数据在物理上分布后，由系统统一管理，用户看到的似乎不是一个分布式数据库，而是一个数据模式为全局数据模式的集中式数据库［１￣５］。 分布式数据库系统包括两个重要组成部分：分布式数据库和分布式数据库管理系统。分布式数据库系统具有位置透明性和复制透明性，使用户看到的系统如同一个集中式系统。分布式数据库系统分为三类：同构同质型ＤＤＢＳ、同构异质型ＤＤＢＳ和异构ＤＤＢＳ。同构同质型ＤＤＢＳ是指各个场地都采用同一类型的数据模型，并且是同一型号数据库管理系统；同构异质型ＤＤＢＳ是指各个场地都采用同一类型的数据模型，但是数据库管理系统是不同型号的；异构型ＤＤＢＳ是指各个场地的数据模型是不同的类型。 分布式结构是相对于集中式结构而言的。从数据处理的角度来说，典型的集中式结构是数据集中存放和处理，用户通过远程终端或通过网络连接来共享集中存放的数据。分布式结构则是将数据及其处理分散在不同场地，各场地各自管理一部分数据，同时又通过网络系统相互连接。各场地的用户除可以访问和处理本地数据外，也可以访问和处理别的场地的数据。分布式数据库是典型的分布式结构。它包括对数据的分布存储和对事务的分布处理。设计一个分布式数据库系统会遇到许多集中式数据库设计中所没有的问题，一致性是其中必须认真对待和解决的主要问题。 ２ＤＤＢＳ的体系结构 ２．１综合型体系结构 综合型体系结构是指在综合权衡用户需求之后，设计出分布的数据库，然后再设计出一个完整的ＤＢＭＳ，把ＤＢＭＳ的功能按照一定的决策分散配置在一个分布的环境中。每个结点的ＤＢＭＳ均熟知整个网络的情况，也了解其它结点的情况。从整体上，各结点组成一个完整的系统，它们之间是靠进程通讯的手段来维持互访连接，如图１所示。２．２联合型体系结构 联合型体系结构是指每个结点上先有ＤＢＭＳ，以此为基础，再建立分布式环境以实现互访连接。若各个结点的局部ＤＢＭＳ支持同一种数据模式和 分布式数据库系统及其一致性方法研究 刘萍芬，马瑞芳，王军 （西安交通大学电信学院，陕西西安７１００４９） 摘要：分布式数据库系统是数据库领域中的一个主要研究方向，数据一致性维护是分布式数据库系统中的一个非常关键的技术问题。在分析分布式数据库系统体系结构的基础上，讨论了两种一致性方法：两阶段提交和复制服务器，并提出一种具有复制服务器的分布式数据库系统的结构框架，它具有有效性和实用性。 关键词：分布式数据库系统；一致性；两阶段提交；复制服务器 中图分类号：ＴＰ３１文献标识码：Ａ文章编号：１０００－７１８０（２００７）１０－０１３７－０３ ＲｅｓｅａｒｃｈｏｆＤｉｓｔｒｉｂｕｔｅｄＤａｔａｂａｓｅＳｙｓｔｅｍａｎｄＤａｔａＣｏｎｓｉｓｔｅｎｃｙ ＬＩＵＰｉｎｇ－ｆｅｎ，ＭＡＲｕｉ－ｆａｎｇ，ＷＡＮＧＪｕｎ （ＣｏｌｌｅｇｅｏｆＥｌｅｃｔｒｏｎｉｃｓａｎｄＩｎｆｏｒｍａｔｉｏｎＥｎｇｉｎｅｅｔｉｎｇ，Ｘｉ′ａｎＪｉａｏｔｏｎｇＵｎｉｖｅｒｓｉｔｙ，Ｘｉ′ａｎ７１００４９，Ｃｈｉｎａ） Ａｂｓｔｒａｃｔ：Ｄｉｓｔｒｉｂｕｔｅｄｄａｔａｂａｓｅｓｙｓｔｅｍｉｓａｍａｉｎｒｅｓｅａｒｃｈｄｉｒｅｃｔｉｏｎｉｎｔｈｅｄａｔａｂａｓｅｆｉｅｌｄ．Ｍａｉｎｔａｉｎｉｎｇｔｈｅｄａｔａｃｏｎｓｉｓ－ｔｅｎｃｙｉｓａｃｒｉｔｉｃａｌｔｅｃｈｎｉｃａｌｐｒｏｂｌｅｍｉｎｔｈｅｄｉｓｔｒｉｂｕｔｅｄｄａｔａｂａｓｅｓｙｓｔｅｍ．Ｔｈｉｓｐａｐｅｒｄｉｓｃｕｓｓｅｓｔｗｏｍｅｔｈｏｄｓｏｆｍａｉｎｔａｉｎｉｎｇｄａｔａｃｏｎｓｉｓｔｅｎｃｙｂａｓｅｄｏｎａｎａｌｙｚｉｎｇｔｈｅｓｔｒｕｃｔｕｒｅｏｆｔｈｅｄｉｓｔｒｉｂｕｔｅｄｄａｔａｂａｓｅｓｙｓｔｅｍ，ｗｈｉｃｈａｒｅ２ＰＣａｎｄｒｅｐｌｉｃａｔｉｏｎｓｅｒｖ－ｅｒ．Ｔｈｅｎｔｈｅｐａｐｅｒｐｕｔｓｆｏｒｗａｒｄａｄｉｓｔｒｉｂｕｔｅｄｄａｔａｂａｓｅｆｒａｍｅｗｏｒｋｗｈｉｃｈｈａｖｅｒｅｐｌｉｃａｔｉｏｎｓｅｒｖｅｒｓｔｒｕｃｔｕｒｅ．Ａｎｄｉｔｉｓｅｆｆｅｃ－ｔｉｖｅａｎｄａｐｐｌｉｅｄ． Ｋｅｙｗｏｒｄｓ：ｄｉｓｔｒｉｂｕｔｅｄｄａｔａｂａｓｅｓｙｓｔｅｍ；ｄａｔａｃｏｎｓｉｓｔｅｎｃｙ；２ＰＣ；ｒｅｐｌｉｃａｔｉｏｎｓｅｒｖｅｒ 收稿日期：２００６－１０－２７ １３７
论分布式数据库的设计与实现 摘要：本文讨论某高校管理信息系统中分布式数据库的设计与实现。该系统架构设计采用C/S与B/S混合的架构方式。在全局数据与各院系的数据关系中，采用水平分片的方式；在全局数据与各部门之间，以及数据库服务器与Web数据库服务器的数据关系中，采用垂直分片的方式。设计过程中采用了基于视图概念的数据库设计方法。开发过程中在数据集成、测试、分布式数据库部署等方面做了大量的工作。并使用合并复制的方式有效地解决了分布式数据库中数据同步的问题。 关键词：分布式数据库架构设计应用数据集成合并复制 针对某高校管理信息系统的开发，该高校共有三个校区，总校区和两个校区，教务处等校级行政部门在总校区办公，15个院、系分布在两个校区。在工作中它们处理各自的数据，但也需要彼此之间数据的交换和处理，如何处理分散的数据和集中的管理是一个难题。学校信息系统中复杂而分散的数据信息之间的交换、相互转换和共享等问题是系统开发要解决的关键性问题，分布式数据库系统技术为解决这个问题提供了可能。 1、系统的架构设计 采用分布式的C/S与B/S混合的架构方式。各院系、部（室）通过局域网直接访问数据库服务器，软件采用C/S架构；其它师生员工通过Internet访问Web 服务器，通过Web服务器再访问数据库服务器，软件采用B/S架构。学校各部门之间工作时数据交互性较强，采用C/S架构可以使查询和修改的响应速度快；其它师生员工不直接访问数据库服务器，能保证学校数据库的相对安全。 2、数据的分布 从全局应用的角度出发，将局部数据库自下而上构成分布式数据库系统，各系部存放本机构的数据，全局数据库则存放所有业务数据，并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，也提高了局部应用的效率，减少了通讯代价。 将关系分片，有利于按用户需求组织数据的分布，根据不同的数据关系采用了不同的分片方式： （1）在全局数据与各院系的数据关系中，由于各院系的数据是全局数据的子集，采用了水平分片的方式。 （2）在全局数据与教务处、总务处等各部门之间，数据是按照其应用功能来划分的，所以采用了垂直分片的方式。在数据库服务器与Web数据库服务器
基础架构事业群-数据库技术-数据库内核 何登成 Paxos/Raft 分布式一致性算法原理剖析及其在实战中的应用
目录Contents Consensus Problem Basic Paxos Multi-Paxos and Raft 实战分析 参考资料
定义：The consensus problem requires agreement among a number of processes (or agents) for a single data value.
?理解Consensus 问题的关键 ?绝对公平，相互独立：所有参与 者均可提案，均可参与提案的决 策 ?针对某一件事达成完全一致：一 件事，一个结论 ?已经达成一致的结论，不可被推 翻 ?在整个决策的过程中，没有参与 者说谎 ?晚饭吃什么？ 炉鱼食堂同乐会 炉鱼炉鱼 炉鱼 Consensus Algorithm
Consensus Algorithm：Basic Paxos ?Basic Paxos ?一个或多个Servers可以发起提案（Proposers） ?系统必须针对所有提案中的某一个提案，达成一致 ?何谓达成一致？系统中的多数派同时认可该提案?最多只能针对一个确定的提案达成一致 ?Liveness (只要系统中的多数派存活，并且可以相互通信)?整个系统一定能够达成一致状态，选择一个确定的提案
Basic Paxos：Components ?Proposers ?Active：提案发起者（value） ?处理用户发起的请求 ?Acceptors ?Passive：参与决策，回应 Proposers的提案 ?存储accept的提案（value）， 存储决议处理的状态 ?Learners ?Passive：不参与决策，从 Proposers/Acceptors学习最新 达成一致的提案（value）?本文接下来的部分，一个Server同时具有Proposer和Acceptor两种角色，Learner角色逻辑简单，暂时不讨论
智能电能表通信协议（TCP）及功能一致性测试（ETS）与协议标准的探讨 发表时间：2018-03-14T15:13:27.440Z 来源：《基层建设》2017年第34期作者：刘永杰[导读] 摘要：开放式综合设备网络可以满足建筑节能、引进设备控制网络、连接现有的各种电气设备网络协议、通过扩展因特网的方式构建广域建筑设备控制网络等要求。 公诚管理咨询有限公司 520000 摘要：开放式综合设备网络可以满足建筑节能、引进设备控制网络、连接现有的各种电气设备网络协议、通过扩展因特网的方式构建广域建筑设备控制网络等要求。 关键词：通信协议；标准规格；一次性测试；互操作性引言：随着人们对通信要求的增加和通信技术自身的发展，通信网的建构日益成为一个庞大的系统工程。协议在通信网中占有绝对重要的地位，ISO开发的OSI七层协议参考模型为推动通信网的发展作出了很大贡献。但仅仅制定了协议还不够，协议工程概念的提出使得协议的制定、验证实现与测试紧密结合在一起，保证了通信网得以正确有效的运行。在整个协议工程过程中，协议的测试居于最后的阶段，测试的 结果表明通信产品可否满足最初的协议要求，直接影响到产品能否投入使用。因此，协议测试是协议工程的重要组成部分。图1示出协议工程总体概览以及协议测试所处的地位。正是鉴于协议测试的重要性，ISO和IEC共同制定了关于一致性测试方法学和框架的国际标准，这就是IS0/IEC9646系列标准。所谓一致性测试，简言之就是测试协议实现与协议规范标准的符合程度。 1.一致性测试的意图、能力和类型 一致性测试包括测试一个协议实现（protocol implementation）的能力和行为两个方面，同时检查是否有与相关国际标准或CCITT建议中的一致性要求以及实现者所声明的实现能力相违背的地方。一致性测试的意图在于增加不同的OSI协议实现在相互联接时的成功率。但是，从技术和经济上双重考虑，对协议实现进行穷尽测试是不现实的。一个正确的协议实现应该具备协议要求的能力并且行为上与协议表现一致，一致性测试要做的仅在于提高这一可信度。正如前面所言，一致性测试的目的在于判断协议实现是否与协议规范相一致。根据对一致性不同的指示程度，可以将一致性测试分为四种： 1.1 基本互联测试，这类测试目的在于检测严重的不一致情况是否存在，即IUT甚至不能与测试器相联或者没能实现协议的主要特征。 1.2 能力测试，静态一致性要求定义了协议实现所要具备的核心能力集合能力测试按照静态一致性要求进行测试，判断IUT的哪些能力可被观察到并检查这些可观察能力的有效性。 1.3 行为测试，行为测试是标准化的抽象测试集（ATS-Abstraet Test Suite）中的主要组成部分。它覆盖了动态一致性要求的全部，旨在确定协议实现的动态一致性。 1.4 一致性决定测试，这类测试提供尽可能明确的诊断性回答，以断定协议实现是否满足特定要求。一般认为，基本互联测试和能力测试可以作为行为测试的先行，而一致性决定测试是非标准化的，可以作为行为测试的后继补充。 2.抽象测试方法及其比较选择 2.1 在本地测试法中，测试器位于测试系统内部，要求IUT的上层服务边界是标准化的硬件接口，测试协调规程在测试系统中予以完全的实现。该方法仅适于有两个硬件接口的SUT。在这里，测试系统是指包括下测试器实现的一个真实系统。 2.2 分布式方法中，上测试器位于SUT中，上层服务边界应该是人工用户接口或者标准编程语言接口。适用于该法的IUT应该有一个上层接口，该接口能够为人工用户或含标准编程语言接口的软件化上测试器所访问。 2.3 在协调法中，测试协调规程由标准的测试管理协议（TMP-Test M anagement Protoco1）来实现。上测试器实质上是相应TMP的一个实现该法适用于TMP能够在上测试器中得以实现的情况。 2.4 在远程法中，对测试协调规程的要隐含于或非形式化地表述于抽象测试集（ATS—A bstract Test Suite，见下节）中，一般没有上测试器，但某些上测试器的功能需由SUT来执行，适用于可以利用SUT的某些功能来控制IUT而无须上测试器的情况。这四种测试方法见图2。
一、何为分布式数据库系统？一个分布式数据库系统有哪些特点？ 答案：分布式数据库系统通俗地说，是物理上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来，共同组成一个统一的数据库系统。因此，分布式数据库系统可以看成是计算机网络与数据库系统的有机结合。一个分布式数据库系统具有如下特点： 物理分布性，即分布式数据库系统中的数据不是存储在一个站点上，而是分散存储在由计算机网络连接起来的多个站点上，而且这种分散存储对用户来说是感觉不到的。 逻辑整体性，分布式数据库系统中的数据物理上是分散在各个站点中，但这些分散的数据逻辑上却构成一个整体，它们被分布式数据库系统的所有用户共享，并由一个分布式数据库管理系统统一管理，它使得“分布”对用户来说是透明的。 站点自治性，也称为场地自治性，各站点上的数据由本地的DBMS管理，具有自治处理能力，完成本站点的应用，这是分布式数据库系统与多处理机系统的区别。 另外，由以上三个分布式数据库系统的基本特点还可以导出它的其它特点，即：数据分布透明性、集中与自治相结合的控制机制、存在适当的数据冗余度、事务管理的分布性。 二、简述分布式数据库的模式结构和各层模式的概念。 分布式数据库是多层的，国内分为四层： 全局外层：全局外模式，是全局应用的用户视图，所以也称全局试图。它为全局概念模式的子集，表示全局应用所涉及的数据库部分。 全局概念层：全局概念模式、分片模式和分配模式 全局概念模式描述分布式数据库中全局数据的逻辑结构和数据特性，与集中式数据库中的概念模式是集中式数据库的概念视图一样，全局概念模式是分布式数据库的全局概念视图。分片模式用于说明如何放置数据库的分片部分。分布式数据库可划分为许多逻辑片，定义片段、片段与概念模式之间的映射关系。分配模式是根据选定的数据分布策略，定义各片段的物理存放站点。 局部概念层：局部概念模式是全局概念模式的子集。局部内层：局部内模式 局部内模式是分布式数据库中关于物理数据库的描述，类同集中式数据库中的内模式，但其描述的内容不仅包含只局部于本站点的数据的存储描述，还包括全局数据在本站点的存储描述。 三、简述分布式数据库系统中的分布透明性，举例说明分布式数据库简单查询的 各级分布透明性问题。 分布式数据库中的分布透明性即分布独立性，指用户或用户程序使用分布式数据库如同使用集中式数据库那样，不必关心全局数据的分布情况，包括全局数据的逻辑分片情况、逻辑片段的站点位置分配情况，以及各站点上数据库的数据模型等。即全局数据的逻辑分片、片段的物理位置分配，各站点数据库的数据模型等情况对用户和用户程序透明。
基于Raft分布式一致性协议实现的局限及其 对数据库的风险
普通服务器具有良好的性价比，因此在互联网等行业得到了广泛的应用。但普通服务器也不得不面对2%-4%的年故障率([1])，于是必须高可用的传统数据库只得很悲催地使用性价比低得可怜的高可靠服务器。 分布式一致性协议（distributed consensus protocol）是迄今为止最有效的解决服务器不可靠问题的途径，因为它使得一组服务器形成一个相互协同的系统，从而当其中部分服务器故障后，整个系统也能够继续工作。而Paxos协议([2])则几乎成了分布式一致性协议的代名词。 然而，Paxos协议的难以理解的名声似乎跟它本身一样出名。为此，Stanford大学的博士生Diego Ongaro甚至把对Paxos协议的研究作为了博士课题。他在2014年秋天正式发表了博士论文：“CONSENSUS: BRIDGING THEORY AND PRACTICE”，在这篇博士论文中，他们给出了分布式一致性协议的一个实现算法，即Raft。由于这篇博士论文很长（257页），可能是为了便于别人阅读和理解，他们在博士论文正式发表之前，即2014年初，把Raft相关的部分摘了出来，形成了一篇十多页的文章：“In Search of an Understandable Consensus Algorithm”，即人们俗称的Raft论文。 Raft算法给出了分布式一致性协议的一个比较简单的实现，到目前为止并没有人挑战这个算法的正确性。然而，OceanBase却没有采用Raft算法，这并非是OceanBase团队同学不懂Raft，而是Raft的一个根本性的局限对数据库的事务有很大的风险。 Raft有一个很强的假设是主（leader）和备（follower）都按顺序投票，为了便于阐述，以数据库事务为例： 1）主库按事务顺序发送事务日志 2）备库按事务顺序持久化事务和应答主库 3）主库按事务顺序提交事务
(完整)分布式数据库研究现状及发展趋势 编辑整理： 尊敬的读者朋友们： 这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（(完整)分布式数据库研究现状及发展趋势）的内容能够给您的工作和学习带来便利。同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。 本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为(完整)分布式数据库研究现状及发展趋势的全部内容。
山西大学研究生学位课程论文（2014 —--— 2015 学年第 2 学期) 学院（中心、所）：计算机与信息技术学院 专业名称：计算机应用技术 课程名称：分布式数据库技术 论文题目：分布式数据库研究现状及发展趋势授课教师（职称）: 曹峰（) 研究生姓名: 刘杰飞 年级： 2014级 学号： 201422403003 成绩: 评阅日期: 山西大学研究生学院 2015年 6 月 17日
分布式数据库研究现状及发展趋势 摘要随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化,特别是计算机网络与数字通信技术的飞速发展，卫星通信、蜂窝通信、计算机局域网、广域网和激增的Intranet及Internet得到了广泛应用,使分布式数据库系统应运而生。为了符合当今信息系统的应用需求和企业组织的管理思想和管理模式。分布式数据库提供了解决整个信息资产被分裂所成的信息孤岛，为孤岛联系在一起提供桥梁.本文主要介绍分布式数据库的研究现状，存在的一些问题以及未来的发展趋势。 关键词分布式数据库；发展趋势；现状及问题 1.引言 随着信息技术的飞速发展，社会经济结构、生产方式和消费结构已经发生了重大变化，这些变化深刻地影响着人民生活的方方面面。尤其是近十年来人们对计算机的依赖性越来越强，同时也对计算机提出了更高的要求。随着数据库在各个行业中的不断发展,各行业也对数据库提出了更高的要求，数据量也急剧增加，同时有关大数据分析的讨论正在愈演愈烈.甚至出现了爆炸性增长的趋势，一方面是由于移动互联网和移动智能终端的普及发展，数据信息正以每年40%的速度增长，造成数据量庞大；同时,数据种类呈多样性，文本、图片、视频等结构化和非结构化数据共存；另一方面也要求实时交互性强；最重要的是大数据蕴含了巨大的商业价值。相应的对于管理这些数据的复杂度也随之增加。同时各行业部门或企业所使用的软硬件之间的差异，这给开发企业管理数据库管理软件带来了巨大的工作量，如果能够有效解决这个问题,即使用同一模块管理操作不同的数据表格，对不同的数据表格进行查询、插入、删除、修改等操作，也即对企业简单的应用实现即插即用的功能，那么就能大大地减少软件开发的维护和更新费用,缩短软件的开发周期。分布式数据库系统的开发，降低了企业开发的成本,提高了软件使用的回报率。当今社会已进入了信息时代，人们将越来越多的信息存储在网络中的计算机上。如何更有
分布式数据库研究现状及发展趋势 摘要随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化，使分布式数据库系统应运而生。为了符合当今信息系统的应用需求和企业组织的管理思想和管理模式。分布式数据库提供了解决整个信息资产被分裂所成的信息孤岛，为孤岛联系在一起提供桥梁。本文主要介绍数据库数据存储特点，以及分布式数据库灾备的实现方法。 关键词分布式数据库；发展趋势；现状及问题 1.引言 当今社会已进入了信息时代，人们将越来越多的信息存储在网络中的计算机上。如何更有效地存储、管理、共享和提取信息，越来越引起人们的关注。随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化，集中式数据库已经不能满足人们的需求，因此分布式数据库系统应运而生，并且得到迅速发展。 分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式架构发展，基于关系型的分布式数据库在保留了传统数据库的数据模型和基本特征下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。 分布式数据库系统是由分布于多个计算机结点上的若干个数据库组成，,每个子数据库系统都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、终端，以及各自的局部数据库管理系统，分布式数据库在使用上可视为一个完整的数据库 ,而实际上它是分布在地理分散的各个结点上，它的数据存储方式与集中式数据库系统不同，数据被分片并分散存储于网络中不同的存储节点之上，并且每一个分片都有2到3个副本，以保证数据可靠性，但每一个存储节点上都只有部分数据，没有一个存储节点存有这样将为分布式数据库灾备的实现带来挑战，传统的基于卷、基于集中存储、基于传统数据库的两地三中心解决方案将不再适用于分布式环境灾备的实现，本文将主要介绍分布式数据库数据存储特点，以及分布式数据库灾备的实现方法。
分布式数据库管理系统简介 一、什么是分布式数据库： 分布式数据库系统是在集中式数据库系统的基础上发展来的。是数据库技术与网络技术结合的产物。 分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。 分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。 在分布式数据库系统中，一个应用程序可以对数据库进行透明操作，数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。 一个分布式数据库在逻辑上是一个统一的整体：即在用户面前为单个逻辑数据库，在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲，不存储在同一计算机的存储设备上。这就是与集中式数据库的区别。从用户的角度看，一个分布式数据库系统在逻辑上和集中式数据库系统一样，用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上，有单个数据库管理系统(DBMS)管理一样，用户并没有什么感觉不一样。 分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性。 分布式数据库系统是一个客户/服务器体系结构。 在系统中的每一台计算机称为结点。如果一结点具有管理数据库软件，该结点称为数据库服务器。如果一个结点为请求服务器的信息的一应用，该结点称为客户。在ORACLE客户，执行数据库应用，可存取数据信息和与用户交互。在服务器，执行ORACLE软件，处理对ORACLE 数据库并发、共享数据存取。ORACLE允许上述两部分在同一台计算机上，但当客户部分和服务器部分是由网连接的不同计算机上时，更有效。 分布处理是由多台处理机分担单个任务的处理。在ORACLE数据库系统中分布处理的例子如： 客户和服务器是位于网络连接的不同计算机上。 单台计算机上有多个处理器，不同处理器分别执行客户应用。
分布式数据库设计报告
目录 1案例背景 (1) 需求分析 (1) 2 分布式数据库设计 (2) 设计目标 (2) 总体设计目标 (2) （4）可靠性： (3) 完成方式及周期 (3) 分布式数据库架构图 (4) 物理设计施工 (5) 3 总结 (5) 4所用设备汇总 (7) 5所使用软件 (7)
成品车间分布式数据库设计 1案例背景 随着成品车间信息化程度越来越高，我们的传统集中式数据库系统的缺点逐渐体现出来主要有: 1、所有数据处理、存储集中在一台计算机上完成，一旦机器损坏或系统崩 溃数据数据很难恢复。 2、单台机器写入/查询处理能力不足，一台机器既要读取数据，又要写入数 据，遇到大批量超过单台数据库的处理能力，就会出现卡顿，在生产时 间不敢批量制造/查询数据。 3、硬件性能瓶颈，包括(硬盘、CPU、内存)，使用升级硬件的方法效果有限。 4、出现故障没有备用服务器可以替代。 5、当前成品车间存在2种数据库，oracle，sql sever，交叉使用不方便管 理维护，出现问题排查困难。 6、由于数据库初期创建数据库/表比较混乱，现在对数据的统计管理需要在 两台服务器之间交叉进行，统计难度高，效率低。 需求分析 成品车间信息化程度越来越高，各个节点产生的数据量越来越大，对数据系统要求越来越高，我们所使用的传统集中式数据库已经无法从容应对越来越大的数据。 成品车间生产线数据库主要有oracle和sql server两种，分别分布在2台计算机中，柔性线、自动线、三相线交叉使用两种类型数据库，主要出现的问题有; 1、一旦其中一个数据库出现问题，那么就有很大的几率导致三条线体 的某个节点或全部节点失去数据服务，导致停线。 2、数据库出现故障，必须停线，故障修复之后才可以上线使用。
分布式系统一致性与共识的原理 1一致性问题 一致性问题是分布式领域最为基础也是最重要的问题。如果分布式系统能实现“一致”，对外就可以呈现为一个完美的、可扩展的“虚拟节点”，相对物理节点具备更优越性能和稳定性。这也是分布式系统希望能实现的最终目标。 1.1定义与重要性 定义一致性（c o n s i s t e n c y），早期也叫a g r ee m e n t，是指对于分布式系统中的多个服务节点，给定一系列操作，在约定协议的保障下，试图使得它们对处理结果达成“某种程度”的认同。 理想情况下，如果各个服务节点严格遵循相同的处理协议，构成相同的处理状态机，给定相同的初始状态和输入序列，则可以保障在处理过程中的每个环节的结果都是相同的。 那么，为什么说一致性问题十分重要呢？举个现实生活中的例子，多个售票处同时出售某线路上的火车票，该线路上存 在多个经停站，怎么才能保证在任意区间都不会出现超售（同一个座位卖给两个人）的情况呢？ 这个问题看起来似乎没那么难，现实生活中经常通过分段分站售票的机制。然而，为了支持海量的用户和避免出现错误，存在很多设计和实现上的挑战。特别在计算机的世界里，为了达到远超普通世界的高性能和高可扩展性需求，问题会变得更为复杂。 注意一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否；
例如，所有节点都达成失败状态也是一种一致。 1.2问题与挑战
看似强大的计算机系统，实际上很多地方都比人类世界要脆弱得多。特别是在分布式计算机集群系统中，如下几个方面很容易出现问题： ·节点之间的网络通信是不可靠的，包括消息延迟、乱序和内容错误等； ·节点的处理时间无法保障，结果可能出现错误，甚至节点自身可能发生宕机； ·同步调用可以简化设计，但会严重降低分布式系统的可扩展性，甚至使其退化为单点系统。 仍以火车票售卖问题为例，愿意动脑筋的读者可能已经想到了一些不错的解决思路，例如： ·要出售任意一张票前，先打电话给其他售票处，确认下当前这张票不冲突。即通过同步调用来避免冲突； ·多个售票处提前约好隔离的售票时间。比如第一家可以在上午8点到9点期间卖票，接下来一个小时是另外一家……即通过令牌机制来避免冲突； ·成立一个第三方的存票机构，票集中存放，每次卖票前找存票机构查询。此时问题退化为中心化单点系统。 当然，还会有更多方案。实际上，这些方案背后的思想，都是将可能引发 不一致的并行操作进行串行 化。这实际上也是现代分布式系统处理一致性问题的基础思路。只是因为现在的计算机系统应对故障往往不够“智能”，而人们又希望系统可以更快更稳定地工作，所以实际可行的方案需要更加全面和更加高效。 注意这些思路都没有考虑请求和答复消息出现失败的情况，同时假设每个售票处的售票机制是正常工作的。 1.3一致性要求
多智能体系统一致性综述 一引言 多智能体系统在20世纪80年代后期成为分布式人工智能研究中的主要研究对象。研究多智能体系统的主要目的就是期望功能相对简单的智能体系统之间进行分布式合作协调控制，最终完成复杂任务。多智能体系统由于其强健、可靠、高效、可扩展等特性，在科学计算、计算机网络、机器人、制造业、电力系统、交通控制、社会仿真、虚拟现实、计算机游戏、军事等方面广泛应用。多智能体的分布式协调合作能力是多智能体系统的基础，是发挥多智能体系统优势的关键，也是整个系统智能性的体现。 在多智能体分布式协调合作控制问题中，一致性问题作为智能体之间合作协调控制的基础，具有重要的现实意义和理论价值。所谓一致性是指随着时间的演化，一个多智能体系统中所有智能体的某一个状态趋于一致。一致性协议是智能体之间相互作用、传递信息的规则，它描述了每个智能体和其相邻的智能体的信息交互过程。当一组智能体要合作共同去完成一项任务，合作控制策略的有效性表现在多智能体必须能够应对各种不可预知的形式和突然变化的环境，必须对任务达成一致意见，这就要求智能体系统随着环境的变化能够达到一致。因此，智能体之间协调合作控制的一个首要条件是多智能体达到一致。 近年来，一致性问题的研究发展迅速，包括生物科学、物理科学、系统与控制科学、计算机科学等各个领域都对一致性问题从不同层面进行了深入分析，研究进展主要集中在群体集、蜂涌、聚集、传感器网络估计等问题。 目前，许多学科的研究人员都开展了多智能体系统的一致性问题的研究，比如多智能体分布式一致性协议、多智能体协作、蜂涌问题、聚集问题等等。下面，主要对现有文献中多智能体一致性协议进行了总结，并对相关应用进行简单的介绍。 1.1图论基础 多智能体系统是指由多个具有独立自主能力的智能体通过一定的信息传递方式相互作用形成的系统；如果把系统中的每一个智能体看成是一个节点，任意两个节点传递的智能体之间用有向边来连接的话，智能体的拓扑结构就可以用相应的有向图来表示。 用)(A E,V ,G =来表示一个有向加权图，其中}{n 21v ,,v ,v V =代表图的n 个顶
系统分布式情况下最终一致性方案梳理 本文章来自于阿里云云栖社区 摘要：前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。前言 目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。 基础理论相关 说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE 等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。 ACID 特性 o A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行； o C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确；
o I（隔离性）保证事务不受外部并发操作的独立环境执行； o D（持久性）事务完成之后，对于数据的修改是永久的，即使系统出现故障也能够保持； ?CAP o C（一致性）一致性是指数据的原子性，在经典的数据库中通过事务来保障，事务完成时，无论成功或回滚，数据都会处于一致的状态，在分布式环境下，一致性是指多个节点数据是否一致； o A（可用性）服务一直保持可用的状态，当用户发出一个请求，服务能在一定的时间内返回结果； o P（分区容忍性）在分布式应用中，可能因为一些分布式的原因导致系统无法运转，好的分区容忍性，使应用虽然是一个分布式系统，但是好像一个可以正常运转的整体 ?BASE o BA: Basic Availability 基本业务可用性； o S: Soft state 柔性状态； o E: Eventual consistency 最终一致性； 最终一致性的几种做法
1.大型分布式数据库解决方案 企业数据库的数据量很大时候，即使服务器在没有任何压力的情况下，某些复杂的查询操作都会非常缓慢，影响最终用户的体验；当数据量很大的时候，对数据库的装载与导出，备份与恢复，结构的调整，索引的调整等都会让数据库停止服务或者高负荷运转很长时间，影响数据库的可用性和易管理性。 分区表技术 让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。但是分区表只能把数据分散到同一机器的不同磁盘中，也就是还是依赖于一个机器的硬件资源，不能从根本上解决问题。 分布式分区视图 分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。但是并没有简化分区数据集的管理、设计。用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数
据完整性约束，管理工作变得非常复杂。而且还有一些限制，比如不能使用自增列，不能有大数据对象。对于全局查询并不是并行计算，有时还不如不分区的响应快。 库表散列 在开发基于库表散列的数据库架构，经过数次数据库升级，最终采用按照用户进行的库表散列，但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。客户在实际应用中要投入很大的研发成本，面临很大的风险。 面对海量数据库在高并发的应用环境下，仅仅靠提升服务器的硬件配置是不能从根本上解决问题的，分布式网格集群通过数据分区把数据拆分成更小的部分，分配到不同的服务器中。查询可以由多个服务器上的CPU、I/O来共同负载，通过各节点并行处理数据来提高性能；写入时，可以在多个分区数据库中并行写入，显著提升数据库的写入速度。
摘要 本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用。首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题。 分布式缓存问题 假设我们有一个网站，最近发现随着流量增加，服务器压力越来越大，之前直接读写数据库的方式不太给力了，于是我们想引入Memcached作为缓存机制。现在我们一共有三台机器可以作为Memcached服务器，如下图所示。 很显然，最简单的策略是将每一次Memcached请求随机发送到一台Memcached 服务器，但是这种策略可能会带来两个问题：一是同一份数据可能被存在不同的机器上而造成数据冗余，二是有可能某数据已经被缓存但是访问却没有命中，因为无法保证对相同key的所有访问都被发送到相同的服务器。因此，随机策略无论是时间效率还是空间效率都非常不好。 要解决上述问题只需做到如下一点：保证对相同key的访问会被发送到相同的服务器。很多方法可以实现这一点，最常用的方法是计算哈希。例如对于每次访问，可以按如下算法计算其哈希值： h = Hash(key) % 3
其中Hash是一个从字符串到正整数的哈希映射函数。这样，如果我们将Memcached Server分别编号为0、1、2，那么就可以根据上式和key计算出服务器编号h，然后去访问。 这个方法虽然解决了上面提到的两个问题，但是存在一些其它的问题。如果将上述方法抽象，可以认为通过： h = Hash(key) % N 这个算式计算每个key的请求应该被发送到哪台服务器，其中N为服务器的台数，并且服务器按照0 – (N-1)编号。 这个算法的问题在于容错性和扩展性不好。所谓容错性是指当系统中某一个或几个服务器变得不可用时，整个系统是否可以正确高效运行；而扩展性是指当加入新的服务器后，整个系统是否可以正确高效运行。 现假设有一台服务器宕机了，那么为了填补空缺，要将宕机的服务器从编号列表中移除，后面的服务器按顺序前移一位并将其编号值减一，此时每个key就要按h = Hash(key) % (N-1)重新计算；同样，如果新增了一台服务器，虽然原有服务器编号不用改变，但是要按h = Hash(key) % (N+1)重新计算哈希值。因此系统中一旦有服务器变更，大量的key会被重定位到不同的服务器从而造成大量的缓存不命中。而这种情况在分布式系统中是非常糟糕的。 一个设计良好的分布式哈希方案应该具有良好的单调性，即服务节点的增减不会造成大量哈希重定位。一致性哈希算法就是这样一种哈希方案。 一致性哈希算法 算法简述 一致性哈希算法（Consistent Hashing）最早在论文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》中被提出。简单来说，一致性哈希将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0 - 232-1（即哈希值是一个32位无符号整形），整个哈希空间环如下：
第一章 1.1 采用分布式数据库系统的主要原因是什么？ 集中式数据库系统的不足：1.数据按实际需要已经在网络上分布存储，如果再采用集中式处理，势必造成附加成本和通信开销，2,。应用程序集中在一台计算机上运行，一旦该计算机发生故障，将会影响整个系统的运行，可靠性不高。3集中式处理导致系统的规模和配置都不够灵活，系统的可扩展性较差。 1.2 分布式数据库系统有哪几种分类方法？这些方法是如何分类的？ 1.按局部数据库管理系统的数据模型的类型分类。 （1）同构型：同构同质型：各个站点上的数据库的数据模型都是同一类型的，而且是同一种DBMS。 同构异质型：各个站点上的数据库的数据模型都是同一类型的，但不是同一种DBMS。 （2）异构型：各个站点上的数据库的数据模型各不相同。 2.按分布式数据库系统全局控制系统类型分类 （1）全局控制集中型DDBS （2）全局控制分散型DDBS （3）全局控制可变型DDBS 1.3 什么是分布式数据库系统？它具有那些主要特点？怎样区分分布式数据库系统与只提供远程数据访问的网络数据库系统？ 分布式数据库系统是物理上分散而逻辑上集中的数据库系统，其可以看成是计算机网络和数据库系统的有机结合。 基本特点：物理分布性、逻辑整体性、站点自治性。 导出特点：数据分布透明性、集中与自治相结合的机制、存在适当的数据冗余度、事务管理的分布性。 区分：分布式数据库的分布性是透明的，用户感觉不到远程与本地结合的接缝的存在。 1.6分布式DBMS具有哪些集中式DBMS不具备的功能？ 数据跟踪，分布式查询处理，分布式事务管理，复制数据管理，安全性，分布式目录管理 1.14分布式数据库系统的主要优点是什么？存在哪些技术问题？ 分布式数据库系统优点：良好地可靠性和可用性；提高系统效率，降低通信成本；较大的灵活性和可伸缩性；经济型和保护投资；适应组织的分布式管理和控制；数据分布式具有透明性和站点具有较好的自治性；提高了资源利用率；实现了数据共享。