一、 专题分享:快捷双活架构

1.1 背景

大家好,今天我想跟大家分享的是主要是银行的快捷架构,银行快捷业务,差错,对账的流程。 前面有很多大牛,讲的很好,我也把我仅有的点干货跟大家分享下,希望对大家有所启发。由于现在单位管理的原因,我不能拿原图出来,图都是我重新简化的,原创,而且讲解主要是讲原理,不影响大家理解。

20170706_192759.png

随着pc机器,云计算的发展,银行业也开始把大量非关键性计算,大量历史数据,下移到开放平台,如明细查询,历史查询,报表,等非关键实时性的功能下移到开放端,形成了这样一个大外围小核心的架构。快捷支付也服从于这一架构,关键的账务,转账处理在主机上,开放上做签名验签,校验,记流水,出对账单等功能。

20170706_192841.png

1.2 关键技术

下面先说几项关键技术,帮非技术的人理解原理,最后说一下双活架构是怎么实现的。

1.2.1 读写分离

20170706_192930.png

主库在运行时会不断产生redo log,这些日志会通过可靠网络传送到备库进行重做。这其实也是灾备的原理,主机的灾备,也是同样的原理。但是主库与备库如果相隔千里,形成异地灾备,主备之间就会存在一个时间差数据变化量,这个变化量就要采用联机补偿机制。

1.2.2 数据库集群

20170706_193037.png
跟PC集群一样,数据库也进行了集群化的处理

1.2.3 分库分表技术

20170706_193120.png

快捷业务的特点就是数据量流水大,高并发。分库分表是必然的选择

1.3 快捷双活数据流转

20170706_193229.png

这就是快捷的一个双活架构图,我先说明一下数据的请求处理流程:

回到开头说的,关键技术,分库分表,我们跟据卡号规则,分了100张表分布在四个RAC里面,服务器跟据我们预定的规则根据卡号,访问不同的RAC。

1.4 双活灾备

举一个列子,如果主中心1库挂了,就可以启用备中心的库红1,F5将请求发往灾备中心,其它RAC同理。

20170706_193704.png

结合这张图就能更清楚的理解双活的架构用意。 主中心有1,2,3库(黑字体),同城有相对应的备库(蓝字体),备主心也有相对应的跨中心备库(红字体),主库和备库之间都是通过ADG技术进行备份,主库可读写,备库只读。

我们在备库出每天跑对账单。

从这个图中,我们可以看到双保险的机制,同城备库,防止主数据库挂掉,跨中心备品库,能防止地震等特大灾害。这张图也体现了两地三中心灾备的思路了。实际上我们只实现了两地两中心,同中心备库是在一个中心里(物理地点)。

1.5 差错产生的原因

以前有人讲过,差错处理的过程,我这里就跟大家讲讲,为什么 差错会产生。

20170706_193829.png

咱们又回到最初的大外围小核心的架构上,快捷支付把大量的计算工作放在开放上,如鉴权,记流水,计算手绪费等,到主机上只做两件事,卡转账,记账。

由于在高并发的情况下,主机处理不过来或是响应变慢,指定时间内无回应,为了提高响应效率,利用柔性事务的原则,开放端首先返回成功状态给第三方支付机构,开放端记一个交易状态不确定。随后由开放端去主机上查证交易结果状成。主机端要是成功,无问题; 主机端要是失败,开放端返回成功,则形成了差错。这就需要线下由银行内营人员手工处理。这就是差错产生的根本原因。

1.6 快捷支付资金清算与对账

20170706_194057.png

在X银行,快捷支付不存在他行的卡,而一般第三方支付机都在X银行开设了备付金账户。快捷支付的实质,就是将客户的钱转到第三方支付机构的备付金账户。因此白天客户支付,将客户的钱转入一个过渡的内部中间户头,日终结束后,再根据白天主机记账结果,将钱从中间户头打入支付机构备付金账户。这就是资金清算的处理,比较简单。

至于对账,银行只出对账单不对账,由第三方支付机构,根据银行出的对账单与划入的资金,与第三方机构自身的流水进行勾兑。如果发生问题,银行配合第三方支付机构进行排查。

1.7 实践效果

在银行这里看,快捷90%的业务量都在,X付宝与财付通,而且出于利润来说,银行欢迎双十一,不喜欢红包雨。

20170706_194156.png

二、 在线问答

Q:冒昧问下,你们做到9kTPS整个集群数量大概多少?

A:主中心30台,备中心30台,共60台

Q:是双十一tps最高吗?

A:春节,比较不爽,过年。。。(小额红包来的应该最猛)

Q:最高TPS为啥要设计到9k这么高 比峰值翻倍?

A:不是设计成那么高,是业务要求,和阿里压测的时候,到了1.2W

Q:你们做到9kTPS整个集群数量大概多少?

A:60台,每台300联接数


Q:主备之间的数据同步是什么技术处理的?

A:oracle ADG(细节请百度)


Q:银行快捷收费都是按交易金额算的么?不是按交易笔数?

A:打包按总金额收


Q:备中心也处理用户请求,数据双向同步?

A:单向,你仔细看我的图,备中心4号库是主库

Q:备中心是仅仅备份数据比他对账单,还是也要处理支付请求?

A:备中心设有一个主库,分1/4的业务


Q:那个分发用到什么算法吗,取模吗?

A:这个算法我就不细说了,有卡号了分表就很容易了


Q:分库分表用的是什么技术和框架?

A:自主设计开发


Q:请教个问题 不管怎么备份复制 主中心宕机的瞬间 一定有一部分数据来不及完全同步到副中心 不知道对于这部分差异数据怎么识别和处理的? 不只是简单的把请求转发到副中心吧?

A:看adg 配置,如果配置成最高级同步模式,理论上不会丢失数据。

Q:假设两地延时有100ms 在高峰期这100ms期间会有多少数据被更新 理论上不可能完全一致

A:如果延时很长,这种情况性能会很差。根本无法commit 成功,会回滚,交易失败。

A:这个问题问的非常好,主机那边,有个技术叫联机补偿,就是会录几分钟的请求报文,切换时先放缺失的报文,再接收请正常计求,一般这个差很小。。

Q:主中心在任何时候都预先保留几分钟的请求数据 切换时在备中心放最后这几分钟的请求 相当于在被中心重复执行一遍 这个意思?

A:是的,原理是这样的,我没具体实施过,不会重复执行,只执行缺失的

Q:是的,对照备中心的最近更新时间,当然不能重复执行,要做到完美难度应该很大;假设并发一万,延时100ms,那也会有至少上千个请求会产生差异

A:这个问题技术分享过 记不清了 大家自己看文章找灵感吧 京东金石系统-多中心高可用的交易系统

三. 话题整理

3.1 上期分享的作业

Q:请大家根据我前面的在XX网上的购物体验来自己也梳理一下账务流程和规则

A:人民币: RMB 169.00
美元: $ 24.81
美元对人民币报价汇率:6.8124
收费费率:3%(和商户约定的合同费率)

充值:
借: 待清算充值款项-银行-业务充值待清算 169.00 (日终跑批汇总记账)
贷:个人账户存款(公司账户存款) 169.00(会员充值时实时单笔记账,增加账户余额)

1、生成购汇文件之前:我在XX网使用X付宝付款,X付宝系统根据报价汇率换算成人民币报价逐步进行账务处理
人民币报价=交易外币金额报价汇率=24.816.8124=169.00
账务处理:
借:个人账户存款(公司账户存款) RMB169.00
贷:代理业务资金-购汇-购汇过渡户 RMB169.00

生成购汇文件时单边借记购汇过渡户,贷方在系统日终跑批时汇总记账

2、生成购汇文件时,系统按预算购汇金额从购汇过渡户扣除:
预算购汇金额=[正常交易商品外币报价(1-收费费率)-退款商品外币报价]报价汇率=[24.81(1-0.03)-0]6.8124=163.95
借:代理业务资金-购汇-购汇过渡户 RMB163.95
贷:待清算购汇款项-XX银行-X行购汇待清算(日终跑批汇总记账)RMB163.95

实际结(购)汇汇率: 6.8100(汇兑收益)
实际结(购)汇汇率: 6.8200(汇兑损失)

3、购汇成功,将购汇文件回导对账后,某某宝收费系统逐笔进行收费(某某宝以人民币计收入),

收收佣金=正常交易商品外币报价收费费率*购汇汇率=24.810.03*6.8100=5.07
借:代理业务资金-购汇-购汇过渡户 RMB5.07
贷:公司账户存款(账务收费某某宝账户)RMB5.07

收收佣金=正常交易商品外币报价收费费率*购汇汇率=24.810.03*6.8200=5.08
借:代理业务资金-购汇-购汇过渡户 RMB5.08
贷:公司账户存款(账务收费某某宝账户)RMB5.08

4、购汇发生汇兑损益的处理:收益转至“汇兑损益备用金户”,损失从“汇兑损益备用金户”补回。(计算结果为正时为收益,否则为损失)

汇兑损益=[正常交易商品外币报价-退款商品外币报价]*(报价汇率-购汇汇率)=
24.81 * ( 6.8124 - 6.8100 ) = 0.06

汇兑损益=[正常交易商品外币报价-退款商品外币报价]*(报价汇率-购汇汇率)=
24.81 * ( 6.8124 - 6.8200 ) = -0.19

汇兑收益的账务处理(本次体验产生收益):
借:代理业务资金-购汇-购汇过渡户 RMB0.06
贷:自有资金账户存款-专项备用金-专项备用金 RMB0.06

若汇兑损失的账务处理如下:
借:自有资金账户存款-专项备用金-专项备用金 RMB0.19
贷:代理业务资金-购汇-购汇过渡户 RMB0.19

境内银行通过 环球银行电信协会SWIFT 电汇 $24.07 境外商户美元账户

3.2 汇兑损益

Q:购汇、结汇汇率方面银行的报价应该不是实时的吧,怎么来预防资损的?

A1:这个需要进行汇兑的头寸管理,或者购买远期期权

A2:你没有看到账户结构的用意吗?不能说预防汇兑损益,有一个汇兑损益的账户,当发生汇率风险的时候,亏损资金从损益帐户出

A3:是确保损益核算准确,这个是账户结构的目的;嗯,损益账户也是自有资金账户,也是符合会计记账的规则

A4:账户只能核算亏多少,解决不了亏损的问题

A5:汇率文件以前是每天10:05到18:05 每小时启动一次,系统设计里面是有波动区间值的,汇率波动预警

A6:X付宝在跨境收单这块佣金是百二还是百三?从实际情况来看,主流币种跟人民币之间的汇率波动应该不可能超过佣金金额的,何况长远来看汇率波动损益是一个平衡值;所以某某宝汇率损益这块问题应该不大,能这么理解吗?

3.3 充值卡卡号生成规则

Q:大家做充值卡的时候,卡号的生成规则是怎样的?如何保证卡号不重复

A1:最后一位校验位,前面得按顺序加1

A2:参考身份证的校验方法,不过量大的话,专门要做分布式ID机制,有时候是性能响应不过来,导致卡号重复,规则只能保证业务上不重复,这个是比较初级的办法

A3:系统要有个卡数据生成管理啊,每次生成制卡数据,卡号都是被统一管理起来的。

A4:卡号加年份、地市、生产商、业务号识别,其他位随机生成,系统提前一天生成不重复的一批卡号,用累加的话会被人家猜出规律

A5:几位卡号加年份时间地点,最后是加密机随机校验码

3.4 滴滴顺风车认证

Q:有人知道滴滴顺风车的这个认证是什么吗?(图略)

A1:微信支付的用户都是实名过的,通过微信支付认证的意思就是滴滴顺风车有这个用户实名信息啊

A2:代表并不是一个实体追踪不到的用户

Q:似乎不完全是这样,是这个接口,针对已实名认证的用户,微信支付可提供校验真实姓名一致性的可选功能。

https://pay.weixin.qq.com/wiki/doc/api/tools/mch_pay.php?chapter=14_1

A3:因为普通平台做用户的实名认证,一方面代价大,另一方面用户的体验繁琐。所以直接和腾讯合作,通过微信支付认证实名。可双向简便的获取并认证用户的实名信息

3.5 复式记账法

账务系统-复式记账法总结 - 知乎专栏

3.6 积分堆积

Q:上次的积分分享,好像没有说如果积分堆积 如何解决的问题?这个是个整体问题,因为积分会堆积,堆积会让负债扩大,扩大会有风险

A1:解决积分堆积不是商务问题吗,不是产品问题吧

A2:建立积分消费通道,定期通知用户消费积分

A3:这个不是产品的问题,你有多少资金玩多大,每天限制积分发放数量,个人每日获取积分数量

A4:这个是业务问题,跟产品无关;积分获取规则也属于业务问题

A5:现在都分不开啦,做的时候就要考虑到这个;这个本质不变,不过是你自己做业务规则而已

3.7 快捷支付和银联无卡支付

Q:请教一下,快捷支付和银联无卡支付,这两种业务有啥不一样么?为啥X付宝接北京银行快捷支付就可以,中金接北京银行就只能开银联无卡支付?

A1:银联无卡支付的定位是做一个类似X付宝和财付通的快捷支付聚合平台,这样银行可以从收单侧推银联体系的快捷支付业务

A2:银联无卡和X付宝快捷走的银行渠道可能不一样;狭义的无卡支付就是银联网关无卡产品,广义的无卡其实是无卡渠道的交易,银联包装了很多无卡渠道的产品

A3:不是的,无卡就是每次都需要输入卡信息,是银联支付网关;而快捷是绑定卡支付,类似X付宝;

A4:无卡的范围很大,二维码也可以是无卡,属于认证支付,快捷属于协议类,认证只在签约时,快捷算是无卡中的协议类。

3.8 芯片卡交易签购单

Q:谁知道现在芯片卡交易的签购单,芯片卡信息要打哪些信息?除了AID和arqc之外的其他信息要打印到签购单上么?

A:待回应


本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。