SlideShare une entreprise Scribd logo
1  sur  50
数据访问层DAL架构和实践(7)技术交流 
技术规划中心软件组& 工行软件开发中心北京研发部 
Version 7.1.20140425 
刘胜liusheng@umpay.com 
联动优势B办公区 
北京市西城区安德路甲104号证通商务楼F5层(100120)
2 
0*历史版本 
 关于DAL的历史版本 
 20091224数据访问层DAL概念和实践1(刘胜).ppt 【概念/设计/原型】 
 20100330数据访问层DAL概念和实践2(刘胜).ppt 【实现/统一/远景】 
 20100902数据访问层DAL架构和实践3(刘胜).ppt 【接口/本地/模板】 
 专利201010506543.2 数据访问方法及装置 
 20120613数据访问层DAL架构和实践4(刘胜)新的特性.pptx 
 20130626数据访问层DAL架构和实践5(刘胜)数据分片.pptx 
 20131030数据访问层DAL架构和实践6(殷舒)SQL解析.ppt 
 20140116技术开发小组沟通会6(刘胜)论Jdbc4dal可行性和用户信息收集.pptx 
 20140326数据访问层DAL架构和实践7(刘胜)技术交流.pptx 
 最近培训材料 
 20120613数据访问层DAL架构和实践4新的特性(刘胜).pptx 
 20121012联动优势技术大会(刘胜)三年技术规划v1.3.4.pptx 
 20121208联动优势2012年度述职报告(刘胜)1206正式版.pptx 
 20130325理解REST设计模式和反模式(刘胜)草案.pptx 
 20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx 
 20130604代码质量和单元测试(刘胜).pptx 
 20130604联动优势企业架构介绍(刘胜).pptx
3 
1 数据库集群访问中间层技术需求 
1. 需求分析(数据库集群访问中间层) 
 需求理念和原则 
 原始需求 
 需求分析 
 需求细节 
2. 现有DAL中间层技术介绍 
3. 技术可行性分析(Jdbc4udal方案)
4 
1.0*需求原则:FQC原则引入(图) 
分布式系统CAP定律 
(Eric A. Brewer 2000) 
——————————— 
Consistency 一致性 
Availability 可用性 
Partition tolerance 分布性 
需求分析的FQC原则 
(刘胜2014) 
———————————— 
Functional Features 功能需求 
Quality 质量需求 
Cost reduction 成本需求 
Pick Two ! 
Cost reduction
5 
1.0*需求原则:FQC原则解释(图) 
 分布系统CAP定律(2000 Brewer's theorem) 
 分布式系统最多只能满足CAP三项中的两项。 
FQC != Final Quality Control 
 需求分析FQC原则(2014 刘胜) 
 Functional Features 
 Quality 
特性需求:功能性 
质量需求:非功能性 
 健壮性,高可用性,可读性、易维护、易扩展、… 
 Cost reduction 
 降低资金成本 
 降低硬件成本 
 降低人力成本 
 降低时间成本 
Pick Two ! 
Partition tolerance 
Pick Two ! 
Cost reduction 
质量决定后期成本(隐式成本) 
成本决定前期成本(显式成本) 
TCO 
在某些场景,不同成本可以转化,但转化损耗较高! 
例如?——1)一个妈妈怀胎十月生宝宝;2)…
6 
1.1*原始需求:描述 
 解决问题: 
 当传统Web应用面对高并发数据访问需求时,原底层单数据库设 
计难以有效支撑上层应用的数据访问,因此需要对数据库采用读 
写分离或分库/分表等手段实施多库拆分,以便整体提高应用的高 
可用性。 
 设计思路: 
 参照上述策略对原单数据库完成水平扩展后,就上层应用访问而 
言,势必出现如SQL动态解析、多库路由读写访问、跨库事务一 
致性、跨库查询结果数据合并/排序等问题,所以考虑引入数据访 
问层DAL(数据库驱动层之上,应用DAO层/ORM框架层之下)以 
便透明解决上述难题。 
 合作方式: 
 请帮忙了解贵公司目前是否存在该架构?如存在是否已形成产品 
可直接对外出售?如不存在是否有意根据我行需求以单独承包/合 
作开发的方式对该架构进行落地研发?
7 
1.1*原始需求:分析 
 需求特性: 
 1,多库路由读写访问【DONE:有两种策略】 
 2,跨库查询结果数据合并/排序【DONE:避免大结果集】 
 3,SQL动态解析【TODO:Jdbc4udal方案】 
 4,跨库事务一致性【UNDO:分布式事务】 
 设计思路: 
 数据库驱动层之上【Not Only JDBC】 
 应用DAO层/ORM框架层之下【YES/NO】 
 “透明” 【NOT ALL】 
 客户端透明地使用“RDB数据库” 【DONE:RDB,NOSQL,Anything】 
 客户端透明地使用全部功能特性【~缺陷透明,CAP原理】 
 客户端透明地使用DAL中间层【限定JDBC+SQL】 
 客户端透明地访问分片数据【DONE】 
Pick Two ! 
Partition tolerance
8 
1.2 需求分析:不同的读写场景(图) 
 全库读写混合 
 根据读写比分类 
 高可写:主主模式 
 高可读:主从模式,读写分离 
 实现方式(读写分离) 
 读写使用不同VIP,动态DNS 
 定制客户端API 
 通过DAL服务器 
 分库只读 
 实现方式(分片路由) 
 定制客户端API路由 
 使用DAL服务器路由 
 分库读写混合 
 实现方式(CAP原理) 
 降低A(系统可用性) 
 降低C(事务一致性) 
DAL 
代理?
10 
1.2*需求分析:不同层次的方案(图) 
数据访问对象(DAO) 
读写混合操作只读操作只写操作 
ORM框架(iBatis, Hibernate, …) 
自定义JDBC Driver 
( Udal-Jdbc) 
自定义Udal-Client 
(本地| 远程) 
HTTP或 
CM20 
DaaS 中间层(Udal-Server) 
JDBC (MySql) 
RDS 中间层(Amoeba, 
Cobar, DRDS, Atlas, … ) 
关系型数据库(MySql/DB2/Oracle/…) 
NoSQL 
Tuxedo等 
自定义 
DataSource 
(Tddl, Zdal) 
业 
务 
层 
中 
间 
层 
数 
据 
层 
JDBC (MySql/Db2/Oracle) 
2 
4 
1 3 4
11 
1.2+需求分析:不同模式中间层(图) 
RDS 
中国主流国际主流 
(Relational Database Service) 
————————————— 
MySql-Proxy@MySQL 
Atlas@Qihoo360 
Amoeba,Cobar@Alibaba 
TDDL@Alibaba 
RDS & DRDS@Alibaba 
DDB@网易杭研院 
DDBS@百度 
云数据库@腾讯 
RDS@Amazon 
AzureSQL@MS 
CloudSQL@Google 
DBaaS & DaaS 
(Database as a Service) 
——————————— 
JPA@SUN 
S3@Amazon 
DynamoDB@Amazon 
SimpleDB@Amazon 
CloudDataStore@Google 
BigTable & Spanner@Google 
Azure(Tables/Blobs/Queues)@MS 
DAL@iMobile 
… 
UDAL@UMPAY
13 
1.2*需求分析:不同机房的方案(图) 
Zone #A Zone #B 
1.跨机房负载均衡 
DalServer#A1 DalServer#A2 
MySql 
#A集群 
负载均衡器#A 
(如LVS/HaProxy) 
DB2 
#A集群 
Oracle 
#A集群 
DalServer#B1 DalServer#B2 
MySql 
#B集群 
DB2 
#B集群 
Oracle 
#B集群 
服务查找器#A 
(如DNS) 
负载均衡器#B 
(如LVS/HaProxy) 
服务查找器#B 
(如DNS) 
网络协议(HTTP、TCP等) 
存储接口(JDBC等) 
MongoDB 
#A集群 
… 
业务线应用系统 
双向复制 
2.跨机房远程服务路由 
3. 跨机房远程数据源 
PS:工行需求。CRM迁移案例。
14 
1.3 需求细节1 多库路由读写访问 
 读写分离后的访问路由【无分片,都是全库】 
 应用端区分【读写库不同域名,动态DNS】 
 服务端区分【SQL解析】 
 数据分片后的访问路由 
 场景分类 
 单表分片【DONE】 
 多表分片字段一致【DONE】 
 多表分片字段相似【DONE,如日、月、年】 
 多表分片规则不一致【不支持】 
 实现方式 
 根据“SQLID”路由【DONE 推荐方式】 
 根据“表名+字段值”路由【TODO 暂不支持】
15 
1.3 需求细节2 跨库查询结果集合并/排序 
 合并 
 小数据集合并【支持】 
 大数据集合并【有限制】 
 排序 
 单一字段排序【支持】 
 多个字段排序【可扩展】 
 其他 
 分页【支持】 
 分组(Group by) 【需扩展】
16 
1.3 需求细节3 解析SQL语句 
 从使用者角度 
 是否必须知道数据的存储方式? 【RDB,NOSQL】 
 是否必须知道数据库的厂商和版本? 【不同JDBC驱动】 
 是否必须知道数据库的表结构? 【SQL】 
 是否必须经过ORM? 
 从开发者角度(JDBC) 
 已有驱动vs. 定制驱动vs. 抛弃JDBC? 
 从性能的角度(透明方式) 
 DAO 【函数名+参数】 
 iBatis 【拼装为SQL语句】 
 JDBC 【构造网络报文】 
 *DAL/Codec 【解析网络报文】 
 *DAL/SqlParser 
 DAL/SqlRouter 
 DAL/SqlExecutor 
 DAL/ResultMerge【合并和排序】 
1 
2 
3 
4 
5
17 
这个世界上只有一种一致性算法,那就是 
Paxos,其它的算法都是残次品(包括 
2PC和3PC等)——Google Chubby作者 
Mike Burrows 
1.3*需求细节4 分布式事务… 
 解决方案: 
 Classic Paxos(1990/1998)和Fast Paxos(2005) 
 二阶段提交(2PC) 【可靠但太重,JTA+支持XAResource的Jdbc驱动】 
 三阶段提交(3PC) 【询问时并不锁定资源,除非所有人都同意后才锁】 
 重试机制【不可靠】 
 异常恢复补偿【应用端】 
 容错理论 
 CAP理论 
 NWR模型【Amazon Dynamo,W+R>N】 
 一致性模型【弱一致性、最终一致性、强一致性】 
 拜占庭将军问题:BFT(Byzantine-Fault-Tolerance)Approach 
 agreement-based【replica广播】 
 quorum-based 【client协调】无并发写冲突时更优
18 
1.3 需求细节5 多表关联(JOIN) 
 跨库多表关联/JOIN 【不支持】 
 同库多表关联/JOIN 【尽量支持】 
 单表分片 
 多表分片字段一致 
 多表分片字段相似【如:日、月、年】 
 多表分片规则不一致【不支持】
19 
2 现有DAL中间层技术介绍 
1. 需求分析(数据库集群访问中间层) 
2. 现有DAL中间层技术介绍 
 概念 
 需求: 
 背景:已有技术 
 现状:UDAL 
3. 技术可行性分析(Jdbc4udal方案)
20 
2.0 概念:数据访问层DAL 
 数据访问层DAL 
 Data Access Layer(Layer=Services) 
 DAL是一系列服务的集合,是DAO的自然延伸,是 
SOA的具体实现。 
 部署DAL的好处 
 简化客户端接口,规范数据访问操作 
 保持客户端接口,动态升级服务端实现 
 支持更多客户端:Java/C/PHP/… 
 共享数据库连接,减少总数据连接数 
 更细粒度访问控制 
 方便实施服务治理:权限/管理/监控/分析/优化/… 
 方便实施数据库的迁移/升级/重构/… 
 方便实施读写分离,支持高并发访问 
 方便实施数据分片,支持海量数据库 
 。。。
21 
2.0 概念:What and Why 
 概念:数据访问层DAL 【Layer=Services】 
 【维基百科】A Data Access Layer (DAL) is a layer of a computer program which provides simplified 
access to data stored in persistent storage of some kind, such as an entity-relational database. This data 
access layer is used in turn by other program modules to access and manipulate the data within the data 
store without having to deal with the complexities inherent in this access. 
 DAL是一系列服务的集合,是DAO在大型系统中的自然延伸,是SOA的具体实现。 
 好处: 
 简化客户端接口,规范数据操作【透明性分片】 
 保持客户端接口,动态升级服务端实现【SOA】 
 支持对巨量数据的访问【缓存;读写分离;分片(分库/分表)】 
 服务的治理【认证/管理/权限/监控/分析/优化/…】 
 功能需求: 
 访问代理【Proxy】 
 读写分离【RAIDb-1镜像,每个库都是全库。写库是单点】 
 数据分片【RAIDb-0分区,每个库都是子库。】 
 高可用性【支持Quorum-NWR模型——多个写库】 
 特性需求: 
 平台中立【DAL服务器,可部署在多种平台上】 
 语言中立【DAL客户端,支持Java、C/C++、PHP、Flex等多种语言。】 
 数据库中立【1)多种数据库类型;2)多个数据库版本?】 
 资源共享【1) 共享DataSource连接池; 2)共享Cache。】 
 访问日志【1)提供SqlLog可用于性能瓶颈分析;2)提供BackLog可用于数据恢复。】 
 访问控制【1)用户认证;2)连接管理;3)权限控制。】 
 读写分离【FullDB】 
 数据分片【分表,分库】 
 访问集群【负载均衡:HA-Proxy、JGroup】
22 
2.0 概念:高可用数据存储架构(问) 
 Share-Anything架构 
 案例:Oracle RAC共享缓存和存储 
 缺点:扩展能力有限(<10) 
 Share-Storage主备架构 
 案例:DB2双机主备方案 
 缺点:存储是单点 
 Share-Nothing分区架构 
 案例:DB2v9分区方案 
 缺点:管理节点是单点? 
 Share-Nothing主从架构(问:区别?) 
 案例:MySQL主从单向复制 
 缺点:写库是单点,也是瓶颈 
 Share-Nothing主主架构 
 案例:MySQL主从双向复制 
 缺点:未读写分离 
 Share-Nothing双主多从 
 优点:写库非单点,第一写库可停机 
 缺点:写库是瓶颈,第二写库不能停机 
DAL 
代理?
23 
2.1 需求:核心库减负(简) 
 问题1:核心数据库不堪重负(201106) 
 数据量大 
 用户表:tuser + tuserBank 
 交易表:transAll  七天翻滚表 
 数据冗余 
要么分区,要么分片。 
分区成本高,依赖厂商技术。 
分片阻力大,应用端改动多。 
 数据表多个版本混存,每个用户记录两次,每条交易记录两次。【双写】 
 个别应用过度依赖于TransAll表,未做日表翻滚。【分片】 
 系统迁移不彻底,有残留数据。(用户管理系统:望京丰台) 【多查】 
 读写不均【读写分离】 
 淘宝读写比测算:10:1(来自iDataForum) 
 联动读写比估算:用户表(20:1),交易表(2:1) 
 连接池问题: 【连接共享】 
 应用太多太分散,容易使数据库连接总数超限,导致DB中断 
 问题2:针对复杂的数据库部署,应用开发困难 
 同时连多个数据库 
对于简单分片, 
也能凑活实现。 
 依次查多个数据库表:丰台-望京;七天翻滚表;在线-离线库
24 
2.1 需求:核心库减负(分片) 
 最终目的:替核心数据库减负,同时降低开发难度 
 数据冗余:根据读写操作,使用不同的库。【Full-DB】 
 横向拆分:根据应用拆分多个库。【ShardDB】 
 纵向拆分:根据数据拆分多个库和多个表。【ShardDB】 
 需求细分: 【 实际场景千变万化] 
 后端访问方式: 【暂不考虑NOSQL存储】 
 基于JDBC的访问【普通SQL/预编译SQL/存储过程】 
 数据分片策略: 
 按读写操作的类型【读写分离】 
 按分片数据库库名【相同库相同表,相同库不同表】 
 按分片数据库表名【不同库相同表,不同库不同表】 
 按单个分片字段的类型【整数ID值,字符串DT时间】 
 按单个分片字段值个数 
 没有分片字段值(全局) 【全局查询】 
 单个分片字段值(单条) 【单表查询】 
 两个分片字段值(范围) 【多表查询】 
如何 
以不变应万变 
 按多个分片字段值分片,通过计算产生单一分片关键字【如hash】 
?
26 
2.2 背景:已有中间层技术方案(C+x) 
方案1:Mysql-Proxy@MySQL(官方) 
•特点:官方提供,可通过lua脚本扩展 
•功能:负载平衡/读写分离/failover等,不支持大数据量的分库分表,性能较差。 
•源码:http://dev.mysql.com/downloads/mysql-proxy/ 
•参考:https://github.com/drmingdrmer/mysql-proxy-xp/blob/master/lib/rw-splitting. 
lua 
•参考:http://bbs.chinaunix.net/thread-1341765-1-1.html 再提mysql-proxy读写 
分离脚本(rw-splitting.lua)BUG问题 
方案2:Atlas@Qihoo360(王超) 
•源码:https://github.com/Qihoo360/Atlas 
•特点:在mysql-proxy-0.8.2版基础上优化,增加若干新特性。 
•功能:1.读写分离;2.从库负载均衡;3.IP过滤;4.自动分表;5.DBA可平滑上 
下线DB;6.自动摘除宕机的DB; 
•优势: 
• 1.将主流程中所有Lua代码用C重写,Lua仅用于管理接口 
• 2.重写网络模型、线程模型 
• 3.实现了真正意义上的连接池 
• 4.优化了锁机制,性能提高数十倍
27 
2.2*背景:已有中间层技术方案(Java) 
方案3:Amoeba@盛大(陈思儒) 
• 源码:http://sourceforge.net/projects/amoeba/ 
• 文档:http://docs.hexnova.com/amoeba/ 
• 版本:Amoeba for MySQL/Aladdin/MongoDB 
• 缺点:不支持事务/存储过程/输出大数据量结果集/分库分表。目前 
只做到分DB实例,每个节点需要保持库表结构一致。 
方案4:Cobar@AliBaBa(贺贤懋) 
• 源码:http://code.alibabatech.com/wiki/display/cobar/Home 
• 缺点:基于amoeba0.34,开源版只支持mysql,不支持读写分离。 
方案5:TDDL@Taobao 
• 源码:https://github.com/alibaba/tb_tddl 
• 特点:基于JDBC数据源,具主备/读写分离/动态数据库配置等功能。 
• TGroupDataSource & TAtomDataSource 
• 缺点:复杂度相对较高,文档较少,只开源动态数据源,分表分库部 
分还未开源,还需要依赖diamond,不推荐使用。 
方案6: RDS@阿里云(皓庭/王骞) 
• DTCC#2013:阿里云分布式RDS平台(柳彦召) 
• DTCC#2014:淘宝数据库高性能透明分库分表探索(皓庭)DRDS
28 
2.2+背景:已有中间层技术方案(DDB) 
DDB@网易 
王磊@网易杭研院
29 
2.2 背景:已有中间层技术方案(不开源) 
方案7:S3@Amazon & SimpleDB@Amazon 
• 特点:非开源。(S3)基于标准REST和SOAP接口的超级SAN存储。 
方案8:DAL@iMobile(许超前@百度) 
• 特点:非开源。针对PHP页面访问MySQL库。 
• 参考: http://cio.it168.com/a2010/0421/876/000000876821.shtml 
• 优势: 
• 1) 不但具备了memcached和mysql proxy的优点,还避免了两者的缺点。 
• 2) Dal作为一个中间件,应保持语言中立、数据库中立。 
• 3) 让系统在数据访问层上具备分布式计算能力。 
• 4) 不造ORM轮子,只是发明访问数据的接口。
30 
2.3*背景:解析中间层架构(Java) 
1 
2 
3 
4 
5 
 模块组成 
 网络:JDBC协议解析(MySQL) 
 解析:{SqlParser | Cobar} 
 路由:基于{表名+字段值| SQLID} 
 执行:{SQL | PSQL | CALL} 
 结果集合并& 排序 
 访问方式 
 方案1:SQL/JDBC 
 使用MySql的JDBC驱动,使用ORM方式不变 
 方案2:SQLID/自定义协议(CM20|HTTP) 
 使用自定义通信协议,限制前端接口。
31 
2.4 现状:UDAL介绍 
 名称:联动优势数据访问层UDAL 
 结构 
 UDAL服务器【从产品到平台】 
 UDAL通用接口协议【HTTP | CM20】 
 UDAL客户端接口(for Java) 
 RmoteAPI 【可自定义】 
 LocalAPI 【~iBatis】 
 PoGenerator组件【~】 
 生成PO对象 
 生成SQL模板 
 生成SQL分页模板 
 BS3相关:IoC容器,Dalet扩展
32 
2.4 现状:UDAL演化路线(第5阶段) 
 第一阶段目标:访问代理 
 平台中立【DAL服务端,基于Java开发,可部署在多个平台上】 
 语言中立【DAL客户端,支持多种语言访问(JAVA/PHP/C/Ruby/…)】 
 厂商中立【支持多个DB厂商;支持多个DB版本;支持NOSQL存储;】 
 第二阶段目标:服务治理 
 资源共享【多种连接池,共享连接池;共享缓存(MCached/EhCached)】 
 权限控制【身份认证,连接管理,访问控制】 
 访问日志【业务日志,SqlLog,BackLog】 
 监控优化【性能瓶颈分析和优化】 
 第三阶段目标:读写分离 
 读写分离【主从结构,需要额外的DB复制技术】 
 访问集群【负载均衡:HaProxy】 
 第四阶段目标:非结构化存储【针对RO/CO/KV/DO的访问】 
 参考:三备份/NWR模型/多版本/… 【无需额外的复制,使用NWR模型】 
 支持:Mcache/MongoDB/… 
 支持:MCache高可用模式【永远可写,永远可读】 
 第五阶段目标:数据分片 
 多种执行方式:普通SQL,预编译SQL,存储过程。 
 多种分片策略:单列|多列,无值|单值|多值,多库&多表 
 多种扩展方式:Java类扩展,脚本语言扩展。
33 
2.4 现状:UDAL关键技术的选择(简) 
 1,服务组织风格【RESTful】 
 2,中间层编程语言【Java vs C/C++】 
 3,后端存储方式【NO-RDB】 
 4,前端访问接口【NO-JDBC,NO-SQL】 
 NO-SQL 【用sqlid/callid替代sql语句】 
 抛弃复杂的sql语句,解析更容易,执行更安全。 
 NO-JDBC 【可支持NOSQL存储】 
 抛弃复杂的jdbc,服务端更容易解析 
 抛弃复杂的jdbc,客户端更容易使用 
 还可支持更多的存储方式:1)NOSQL库;2)服务(如Tuxedo) 
 5,交互协议(传输协议+数据协议) 
 数据传输协议【HTTP/CM20/…】 
 序列化技术【java+gz/hessian2+gz/xml/json/…】 
 结果集表示【List<Map<String,Object>>】 
 6,负载均衡: 【避免单点】 
NO=Not Only
34 
2.4 现状:UDAL软件产品(简) 
1 应用逻辑层2 数据访问层(DAL) 
1 应用系统 
21 NIO网络 
协议适配器 
22 Dalet引 
擎 
211 消息头 
解析器 
212 消息体 
解析器 
221 资源 
分发器 
222 操作 
映射器 
23 Dalet容器 
● Dalet1 
● Dalet2 
… 
http 
11表现层 
12逻辑层 
13持久层 
11表现层 
12逻辑层 
13持久层 
http 
Method+URI 
3 数据资源层 
2 数据访问服务(1) 
1应用系统 
2 数据访问服务(2) 
21 22 23 
HTTP或CM20 
JDBC 
Cache Hadoop 
Call 
DB2 MySQL Search 
APIs 
APIs 
专利201010506543.2数据访问方法及装置
35 
2.4 现状:UDAL服务平台(简) 
 服务平台= LBL + DAL + IoC + API 
DAL Remote API 连接池管理序列化和压缩… HTTP 客户端序列化 
BSL基础服务平台 
Mina2框架 
IoService 
过 
滤 
器 
链 
DB2 
BS3框架 
—— 
IoC 
AOP 
JMX 
Log 
REST 
AUTH 
FSM 
XUMP 
… 
Oracle 
Mysql 
过滤器 
IoHandler 
DAL服务器 
NIO协议解析器 
http/cm20/um32/… 
数据访问引擎 
DalEngine 
Dalet扩展 
—— 
Auth 
PSqlid 
MCache 
MCacheAW 
MCacheNWR 
… 
序列化和压缩 
java/hessian/json/…/gz 
DB连接池管理 
c3p0/dbcp/bonecp/… 
线程池 
协议解析器 
… 
DAL Local API 
DalEngine Dalets 
… 
DB连接池管理 
中间件 
—— 
Tuxedo 
CICS
36 
2.4 现状:UDAL全局地位(简) 
负载均衡层 
CDN 区域负载 
(可选) 
F5/LVS 
+Nginx/ 
Haproxy 
Web前置集群综合前置FSL 
异 
步 
订阅 
同 
步 
服务层缓存层持久层 
综合前置 
FSL 
通知和反馈SMS,Email,IM,… 
Memcached 
+ Membase 
二级缓存 
应用切分 
水平切分 
垂直切分 
读写分离 
双主多从 
F5/LVS 
+Nginx/ 
Haproxy 
主备机制 
JMS 
Camel 
通过DAL访问 
NOSQL 
DB 
Hadoop / HBase 
… 
NameNode2 
复制 
Master DB 
(行式)在线交易库 
Master / Slave,分片,集群 
DataNodes 
同NameNode1 
步 
 
异 
步 
页面缓存 
Squid 
Varnish 
OSCache 
静态资源 
合作机构 
银行 
移动 
商户 
分布式服务集群 
应用服务:ASL 
基础服务:BSL 
数据访问:DAL 
监控服务定时服务:TSL 
集群 
… 
读 
(列式)离线分析库 
写 
读… 
复 
制 
Slave DB
37 
3 论Jdbc4udal方案的技术可行性 
1. 需求分析(数据库集群访问中间层) 
2. 现有DAL中间层技术介绍 
3. 技术可行性分析(Jdbc4udal方案) 
 问题 
 分析 
 对比 
 结论(?)
38 
3.1*问题:使用UDAL并兼任现有开发模式 
 服务端问题:给核心数据库减负 
 数据库需要重构:纵向拆分|横向分片|版本升级|MyQql|… 
 应用端改动太多 
 需要一个中间层 
 引入UDAL服务层 
 客户端问题: 
  应用端改动太大 
问:怎样使用UDAL并能兼任现有开发模式?
39 
3.2*分析:访问UDAL服务的几种方式 
 方案1:直接调用BS3中API接口 
 DalApi4Inf api = 
DalClientFactory.newRemoteApi 
(…); 
 方案2:自定义封装协议接口( 
CM20|HTTP) 
 例:Php4Dal 
 方案3:封装Jdbc4udal驱动 
 服务端:提供固定服务地址,解 
析动态SQL来实现分片。 
 客户端:已有应用系统不用改动 
,可使用任意ORM框架。 
(读+写)混合操作只读操作只写操作 
iBatis 
DAO 
iBatis+X 
Jdbc4udal 
DAO 
DalApi 
中间层1(Amazon,手机之家 
, DalServer) 
中间层2(Mysql-Proxy, 
Atlas,Amoeba,Cobar, 
TDDL) 
MySQL,DB2,Oracle,… 
NOSQL
40 
3.3*分析:方案Jdbc4udal目标 
1、屏蔽数据库差异,换数据库时应用不需要修改。 
 DB2 改MySQL 【问题:sql编译顺序不一,需要重新优化】 
2、屏蔽分表规则。order_0,1,2改成order_0,1,2,3,4,5,6时,应用不需要修改 
多单表查询:解析表名、字段值(单值,值范围,Between,IN) 
表关联:单表分片,多表分片一致,分片字段类似,多表分片规则不一致。 
 重点:不支持跨库JOIN 
3、平滑迁移 
 限指客户端开发模式的迁移(jdbc->dal),方便回退。 
4、节省数据库连接,不为每个应用分配独立DB连接,各应用公用DB连接。 
 支持 
5、支持横向扩展 
(1)服务端支持集群,能够配置任意数目服务器。 支持:多个DAL服务。 
(2)支持数据库集群,可以实现读库和写库分离。 支持: 
补充:
3.3*分析:方案Jdbc4udal当前问题 
1、如何实现实表向虚表的过渡,实表、虚表是由应用端传送一个标志来区分还 
是由服务器端自行适配? 
41 
 修改iBatis配置中的Table名。【存储过程方式?】 
 必须能从名字上区分(_V_前缀):虚表_V_Schema.Tablename 
2、c3p0连接池在管理改动后的Connection是否存在问题? 
 Connection有效性校验。 
 Commit,Rollback,Close,Open 
3、dal如何支持事务? 
 不支持! 
 同时提交多条SQL到服务端,由服务端按事务执行。 
4、dal需要定制出execute、executeQuery、executeUpdate三类服务; 
 executeQuery = GET URI 【在写库读?——】 
 executeUpdate = PUT URI 【在读库写?——全部更新,插入】 
 多个DataSource(在线库!=写库)【通过URI?db=online区分】 
5、dal对不同数据库特有函数的支持; 
 用sqlparser替代cobar解析SQL,需要验证测试(殷舒) 
6、如何将dal返回的数据转换成jdbc的类型? 
 (冗余操作:Map转JDBC结果集,然后再次转Map或Bean)
42 
3.3*分析:方案Jdbc4udal的优缺点 
 方案3:封装Jdbc4udal驱动 
 技术可行性 
 服务端:提供固定服务地址,解析动态SQL来实现分片。 
 客户端:已有应用系统不用改动,可使用任意ORM框架。 
 技术风险点 
 层次增加: 
 Args -> SQL -> URI -> 解析SQL -> 解析表和字段 
 隐含陷阱: 
 特殊SQL  原有Cobar解析不支持,改sqlparser,需验证 
 大数据集 不支持该模式:用dalet直接生成文件后http下载。 
 多表JOIN  
 多表分片
43 
3.3*分析:解析SQL时的问题 
 可解析部分(MySql) 
 操作语句:insert/delete/update/select 
 条件判断:>,<,=, <>,in,between,join,exists 
 解析不成功: 
 函数 
 解析后误判 
 例1:解析正常,有变形。 
 输入:SELECT * FROM tbl0 WHERE 1=1 limit 10,5 
 输出:SELECT * FROM tbl0 WHERE 1 = 1 LIMIT 5 OFFSET 10 
 输入:SELECT fields INTO tbl2 FROM tbl0 WHERE 1=1 
 输出:SELECT fields FROM tbl0 WHERE 1 = 1 
 例2:解析异常(net.sf.jsqlparser.parser.ParseException) 
 输入:SELECT * FROM products WHERE id='3' FOR UPDATE 
 异常:ParseException: Encountered " "FOR" "for "" at line 1, column 23. 
 输入:SELECT * FROM products LOCK IN SHARE MODE 
 异常:ParseException: Encountered " "IN" "IN "" at line 1, column 29.
44 
3.3+分析:状态性 
 如何保持状态 
 DB中保持 
 前后端连接一致 
 DAL中保持 
 DAL服务器缓存 
 Client端保持 
 客户端缓存,批次提交。
 三种方案的差异 
45 
3.4*对比:方案对比1(刘胜) 
方案JDBC UDAL Jdbc4udal 备注 
状态有状态无状态去状态状态C/S/DB保持 
登录方式独立登录过程无需预先登录独立登录过程 
大结果集支持不支持去大结果集服务端生成文件 
事务支持客户端事务服务端事务? 
参数Sql/psql/call sqlid + args sql 类“存储过程” 
分片无按sqlid 按表名+字段 
客户端ORM RPC ORM/ibatis 
动态sql 由Ibatis支持缺省参数方式由Ibatis支持 
迁移环节APP代码改动多APP容易迁移 
测试环节按APP测试按APP测试 
中间环节少中多
46 
3.4*对比:方案对比2(殷舒) 
对比项服务端配置SQL SQL解析 
支持动态sql 
支持sql语句场景 
支持单库两分片表关联 
网络流量大小 
数据操作事前监控 
数据操作事后监控 
服务端配置分片规则需要需要 
服务端配置sql 需要不需要
47 
3.5 结论(?) 
1. 三种方案的差异
48 
8+问答1(任)现场问题及简要答复 
对方问题: 
1,关于jdbc4udal驱动,希望有产品或明确的开发计划。——答复:暂无计划。也担心 
实现后效果不佳,无法达到预期的“透明”效果。如有强烈需求,也可先做一些探 
索性预研。 
2,希望支持分布式事务,有难度也想要做,可承担一定代价。——答复:本公司无此应 
用场景。如有需要,可自定义dalet扩展,通过JTA实现。 
3,关于跨地域/跨机房的场景。——答复:本公司无此应用场景。如有需要,也可从两个 
层面来支持:1)服务层,可通过负载均衡器或服务查找模式,实现快速动态切换。 
2)远程JDBC数据源:如果是镜像库模式,也可使用LVS负载均衡器、动态DNS等 
方式,实现快速动态切换。【但是,数据复制的延时,由DB复制工具和网络状况决 
定,与DAL层无直接关系。】 
4,合作模式,希望能够采用合作开发的模式。——另行商定。 
我方问题: 
5,具体应用场景(高可读、高可写、读写混合、分库、强一致的分布式事务)——暂不 
明确,可能都需要覆盖。稍后会整理一个详细的需求列表(包含应用场景),需我 
司针对其需求做出明确的答复。
49 
8+问答2(秦)数据备份和灾备 
 1,贵公司在物理部署上是否支持同城多点和异地多点?我看您的ppt里提到 
了丰台与望京,这是北京2个平等的中心吗?丰台、望京是根据什么策略引导 
用户访问的(如访问分配比例、DNS域名动态解析引导等)? 异地多点有无相 
同引导策略? 
 2,是否存在同城(丰台-望京)数据备份、容灾考虑,实际的容灾设计方案是 
什么样子的,RTO,RPO是多少? 异地容灾有无相同策略? 
答复见邮件“关于贵公司数据备份 
,灾备咨询”
50 
8+问答3(任)技术需求概述 
 第2 章应用数据访问需求 
 1.生产数据库服务器均采用PC Server,支持Oracle数据库。 
 2.需要支持数据部署在不同地域的数据中心,跨不同地域数据中心的读写情况,保障异地数据读写的执行效率。 
 3.基于JDBC规范,支持实现JDBC规范的数据源,数据访问对上层应用调用透明,开发整体采用Java语言。 
 4.支持主流ORM框架下的透明分布式数据访问开发,如:iBatis、Hibernate等。 
 5.支持带有权重的读写分离模式。 
 6.数据库读写库的动态切换。 
 7.支持读写次数、并发度控制。 
 8.数据库实例个数发生动态变更时,可以保障旧应用数据不发生迁移,新数据分布于新数据库中。 
 9.支持SQL解析,需要考虑Oracle中的语法。 
 10.数据库路由,数据库路由策略依照应用制定的策略完成;如是否可以跨库联表查询、能否跨库使用聚合函数、可以select 
...for update等。 
 11.数据分页、查询结果数据合并和排序等。 
 12.集中式数据源信息管理和动态变更。 
 13.具备运行情况监控与分析功能。 
 第3 章数据备份及同步需求 
 1.数据库的本地、异地数据同步方案,数据同步需考虑不同表、不同规则的定制,需考虑数据在本异地同步下的延时。 
 2.提供数据在异地IDC的备份策略,发生灾难时数据的恢复策略。 
 3.数据库日常管理过程中,数据维护、迁移和管理的工具。 
 第4 章分布式事务控制需求 
 1.同一数据中心不同数据库间分布式事务控制方案。 
 2.异地数据中心不同数据库间分布式事务控制方案。 
答复见文档『20140418联动优势数据访 
问层DAL架构-技术需求概述(任)_答复( 
刘胜).doc』 
 3.分布式事务控制对上层应用需要尽量避免影响考虑失败情况的应对支持等。
51 
9+参考索引 
 网址 
 http://coolshell.cn/articles/10910.html 分布式系统的事务处理(陈皓 
)2014年1月20日发表 
 其实,2PC/3PC都是分布式一致性算法的残次版本,Google Chubby的作者 
Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算 
法都是残次品。 
 Slideshare.net 
 http://www.slideshare.net/guestf5121c/ss-2334825 手机之家的数 
据访问层实践(许超前) 
 http://www.slideshare.net/xcq/ss-3629618 数据访问层开发实践 
 http://www.slideshare.net/nikeliu/20120613dal4 20120613数据 
访问层DAL架构和实践4(刘胜)新的特性.pptx 
 http://www.slideshare.net/nikeliu/20130626dal51-h 20130626数 
据访问层DAL架构和实践5(刘胜)数据分片.pptx
52 
Q9& 结A语:Q&A 
 现场问题——? 
 1,? 
 2,? 
 3,? 
 4,? 
 5,? 
 思考题—— 
 1,? 
 2,? 
 3,?
53 
9 总结:相关培训 
 20081113大型分布式系统架构技术简介(刘胜)中级.pdf 
 20081211大型软件系统开发综述(刘胜)中级.pdf /.mm/.png 
 20090219网络信息安全和认证技术(刘胜)中级.pdf 
 20090625服务器框架的概念和实践(刘胜)20121204.ppt 
 20090625分布式认证和授权技术(刘胜)初级.ppt 
 20090914系统架构师2009大会归来(刘胜)暨头脑风暴.ppt 
 20091224数据访问层DAL概念和实践1(刘胜).ppt 
 20100326数据访问层DAL概念和实践2(刘胜).ppt 
 20100902数据访问层DAL架构和实践3(刘胜).ppt 
 20101217软件技术大会和JavaOne大会归来(刘胜).ppt 
 20110223高可用可扩展的负载均衡层(卢翔,刘胜).ppt 
 20110801应用监控系统架构实践(刘胜).ppt 
 20120613数据访问层DAL架构和实践4(刘胜).pptx 
 20121012联动优势技术大会(刘胜)三年技术规划v1.3.4.pptx 
 20121013联动技术框架能力发布-BS3&DAL(殷舒).pptx 
 20121218联动优势技术平台介绍(for漫道科技)v5.pptx 
 20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx 
 20130521联动优势企业架构介绍(刘胜).pptx 
 20130325理解REST设计模式和反模式(刘胜)草案.pptx

Contenu connexe

Tendances

Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改yp_fangdong
 
数据访问层开发实践
数据访问层开发实践数据访问层开发实践
数据访问层开发实践xcq
 
Ibm solid db overview v6.3 20090320
Ibm solid db overview v6.3 20090320Ibm solid db overview v6.3 20090320
Ibm solid db overview v6.3 20090320小新 制造
 
深入淺出Node.JS
深入淺出Node.JS深入淺出Node.JS
深入淺出Node.JS國昭 張
 
阿里巴巴运维团队的无状态运维思路
阿里巴巴运维团队的无状态运维思路阿里巴巴运维团队的无状态运维思路
阿里巴巴运维团队的无状态运维思路mysqlops
 
SQL Server效能調校
SQL Server效能調校SQL Server效能調校
SQL Server效能調校國昭 張
 
大规模数据处理
大规模数据处理大规模数据处理
大规模数据处理Kay Yan
 
盛大游戏运维体系
盛大游戏运维体系盛大游戏运维体系
盛大游戏运维体系Ken Liu
 
腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程areyouok
 
腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程topgeek
 
开源应用日志收集系统
开源应用日志收集系统开源应用日志收集系统
开源应用日志收集系统reinhardx
 
賽門鐵克 Storage Foundation 6.0 簡報
賽門鐵克 Storage Foundation 6.0 簡報賽門鐵克 Storage Foundation 6.0 簡報
賽門鐵克 Storage Foundation 6.0 簡報Wales Chen
 
MySQL 高可用方案及成功案例
MySQL 高可用方案及成功案例MySQL 高可用方案及成功案例
MySQL 高可用方案及成功案例郁萍 王
 
我的互联网运维理论与实践
我的互联网运维理论与实践我的互联网运维理论与实践
我的互联网运维理论与实践Leo Zhou
 
開放原始碼 Ch2.4 app - oss - db (ver 1.0)
開放原始碼 Ch2.4   app - oss - db (ver 1.0)開放原始碼 Ch2.4   app - oss - db (ver 1.0)
開放原始碼 Ch2.4 app - oss - db (ver 1.0)My own sweet home!
 
开源+自主开发 - 淘宝软件基础设施构建实践
开源+自主开发  - 淘宝软件基础设施构建实践开源+自主开发  - 淘宝软件基础设施构建实践
开源+自主开发 - 淘宝软件基础设施构建实践Wensong Zhang
 
Taobao数据库这5年
Taobao数据库这5年Taobao数据库这5年
Taobao数据库这5年yp_fangdong
 
Big Data, NoSQL, and MongoDB
Big Data, NoSQL, and MongoDBBig Data, NoSQL, and MongoDB
Big Data, NoSQL, and MongoDBMonster Supreme
 
Team Foundation Server
Team Foundation ServerTeam Foundation Server
Team Foundation Server國昭 張
 

Tendances (20)

Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改
 
数据访问层开发实践
数据访问层开发实践数据访问层开发实践
数据访问层开发实践
 
Ibm solid db overview v6.3 20090320
Ibm solid db overview v6.3 20090320Ibm solid db overview v6.3 20090320
Ibm solid db overview v6.3 20090320
 
深入淺出Node.JS
深入淺出Node.JS深入淺出Node.JS
深入淺出Node.JS
 
阿里巴巴运维团队的无状态运维思路
阿里巴巴运维团队的无状态运维思路阿里巴巴运维团队的无状态运维思路
阿里巴巴运维团队的无状态运维思路
 
Ibm solid db_基础
Ibm solid db_基础Ibm solid db_基础
Ibm solid db_基础
 
SQL Server效能調校
SQL Server效能調校SQL Server效能調校
SQL Server效能調校
 
大规模数据处理
大规模数据处理大规模数据处理
大规模数据处理
 
盛大游戏运维体系
盛大游戏运维体系盛大游戏运维体系
盛大游戏运维体系
 
腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程
 
腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程
 
开源应用日志收集系统
开源应用日志收集系统开源应用日志收集系统
开源应用日志收集系统
 
賽門鐵克 Storage Foundation 6.0 簡報
賽門鐵克 Storage Foundation 6.0 簡報賽門鐵克 Storage Foundation 6.0 簡報
賽門鐵克 Storage Foundation 6.0 簡報
 
MySQL 高可用方案及成功案例
MySQL 高可用方案及成功案例MySQL 高可用方案及成功案例
MySQL 高可用方案及成功案例
 
我的互联网运维理论与实践
我的互联网运维理论与实践我的互联网运维理论与实践
我的互联网运维理论与实践
 
開放原始碼 Ch2.4 app - oss - db (ver 1.0)
開放原始碼 Ch2.4   app - oss - db (ver 1.0)開放原始碼 Ch2.4   app - oss - db (ver 1.0)
開放原始碼 Ch2.4 app - oss - db (ver 1.0)
 
开源+自主开发 - 淘宝软件基础设施构建实践
开源+自主开发  - 淘宝软件基础设施构建实践开源+自主开发  - 淘宝软件基础设施构建实践
开源+自主开发 - 淘宝软件基础设施构建实践
 
Taobao数据库这5年
Taobao数据库这5年Taobao数据库这5年
Taobao数据库这5年
 
Big Data, NoSQL, and MongoDB
Big Data, NoSQL, and MongoDBBig Data, NoSQL, and MongoDB
Big Data, NoSQL, and MongoDB
 
Team Foundation Server
Team Foundation ServerTeam Foundation Server
Team Foundation Server
 

En vedette

20150211支付清算协会分布式架构研究与设计参考 v1.0.0211
20150211支付清算协会分布式架构研究与设计参考 v1.0.021120150211支付清算协会分布式架构研究与设计参考 v1.0.0211
20150211支付清算协会分布式架构研究与设计参考 v1.0.0211liu sheng
 
20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc
20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc
20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.docliu sheng
 
手机之家的数据访问层实践
手机之家的数据访问层实践手机之家的数据访问层实践
手机之家的数据访问层实践guestf5121c
 
20160315内刊投稿(刘胜)区块链研究综述v1.1.0331
20160315内刊投稿(刘胜)区块链研究综述v1.1.033120160315内刊投稿(刘胜)区块链研究综述v1.1.0331
20160315内刊投稿(刘胜)区块链研究综述v1.1.0331liu sheng
 
20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版
20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版
20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版liu sheng
 
20160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.0305
20160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.030520160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.0305
20160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.0305liu sheng
 
20160301内刊投稿(刘胜)区块链应用初探v1.doc
20160301内刊投稿(刘胜)区块链应用初探v1.doc20160301内刊投稿(刘胜)区块链应用初探v1.doc
20160301内刊投稿(刘胜)区块链应用初探v1.docliu sheng
 

En vedette (7)

20150211支付清算协会分布式架构研究与设计参考 v1.0.0211
20150211支付清算协会分布式架构研究与设计参考 v1.0.021120150211支付清算协会分布式架构研究与设计参考 v1.0.0211
20150211支付清算协会分布式架构研究与设计参考 v1.0.0211
 
20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc
20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc
20141204支付清算行业分布式系统架构设计研究报告(草案)联动优势刘胜.doc
 
手机之家的数据访问层实践
手机之家的数据访问层实践手机之家的数据访问层实践
手机之家的数据访问层实践
 
20160315内刊投稿(刘胜)区块链研究综述v1.1.0331
20160315内刊投稿(刘胜)区块链研究综述v1.1.033120160315内刊投稿(刘胜)区块链研究综述v1.1.0331
20160315内刊投稿(刘胜)区块链研究综述v1.1.0331
 
20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版
20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版
20150820支付清算协会分布式架构研究与设计参考 v2.0820正式版
 
20160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.0305
20160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.030520160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.0305
20160230联动技术大讲堂xx(刘胜)区块链应用研究1初探v1.2.0305
 
20160301内刊投稿(刘胜)区块链应用初探v1.doc
20160301内刊投稿(刘胜)区块链应用初探v1.doc20160301内刊投稿(刘胜)区块链应用初探v1.doc
20160301内刊投稿(刘胜)区块链应用初探v1.doc
 

Similaire à 20140326联动优势数据访问层DAL架构和实践7(刘胜)工行交流

王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计YANGL *
 
浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性Xuefeng Zhang
 
Delta Lake Architecture: Delta Lake + Apache Spark Structured Streaming
Delta Lake Architecture: Delta Lake + Apache Spark Structured StreamingDelta Lake Architecture: Delta Lake + Apache Spark Structured Streaming
Delta Lake Architecture: Delta Lake + Apache Spark Structured StreamingXiao Li
 
E tom ngoss规范及siebel系统在电信行业的应用 陈永林
E tom ngoss规范及siebel系统在电信行业的应用 陈永林E tom ngoss规范及siebel系统在电信行业的应用 陈永林
E tom ngoss规范及siebel系统在电信行业的应用 陈永林corlin chen
 
imobile-beta技术沙龙
imobile-beta技术沙龙imobile-beta技术沙龙
imobile-beta技术沙龙posestudio
 
20150528联动技术大讲堂15(刘胜)业务系统上线标准指引
20150528联动技术大讲堂15(刘胜)业务系统上线标准指引20150528联动技术大讲堂15(刘胜)业务系统上线标准指引
20150528联动技术大讲堂15(刘胜)业务系统上线标准指引liu sheng
 
N-layer design & development
N-layer design & developmentN-layer design & development
N-layer design & developmentXuefeng Zhang
 
腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程George Ang
 
20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索
20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索
20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索liu sheng
 
Qcon2013 罗李 - hadoop在阿里
Qcon2013 罗李 - hadoop在阿里Qcon2013 罗李 - hadoop在阿里
Qcon2013 罗李 - hadoop在阿里li luo
 
百度分布式数据实践与进展
百度分布式数据实践与进展百度分布式数据实践与进展
百度分布式数据实践与进展yp_fangdong
 
Build 1 trillion warehouse based on carbon data
Build 1 trillion warehouse based on carbon dataBuild 1 trillion warehouse based on carbon data
Build 1 trillion warehouse based on carbon databoxu42
 
《数据库发展研究报告-解读(2023年)》.pdf
《数据库发展研究报告-解读(2023年)》.pdf《数据库发展研究报告-解读(2023年)》.pdf
《数据库发展研究报告-解读(2023年)》.pdfmarkmind
 
手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享Dahui Feng
 
Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境
Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境
Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境drewz lin
 
05 杨志丰
05 杨志丰05 杨志丰
05 杨志丰锐 张
 
众行业公司系统架构案例介绍
众行业公司系统架构案例介绍众行业公司系统架构案例介绍
众行业公司系统架构案例介绍mysqlops
 
淘宝对象存储与Cdn系统到服务
淘宝对象存储与Cdn系统到服务淘宝对象存储与Cdn系统到服务
淘宝对象存储与Cdn系统到服务drewz lin
 
Taobao图片存储与cdn系统到服务
Taobao图片存储与cdn系统到服务Taobao图片存储与cdn系统到服务
Taobao图片存储与cdn系统到服务Wensong Zhang
 

Similaire à 20140326联动优势数据访问层DAL架构和实践7(刘胜)工行交流 (20)

王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计
 
浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性
 
Delta Lake Architecture: Delta Lake + Apache Spark Structured Streaming
Delta Lake Architecture: Delta Lake + Apache Spark Structured StreamingDelta Lake Architecture: Delta Lake + Apache Spark Structured Streaming
Delta Lake Architecture: Delta Lake + Apache Spark Structured Streaming
 
E tom ngoss规范及siebel系统在电信行业的应用 陈永林
E tom ngoss规范及siebel系统在电信行业的应用 陈永林E tom ngoss规范及siebel系统在电信行业的应用 陈永林
E tom ngoss规范及siebel系统在电信行业的应用 陈永林
 
imobile-beta技术沙龙
imobile-beta技术沙龙imobile-beta技术沙龙
imobile-beta技术沙龙
 
20150528联动技术大讲堂15(刘胜)业务系统上线标准指引
20150528联动技术大讲堂15(刘胜)业务系统上线标准指引20150528联动技术大讲堂15(刘胜)业务系统上线标准指引
20150528联动技术大讲堂15(刘胜)业务系统上线标准指引
 
N-layer design & development
N-layer design & developmentN-layer design & development
N-layer design & development
 
腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程腾讯大讲堂24 qq show2.0重构历程
腾讯大讲堂24 qq show2.0重构历程
 
20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索
20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索
20141128(刘胜)UTC2014分布式和云服务的思考与实践——支付清算行业分布式架构的探索
 
Qcon2013 罗李 - hadoop在阿里
Qcon2013 罗李 - hadoop在阿里Qcon2013 罗李 - hadoop在阿里
Qcon2013 罗李 - hadoop在阿里
 
百度分布式数据实践与进展
百度分布式数据实践与进展百度分布式数据实践与进展
百度分布式数据实践与进展
 
Build 1 trillion warehouse based on carbon data
Build 1 trillion warehouse based on carbon dataBuild 1 trillion warehouse based on carbon data
Build 1 trillion warehouse based on carbon data
 
《数据库发展研究报告-解读(2023年)》.pdf
《数据库发展研究报告-解读(2023年)》.pdf《数据库发展研究报告-解读(2023年)》.pdf
《数据库发展研究报告-解读(2023年)》.pdf
 
手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享手机之家新系统介绍及架构分享
手机之家新系统介绍及架构分享
 
Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境
Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境
Top100summit 腾讯-周健-服务化与体系化解决大量定制小项目开发困境
 
Hic2011
Hic2011Hic2011
Hic2011
 
05 杨志丰
05 杨志丰05 杨志丰
05 杨志丰
 
众行业公司系统架构案例介绍
众行业公司系统架构案例介绍众行业公司系统架构案例介绍
众行业公司系统架构案例介绍
 
淘宝对象存储与Cdn系统到服务
淘宝对象存储与Cdn系统到服务淘宝对象存储与Cdn系统到服务
淘宝对象存储与Cdn系统到服务
 
Taobao图片存储与cdn系统到服务
Taobao图片存储与cdn系统到服务Taobao图片存储与cdn系统到服务
Taobao图片存储与cdn系统到服务
 

Plus de liu sheng

20151113 uptc(刘胜)联动优势技术之路v6.1112.out
20151113 uptc(刘胜)联动优势技术之路v6.1112.out20151113 uptc(刘胜)联动优势技术之路v6.1112.out
20151113 uptc(刘胜)联动优势技术之路v6.1112.outliu sheng
 
20151021联动技术大讲堂35(刘胜)网络爬虫技术实战
20151021联动技术大讲堂35(刘胜)网络爬虫技术实战20151021联动技术大讲堂35(刘胜)网络爬虫技术实战
20151021联动技术大讲堂35(刘胜)网络爬虫技术实战liu sheng
 
20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out
20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out
20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.outliu sheng
 
20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx
20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx
20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptxliu sheng
 
20141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.1218
20141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.121820141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.1218
20141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.1218liu sheng
 
20140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.3
20140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.320140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.3
20140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.3liu sheng
 

Plus de liu sheng (6)

20151113 uptc(刘胜)联动优势技术之路v6.1112.out
20151113 uptc(刘胜)联动优势技术之路v6.1112.out20151113 uptc(刘胜)联动优势技术之路v6.1112.out
20151113 uptc(刘胜)联动优势技术之路v6.1112.out
 
20151021联动技术大讲堂35(刘胜)网络爬虫技术实战
20151021联动技术大讲堂35(刘胜)网络爬虫技术实战20151021联动技术大讲堂35(刘胜)网络爬虫技术实战
20151021联动技术大讲堂35(刘胜)网络爬虫技术实战
 
20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out
20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out
20150925联动技术大讲堂xx(刘胜)初创企业知识产权保护和专利挖掘实践.out
 
20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx
20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx
20150111专利知识和专利申请实践(刘胜)号码集合和网络认证.84p.pptx
 
20141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.1218
20141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.121820141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.1218
20141212联动优势(刘胜)北京公交一卡通平台架构演进参考.v1.1.1218
 
20140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.3
20140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.320140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.3
20140818内刊投稿(刘胜)技术创新和专利申请.图文版v3.3
 

20140326联动优势数据访问层DAL架构和实践7(刘胜)工行交流

  • 1. 数据访问层DAL架构和实践(7)技术交流 技术规划中心软件组& 工行软件开发中心北京研发部 Version 7.1.20140425 刘胜liusheng@umpay.com 联动优势B办公区 北京市西城区安德路甲104号证通商务楼F5层(100120)
  • 2. 2 0*历史版本  关于DAL的历史版本  20091224数据访问层DAL概念和实践1(刘胜).ppt 【概念/设计/原型】  20100330数据访问层DAL概念和实践2(刘胜).ppt 【实现/统一/远景】  20100902数据访问层DAL架构和实践3(刘胜).ppt 【接口/本地/模板】  专利201010506543.2 数据访问方法及装置  20120613数据访问层DAL架构和实践4(刘胜)新的特性.pptx  20130626数据访问层DAL架构和实践5(刘胜)数据分片.pptx  20131030数据访问层DAL架构和实践6(殷舒)SQL解析.ppt  20140116技术开发小组沟通会6(刘胜)论Jdbc4dal可行性和用户信息收集.pptx  20140326数据访问层DAL架构和实践7(刘胜)技术交流.pptx  最近培训材料  20120613数据访问层DAL架构和实践4新的特性(刘胜).pptx  20121012联动优势技术大会(刘胜)三年技术规划v1.3.4.pptx  20121208联动优势2012年度述职报告(刘胜)1206正式版.pptx  20130325理解REST设计模式和反模式(刘胜)草案.pptx  20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx  20130604代码质量和单元测试(刘胜).pptx  20130604联动优势企业架构介绍(刘胜).pptx
  • 3. 3 1 数据库集群访问中间层技术需求 1. 需求分析(数据库集群访问中间层)  需求理念和原则  原始需求  需求分析  需求细节 2. 现有DAL中间层技术介绍 3. 技术可行性分析(Jdbc4udal方案)
  • 4. 4 1.0*需求原则:FQC原则引入(图) 分布式系统CAP定律 (Eric A. Brewer 2000) ——————————— Consistency 一致性 Availability 可用性 Partition tolerance 分布性 需求分析的FQC原则 (刘胜2014) ———————————— Functional Features 功能需求 Quality 质量需求 Cost reduction 成本需求 Pick Two ! Cost reduction
  • 5. 5 1.0*需求原则:FQC原则解释(图)  分布系统CAP定律(2000 Brewer's theorem)  分布式系统最多只能满足CAP三项中的两项。 FQC != Final Quality Control  需求分析FQC原则(2014 刘胜)  Functional Features  Quality 特性需求:功能性 质量需求:非功能性  健壮性,高可用性,可读性、易维护、易扩展、…  Cost reduction  降低资金成本  降低硬件成本  降低人力成本  降低时间成本 Pick Two ! Partition tolerance Pick Two ! Cost reduction 质量决定后期成本(隐式成本) 成本决定前期成本(显式成本) TCO 在某些场景,不同成本可以转化,但转化损耗较高! 例如?——1)一个妈妈怀胎十月生宝宝;2)…
  • 6. 6 1.1*原始需求:描述  解决问题:  当传统Web应用面对高并发数据访问需求时,原底层单数据库设 计难以有效支撑上层应用的数据访问,因此需要对数据库采用读 写分离或分库/分表等手段实施多库拆分,以便整体提高应用的高 可用性。  设计思路:  参照上述策略对原单数据库完成水平扩展后,就上层应用访问而 言,势必出现如SQL动态解析、多库路由读写访问、跨库事务一 致性、跨库查询结果数据合并/排序等问题,所以考虑引入数据访 问层DAL(数据库驱动层之上,应用DAO层/ORM框架层之下)以 便透明解决上述难题。  合作方式:  请帮忙了解贵公司目前是否存在该架构?如存在是否已形成产品 可直接对外出售?如不存在是否有意根据我行需求以单独承包/合 作开发的方式对该架构进行落地研发?
  • 7. 7 1.1*原始需求:分析  需求特性:  1,多库路由读写访问【DONE:有两种策略】  2,跨库查询结果数据合并/排序【DONE:避免大结果集】  3,SQL动态解析【TODO:Jdbc4udal方案】  4,跨库事务一致性【UNDO:分布式事务】  设计思路:  数据库驱动层之上【Not Only JDBC】  应用DAO层/ORM框架层之下【YES/NO】  “透明” 【NOT ALL】  客户端透明地使用“RDB数据库” 【DONE:RDB,NOSQL,Anything】  客户端透明地使用全部功能特性【~缺陷透明,CAP原理】  客户端透明地使用DAL中间层【限定JDBC+SQL】  客户端透明地访问分片数据【DONE】 Pick Two ! Partition tolerance
  • 8. 8 1.2 需求分析:不同的读写场景(图)  全库读写混合  根据读写比分类  高可写:主主模式  高可读:主从模式,读写分离  实现方式(读写分离)  读写使用不同VIP,动态DNS  定制客户端API  通过DAL服务器  分库只读  实现方式(分片路由)  定制客户端API路由  使用DAL服务器路由  分库读写混合  实现方式(CAP原理)  降低A(系统可用性)  降低C(事务一致性) DAL 代理?
  • 9. 10 1.2*需求分析:不同层次的方案(图) 数据访问对象(DAO) 读写混合操作只读操作只写操作 ORM框架(iBatis, Hibernate, …) 自定义JDBC Driver ( Udal-Jdbc) 自定义Udal-Client (本地| 远程) HTTP或 CM20 DaaS 中间层(Udal-Server) JDBC (MySql) RDS 中间层(Amoeba, Cobar, DRDS, Atlas, … ) 关系型数据库(MySql/DB2/Oracle/…) NoSQL Tuxedo等 自定义 DataSource (Tddl, Zdal) 业 务 层 中 间 层 数 据 层 JDBC (MySql/Db2/Oracle) 2 4 1 3 4
  • 10. 11 1.2+需求分析:不同模式中间层(图) RDS 中国主流国际主流 (Relational Database Service) ————————————— MySql-Proxy@MySQL Atlas@Qihoo360 Amoeba,Cobar@Alibaba TDDL@Alibaba RDS & DRDS@Alibaba DDB@网易杭研院 DDBS@百度 云数据库@腾讯 RDS@Amazon AzureSQL@MS CloudSQL@Google DBaaS & DaaS (Database as a Service) ——————————— JPA@SUN S3@Amazon DynamoDB@Amazon SimpleDB@Amazon CloudDataStore@Google BigTable & Spanner@Google Azure(Tables/Blobs/Queues)@MS DAL@iMobile … UDAL@UMPAY
  • 11. 13 1.2*需求分析:不同机房的方案(图) Zone #A Zone #B 1.跨机房负载均衡 DalServer#A1 DalServer#A2 MySql #A集群 负载均衡器#A (如LVS/HaProxy) DB2 #A集群 Oracle #A集群 DalServer#B1 DalServer#B2 MySql #B集群 DB2 #B集群 Oracle #B集群 服务查找器#A (如DNS) 负载均衡器#B (如LVS/HaProxy) 服务查找器#B (如DNS) 网络协议(HTTP、TCP等) 存储接口(JDBC等) MongoDB #A集群 … 业务线应用系统 双向复制 2.跨机房远程服务路由 3. 跨机房远程数据源 PS:工行需求。CRM迁移案例。
  • 12. 14 1.3 需求细节1 多库路由读写访问  读写分离后的访问路由【无分片,都是全库】  应用端区分【读写库不同域名,动态DNS】  服务端区分【SQL解析】  数据分片后的访问路由  场景分类  单表分片【DONE】  多表分片字段一致【DONE】  多表分片字段相似【DONE,如日、月、年】  多表分片规则不一致【不支持】  实现方式  根据“SQLID”路由【DONE 推荐方式】  根据“表名+字段值”路由【TODO 暂不支持】
  • 13. 15 1.3 需求细节2 跨库查询结果集合并/排序  合并  小数据集合并【支持】  大数据集合并【有限制】  排序  单一字段排序【支持】  多个字段排序【可扩展】  其他  分页【支持】  分组(Group by) 【需扩展】
  • 14. 16 1.3 需求细节3 解析SQL语句  从使用者角度  是否必须知道数据的存储方式? 【RDB,NOSQL】  是否必须知道数据库的厂商和版本? 【不同JDBC驱动】  是否必须知道数据库的表结构? 【SQL】  是否必须经过ORM?  从开发者角度(JDBC)  已有驱动vs. 定制驱动vs. 抛弃JDBC?  从性能的角度(透明方式)  DAO 【函数名+参数】  iBatis 【拼装为SQL语句】  JDBC 【构造网络报文】  *DAL/Codec 【解析网络报文】  *DAL/SqlParser  DAL/SqlRouter  DAL/SqlExecutor  DAL/ResultMerge【合并和排序】 1 2 3 4 5
  • 15. 17 这个世界上只有一种一致性算法,那就是 Paxos,其它的算法都是残次品(包括 2PC和3PC等)——Google Chubby作者 Mike Burrows 1.3*需求细节4 分布式事务…  解决方案:  Classic Paxos(1990/1998)和Fast Paxos(2005)  二阶段提交(2PC) 【可靠但太重,JTA+支持XAResource的Jdbc驱动】  三阶段提交(3PC) 【询问时并不锁定资源,除非所有人都同意后才锁】  重试机制【不可靠】  异常恢复补偿【应用端】  容错理论  CAP理论  NWR模型【Amazon Dynamo,W+R>N】  一致性模型【弱一致性、最终一致性、强一致性】  拜占庭将军问题:BFT(Byzantine-Fault-Tolerance)Approach  agreement-based【replica广播】  quorum-based 【client协调】无并发写冲突时更优
  • 16. 18 1.3 需求细节5 多表关联(JOIN)  跨库多表关联/JOIN 【不支持】  同库多表关联/JOIN 【尽量支持】  单表分片  多表分片字段一致  多表分片字段相似【如:日、月、年】  多表分片规则不一致【不支持】
  • 17. 19 2 现有DAL中间层技术介绍 1. 需求分析(数据库集群访问中间层) 2. 现有DAL中间层技术介绍  概念  需求:  背景:已有技术  现状:UDAL 3. 技术可行性分析(Jdbc4udal方案)
  • 18. 20 2.0 概念:数据访问层DAL  数据访问层DAL  Data Access Layer(Layer=Services)  DAL是一系列服务的集合,是DAO的自然延伸,是 SOA的具体实现。  部署DAL的好处  简化客户端接口,规范数据访问操作  保持客户端接口,动态升级服务端实现  支持更多客户端:Java/C/PHP/…  共享数据库连接,减少总数据连接数  更细粒度访问控制  方便实施服务治理:权限/管理/监控/分析/优化/…  方便实施数据库的迁移/升级/重构/…  方便实施读写分离,支持高并发访问  方便实施数据分片,支持海量数据库  。。。
  • 19. 21 2.0 概念:What and Why  概念:数据访问层DAL 【Layer=Services】  【维基百科】A Data Access Layer (DAL) is a layer of a computer program which provides simplified access to data stored in persistent storage of some kind, such as an entity-relational database. This data access layer is used in turn by other program modules to access and manipulate the data within the data store without having to deal with the complexities inherent in this access.  DAL是一系列服务的集合,是DAO在大型系统中的自然延伸,是SOA的具体实现。  好处:  简化客户端接口,规范数据操作【透明性分片】  保持客户端接口,动态升级服务端实现【SOA】  支持对巨量数据的访问【缓存;读写分离;分片(分库/分表)】  服务的治理【认证/管理/权限/监控/分析/优化/…】  功能需求:  访问代理【Proxy】  读写分离【RAIDb-1镜像,每个库都是全库。写库是单点】  数据分片【RAIDb-0分区,每个库都是子库。】  高可用性【支持Quorum-NWR模型——多个写库】  特性需求:  平台中立【DAL服务器,可部署在多种平台上】  语言中立【DAL客户端,支持Java、C/C++、PHP、Flex等多种语言。】  数据库中立【1)多种数据库类型;2)多个数据库版本?】  资源共享【1) 共享DataSource连接池; 2)共享Cache。】  访问日志【1)提供SqlLog可用于性能瓶颈分析;2)提供BackLog可用于数据恢复。】  访问控制【1)用户认证;2)连接管理;3)权限控制。】  读写分离【FullDB】  数据分片【分表,分库】  访问集群【负载均衡:HA-Proxy、JGroup】
  • 20. 22 2.0 概念:高可用数据存储架构(问)  Share-Anything架构  案例:Oracle RAC共享缓存和存储  缺点:扩展能力有限(<10)  Share-Storage主备架构  案例:DB2双机主备方案  缺点:存储是单点  Share-Nothing分区架构  案例:DB2v9分区方案  缺点:管理节点是单点?  Share-Nothing主从架构(问:区别?)  案例:MySQL主从单向复制  缺点:写库是单点,也是瓶颈  Share-Nothing主主架构  案例:MySQL主从双向复制  缺点:未读写分离  Share-Nothing双主多从  优点:写库非单点,第一写库可停机  缺点:写库是瓶颈,第二写库不能停机 DAL 代理?
  • 21. 23 2.1 需求:核心库减负(简)  问题1:核心数据库不堪重负(201106)  数据量大  用户表:tuser + tuserBank  交易表:transAll  七天翻滚表  数据冗余 要么分区,要么分片。 分区成本高,依赖厂商技术。 分片阻力大,应用端改动多。  数据表多个版本混存,每个用户记录两次,每条交易记录两次。【双写】  个别应用过度依赖于TransAll表,未做日表翻滚。【分片】  系统迁移不彻底,有残留数据。(用户管理系统:望京丰台) 【多查】  读写不均【读写分离】  淘宝读写比测算:10:1(来自iDataForum)  联动读写比估算:用户表(20:1),交易表(2:1)  连接池问题: 【连接共享】  应用太多太分散,容易使数据库连接总数超限,导致DB中断  问题2:针对复杂的数据库部署,应用开发困难  同时连多个数据库 对于简单分片, 也能凑活实现。  依次查多个数据库表:丰台-望京;七天翻滚表;在线-离线库
  • 22. 24 2.1 需求:核心库减负(分片)  最终目的:替核心数据库减负,同时降低开发难度  数据冗余:根据读写操作,使用不同的库。【Full-DB】  横向拆分:根据应用拆分多个库。【ShardDB】  纵向拆分:根据数据拆分多个库和多个表。【ShardDB】  需求细分: 【 实际场景千变万化]  后端访问方式: 【暂不考虑NOSQL存储】  基于JDBC的访问【普通SQL/预编译SQL/存储过程】  数据分片策略:  按读写操作的类型【读写分离】  按分片数据库库名【相同库相同表,相同库不同表】  按分片数据库表名【不同库相同表,不同库不同表】  按单个分片字段的类型【整数ID值,字符串DT时间】  按单个分片字段值个数  没有分片字段值(全局) 【全局查询】  单个分片字段值(单条) 【单表查询】  两个分片字段值(范围) 【多表查询】 如何 以不变应万变  按多个分片字段值分片,通过计算产生单一分片关键字【如hash】 ?
  • 23. 26 2.2 背景:已有中间层技术方案(C+x) 方案1:Mysql-Proxy@MySQL(官方) •特点:官方提供,可通过lua脚本扩展 •功能:负载平衡/读写分离/failover等,不支持大数据量的分库分表,性能较差。 •源码:http://dev.mysql.com/downloads/mysql-proxy/ •参考:https://github.com/drmingdrmer/mysql-proxy-xp/blob/master/lib/rw-splitting. lua •参考:http://bbs.chinaunix.net/thread-1341765-1-1.html 再提mysql-proxy读写 分离脚本(rw-splitting.lua)BUG问题 方案2:Atlas@Qihoo360(王超) •源码:https://github.com/Qihoo360/Atlas •特点:在mysql-proxy-0.8.2版基础上优化,增加若干新特性。 •功能:1.读写分离;2.从库负载均衡;3.IP过滤;4.自动分表;5.DBA可平滑上 下线DB;6.自动摘除宕机的DB; •优势: • 1.将主流程中所有Lua代码用C重写,Lua仅用于管理接口 • 2.重写网络模型、线程模型 • 3.实现了真正意义上的连接池 • 4.优化了锁机制,性能提高数十倍
  • 24. 27 2.2*背景:已有中间层技术方案(Java) 方案3:Amoeba@盛大(陈思儒) • 源码:http://sourceforge.net/projects/amoeba/ • 文档:http://docs.hexnova.com/amoeba/ • 版本:Amoeba for MySQL/Aladdin/MongoDB • 缺点:不支持事务/存储过程/输出大数据量结果集/分库分表。目前 只做到分DB实例,每个节点需要保持库表结构一致。 方案4:Cobar@AliBaBa(贺贤懋) • 源码:http://code.alibabatech.com/wiki/display/cobar/Home • 缺点:基于amoeba0.34,开源版只支持mysql,不支持读写分离。 方案5:TDDL@Taobao • 源码:https://github.com/alibaba/tb_tddl • 特点:基于JDBC数据源,具主备/读写分离/动态数据库配置等功能。 • TGroupDataSource & TAtomDataSource • 缺点:复杂度相对较高,文档较少,只开源动态数据源,分表分库部 分还未开源,还需要依赖diamond,不推荐使用。 方案6: RDS@阿里云(皓庭/王骞) • DTCC#2013:阿里云分布式RDS平台(柳彦召) • DTCC#2014:淘宝数据库高性能透明分库分表探索(皓庭)DRDS
  • 26. 29 2.2 背景:已有中间层技术方案(不开源) 方案7:S3@Amazon & SimpleDB@Amazon • 特点:非开源。(S3)基于标准REST和SOAP接口的超级SAN存储。 方案8:DAL@iMobile(许超前@百度) • 特点:非开源。针对PHP页面访问MySQL库。 • 参考: http://cio.it168.com/a2010/0421/876/000000876821.shtml • 优势: • 1) 不但具备了memcached和mysql proxy的优点,还避免了两者的缺点。 • 2) Dal作为一个中间件,应保持语言中立、数据库中立。 • 3) 让系统在数据访问层上具备分布式计算能力。 • 4) 不造ORM轮子,只是发明访问数据的接口。
  • 27. 30 2.3*背景:解析中间层架构(Java) 1 2 3 4 5  模块组成  网络:JDBC协议解析(MySQL)  解析:{SqlParser | Cobar}  路由:基于{表名+字段值| SQLID}  执行:{SQL | PSQL | CALL}  结果集合并& 排序  访问方式  方案1:SQL/JDBC  使用MySql的JDBC驱动,使用ORM方式不变  方案2:SQLID/自定义协议(CM20|HTTP)  使用自定义通信协议,限制前端接口。
  • 28. 31 2.4 现状:UDAL介绍  名称:联动优势数据访问层UDAL  结构  UDAL服务器【从产品到平台】  UDAL通用接口协议【HTTP | CM20】  UDAL客户端接口(for Java)  RmoteAPI 【可自定义】  LocalAPI 【~iBatis】  PoGenerator组件【~】  生成PO对象  生成SQL模板  生成SQL分页模板  BS3相关:IoC容器,Dalet扩展
  • 29. 32 2.4 现状:UDAL演化路线(第5阶段)  第一阶段目标:访问代理  平台中立【DAL服务端,基于Java开发,可部署在多个平台上】  语言中立【DAL客户端,支持多种语言访问(JAVA/PHP/C/Ruby/…)】  厂商中立【支持多个DB厂商;支持多个DB版本;支持NOSQL存储;】  第二阶段目标:服务治理  资源共享【多种连接池,共享连接池;共享缓存(MCached/EhCached)】  权限控制【身份认证,连接管理,访问控制】  访问日志【业务日志,SqlLog,BackLog】  监控优化【性能瓶颈分析和优化】  第三阶段目标:读写分离  读写分离【主从结构,需要额外的DB复制技术】  访问集群【负载均衡:HaProxy】  第四阶段目标:非结构化存储【针对RO/CO/KV/DO的访问】  参考:三备份/NWR模型/多版本/… 【无需额外的复制,使用NWR模型】  支持:Mcache/MongoDB/…  支持:MCache高可用模式【永远可写,永远可读】  第五阶段目标:数据分片  多种执行方式:普通SQL,预编译SQL,存储过程。  多种分片策略:单列|多列,无值|单值|多值,多库&多表  多种扩展方式:Java类扩展,脚本语言扩展。
  • 30. 33 2.4 现状:UDAL关键技术的选择(简)  1,服务组织风格【RESTful】  2,中间层编程语言【Java vs C/C++】  3,后端存储方式【NO-RDB】  4,前端访问接口【NO-JDBC,NO-SQL】  NO-SQL 【用sqlid/callid替代sql语句】  抛弃复杂的sql语句,解析更容易,执行更安全。  NO-JDBC 【可支持NOSQL存储】  抛弃复杂的jdbc,服务端更容易解析  抛弃复杂的jdbc,客户端更容易使用  还可支持更多的存储方式:1)NOSQL库;2)服务(如Tuxedo)  5,交互协议(传输协议+数据协议)  数据传输协议【HTTP/CM20/…】  序列化技术【java+gz/hessian2+gz/xml/json/…】  结果集表示【List<Map<String,Object>>】  6,负载均衡: 【避免单点】 NO=Not Only
  • 31. 34 2.4 现状:UDAL软件产品(简) 1 应用逻辑层2 数据访问层(DAL) 1 应用系统 21 NIO网络 协议适配器 22 Dalet引 擎 211 消息头 解析器 212 消息体 解析器 221 资源 分发器 222 操作 映射器 23 Dalet容器 ● Dalet1 ● Dalet2 … http 11表现层 12逻辑层 13持久层 11表现层 12逻辑层 13持久层 http Method+URI 3 数据资源层 2 数据访问服务(1) 1应用系统 2 数据访问服务(2) 21 22 23 HTTP或CM20 JDBC Cache Hadoop Call DB2 MySQL Search APIs APIs 专利201010506543.2数据访问方法及装置
  • 32. 35 2.4 现状:UDAL服务平台(简)  服务平台= LBL + DAL + IoC + API DAL Remote API 连接池管理序列化和压缩… HTTP 客户端序列化 BSL基础服务平台 Mina2框架 IoService 过 滤 器 链 DB2 BS3框架 —— IoC AOP JMX Log REST AUTH FSM XUMP … Oracle Mysql 过滤器 IoHandler DAL服务器 NIO协议解析器 http/cm20/um32/… 数据访问引擎 DalEngine Dalet扩展 —— Auth PSqlid MCache MCacheAW MCacheNWR … 序列化和压缩 java/hessian/json/…/gz DB连接池管理 c3p0/dbcp/bonecp/… 线程池 协议解析器 … DAL Local API DalEngine Dalets … DB连接池管理 中间件 —— Tuxedo CICS
  • 33. 36 2.4 现状:UDAL全局地位(简) 负载均衡层 CDN 区域负载 (可选) F5/LVS +Nginx/ Haproxy Web前置集群综合前置FSL 异 步 订阅 同 步 服务层缓存层持久层 综合前置 FSL 通知和反馈SMS,Email,IM,… Memcached + Membase 二级缓存 应用切分 水平切分 垂直切分 读写分离 双主多从 F5/LVS +Nginx/ Haproxy 主备机制 JMS Camel 通过DAL访问 NOSQL DB Hadoop / HBase … NameNode2 复制 Master DB (行式)在线交易库 Master / Slave,分片,集群 DataNodes 同NameNode1 步 异 步 页面缓存 Squid Varnish OSCache 静态资源 合作机构 银行 移动 商户 分布式服务集群 应用服务:ASL 基础服务:BSL 数据访问:DAL 监控服务定时服务:TSL 集群 … 读 (列式)离线分析库 写 读… 复 制 Slave DB
  • 34. 37 3 论Jdbc4udal方案的技术可行性 1. 需求分析(数据库集群访问中间层) 2. 现有DAL中间层技术介绍 3. 技术可行性分析(Jdbc4udal方案)  问题  分析  对比  结论(?)
  • 35. 38 3.1*问题:使用UDAL并兼任现有开发模式  服务端问题:给核心数据库减负  数据库需要重构:纵向拆分|横向分片|版本升级|MyQql|…  应用端改动太多  需要一个中间层  引入UDAL服务层  客户端问题:   应用端改动太大 问:怎样使用UDAL并能兼任现有开发模式?
  • 36. 39 3.2*分析:访问UDAL服务的几种方式  方案1:直接调用BS3中API接口  DalApi4Inf api = DalClientFactory.newRemoteApi (…);  方案2:自定义封装协议接口( CM20|HTTP)  例:Php4Dal  方案3:封装Jdbc4udal驱动  服务端:提供固定服务地址,解 析动态SQL来实现分片。  客户端:已有应用系统不用改动 ,可使用任意ORM框架。 (读+写)混合操作只读操作只写操作 iBatis DAO iBatis+X Jdbc4udal DAO DalApi 中间层1(Amazon,手机之家 , DalServer) 中间层2(Mysql-Proxy, Atlas,Amoeba,Cobar, TDDL) MySQL,DB2,Oracle,… NOSQL
  • 37. 40 3.3*分析:方案Jdbc4udal目标 1、屏蔽数据库差异,换数据库时应用不需要修改。  DB2 改MySQL 【问题:sql编译顺序不一,需要重新优化】 2、屏蔽分表规则。order_0,1,2改成order_0,1,2,3,4,5,6时,应用不需要修改 多单表查询:解析表名、字段值(单值,值范围,Between,IN) 表关联:单表分片,多表分片一致,分片字段类似,多表分片规则不一致。  重点:不支持跨库JOIN 3、平滑迁移  限指客户端开发模式的迁移(jdbc->dal),方便回退。 4、节省数据库连接,不为每个应用分配独立DB连接,各应用公用DB连接。  支持 5、支持横向扩展 (1)服务端支持集群,能够配置任意数目服务器。 支持:多个DAL服务。 (2)支持数据库集群,可以实现读库和写库分离。 支持: 补充:
  • 38. 3.3*分析:方案Jdbc4udal当前问题 1、如何实现实表向虚表的过渡,实表、虚表是由应用端传送一个标志来区分还 是由服务器端自行适配? 41  修改iBatis配置中的Table名。【存储过程方式?】  必须能从名字上区分(_V_前缀):虚表_V_Schema.Tablename 2、c3p0连接池在管理改动后的Connection是否存在问题?  Connection有效性校验。  Commit,Rollback,Close,Open 3、dal如何支持事务?  不支持!  同时提交多条SQL到服务端,由服务端按事务执行。 4、dal需要定制出execute、executeQuery、executeUpdate三类服务;  executeQuery = GET URI 【在写库读?——】  executeUpdate = PUT URI 【在读库写?——全部更新,插入】  多个DataSource(在线库!=写库)【通过URI?db=online区分】 5、dal对不同数据库特有函数的支持;  用sqlparser替代cobar解析SQL,需要验证测试(殷舒) 6、如何将dal返回的数据转换成jdbc的类型?  (冗余操作:Map转JDBC结果集,然后再次转Map或Bean)
  • 39. 42 3.3*分析:方案Jdbc4udal的优缺点  方案3:封装Jdbc4udal驱动  技术可行性  服务端:提供固定服务地址,解析动态SQL来实现分片。  客户端:已有应用系统不用改动,可使用任意ORM框架。  技术风险点  层次增加:  Args -> SQL -> URI -> 解析SQL -> 解析表和字段  隐含陷阱:  特殊SQL  原有Cobar解析不支持,改sqlparser,需验证  大数据集 不支持该模式:用dalet直接生成文件后http下载。  多表JOIN   多表分片
  • 40. 43 3.3*分析:解析SQL时的问题  可解析部分(MySql)  操作语句:insert/delete/update/select  条件判断:>,<,=, <>,in,between,join,exists  解析不成功:  函数  解析后误判  例1:解析正常,有变形。  输入:SELECT * FROM tbl0 WHERE 1=1 limit 10,5  输出:SELECT * FROM tbl0 WHERE 1 = 1 LIMIT 5 OFFSET 10  输入:SELECT fields INTO tbl2 FROM tbl0 WHERE 1=1  输出:SELECT fields FROM tbl0 WHERE 1 = 1  例2:解析异常(net.sf.jsqlparser.parser.ParseException)  输入:SELECT * FROM products WHERE id='3' FOR UPDATE  异常:ParseException: Encountered " "FOR" "for "" at line 1, column 23.  输入:SELECT * FROM products LOCK IN SHARE MODE  异常:ParseException: Encountered " "IN" "IN "" at line 1, column 29.
  • 41. 44 3.3+分析:状态性  如何保持状态  DB中保持  前后端连接一致  DAL中保持  DAL服务器缓存  Client端保持  客户端缓存,批次提交。
  • 42.  三种方案的差异 45 3.4*对比:方案对比1(刘胜) 方案JDBC UDAL Jdbc4udal 备注 状态有状态无状态去状态状态C/S/DB保持 登录方式独立登录过程无需预先登录独立登录过程 大结果集支持不支持去大结果集服务端生成文件 事务支持客户端事务服务端事务? 参数Sql/psql/call sqlid + args sql 类“存储过程” 分片无按sqlid 按表名+字段 客户端ORM RPC ORM/ibatis 动态sql 由Ibatis支持缺省参数方式由Ibatis支持 迁移环节APP代码改动多APP容易迁移 测试环节按APP测试按APP测试 中间环节少中多
  • 43. 46 3.4*对比:方案对比2(殷舒) 对比项服务端配置SQL SQL解析 支持动态sql 支持sql语句场景 支持单库两分片表关联 网络流量大小 数据操作事前监控 数据操作事后监控 服务端配置分片规则需要需要 服务端配置sql 需要不需要
  • 44. 47 3.5 结论(?) 1. 三种方案的差异
  • 45. 48 8+问答1(任)现场问题及简要答复 对方问题: 1,关于jdbc4udal驱动,希望有产品或明确的开发计划。——答复:暂无计划。也担心 实现后效果不佳,无法达到预期的“透明”效果。如有强烈需求,也可先做一些探 索性预研。 2,希望支持分布式事务,有难度也想要做,可承担一定代价。——答复:本公司无此应 用场景。如有需要,可自定义dalet扩展,通过JTA实现。 3,关于跨地域/跨机房的场景。——答复:本公司无此应用场景。如有需要,也可从两个 层面来支持:1)服务层,可通过负载均衡器或服务查找模式,实现快速动态切换。 2)远程JDBC数据源:如果是镜像库模式,也可使用LVS负载均衡器、动态DNS等 方式,实现快速动态切换。【但是,数据复制的延时,由DB复制工具和网络状况决 定,与DAL层无直接关系。】 4,合作模式,希望能够采用合作开发的模式。——另行商定。 我方问题: 5,具体应用场景(高可读、高可写、读写混合、分库、强一致的分布式事务)——暂不 明确,可能都需要覆盖。稍后会整理一个详细的需求列表(包含应用场景),需我 司针对其需求做出明确的答复。
  • 46. 49 8+问答2(秦)数据备份和灾备  1,贵公司在物理部署上是否支持同城多点和异地多点?我看您的ppt里提到 了丰台与望京,这是北京2个平等的中心吗?丰台、望京是根据什么策略引导 用户访问的(如访问分配比例、DNS域名动态解析引导等)? 异地多点有无相 同引导策略?  2,是否存在同城(丰台-望京)数据备份、容灾考虑,实际的容灾设计方案是 什么样子的,RTO,RPO是多少? 异地容灾有无相同策略? 答复见邮件“关于贵公司数据备份 ,灾备咨询”
  • 47. 50 8+问答3(任)技术需求概述  第2 章应用数据访问需求  1.生产数据库服务器均采用PC Server,支持Oracle数据库。  2.需要支持数据部署在不同地域的数据中心,跨不同地域数据中心的读写情况,保障异地数据读写的执行效率。  3.基于JDBC规范,支持实现JDBC规范的数据源,数据访问对上层应用调用透明,开发整体采用Java语言。  4.支持主流ORM框架下的透明分布式数据访问开发,如:iBatis、Hibernate等。  5.支持带有权重的读写分离模式。  6.数据库读写库的动态切换。  7.支持读写次数、并发度控制。  8.数据库实例个数发生动态变更时,可以保障旧应用数据不发生迁移,新数据分布于新数据库中。  9.支持SQL解析,需要考虑Oracle中的语法。  10.数据库路由,数据库路由策略依照应用制定的策略完成;如是否可以跨库联表查询、能否跨库使用聚合函数、可以select ...for update等。  11.数据分页、查询结果数据合并和排序等。  12.集中式数据源信息管理和动态变更。  13.具备运行情况监控与分析功能。  第3 章数据备份及同步需求  1.数据库的本地、异地数据同步方案,数据同步需考虑不同表、不同规则的定制,需考虑数据在本异地同步下的延时。  2.提供数据在异地IDC的备份策略,发生灾难时数据的恢复策略。  3.数据库日常管理过程中,数据维护、迁移和管理的工具。  第4 章分布式事务控制需求  1.同一数据中心不同数据库间分布式事务控制方案。  2.异地数据中心不同数据库间分布式事务控制方案。 答复见文档『20140418联动优势数据访 问层DAL架构-技术需求概述(任)_答复( 刘胜).doc』  3.分布式事务控制对上层应用需要尽量避免影响考虑失败情况的应对支持等。
  • 48. 51 9+参考索引  网址  http://coolshell.cn/articles/10910.html 分布式系统的事务处理(陈皓 )2014年1月20日发表  其实,2PC/3PC都是分布式一致性算法的残次版本,Google Chubby的作者 Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算 法都是残次品。  Slideshare.net  http://www.slideshare.net/guestf5121c/ss-2334825 手机之家的数 据访问层实践(许超前)  http://www.slideshare.net/xcq/ss-3629618 数据访问层开发实践  http://www.slideshare.net/nikeliu/20120613dal4 20120613数据 访问层DAL架构和实践4(刘胜)新的特性.pptx  http://www.slideshare.net/nikeliu/20130626dal51-h 20130626数 据访问层DAL架构和实践5(刘胜)数据分片.pptx
  • 49. 52 Q9& 结A语:Q&A  现场问题——?  1,?  2,?  3,?  4,?  5,?  思考题——  1,?  2,?  3,?
  • 50. 53 9 总结:相关培训  20081113大型分布式系统架构技术简介(刘胜)中级.pdf  20081211大型软件系统开发综述(刘胜)中级.pdf /.mm/.png  20090219网络信息安全和认证技术(刘胜)中级.pdf  20090625服务器框架的概念和实践(刘胜)20121204.ppt  20090625分布式认证和授权技术(刘胜)初级.ppt  20090914系统架构师2009大会归来(刘胜)暨头脑风暴.ppt  20091224数据访问层DAL概念和实践1(刘胜).ppt  20100326数据访问层DAL概念和实践2(刘胜).ppt  20100902数据访问层DAL架构和实践3(刘胜).ppt  20101217软件技术大会和JavaOne大会归来(刘胜).ppt  20110223高可用可扩展的负载均衡层(卢翔,刘胜).ppt  20110801应用监控系统架构实践(刘胜).ppt  20120613数据访问层DAL架构和实践4(刘胜).pptx  20121012联动优势技术大会(刘胜)三年技术规划v1.3.4.pptx  20121013联动技术框架能力发布-BS3&DAL(殷舒).pptx  20121218联动优势技术平台介绍(for漫道科技)v5.pptx  20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx  20130521联动优势企业架构介绍(刘胜).pptx  20130325理解REST设计模式和反模式(刘胜)草案.pptx

Notes de l'éditeur

  1. 【修改历史】 Version 5.0.20130606 初期版本。 Version 5.1.20130608 +写库读操作修改测试验证。+脚本语言选择。*设计原则。 Version 5.2.20130619 +性能测试,+用例和测试 Version 5.2.20130620 +其它新需求,+功能测试(黄进),*性能自试(殷舒),*设计方案,+实现方案(比较),+发布地址 Version 5.3.20130621 *其它新需求(TODO) Version 5.3.20130624 *相关约定(+SHARDING_FIRST), Version 5.3.20130626 +例9单列分片普通SQL全局优先查询,+实现:新旧读写分离方式对比,*背景问题,*背景需求, Version 5.3.20130626 *需求满足度(改为:需求和示例),个别细节修改(分片类型,新旧方式的对比) Version 5.4.20130626 评审。隐藏部分内容(高可用数据存储架构,DAL技术选择,DAL服务平台,DAL地位,现状多表分离和多表查) Version 5.5.20130628 发布。*新需求(陈瑛琦)支持DB2导出的归档数据文件;*相关约定:分隔符逗号改分号?! Version 5.5.20130709 +新需求-结果合并 Version 5.6.20130802 +例10-x:多表分页 Version 5.6.20130814 *其他:框架拆分 Version 5.7.20131016 +例10-0:多表分页查询的参数 Version 5.7.20131016 +小节:新需求(TODO-1016) 20131030数据访问层DAL架构和实践(6)SQL解析(殷舒).ppt 20140326数据访问层DAL架构和实践(7)技术交流(刘胜).pptx Version 6.1.20130326 3.3+分析:解析SQL时的问题 / 状态性 Version 7.1.20140425 1.2*需求分析:不同层次的方案/不同模式中间层/不同机房的方案 1.2+需求分析:CAP和RQC原则/两个行业类比 2.2+背景:已有中间层技术方案(DDB) 补充调整:1.0/1.1/1.2/1.3 -------- 标题: architecture_and_practice_for_dal_7_exchanges_with_icbc Architecture and Practice for DAL (7) Exchanges with ICBC Architecture and Practice for Data Access Layer (7) Exchanges with ICBC 联动优势数据访问层DAL架构和实践之七:技术交流 说明: 针对2014.3.26与工行软件开发中心北京研发部交流,而准备的DAL相关材料。 和已有DAL软件(如许超前DAL手机之家、陈思儒Amoeba/贺贤懋Cobar等)不一样,在前端访问方式的选择上,抛弃JDBC方式,而是为同一个dalet数据服务,同时提供自定义TCP长连接和HTTP长连接两种接口。 因而通过抛弃JDBC可以获得多方面的好处—— 1)可减少S端协议解析和查询分析的开销; 2)也简化C端编程。 3)后端存储就不再限于RDB了,而可以是任意NOSQL、文件、缓存、甚至是Tuxedo等在线服务。 4)可以实现无状态了,更容易横向扩展。 5)从接口上就可消除join等关键字的误用,避免引起服务端负担过重。 -------- 分享:http://www.slideshare.net/nikeliu/20130626dal51-h 标题:联动优势数据访问层DAL架构和实践之五:访问分片数据 Architecture and Practice for DAL (5) Data Sharding Architecture and Practice for Data Access Layer (5) Data Sharding Architecture and Practice for DAL (5) Data Sharding 联动优势数据访问层DAL架构和实践之五:分片数据分片 说明: How to implement a dalet to access sharding databases. 按照许超前的说法(见http://www.slideshare.net/xcq/ss-3629618),其实现的DAL与memcache比较,其性能差异主要在协议解析和查询分析上。 和已有DAL软件(如许超前DAL手机之家、陈思儒Amoeba/贺贤懋Cobar等)不一样,在前端访问方式的选择上,抛弃JDBC方式,而是为同一个dalet数据服务,同时提供自定义TCP长连接和HTTP长连接两种接口。 因而通过抛弃JDBC可以获得多方面的好处—— 1)可减少S端协议解析和查询分析的开销; 2)也简化C端编程。 3)后端存储就不再限于RDB了,而可以是任意NOSQL、文件、缓存、甚至是Tuxedo等在线服务。 4)可以实现无状态了,更容易横向扩展。 5)从接口上就可消除join等关键字的误用,避免引起服务端负担过重。 --------
  2. 代码质量@刘胜20130426.mm 确定“优秀代码评选标准”时的一些总结。思维导图格式。主要是大原则,没写具体实例。可以一起讨论交流一下。 20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx 黑名单存储,以及专利知识。之前这边和金泽分别讲过一次。如还有人有兴趣,可以再讲一次。 20130521联动优势企业架构介绍(刘胜).pptx 按部门培训计划来的命题作文,原计划是5.21在金泽讲的,后因搬家改期。如有兴趣可先讲。主要是综合了服务器框架、技术规划等相关内容。 20130325理解REST设计模式和反模式(刘胜)草案.pptx 初稿,总结了三个REST模式和反模式,附录还有更多的反模式。 3.3+分析:解析SQL时的问题
  3. 修改:Requirements / Features / Function points / Functional Features 修改:Quality / Quality available 修改:Costs tolerance / Conts limit / Cost reduction 平衡:时间、范围、成本、质量 项目管理是时间、成本、范围和质量的平衡艺术。 项目管理三角形(时间、质量、成本)中间是范围。 http://blog.csdn.net/rishengcsdn/article/details/7406099 (图) Eric A. Brewer是Inktomi公司的创始人,也是berkeley大学的教授 在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:[1][2] 一致性(Consistency)(所有节点在同一时间具有相同的数据) 可用性(Availability)(保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance)(系统中任意信息的丢失或失败不会影响系统的继续运作) 根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项[3]。 这个定理起源于柏克莱加州大学(University of California, Berkeley)的计算机科学家埃里克·布鲁尔(Eric Brewer)在2000年的分布式计算原则研讨会(Symposium on Principles of Distributed Computing(PODC))上提出的一个猜想。[4] 在2002年,麻省理工学院(MIT)的赛斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)发表了布鲁尔猜想的证明,使之成为一个定理。[1]吉尔伯特和林奇证明的CAP定理比布鲁尔设想的某种程度上更加狭义。定理讨论了在两个互相矛盾的请求到达彼此连接不通的两个不同的分布式节点的时候的处理方案。 (http://www.julianbrowne.com/article/viewer/brewers-cap-theorem CAP原则及证明的原文)
  4. Eric A. Brewer是Inktomi公司的创始人,也是berkeley大学的教授 分布系统CAP原则:Consistency,Availability,Partition tolerance 软件产品FQC原则:Features(requirement),Quality,Costs available Features = requirement points 见:《人月神话》,《快速软件开发》 Total cost of ownership (TCO)  1人10月生孩子 != 10人1月生孩子 最佳质量成本模型图 http://www.google.com.hk/imgres?imgurl=http://www.tuandui.org.cn/uploads/allimg/080808/1448201.jpg&imgrefurl=http://www.tuandui.org.cn/html/ProjectManagement/Cost/20080808/2154.html&h=353&w=507&tbnid=I_LLMM0m0lH2tM:&zoom=1&docid=v7XeAB2OBAt5MM&ei=oTdoU82QK4GHrAfOzoDABA&tbm=isch 最低质量成本模型图 http://www.google.com.hk/imgres?imgurl=http%3A%2F%2Fwww.zhijiegl.com%2Fuploads%2F120801%2F1-120P1150219596.jpg&imgrefurl=http%3A%2F%2Fwww.zhijiegl.com%2Fguanli%2F123.html&h=311&w=536&tbnid=fpTJRW6w00ILIM%3A&zoom=1&docid=mZNn2ggudsqBrM&ei=ozdoU7OdHMWPrQf88YDQDQ&tbm=isch&ved=0CGsQMygNMA0&iact=rc&uact=3&dur=311&page=1&start=0&ndsp=15&biw=1366&bih=677 http://www.sdqmc.cn/ucecmc/33641-360927.aspx 质量改进工具——质量成本分析(cost-of-Quality Analysis)下 C1——预防成本;·  C2——鉴定成本;·  C3——事故成本;·  C4——基本生产成本。 http://www.cfc365.com/case/2013-02-22/8316_2.shtml “质量”是棵“摇钱树”
  5. -------- 转发邮件信息 -------- 发件人:yimlc@sina.com 发送日期:2014-03-24 17:19:01 收件人:wwj_0303 <wwj_0303@163.com> 主题:联动优势数据访问层DAL架构-技术交流 你好: 经互联网搜索了解到贵公司可能有一个数据访问层DAL架构,大概理解要解决的问题及设计思路如下。 解决问题:当传统Web应用面对高并发数据访问需求时,原底层单数据库设计难以有效支撑上层应用的数据访问,因此需要对数据库采用读写分离或分库/分表等手段实施多库拆分,以便整体提高应用的高可用性。 设计思路:参照上述策略对原单数据库完成水平扩展后,就上层应用访问而言,势必出现如SQL动态解析、多库路由读写访问、跨库事务一致性、跨库查询结果数据合并/排序等问题,所以考虑引入数据访问层DAL(数据库驱动层之上,应用DAO层/ORM框架层之下)以便透明解决上述难题。 请帮忙了解贵公司目前是否存在该架构?如存在是否已形成产品可直接对外出售?如不存在是否有意根据我行需求以单独承包/合作开发的方式对该架构进行落地研发? 因此事较紧急,如果方便希望能够尽快给予答复,有合作可能在明/后两天(2014/03/25或2014/03/26)安排初步的当面技术交流(直接来我行北研基地或前往贵公司),谢谢。 --工行软件开发中心北京研发部-研发支持部 任风雷 办公座机:010-82706707
  6. 中间层1(UDAL,Amazon,手机之家DAL) IaaS,PaaS,SaaS, 中间层2(RDS)MySql/Proxy,Atlas,Amoeba,Cobar,TDDL) 中间层1(DaaS ) UDAL, S3, JPA DBaaS中间层(UDAL,S3,SimpleDB,…)
  7. http://en.wikipedia.org/wiki/Amazon_Relational_Database_Service Several other vendors provide cloud database services similar to Amazon RDS. Oracle offers Oracle Cloud,[16] a database service supporting Oracle's database technology. Microsoft offers Windows Azure SQL,[17] a service supporting the Microsoft SQL database. Competitors supporting MySQL include RackSpace Cloud Databases,[18] Google Cloud SQL,[disambiguation needed] [19] HP Cloud for MySQL,[20] Xeround Cloud Database[21] and ClearDB.[22] http://msdn.microsoft.com/en-us/library/gg433040.aspx For getting started information about Windows Azure storage, see the following topics in the Windows Azure Developer Center: How to Use the Blob Storage Service How to Use the Table Storage Service How to Use the Queue Storage Service http://www.scaledb.com/DBaaS-Database-as-a-Service.php DBaaS: Ecosystem Isn’t Important, It’s Everything! The database graveyard includes object databases, graph databases, XML databases, object-relational databases, in-memory databases, and now NoSQL and NewSQL. http://www.oracle.com/technetwork/topics/entarch/oes-refarch-dbaas-508111.pdf 【论文】Database as a Service: Reference Architecture – An Overview http://dblab.xmu.edu.cn/post/google-spanner/ Spanner会把下面的数据特性集合暴露给应用:基于模式化的半关系表的数据模型,查询语言和通用事务。 Spanner的数据模型不是纯粹关系型的,它的行必须有名称。更准确地说,每个表都需要有包含一个或多个主键列的排序集合。 http://db-engines.com/en/system/DynamoDB%3BSimpleDB 比较 http://www.programmer.com.cn/11081/ http://stackoverflow.com/questions/8961333/amazon-simpledb-vs-amazon-dynamodb http://stackoverflow.com/questions/4572227/difference-between-simpledb-and-s3 http://zh.wikipedia.org/wiki/Amazon_SimpleDB Amazon SimpleDB是一个分散式数据库,以Erlang撰写。同与Amazon EC2和亚马逊的S3一样作为一项Web 服务,属于亚马逊网络服务的一部分。 http://www.nosqlnotes.net/archives/163 Amazon S3 & Simpledb内部实现分析 Posted by chuanhui on 2011 年 03 月 27 日 Leave a comment (6)Go to comments Amazon S3申请了一篇专利,名称为”Keymap Service Architecture for A Distributed Storage System“,而Amazon Simpledb的实现细节暂时没有公开。本文根据Dynamo论文,S3专利以及S3&Simpledb的对外API尝试推测这两个系统的内部实现。 Amazon S3(Simple Storage Service)起源于Dynamo,基本可以认为是Dynamo(称为Keymap) + Blob File System(称为Bitstore)。 S3和Simpledb最大的区别还在于一致性选择,初期的S3选择走Dynamo的技术路线,后来的系统发现这个路线不容易走,比如用户迫切希望的乐观锁和强一致读功能无法实现,因此Simpledb对于更新操作选择强一致性。Simpledb支持乐观锁机制并提供了简单的SQL Select子集支持,我认为这个系统的设计是比较优雅的。
  8. 3,关于跨地域/跨机房的场景。 ——答复:本公司无此应用场景。如有需要,也可从两个层面来支持:1)服务层,可通过负载均衡器或服务查找模式,实现快速动态切换。2)远程JDBC数据源:如果是镜像库模式,也可使用LVS负载均衡器、动态DNS等方式,实现快速动态切换。 【但是,数据复制的延时,由DB复制工具和网络状况决定,与DAL层无直接关系。】
  9. http://jm-blog.aliapp.com/?p=448 ZooKeeper是近期比较热门的一个类Paxos实现。也是一个逐渐得到广泛应用的开源的分布式锁服务实现。 被认为是Chubby的开源版 http://blog.csdn.net/historyasamirror/article/details/3870168 综上所述,Chubby是一个lock service,通过这个lock service可以解决分布式中的一致性问题,而这个lock service的实现是一个分布式的文件系统。 http://pchou.info/algorithm/2013/11/07/527ba36a16888.html数据库一致性原理浅析 http://coolshell.cn/articles/10910.html 分布式系统的事务处理(陈皓) 其实,2PC/3PC都是分布式一致性算法的残次版本,Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。 CAP理论 【高可用分布式一致性性能不可用】 http://www.cnblogs.com/aigongsi/archive/2013/01/14/2860372.html 一个简单的跨库事务问题 1 考虑使用JTA等支持分布式事务的事务管理器 这种方案的优势就是直接有现成的解决方案,一般的j2ee服务器都提供了JTA的相关的实现。比较明显的问题就是解决方案太重量级。一般JTA除了服务器要支持,对应的数据库服务厂商一般也要提供相应的商业支持,主要是提供基于 XAResource JDBC驱动,这一些商业上的支持,部分是需要付费的。而且使用XA 数据库驱动,本身可能导致一些潜在的问题,尤其是基于不同的数据库厂商的时候。而XA是基于两阶段提交协议,事务管理器为了完成一个事务,需要多次和数据库通信,效率上比较低。 2 考虑使用数据库自身的数据同步机制 3 在old库存放相同的两张模型表,一张表用于old库的持久化表,另外一张作为临时表,主要是作为需要同步到到新库的数据。
  10. 不同厂商的数据库 各种NOSQL数据存储 在线服务 概念:数据访问层DAL 【Layer=Services】 是一系列服务的集合,是DAO的自然延伸,是SOA的具体实现。 好处: 简化客户端接口,规范数据操作 【=>RESTful DB】 保持客户端接口,动态升级服务端实现 【SOA】 支持对巨量数据的访问 【缓存;读写分离;分片(分表/分库)】 服务的治理 【认证/管理/权限/监控/分析/优化】 功能需求: 访问代理 【Proxy】 读写分离 【RAIDb-1镜像,每个库都是全库】 数据分片 【RAIDb-0分区,每个库都是子库】 高可用性 【支持三备份和NWR模型】 特性需求: 厂商中立 【1)多种数据库类型;2)多个数据库版本?】 语言中立 【支持Java、C/C++、PHP、Flex等多种客户端接口】 资源共享 【共享DataSource连接池,共享Cache】 访问日志 【提供SqlLog和BackLog,可用于性能瓶颈分析和数据恢复】 访问控制 【用户认证/连接管理/权限控制】 读写分离 【FullDB】 数据分片 【分表,分库】 访问集群 【HA-Proxy、JGroup】
  11. 问题:分区和主从的区别?
  12. 数据量大 【陈瑛绮】 联动用户表:老表userinf有1.1亿,mobileBankInf有4000万。 【新表tuser+tuserBank】 联动交易表:老表transAll有1.2亿, 【从2010.10.1-2011.6,日均50万】 数据冗余: 【陈瑛绮】 数据表多个版本混存,每个用户记录两次,每条交易记录两次。 【双写,效率低,不一致】 个别应用过度依赖于TransAll表,未做日表翻滚。 【小额年底改造/空充无人维护/个别电渠】 读写不均 淘宝读写比测算:10:1(来自iDataForum) 联动读写比估算:用户表(20:1),交易表(2:1) 连接池问题:应用太多太分散,导致数据库连接数超限。 【未有效共享连接池】
  13. 已有JDBC驱动:直接使用MySQL驱动 Mysql-Proxy Atlas@Qihoo360 Amoeba Cobar@AliBaBa 定制JDBC驱动 TDDL@Alibaba 放弃JDBC驱动 DAL@手机之家 UDAL@Umpay 方案1:Mysql-Proxy@MySQL官方 特点:官方提供,可实现负载平衡/读写分离/failover等,但不支持大数据量的分库分表且性能较差。 参考:http://dev.mysql.com/downloads/mysql-proxy/ 参考:https://github.com/drmingdrmer/mysql-proxy-xp/blob/master/lib/rw-splitting.lua 方案2:Atlas@Qihoo360/王超 特点:在mysql-proxy-0.8.2版基础上优化,增加若干新特性。 源码:https://github.com/Qihoo360/Atlas 方案3:Amoeba@/陈思儒 缺点:不支持事务/存储过程/输出大数据量结果集/分库分表。目前只做到分DB实例,每个节点需要保持库表结构一致。 版本:Amoeba for MySQL/Aladdin/MongoDB 源码:http://sourceforge.net/projects/amoeba/ 文档:http://docs.hexnova.com/amoeba/ 方案4:Cobar@AliBaBa/贺贤懋 缺点:基于amoeba 0.34,开源版只支持mysql,并不支持读写分离。 源码:http://code.alibabatech.com/wiki/display/cobar/Home 方案5:TDDL@Taobao 特点:基于集中式配置的Jdbc数据源实现,具有主备/读写分离/动态数据库配置等功能。 缺点:复杂度相对较高,文档较少,只开源动态数据源,分表分库部分还未开源,还需要依赖diamond,不推荐使用。 源码:https://github.com/alibaba/tb_tddl 方案6:S3@Amazon(Simple Storage Service) 特点:基于标准REST和SOAP接口的超级SAN存储 -------- 参考:http://bbs.chinaunix.net/thread-1341765-1-1.html 再提mysql-proxy读写分离脚本(rw-splitting.lua)BUG问题 参考:http://www.open-open.com/doc/view/f8d0b2d9898d4c898fe53bcdaddca2a3 Cobar -- 分布式数据库Proxy方案.pptx Cobar 前身之前版本为amoeba 0.34已经在生产环境中投入使用,目前开发的新版本更名为cobar 。Cobar 应用领域在分布式数据库领域中致力于解决数据切分、数据分发、数据合并、数据返回等功能。为前端应用提供一个透明的、单一的数据访问服务。屏蔽后端分布式数据库的复杂逻辑。
  14. 13:30-14:20 淘宝数据库高性能透明分库分表探索 皓庭:淘宝数据库工程师 DTCC2013:阿里云分布式RDS平台——柳彦召 DTCC2014:DRDS分库分表 - RDS关系数据库云服务的水平扩容技术-皓庭_IT168文库.pdf --------- 2012.6,联合阿里集团POR技术团队,合作开发,分布式数据库,预计12月公布。 参考:http://www.itpub.net/thread-1836168-1-1.html ITPUB名人堂 采访阿里皓庭 :阿里云平台相关技术经验分享! 方案3:Amoeba@/陈思儒 缺点:不支持事务/存储过程/输出大数据量结果集/分库分表。目前只做到分DB实例,每个节点需要保持库表结构一致。 版本:Amoeba for MySQL/Aladdin/MongoDB 源码:http://sourceforge.net/projects/amoeba/ 文档:http://docs.hexnova.com/amoeba/ 方案4:Cobar@AliBaBa/贺贤懋 缺点:基于amoeba 0.34,开源版只支持mysql,并不支持读写分离。 源码:http://code.alibabatech.com/wiki/display/cobar/Home 方案5:TDDL@Taobao 特点:基于集中式配置的Jdbc数据源实现,具有主备/读写分离/动态数据库配置等功能。 缺点:复杂度相对较高,文档较少,只开源动态数据源,分表分库部分还未开源,还需要依赖diamond,不推荐使用。 源码:https://github.com/alibaba/tb_tddl
  15. http://wenku.baidu.com/view/523b68ec551810a6f524863e.html 网​易​海​量​数​据​存​储​平​台​的​构​建​和​运​维​-​网​易​:​王​磊@网易杭研院​​​
  16. BSL平台(=LBL+DAL+IoC)
  17. 丁喆 13:44:05 我们不修改ibatis,只是做了一个dal的驱动,封装成jdbc方式 丁喆 13:44:18 具体情况正在验证 丁喆 13:44:24 还没弄完 【虎.无名】 13:45:05 但是,jdbc是有连接状态的,而dal是无状态的。尤其对于大数据集的场景,用dal并不适合。 丁喆 13:47:56 jdbc是有连接状态的,我们可以不保存链接的方式 丁喆 13:48:39 每次都是获取新的链接,或者连接池中只保存connection对象 丁喆 13:49:24 你这里说的大数据集是否有界定?多少算大? 丁喆 13:52:34 这个倒是可以在客户端加以限制 【虎.无名】 13:52:50 在线操作,是不需要大数据集的。离线操作才需要。 丁喆 13:53:30 目前我们对于这种大数据集都是在应用层面做了限制 【虎.无名】 13:53:59 3)分页。2)自定义dalet在服务端生产所需文件,然后通过web获取。1)直接访问DB。
  18. 服务端:提供固定服务地址,解析动态SQL来实现分片。 客户端:已有应用系统不用改动,可使用任意ORM框架。 层次多:Args -> SQL -> URI -> 解析SQL -> 解析表和字段 陷阱多:特殊SQL、大数据集、多表JOIN、多表分片
  19. http://hi.baidu.com/benzhan/item/8858e04c24db8fe81f19bce1 SELECT FOR UPDATE 假设有个表单products ,里面有id 跟name 二个栏位,id 是主键。 例1: (明确指定主键,并且有此数据,row lock) SELECT * FROM products WHERE id='3' FOR UPDATE; 例2: (明确指定主键,若查无此数据,无lock) SELECT * FROM products WHERE id='-1' FOR UPDATE; 例2: (无主键,table lock) SELECT * FROM products WHERE name='Mouse' FOR UPDATE; 例3: (主键不明确,table lock) SELECT * FROM products WHERE id<>'3' FOR UPDATE; 例4: (主键不明确,table lock) SELECT * FROM products WHERE id LIKE '3' FOR UPDATE; 注1: FOR UPDATE 仅适用于InnoDB,且必须在事务区块(BEGIN/COMMIT)中才能生效。 注2: 要测试锁定的状况,可以利用MySQL 的Command Mode ,开二个视窗来做测试。
  20. http://www.slideshare.net/mkindahl/pluk-2013-my-sql-fabric
  21. 20131030数据访问层DAL架构和实践6(殷舒)SQL解析.ppt
  22.       三、需要我司反馈的问题:         1、需要我司明确双方的合作模式:工行希望能够采用合作开发的模式(以我司开发为主,工行配合),最终产品与源代码提交工行,关于知识产权问题双方协商确定;         2、工行会整理一个详细的需求列表(包含应用场景),我司针对其需求做出明确的答复;         3、能够向对方提供本次交流的PPT 提出了使用中间层的需求,但是具体应用在何种场景(高可读、高可写、读写混合、分库和分布式事务)尚未确定,未给出明确答复。他们后续会进一步落实。
  23. 你好,王秦川 客气了。 另外也不好意思,邮件回复慢了。 最近几天有人员外出参见“数据库技术大会”,因灾备是网络部门实施的,咨询不方便。 1, 贵公司在物理部署上是否支持同城多点和异地多点? ——如您指公司现有移动支付系统,那么尚未没做到支持多中心。 ——如仅仅指UDAL则是比较容易做到的。由于UDAL设计是完全服务化,而且是无状态的。所以,只要数据复制解决好了,对数据访问而言就很容易进行负载或迁移。 我看您的ppt里提到了丰台与望京,这是北京2个平等的中心吗? ——联动目前有丰台、望京、亦庄三个机房,并非平等的中心。主要是业务分离,而不是针对灾备的多中心。 ——联动的多中心的原因:一是原有移动望京机房容量不够。二是两公司(联动科技,联动电商)分离后导致的业务分离以及硬件资产物理分离; 丰台、望京是根据什么策略引导用户访问的(如访问分配比例、DNS域名动态解析引导等)? ——单业务多中心,只是临时状态,引入DAL后解决迁移过程中临时状态的问题,确保平滑迁移。 ——场景很简单,因为新老系统临时并存,历史数据已迁移到丰台,有部分新数组尚未迁移完成,遗留在望京。 ——策略很简单,就是访问丰台数据源无对应交易数据,那么继续访问望京的数据源,使用下面的“模式1” ——模式1)根据UDAL分片策略,返回多个可选库/表,依次访问每个库表,直到获取到有效数据(或全部为空)就返回,不再访问剩下的库表。 ——模式2)根据UDAL分片策略,返回多个可选库/表,依次访问所有库表(也可并发访问),获取每个库表的子结果集,然后归并/排序再返回。 异地多点有无相同引导策略? ——联动做的尚未如此专业。 ——对于分库场景,不推荐做太复杂,不推荐使用远程的分库,最好都是本地分库。 ——建议是“远程DalServer”模式,切换更方便。 ——如有需要,也可从两个层面(远程DalServer|远程DataSource),多种方案来支持(DNS或其他服务查找器;LVS/HaProxy等负载均衡器) 远程UDAL服务器:可通过负载均衡器,或服务查找器,实现多个中心间的快速动态切换。 远程JDBC数据源:如果是镜像库模式,也可使用LVS负载均衡器、动态DNS等方式,实现快速动态切换。 例如: Client - DNS - LVS/HaProxy - DalServer#1 - Local#1 DataSource Client - DNS - LVS/HaProxy - DalServer#1 - Remote  DataSource Client - DNS - LVS/HaProxy - DalServer#2 - Local#2  DataSource 但是,数据复制的延时,由DB复制工具和网络状况决定,与DAL层无直接关系。 2,是否存在同城(丰台-望京)数据备份、容灾考虑,实际的容灾设计方案是什么样子的,RTO,RPO是多少? 异地容灾有无相同策略? ——去年,公司网络部门上了灾备系统,主要是使用SVC(Switching Virtual Circuit)技术在网络层做的灾备,但尚未经过严格的实际检验,不具备推广价值。未对RTO和RPO有指标要求。 ——个人觉得,好的容灾,应该是镜像模式,从上到下都有完整的一套,根据需要自动切换。所有的业务应用做成无状态的,这样只需要把数据库层这个唯一单点的复制做好,就OK了。 ——具体的容灾方案,得与具体的场景相关。 ——想实现高一致性/高可用性容灾,是很困难的。在三种数据复制模式(异步复制/半同步复制/同步复制),要高一致/高可用,一笔事务也不允许丢失,那就只能是同步复制,这个对性能影响很大。实施成本也很高。 ——“沃趣”的QData for Oracle/MySQL数据库一体机,通过引入高速网卡、PCIe Flash高速存储、软件RAID等技术,在存储层实现复制,是一种比较好的思路,这样对数据库软件本身改造最少。 另外,上次的讲义中也有一页,针对当时交流的问题,做了简要回答。 8+问答:现场问题及简要答复 问题: 1,关于jdbc4udal驱动,希望有产品或明确的开发计划。——答复:暂无计划。也担心实现后效果不佳,无法达到预期的“透明”效果。如有强烈需求,也可先做一些探索性预研。 2,希望支持分布式事务,有难度也想要做,可承担一定代价。——答复:本公司无此应用场景。如有需要,可自定义dalet扩展,通过JTA实现。 3,关于跨地域/跨机房的场景。——答复:本公司无此应用场景。如有需要,也可从两个层面来支持:1)服务层,可通过负载均衡器或服务查找模式,实现快速动态切换。2)远程JDBC数据源:如果是镜像库模式,也可使用LVS负载均衡器、动态DNS等方式,实现快速动态切换。【但是,数据复制的延时,由DB复制工具和网络状况决定,与DAL层无直接关系。】 4,合作模式,希望能够采用合作开发的模式。——另行商定。 在 2014年4月11日 上午10:29, <wangqc@sdc.icbc.com.cn>写道: 刘架构,您好          我是3月25日与贵公司交流DAL产品的工行软件开发中心北京的同事,我有2个问题咨询您:          1,贵公司在物理部署上是否支持同城多点和异地多点?我看您的ppt里提到了丰台与望京,这是北京2个平等的中心吗?丰台、望京是根据什么策略引导用户访问的(如访问分配比例、DNS域名动态解析引导等)? 异地多点有无相同引导策略?          2,是否存在同城(丰台-望京)数据备份、容灾考虑,实际的容灾设计方案是什么样子的,RTO,RPO是多少? 异地容灾有无相同策略?          烦请不吝赐教,谢谢                                                                                                                                          工行软开王秦川 010-82706219