共计 2979 个字符，预计需要花费 8 分钟才能阅读完成。
自从证监会公布《客户交易结算资金治理方法》以来，券商的次要经营方式由网点营业部模式变动为总部集中模式，在集中交易系统的建设背景下，关系型数据库的重要性更加突出，以 Oracle、DB2 为代表的数据库产品简直占据了整个券商的各类外围业务零碎。
证券基金行业的外围零碎整体上可分为两类，一类是以股票交易为核心的在线类业务，另一类是以基金 / 资管为核心的“T + 1”业务。对于数据库而言，前者强调极致的低提早与高可用；后者则通常波及批处理、大事务、简单查问、备份复原，对数据库的综合能力有较高要求。
本文重点形容近年来在基金 / 资管场景下，OceanBase 整体解决方案与落地实际。
基金资管的业务架构与数据库实际
业务模型
典型的资管场景业务架构如下：
对客查问零碎：终端用户通过券商 / 基金的直销渠道或互联网分销渠道执行买入、卖出、查问等申请；
TA 注销过户零碎：注销用户交易申请，在每笔交易链路中，依据资产估值计算用户的理论买入份额与卖出金额；在用户与交易两个维度进行批处理；
估值零碎：计算资产的净值、利息收入，资产维度批处理；
投资交易系统：交易外围账务解决；高并发低提早，满足 ACID；
投资剖析零碎：统计分析，包含大量大事务，简单查问。
容灾要求
- 机房切换演练：
在线类交易业务对业务连续性有较高的要求，以银行外围做比照，产生劫难时，银行账务外围需优先保 RPO，确保数据统一，在此前提下，能承受肯定工夫的零碎不可用；而证券外围交易系统须要优先确保业务可用，其交易期间的零碎不可用损失往往以秒为单位计算。因而证券行业须要定期做各类高可用切换演练。
- 疾速数据恢复：
T+1 类交易业务则对数据一致性有较高要求，一旦跑批呈现谬误，须要将数据恢复到某个工夫点进行重跑，同时须要在跑批工夫窗口实现批量工作，因而一方面须要跑批稳固，尽量不出错，一旦出错还须要数据能牢靠且疾速地实现工夫点复原。
针对业务模型的数据库计划实际
- 对客查问零碎：
在自有销售渠道预期增长的背景下，为了撑持将来高并发场景，局部头部企业开始专库专用，将对客查问模块从数仓平台中抽出，独自运行在分布式关系型数据库。
资管零碎的对客查问模块，尽管 SQL 根本都带有“用户 ID”这类信息作为等值条件，但其 SQL 往往不是简略的点查，而是带有去重排序等各类计算以及多表 join 的中等简单 SQL。在此状况下，OceanBase 的分区表 +TableGroup+ 复制表可尽量将 join 中的雷同数据放在同一个节点，缩小分布式系统下带来的跨机 RPC 申请，同时 OceanBase 的一体化设计能尽量避免计算过程中的数据 merge。综合多方面个性，OceanBase 在此类场景下可能提供高并发低提早的查问能力。
对于写入负载，若数据来源于数仓平台，倡议在数仓平台实现数据进行荡涤后再导入；若抉择间接在对客查问零碎进行数据荡涤，则倡议管制事务尺寸，尽量避免一条 SQL 解决一整段工夫的数据（如一个月），只管 OceanBase 3.X 曾经反对大事务，但为了放弃零碎继续久远运行的健壮性，倡议固定事务尺寸，否则随业务增长，按工夫维度的事务大小也将持续增长，在达到临界点后，还是须要回头调整业务逻辑。
- TA 注销过户零碎：
引入分布式数据库并且借助其可扩展性，可在放弃业务架构不变的状况下，较好应答将来基金用户数、交易数大幅晋升的需要。
该零碎波及用户记录与交易记录两个维度，同时局部清理必须以串行形式实现，因而架构上较好计划是单元化，行将业务拆分为若干个可能独立实现要害业务流程的数据单元，单元之间防止 DB 间的交互，将不同业务单元以租户或用户维度进行部署，并将其主节点置于不同主机，从而晋升整体批处理效率并且保障硬件资源利用率。
在每个单元内，须要确保其数据绝对平均并且执行效率相当，因为零碎整体的解决工夫实质上就是最初一个单元实现清理的工夫，这须要数据库具备良好的租户资源隔离能力。
绝对于分片单元而言的是汇聚单元，汇聚单元内有所有的数据，负责承载全局剖析类负载，这须要数据库具备良好的 AP/TP 负载隔离能力。
- 估值零碎：
该零碎只波及资金维度，其批处理逻辑较为简单，通过热点大表分区 +TableGroup，可将负载均匀分布到各个节点，达到较高的性能成果，以后 Oracle 生产环境运行在一套高配 Oracle 数据库中，跑批工夫在小时级别，高峰期 CPU 达到满负荷，OceanBase 采纳了比生产多一倍的数据进行跑批压测，在国产芯片的 2-2-2 集群环境中，可在 6 分钟内实现。
- 投资剖析零碎：
线上常见的问题是偶发的执行打算走错，导致简单查问 SQL 工夫变长，该问题在 Oracle 数据库也是常见的影响性能的因素之一，OceanBase 反对通过 HINT 来形容具体如何固定打算，并具备绑定执行打算的能力，更进一步，以后 OCP 3.2.1 版本已反对白屏绑定历史执行打算。
对于上述场景，若该 SQL 在执行打算变动之前始终运行失常，则可找到以前失常的执行打算，若定位后发现根本原因的确是执行打算扭转，则可间接一键绑定历史执行打算。该能力大大降低了线上环境简单 SQL 打算调优的操作危险与复杂度。
除此之外，简单剖析 SQL 往往大量运行在 PL 环境中，业务逻辑均在存储过程、函数、匿名块中，数据库自身对 PL 语言的反对水平也决定了业务迁徙革新的施行难度，OceanBase 能兼容 PL 的根本常见语法，在该我的项目中，原运行在 Oracle 的 PL 代码简直没有做业务逻辑批改。
数据库部署架构
- 集群内高可用能力：
OceanBase 集群在同机房内部署，其提供的高可用能力与成果可认为是一组节点扩大能力下限更高、没有存储单点危险的 Oracle RAC：无需人工或内部工具参加的主动故障转移、多节点多活提供服务、增加节点即可实现资源主动扩大。OceanBase 基于 Paxos 多数派共识协定的高可用底座经验了阿里巴巴 / 蚂蚁团体“双十一”级别的负载考验，而 TableGroup、集群内负载平衡等日常运维伎俩也都依赖于高可用切主，因而能够认为集群内高可用曾经是成熟稳固的能力，可无效抵挡基础设施计划外故障导致的业务中断。
- 集群间高可用能力：
基于多数派共识的高可用协定对于双机房场景无奈无效抵挡危险，若将多数派节点搁置在主机房，则主机房故障就无奈提供服务；若将多数派搁置在备机房，对于主机房而言，其具备了故障转移的能力，但若备机房故障，主机房可用性将受到影响，零碎整体可用性没有本质晋升，在没有同城三机房的条件下，若要借助集群内高可用能力实现“双活”级别可用性，则至多须要引入第三机房寄存日志正本做 Paxos 投票。
在此背景下，OceanBase 提供了集群级别的主备能力，针对双机房场景提供机房级别高可用能力。对于机房切换演练，带生产数据进行切换演练时，可通过 switchover 将主备集群的角色调换，演练完结后业务负载回到主机房，数据库侧则再次执行 switchover。不带生产数据做演练时，则将第二备集群与主集群解耦，让其独立为一个独自的集群，测试数据运行完后，重建该备集群。
相比耳熟能详的单机数据库，OceanBase 在开发应用、运维治理方面还不足够被宽广技术人员熟知，同时产品架构与性能细节也在继续迭代。泛滥外围业务的胜利上线离不开客户与合作伙伴的信赖，OceanBase 也将以解决实在业务场景难题作为方向，一直晋升产品能力，用技术让数据的治理和应用更简略。
