业务驱动的技术架构
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
B B
机房7
机房8
C C
D
B
E
C
B
C
机房9
F
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
机房1
F
Leader
城市2
Follower
机房2
机房3
机房4
A
E
D
F
E
D
ReadOnly
城市3
LogOnly
机房5
机房6
B
机房7
机房8
C
机房9
D
E
F
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
机房4
A
A
A
A
ReadOnly
城市3
LogOnly
机房5
机房6
B B
机房7
机房8
C C
B
C
B
C
机房9
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
B B
机房7
机房8
C C
机房9
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
F
E
D
机房4
A A
A
F
E
D
A
ReadOnly
机房1
机房2
机房3
F
E
D
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
B B
机房7
机房8
C C
机房9
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
F
E
D
2010年项目启动
2014年起宝支持支付 核心业务去Oracle
2017年服行务外部银 构建互联网金融核心
2018年发布2.0版本 直击金融业务架构转型痛点
OceanBase架构介绍
• 全对等节点的无共享分布 式数据库；
• 数据分区，多副本及 Paxos协议；
• OBProxy反向代理;
• 基于LSM Tree的存储结构；
OceanBase架构（一）
• 多副本：OceanBase一般部署为三个子集群 (Zone)，每个子集群(Zone)由多个节点/服务器 （OBServer）组成，拥有完整的一份数据；
• 全对等：每个节点均有自己的SQL引擎和存储引擎， 各自管理不同的数据分区，完全对等
• 无共享：OceanBase数据分布在各个节点上，不 基于任何共享存储结构
通过副本类型变更支持弹性大促
Leader
Follower
ReadOnly
LogOnly
Backup
• 主副本（Leader）：Paxos协议复制组中的主分区； • 从副本（Follower）：Paxos协议复制组中的从分区； • 只读副本（ReadOnly）：不参与Paxos协议投票，可提供读能力的分区； • 日志副本（LogOnly）：参与Paxos协议投票，但只包含日志（不含数据）的分区； • 备份副本（Backup）：不参与Paxos协议投票，仅仅从主从副本复制数据的分区；
通过全局索引解决多维度查询
下一代的OceanBase
Oracle兼容
计算存储分离
HTAP
• 反向代理功能
• 复杂场景支持
• 自动化运维
OceanBase架构（四）
业务的挑战
• 如何在业务高峰平滑扩容，高峰后如何缩容，甚至对业务无感知； • 如何去O，如何保证风险可控地去O； • 如何解决多活和异地容灾； • 如何备份分布式数据库，如何恢复到一个全局一致的时间点； • 如何规避分布式数据库的种种限制，如分区键和主键的绑定关系； • 如何解决非分区维度查询的问题； • 如何解决业务数据量膨胀之后的冷热数据问题；
业务驱动的技术架构 —OceanBase的实践与展望
大纲
1.关于OceanBase 2.OceanBase的架构介绍 3.来自业务的挑战和需求 4.OceanBase应对业务挑战的架构演进 5.展望：下一代的OceanBase
关于OceanBase
• 100%自主知识产权的国产数据库； • 商业数据库； • 通用关系型数据库； • 原生分布式数据库；
通过热备库解决异地容灾
通过热备库解决异地容灾
通过热备库解决异地容灾
通过备份恢复组件实现数据备份
通过备份恢复组件实现数据恢复
通过历史库平台实现冷热数据分离
解决在线库空间日渐紧张的问题，节约数据存储成本
通过数据转换服务实现去O
评估兼容性
PoC部署OB相关
预迁移部分数据
验证sql性能
正式迁移全量和 增量数据
校验以及订正
切换停应用
回滚反向切换 （可选）
性能诊断（可选）
通过GTS实现全局一致性
GTS（Global Time Service）
• OceanBase 内部每个租户启 动一个全局时间戳服务；
• 事务提交时通过本租户的时间 戳服务获取事务版本号，保证 全局的事务顺序；
• GTS同样采用三副本保证高可 用；
城市3
LogOnly
机房5
机房6
B
机房7
机房8
C
机房9
B
C
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
F
E
D
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
城市1
Leader
城市2
Follower
机房1
机房2
机房3
Fຫໍສະໝຸດ Baidu
E
D
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
B
机房7
机房8
C
B
C
机房9
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
OceanBase架构（二）
• 数据分区：OceanBase数据架构的基本 单元，是传统数据库的分区表在分布式 系统上的实现
• 高可用+强一致：多副本+Paxos协议， 保证数据（日志）写（持久化）到三台 机器中至少两台
OceanBase架构（三）
• OBProxy：百万级处理能力的代理， 路由转发，轻量级SQL Parser，无状 态
机房7
机房8
C C
D
B
E
C
B
C
机房9
F
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
机房1
F
Leader
城市2
Follower
机房2
机房3
机房4
A
E
D
F
E
D
ReadOnly
城市3
LogOnly
机房5
机房6
B
机房7
机房8
C
机房9
D
E
F
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
机房4
A
A
A
A
ReadOnly
城市3
LogOnly
机房5
机房6
B B
机房7
机房8
C C
B
C
B
C
机房9
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
B B
机房7
机房8
C C
机房9
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
F
E
D
机房4
A A
A
F
E
D
A
ReadOnly
机房1
机房2
机房3
F
E
D
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
B B
机房7
机房8
C C
机房9
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
F
E
D
2010年项目启动
2014年起宝支持支付 核心业务去Oracle
2017年服行务外部银 构建互联网金融核心
2018年发布2.0版本 直击金融业务架构转型痛点
OceanBase架构介绍
• 全对等节点的无共享分布 式数据库；
• 数据分区，多副本及 Paxos协议；
• OBProxy反向代理;
• 基于LSM Tree的存储结构；
OceanBase架构（一）
• 多副本：OceanBase一般部署为三个子集群 (Zone)，每个子集群(Zone)由多个节点/服务器 （OBServer）组成，拥有完整的一份数据；
• 全对等：每个节点均有自己的SQL引擎和存储引擎， 各自管理不同的数据分区，完全对等
• 无共享：OceanBase数据分布在各个节点上，不 基于任何共享存储结构
通过副本类型变更支持弹性大促
Leader
Follower
ReadOnly
LogOnly
Backup
• 主副本（Leader）：Paxos协议复制组中的主分区； • 从副本（Follower）：Paxos协议复制组中的从分区； • 只读副本（ReadOnly）：不参与Paxos协议投票，可提供读能力的分区； • 日志副本（LogOnly）：参与Paxos协议投票，但只包含日志（不含数据）的分区； • 备份副本（Backup）：不参与Paxos协议投票，仅仅从主从副本复制数据的分区；
通过全局索引解决多维度查询
下一代的OceanBase
Oracle兼容
计算存储分离
HTAP
• 反向代理功能
• 复杂场景支持
• 自动化运维
OceanBase架构（四）
业务的挑战
• 如何在业务高峰平滑扩容，高峰后如何缩容，甚至对业务无感知； • 如何去O，如何保证风险可控地去O； • 如何解决多活和异地容灾； • 如何备份分布式数据库，如何恢复到一个全局一致的时间点； • 如何规避分布式数据库的种种限制，如分区键和主键的绑定关系； • 如何解决非分区维度查询的问题； • 如何解决业务数据量膨胀之后的冷热数据问题；
业务驱动的技术架构 —OceanBase的实践与展望
大纲
1.关于OceanBase 2.OceanBase的架构介绍 3.来自业务的挑战和需求 4.OceanBase应对业务挑战的架构演进 5.展望：下一代的OceanBase
关于OceanBase
• 100%自主知识产权的国产数据库； • 商业数据库； • 通用关系型数据库； • 原生分布式数据库；
通过热备库解决异地容灾
通过热备库解决异地容灾
通过热备库解决异地容灾
通过备份恢复组件实现数据备份
通过备份恢复组件实现数据恢复
通过历史库平台实现冷热数据分离
解决在线库空间日渐紧张的问题，节约数据存储成本
通过数据转换服务实现去O
评估兼容性
PoC部署OB相关
预迁移部分数据
验证sql性能
正式迁移全量和 增量数据
校验以及订正
切换停应用
回滚反向切换 （可选）
性能诊断（可选）
通过GTS实现全局一致性
GTS（Global Time Service）
• OceanBase 内部每个租户启 动一个全局时间戳服务；
• 事务提交时通过本租户的时间 戳服务获取事务版本号，保证 全局的事务顺序；
• GTS同样采用三副本保证高可 用；
城市3
LogOnly
机房5
机房6
B
机房7
机房8
C
机房9
B
C
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
机房1
机房2
机房3
F
E
D
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
城市1
Leader
城市2
Follower
机房1
机房2
机房3
Fຫໍສະໝຸດ Baidu
E
D
机房4
A A
A
F
E
D
A
ReadOnly
城市3
LogOnly
机房5
机房6
B
机房7
机房8
C
B
C
机房9
D
B
E
C
F
B
C
机房2、3、5、7为云机房
支付宝的弹性大促
UID 00 UID 01 UID 02 UID 03
城市1
Leader
城市2
Follower
OceanBase架构（二）
• 数据分区：OceanBase数据架构的基本 单元，是传统数据库的分区表在分布式 系统上的实现
• 高可用+强一致：多副本+Paxos协议， 保证数据（日志）写（持久化）到三台 机器中至少两台
OceanBase架构（三）
• OBProxy：百万级处理能力的代理， 路由转发，轻量级SQL Parser，无状 态