09:52:21 石-鄞州银行，科技部开发
请教一下各位，支付宝交易不是实时的吗？做支付宝一笔消费，在做撤销，消费竟然有不成功，撤销成功了，对账时消费就入差错了，实际撤销成功了，消费是否成功都会作废吧
09:56:05 石-鄞州银行，科技部开发
老是有对账不平的，这个问题怎么解决
09:57:34 我
消费不成功是从同步还是异步接口得到的结果？
09:59:46 李楚华-嘉联支付-资金平台
我们之前对接一个银行的微信交易，撤销和冲正是同一个接口。不知道@小石_华腾_宁波 你们公司是不是这样的情况。
10:14:32 石-鄞州银行，科技部开发
被扫是同步，主扫是异步
10:19:19 石-鄞州银行，科技部开发
异步去查结果
10:25:30 石-鄞州银行，科技部开发
各位高手给一下建议
10:28:55 王涵
没做过撤销，做过退款，什么场景下会用到撤销，能不能用退款代替呢？
10:31:07 肖勇
冲正、撤销、退款都是有使用场景的，在交易接口中不能乱用。
10:31:53 superbboy
支付宝刷卡接口不是建议消费不成功，先查询不行再撤销码？
10:31:58 肖勇
消费交易都没有成功，怎么会有撤销交易呢。
10:32:19 superbboy
撤销就是相当于POS的冲正
10:33:02 肖勇
如果相当于POS的冲正，是不应该参与对账得
10:34:07 张泽雄-民生金服 项目总监
撤销不相当于冲正，是相当于当日退货
10:36:45 superbboy
10:36:59 superbboy
我之前看文档时这样说的，所以我理解就是冲正
10:37:54 张泽雄-民生金服 项目总监
从文档上看是冲正
11:25:37 淡风林-中移动杭州研发中心PM
退货都是隔日的，撤销是24小时内的，交易撤销是全部退款，退货可以部分退的
11:26:24 李行-途牛支付中心研发总监
也有当天非全额退款场景
11:27:30 华-南京亚软-IT总监
退货：可以是当天，也可以是隔天； 冲正：一般都会有时效，比如5分钟。
11:27:32 淡风林-中移动杭州研发中心PM
这个比较少吧，支付宝微信啥的调用交易撤销都是直接反向交易的
11:43:46 龚晓冬-银商账户-产品-上海
11:44:06 龚晓冬-银商账户-产品-上海
刚才支付圈公众号发出来的
12:07:49 都沙沙-点融网-支付PM
各位老师，有个问题想请教下
12:09:17 都沙沙-点融网-支付PM
就是支付机构给商户结算之前，要不要等上游渠道全部对帐完，如果有的渠道给的对帐文件晚或者是异常了没拿到对帐文件，那商户的结算流程就全部挂起？还是跳过这个渠道部分结算？还是先结算后面再对？
12:09:31 都沙沙-点融网-支付PM
我们以前都是一刀切的做法，严格的对完再结，想看看大家是什么做法
12:11:17 于江宁-银联电子PM
先给商户结算出去，后面再对账
12:11:48 张泽雄-民生金服 项目总监
只要在合同规定的时间内给商户结了，内部怎么做都行
12:12:31 张泽雄-民生金服 项目总监
关键是账上有没有钱
12:19:03 张泽雄-民生金服 项目总监
这两种方案都不冲突，清算都是各自清算，只是给商户结算的风控力度不同
12:26:31 stranger-同城旅游支付PL
@沙莎-点融网-支付产品经理-上海 ，按照现有的方式是不是上游渠道晚了，你们的账单也会跟着晚？
12:26:48 都沙沙-点融网-支付PM
是的
12:27:08 都沙沙-点融网-支付PM
不单是账单了，跑批落库也会晚
12:27:29 都沙沙-点融网-支付PM
因为我们几乎没碰到渠道的对账文件严重滞后和异常的情况
12:27:39 都沙沙-点融网-支付PM
也是最近突然出了个事儿，给我提了醒
12:29:48 stranger-同城旅游支付PL
那像我们这种会去自动获取账单的，早上就要把账务数据准备好的商户来说，体验不是太理想。
12:30:21 都沙沙-点融网-支付PM
是的呢
12:40:54 张泽雄-民生金服 项目总监
这两个应该是分开的
12:40:56 张泽雄-民生金服 项目总监
12:43:23 都沙沙-点融网-支付PM
给商户的清算，不依赖上游的对账结果吗？那岂不是给出去的对账单是不准的
12:43:44 张泽雄-民生金服 项目总监
为什么是不准的？
12:44:02 都沙沙-点融网-支付PM
因为跟上游渠道还没对完啊，会有单边账啊
12:44:22 都沙沙-点融网-支付PM
也有两段式处理的模式，各做各的，但是后续的调账流程会很麻烦诶
12:45:06 张泽雄-民生金服 项目总监
从业务流程上说，商户与第三方支付签署了合同，商户所有数据都应该以第三方的数据为准，而第三方支付也要对自己的数据负责。
12:45:39 张泽雄-民生金服 项目总监
和渠道的事是另一纸合同了
12:46:15 Ben富友PM
简单的说，要长款不要短款
12:46:55 张泽雄-民生金服 项目总监
看你怎么对短款进行定义了
12:48:02 张泽雄-民生金服 项目总监
你系统可以比渠道提前几分钟日终就行了
13:23:03 都沙沙-点融网-支付PM
这招好
13:30:15 袁军-架构师-快捷通
没T0实时结算的啊～
13:32:20 孔晓光 丰瑞祥CTO
你界定一个原则就是究竟要不要信赖上游。如果完全按照上游出了对好再打款，客户体验很差
13:54:45 张泽雄-民生金服 项目总监
有没有T0不影响方案。 这种做法，其实背后深层的原因就像上面富友那位朋友说的，企业的真实诉求是不想短款，不想垫资。 在合同规定范围内，只要渠道能无条件兑付，就不会有什么太大风险。但清算只是个信息流，等渠道结算完再结给商户的做法也是可以的。
15:21:07 袁军-架构师-快捷通
做T0就是垫资业务啊，当然会有些不一样，程序相对都要更严谨。依赖上游对账结果，就没法做啦。
15:36:43 朱黎明 海尔快捷通
T+0差错处理你们怎么做的？
15:37:08 朱黎明 海尔快捷通
实时清算
16:07:48 袁军-架构师-快捷通
不明确交易都处理中，T1处理，正常交易t0多个批次清算。很多银行也这么处理的
17:26:28 张超千-点融网高级PM
请问有谁认识airbnb的人不？
17:27:47 荣飞-有赞Java资深工程师
17:27:54 荣飞-有赞Java资深工程师
@超千-点融-产品经理
17:28:15 张超千-点融网高级PM
谢谢
17:35:08 会唱歌的石头
有无做大数据征信的兄弟互相加了交流
18:25:09 MEET
群里有做网络借贷平台精准匹配的技术和产品人事不[呲牙]
18:25:27 MEET
咨询点技术问题[呲牙]
19:08:18 程琳-杉德支付-PM
今天请到一位去哪儿的朋友，@陈从武-去哪儿-开发 给大家做分享。主题是“去哪儿网酒店交易系统架构介绍”，开始时间为19:30；欢迎欢迎[鼓掌][鼓掌][鼓掌]！（注： 1.嘉宾分享期间其他人不要发言打断嘉宾分享。2.分享完成后请大家积极补充和提问；3.烦请领取红包签到，谢谢！）
19:08:37 程琳-杉德支付-PM
微信红包
19:08:50 会唱歌的石头
[强]
19:09:15 程琳-杉德支付-PM
欢迎分享[鼓掌][鼓掌]
19:09:29 vniuv-群星金融（供应链金融）产品
欢迎分享[鼓掌][鼓掌]
19:09:44 程文东-拉卡拉PL
[鼓掌][鼓掌][鼓掌]
19:10:14 小七-拉卡拉-工程师
[强]
19:10:34 周红仁-去哪儿支付
[强]
19:10:43 Peter-找钢网-PM
[玫瑰][强]
19:11:04 石-鄞州银行，科技部开发
谢谢分享
19:11:32 build-去哪儿-QA
[强]
19:11:44 Tim-深圳百灵鸟-架构
[强]
19:11:47 happycoral
[强]
19:12:22 庄浩田-51信用卡支付清算产品
[强]
19:12:26 陈桂荣 翼支付 -研发组长
[强]
19:12:55 典典子
[强]
19:13:50 落雪飞花-农信互联-开发经理
[强][强][强]
19:14:28 胡永
[强]
19:14:58 孙军-中证互联PM
[强]
19:15:05 吴浩-小牛在线
[强][强][强]
19:15:37 吕剑辉-杉德-PL
[强]
19:16:03 少帅-快捷通支付产品
谢谢分享
19:16:08 赵业招
[强][强][强]
19:16:12 车睿??
[强]
19:16:23 sunshine-苏宁金融
[强]
19:16:26 上海块钱业务分析师
[强]
19:16:42 徐萍 途牛产品总监
[强]
19:18:16 Kelly-美团支付PM
[强]
19:19:37 Dz-京东金融-PM
[强]
19:19:53 李行-途牛支付中心研发总监
[强]
19:20:12 Daniel
[强]
19:20:52 EagleCheng-兴业银行架构师
[强]
19:21:05 封国辉-广发银行-系统设计
[强][强][强]
19:23:37 李奔-快钱-支付PM
[鼓掌][鼓掌][鼓掌]
19:24:35 龚正-滴滴-支付金融
[强]
19:25:30 沈一点-恒生电子-工程师
[强]
19:26:02 李紫建
期待
19:27:19 陈从武
谢谢大家，我们7点半准时开始
19:29:08 WillYang-嘉联支付-架构师
[强]
19:29:36 忘乎所以-腾讯-支付线风控后台开发
谢谢分享
19:30:05 豆角茄子-卡友支付-PM
[强]
19:30:26 陈从武
大家好，我叫陈从武，目前在去哪儿网大住宿事业部负责交易系统研发工作。我今天给大家分享我们交易系统架构设计方面的两个特点，事件驱动与文档模型，主要是偏技术方面的。
19:30:52 陈从武
现在介绍第一部分，事件驱动。先介绍一下引入事件驱动之前，我们面临的问题。
19:31:06 陈从武
19:31:51 陈从武
第一个问题是服务化拆分之后来带来的。交易系统从单体应用演进到服务化拆分，让不同领域的微服务服务关注特定的领域，提高了系统的扩展性，使得多个团队可以分别维护不同的服务。
19:31:52 杨继军-联想电商平台架构师
[鼓掌]
19:32:22 陈从武
然而由于业务的复杂性，一个典型的订单操作需要许多个不同的微服务协同完成，如果全部通过RPC调用的方式，会导致系统耦合，服务之间一致性难以保证，服务可用性降低，服务响应时间过长等问题。
19:32:41 陈从武
比如我们在取消订单的时候，还需要根据订单取消规则为用户退款，如果在取消订单的接口同步调用退款接口，一方面无法保证订单取消与退款操作的一致性，另一方面也会影响取消订单的响应时间和可用性。
19:34:29 陈从武
19:34:46 陈从武
另外一个问题是状态机的状态膨胀。交易系统的设计一般都是以订单状态机为核心的。状态机规定了订单在一个状态下，收到事件，流转到新的状态，同时需要触发执行的一系列动作。随着业务变的复杂，我们发现状态变得越来越多，难以维护。
19:35:29 陈从武
这种状态的复杂性比较常见的有两种，第一状态机的嵌套，即状态S1流转到状态S2，是一个独立的子状态机；第二种状态机的组合，订单实际存在多个并行执行的状态机，多个状态机的状态的乘积组合是实际的所有状态，如果按照乘积的方式展开状态会导致状态增多且不好理解。比如对于酒店交易系统就存在订单状态与支付状态两个并行执行的状态机。
19:36:19 陈从武
状态机可以看作是一个事件驱动的系统，通过事件驱动状态机的运行，但是在实现复杂业务的时候难以解决上述状态膨胀的问题。我们通过扩展状态机的模型，将订单数据的变化做为事件，订单数据看作状态，所执行的动作就是我们的业务。通过订单数据的变化驱动订单业务逻辑。
19:37:31 陈从武
我们通过引入事件的机制，将复杂的业务流程拆分为同步状态操作和多个状态变化事件处理器。通过这种方式将同步调用转化为异步调用，提高系统的扩展性，可用性。同时通过事件的可靠分发机制，保证不同微服务之间的最终一致性，减少系统设计中的分布式事务问题。
19:38:10 陈从武
19:40:16 陈从武
从事件驱动的角度来看，一个典型的订单生命周期中由若干次外部事件激活,外部事件指用户操作，运营操作等。外部事件触发订单数据发生变更，订单的变更事件进一步触发各领域服务的事件监听器，事件监听器的执行进一步触发了新的订单变更事件，从而触发更多的事件监听器执行。交易核心系统只需要专注订单数据变更及发出变更事件即可，各业务系统通过实现特定的订单变更事件完成各自业务。
19:40:30 陈从武
比如订单取消操作，处理订单取消的同步业务流程只需要检查订单是否可以取消，如果满足将订单状态修改为取消状态即可。负责退款的业务会通过监听订单取消事件异步为用户退款。代理商对接系统通过监听事件，向代理商系统取消订单。退款成功的回掉通知中只负责更新订单的退款流水信息，而退款流水的变化事件监听器会决定是否将订单的支付状态推送到退款成功。
19:42:30 许巍-微盟-支付系统
[强]
19:43:22 陈从武
19:43:42 陈从武
下面介绍一下在工程实现上，我们系统的实际架构。我们系统的核心是一个几乎业务无关的StoreEngine系统，该系统提供订单数据的更新功能，并且在订单数据变更成功的时候保证同步发出一个订单变更事件，该事件的内容是此次订单变更的变化字段。
19:45:05 陈从武
所有的业务系统，包括负责用户订单的核心系统都是构建在订单变更事件的基础之上的。采用这种结构，StoreEngine系统只负责事件的发送，稳定性高。其他业务系统都通过事件监听器的方式工作，系统的扩展性很强，增加一个新的业务只需要在合适的事件上注册自己的监听器即可。同时，系统的隔离性也很好，不同系统是不同的监听器，一个系统的失败不会影响其他系统的运转。
19:46:32 陈从武
简单总结一下，交易系统面临着流程复杂，分布式一致性难以保证，状态机状态膨胀的问题。我们将交易系统构建在事件驱动的机制之上，订单任意数据字段的变更都会发出一个变化事件，业务系统通过监听这个事件完成业务，如果修改了订单数据，就会触发新的事件发出，从而不断驱动业务流转。通过事件驱动的方式，我们的系统得到解耦和隔离，复杂业务流程得以拆分，原来复杂的分布式一致性问题也简化为最终一致性问题得以解决。
19:48:24 陈从武
下面介绍第二部分，我们系统的另外一个特性，文档模型。
19:48:46 陈从武
交易系统中的订单存储一般都是基于关系数据库实现，我们采用了基于文档模型构建系统的一种新的思路。我们将一个订单的所有数据打平，看作一个文档，将订单数据以字符串的形式存储在关系数据库的一张表里。采用这种Schemaless的文档模型，使得数据模型变更的成本很低，提高了业务灵活性。
19:49:26 许巍-微盟-支付系统
事件监听是用消息中间件？
19:50:12 陈从武
我们为什么要使用文档模型，与关系数据模型相比有什么好处呢？先看一下使用关系数据模型给我们带来的一些困扰。
19:50:56 陈从武
第一个困扰就是随着业务的变化，需要经常性的修改原来的表结构，而对于数以亿条的订单数据库来说，修改表结构的成本非常高，想做到不影响服务在线变更也很困难。
19:51:16 陈从武
第二个困扰是关系模型往往依赖业务人员自己编 写SQL来实现业务逻辑，SQL如果写的不好，表的索引设计的不好，都容易出现慢查询，从而影响系统的整体稳定性。对于交易系统来说还经常会出现大量的事务带来的死锁问题。为了避免此类问题，要求我们对开发人员的SQL进行严格的审计，线上SQL执行进行周密的监控，开发测试成本随之增大。
19:51:38 陈从武
第三个困扰是系统的可读性。 采用关系数据库，我们需要把一个订单的所有数据分拆到上百张表中，这些表以不同的关系互相关联，想理清这些关系往往需要画一张错综复杂的ER关系图。
19:53:09 陈从武
我们尝试采用Schemaless的文档模型来构建系统，数据模型的变更成本很低，也避免了不合理的SQL带来的系统不稳定的潜在风险，同时对我们来说也订单数据也更加可读。
19:54:10 陈从武
19:54:29 陈从武
我们将一个订单的数据按照业务，层次化的分拆到不同子节点中。比如对于我们线上一个典型的订单，我们首先拆分为报价快照，订单，支付，资金，搭售子单，订单运营等多个子节点。每一个子节点内又可以按照自己的业务模型进一步增加节点进行划分。第一层的子节点都会序列化为一个字符串存储在关系数据库中。
19:55:28 陈从武
由于这种Schemaless的设计，如果需要调整节点的结构，直接在业务代码中修改即可，存储层没有额外的成本。同时文档模型的结构更加直观，可以清晰的表示各种复杂的关联关系，常见一对多，一对一，多对多都可以比较方便的实现。另外大多数的查询场景都是基于订单号的，我们将一个订单的所有数据聚合在一起，相比于从几百张表中按照关联关系依次分散查询，效率更高。
19:55:55 陈从武
19:56:11 陈从武
下面我们介绍一些实现上的细节。先介绍基于版本号的一致性保证。
19:56:31 陈从武
订单的版本号在保证数据一致性方面起着关键作用。我们的订单查询接口会依次查询内存缓存，数据库从集群，数据库主集群。不管是缓存，还是数据库从库的数据都有可能不是最新的。为了保证订单数据的强一致，每次读取订单的时候，我们都会先查一次数据库的主库，单独查询订单版本表，得到订单的最新版本号，如果缓存或从库中的数据的版本号小于主库中读到的版本号，我们就认为数据是过期的。采用这种方式虽然每次订单查询都需要查一次数据库主库，但是因为我们只需要根据主键查询一个版本号，而不需要将订单的所有数据从数据库中查出，降低了主库的压力。
19:57:20 陈从武
19:57:33 陈从武
下面介绍订单检索的问题。使用文档模型之后，数据库只能提供按照订单号的查询请求。其他类 型的检索请求就无法通过写SQL的形式满足了。我们通过构建独立的订单检索引擎来满足这类查询需求。我们将订单数据通过事件监听器的形式准实时的同步到多个基于ElaticSearch构建的 全文检索集群中，由ES提供订单检索服务。
19:58:02 陈从武
我们按照时间维度提供全量与热点不同的检索集群，以保证热点数据的高效访问。基于事件的实时订单同步，不同的业务也可以结合自己的查询场景自行建立适合自己业务场景的检索引擎，以达到查询的最佳效率。这种方式有一点局限是索引数据不是强一致的，会有短暂的同步延迟，在实际的场景中这种延迟都在毫秒级别。
19:59:05 陈从武
第二部分总结一下，不同于关系模型，我们尝试采用文档模型的方式来构交易系统的存储模型。我们通过将订单数据按照Schemaless的字符串的形式存储在数据库中，简化了数据库表结构变更的成本，提高了业务响应的灵活性。
19:59:20 陈从武
通过版本号判断缓存数据的有效性保证缓存的一致性。为了解决非订单号的检索需求，我们通过事件驱动的方式监听订单数据变更事件，准实时构建独立的检索引擎。
20:00:26 陈从武
今天主要是介绍了我们交易系统设计中的两个特点，事件驱动与文档模型。我的分享结束了，谢谢大家。
20:00:39 许巍-微盟-支付系统
[强]
20:01:21 王qz-玖富支付
[强]
20:01:36 陈从武
基于文档模型的交易系统
20:01:37 陈从武
今天的分享也可以看这篇公众号文章
20:01:49 刘洪明-便利蜂支付
[强][强][强]
20:02:14 JianYongWu-支付通技术总监
[强]
20:02:30 陈从武
@许巍-微盟-技术?事件是依靠公司自研的可靠消息队列QMQ
20:02:41 Peter-找钢网-PM
[强]
20:03:27 杨继军-联想电商平台架构师
[鼓掌][鼓掌][鼓掌]
20:03:28 许巍-微盟-支付系统
嗯，了解@陈从武-去哪儿-研发?
20:04:26 thq
更新订单中的字段的过程，需要先把订单反序列化后修改字段，再序列化保存入库？
20:05:19 陈从武
嗯，是这样的
20:06:22 thq
这样订单更新的效率会不会很低？如果层级很多序列化的内容也会很多
20:06:53 陈小学学-迅联智付-架构师
收拾出发咧
20:06:54 杨继军-联想电商平台架构师
这个有点重了吧？还是状态可以独立于文档，单独的字段？
20:07:30 陈从武
序列化和反序列化是一个系统cpu热点，但CPU还是很快的哈哈，所以并不是瓶颈
20:07:55 陈从武
@架构师-联想-杨-北京?只有一个文档，没有单独的字段
20:08:19 thq
但每次从数据库取这条订单的io也不低啊
20:08:28 陈从武
实际系统中的瓶颈都是IO，运算都是ms级的
20:08:34 许巍-微盟-支付系统
有分库分表吗？
20:08:54 陈从武
有的
20:09:08 杨继军-联想电商平台架构师
我们现在是基础信息是文档，状态等敏感属性独立，您这个很厉害????
20:09:52 许巍-微盟-支付系统
不错的想法，受教了
20:10:51 陈从武
@thq-51信用卡?从db取订单数据的时候，其实从整体上看效率更高了，因为一个订单的数据合并在一个字段里只需要一次IO，而如果实在多张表里就需要很多次IO。整体上看io次数减少了
20:12:21 杨继军-联想电商平台架构师
嗯，关键是有强大的es做聚合查询，省去了后顾之忧
20:50:47 小七-拉卡拉-工程师
扩展性确实比用关系库要高
20:52:54 李清华-随手记
行业内是否有金融业务表常用字段通用的的命名标准文档
20:55:33 田浩沛-银生宝电子支付公司技术总
交易系统对事务原子性，一致性高，我一直认为这个是NoSQl数据库的弱点
20:56:10 姚刚-阿里-PD
想问下钱包类业务中，对客户的临时垫款（并融资款），是新给客户创建贷记账户？并新增欠款记录？
21:00:42 刘险峰-卡牛信用卡-PL
行业内是否有金融业务表常用字段通用的的命名标准文档。同问。[憨笑]
21:07:15 张泽雄-民生金服 项目总监
标准规范都是自己定的
21:08:10 pangning-安邦集团收付团队研发
字段这些，自定义就好[擦汗]
21:10:11 张泽雄-民生金服 项目总监
找自己公司的架构委员会
21:23:04 刘险峰-卡牛信用卡-PL
嗯。现在就是标准不统一。OK，内部统一就可以了。[握手]
21:35:57 崔奕
@刘险峰-卡牛-深圳?http://www.cfstc.org/publish/main/21/index.html
21:36:18 崔奕
金融标准化委员会负责制定
21:46:12 蔡云龙 开联通支付
[强]谢谢分享
22:27:07 李清华-随手记
[强]
22:28:59 王子硕-便利蜂
[强]感谢分享
22:29:21 文奇
感谢分享
22:31:07 刘险峰-卡牛信用卡-PL
[强]
22:31:17 呼呼-汇中金融产品经理
[强]感谢分享
22:31:30 lisp 财付通结算财务
[强]
22:31:41 MX农行
[强][强]
22:31:43 郑阳-微汇金融-USTC
感谢分享
22:36:42 junzhu
感谢分享[微笑]
22:46:12 会唱歌的石头
[强][强]
22:57:42 我
感谢分享，[强][强]
22:58:32 Chess-技术总监 首付游
感谢分享
22:58:59 Peter-找钢网-PM
感谢分享[玫瑰][玫瑰]
22:59:57 田浩沛-银生宝电子支付公司技术总
感谢分享
23:15:33 李飞-产品经理 掌众金融
[强]
23:16:55 Summer 梁夏
感谢分享
23:27:51 胡永
感谢分享
23:35:06 甘建新-快捷通支付架构师
感谢分享