20170706-银行快捷双活架构

Posted by PaymentGroup on July 6, 2017

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

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

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

  • 1.用户访第三方支付机构做支付。
  • 2.第三方支付机构把请求通过专线 按比例发给主中心和备中心。(图中,标为2的是专线)
  • 3.F5负载均衡跟据报文中的卡号按预先的规则,分别将报文发到主备中心的服务器上。(在这里,存在主中心与备中心转发的情况)
  • 4.服务器处理完成后原路返回。

回到开头说的,关键技术,分库分表,我们跟据卡号规则,分了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:你没有看到账户结构的用意吗?不能说预防汇兑损益,有一个汇兑损益的账户,当发生汇率风险的时候,亏损资金从损益帐户出

  • Q:汇兑损益账户我理解是用来垫资?
  • A:你需要预先充值一笔
  • A:不是垫资,而是真实的资金损失,因为账务记账是实时发生的,汇率是实时变动的
  • A:有亏也有赚,用一个账户记录就好了

  • Q:我的意思是,购汇从银行拿到的汇率可能是前天的,可能新的汇率已经出来了,只不过X付宝拿不到,银行会实时给同步汇率吗?

  • A:一般报价比行市高,银行的汇率都是实时的,你什么时候找他汇兑,他按什么价格给你做,报价是你和用户的事,所以有报价汇率 和购汇汇率;购汇汇率是清算时候的牌价
  • A:和银行挂牌汇率联动的,这个是系统设计需要考虑的,嗯,汇率波动较大会暂停业务
  • A:但是系统里面会有一个校验,如果汇率波动较大 就会预警
  • A:嗯,是的,一直在波动的,直到支付成功那一刻

  • Q:和银行挂牌汇率联动?我还以为是X付宝定时去获取汇率
  • A:以前是定时获取的,现在是不是我不了解了,连连的兄弟你们应该更清楚
  • A:实时的,你也避免不了给用户的报价高了低了,你自己去银行做一个购结汇就知道了

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

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

  • Q:为什么一定要解决亏损?汇兑损益很正常啊
  • A:公司赔钱啊,系统设计要避免亏损风险,很正常
  • A:因为他们考虑的是盈利,而不是系统设计。。亏损风险那是风险部门考虑的事情,计划财务也应该有相应制度流程
  • A:那是老板提出来的,赔钱赔的是老板的,又不是财务的
  • A:怎么叫亏呢,还有可能赚呢
  • A:是的啊,一般都是赚
  • A:赚就不说了 亏尽量减少嘛
  • A:我意思是说 能否尽量用最准确的报价来 哈哈
  • A:如果要完全避免汇兑损益这个问题,需要别的解决办法,不是在系统设计层面解决的
  • A:嗯,一般是财务通过金融衍生产品对冲汇兑损益
  • A:对冲那是另一回事了
  • A:如果有兴趣可以看一下金融衍生品齐全那块的材料,有特别说明减少汇兑损益的
  • A:对冲和系统没有关系,题主的意思是纯只有收单系统的情况下,如何在系统设计上减少汇率波动带来的亏损风险
  • A:那真没有办法减少。。。。银行报价多少是多少
  • A:系统层面那就简单了,尽量缩短你给用户承诺的时间和你做汇兑的时间
  • A:不是啊,上面说的有个波动区间,不也是一个办法吗?
  • A:但是财务记账就很复杂了

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

  • A:敞口风险说白了就是时间风险
  • A:有的银行会在挂牌汇率上进行在自己调节
  • A:嗯,那个是一般是风控系统会判定,这个顶多也是个预警。。。
  • A:是的,人民币跳水了,系统报警,人工干预,这都是措施阿
  • A:一般用不太到,因为你和银行是在定期拿汇率的,在这个时间周期内,不太会碰到区间边界。前提是区间不能影响正常业务进行。
  • Q:不过好像阿里应该有汇率预测系统吧,推送后续一段时间的汇率波动
  • A:汇率没法预测,如果汇率可以预测的话,炒外汇早赚翻了
  • A:有的,当时我在银行,银行有预测系统的。。。
  • A:我之前在做清算的时候,都先看看实时汇率怎么样的,然后再清算;一个笨办法,就盯着系统里面的汇率在一个什么区间,试算一下什么值,收益最大,然后清算
  • A:这个我理解为在一定的波动范围内做业务,波动过大,就业务熔断了
  • A:其实就是系统加人工经验判断,要引入模型也未免不可啊
  • A:资金量大,在合适的报价汇兑,很合算的,哈哈,我觉得公司应该引入外汇高手
  • A:不用啊,又不是专门做换汇业务,意义不大
  • A:这个做法是外汇交易员的做法,我当时在银行是使用了多种预测模型辅助外汇交易员进行购汇
  • A:其实是两码事,一个是业务,一个是清算,正道是开发双向的业务,对敲起来美滋滋;因为外汇变动都是一个大环境长期过程,只有单向业务,业务每天发生,你需要每天清算,如果长期是在下行趋势,那就是一直亏,每天看汇率也没多大意义
  • Q:外汇高手,工行是不是强硬些?
  • A:外汇高手很少,风险也比较大,比较靠谱的就是对冲
  • A:对冲做得好能发家
  • A:有些对冲有隔夜利息
  • A:清结算这点量对外汇市场来说太小了,这点钱炒外汇工资都不出来
  • A:现在就好多创业公司在做这个业务
  • A:哈哈,遇到脱欧似的黑天鹅事件,就亏惨了,所以对冲还是很有必要的

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:现在都分不开啦,做的时候就要考虑到这个;这个本质不变,不过是你自己做业务规则而已

  • Q:这个应该是设计的时候就该想到问题吧,我的意思是整体的积分消耗。比如你系统累计发出了3亿个积分,结果因为某些特殊原因突然在短期内所有用户将积分消耗殆尽,这怎么办,做不好公司会倒的
  • A:没钱就关闭交易呗,商品下架
  • Q:那朋友这么说,就是要一个积分体系的风控?
  • A:可有可无
  • A:其实这个问题就像共享单车退押金,余额宝大量提现一样,个人感觉不是产品问题。量小是运营问题,如果量大,那是公关问题了。

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

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

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

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

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

  • Q:你说的那个是银联在线
  • A:嗯。官方叫法是无卡
  • Q:无卡是类似认证支付?
  • A:只要卡信息就可支付,而且每次验证,不留存的
  • Q:不签约是吧
  • A:对;银联后续有个新产品叫做无卡快捷,有兴趣的可以关注下,在 open.unionpay.com 都有介绍
  • Q:无卡和快捷认证要素都是一样吧
  • A:都一样
  • Q:那无卡和快捷从产品逻辑上为啥是分开两个的呢,为啥要一个签约一个不签约呢?
  • A:时代发展的产物,原先的无卡脱胎无网银,所以无卡渠道往往支持银行多于快捷
  • Q:那验卡的这个流程,理论上讲,接无卡还是接快捷,完全取决于提供验卡服务的第三方?
  • A:取决于您想不想一次绑定吧,一次绑定的话就接快捷的,不用每次输入四要素

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

3.8 芯片卡交易签购单

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

A:待回应

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