支付宝核心会计到甲骨文实践.pptx

2021年1月汇报人：支付宝核心会计到甲骨文实践账务的数据和特性分布式事 务账户余额资金明细账户资金更新热点极高并发要求数据丢失零容忍数据错误零容忍极高稳定性要求数据层架构选型策略业务要求技术能力性能伸缩性稳 定 性 要 求峰 值 要 求性 能 要 求写/ 读稳定性成本人的要求人员储备经验积累维护能力账务的技术架构演进(1)账务appMaster slave早期： IBM小型机，EMC高端存储，Oracle单库，一主一备账务的技术架构演进(2)cache账务appfailoverReadMasterSlave双11带来架构的演进：PC机，分库分表，Oracle dataguard，应用层failover账务的技术架构演进(3)CITY1CITY2IDC1IDC3IDC2IDC4MasterMasterMasterMasterReadReadReadRead全局复制LFO+RFOLFO+RFOLFO+RFOLFO+RFO同城容灾 异地容灾高可用带来的架构演进： 单元化，异地多活，同城容灾，异地容灾账务的技术架构演进(4)MASTER-CITY1(25%)CLOUD-CITY (50%)IDC1IDC2CLOUD- IDCCLOUD-IDCMASTER-CITY2(25%)IDC3IDC4双11每年翻番带来的架构演进： 弹性混合云架构，数据灵活扩容缩容业务推动数据层技术发展垂直拆分，水平拆分， 机房扩容，硬件更新容量每年双11容量需求翻番去IOE，采用廉价硬件， 自主技术成本IOE的成本压力支付宝的社会价值 RPO＝0，RTO接近0应用Failover，机房容 灾稳定性数据层架构如何进一步优化？伸缩性，稳定性如何进一步提升？2016年双11数据双11背后的数据库：OceanBase简介OceanBase的演进路径2016:1.x版本2014:0.5版本金融级 云数据 库2013:0.4版本金融级DB2010:0.1~0.3版本支持SQL第一个 用户账务OceanBase整体架构OceanBase最新性能数据insert.luaselect.luaoltp.lua三副本1,071,932(2.70ms/4.03ms)2,597,304(1.08ms/1.96ms)627,607 (57.34ms/96.51ms)CPU:lntel(R) Xeon(R) CPU E5-2682 v4 2.50Ghz 六 2 32 Core, 64 超线程Memory:512GB ( 16 六 32GB, 2133 MHz)NlC: 10Gb 六 2 机器共6台:3台运行OceanBase服务，3台运行客户端OceanBase的容量线性扩展无需分库分表 自动负载均衡 加机器即扩容扩容过程PC服务器 分布式，无共享，多副本OceanBase的高可用机制切换到OceanBase的常用方案切换前 切换后白名单1%流水型数据 多活模式主 写空OracleOceanBase可 写主 写OracleOceanBase状态型数据 双写模式主 写复 制OracleOceanBase复 制主 写OracleOceanBase切 换 力 度5%20%50%100%账务上OceanBase-原理ORACLEOceanBase1/100数据1/1000数据1/1w 1/1wA账户|余额|明细 B账户|余额|明细 C账户|余额|明细……1/1w1/1w1/1w1/1w1/1000数据1/1w 1/1w…………1停，2切，3写极低影响可双向切换完整性校验准实时镜像账务上OCEANBASE-实施账务APP 可靠消息 账务APP快照消息迁 移 前正常业务准实时全量余额数据OceanBaseOracle灰度切换账务APP账务APP可靠消息迁 移 中确认消息全被消化精细化监控OracleOceanBase余额数据双边完全一致稳定性兜底账务APP可靠消息账务APP迁 移 后快照消息正常业务Oracle准实时全量余额数据OceanBase***行业有限公司PPT格式，可编辑可复制感谢聆听