聊聊OceanBase数据库开发和运维漫谈（下）2023/7/10 3:33:17

2023-7-10 03:33| 发布者: 天若有情| 查看: 43| 评论: 0

摘要: 　　摘要：本文是面向初次接触OceanBase数据库的开发和运维人员，介绍OceanBase数据库的直观特点（所以没有高大上的理论和复杂的技术细节）。然后再以一个实际问题为引子，逐步展现OceanBase数据库的独特魅力。兼容o ...

　　摘要：本文是面向初次接触OceanBase数据库的开发和运维人员，介绍OceanBase数据库的直观特点（所以没有高大上的理论和复杂的技术细节）。然后再以一个实际问题为引子，逐步展现OceanBase数据库的独特魅力。兼容oracle的数据库https://www.oceanbase.com/solution/database-migrationoceanbase，完全自主研发的原生分布式数据库，连续年稳定支撑双，创新推出“三地五中心”城市级容灾新标准，一套引擎同时支持tp和ap的混合负载，具备数据强一致，高扩展，高可用，高性价比，高度兼容oracle/mysql等特性，已助力+行业客户实现关键业务系统升级。

　　OceanBase数据库开发和运维漫谈（上）

　　数据拆分通常有两种做法一是使用分区拆分。如Oracle 12c的sharding、OceanBase的分区表等。二是使用分库分表。通过分布式数据库中间件来做。如阿里云的DRDS、腾讯的TDSQL。业界还有一个做法稍有不同就是拆分为比分区更细的粒度。如TiDB数据拆分为一定大小的Region。

　　分区的特点是所有分区在数据库内部是有内在联系的有强约束。比如说分区的结构要一致、可能有全局约束逻辑、要有全局索引等。分表的特点就是站数据库角度都是独立的表彼此没有内在联系。分表之间的联系由中间件去维护使得它适合做灰度表结构变更。

　　做数据拆分会面临一些共同的问题根据问题的范围选择在何种层面去解决。

　　5.1 分布式事务

　　一个事务多个SQL读写多个表时其分区的Leader副本可能在多个节点上这个事务的ACID就不能靠本机事务保证了。OceanBase支持分布式事务使用XA协议是强一致。不同于分布式事务中间件产品常用的最终一致的解决思路。

　　分布式事务的性能会比本机事务性能差一点。所以在表设计上首先应该能通过表分组TableGroup技术尽可能的避免有业务联系的表的分区分布在不同节点上。这是第一层保证。当业务规模非常大的时候数据量和访问量都很大远超出单台OBServer的能力时则只能尽量将有业务联系的表的分区的Leader副本约束在同一个机房Zone。这样依然可以依靠OceanBase的分布事务去解决。

　　至此这些数据还是在一个租户里。当业务规模大到那种把所有数据放在一个租户里风险很大的时候在应用层就要设计数据拆分先拆分到多个租户里那就需要借助中间件的分库分表能力。由于OceanBase原生的分布式事务不能跨租户。所以这个时候的分布式事务就要借助中间件的能力。通常就是用TCC实现最终一致或者用XA实现强一致。OceanBase可以为此做的事情就是利用将有业务联系的分表的Leader副本约束在同一个机房Zone或机器OBServer里让中间件层的分布式事务少发生跨机房调用。

　　5.2 全局一致性快照

　　上面OceanBase的分布式事务在1.x版本里有个缺陷。当一个SQL读取或者修改多个分区并且这些分区跨节点的时候OceanBase 1.x是不支持的会提示“strong consistency across distributed node not supported”。这是因为还不支持全局一致性快照。这样的SQL隐含要求是如果访问的数据在多个节点这些数据必须是来自于同一个时间点之前含已提交的数据。要实现这个要求需要有一个全局的时钟。Google Spanner是通过硬件原子钟和API实现。实现这个的目前还有TiDB。DRDS和TDSQL只是在server节点将各个db节点返回的数据做聚合处理直接忽略了一致性要求。

　　OceanBase 2.x版本将会在内部用软件实现一个全局时钟解决全局一致性快照难题。所以硬件层面所有OceanBase机器的时间必须使用同一NTP源。彼此误差不能超过50ms。这点对IDC来说应该是基本要求。

　　所以这个全局一致性快照只能在数据库内核层面解决。如果是使用分布式数据库中间件的话做这个就不容易了。这点供拆分决策参考。

　　5.3 多活和单元化

　　多活通常说的是同城双活或者异地多活等。应用只要稍作一些服务化拆分支持集群化部署集群节点都是无状态的很容易就可以实现多活部署。难的是数据库支持多活。OceanBase是很适合做数据库多活能支持不同层次的多活不过需要应用一起设计。

　　当使用分区的方式拆分时OceanBase把相同租户的很多分区的Leader副本分散在多个Zone或者把不同租户的很多分区的Leader副本分散在多个Zone。只有Leader副本才能提供写入能力Follower副本不能。这种效果是多个Zone机房都有写入但是写入的是不同的表或者分区Partition。这是初级的多活离业务的需求还有点距离。

　　业务想的是两个机房都能写入相同的表。但是也必须是不同的数据否则就双写冲突了双写的危害就是数据被覆盖难以追回。这是讨论多活的前提。

　　要满足业务这个需求仅靠数据库是不够的。业务必须做顶层的拆分设计。即将业务数据能按照某个维度拆分最好的是按用户拆分然后不同的用户可以在不同的机房读取和写入数据这才是业务要的多活。这种拆分设计又叫单元化设计。如果业务做不了这种拆分还要求多活就是一种奢想。

　　实现方法是用户请求应用时在域名解析层面就能够按某种策略将用户引导到相应地区应用的接入层。然后后面用户所有的请求都可以在本地区完成。理想的单元化设计就是用户所有的操作都可以在该单元地区内完成。现实会有点差距总有些业务数据不适合按用户拆分。比如说商品数据、库存数据等。这些数据的写请求只能集中在某一单元这种跨单元的访问也是不可避免的。要支持单元化数据库设计还要做分库分表配合。业务数据按用户ID拆分到多个分表里不同分表的Leader副本设置到不同的机房这样做到业务层面多个机房同时写入同类业务表只是写入的分表不同这也是一种多活形态。蚂蚁选择的是这一形态。

　　当然多活做得更彻底的就是阿里电商的基于MySQL的分布式数据库单元化设计。异地之间的MySQL彼此没有内在联系通过外在同步工具DTS做数据同步异地之间可以同时读写相同的分表只是读写的数据是属于不同用户的。这就要求应用顶层流量分发和接入层要严格保证用户请求访问正确否则很容易导致双写。此外DTS同步不保证强一致可能有延时所以同步的时候会有实时增量比对源和目的端数据并且每晚还有一次全量校验。

　　在流量切换的时候应用层面还要通过“禁止更新”和“禁止读写”一些策略保护同步中的数据不会出现双写。

　　OceanBase的基本特点简单总结就是分布式、弹性扩展、高可用强一致。OceanBase里的Zone是逻辑划分实际一个Zone由部署决定。小至一个机柜大至一个机房。运维可以根据业务需求搭建合适模式的OceanBase集群。需求不同部署模式就不同。下面简单介绍OceanBase各种部署形态。

　　6.1 单机房三副本部署

　　? 部署说明就是三个Zone放在单机房内。建议放在不同的房间或者机柜下以及不同的交换机下。

　　? 场景说明生产环境使用意义不大不能抵抗单机房不可用故障。开发测试环境可用。

　　6.2 同城三机房部署

　　? 部署说明同城多个核心机房延迟一般在0.5 ~ 2ms之间

　　? 场景说明同城多机房容灾。很少有客户有第三个机房可以租用一个运营商机房或者公有云机器专门存放日志副本不包含数据所以没有丢数据的风险。不能抵抗同城整体不可用比如说城市大规模断电断网、地震或海啸等天灾。

　　6.3 两地三中心部署

　　? 部署说明主业务所在城市或者可靠性相对高的城市部署双机房异地部署一个机房。如果深圳挂了一个机器或者机房则事务提交延时会因为异地请求投票而多30ms。

　　? 场景说明同城单机房容灾有高可用有异地灾备。容灾时应用性能会下降。不能抵抗同城整体不可用。

　　6.4 两地三中心五副本部署

　　? 部署说明是上面两地三中心三副本升级版。可以容忍同城单机房的机器不可用性能无损耗。单机房挂掉后性能会下降。但是可以立即从五副本降级为三副本模式性能就会恢复。

　　? 场景说明同城双机房容灾不能抵抗同城整体不可用。

　　6.5 三地三中心五副本部署

　　? 部署说明上面的升级版。可以容忍单机房不可用和单个城市不可用。单个城市不可用的适合应用性能会有下降可以立即从五副本降级为三副本应用性能恢复。

　　? 场景说明有高可用、有容灾、城市容灾。

　　6.6 三地三中心五副本容灾及多活、读写分离部署

　　? 部署说明容灾就不用说了。多活方面业务分库分表OceanBase有多个集群多个租户不同租户的Primary Zone和切换备用Zone不同。多个机房同时写入。同时部分机房部署了只读副本专门提供读服务给某些查询量大的业务业务能容忍查询有些许延时。

　　? 场景说明满足拆分、容灾、多活、读写分离场景。

　　7.1 学习资源

　　OceanBase官网地址https://oceanbase.alipay.com/ 上面有公开的技术文档。文档体系目前还显得有点乱和不够丰满产品团队在设法完善中。

　　7.2 对外输出

　　OceanBase目前支持独立部署输出和通过专有云输出。

　　独立部署时客户只需要提供机器即可。通过专有云输出时客户需要使用云的基础设施阿里云的飞天或者蚂蚁金融云。如果需要合作可以联系阿里云或者金融云的业务拓展专家、或者在群内联系OceanBase服务组人员。

　　OceanBase是蚂蚁金服完全自主研发的分布式关系数据库目标是做一个通用型的分布式数据库。OceanBase基本兼容MySQL常用SQL部分兼容Oracle后续会兼容Oracle更多常用功能如存储过程、游标等。

　　OceanBase是分布式架构可以弹性扩展能自动做故障切换并且不丢一点数据非常适合做异地容灾/多活等。

　　本文作者：mq4096

　　原文链接

　　更多技术干货敬请关注云栖社区知乎机构号：阿里云云栖社区 - 知乎

　　本文为云栖社区原创内容，未经允许不得转载。