共计 5762 个字符，预计需要花费 15 分钟才能阅读完成。
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
国泰产险自 2018 年以来业务开始高速增长，现平峰日均保单量达数千万级，顶峰日均保单量达亿级。面对财产保险场景化、碎片化特色，国泰产险最终抉择分布式数据库 OceanBase 并已安稳运行近 5 年。在此期间，国泰产险积极探索，在运维翻新与数据库迁徙等方面积淀了大量可借鉴的行业教训。3 月 25 日，2023 OceanBase 开发者大会在京召开， 国泰产险资深数据库专家舒明分享了《国泰产险的 OceanBase 上云实际》的主题演讲， 以下为演讲实录。
国泰产险于 2008 年在上海成立，迄今已在西北沿海和中西部地区 9 个省市设立 25 家分支机构。过来的 2022 年，全年保单数量达 57.8 亿单，保费规模达 53.8 亿元，累计服务客户达 3 亿人，并取得 2021 年中国金鼎奖“年度卓越财产保险公司”、2022 年“金理财”奖年度企业社会责任奖。
国泰产险互联网产品有两个比拟显著的特点：
一是场景化。 所谓场景化，就是在生存和工作中遇到的一些场景。例如以电商场景为代表的退货运费险，大家在淘宝、天猫等平台购买商品时商家赠送的退货运费险，很有可能就是咱们国泰产险的产品。这种产品特点体现在“小单”和“天量”，“小单”是指保费支出和保额较少，但绝对其余险种它的“天量”即数量十分大。像过来几年的“双 11”期间，国泰产险的退货运费险日保单量根本都在 1 亿以上。
二是碎片化。 国泰产险的产品笼罩生存场景中的很多碎片化需要，这类产品特点通常不能用一些通用的模型来解释，比拟偏定制化、个性化。例如大家给本人买的健康险、给宝宝买的“萌宝保”、给父母买的“孝顺保”等。国泰产险针对这些碎片化场景打造了 200+ 翻新产品，驱动业务高质量倒退。
面临多重挑战
基于国泰产险产品场景化、碎片化的特点，咱们在理论生产过程中遇到了一些业务和技术上的挑战。
▋ 挑战一：要求 7×24 小时全天候高可用
降级为互联网科技保险公司后，咱们的零碎要求 7×24 小时全天候提供服务，因为即便是在深夜也会有用户在淘宝、天猫等线上平台下单，进而同步购买咱们的各种产险产品，假如进行服务五分钟，都会给咱们带来间接的经济损失。而作为底层服务的数据库须要放弃更高的可用性。
▋ 挑战二：业务快速增长，分库分表逻辑简单
近年来，国泰产险在互联网平台上的保单数快速增长，数据库的单表数据量急剧收缩。这种状况下，咱们已经思考分库分表加历史数据归档，还对一些分库分表计划进行了选型，如通过第三方中间件，如间接本人写框架在程序层进行逻辑管制。但无论哪种计划，整体逻辑都会比较复杂且后续保护不不便。
▋ 挑战三：并发高，性能要求刻薄
每逢节假日、大促日，尤其是“双 11”期间，高并发的特色非常明显。像在大促日 24 点时，很多用户都守在 APP 前筹备集中下单，短期内成千上万甚至上亿的保单量，刹时流量十分大，对咱们的利用来说压力十分大。再加上保险业务的一个申请要通过承保前置、承保、合约、风控等链路，并且对链路上每个节点的运行晦涩度要求都十分高。所以咱们对数据库性能的要求能够说是十分刻薄的。
分布式数据库选型及成绩
为了晋升互联网化交付速度、麻利响应大规模业务需要，国泰产险信心全力打造保险中台，而保险中台的底层须要一款经验过海量数据考验的数据库做撑持。
一方面是基于打造保险中台的大背景，一方面是基于以上三点业务和技术上日益凸显的挑战，咱们开始进行大量的数据库调研工作，发现 OceanBase 有三个特点十分吸引咱们，也是咱们最终抉择握手 OceanBase 的次要起因。
特点一：高度兼容 MySQL 和 Oracle，无需分库分表。
OceanBase 高度兼容 MySQL 和 Oracle，对国泰产险现有的 SQL 代码无需额定改变，对开发人员十分敌对。针对数据量收缩的问题，咱们之前须要分库分表，当初只需通过表分区就能解决，无需额定进行繁冗的分库分表工作。
特点二：利用通明的程度扩大。
高并发下全链路压测 OceanBase 的性能十分优良，针对节假日、大促日等的高并发场景下，能进行疾速的扩容、疾速的缩容，并且对利用通明无感。
特点三：极致的高可用。
两地三核心、三地五核心等多机房的容灾能力，是咱们十分关注的。有多机房容灾的状况下，能力保证数据不论是产生机房级还是服务器级故障时都能疾速复原、能力保障在高并发写入状况下数据零失落。
得益于稳固牢靠的数据底座，咱们能更好更快地通过技术创新赋能业务增长。从 2018 年开始选型到正式上线，现在，OceanBase 曾经在国泰产险安稳运行近 5 年，并失去以下次要成绩：
- 高并发。 国泰产险的日均保单量级根本在数千万，在“双 11”期间有超高流量涌入，日均保单量超一亿。OceanBase 完满撑持了咱们一次又一次“双 11”日均保单量过亿级的业务申请，巅峰达 8.5 万次 TPS。
- 稳定性。 稳定性是金融行业选型数据库最看重的点之一，运行 OceanBase 多年来国泰产险整体实现 RTO<30s, RPO=0 的指标。即便硬件偶然呈现故障，OceanBase 的预警性能也能揭示咱们及时染指解决，咱们就能够把故障节点上的 Leader 租户切走，疾速替换再切回来。
- 多租户。 咱们将业务通过保障等级（高保、中保、低保）划分为不同的租户，租户之间处于硬件资源隔离、数据资源隔离的状态。如大促降临，国泰产险能够动静调整，优先把资源调给链路前端部门应答高并发流量。即便以后端正在高并发写入状况下，动静资源调整对利用也无感通明。
- 降本增效。 OceanBase 在降本增效这块体现地十分好，国泰产险的数据库综合老本升高 2/3，数据库性能整体晋升 20%。
运维翻新：1.X 版本基于零碎视图自建数据库平台
国泰产险接触 OceanBase 较早，咱们最先应用的是 1.X 版本，那时的运维体验并不像当初好。于是咱们基于 OceanBase 的零碎视图自建了一个数据库平台，次要蕴含三个模块：
模块一，监控。 监控十分重要，因为咱们必须要把握数据库以后的状态，包含各租户的资源状态。国泰产险的表的数据十分大，咱们精密统计到了所有表空间具体的值，将数据落库进行趋势展现，同时实时展现 CPU、内存等资源，不便运维人员和开发人员迅速剖析。
模块二，报警。 当数据库租户的资源产生报警时，运维人员须要及时地理解并染指。咱们基于视图做了资源报警，如 CPU 等资源报警；慢 SQL 报警，如报警以后执行的慢 SQL、超过不能承受范畴的慢 SQL，反映数据库的状态；还有应用层的异样表监控，保障整个零碎的稳固运行。此外，咱们还接入了钉钉进行及时的报警揭示。
模块三，慢 SQL 治理平台。 慢 SQL 的危害十分大，甚至会拖垮租户和集群造成大规模的利用超时。依据慢 SQL 产生的特点，咱们将整个过程分为事先、事中、预先三个阶段。
- 事先 Review SQL。 事先咱们会进行 DBA 的人工审核和程序卡点，双 Review 对立进行，争取在慢 SQL 上线之前就毁灭它。
- 事中抓取慢 SQL 落库。 慢 SQL 产生时，咱们首先会通过后面提到的报警模块先报警进去，而后把慢 SQL 通过抓取落到咱们自建的日志库。
- 预先造成工单流程跟踪优化。 预先咱们会对慢 SQL 进行整改，把聚合后的慢 SQL 进行荡涤、剖析、统计，最终造成一个工单流，派发给对应业务的开发人员。由开发人员和 DBA 双重角色保护，因为有时慢 SQL 不仅要从 SQL 层优化，还可能要从零碎层优化。
通过事先、事中、预先这三个阶段，国泰产险自建的慢 SQL 治理平台能对慢 SQL 进行全链路的跟踪、优化，直到它上线。
仅需半小时，1.x 版本平滑迁徙至 2.x 版本
数据库迁徙是很多行业尤其是金融行业感兴趣的话题，咱们破费了将近小半年的工夫进行迁徙工作，其中大部分工夫都在进行计划的论证与整顿，最终理论迁徙破费三个月的工夫，次要分为三个阶段。
▋ 第一阶段，前置工作。
首先进行 OMS（OceanBase Migration Service，OceanBase 数据迁徙工具）搭建。其次，进行账号权限梳理，有些账号曾经没有应用或者账号异样，咱们要趁这个机会进行对立梳理。而后环境初始化，跨域跨账号须要更多网络买通，以及各种数据库环境创立。最初，脏数据排查，从低版本到高版本有些数据可能对数据库来说是脏数据，咱们须要清理掉，例如，某些 datatime 值不兼容的问题，就能够提前更新并解决掉。
▋ 第二阶段，迁徙和灰度。
迁徙过程自身并不漫长，但国泰产险为了验证整个计划的稳定性和成熟度，将工夫拉长至 2～3 个月，通过工夫维度来验证计划的可行性。次要蕴含四个步骤：
步骤一，全量、增量迁徙。 咱们会将所有库表进行全量和增量的数据迁徙，能够在 OMS 里进行库表工作的工作配置。
步骤二，数据一致性校验。 这是迁徙的重中之重，咱们十分关怀迁徙前后的数据是否统一。针对一致性校验，OceanBase 提供数据校验的性能，如果发现数据不统一会显示进去。作为金融行业，国泰产险对数据一致性的要求十分高，所以咱们还自建了一个校验数据一致性的小工具，监控这些表的同步状况，双保底计划验证迁徙前后的数据一致性，确保源端和目标端的数据一致性。
步骤三，差别数据处理。 如果真正在迁徙过程中发现数据不统一怎么解决？针对差别数据，依据理论状况具体问题具体分析，判断是抉择从新同步这张表，还是在指标端进行相干操作。例如，惟一索引的问题，若在晚期版本中建了惟一索引，尽管有反复数据会建失败，但还是建了，但在迁徙过程中先建惟一索引的话，反复数据写入就会报错。
步骤四，利用灰度切流。 最初是局部利用的切流，咱们将利用的查问申请打到新的 OceanBase 集群，把 OceanBase 当成一个热备，通过只读场景去验证新集群的整个性能是否有问题。
▋ 第三阶段，切换和验证。
做了这么多前置工作，第三阶段相当于最初的临门一脚。在整个切换过程中十分顺利、顺滑。那天早晨咱们 8 点开始，8 点 30 根本就完结，大略继续不到半个小时即切换胜利，这里分享一下咱们过后做的具体工作。
工作一，利用限流。 咱们对利用做了一个零碎的开关，将利用进行限流后，对底层数据库的申请绝对比拟少，压力也就比拟小。 工作二，OceanBase 源端禁写。 咱们通过批改参数把 OceanBase 源端进行禁写，尽可能保障源端和目标端的数据一致性。 工作三，对立切换配置。 咱们写了一个脚本，能够批量批改数据源的配置，使其连贯到新的数据源。 工作四，利用验证复原。 咱们把所有利用启起来进行性能验证，复原流量后进行最终验证。
整个过程花了不到半个小时，这得益于咱们后面进行的大量的重复演练，不必大家蹲守到中午公布，这对运维人员来说是十分好的体验。
云上数据库运维实际
上云 OceanBase 后，DBA 能显著地感触到运维效率晋升。
一是监控报警， 根底运维工作能够配置报警规定，关怀哪些参数能够及时报警进去； 二是可视化运维操作， 咱们能够将切可用区、被动发动备份等操作间接在白屏进行，绝对稳固平安，不必黑屏做这件事。
三是灾备零碎欠缺， 咱们之前须要通过写脚本进行备份和复原，当初通过页面化的性能来配置即可实现； 四是反对数据传输， 不仅反对集群间的数据传输，还反对通过 OMS 传输至国泰产险的数仓进行离线 / 在线剖析等。
▋ 全生命周期治理数据安全
金融行业对数据安全非常重视，随着数据成为生产因素，各行各业对数据安全的器重水平基本上都是只增不减。咱们把数据从生产到销毁稀释成三个阶段：传输、存储、应用。
在传输层通过 SSL 链路加密且进行严格的拜访白名单管制。在存储层进行 TDE 加密，对一些敏感数据进行加密存储。在应用层针对人工查问拜访数据库的申请，咱们对立收口到数据管理平台，在外面进行敏感数据爱护的设置，做权限管制和操作等级的设置等。这样就在全生命周期的各个环节加固数据安全。
▋ 玩转云上 OceanBase 精细化运维
上云之后，很多根底运维工作的确被代替了，这个置信大家也深知，咱们也没什么好避讳的。但不代表 DBA 没有事件可做了，我集体应答云数据库时代的计划是——走近业务，贴近业务实现 DBA 的价值。
首先，在架构治理上。 有些业务创立上线的时候，不能很好地辨认业务的保障等级，业务推动过程中能力辨认，因而须要进行高 / 低保租户隔离的动作，防止低保障的利用影响高保障的利用。
当一个新业务上线时，开发 leader 个别无奈精确预估该业务将来会有多大的流量，分配资源也是依照以后该业务合乎的资源，须要 DBA 前期经营。那国泰产险是怎么做的？咱们把资源应用状况通过 API 拉到近数月、一个月、一周的数据，通过数据分析该资源的使用率。如果这个月的使用率不到 20%，其已分配资源就该被动静调整。
其次，降本增效上。 原来，国泰产险的表压缩比不是很高，咱们继续在更改一些表的压缩格局，转成一个更低的压缩比。此外，业务每天的全链路很多，每个节点每天的数据量都会有一两千万的增长，对于整个 OceanBase 的存储压力十分大，于是咱们自建了一个数据库清理归档平台，把这些大表做了一个数据大盘，每张表的数据量、存储状况以及最近的增长状况高深莫测。依据数据分析推动开发进行配置删除策略，这些策略集成在平台中，能够按产品、工夫等多维度进行归档。
对于金融行业，备份必须要做，但异地备份的性价比不是很高，除非真正产生大故障，否则很少去做。大家能够思考把异地备份转归档存储，同时还能够升高应用老本。
最初，SQL 治理上。 一是可疑 SQL 展现与限流，如果某个 SQL 的确比较慢或性能不太好，咱们能够针对它进行限流，间接在页面上配置即可；二是全量 SQL 审计，当咱们线上呈现不明 SQL，能够在页面上开启审计开关，找到 SQL 是从哪里来的？是否是外部执行等；三是索引倡议，OceanBase 能够提供索引倡议供 DBA 参考，进行相应的 SQL 优化；四是慢 SQL 工单流，基于上述提到的国泰产险自建的平台，不便咱们与开发同学一起优化慢 SQL。
总之，真正迁徙到云上的 OceanBase 后，DBA 对于数据库运维的整体效率晋升，感触非常明显。咱们能够更多地聚焦 SQL 治理、数据架构治理、数据安全等工作，更多地开发配套的提效降费工具，而不是将工夫节约在反复而又繁冗的根底运维工作上。我明天的分享就到这里，心愿能对大家有所帮忙，谢谢大家！
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
