核心批量功能：统计分析、交易补记账功能（日终补记账、清算、平仓处理、内部户划转、年终决算）、批量业务处理（代收代付、个人贷款到期还款、信用卡自动还款、定期自动转存、基金定投和结息）、对外系统的数据供数。
会计相关操作的批量在总账系统，基于核算流水档生产会计分录，将分录数据更新/录入总账系统，生成对应的科目账，检查科目账平衡，生成总账相关报表，向外部系统供数、科目日结单、日计表。
联机存款操作：
各种检查、修改外部客户账户、生产核算流水档、交易明细
联机取款操作：
各种检查、修改外部客户账户、生产核算流水档、交易明细
联机转账操作：
行内转账：
各种检查、修改转出账户、生产转出核算流水档、修改转入账户、生产转入核算流水档、交易明细
跨行转账：
与行内转账不同点为，转出行会先把要转出的金额记录到本行的往来户中，通过大小额支付完成从转出行到转入行的资
会计相关操作的批量在总账系统，基于核算流水档生产会计分录，将分录数据更新/录入总账系统，生成对应的科目账，检查科目账平衡，生成总账相关报表，向外部系统供数、科目日结单、日计表。
联机存款操作：
各种检查、修改外部客户账户、生产核算流水档、交易明细
联机取款操作：
各种检查、修改外部客户账户、生产核算流水档、交易明细
联机转账操作：
行内转账：
各种检查、修改转出账户、生产转出核算流水档、修改转入账户、生产转入核算流水档、交易明细
跨行转账：
与行内转账不同点为，转出行会先把要转出的金额记录到本行的往来户中，通过大小额支付完成从转出行到转入行的资金调整，转入行先通过本地的往来户把钱给转入账户。
转账请注明转自高孝鑫的博客！
银行核心最主要的批量是日终批量，日终批量通常会有很多批量节点构成，例如具有代表性的“预处理”、“计提结息”、“重新生成还款计划”、“生成会计分录”、“核算总分核对”等等。
在基于Oracle的银行传统账务核心实现中，针对有性能挑战的批量节点已经有批量分段技术，即将批量任务所覆盖的客户号区间拆分为多个分段，针对这些分段将批量节点任务进行并行，并针对并行执行结果进行汇总。
当讲Oracle替换为分布式国产数据库时，批量执行的分段实现就会成为一个性能瓶颈。因为基于Oracle的分段实现并没有考虑分布式数据库的数据分布特征，就会导致拆分的分段大概率是会跨分布式节点的，会引入大量的分布式事务、分布式锁、分布式网络交互等，进而导致性能瓶颈和难以横向扩展。
所以存量核心去O时批量的一个主要的优化措施就是分段实现的优化，从实践角度，一个可能的实现方式就是基于分布式数据库的数据分布方式，针对每个数据分片内的数据跑原来的批量分段逻辑，这样可以确保所有批量分段后的操作都是在单一数据节点内的，并且整体架构可以充分发挥分布式数据库的横向扩展能力。
证券交易的核心系统主要是柜台系统和围绕柜台系统的OTC场外交易、PB系统、和TA系统。
基本背景：
依据国内监管要求，客户无法直连交易所系统，中间必须经过证券公司的系统，即柜台系统。
柜台系统：
OceanBase4.x版本之后主推的单元化方案是obsharding+observer集群。
obsharding就是一个mysql协议的分库分表中间件，可以同时管理多个ob集群，从OCP获取ob集群的元数据。
obsharding会讲后端的ob集群看作mysql小集群，可以讲业务数据横向拆分分片到多个ob集群上，每个分片可以对应一个租户，也就是对应一个业务单元；一个租户可以是单个unit也可以是多个unit（即跨多个ob
server）。
OB这样设计的原因是单元化架构下可能会搭建多个ob集群，系统通过obsharding实现单元化架构下跨多个ob集群的数据汇聚能力。
目前obsharding还是非常初级的mysql中间件实现，包括不支持分布式事务，不支持跨节点join，应该主要的目标还是支撑跨单元的数据聚合，例如count。
转载请注明转自高孝鑫的博客！
目前国内最主要的核心系统厂商就是长亮、神码和中电金信；核心系统通常会和国产数据库进行适配，以方便在后续的项目中进行更好的落地。
以神码的核心系统为例，一个核心系统大致会拆分成几层：
1.
技术平台层；这层是业务不相关的通用技术能力，该层除了可以给核心用，其他的业务系统也通常会基于这个统一的技术平台进行构建。这部分通常在核心具体落地过程中通常是极少做调整。
2.
基础功能层；核心系统的一些基础性模块，例如参数平台、产品中心、定价服务等。这部分有一定的业务相关，核心落地过程中会做一定的定开。
3. 业务服务层；业务强相关的，例如存款服务、贷款服务、支付服务等。这部分在核心落地过程会有大量定开。
4. 特性业务层：完全定制化，是核心落地过程中，基于客户业务特定需求完全定开的能力。
所以可以看到，一个核心系统的落地过程其实是一个大量定开的过程。
数据库厂商与核心系统做的适配通常是基线版本，主要包括技术平台、和初版的基础功能与业务服务，而后在落地定开过程中再基于对应的国产数据库二次开发定开部分。
向量数据库相似性搜索主要思想是通过两种方式提高搜索效率：
1. 减少向量大小——通过降维或减少表示向量值的长度。
2.
缩小搜索范围——可以通过聚类或将向量组织成基于树形、图形结构来实现，并限制搜索范围仅在最接近的中进行，或者通过最相似的分支进行过滤。
向量数据库主要会用到的一些搜索算法（搜索算法都是在速度和质量还有内存上做一个权衡，这些算法也被称为近似最相邻Approximate
Nearest Neighbor，即ANN算法）：
1. 聚类算法k-means，将向量拆分到K个聚类中心，通过先识别聚类中心来减小搜索范围。
2.
为了避免聚类边界处的最相似向量漏掉（搜索条件与搜索结果落入2个相邻的聚类中），引入的Faiss算法，在K-means基础上设置nprobe，即搜索最相近的n个聚类
3. 为了减少聚类算法所需维护的内存（聚类和
养老金系统主要的模块包括受托、账管、投管、投资、托管，这些都分别有对应的牌照，有牌照才能开展对应的业务。
受托系统是面向养老金用户的业务系统，所有的业务入口都是受托。受托系统对外提供访问接口，常见的包括行销支持相关系统（例如行销支持系统与易行销）和客户服务相关系统（例如微信公众号、网上营业厅、客户侧APP）。
财管系统面向养老金业务流程中所产生的财务信息进行审核管理，还包括计算养老金应付多少。做业务的只要和钱相关的，例如缴费、领取养老金，都必须在账管系统记录。
投管系统是管理投资收益的，指定投资策略。 投资系统基于策略去做投资。
账管系统通常业务量不大，业务压力大部分在受托系统。
受托系统与账管系统会存在文件同步导入，受托做了一个业务，会生产一个文件关于缴费成功了，通过接口交互告知账管系统刚才业务动了哪些表和文件，账管系统将这些文件导入。
账管系统除了和受托系统交互外，还会和报表系统交互。报表系统通过ETL从账管系统T+1的方式抽取
(2023-04-30 01:09)
OB的LCL算法是边追逐算法：依据事务依赖关系向下游节点发送消息，死锁产生的环将通过这些消息被推断出来。
参考https://zhuanlan.zhihu.com/p/624847601 算法过程理解如下：
事务的全局等待关系是一个有向图，每个节点是一个处于等待状态的事务，每个边是一个等待关系。SCC是强连通分量，即一个死锁环。
对于每个事务节点存储如下信息：
1.
对于每个事务启动的时候会分配一个PrID和PrAP，为顶点私有的长亮编号和优先级。这个分配过程是递增的，一个事务分配后PrID和PrAP是固定的。
2.
每个事务节点存储PuID和PrAP，用于存储它目前发现的可能是阻塞它的最晚启动的事务的PrID和PrAP。PuID和PrAP是变量，随着算法的推演会被改变。
3. 每个事务节点存储一个LCLV，用于存储它目前可能阻塞的最大锁等待链长度。
算法的执行过程分为3个阶段：繁殖阶段、扩散阶段和检测阶段：
1. 繁殖阶段
繁殖阶段在A(≠B)→B上的推演定义为：A.(PuAP, PuID)=A.(PrAP,
PrID)， B.(PuAP, PuID)=B.(PrAP, PrID)
金融系统核心的数据库国产化替换建设整体进度相比其他行业会更快一下，所以也有不少成功案例的并行验证切换策略可以参考，具体而言：
1. 并行双写策略。并行双写的验证不是必须的，但是一种成本较高效果较好的并行验证手段：
1）应用层的数据访问层改造实现双写，同时实现2种数据库的DAO层，以Oracle为例，先用Oracle的DAO层写入，而后异步调用国产数据库的DAO层，实现双写。这块可能需要应用层做较大的改动，同时兼容2款异构数据库。
2）驱动层做双写，驱动层异步将SQL请求路由给国产数据库。需要国产数据库做了该业务的Oracle用法兼容。
3）流量镜像双写，在网关层面做生产流量的1：1复制，异步发给基于国产库的新核心系统。这类验证复杂度高，但可以支持新核心整体的架构与库表结构的重构。
4）线下数据导入双写。针对查询类业务，可以将线下的消息队列与文件导入进行双发，实现双写。
2. 流量切换
1）对于更可控的项目，可以考虑一把切，复杂度最低
&n
加载中…
转载▼