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

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：主中心３０台，备中心３０台，共６０台

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：备中心设有一个主库，分１／４的业务

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年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。