分布式OA系统的数据库同步复制技术

第一篇：分布式OA系统的数据库同步复制技术

分布式OA系统的数据库同步复制技术

一、背景概述

随着政府上网、电子政务的不断普及和深入，IBM公司的Lotus Domino系统在国内得到广泛的应用。其中不乏大型的、跨地域的企事业单位或集团公司应用案例。这些案例一般采用分布式系统结构，即分布在全国各地的分支机构分别设有独立的数据库服务器，各地数据库服务器采用数据库同步复制的方式更新本地数据库复本内容。从而使得各地终端用户及时、快捷、可靠地访问到最新公告、新闻等。

本文结合呼和浩特铁路局客运公司办公自动化系统案例讨论基于IBM公司的Lotus Domino技术构建的分布式OA系统中数据库之间的同步复制技术。

二、几个概念

IBM公司的Lotus产品包含Lotus Domino Server，Lotus Notes，Lotus Domino Administrator和Lotus Domino Designer。Lotus Domino Server为后台数据库平台，Lotus Notes为客户端，Lotus Domino Administrator为系统管理平台，Lotus Domino Designer设计开发工具。先介绍几个Domino中和同步复制有关的概念。

1、复制

Notes允许在多个服务器或工作站上保存数据库的多个拷贝，这些拷贝称做“复本”。它们使各个地方的不同网络上的用户共享相同的信息。复本与文件的拷贝不同之处在于在复制时源文件与其复本具有相同的复本标识符。

复制是在复本之间共享更改信息的过程。复制时，Notes通过把更改信息从一个复本拷贝到另一个复本来更新复本。最终，Notes 使所有复本保持一致。可以选择在复本拷贝之间进行复制，这时两个复本都发送并接收更新信息，或者选择仅从一个复本复制到另一个复本。

也可以定期安排复制，或者根据需要手动进行复制。复制可以在两台服务器之间或者在服务器和工作站之间进行。如果设定为定期进行完整复制，那么 Notes会根据时间使所有复本保持同步。

2、复本标识符

复本与源文件或数据库有相同的复本标识符。这是数据库的复本与拷贝的区别所在，因为有共同的标识符才能使复本与源数据库之间可以复制更改信息。如果数据库的两个拷贝具有不同的复本标识符，则不能在它们之间进行复制。

3、复制冲突和保存冲突

在复制之间，如果有两个或多个用户对相同文档的不同复本进行了编辑，就会导致复制冲突。而保存冲突则是在两个或多个用户同时编辑服务器上同一个数据库的同一个文档时发生。当发生复制冲突或保存冲突时，Notes 将在视图页面左边把发生冲突的文档标注出来。

Notes对复制冲突的处理是这样的，在两个或多个用户编辑并保存同一个文档之后，下次进行复制时，Notes 将编辑和保存最频繁的文档指定为主文档，而将其他文档显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。如果用户在一个复本中编辑并保存了某文档，然后另一个用户将该文档删除，则认为该文档是被删除的。然而，如果文档被编辑和保存了多次，或者在该文档被删除之后又被另一个用户编辑和保存过，则把编辑过的文档作为主文档。

Note对保存冲突的处理如下，当多个用户同时打开相同的文档进行编辑时，Notes指定最先保存的文档为主文档。当另一个用户试图保存同一文档时，Notes 就会提示该用户把它作为“保存冲突”文档来保存。如果用户这样做了，那么 Notes 将它显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。

根据笔者的经验，在实际开发过程中，我们应该通过设计控制保存冲突，避免文档产生“保存冲突”的答复文档。对于复制冲突可以设置数据库合并复制冲突，这样如果产生增量改动，服务器在复制过程中会自动合并冲突。需要说明的是，Notes在进行复制时，并不是传统意义上的完全拷贝，而是一系列的规则进行增量的合并。

4、复制类型

Domino中支持四种不同的复制方式

拉入推出：是一个双向过程。此过程进行时，呼叫服务器从响应服务器拉入更新，然后向响应服务器推出自己的更新。使用“拉入推出”时，呼叫服务器上的 Replicator 任务执行所有的工作。拉入推出是系统缺省的复制方式。

分别拉入：是两个服务器交换更新的双向过程。使用“分别拉入”时，两个复制器（一个在呼叫服务器上，另一个在响应服务器上）共同进行复制工作。

只推出：是呼叫服务器向响应服务器推出更新的单向过程。单向复制总是比双向复制耗时少。只拉入：是呼叫服务器从响应服务器拉入更新的单向过程。单向复制总是比双向复制耗时少。

三、案例

笔者曾经参与呼和浩特铁路局客运公司办公自动化系统的设计、开发和实施工作。呼和浩特铁路局客运公司包括三个信息中心，分别在呼和浩特市、包头市和东河区三个地方，三地之间通过64K的DDN专线连接。因为带宽的限制，用户远程访问速度成为本系统的瓶颈，经过再三论证，我们决定构建分布式数据库存储架构，采用后台数据库实时同步复制技术使三个异地服务器内容一致，将远程访问转化为本地访问，从而提高终端用户访问速度。

详细步骤如下。

1、安装服务器

在三地信息中心分别安装Domino服务器，服务器的详细配置并不复杂，读者可以参阅相关资料，一般情况下按照安装配置向导四步就可以快捷配置完毕。注意三台Domino服务器不要同名，其简单拓扑结构如下：

图中呼市处于相对中心的位置，所以呼市和包头之间，呼市和东河之间分别建立了互推复制机制，为了降低网络负担和流通环节，没有建立包头和东河之间的复制，各地直接通过与呼市同步来保持三地数据的一致。一般而言，如果各分支机构处于平等位置，互相之间的数据流量相当，也可以两两之间建立复制机制。

2、建立服务器之间的连接

对于两个服务器之间进行的复制，应创建一个“连接”文档来指定进行信息交换的方式和时间。“连接”文档存储在“Domino 目录”中。一次仅使用一个“连接”文档来处理每对服务器之间的所有复制。创建不必要的“连接”文档会增加网络传输量和阻塞。

缺省情况下，邮件路由和复制都已被启用，但是可以更改此设置并使用单独的“连接”文档来安排每项任务。这样，就可以分别控制复制和邮件路由的特定时间、时间范围或重复间隔，并根据需要增加或减小这些设置。

怎么保证服务器之间的连接能顺利的连通？实际上对于物理连接形式Domino并不关心，也就是说物理上无论通过什么连接方式，专线、光纤、X.25、电话拨号等，只要TCP/IP通，简单说只要能Ping通，就能够保证服务器之间顺利连接。

下面给出了建立服务器之间连接的操作步骤和主要参数的设置说明：

A）在 Domino Administrator 中单击“配置”附签。

B）在“使用目录”域中选择连接服务器的“Domino 目录”。

C）单击“服务器”，然后单击“连接”。

D）单击“添加连接”。

F）关键域配置描述：

域输入

源服务器连接服务器的名称

使用以下端口连接服务器或源服务器使用的网络端口（或协议）名称

使用优先级选择一个：“一般”（缺省）“低”

目标服务器响应服务器的名称

可选网络地址与所选协议相适应的目标服务器的地址。对于 TCP/IP，应使用完全有效的网络域名称（首选）或 IP 地址（例如：HR-E.Acme.com 或者 192.22.256.36）。

对 TCP/IP 或其他需要特定网络地址的协议，建议填写此域。

复制类型缺省情况下，Domino 的复制方向为“拉入推出”。但根据实际情况，为了平衡服务器之间的负载，充分发挥每个服务器的性能，我们可以设定双方互推或者互拉，本例中我们采用服务器双方互推的方式，即每个服务器上的连接复制类型都是由源服务器向目标服务器推出。

复制文件/目录如果为空，则服务器将DATA目录下的所有存在复本的数据库全部进行复制，否则填写哪个库系统就复制哪个库。

安排在安排中可以设置连接时间、重复间隔、每周复制日期等参数。可根据实际情况设定，本例设置为每日8：00到晚上10：00连接，连接期间每一小时进行同步复制或服务器依据增量自动复制，非连接时间服务器处理其他性能调优动作，如更新数据库索引等。

H）保存文档。

3、建立数据库复本

连接建立成功以后，保证服务器之间可以进行通讯了，下一步就是对要进行同步的数据库建立复本，当建立了复本以后，通过连接设定就能保证异地各个复本之间的数据完全一致。

这里需要说明的是，我们在第一台服务器上建立了一套数据库系统，对于需要同步复制的所有数据库，在其他服务器上只需要产生他们的复本，而不能再在每台服务器上分别创建相同的数据库。在本例中我们在呼市客运公司信息中心安装配置好第一台服务器后，在包头信息中心和东河信息中心的Domino服务器上则通过呼市信息中心服务器建立各自本地所有需要的数据库复本。

如果要在本地Domino服务器上创建源Domino服务器的复本数据库，需要本地服务器的系统管理员具有对源服务器访问和创建复本的权限，因为Domino对权限控制很严格，尤其是多域用户之间的访问，其目的就是为了充分保证系统的安全性。那么怎样才能具有这样的创建复本的权限呢？需要具有两个基本的存取权限就可以在本服务器上创建源服务器的数据库复本，一是源服务器配置中允许本地服务器的系统管理员访问，二是允许本地服务器的系统管理员创建数据库复本，这两个权限由源数据库的系统管理员设置给目标数据库的系统管理员。结合本例，需要在包头信息中心的服务器上建立呼市信息中心的数据库复本，则首先在呼市信息中心的服务器上配置“当前服务器”文档。

A）在 Domino Administrator 中单击“当前服务器”文档。

B）单击“编辑服务器”

C）选择“安全”标签页，填写以下两项：

域输入

访问服务器本例为包头信息中心系统服务器名称及管理员的用户名称

创建数据库复本同样是包头信息中心系统管理员的用户名称

D保存后退出。

接下来就可以在包头信息中心的服务器上创建源数据库的复本了，这步动作比较简单，选择源数据库，从菜单中执行创建复本功能即可，这里不在详细描述。

同样的处理在东河的服务器上如法炮制一遍，则所有数据库复本成功建立完毕。

4、复制测试

完成以上三步，配置就全部完成，接下来就要测试一下配置是否完全成功以及配置是否生效。我们测试主要包括两个内容：一是测试连接是否成功，能否进行复制动作。二是测试设置的复制安排是否按照预定生效。

A）进行第一项测试的办法是在Domino的控制台上，使用Domino的系统命令，进行数据库的推、拉测试，检查复制是否能成功进行，命令格式如下：

拉入复制

语法：Pull servername [databasename]

描述：强制从指定服务器到本地服务器进行单向复制。通过在命令行中包括单个数据库名称，将其从特定服务器单向复制到本地服务器。发起复制的服务器从指定的服务器接受数据，但不能申请将自己的数据复制到其他服务器上。该命令重设在“Domino 目录”中预定的任何复制，而强制一台服务器与发起复制的服务器立即进行复制。如果可能，请输入服务器完整的层次结构名称。

推出复制

语法：Push servername [databasename]

描述：强制进行从本地服务器到指定服务器的单向复制。也可以通过在命令行中包括要复制的单个数据库名称，来将其从本地服务器单向复制到特定服务器。发起复制的服务器将数据发送到指定的服务器，但不申请获得数据。该命令可以重设在“Domino 目录”中预定的任何复制，而强制一台服务器立即与发起复制的服务器进行复制。如果可能的话，请指定服务器完整的层次结构名称。

B）第二项测试通过将连接文档的安排时间设置为两分钟进行一次，同时观察Domino的系统控制台，查看服务器的动作，以确保安排设定生效。正确的结果是从控制台上能看到系统报告复制过程。

按照以上实例说明进行，没有任何问题。

四、结束语

我们同样可以在客户端利用复制技术，例如在本地客户端建立邮件文件数据库的复本，以便与我们在外出或者脱机状态下还可以访问邮件文件。本地复本要求没有在服务器之间进行复制的要求那么高，本地复本的作用体现在通过本地复本，可以在没有通过网络连接服务器时对数据库进行操作。当设置 Notes 为远程工作站时，就可以通过调制解调器呼叫服务器并在本地复本和服务器数据库之间交换更新信息。

第二篇：网络数据库讲稿(复制)

网络数据库讲稿

4/20/2013

一、复制的基本概念

SQL Server复制是在数据库之间对数据和数据库对象进行复制和分发并且对于数据的修改进行同步，以确保其一致性的一组技术。使用复制可以将数据分发到不同位置，通过局域网、Internet分发给多个远程服务器站点；还可将多个用户和站点的数据进行合并。

二、复制模型

复制技术采用发布(出版)——订阅模型分发数据。

SQL Server复制模型由下列对象组成：发布服务器，分发服务器，订阅服务器，发布，项目，订阅。还有几个负责在发布服务器和订阅服务器之间复制和移动数据的复制进程：快照代理程序，分发代理程序，日志读取器代理程序，队列读取器代理程序，合并代理程序。1.服务器角色

参与复制的服务器根据任务不同可划分为以下角色： ①发布服务器：数据源所在的服务器。

②分发服务器：将出版物从发布服务器移动到订阅服务器。③订阅服务器 2.项目

3.发布(出版物)4.订阅 5.复制的类型 ①快照复制 ②事务复制 ③合并复制 6.复制代理程序

①快照代理程序：与所有复制类型一起使用。

②分发代理程序：与快照复制和事务复制一起使用。③合并代理程序：与合并复制一起使用。

④日志读取器代理程序：与事务复制一起使用。

⑤队列读取器代理程序：与快照复制或事务复制一起使用。

三、服务器的连接方式

1.发布服务器与分发服务器为同一物理服务器 2.发布服务器与分发服务器为不同物理服务器 3.发布者与再次发布者连接方式

4.多发布服务器单订阅服务器连接方式

四、配置复制

复制一般包括以下几个阶段：配置发布和分发，生成和应用初始快照，修改复制数据，同步和传播数据。

复制过程中各代理程序的调度由SQL Server Agent服务管理，应配置SQL Server Agent服务能够在系统启动的时候自动启动，并且在意外停止时能够自动重新启动，由于复制操作跨越多个服务器传输数据，所以SQL Server Agent服务的启动帐号应使用域用户帐号。1.配置分发服务器

网络数据库讲稿

4/20/2013 分发服务器是快照复制和事务复制的首要组件。在企业管理器中运行向导，右击【复制】，单击【配置发布、订阅服务器和分发】启动【配置发布和分发向导】。然后按提示进行。

配置完成后，系统在分发服务器上创建distribution系统数据库、复制文件夹、复制监视器。

2.配置发布服务器和创建出版物

出版物是准备发布的表、表中数据的子集或其它数据库对象的集合。出版物是订阅的单元。

在企业管理器中运行向导，右击【复制】，单击【新建/发布】启动【创建发布向导】，然后按提示进行。

在“指定项目”步骤，单击“项目默认值”或“对象”右端的省略号按钮，可设置快照属性。

可循环创建多个发布。

可查阅和修改已建发布的属性。

3.订阅

订阅是对发布到指定订阅服务器的数据或数据库对象的请求。一个订阅服务器可以向不同发布请求多个订阅。

订阅可在发布服务器上创建(强制订阅)或在订阅服务器上创建(请求订阅)。(1)强制订阅

在企业管理器中：工具/向导，展开【复制】，启动【创建强制订阅向导】，然后按提示进行。

(2)请求订阅 在企业管理器中：工具/向导，展开【复制】，启动【创建请求订阅向导】，然后按提示进行。

也可按教材P175的例子，先创建发布，再配置发布和分发服务器，最后创建订阅。

第三篇：OA办公系统的产品和技术

和您一样，内行青睐万户OA

OA办公系统的产品和技术

1.产品和技术是骨架

如今，技术发展日新月异，要求OA办公系统选型必须跟得上技术和需求的潮流，才能让先进的信息技术为我所用，提升管理效率。正所谓“产品和技术就好比一个骨架，如果这个骨架缺了胳膊，或者关节不灵活，那么就很难满足企业的现实所需”。因此，企业在选型中首先要关注的就是产品和技术能否提供一个平衡且灵活的“骨架”。

2.php技术平台以其成熟性、开放性和跨平台性

从技术方面来说，java平台的OA办公系统以其拓展性、稳定性等优势雄踞高端OA市场;php技术平台以其成熟性、开放性和跨平台性等优势成为中小企业试水协同办公的首选产品。通过JAVA语言开发产品具有很强的优势，其基于“协同矩阵”模型和齿轮联动模型打造的协同管理平台，能将企业作为一个有机的整体来对待，将组织的七大要素：人的要素、流程的要素、知识的要素、客户资源的要素、项目事件的要素、物的要素和财的要素进行“立体多线程”的管理，并以人力资源和工作流程模块作为整个系统的心脏和血脉，与其他功能模块，如：知识文档管理模块、客户关系管理模块、项目管理模块、财务管理模块和资产管理模块强相关联，从而更好地发挥协同作用，让组织运行更更为顺畅。

3.产品是“骨架”服务填充“血肉”

目前，用户在选择OA办公系统时已日趋理性，不仅会关注产品与自身需求的切合度，也会更加关注OA厂商的实施服务能力。所以，用户将更关注OA厂商是否能够在实施过程中帮助他们进行应用推广，在项目交付时就能够初见成效。而要想做到这一点，OA厂商必须要有严格的实施过程控制机制和伸缩性足够强大的实施服务力量。

协同OA办公系统要能够焕发出管理的生命力，必须要有血有肉，如果说产品和技术是骨架，那么服务就是填充血肉的过程，这个过程也决定着最终的应用效果，而要做好服务，则取决于厂商的本地化服务能力、实施体系控制等。

第四篇：OA办公系统的主要技术架构

和您一样，内行青睐万户OA

OA办公系统的主要技术架构

OA办公系统是一种重要的应用软件，目前各类应用软件已经倾向于组件化的设计思想，以降低各逻辑组件间的耦合性。设计思想中最为流行的、为绝大部分现有应用系统所采用的是：“MVC”（Model View Controller）设计思想。OA办公系统实现此思想时根据所采用的具体开发技术又分为三种架构：Domino架构、J2EE架构、Net架构。MVC设计思想

MVC英文即Model View Controller。即把一个应用的输入输出、处理、存储流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。

MVC是构筑软件优秀的设计思想，将业务处理与显示分离。各层之间松耦合，日后当进行扩展或者整合的时候，可以用搭积木一样的方式来进行。Domina架构

Domino属于IBM阵营的技术，最初由Lotus公司开发。后被IBM收购而更加发扬光大，是OA领域最成熟的技术。目前基于Domino技术开发的OA办公系统，通常是将Domino作为Model。不需另行开发，再在Domino之上通过其提供的工具开发Controller和View，其中的View目前大部分是Web页面形式。这种架构其实就是在Domino精华之上加了一层壳，实质还是原来的Domino系统。J2EE架构

J2EE全称为Java 2 Enterprise Edition，后改名为：Java EE，即Java Platform Enterprise Edition。J2EE原属于SUN阵营，去年SUN为Oracle公司所收购。Java语言的流行、开源应用的蓬勃发展，使得J2EE是目前最流行的应用开发架构，也是将MVC思想实现地最彻底的新技术。J2EE提供了一系列的规范，可以与多种产品和技术无缝集成。Net架构

Net属于Microsoft阵营，在应用开发领域，是J2EE架构近年来的竞争对手。两者的设计思想很多地方相互学习，十分类似。最大的不同在于：。Net架构用Microsoft的技术实现，只能运行于Windows平台之上，而J2EE架构用Java语言实现。可以运行于任何平台之上，能和任何符合其规范的产品或技术“搭积木”。

第五篇：从Google Spanner漫谈分布式存储与数据库技术

从Google Spanner漫谈分布式存储与数据库技术

文/曹伟

Spanner 的设计反映了 Google 多年来在分布式存储系统领域上经验的积累和沉淀，它采用了 Megastore 的数据模型，Chubby 的数据复制和一致性算法，而在数据的可扩展性上使用了 BigTable 中的技术。新颖之处在于，它使用高精度和可观测误差的本地时钟来判断分布式系统中事件的先后顺序。Spanner 代表了分布式数据库领域的新趋势——NewSQL。

Spanner 是 Google 最近公开的新一代分布式数据库，它既具有 NoSQL 系统的可扩展性，也具有关系数据库的功能。例如，它支持类似 SQL 的查询语言、支持表连接、支持事务（包括分布式事务）。Spanner 可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套 Spanner 集群可以扩展到上百个数据中心、百万台服务器和上T条数据库记录的规模。目前，Google 广告业务的后台（F1）已从 MySQL 分库分表方案迁移到了 Spanner 上。

数据模型

传统的 RDBMS（例如 MySQL）采用关系模型，有丰富的功能，支持 SQL 查询语句。而 NoSQL 数据库多是在 key-value 存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。Spanner 继承了 Megastore 的设计，数据模型介于 RDBMS 和 NoSQL 之间，提供树形、层次化的数据库 schema，一方面支持类 SQL 的查询语言，提供表连接等关系数据库的特性，功能上类似于 RDBMS；另一方面整个数据库中的所有记录都存储在同一个 key-value 大表中，实现上类似于 BigTable，具有 NoSQL 系统的可扩展性。

在 Spanner 中，应用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图 1 中创建的两个表——用户表（Users）和相册表（Albums），并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录（一个用户）对应着相册表中的多条记录（多个相册）。此外，要求子节点的主键必须以父节点的主键作为前缀。例如，用户表的主键（用户 ID）就是相册表主键（用户 ID+ 相册 ID）的前缀。

图 1 schema 示例，表之间的层次关系，记录排序后交错的存储

显然所有表的主键都将根节点的主键作为前缀，Spanner 将根节点表中的一条记录，和以其主键作为前缀的其他表中的所有记录的集合称作一个 Directory。例如，一个用户的记录及该用户所有相册的记录组成了一个 Directory。Directory 是 Spanner 中对数据进行分区、复制和迁移的基本单位，应用可以指定一个 Directory 有多少个副本，分别存放在哪些机房中，例如把用户的 Directory 存放在这个用户所在地区附近的几个机房中。

这样的数据模型具有以下好处。

 一个 Directory 中所有记录的主键都具有相同前缀。在存储到底层 key-value 大表时，会被分配到相邻的位置。如果数据量不是非常大，会位于同一个节点上，这不仅提高了数据访问的局部性，也保证了在一个 Directory 中发生的事务都是单机的。

 Directory 还实现了从细粒度上对数据进行分区。整个数据库被划分为百万个甚至更多个 Directory，每个 Directory 可以定义自己的复制策略。这种 Directory-based 的数据分区方式比 MySQL 分库分表时 Table-based 的粒度要细，而比 Yahoo!的 PNUTS 系统中 Row-based 的粒度要粗。

 Directory 提供了高效的表连接运算方式。在一个 Directory 中，多张表上的记录按主键排序，交错（interleaved）地存储在一起，因此进行表连接运算时无需排序即可在表间直接进行归并。

复制和一致性

Spanner 使用 Paxos 协议在多个副本间同步 redo 日志，从而保证数据在多个副本上是一致的。Google 的工程师钟情于 Paxos 协议，Chubby、Megastore 和 Spanner 等一系列产品都是在 Paxos 协议的基础上实现一致性的。

Paxos 的基本协议很简单。协议中有三个角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分别是读者和写者，Acceptor 相当于存储节点。整个协议描述的是，当系统中有多个 Proposer 和 Acceptor 时，每次 Proposer 写一个变量就会启动一轮决议过程（Paxos instance），如图 2 所示。决议过程可以保证即使多个 Proposer 同时写，结果也不会在 Acceptor 节点上不一致。确切地说，一旦某个 Proposer 提交的值被大多数 Acceptor 接受，那么这个值就被选中，在整轮决议的过程中该变量就不会再被修改为其他值。如果另一个 Proposer 要写入其他值，必须启动下一轮决议过程，而决议过程之间是串行（serializable）的。

图 2 Paxos 协议正常执行流程

一轮决议过程分为两个阶段，即 prepare 阶段和 accept 阶段。

 第一阶段A：Proposer 向所有 Acceptor 节点广播 prepare 消息，消息中只包含一个序号——N。Proposer 需要保证这个序号在这轮决议过程中是全局唯一的（这很容易做到，假如系统中有两个 Proposer，那么一个 Proposer 使用1，3，5，7，9，„„，另一个 Proposer 则使用0，2，4，6，8，„„）。



第一阶段B：Acceptor 接收到 prepare 消息后，如果N是到目前为止见过的最大序号，就返回一个 promise 消息，承诺不会接受序号小于N的请求；如果已接受过其他 Proposer 提交的值，则会将这个值连同提交这个值的请求的序号一同返回。 第二阶段A：当 Proposer 从大多数 Acceptor 节点收到了 promise 消息后，就可以选择接下来要向 Acceptor 提交的值了。一般情况下，当然选原本打算写入的值，但如果从收到的 promise 消息中发现已经有其他值被 Acceptor 接受了，那么为了避免造成数据不一致的风险，这时 Proposer 就必须“大义灭亲”，放弃自己打算写入的值，从其他 Proposer 提交的序号中选择一个最大的值。接下来 Proposer 向所有的 Acceptor 节点发送 accept 包，其中包含在第一阶段中挑选的序号N和刚才选择的值V。



第二阶段B：Acceptor 收到 accept 包之后，如果N的大小不违反对其他

Proposer 的承诺，就接受这个请求，记录下值V和序号N，返回一个 ack 消息。反之，则返回一个 reject 消息。

如果 Proposer 从大多数 Acceptor 节点收到了 ack 消息，说明写操作成功。而如果在写操作过程中失败，Proposer 可以增大序号，重新执行第一阶段。

基本的 Paxos 协议可以保证值一旦被选出后就一定不会改变，但不能保证一定会选出值来。换句话说，这个投票算法不一定收敛。有两个方法可以加速收敛的过程：一个是在出现冲突后通过随机延迟把机会让给其他 Proposer，另一个是尽量让系统中只有一个 Proposer 去提交。在 Chubby 和 Spanner 系统中这两种方法都用上了，先用随机延迟的方法通过一轮 Paxos 协议，在多个 Proposer 中选举出一个 leader 节点。接下来所有的写操作都通过这个 leader 节点，而 leader 节点一般还是比较“长寿”的，在广域网环境下平均“任期”可以达到一天以上。而 Megastore 系统中没有很好地解决这个问题，所有的 Proposer 都可以发起写操作，这是 Megastore 写入性能不高的原因之一。

基本的 Paxos 协议还存在性能上的问题，一轮决议过程通常需要进行两个回合通信，而一次跨机房通信的代价为几十到一百毫秒不等，因此两个回合的通信就有点开销过高了。不过幸运的是，绝大多数情况下，Paxos 协议可以优化到仅需一个回合通信。决议过程的第一阶段是不需要指定值的，因此可以把 prepare/promise 的过程捎带在上一轮决议中完成，或者更进一步，在执行一轮决议的过程中隐式地涵盖接下来一轮或者几轮决议的第一阶段。这样，当一轮决议完成之后，其他决议的第一阶段也已经完成了。如此看来，只要 leader 不发生更替，Paxos 协议就可以在一个回合内完成。为了支持实际的业务，Paxos 协议还需要支持并发，多轮决议过程可以并发执行，而代价是故障恢复会更加复杂。

因为 leader 节点上有最新的数据，而在其他节点上为了获取最新的数据来执行 Paxos 协议的第一阶段，需要一个回合的通信代价。因此，Chubby 中的读写操作，以及 Spanner 中的读写事务都仅在 leader 节点上执行。而为了提高读操作的性能，减轻 leader 节点的负载，Spanner 还提供了只读事务和本地读。只读事务只在 leader 节点上获取时间戳信息，再用这个时间戳在其他节点上执行读操作；而本地读则读取节点上最新版本的数据。

与 Chubby、Spanner 这种读写以 leader 节点为中心的设计相比，Megastore 体现了一定的“去中心化”设计。每个客户端都可以发起 Paxos 写操作，而读操作则尽可能在本地执行。如果客户端发现本地数据不是最新的，会启动 catchup 流程更新数据，再执行本地读操作返回给客户端。

最后，对比下其他系统中 replication 的实现。在 BigTable 系统中每个 tablet 服务器是没有副本的，完全依赖底层 GFS 把数据存到多台机器上。数据的读写都通过单个 tablet 服务器，在 tablet 服务器出现故障的时需要 master 服务器将 tablet 指派到其他 tablet 服务器上才能恢复可用。Dynamo 系统则贯彻了“去中心化”的思想，将数据保存在多个副本上，每个副本都可以写入（update everywhere）。而不同副本同时写入的数据可能会存在不一致，则需要使用版本向量（version vector）记录不同的值和时间戳，由应用去解释或合并不一致的数据。尽管 Dynamo 系统还提供了 NWR 的方式来支持有一致性保证的读写操作，但总的来说 Dynamo 为了高可用性牺牲了一致性。ZooKeeper、MongoDB 与 Chubby、Spanner 类似，通过 leader 选举协议从多个副本中选择一个 leader，所有写操作都在经过 leader 节点序列化后，同步到其他副本上。ZooKeeper 则是在写入大多数节点后返回，而 MongoDB 主要采用异步的主从复制方式。

分布式事务

Spanner 系统中的分布式事务通过两阶段提交协议（2PC）实现。2PC 是一类特殊的一致性协议，假设一个分布式事务涉及了多个数据节点，2PC 可以保证在这些节点上的操作要么全部提交，要么全部失败，从而保证了整个分布式事务的原子性（ACID 里的A）。协议中包含两个角色：协调者（coordinator）和参与者（participant/cohort）。协调者是分布式事务的发起者，而参与者是参与了事务的数据节点。在协议最基本的形式中，系统中有一个协调者和多个参与者。

顾名思义，2PC 也包含两个阶段，即投票阶段和提交阶段（如图 3 所示）。

图 3 两阶段提交协议  在第一阶段，协调者向所有的参与者发送投票请求，每个参与者决定是否要提交事务。如果打算提交的话需要写好 redo、undo 等日志，并向协调者回复 yes 或 no。

 在第二阶段，协调者收到所有参与者的回复，如果都是 yes，那么决定提交这个事务，写好日志后向所有参与者广播提交事务的通知。反之，则中止事务并且通知所有参与者。参与者收到提交/中止事务的命令后，执行相应操作，如果提交的话还需要写日志。

协议过程包括两回合的通信，在协调者和参与者端需要多次写日志，而且整个过程中所有参与者都占有读锁、写锁，可见 2PC 开销不菲。

2PC 最令人诟病之处还不在于性能，而是在有些故障条件下，会造成所有参与者占有读锁、写锁堵塞在第二阶段，需要人工干预才能继续，存在严重的可用性隐患。假设故障发生在第二阶段，协调者在做出决定后，通知完一个参与者就宕机了，更糟糕的是被通知的这位参与者在执行完“上级指示”之后也宕机了，这时对其他参与者来说，就必须堵塞在那里等待结果。

Spanner 利用基于 Paxos 协议的复制技术，改善了 2PC 的可用性问题。2PC 协议过程中的协调者和参与者生成的日志都会利用 Paxos 协议复制到所有副本中，这样无论是协调者或参与者宕机，都会有其他副本代替它们，完成 2PC 过程而不至于堵塞。在 Paxos 协议上实现 2PC 这一思路很巧妙，Paxos 协议保证了大多数节点在线情况下的可用性，而 2PC 保证了分布式协议的一致性。

事件的顺序

传统上，在设计一个分布式系统时，都会假设每个节点的运行速度和时钟的快慢各不相同的情况，并且在节点之间进行同步的唯一方法就是异步通信。系统中的每个节点都扮演着观察者的角色，并从其他节点接收事件发生的通知。判断系统中两个事件的先后顺序主要依靠分析它们的因果关系，包括 Lamport 时钟、向量时钟等算法，而这一切都存在通信开销。

因此，Spanner 提出了一种新的思路，在不进行通信的情况下，利用高精度和可观测误差的本地时钟（TrueTime API）给事件打上时间戳，并且以此比较分布式系统中两个事件的先后顺序。利用这个方法，Spanner 实现了事务之间的外部一致性（external consistency）（如图 4 所示），也就是说，一个事务结束后另一个事务才开始，Spanner 可以保证第一个事务的时间戳比第二个事务的时间戳要早，从而两个事务被串行化后也一定能保持正确的顺序。

图 4 事务外部一致性的实现

TrueTime API 是一个提供本地时间的接口，但与 Linux 上 gettimeofday 接口不一样的是，它除了可以返回一个时间戳t，还会给出一个误差ε。例如，返回的时间戳是 1 分 30 秒 350 毫秒，而误差是 5 毫秒，那么真实的时间在 1 分 30 秒 345 毫秒到 355 毫秒之间。真实的系统中ε平均下来是 4 毫秒。

利用 TrueTime API，Spanner 可以保证给出的事务标记的时间戳介于事务开始的真实时间和事务结束的真实时间之间。假如事务开始时 TrueTime API 返回的时间是{t1, ε1}，此时真实时间在 t1-ε1到 t1+ε1之间；事务结束时 TrueTime API 返回的时间是{t2, ε2}，此时真实时间在 t2-ε2到 t2+ε2之间。Spanner 会在 t1+ε1和 t2-ε2之间选择一个时间点作为事务的时间戳，但这需要保证 t1+ε1小于 t2-ε2，为了保证这点，Spanner 会在事务执行过程中等待，直到 t2-ε2大于 t1+ε1时才提交事务。由此可以推导出，Spanner 中一个事务至少需要2ε的时间（平均 8 毫秒）才能完成。

由此可见，这种新方法虽然避免了通信开销，却引入了等待时间。为了保证外部一致性，写延迟是不可避免的，这也印证了 CAP 定理所揭示的法则，一致性与延迟之间是需要权衡的。

最后介绍一下 TrueTime API 的实现。TrueTime API 的实现大体上类似于网络时间协议（NTP），但只有两个层次。第一层次，服务器是拥有高精度计时设备的，每个机房若干台，大部分机器都装备了 GPS 接收器，剩下少数机器是为 GPS 系统全部失效的情况而准备的，叫做“末日”服务器，装备了原子钟。所有的 Spanner 服务器都属于第二层，定期向多个第一层的时间服务器获取时间来校正本地时钟，先减去通信时间，再去除异常值，最后求交集。

NewSQL

六年前，BigTable 展示了一个简洁、优美、具有高可扩展性的分布式数据库系统，引起了 NoSQL 浪潮。然而 Spanner 的设计者们指出了 BigTable 在应用中遇到的一些阻力。

 缺少类似 SQL 的界面，缺少关系数据库拥有的丰富的功能。 只支持单行事务，缺少跨行事务。



需要在跨数据中心的多个副本间保证一致性。

这些来自应用开发者的需求催生了 Spanner，一个既拥有 key-value 系统的高可扩展性，也拥有关系数据库的丰富功能（包括事务、一致性等特性）的系统。这类兼顾可扩展性和关系数据库功能的产品被称为“NewSQL”，Spanner 的公开会不会开启 NewSQL 的时代呢？我们拭目以待。

总结

最后从 CAP 定理的角度来分析下 Spanner。

CAP 定理是指在网络可能出现分区故障的情况下，一致性和可用性不可得兼。形式化地说就是，P => 非(A与P)，可以更进一步地总结为，一致性和延迟之间必须进行权衡。Paxos 协议在C和A之间选择了严格的一致性，而A则降级为大多数一致性（majority available）。

Spanner 还通过在事务中增加延迟的方法实现了外部一致性，每个事务需要至少两倍的时钟误差才能完成。如果时钟出现故障造成误差增长，那么完成事务所需的时间也就随之增长。在这里，时钟故障也应当认为是P的一种形式。在发生时钟故障（P）的情况下，为了保证一致性（C），而必须增加延迟（A），这一点充分印证了 CAP 定理。

从 Spanner 系统中，我们可以学习到一些经验。

 MegaStore、Spanner 和 F1 系统所选择的树形、层次化的数据库 schema 是很精妙的，它能支持高效的表连接，这既提供了类似关系模型的范式，也提供了一个合适的粒度进行数据分区，具有好的可扩展性，H-Store 也采用了这样的 schema。

 跨数据中心的多个副本间保持一致是可行的，Paxos 协议的性能可以优化到一个可接受的范围。

 在 Paxos 协议的基础之上实现的两阶段提交的可用性得到了提高。 在一个分布式系统中，本地时钟的作用可以比我们之前想象的大很多。

作者曹伟，淘宝核心系统数据库组技术专家，从事高性能服务器、IM、P2P、微博等各类型分布式系统、海量存储产品的开发，关注系统高可用性和一致性及分布式事务领域。