2014 Alibaba Tech OceanBase Note

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