从数据库到业务系统：oceanbase 在证券业的实践与影响-c7电子娱乐
*文章来自转发 原创作者：刘欢 恒生light dba club
一、引言
在证券业务系统中，数据库架构设计至关重要，它对于数据的存储、管理和处理起着关键作用。
oceanbase原生的分布式数据库系统，能否为金融业务系统的可靠性、扩展性和性能提供有力支持？
我们将探讨oceanbase数据库架构设计与证券业务系统结合的可能性。
二、技术解读
首先，我们来了解一下oceanbase的数据库架构设计。
oceanbase采用分布式多租户架构，具有高度的可扩展性和稳定性，这种设计使得oceanbase能够轻松应对大规模的数据存储和管理需求。
同时，oceanbase还采用了自主研发的存储引擎，具有高性能、低延迟的特点，为金融业务系统的运行提供了强大的支持。
原生分布式多租户架构
集群由多个zone组成，每个zone可以包含多个物理节点，多个物理节点组成资源池；租户在一定程度上相当于传统数据库的"实例"概念，是资源分配的单位，是数据库对象管理和资源管理的基础。
在数据安全方面，oceanbase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险。
在资源使用方面，oceanbase 数据库表现为租户"独占"其资源配额。总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（cpu、memory、io 等）的容器。
高可用能力
oceanbase 数据库作为一款原生的分布式数据库能够对外提供一致的、高可用的数据服务。oceanbase 数据库的事务一致性，存储持久化保证在出现 observer 退出重启情况下能够恢复到重启前相同的数据和状态。另外，oceanbase 数据库的备份恢复、主备库c7电子娱乐的解决方案也保证了在不同场景下 oceanbase数据库的高可用能力。
分布式选举
oceanbase 数据库的选举模块保证选举出唯一的主副本对外提供数据服务。同时，通过 paxos 协议实现了多数派 clog 强一致同步持久化，在 paxos 组中任意少数派副本发生故障的情况下，剩下的多数派副本都能保证有最新的clog，因此就能避免个别硬件故障带来的数据损失，保证了数据可靠性。
clog 及存储引擎
oceanbase 数据库的存储引擎将基线数据保存在 sstable，增量数据保存在 memtable 中。oceanbase clog 是数据的 redo log。当有数据修改发生时，请求会到达 leader 副本所在节点，将数据更改请求更新到 memtable，事务进行提交，leader 更新本地 clog 并通过 paxos 协议将日志同步写到其他 follower 的副本节点上。当有多数派节点的日志写盘成功后，数据修改成功，返回客户端。follower 副本会将 clog 回放到本地 memtable 上提供弱一致读服务。
当 oceanbase 数据库由于故障（软件退出、异常重启、断电、机器故障等）重启或者计划内停机维护重启时，observer 能够在启动中恢复，将 observer store 目录下的日志和数据还原到内存中，将进程的状态恢复到宕机前的状态。如果多数派副本故障并需要重启，数据服务会发生中断，oceanbase 数据库保证在多数派宕机重启后数据可以完全恢复到宕机之前。
备份恢复
oceanbase提供物理备份功能，实现全量、增量备份，当 oceanbase 数据库出现数据损坏、节点 crash 或者集群故障，oceanbase 数据库可以从备份的基线数据和 clog 备份中恢复。
主备库
主备库也被称为主备集群，类似于传统oracle的adg。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（rpo = 0）和有损切换（rpo > 0）两种容灾能力。oceanbase 数据库支持创建、维护、管理和监控一个或多个备集群。
异地多活
利用 oceanbase 的多地多副本架构，以及高效的 paxos 一致性协议工程实现，将数据库集群进行“三地五中心”部署，数据副本分别存储在同城和异地，实现异地容灾。在“三地五中心”架构下，oceanbase 可以实现单元化部署，配合应用微服务中间件，实现单个业务单元发生故障后，业务影响爆炸半径最低可降至 1%，并且即使遇到城市级故障也能在 1 分钟内自动恢复，同时保证零数据丢失。
高可用设计
基于分布式架构，oceanbase的高可用设计基本思路为：将多个副本（节点）分散到多个机房、多个城市中，通过跨机房/跨城市实现paxos group。
通用部署方案如下：
数据压缩
oceanbase 数据库的高级压缩功能采用全新设计的行列混合存储结构，以及高效的数据编码技术与一系列综合的数据压缩算法结合的方法，实现了在使用相同后端进行压缩的场景下，存储空间大幅减少。其压缩方式主要分为通用压缩与数据编码压缩。
通用压缩：在压缩算法对数据内部的结构没有了解的情况下，直接对数据块进行压缩。这种压缩往往是根据二进制数据的特征进行编码来减少存储数据的冗余，并且压缩后的数据不能随机访问，压缩和解压都要以整个数据块为单位进行。对数据块的压缩，oceanbase 数据库支持 zlib、snappy、lz4 和 zstd 四种压缩算法，zstd 和 lz4 的压缩等级是 1，zlib 的压缩等级为 6，snappy 使用默认的压缩等级。
在 mysql 模式下，支持用户指定单独选择 zlib、snappy、lz4 或 zstd 压缩算法；在 oracle 模式下，兼容 oracle 数据库的压缩选项，仅支持用户选择 lz4 或 zstd 的压缩算法。
数据编码压缩：oceanbase 数据库自研了一套对数据库进行行列混存编码的压缩方法（encoding）。和通用压缩不同，encoding 建立在压缩算法感知数据块内部数据的格式和语义的基础上。oceanbase 数据库是一个关系型数据库，数据是以表的形式来组织的，表中的每一列都有固定的类型，这就保证了同一列数据在逻辑上存在着一定的相似性；而且在一些场景下，业务的表中相邻的行之间数据也可能会更相似，所以如果将数据按列进行压缩并存储在一起就可以带来更好的压缩效果。
根据uf3.0实际生产环境，在oracle数据库中，通过查询dba_segments视图，统计hs_cqs用户数据量约为570g；全量迁移至ob-oracle租户后，hs_cqs用户数据量查询结果约为100g。压缩比约为 5.7:1。
针对oceanbase-mysql租户，我们进行了实测：
可以看到对于不同的表，oceanbase的数据压缩比也不同。综合来看，平均压缩比约为 4.71:1。
数据审计与加密
数据加密和访问控制可以大幅降低安全风险，但对于具备权限的用户，仍然需要记录其操作，以防止用户登录信息泄露，或者访问权限被滥用。审计功能可以加强企业对数据安全、合规等方面的要求，是跟踪用户行为最主要的工具。
oceanbase支持白屏化查看近期对主机、oceanbase集群、obproxy 集群、租户、备份恢复和平台用户的操作记录，包括：事件类型、事件操作、资源名、事件信息、操作人、执行时间和执行结果的内容。
oceanbase能够实现数据传输加密、数据存储加密。
数据传输加密：oceanbase数据库在原有的 tcp 通信上扩展支持 ssl/tls 协议，解决通信加密的问题。
数据存储加密：oceanbase数据在写入存储设备前自动进行加密，读取时自动解密，该过程对用户是透明的，黑客和恶意用户无法从数据文件、数据库备份或磁盘中读取到敏感数据。
三、证券业务系统实践
券商数字化时代全面开启，在新形势下，行业规则不断变化，业务创新在争分夺秒，精细化服务客户成为了重中之重。传统烟囱式、系统紧耦、信息分裂的系统架构已经无法适应当前业务发展。
恒生新一代证券业务系统与原生分布式oceanbase数据库是否能够做到紧密结合？我们接着往下看。
核心交易系统uf3.0
新一代的核心交易系统uf3.0，是支持券商财富管理转型的整体it支持平台，提供全业务、全功能的综合金融服务。
uf3.0是一站式经纪业务平台，在技术架构、系统解耦、业务设计、接口易用性、性能等方面全面重构，具备“高容量、大并发、低时延、高性能”的特点，同时具备水平扩展、松耦合、组件化、快速迭代、灰度发布、弹性资源等特性。
uf3.0采用分布式微服务架构进行建设，实现了交易、清算、管理的三分离，专业化分工，支持7*24小时业务，高效、稳定、扩展性强。中间件支持无限扩展，从容应对万亿行情，超千万级客户的交易、清算等高效处理。
从以上几点来看，uf3.0业务系统与oceanbase数据库的设计具有相通性。
uf3.0与oceanbase
架构设计
整体架构设计如下所示：
在oceanbase数据库架构设计方面，
对于ob集群
1、从高可用容灾角度考虑
一般采用两地三中心五副本 异地备库的模式，如下：
● 实现机房级高可用，异地备库提供城市级容灾；
● 应用对称部署在同城两个机房，实现业务与数据库的双活；
● 机房1故障后，可以通过降副本操作把zone_1 和zone_2 副本从paxos选举组中剔除，副本总数由五个变成三个。机房2内两副本满足多数派，避免了跨城市同步。
该架构中，
● 每个zone的observer个数可以根据实际情况调整，采用单台或多台；
● 备集群可以采用单zone或多zone模式（即单节点或三节点）；
● oceanbase 4.1版本引入仲裁服务新特性，可将异地机房zone_5设置为单台仲裁节点，解决了两地三中心同城副本故障时rt变大的问题，还能降低跨城带宽开销，并将第三机房的成本降到极低。
2、从成本角度综合考虑
一般采用单中心三副本 同城备库的模式，如下：
● 实现服务器级无损容灾，不能满足机房级无损容灾的需求；
● 适用于对容灾要求较低的场景。
该架构中，
● 每个zone的observer个数可以根据实际情况调整，采用单台或多台；
● 备集群可以采用单zone或多zone模式（即单节点或三节点）；
● 同城备库也可以通过逻辑同步实现，一般使用oms做全量迁移 dsg/英方做增量同步等方式。
对于ocp
ocp节点可以使用虚拟机，一般为多集群模式，通过主备ocp集群实现高可用。
ocp主集群（leader）
● ocp集群间的消息中转站
● 数据分发站
ocp备集群（follower）
● 可通过日常切换或容灾切换，
● 替换原ocp主集群
架构图如下：
性能表现
在基于oceanbase数据库的uf3.0业务压力测试场景中，oceanbase有着不俗的性能表现。
在uf3.0全信创环境的压力测试中，集中交易的性能已超出预期，兼具高效率以及稳定性；两融以及期权交易的性能数据较为合理，能够较好地满足于客户实际生产需求。
在模拟真实业务的测试场景中，我们首先测试了leader副本集中的模式（zone1;zone2,zone3）,性能表现不足；后续采用leader副本打散模式（zone1,zone2,zone3），利用了多节点的并发性能，并且通过调整分区表以及表组，使得性能提升近一倍。在ob数据库中，委托交易的事务执行平均时间在1ms以内。
oceanbase在uf3.0业务压力下的性能良好，且通过增加uf3.0微服务节点、增加observer节点仍能进一步提升性能。
本次测试基于oceanbase 3.2.4.5版本，相信后续使用近期发布的oceanbase 4.2.1 lts版本将会有更好的性能表现。
登记过户系统ta6.0
登记过户机构（ta）的作用是管理投资者的开放式基金账户，记录基金持有人份额，进行开放式基金份额过户的机构。登记过户机构通过一套计算机系统执行上述功能，即登记过户系统（ta）。
ta系统是证券行业关键且重要的业务应用系统之一。恒生新一代ta系统，在芯片、存储、服务器、操作系统、数据库、中间件等基础软硬件方面，进行了全面的信创选型及适配改造，具备兼容、稳定的特性。以信创适配为基础，恒生新一代ta系统在统一登记、清算优化、运营一体化等方面完成全面升级和优化。
其功能涵盖了基金交易业务的各个环节，包括账户业务处理，如投资者开户、修改账户资料、挂失/解挂等；日常交易业务处理，如认购、申购（一般申购和定期定额）、赎回（一般赎回、指定赎回、预约赎回等）、转托管、基金转换等；特殊业务处理，如非交易过户、账户冻结/解冻等；分红业务处理，如现金分红和红利再投资。
架构图如下：
ta6.0与oceanbase
ta6.0已全面适配oceanbase，在信创环境中的连续性、稳定性、高效性方面都受到广泛认可。
在数据分布方面，ta6.0适用于oceanbase的leader副本集中的模式（zone1;zone2,zone3），确保数据的完整性和一致性。同时，ta6.0的单zone架构能够满足性能需求，提供更高的稳定性。这种设计使得系统在处理大量数据时仍能保持高效的性能表现，并且能够有效地减少因系统故障导致的停机时间，确保了业务的连续性和稳定性。
架构设计
对于ob集群
一般采用单中心三副本 同城备库（可选）的模式，如下：
● 实现服务器级无损容灾，不能满足机房级无损容灾的需求；
● 适用于对容灾要求较低的场景。
该架构中，
● 每个zone的observer个数可以根据实际情况调整，采用单台或多台；
● 备集群可以采用单zone或多zone模式（即单节点或三节点）；
● 同城备库也可以通过逻辑同步实现，一般使用oms做全量迁移 dsg/英方做增量同步等方式。
对于ocp
ocp节点可以采用虚拟机，部署模式一般为单节点或多节点模式。多节点模式提供了ocp节点的高可用，通过f5/nlb提供vip做负载均衡，在单个ocp节点异常时，仍能正常进行ob集群的白屏化管理。
单节点模式架构图如下：
多节点模式架构图如下:
数据库paas服务
针对金融业非核心的、周边的、自研的业务系统，oceanbase不仅提供自主创新的分布式数据库技术，还可以作为数据库paas平台快速提供基于数据库的paas服务。
作为一种高可靠、高扩展的分布式数据库系统，oceanbase提供了可靠的数据存储和处理能力，同时通过数据库paas平台的形式，简化了部署和管理的复杂性。在oceanbase中各系统数据库将以租户的形式存在，彼此资源隔离，又实现了统一管理。
金融机构可以将自己的业务系统与oceanbase集成，在其基础上构建自研的周边应用。这种方式不仅能够满足业务系统的数据存储需求，还提供了灵活的扩展性和自动化的运维能力。
同时，oceanbase 4.x版本进一步完善了对olap场景的支持，对于某些数仓的业务改造，也能基于oceanbase完成设计。
架构设计
对于ob集群
使用oceanbase数据库作为paas平台，需要兼顾高可用与成本，一般采用同城三中心三副本 异地备库（可选）的模式，如下：
● 机房级高可用，异地备库提供城市级容灾；
● 所有机房对等部署，实现应用与数据库的多活；
● 建议应用与数据库适配来减少远程访问与分布式事务，提高性能。
该架构中，
● 每个zone的observer个数可以根据实际情况调整，采用单台或多台；
● 备集群可以采用单zone或多zone模式（即单节点或三节点）；
● 异地备库也可以通过逻辑同步实现，一般使用oms做全量迁移 dsg/英方做增量同步等方式。
对于ocp
ocp节点可以采用虚拟机，部署模式一般多可用区模式。每一个机房配置所属可用区，一个可用区可映射为1个或多个物理机房。为可用区或者全部可用区分别分配一个ocp，每个 ocp 管理本可用区内的 oceanbase 集群副本，每个可用区的 ocp 对外使用独立的访问地址，但所有可用区的ocp 可查看与管理的内容相同。
架构图如下：
四、日常运维面临的问题
周末测试场景
当前大环境中，证券机构已经不局限于仅使用股票等竞价交易，理财业务等非竞价业务也成为了重要的业务领域。在其它理财大型平台具备流量优势的背景下，提升服务的在线时间和加强用户体验已成为争夺更多用户的关键目标。
即使在周末参加交易所生产测试的情况下，我们仍然致力于为客户提供持续服务，尽可能延长服务时间。这已成为恒生新一代核心系统架构设计的重要要求之一。
现有券商生产参加周末测试时，业务服务情况大致分为三类：
○ 周末测试时不提供服务（非7*24小时）；
○ 提供基本的查询资金、持仓服务；
○ 提供查询服务外，还提供转账业务，理财委托受理、账户业务受理等部分写入业务。
1、传统数据库
在传统oracle/mysql等数据库目前一般采用两种方式：
（1）非7*24小时业务
应用测试前直接在主库进行物理与逻辑备份，测试完成后进行数据恢复。
（2）7*24小时业务（如cqs等）
将备库切换为读写库提供测试，如oracle snapshot standby/mysql slave重建。
2、oceanbase数据库
在oceanbase中，同样适用两种场景
（1）非7*24小时业务（单集群模式）
为避免应用修改连接串信息，可以进行如下操作：
■ 测试前主集群租户进行物理备份（ob自带）与逻辑备份（obdumper/obloader）；
■ 原租户进行重命名；
■ 通过物理备份恢复一个与原租户同名的租户，供业务测试；
■ 完成测试后删除测试租户，并将原租户重命名回来。
（2）非7*24小时业务（主备集群模式）
主备集群模式目前暂不支持物理备份恢复的方式，需要用到逻辑备份恢复：
■ 测试前主集群租户进行逻辑备份（obdumper）；
■ 完成测试后通过obloader完成数据恢复。
（3）7*24小时业务（如cqs等）
业务不能中断的场景下，需要用到备库进行测试，方案如下：
■ 测试前将ob主备集群解耦，使用备集群进行测试；
■ 测试完成后重建备集群。
注：
1、为实现7*24小时业务，“ob主备集群解耦”方案也需要结合业务应用主备架构，应用侧与数据库侧均使用备节点进行测试，在现有的uf30微服务架构中，实现了同城双中心部署、主备机房部署两种模式。
2、从运维难度、成本投入等角度综合分析，应用侧倾向于在7*24小时业务测试场景独立部署一套小的7*24环境的方式，一旦生产参与测试，就用这套小的7*24环境提供给客户服务。此方案契合“ob租户重命名->备份恢复”的方式。
引申
周末场景一般只针对单个业务租户，无论是使用ob主备集群还是同步软件的方式，重建备集群的时间成本都较高，且容灾安全性不足。若备集群采用多zone的架构，则在周末测试时，可以将备集群中的单zone踢出集群，使用该节点重建另一个备集群并进行主备解耦后用作测试，测试完成后重新加入原备集群，这样既保证测试时的主备容灾架构，恢复备集群的时间成本也较低。
oceanbase 4.1.0 版本开始，物理备库的产品形态变更为租户级主备，即主或备的角色信息属于租户，分为主租户和备租户，集群不再有主备角色的概念，而只是承载租户的容器。主租户是用户创建的业务租户，支持完整的数据库服务能力，包括：查询、dml、ddl 等；备租户则仅提供容灾和只读服务的能力。
性能优化
oceanbase中的优化手段一般包括：操作系统参数优化、ob参数优化、应用url优化、分布式事务优化、sql优化。
本次主要讨论分布式事务的优化思路：
1、primary zone 优化
在单台节点可以承载业务量的时候，可以把primary设置成一个zone来去除分布式事务。
alter tenant mq_t1 primary_zone='zone1;zone2,zone3'
2、表组优化
分区表打散的时候，可以将亲和度高的表加入一个表组来减少分布式事务。
表组创建方式：
create tablegroup 组名 partition by hash() partitions 6;
alter table xxx tablegroup = 组名;
3、复制表优化
一些极少增删改的配置表，可以把其修改为复制表，减少分布式事务。
在联合业务模拟的真实交易场景中，通过以上优化手段，ob性能提升近一倍。
五、结束语
oceanbase数据库架构与证券业务系统的结合，为证券交易提供了可靠、高性能的数据存储和处理c7电子娱乐的解决方案，其分布式特性和优化查询引擎确保了系统的高可用和性能，满足了高并发和大规模数据处理的需求，为金融行业提供了自主可控的、可信赖的基础设施，促进了业务的发展和创新。
