2014 阿里技术沙龙 OceanBase 专场

主要流程

1. OceanBase-迎接关系数据库历史性机遇
2. OceanBase-破解数据库高可用性难题
3. OceanBase-支付宝交易O2O最佳实践

OceanBase-迎接关系数据库历史性机遇

杨传辉/日照（阿里巴巴蚂蚁金服）

1. 分布式数据库的基本问题
2. OB方案介绍
3. OB发展历程

• Shard-Disk - Oracle RAC, IBM pureScale

• Shard-Nothing - Spanner/Percolator, IBM DB2 DPF, VoltDB, 分库分表

• 分布式事务 ACID
• 分布式写事务
• 2阶段提交 经典方式
• RAC 数据块
• 分布式快照读（全局版本号）
• 全局时钟 - 硬件方式保证 - Spanner
• 单点，一台机器生成版本号 - Percolator
• 加锁

可扩展性

• 已有扩容方案
  • 分库分表 - 业务增长比较慢，几年翻倍
  • RAC - 业务增长迅速，比如一年翻5倍
• 期望的扩容方式
  • 廉价的服务器集群

高可用

• 传统关系数据库：主备库
  • 最大保护：事务一定同步到备库
  • 最高性能：事务异步同步到备库
  • 最大可用：事务尽力同步到备库
• OB：分布式投票

高性能

• 数据库写入放大
• 传统数据库是面向磁盘的，数据块
• SSD 写入数据量远远小于擦除的数据量
• Multi-Core CPU & Ultra-Large Memory
• memsql (64 core, 150w qps 写入)，SAP HANA，SQL Server

数据库背后的事实

• 数据库：总量大，增删改量少
• 10亿写事务，100B/事务 - 100GB

DATA = 基线数据(固态盘) + 修改增量(内存)

每日合并 DATA = 基线数据(固态盘) + 修改增量(内存) + 新的修改增量

OB架构(单集群)

• Update Server - 增量
• Chunk Server - 基线
• Root Server - 总控中心
• Merge Server - 应用入口

OB架构(三集群) 同城机房

Paxos选举主集群

• Paxos协议
  • Leslie Lamport
• 工程实现简化
  • Raft
  • OB 同步选举协议
• 挑战
  • 消息乱序怎么办？
  • 如何处理多轮Paxos消息混杂问题？
  • 选举成员故障怎么办？

高性能存储引擎 (单点写事务)

• Lock-free 技术
• 按行索引，行缓存
• 只读基线存储
• 避免SSD随机写入

OB Milestone

• 做了 4年+
• 2010.06 - kv 系统
• 2011.02 - v0.1 1个集群
• 2011.10 - v0.2 2个集群，双机房，收藏夹业务
• 2012.04 - v0.3 OLAP 数据报表，数据统计和分析
• 2012.11 - v0.4 SQL
• 2014.02 - v0.5 三集群，选举，高可用

OB 的应用

• 收藏夹
• 交易评价
• 交易记录
• 每天数百亿次读写访问
• 单表最大超过2000亿数据
• 单一业务超过100台服务器

支付宝交易库020实践

• OB 第一个用于金融业务的非商用数据库
• 数据丢失 零容忍
• 事务ACID
• 可扩展性，高性能，高可用

020 面临那些挑战

• 如何降低业务系统改造成本？
• 如何实现数据迁移？
• 如何是实现灰度操作？

云上的OB(1.0)

• 完全兼容 MySQL
• 动态伸缩能力
• 分布式事务
• 更少成本
• 数据强一致

小结

• OB：单机写事务+分布式读事务

• OB：高可用+高可扩展+内存引擎

• 天时：云计算技术成熟，SSD，多核硬件发展
• 地利：阿里的应用场景，双十一的压力
• 人和：公司层面的鼎力支持，靠谱的小伙伴

关于 CAP

• CAP 做理论的人的假设是死的，在现实世界中，可以细分，折衷
• 宕机时间，1s？1m？1h？
• 100ms内

OceanBase-破解数据库高可用性难题

《OceanBase-破解数据库高可用性难题》 - 李凯/郁白（阿里巴巴蚂蚁金服）

1. 数据库高可用的意义
2. 传统数据库的高可用方案
3. OB的高可用方案
4. OB1.0技术展望

高可用的意义

• 数据可靠性前提：保证数据不丢失
• 数据可用性：保证数据可访问
• 故障不可避免

几个“九” 图

5 个 9 的可用性

传统数据库的高可用方案

• 单机高可用
  • 高可用硬件：小型机+高端存储
  • 硬件冗余：多路冗余电源和网络
• 集群高可用
  • 1主N备
  • 可选的备份模式
  • 最大保护，最高性能，最大可用
• 问题
  • 昂贵
  • 谁来选主
  • 不可调和的数据可靠性与可用性矛盾

OB 高可用方案

• 总体架构
• RedoLog同步
• 分布式选举
• 多级Lease时间分析

总体架构

• root server 自己选主，无状态
• update server 由 root server 选主

Root Server Leader Elect Group

• UpdateServer 基于投票的RedoLog 同步

• N个副本，多数派(N+1)/2同步成功

• UpdateServer 基于投票的 RedoLog 同步
• 顺序应答与乱序应答的折衷
  • 顺序应答：实现简单，对网络抖动的容忍度低
  • 乱序应答：调序与补偿逻辑复杂，性能好，对网络抖动的容忍度高
• 关键细节
  • 备机回放的条件
  • 主机未决日志的补偿
  • 备机未决日志的覆盖
  • 幽灵复现 - 时间戳 选主
  • 顺序应答的性能优化
  • 类似 Raft ，都是顺序应答

RootServer 的分布式选举

• 原则：选举保证任意时刻最多只能有一个 Leader
• 投票：得到多数派(N+1)/2的人成为Leader
• 关键细节：
  • 对时钟的依赖：Lease 与 心跳的折衷
  • 选举时机的选择：避免选举分裂，支持投票权重
  • 成员投票不自相矛盾的保证：持久化与非持久化的折衷
  • 折衷的方案，保证简单的设计：
  • 选举窗口，不设心跳，不写日志，依赖时钟
  • 支持权重

RootServer 的分布式选举时序分析

• 时钟误差最大未 Tdiff，网络网路传输单程

RootServer 的分布式选举周期分析

• 假设最大延迟 200ms，考虑到了跨大洲的问题

RootServer 的分布式选举时钟分析

多级 Lease 时间分析

• 多级 Lease : 上级 server 给下级 server 授予 lease
• 假设：
  • 第 i 层系统的 lease 时间为 L(i)
  • 最长不可服务时间未 D(i)
  • Lease renew 间隔为 T(i)
  • D(i) = L(i) + D(i-1)
  • 上级 server 宕机不影响下级 server 的 lease renew
  • 因此要求 D(i-1) <= L(i) - T(i)
  • Lease 时间越长宕机恢复时间越长，因此 D(i-1) = L(i) - T(i)

1.0 展望

• 扁平化系统设计
• multi-paxos 日志乱序同步
• paxos-group 成员变更
• paxos 测试框架
• 数据库水平拆分，动态分裂合并
• 两阶段提交与测试框架
• 分布式一致性读

OceanBase-支付宝交易O2O最佳实践

《OceanBase-支付宝交易O2O最佳实践》 - 师文汇/虞舜（阿里巴巴技术保障）

DBA 怎么使用 OB

• 疯狂双11 亿元
• 2010 - 9.36
• 2011 - 53
• 2012 - 191
• 2013 - 350.19
• 2014 - 571.14

一个事务可能需要做几十次 SQL，互联网一般是单条 SQL

visa 每秒钟 2 万笔交易

OB 简介

金融领域的挑战

• 屌丝理解：与经济相关的业务
• 卡类业务
• 保险类业务
• 理财业务
• 转账付款：
• 强一致

• 业务逻辑复杂

• 兴业银行 CTO 技术全是钱堆出来的
• 同城双中心，两地三中心
• 拉裸光纤，2个中心同时写

金融数据库的挑战

• 金融数据库需要具备什么
• 高可用&IDC容灾 - 两地三中心
• 数据强一致
• ACID/复杂事务
• 高性能
• 可扩展

实践

• 从支付宝交易的实际需求出发
• Paxos 协议强同步
• 单 IDC 故障 RPO 为 0
• 故障影响时间小于 35s
• 5% - 10% 灰度升级
• 随时回滚，30s 完成
• 秒延迟的数据流服务
• 自动化运维操作
• 逐步开放 IaaS 服务

支付宝交易业务介绍

• 蚂蚁集团
• 生活助手
• 无线业务
• 阿里集团
• 淘宝
• B2B
• 合作伙伴
• B2C
• 行业
• 交易
• 收费
• 营销
• 风控
• 余额，积分，红包，预存卡，信用卡支付，折扣劵。。。

交易 O2O 最佳实践

• 业务如何改造
• 如何保证质量
• 数据如何迁移 几百T的数据
• 灰度引流
• 高可用如何实现

去O最佳实践

• 业务改造
• 减少后续业务改造成本
• 通过中间件屏蔽DB差异
• 交易去O质量保证
• 中间层的“双写”验证
• OBTRADE的持续集成
• 数据迁移方案
• 零历史数据迁移的迁移方案
• why？
• 灰度引流的方案
• 原则：稳扎稳打逐步引流
• 辛德勒名单：吃自己的狗粮
• 0.01% - 1% - 10%
• 留好后路，随时回滚
• 数据一致性挑战
• 原理：业务上下层关联的对账
• 基于通知的实时数据对账
• 小时级别的全量数据对账
• 一致性问题的应急处理方案
• 性能优化&分析

支付宝交易双十一

• 双十一准备
• 全链路性能压测
• 完善的异常方案秒级生效
• 数据一致性实时监控

• 淡定的迎接双十一

• Oracle RT短4ms，抖动

• OB 吞吐量2-3倍，RT平稳，成本较低

• 推动 OB 在核心金融业务的落地
• 推进 OB 生态体系的完善

• 为去 IOE积累了丰富的经验和产品

• 有丰富的场景
• 有创新的想法
• 有一群给力的小伙伴

comments powered by Disqus