英文：20141204_umpay_liusheng_noice_research 中文：20141204支付清算行业分布式系统架构设计研究报告（草案）联动优势刘胜.doc 文件：20141204去IOE研究提纲4-联动优势刘胜.doc 说明：本文是为支付清算行业协会编写的“支付清算行业分布式系统架构设计研究报告”草案。 目录： 1. 前言（中行） 2 2. 支付清算行业分布式系统架构概述（光大） 2 3. 典型系统架构（财付通） 3 3.1. 分布式服务架构 3 3.2. 高可用数据架构 4 3.3. 多中心部署架构 5 4. 最佳实践 5 4.1. 用户交互层（概述部分联动） 6 4.1.1. 负载均衡 6 4.1.1.1. 负载均衡概述（联动） 6 4.1.1.2. 案例：使用LVS负载均衡（支付宝） 7 4.1.1.3. 案例：使用名字服务负载均衡（财付通） 7 4.1.2. 反向代理（联动优势） 7 4.1.2.1. 反向代理概述（联动） 7 4.1.3. 页面片段缓存（支付宝） 7 4.1.3.1. 页面片段缓存概述（联动） 8 4.1.3.2. 案例CDN（支付宝） 8 4.1.4. 访问控制 8 4.1.4.1. 访问控制概述（财付通） 8 4.1.4.2. 支付宝案例 8 4.1.4.3. 财付通案例 8 4.1.5. 网络流量控制 8 4.1.5.1. 流量控制概述（联动） 8 4.1.5.2. 财付通案例 9 4.1.5.3. 支付宝案例 9 4.2. 业务逻辑层（概述部分联动） 9 4.2.1. 高可用消息队列 9 4.2.1.1. 高可用消息队列概述（联动） 9 4.2.1.2. 案例：ZQ队列（支付宝） 10 4.2.1.3. 案例：ActiveMQ队列（财付通） 10 4.2.2. 分布式任务调度 10 4.2.2.1. 概述（支付宝） 10 4.2.2.2. 案例：支付宝 10 4.2.3. 分布式服务监控 10 4.2.3.1. 分布式监控概述（联动） 11 4.2.3.2. 案例：支付宝监控架构 12 4.2.3.3. 案例：财付通 12 4.2.4. 服务配置管理 12 4.2.5. 服务流量控制 12 4.2.5.1. 服务流量控制概述（联动） 12 4.2.5.2. 案例：支付宝 13 4.2.5.3. 案例：财付通 13 4.3. 数据持久层（概述部分联动） 13 4.3.1. 分布式文件系统（支付宝） 13 4.3.2. 分布式键值存储库（K-V） 13 4.3.2.1. 分布式键值存储库概述（联动） 13 4.3.2.2. 案例：支付宝 13 4.3.2.3. 案例：财付通 13 4.3.3. 高可用关系数据库 14 4.3.3.1. 高可用关系数据库概述（联动） 14 4.3.3.2. 案例：MySql（财付通） 16 4.3.3.3. 案例：OceanBase（支付宝） 16 4.3.4. 分布式数据访问层（DAL服务） 16 4.3.4.1. 分布式数据访问层概述（联动） 16 4.3.4.2. 案例：典型DaaS实现（联动UDAL） 18 4.3.4.3. 案例：典型RDS实现（阿里RDS云服务） 19 4.3.5. 分布式事务协调（DTC服务） 19 4.3.5.1. 分布式事务协调概述（联动） 20 4.3.5.2. 案例1：支付宝 21 4.3.5.3. 案例2：财付通 21 4.3.6. 数据库复制工具 21 4.3.6.1. 数据库复制技术概述（联动） 21 4.3.6.2. 案例：联动优势DB2复制工具（联动） 22 4.3.6.3. 案例：支付宝 23 4.3.6.4. 案例：财付通 23 5. 支付清算行业信息技术发展展望（中行） 23

1. 支付清算行业分布式系统架构设计
1. 前言（中行）................................................................................................................................................ 2
2. 支付清算行业分布式系统架构概述（光大）.............................................................................................2
3. 典型系统架构（财付通）............................................................................................................................ 3
3.1. 分布式服务架构................................................................................................................................. 3
3.2. 高可用数据架构................................................................................................................................. 4
3.3. 多中心部署架构................................................................................................................................. 5
4. 最佳实践....................................................................................................................................................... 5
4.1. 用户交互层（概述部分联动）..........................................................................................................6
4.1.1. 负载均衡.................................................................................................................................. 6
4.1.1.1. 负载均衡概述（联动）................................................................................................6
4.1.1.2. 案例：使用LVS负载均衡（支付宝）.........................................................................7
4.1.1.3. 案例：使用名字服务负载均衡（财付通）.................................................................7
4.1.2. 反向代理（联动优势）........................................................................................................... 7
4.1.2.1. 反向代理概述（联动）................................................................................................7
4.1.3. 页面片段缓存（支付宝）....................................................................................................... 8
4.1.3.1. 页面片段缓存概述（联动）........................................................................................8
4.1.3.2. 案例CDN（支付宝）....................................................................................................8
4.1.4. 访问控制.................................................................................................................................. 8
4.1.4.1. 访问控制概述（财付通）............................................................................................9
4.1.4.2. 支付宝案例................................................................................................................... 9
4.1.4.3. 财付通案例................................................................................................................... 9
4.1.5. 网络流量控制.......................................................................................................................... 9
4.1.5.1. 流量控制概述（联动）................................................................................................9
4.1.5.2. 财付通案例................................................................................................................... 9
4.1.5.3. 支付宝案例................................................................................................................... 9
4.2. 业务逻辑层（概述部分联动）........................................................................................................10
4.2.1. 高可用消息队列.................................................................................................................... 10
4.2.1.1. 高可用消息队列概述（联动）..................................................................................10
4.2.1.2. 案例：ZQ队列（支付宝）.........................................................................................11
4.2.1.3. 案例：ActiveMQ队列（财付通）.............................................................................11
4.2.2. 分布式任务调度.................................................................................................................... 11
4.2.2.1. 概述（支付宝）.......................................................................................................... 11
4.2.2.2. 案例：支付宝.............................................................................................................11
4.2.3. 分布式服务监控.................................................................................................................... 11
4.2.3.1. 分布式监控概述（联动）..........................................................................................12
4.2.3.2. 案例：支付宝监控架构..............................................................................................13
4.2.3.3. 案例：财付通.............................................................................................................13
4.2.4. 服务配置管理........................................................................................................................ 13
4.2.5. 服务流量控制........................................................................................................................ 13
4.2.5.1. 服务流量控制概述（联动）......................................................................................13
4.2.5.2. 案例：支付宝.............................................................................................................14

2. 4.2.5.3. 案例：财付通.............................................................................................................14
4.3. 数据持久层（概述部分联动）........................................................................................................14
4.3.1. 分布式文件系统（支付宝）.................................................................................................14
4.3.2. 分布式键值存储库（K-V）...................................................................................................14
4.3.2.1. 分布式键值存储库概述（联动）..............................................................................14
4.3.2.2. 案例：支付宝.............................................................................................................15
4.3.2.3. 案例：财付通.............................................................................................................15
4.3.3. 高可用关系数据库................................................................................................................ 15
4.3.3.1. 高可用关系数据库概述（联动）..............................................................................15
4.3.3.2. 案例：MySql（财付通）............................................................................................17
4.3.3.3. 案例：OceanBase（支付宝）....................................................................................17
4.3.4. 分布式数据访问层（DAL服务）..........................................................................................17
4.3.4.1. 分布式数据访问层概述（联动）..............................................................................18
4.3.4.2. 案例：典型DaaS实现（联动UDAL）.......................................................................20
4.3.4.3. 案例：典型RDS实现（阿里RDS云服务）...............................................................21
4.3.5. 分布式事务协调（DTC服务）..............................................................................................21
4.3.5.1. 分布式事务协调概述（联动）..................................................................................21
4.3.5.2. 案例1：支付宝...........................................................................................................22
4.3.5.3. 案例2：财付通...........................................................................................................22
4.3.6. 数据库复制工具.................................................................................................................... 22
4.3.6.1. 数据库复制技术概述（联动）..................................................................................22
4.3.6.2. 案例：联动优势DB2复制工具（联动）..................................................................23
4.3.6.3. 案例：支付宝.............................................................................................................24
4.3.6.4. 案例：财付通.............................................................................................................24
5. 支付清算行业信息技术发展展望（中行）...............................................................................................24
1. 前言（中行）
支付行业系统整体情况。
支付行业系统发展面临的问题。
2. 支付清算行业分布式系统架构概述（光大）
非IOE架构发展状况、特点等。
提出文章的总体思路：分布式服务。

3. 3. 典型系统架构（财付通）
3.1. 分布式服务架构
如上图所示的一个典型的分布式服务系统是以三层体系结构的设计思想为基础，通过对数据缓存
层和消息总线系统的引入，以达到进一步提高系统性能的目的。各个系统层次作用如下：
1．表示层：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。
2．业务逻辑层：主要是针对具体的问题的操作，也可以理解为对数据层的操作。业务逻辑层通过
对数据层的访问，实现指定的业务逻辑。
3．数据访问层：主要是对原始数据（数据库或数据缓存）的操作访问层，而不是指原始数据，也
就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务。
4．数据缓存层：在一般的三层体系结构中，数据访问层一般直接访问数据库或文件系统。在分布
式服务系统中，由于底层数据库服务器存在性能瓶颈问题，为了降低数据访问的延时，可以增加一个
数据缓存层，通过内存缓存数据，提高系统整体性能。
消息总线系统：消息总线系统主要是通过消息的订阅和分发，实现部分业务逻辑的异步化处理，
以减少实时联机交易的处理工作量，提高系统响应性能。

4. 3.2. 高可用数据架构
分布式数据架构可伸缩策略可以按照三个维度：
1．按照业务类型进行垂直拆分。
2．按照客户请求进行水平拆分。
3．对于读远远大于写的数据进行数据复制和读写分离处理。
交易系统的数据主要分为三大数据库集群：
1. 主交易数据库集群，每一笔交易创建和状态的修改⾸首先在这里完成，产生的变更再通过可
靠数据复制中心复制到其他两个数据库集群：消费记录数据库集群、商户查询数据库集群。该
数据库集群的数据被水平拆分成多分，为了既保证可伸缩性和高可靠性，每一个节点都会与
之对应的备用节点和failover节点，在出现故障的时候可以在秒级内切换到failover节点。
2. 消费记录数据库集群，提供消费者更好的⾸用户体验和需求；
商户查询数据库集群，提供商户更好的用户体验和需求；

5. 3.3. 多中心部署架构
多中心部署架构，可以解决如下几个关键问题：
1. 跨单元交互异步化和尽量的少，让异地部署成为可能。整个系统的水平可伸缩性大大提高，不
再依赖同城IDC；
2. 灾备成本和可用性问题，可以实现N+1的异地灾备策略，让灾备的成本变小同时一定是确保
灾备可用的；
3. 整个系统的稳定性提升，这个架构的形成证明了整个系统已经无单点，同城部署多个单元可
以互相切换，有机会做到100%的可用率；
4. 整体系统的可管控能力提升，这个架构让线上压测，流量管控，整体灰度发布等以前难以实
现的需求变的简单。主要因为这套架构的形成让我们在业务级别的流量入口，出口形成了统一
的可管控，可路由的控制点。
4. 最佳实践
示范案例：XXX系统XX业务高可用方案（每个案例字数在1页到2页）
1.需求及问题
（针对该技术使用在支付清算系统中的某一个具体的子模块进行说明，如订单处理模块、账户模
块、队列处理模块、访问控制模块等等，写明该模块的需求内容，要解决的问题等）
2.设计思路及架构说明
（针对该场景有何解决办法，选择解决办法的思路，并对实施的解决方案进行说明）

6. 3.实施效果：
（针对该解决方案的实施效果采用横向比较、纵向比较、定性、定量等方法进行适当说明）
4.1. 用户交互层（概述部分联动）
4.1.1. 负载均衡
概述：对能力描述以及协议层次（IP层 、tcp层）
硬件负载均衡（联动）
概述
Lvs（支付宝）
概述
案例。。。。。
名字服务(l5)(财付通)
案例
4.1.1.1.负载均衡概述（联动）
负载均衡（Load Balancing）是一种计算机网络技术，用来在多个计算机或计算机集群、网络连接、
CPU、磁盘驱动器或其他资源中分配负载，以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同
时避免过载的目的。使用带有负载平衡的多个服务器组件，取代单一的组件，可以通过冗余提高整个系
统的可靠性。而负载均衡器（Load Balancer）就是完成此功能的一个专用软件或硬件设备。
可以采用两大模式，在不同层面、使用不同技术来实现负载均衡功能。
模式1：代理中转方式
 IP层软件负载均衡。如Linux下的LVS软件。特点是内核级操作，负载能力较强，但不检测后端
服务器状态，需要结合一些脚本，才能避免将请求转发到已停机的服务器上。
 TCP层软件负载均衡。如开源HA-Proxy软件。特点是能够智能检测服务器状态，缺点是负载能
力较差。
 HTTP层软件负载均衡。如开源的Apache和Nginx等软件。特点是解析HTTP报文，从而能基于
某些策略，实现服务器粘连性，确保同一个用户的请求，都转发到同一个后台服务器上。
 硬件负载均衡器，基于IP/TCP/HTTP 等多个层次和网络协议，完成负载均衡。如F5 Big-

7. IP，Radware WSD-NP等。特点是负载能力强，功能丰富；缺点是成本较高。
模式2：服务查找方式
 使用智能DNS域名解析服务器。缺点是修改DNS后，生效时间较长，不适合用于支付清算相
关业务。
 使用自定义名字服务或配置中心。特点是需要结合前端应用软件，来完成负载均衡。
4.1.1.2.案例：使用LVS负载均衡（支付宝）
4.1.1.3.案例：使用名字服务负载均衡（财付通）
4.1.2. 反向代理（联动优势）
概述：Apache，Ngix
4.1.2.1.反向代理概述（联动）
反向代理（Reverse Proxy）是指以代理服务器来接受互联网上的连接请求，然后将请求转发给内
部网络上的服务器，并将从服务器上得到的结果返回客户端，此时代理服务器对外就表现为一个服务
器。
通过使用反向代理，可获得如下一些好处：
 提高内部服务器安全性：与一般代理的不同之处在于，这个服务器没有保存任何网页的真实
数据，所有的静态网页或者CGI程序，都保存在内部服务器上。因此对反向代理服务器的攻击
并不会使得网页信息遭到破坏，这样就增强了内部服务器的安全性。
 降低内部服务器的负载：反向代理服务器承担了对内部服务器的静态页面的请求，防止内部
服务器过载。

8. 大多数Web服务器都具备反向代理功能，如Apache和Nginx等。
反向代理通常和HTTP层负载均衡结合使用。
4.1.3. 页面片段缓存（支付宝）
概述
案例cdn
4.1.3.1.页面片段缓存概述（联动）
页面片段缓存是大型系统里经常采用的一种数据缓存技术。通过将页面中的静态和动态片段进行区
分，避免由于页面中这些少量的动态内容而无法将整个页面进行缓存。
业界已有成熟的解决方案，并且有一个W3C标准：ESI（Edge Side Include）。它是一种简单的页面
标识语言，开发人员可以使用它标志各种内容片断，方便缓存服务器识别，并提高缓存效果，从而有
效降低原服务器的负载，同时提高用户访问的响应时间。
开源代理软件Squid和Varnish都有支持ESI的响应模块。
CDN网络也可以利用在分布全国各地的节点中安装支持ESI的Cache服务器来提供对网站动态内容
提供CDN服务。
4.1.3.2.案例CDN（支付宝）
4.1.4. 访问控制
概述（财付通）接口，加密，登陆权限
支付宝案例

9. 财付通案例
4.1.4.1.访问控制概述（财付通）
4.1.4.2.支付宝案例
4.1.4.3.财付通案例
4.1.5. 网络流量控制
概述：这部分流量控制的功能和作用
财付通案例
支付宝案例
4.1.5.1.流量控制概述（联动）
流量控制可以有效的防止由于网络中瞬间的大量数据对网络和服务器带来的冲击，保证网络和服
务器系统高效而稳定的运行。
 网络流量控制：是针对在单位时间内的网络带宽、被发送到网络中的数据量，或者是最大速率
的数据流量发送。
 服务流量控制：主要是针对单位时间内的服务请求数量进行控制，及时分流或限流，防止后
台某单一服务器的过载，而无法响应用户请求，甚至导致整个服务器集群的“雪崩”。
4.1.5.2.财付通案例
4.1.5.3.支付宝案例

10. 4.2. 业务逻辑层（概述部分联动）
4.2.1. 高可用消息队列
概述：重点体现异步化
Zq（支付宝）：概述，案例。。。。。。。。
Activemq（财付通）
4.2.1.1.高可用消息队列概述（联动）
消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。消息队列提
供了异步的通信协议，消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到
接收者取回它。
在一个大型系统中，通过引入“消息队列”组件，可实现如下一些目标：
 解耦子系统：1）各子系统作为队列消息的“生产者”或“消费者”，都能独立地扩展升级。2）消
费者进程异常中断，还可在恢复后继续处理队列消息。3）通过简单增加“生产者”或“消费者”进
程，就可提高消息入队频率或消息处理能力，而不需修改代码或调解参数。
 提升可靠性：1）可靠传输消息：每个消息可靠送达，且只送达一次。2）可靠处理消息：通过
持久化和"插入-获取-删除"范式，确保每阶段的数据都能被正确处理，每一个消息只能被处理
一次。3）顺序处理消息：通过设定，可以能保证数据会按照FIFO（先进先出）的顺序来处理。
4）性能削峰填谷：使用消息队列能够使关键组件顶住增长的访问压力，而不是因为超出负荷
的请求而完全崩溃。5）优化处理过程：通过消息被处理的频率和延时，快速确定那些表现不
佳的处理环节，为进一步优化系统提供依据。
 实现异步通信：消息队列提供了异步处理机制，使得发送方和接收方都不用等待对方返回成
功消息，就可以继续执行后续任务，从而提高了系统的整体处理能力。
然而，随着业务的发展，对消息队列的依赖越来越大，对消息队列的性能和可靠性要求也越来越
高，此时需要一个高可用的分布式消息队列集群。
 主备模式（Active/Passive）：例如，高可用ActiveMQ架构，提供了基于共享存储、基于JDBC、
基于Zookeeper的复制LevelDB存储等多种主从实现机制，从而实现高可用性。
 多主模式（Active/Active）：例如，分布式消息队列Kafka，通过ZooKeeper管理和协调Kafka
代理，可以在集群中动态地增加或减少Kafka代理，从而实现高可用性。（见下图）

11. 4.2.1.2.案例：ZQ队列（支付宝）
4.2.1.3.案例：ActiveMQ队列（财付通）
4.2.2. 分布式任务调度
概述（支付宝）
案例（支付宝）
4.2.2.1.概述（支付宝）
4.2.2.2.案例：支付宝
4.2.3. 分布式服务监控
概述
业务监控，渠道监控，
推模式，拉模式

12. 监控架构，服务体系支持
实时性要求不同区别，采取不同方案
支付宝案例（支付宝监控架构）
财付通案例
4.2.3.1.分布式监控概述（联动）
1，监控的维度（做什么）：
按目标和操作这两个维度，监控可分为四个象限：系统监视、系统控制、应用监视、应用控制。不同
的技术工具，所覆盖的象限范围是不同的。
2，监控的模式（怎么做）：
系统和应用监控，一般分两种模式：Agent模式和Agentless模式。前者对于Agent实现，要求具有
高性能、高靠性、占用资源低、采集数据大。而后者，则依赖多种不同方式来获取数据，
SNMP，Telnet，SSH，WMI，JMX，JDBC，ODBC等。两者比较如下表。
监控方式Agent Agentless
对被监控
占用一定的CPU和内存运行Agent
对CPU和内存的影响，除了对
资源的影
代理软件本身。
telnet/SSH/wmi的影响，其它几乎可忽
响
略。
对监控服
务器的影
响
大部分工作通过监控资源端的Agent
代理软件完成，对监控服务器的影
响相对较小
所有工作通过监控服务器远程连接监控
资源端实现，对监控服务器的影响相对
较大
对网络带
宽的影响
在监控资源端采集的数据，经过压
缩处理后，传输给监控服务器，故
对网络带宽的占用较低。
监控服务器采集的信息直接传输给监控
服务器，数据都未经压缩和汇总，故数
据量相对较大。
监控指标Agent代理监控方式一般都支持二次
开发，监控用户关心的独特的指标。
受实现方式所限，一般监控指标相对固
定，不支持二次开发。
部署方式部署相对麻烦，需要每台主机部署
安装
只需要开通相应的协议和端口，几乎不
需要部署
功能特性即可监视，也可控制控制能力有限
3，监控的模块（怎么分）
一个典型Agent模式的监控系统，包含三个子系统。
3.1）监控代理Agent：包括定时调度引擎、脚本执行引擎、自动更新引擎等。
3.2）数据采集中心：包括告警规则引擎、数据存储引擎（DB或Rrdtool）、图形/报表引擎等。
3.3）告警通知中心：支持日志、邮件、短信、IM等多种通知方式。
4，推和拉模式（数据流向）
 推模式：由Agent将采集到的数据，定时上传到“数据采集中心”。由于Agent不保留数据，上传的

13. 总数据量较大，且“数据采集中心”时，数据有丢失。
 拉模式：由“数据采集中心”定时主动请求Agent索取所需的监控数据。Agent有一定计算能力，可
以对原始数据进行精简，从而减小上传的数据总量。但是Agnet需要开启服务端口，提供远程服务，
会带来一定的安全隐患。
 推拉结合：以推方式实现拉的功能。 Agent主动通过脚本获取采样数据保存到本地。Agent定期根据
指令向Server上传统计数据。避免开启额外端口，安全性更好。但对Agent要求更高，开发难度大。
4.2.3.2.案例：支付宝监控架构
4.2.3.3.案例：财付通
4.2.4. 服务配置管理
概述：服务配置管理的内容，作用等。
配置中心(支付宝)
概述
案例（配置中心）
应用层 dns（联动优势）
概述
案例
4.2.5. 服务流量控制
概述
这部分流量控制的功能和作用
渠道流量控制，与4.1.5流量控制区别
4.2.5.1.服务流量控制概述（联动）
流量控制可以有效的防止由于网络中瞬间的大量数据对网络和服务器带来的冲击，保证网络和服
务器系统高效而稳定的运行。

14. 与“网络流量控制”不同的是，服务流量控制，主要是针对单位时间内的服务请求数量进行控制，
及时分流或限流，防止后台某单一服务器的过载，而无法响应用户请求，甚至导致整个服务器集群的
“雪崩”。
4.2.5.2.案例：支付宝
4.2.5.3.案例：财付通
4.3. 数据持久层（概述部分联动）
4.3.1. 分布式文件系统（支付宝）
概述（支付宝）普通文件不足，扩容，管理难。
案例
对账文件（支付宝）
4.3.2. 分布式键值存储库（K-V）
基于KV的分布式数据缓存概述
支付宝案例
财付通案例
4.3.2.1.分布式键值存储库概述（联动）
键值存储库是一种采用采用Key-Value模型的NoSQL数据库，它：
 放弃了传统数据库的结构化和关系型，以支持各种非结构化和半结构化的数据；
 放弃了ACID强一致性事务，代之以BASE（基本可用，柔性状态，最终一致性）；
 放弃了SQL访问方式，代之以K-V方式，追求高扩展和高性能。
通过分布式部署键值存储库，可以支持海量非结构化数据的高并发读写访问。
对于金融行业来说，也适合将其作为高可用数据缓存系统。
常见的键值存储库有Memcached、Redis、Dynamo、LevelDB等。

15. 4.3.2.2.案例：支付宝
4.3.2.3.案例：财付通
4.3.3. 高可用关系数据库
4.3.3.1. 高可用关系数据库概述（联动）
为了解决数据库的单点故障，提高系统的整体可用性，有两条技术路线。
 技术路线1：基于传统关系型数据库的高可用集群。主要包括共享存储（Share-Storage）、
全共享（Share-Everything）、无共享（Share-Nothing）三类。
 技术路线2：基于NewSQL数据库的高可用架构。如谷歌的Spanner/F1数据库，阿里的
OceanBase分布式数据库。
目前，中小银行的核心系统，对事务一致性要求高，主要采用下面两种集中式方案。
 基于“Share-Storage架构”的主备数据库集群：双机主备，但由于主库和备库共享了一个
磁盘阵列，导致主备切换时间较长。
 基于“Share-Everything架构”的数据库集群：此时不仅共享存储，同时还共享缓存。典型案
例为Oracle RAC数据库集群，由于过度依赖其一致性缓存技术，导致其扩展能力不足，一般只能
扩展到4～10台左右。
更好的方式，是采用基于数据库复制的“Share-Nothing架构”，具备数据冗余，能快速实现主

16. 备切换，具有更高的可用性。针对不同场景，有如下几种方案：
 方案1.主主方式
 方案2.双主多从
 方案3.分片只读
 方案4.分片读写
前两个方案，数据未做水平拆分，写扩展能力有限。后两个方案，数据已做水平拆分，但是分
布式一致性问题难以解决。要解决分布式一致性，一种方案是结合应用端，按照某种分布式一致性
算法，来实现轻量级的事务一致性；另一方案则是引入全新架构的NewSQL数据库，由NewSQL
数据库来保证分布式事务一致性。
1.主主方式2.双主多从+VIP（或：双主多从+DAL）
3.分片只读+DAL 4.分片读写+DAL
几种方案的简要对比如下：
特性×∨√ SSQQLL++集
群
SSQQLL++分片++集
群
NNeewwSSQQLL
R 关系型 √ ∨弱关系√弱关系
Q 支持SQL √ ∨不支持跨库 √精简SQL
C
索引 √ ∨无全局索引 √
关联 √ ∨无跨库JOIN √
事务/ACID √ ∨无跨库事务 √
同DC一致
性
√ ∨可调整∨可调整
跨DC一致
性
× × √

17. A
高扩展容量× √ √
高扩展写 × ∨分片+写√写延时较大
高扩展读√读写分离∨分片+读写分离√
实时性/内存 × × √
P 数据分片× ∨无跨库写√
分片方式 × ∨应用分片√自动分布
案
例
1．主主方
式
3.分片只读+DAL 5.OceanBase数据库
2．双主多
从
4.分片读写+DAL
4.3.3.2. 案例：MySql（财付通）
4.3.3.3. 案例：OceanBase（支付宝）
案例：分布式OceanBase数据库架构
4.3.4. 分布式数据访问层（DAL服务）
概述

18. 案例tddl（支付宝）
案例zdal（支付宝）
案例（金融云rds）（支付宝）
案例（udal）（联动）
4.3.4.1.分布式数据访问层概述（联动）
随着业务量不断增长，传统的三层架构已经无法满足需求，需要进行进一步横向扩展，变集中式
为分布式。而这三层当中，主要包括三类服务器：处理静态页面的Web服务器、处理动态逻辑的APP服
务器、存储数据的DB数据库服务器。对于WEB和APP层，都比较容易实现多机部署和负载均衡，从而
消除单点故障，提高系统的可用性。而DB则是最后一个，也是最难解决的单点故障环节。
当传统Web应用面对高并发数据访问需求时，原底层单数据库设计难以有效支撑上层应用的数据
访问。此时一般通过如下几种方式对DB减负，从而提高系统的整体可用性。
1）按应用拆分——不同业务系统使用不同的数据库（即垂直分区）。
2）按操作拆分——增加多个全量数据镜像，提供数据冗余，实现“读写分离”访问。
3）按数据拆分——相同业务系统根据某种分片策略（时间、ID、HASH等）使用不同的数据库和表
（即水平分区）。
4）按类型拆分——将部分数据从关系数据库迁移到NOSQL数据库中，减少对前者的依赖。
其中1）无需改造业务系统，比较容易实现。而2）3）4）则需要对业务系统做一定改造。尤其对于
3）而言，经常需要根据不同场景下、不同数据量来调整分片策略。在当DB较少，而应用很多时，需要
同时修改多个应用系统，实施起来很困难。此时，需要引入一个独立的数据访问层（DAL），来屏蔽因
为各种拆分而导致的复杂性，简化APP层开发的难度。
维基百科上，将数据访问层（DAL）定义为一种计算机程序层，它提供对存储在某种类型的，持

19. 久存储数据的简单访问，如关系型数据库。其他应用程序模块通过DAL来访问和操纵各种数据存储中的
数据，而不必处理这种访问方式固有的复杂性。简单来说，DAL是一系列服务的集合，是DAO在大型系
统中的自然延伸，是SOA的具体实现。
通过引入独立的数据访问中间层（DAL），可以达到如下一些目标：
1）简化客户端接口，规范数据操作，以便实现“透明性”分片。
2）保持客户端接口，动态升级服务端实现，实现SOA架构。
3）支持访问海量数据，包括分布式缓存、读写分离、数据分片（分库/分表）等。
4）支持对服务的治理，实现各种认证、管理、权限、监控、分析、优化等。
目前数据访问层DAL（Data Access Layer）有三种实现方式：
1）客户端端封装方式：针对特定接口封装自定义SDK包，供前端业务系统端调用。
a) 采用自定义接口或SDK开发包。
b) 实现自定义JDBC驱动，访问多个分库和分表。
c) 实现自定义DataSource数据源，从数据源获取相关DB连接完成操作。，
2）服务端封装RDS中间层（Relational-Database-Service）。完全针对关系型数据服务，应用端SQL
和JDBC 驱动完成和中间层的交互。已有的淘宝TDDL，Amoeba，Cobar，阿里DRDS、奇虎
Atlas，网易DDB、腾讯云数据库、百度DDBS、亚马逊RDS、微软AzureSQL、谷歌Cloud SQL等系统
或服务，都是采用这种方式。其中部分实现完全兼容MySQL网络协议，应用端无需修改任何代
码或驱动库，即可完成数据库访问操作。
3）服务端封装DaaS中间层（Data-as-a-Service）将数据及对数据的访问视为一种服务，此时不限
于访问关系型数据库，还能访问各种非关系型数据库，甚至是Tuxedo中间件之类的在线服务。
此时，需要放弃JDBC网络接口，甚至放弃SQL语法，而改用自定义接口提供给APP端来访问。
如SUN 的JPA 规范，Amazon 的S3 /SimpleDB/DynamoDB 等，Google 的CloudDataStore 和
BigTable等。
其中，3）也可和1）2）结合使用，其层次关系如上图。

20. 4.3.4.2.案例：典型DaaS实现（联动UDAL）
联动优势的UDAL方案，主要采用DaaS方式进行设计和实现，同时也在客户端封装了自定义SDK
和JDBC驱动，方便业务系统调用。
联动优势UDAL的具体实现过程，分为四个阶段：
第一阶段（Udal-Server）：实现DaaS中间层基础架构，完成UDAL服务器，代理各种数据库和在
线服务的访问。
第二阶段（Udal-Client）：为方便业务应用端使用，封装了远程和本地两种接口。前者通过Udal-
Server访问所需数据，后者则直接访问后台数据库和在线服务。
第三阶段（Udal-Shards）：在上述基础上，实现对分片数据（分库和分表）的访问。支持“分库+分
表”访问方式，读写分离、单列/多列分片、全局/单条/范围查询、结果集合并/二次排序、多表分页查询等
高级特性。
第四阶段（Udal-Jdbc）：在上述基础上，实现对SQL的解析。同时通过定制JDBC驱动器（Udal-
Jdbc）与UDAL服务器相连，使用iBatis测试用例完成相关测试。此时应用端直接用Udal-Jdbc驱动，替
代原有的DB2或MySql数据库的JDBC驱动，而无需修改业务代码，就可完成对分库分表的统一访问。
【注：更多细节，请参考“附录U2：联动优势数据访问服务层UDAL”。】
首先，UDAL满足如下一些功能性需求：
1）服务代理：提供独立的数据访问中间层，代理完成所有的数据访问操作。
2）资源共享：a）共享数据库连接池，降低核心DB的并发连接总数；b）共享缓存，提高多机部
署时的缓存命中率；
3）读写分离：识别并区分数据库的读和写操作，根据读写类型访问不同的数据库。
4）数据分片：有两种实现方式：a）根据自定义协议实现分片数据访问；b）根据动态SQL语句
实现分片数据访问。
同时，UDAL还满足如下一些非功能性需求：
1）无状态性：方便进行多机部署和负载均衡。

21. 2）平台中立：支持将DAL服务器部署在多种操作系统上。
3）前端语言中立：支持多种DAL客户端，支持Java、C/C++、PHP、Flex等多种语言。
4）后端数据库中立：
i. 支持多个厂商的关系型数据库（如DB2、MySQL等），以及混搭使用。
ii. 支持多种NOSQL数据库（如MemCached、MongoDB等），以及混搭使用。
iii. 支持Tuxedo中间件等在线服务。
5）数据访问安全性增强（访问控制）：
i. 用户认证：单认证策略；多认证策略；
ii. 连接管理：限制用户连接数；限制IP连接数；
iii. 权限控制：基于角色的授权；精确控制到SQL语句级，而不是库/表/字段级。
4.3.4.3.案例：典型RDS实现（阿里RDS云服务）
4.3.5. 分布式事务协调（DTC服务）
概述
保证最终一致性、冻结
财付通案例
支付宝案例
4.3.5.1.分布式事务协调概述（联动）
对于一个“高可用关系型数据库”而言，为了支持海量数据和高可用性，其数据分布和系统分布都
在所难免。如何确保一致性，这就牵涉到分布式事务一致性的问题，即在一个分布式系统中实现事务的
ACID（Atomic，Consistent，Isolated与Durable）属性。
 方案1：基于CAP理论，适当放弃ACID强一致性，基于BASE原则，实现基本可用（Basically
Available）、柔性状态（Soft-state）、和最终一致性（Eventual Consistency）。
 方案2：引入分布式事务协调机制，即DTC（Distributed Transaction Coordinator），按照某种
一致性算法，将一个事务分为准备（Prepare）、提交（Commit）等多个阶段，要求整个事务
的所有参与者以投票形式决定事务是完全成功还是失败，从而确保一致性。
实现分布式一致性有两类架构：
 对称的无主架构（Leader-Less）：所有Server都是对等的，Client可以和任意Server进行交互。
 非对称有主架构（Leader-Based）：任意时刻，有且仅有1台Server拥有决策权，Client仅和
该Leader交互。

22. 实现分布式一致性有两类技术：
 基于协议广播（Agreement-Based）；
 基于仲裁协调（Quorum-Based）：在没有并发写冲突时，性能更优。
在具体实践中，考虑系统性能和延迟，通常结合上面两种架构和技术来实现：
 在准备阶段，为对称架构，通过广播方式完成投票并选定Leader。
 在提交阶段，非对称架构，通过Leander完成分布式事务的最后提交。
常见的分布式一致性算法有：
 2PC算法（Two Phase Commit protocol），分准备阶段和提交阶段。以阻塞方式完成，性能差；
无容错机制，无法处理协调者宕机问题。
 3PC算法（Three Phase Commit protocol）。在2PC基础上引入超时机制，将准备阶段分解为两
个阶段：在超时发生以前，系统处于不确定阶段；在超时发生以后，系统则转入确定阶段。
 Paxos算法：包括Classic Paxos（1990/1998），以及Fast Paxos（2005）等改进方案。基于分布
式选举原理，具有高度容错特性，且唯一被证明的一种一致性算法。
 Raft算法：基于复制状态机的原理，将问题分解为选主算法，日志复制，安全性等子问题，
更容易理解和实现。
几种一致性方案的初步比较如下：
方案/算法备份主/从主/主2PC 3PC Paxos Raft
一致性弱一致性最终一致性强一致性
事务无全本地完全事务性
延迟低低低高高高低
性能高高高低低+ 中高
数据丢失大量少量少量无无无无
失败转移无读读&写读&写读&写读&写读&写
复杂性低低低中中高中
4.3.5.2.案例1：支付宝
4.3.5.3.案例2：财付通
4.3.6. 数据库复制工具
4.3.6.1.数据库复制技术概述（联动）
为了实现Share-Nothing架构的高可用关系型数据库集群，在引入数据库访问层（DAL）、分布式事

23. 务协调器（DTC）的同时，还需要一个重要的技术组件——数据库复制工具（Database-Replicator），
来将单一数据库的数据内容，复制到备份数据库或从属数据库上，增加数据冗余，提高数据可靠型和
系统可用性。
按数据库复制机制分类，可分为：
 同步复制方式：复制时需要等待目标库的应答，实现最大保护，但性能较低。
 异步复制方式：复制时无需等待目标库的应答，实现最大性能，但数据可能不一致。
 混合复制方式（半同步）：在“最高性能”和“最大保护”中权衡。当同步复制超时或失败时，自
动转为异步复制，确保复制的“最大可用性”。其缺点是，在网络连接中断后，主库又发生故障，
此时会导致数据丢失，造成备库数据不一致！
按数据源和目标库的个数，可分为：
 一对一复制：数据源为单一数据库，目标也是单一数据库。
 一对多复制：数据源为单一数据库，目标为多个数据库。
 多对多复制：数据源有多个数据库，目标为多个数据库。
按数据库类型不同，可分为：
 同类库复制：如从DB2复制到DB2数据库。
 同构库复制：如从DB2复制到MySql数据库。
 异构库复制：如从DB2复制到NoSql数据库。
按复制工具的实现架构，可分为：
 集中式复制模式：单一模块部署在源端，通过远程接口写入目标端。一般为一对一模式。
 客户/服务器模式：源端部署“服务器”，多个目标端部署“客户端”。一般为一对多模式。
 发布/订阅模式：多个源端部署“生产者”，多个目标端部署“消费者”。支持多对多模式。
4.3.6.2.案例：联动优势DB2复制工具（联动）
1. 需求及问题
将联动的DB2在线交易库复制到DB2离线数据库，将DB2离线数据库复制并归档到MySql读库集
群，用于完成一些统计查询，以及一些大范围历史数据的查询处理。
公司已购的商业复制工具IBM-CDC价格不菲，操作不便，不支持复制到MySql中，经常因数据库
结构变更等原因导致复制中止，其可用性不可控。
基于以上原因，公司开发了DBRep复制工具。

24. 2.设计思路及架构说明
联动的DBRep复制工具，采用客服/服务器模式，实现了异构数据库的异步复制。
3.实施效果：
联动的DBRep复制工具，已完成如下特性：
 支持DB2到DB2和DB2到MySql的复制，并可扩展复制到MongoDB数据库。
 支持一对多库的复制；
 支持表名过滤和映射（单表对多表，多表对单表）；
 支持字段过滤和映射；
 其关键技术已获发明专利授权（200910241240.X数据同步方法及装置）。
目前已经用于联动优势话费读库、第三方支付读库、用户管理等多个系统中。
4.3.6.3.案例：支付宝
4.3.6.4.案例：财付通
5. 支付清算行业信息技术发展展望（中行）