- 摘要: 订单. 库存. 规则引擎. 业务漏洞.
1. 认同么?《逆流而上 阿里巴巴技术成长之路》[成都-梅小西]
北京-喜<-> 20:13:47
paxos那一段是有问题的。 paxos适用于角色一致的场景, 分布式事务还有个场景是不同角色共同完成一件事
北京-竹竿(-) 20:14:40
而且补偿不是万能的，有些业务不适合补偿
北京-张文(-) 20:15:10
是因为paxos里都是提案者？角色一致, raft里有leader和follower就是角色 不一致？
上海-水货(-) 20:15:39
paxos也有改良的啊 也分角色的。你理解错了, mutil-paxos就有leader, paxos干的事情就是要让所有人统一口径 所以说是 适用角色一致的场景,
喜神说的角色一致 和 你想的 角色 不是一回事.
北京-喜<-> 20:16:22
比如 A B C D 一起完成，是4个应用
北京-Easy哥(-) 20:18:53
这种只不过 paxos的一个特例 , 任何一个 2PC或者3PC可以保证强一致的系统 paxos都适用
成都-梅小西(-) 20:18:58
商品当前库存数量=商品表中的库存数量-预减明细表中该商品对应明细表中库存数量之和
原来淘宝也是用的这种, 减库存不是真的减库存，而是增加一条记录
北京-Easy哥(-) 20:19:43
这个去年我不是跟你说过了么
北京-喜<-> 20:19:50
等于是把paxos拆成2层来看
北京-Easy哥(-) 20:19:54
高并发系统 数据库只有2个操作, 一个 select 另外一个是 insert, 其他都要转化
成都-梅小西(-) 20:20:27
那最终update的时候是神马时候? 定时job？
北京-Easy哥(-) 20:21:10
没有update, 所有的最终状态 都是 临时计算的
南京-tony<-> 20:21:13
不实时同步，怎么保证呢?
北京-喜<-> 20:21:14
和记账与清算一个意思，这个适合于有采购系统/补货系统的场景
成都-梅小西(-) 20:21:45
看来用消息做一致性是通用做法啊
北京-Easy哥(-) 20:22:25
linkedin 有一篇论文 the log
成都-无名(-) 20:22:55
update怎么转化？还是不转化了？
南京-tony<-> 20:23:04
不update。。。哪里得到还剩多少呢, 插insert，反向减？？？
成都-梅小西(-) 20:24:01
对，easy的意思就是查出来然后减去记录表里的数据, 原来的库存量是不变的
北京-喜<-> 20:24:26
这个是有场景的, 就是可以补货的系统可以这么玩
南京-tony<-> 20:24:51
但是select查出来的，并不是一定准啊, 如果insert慢呢, 会不会不一致
北京-喜<-> 20:25:08
你去看下 头寸和清算, 金额里对账就是这么对的
成都-梅小西(-) 20:24:31
理解下这个图
杭州-江(-) 20:25:08
和我们公司的差不多啊 这个图
成都-梅小西(-) 20:25:28
这个交易表其实类似于预扣记录表？
北京-小柒<-> 20:25:28
库存减去所有该商品订单的总额？？？
北京-喜<-> 20:25:31
金融里对账就是这么对的
成都-无名(-) 20:25:49
哦，还是业务决定嘛
成都-梅小西(-) 20:26:05
那这个人要是不买了，那这个交易预扣表是不是要置为失效记录
北京-Easy哥(-) 20:26:06
小西的这本书 比较老了, 那个MQ是notify, 现在都不用了
北京-喜<-> 20:26:41
有些东西是有生产线的, 有些东西没有, 比如服装 和 酒店，是2个完全不同的 库存
北京-Easy哥(-) 20:27:08
额 所有的系统都可以这么做, 飞猪的酒店就是我说的这逻辑
北京-喜<-> 20:27:21
做是可以做, 担风险
北京-Easy哥(-) 20:27:52
这个 也是高并发系统的基本做法
成都-无名(-) 20:28:15
update比insert慢多少了？
北京-漫游(-) 20:28:34
update可能有冲突,insert不会
成都-梅小西(-) 20:28:33
@北京-Easy哥 啥逻辑？
北京-Easy哥(-) 20:30:15
insert 如果是ssd盘 tps有-, update 只有 5000, 如果是 stat盘 insert tps是8000, update只有3000. 所以 如果 你前面的机器性能都压榨的差不多了, 你要不要搞一下数据库, 极致性能需要极致手段, 这种手段带来的副作用就是 业务会多了很多额外的逻辑, 一个是加业务逻辑 一个是改业务逻辑
北京-喜<-> 20:32:28
超卖了咋处理的?
成都-梅小西(-) 20:33:23
超卖的逻辑。。。什么情况下会超卖, 库存在不同的库里, 无法及时更新总库存？[原子性是针对你这一段说的，小西]
北京-喜<-> 20:33:49
原子性 是啥意思
北京-Easy哥(-) 20:33:58
超卖的话 目前我知道的 采取这种处理的2家公司 阿里和亚马逊是采用前置统一cache方式来解决的 , 就是 需要库存限制的时候 使用 cache做库存临时表 , 只是 这个 cache是带落地的
北京-喜<-> 20:34:02
这个不就是1个典型的非原子性方案么, 那整体看下来是一样的
成都-梅小西(-) 20:35:03
cache？你是说吧库存全放缓存啊,
北京-喜<-> 20:35:22
库存系统基本都靠cache抗的
北京-Easy哥(-) 20:35:26
你可以这么理解 , 这个cache你可以看作磁盘cache, 不是内存cache
北京-喜<-> 20:35:56
限制不限制库存，透过商品模型控制，决定走不走cache,DB层不处理, 加cache，就是加了1层原子性
北京-Easy哥(-) 20:36:53
这种设计的基本原理就是 DB只是数据备份, 不参与业务逻辑, 做的极限一点 可以做到整个交易 不需要数据库参与
成都-梅小西(-) 20:37:45
哦，我之前也听到一种说法，高并发下，所有参与的计算啊什么的，全是cache内存计算，db只做最后的结果记录？
北京-Easy哥(-) 20:37:53
上次 夫子不是说过 深圳有一家公司 这么做的么
成都-献计献策(-) 20:38:05
我觉得小西说的对, 真正的高并发怎么能直接操作数据库呢, 你业务库直接面向用户…万一遇到攻击呢?
北京-喜<-> 20:39:00
和这些没关系, 单存因为DB扛不住, 攻击的流量 cache也扛不住
成都-献计献策(-) 20:39:44
直接库被打死, 但是你是你的业务数据
北京-喜<-> 20:40:03
cache里也是, 你觉得cache为主 DB为辅, 还有DB纯粹是因为SQL, 结构化查询的诉求而已
杭州-江(-) 20:40:34
那对cache的要求就很高了啊, 万一跪了 数据都找不到啊
南京-tony<-> 20:40:50
肯定都防刷的，cache只能是抗主要流量, 就怕它挂。。。
成都-梅小西(-) 20:41:00
所以啊，他说他的cache是落地的
北京-喜<-> 20:41:14
业内典型的 微博就是这样做的
成都-献计献策(-) 20:41:21
cache必须保证高可用
南京-tony<-> 20:41:25
cache落地。。。也会有时延, 做不到cache实时落地吧
北京-喜<-> 20:41:34
一个是因为他的业务数据允许有损。 一个是流量
成都-献计献策(-) 20:41:45
微博说明cache还是没法完全高了用
南京-tony<-> 20:41:59
嗯，除非允许有些损失
北京-喜<-> 20:43:03
cache挂了 和 DB挂了 对业务的影响基本一样
成都-梅小西(-) 20:43:36
easy哥，淘宝现在还是这么干的么
北京-喜<-> 20:43:45
对业务而言，是不是能识别出来哪些数据是在挂掉的临界区内产生的，需要重新处理的, 这个用DB的话，你也识别不出来
北京-喜<-> 20:45:22
所有的方案都很常规 主要是那个第4点, 库存检测系统
北京-Easy哥(-) 20:45:26
上个图 说是缓存 也不是单纯的 inr 或者 der, 也是记录操作事件
如果失败了 则重新替换新节点然后 重放操作 , 大约 需要 3秒左右 , 所以 你就会看到 卧槽 支付宝挂了 , 过一会 唉 又好了 , 其实 是做了个重放[一般重放至多5秒 ].
成都-梅小西(-) 20:48:23
easy你这个图就说明cache的架构么? cache挂了还能替换新节点啊。。全自动啊[是的]
成都-梅小西(-) 20:47:31
喜神，第四点怎么了
北京-喜<-> 20:47:39
数据对齐系统啊, 才是这个里面的精华, 检测2个数据源的数据是不是一致, 订单的量数 和 库存消耗数 是不是一致, 不是的话 预警并且用订单刷库存
杭州-江(-) 20:49:32
那挂了那台的cache数据在哪里
北京-Easy哥(-) 20:49:34
然后 再加上 之前提到的 在实际支付时 才真正处理库存 保证最终一致性, 这个 小小手段 , 核心就是 数据尽可能内存化,异地备份, 顺序读写,核心理论 一篇论文 THe Log.
成都-梅小西(-) 20:50:25
@北京-Easy哥 那新节点的数据能做到一致么? [是一致的 因为我缓存的不是数据本身 而是 数据操作流程 说白了就是 log, 只要重放就完了, 流量起来以后 整个业务的设计方式 都会改变,这也是 以前为啥说 业务决定技术存活 而技术决定业务的发展]
北京-喜<-> 20:49:39
里面有提到他的BCP 平台, 就是你们看到的 秒杀系统, BCP平台 是所有做交易的系统都需要的
杭州-江(-) 20:53:19
打开了我的思路啊 以前从没见过这么玩的
成都-梅小西(-) 20:51:22
《企业IT架构》
原来支付宝的XTC系统是基于TCC
这个tcc说实话没有demo看我还是一头雾水
北京-喜<-> 20:54:34
那你没看到BCP那个， XTS 和 BCP 比较厉害， XTS 有业内门槛， BCP是交易类业务都需要的，主要是因为是平台性质
北京-Easy哥(-) 20:57:05
阿里的中台战略其实 蛮好的 ， 这个 公司是一体的 效率很高
北京-喜<-> 20:57:14
可能是天猫和淘宝这样吧， 中台战略 应该是他们从金融那里消化到的, 转化到了业务交易这边
成都-梅小西(-) 20:58:00
他们的很喜欢吹自己的中台战略
北京-喜<-> 21:01:29
中台需要对业务理解很深
成都-梅小西(-) 21:03:01
喜神你说的xts入门门槛高，是指啥, 这东西很难？
北京-喜<-> 21:03:15
这个好像是DB层的吧, 我记得
成都-梅小西(-) 21:04:39
看这书，我最佩服阿里的一点就是哪个东西用的不爽了，直接造个新轮子，对他们来说不是事儿, 光是分布式db中间件都好几个了
杭州-LuLei(-) 21:05:01
那是因为人多。。
北京-喜<-> 21:05:22
还真不是, 牛人确实比较多 公司也给施展的空间
成都-梅小西(-) 21:06:23
最后又弄了一个这个txc, 我根本看不懂。。。
北京-喜<-> 21:06:27
业务研发部门 还得挺基础技术部门才行，相辅相成, 典型分布式事务 需要有manager或者leader啊, 他们不是自己研发的组件和协议, 是改造的DB 我记得
成都-梅小西(-) 21:08:47
这个吹的有点过了吧
北京-喜<-> 21:09:29
事务和参与者的多少有关系, 就记得他有这个东西就行了, 那些数字别认真
北京-喜<-> 21:21:16
北京-张文(-) 21:24:52
下单的时候不要先判断库存是否足够吗？库存是前置条件
北京-喜<-> 21:25:32
这个不是没库存, 是库存有状态, 有个预占/冻结的状态, 售罄之后，可以采取预售，但是按照支付比，预售冻结库存的一部分, 不过这类优化 实际没什么意义, 有些公司会把库存系统挂在下单系统的前面, 库存验证通过后，才会交给下单
北京-喜<-> 21:36:57
第4步不多余, 假如RPC失败了，出于一致性的考虑 有2种方式, 这个老生常谈了。一种是补偿，一种是逆向, 这个对齐程序就是来做这个事情了。 业务编码的时候不必考虑
北京-初出茅庐(-) 21:38:13
一般都是补偿啊, 感觉 逆向一致性不好控制
北京-喜<-> 21:38:33
下单对库存 是逆向
北京-初出茅庐(-) 21:39:05
这种下单对库存 量大的时候 总感觉会慢, 一般做库存 都会多多少少业务上回控制下, 比如加入库存预警, 库存达到多少的时候 就会提醒补充库存
北京-喜<-> 21:39:28
不会慢的, 别高估自己的流量, 也别低估对齐程序的性能
北京-张文(-) 21:40:36
第4步是为了做逆向回滚用的吗
北京-喜<-> 21:40:50
对, 第10步的是 做正向补偿的
成都-凌落(-) 21:41:15
商品有先销后采和先采后销模式[我们有个业务现在2种模式一起玩。给他们的技术难傻了, 产品同学就是我不管，就要这个]
北京-喜<-> 21:41:23
9和10那里的, 并且能看到 10和11是并行的, 有由支付驱动的
2. 一个主订单下有多个子订单，子订单的粒度是同一个商品，还是单个商品数量, 这张图的意思是子订单的粒度是同一个商品, 那针对同一个商品下的其中一个商品退款，状态转移不就难以支持了？[北京-张文]
北京-喜<-> 21:58:42
不会
北京-张文(-) 21:59:19
同一个商品我买了5件，我要退2件
北京-喜<-> 22:00:24
所以有购买项的概念, 这里没画出来
北京-张文(-) 22:01:51
购买项开始规定 就是同一个商品，无论数量？退款就要全退吗
北京-喜<-> 22:02:53
一个数量一个购买项。具体看商品属性
北京-张文(-) 22:05:10
现在一个母订单下，有商品A，B，C三种，A商品买了2个，B和C买了3个。我要退A中的一个商品, 子订单表的粒度就是单个商品才能支持这样的逻辑吧.
北京-喜<-> 22:06:53
看商品类型。是虚拟类的还是实物类的, 假设是实物，比如衣服。还库存即可, 虚拟类的，可以还需要票号啥的，比如门票、机票, 就挂购买项，购买项有票好, 退的动作操作的是票/购买项, 不是订单
北京-张文(-) 22:08:59
子订单状态要流转，申请退货中->卖家同意退货->...恩，我主要考虑的子订单的状态流转和控制.
北京-喜<-> 22:10:11
这个看业务, 允许部分退 还是 整体退, 从而决定操作实体是订单还是票
成都-凌落(-) 22:19:45
先销后采的可以负库存，项目组好像是这么设定的, 先采后销必须有库存才能下单
北京-喜<-> 22:21:00
一般不是库存问题, 是优惠的问题
北京-张文(-) 22:21:16
这样下单了支付了，确没有库存？买家不会投诉？
北京-喜<-> 22:21:25
优惠的分摊和计算 比较难, 所以不允许部分退
北京-张文(-) 22:22:16
对，优惠卷下 部分退款金额需要计算
成都-凌落(-) 22:23:52
我们实现的拆单，先前考虑商品的销售模式，还有供应商的统采，直配什么的，后面都改成了，，自动拆单(库存充足了就发货)，手动拆单，人工任意拆, 我擦怎么都大同小异, 我们的优惠券, 退货的时候按比例来
杭州－东子(-) 22:26:13
拆单这种业务一直有的
成都-凌落(-) 22:26:34
我说的优惠券
北京-喜<-> 22:28:32
都要做成规则
杭州－东子(-) 22:40:14
券：按子单占总金额比例拆分，每个子单都会带上券、券编码。限品类、单品、商家券，只会分摊到满足要求的子单上。劵的规则.
上海-给你们(-) 22:42:24
最近在做 促销，听起来都一个套路
北京-喜<-> 22:42:39
券要看做薄还是做厚
杭州－东子(-) 22:43:13
应收实收那里也可以讨论一下, 还有订单的逆流程
上海-给你们(-) 22:42:52
就是一个 分摊尾差的问题
北京-喜<-> 22:44:07
不是这么简单, 当你有成人 老人 儿童 婴儿的场景, 不同人群票可以一起买, 优惠比如儿童不参加
深圳-rubin(-) 22:44:08
我前段时间就是重构 售后的算法
成都-凌落(-) 22:44:20
就是下单的后 应收多少 ？
成都-凌落(-) 22:44:25
实际收货多少？
杭州－东子(-) 22:44:34
收钱
北京-jax(-) 22:44:39
应收，实收
深圳-rubin(-) 22:45:04
订单那边不帮分摊好，都是逆向分摊
北京-喜<-> 22:45:37
收付款那个不要做到订单里, 做个账务系统
杭州－东子(-) 22:45:43
还有你退货时候对于那些免费赠品的处理，好多人薅羊毛，赠品不退了
北京-jax(-) 22:45:54
, 分摊有个问题, 加入100元，33.33 33.33 33.34退费是时候就会出现一分的情况
北京-喜<-> 22:46:10
就是这么干的, 要不你就3人减99, 一直是比例, 为毛用100
北京-jax(-) 22:46:58
缴费是合并缴费的
深圳-rubin(-) 22:47:12
100元买3件，有这种业务的
北京-喜<-> 22:47:41
给用户说明退款规则
北京-张文(-) 22:47:44
退34或33上下取整
北京-喜<-> 22:48:51
还要做财务模型, 订单账户
北京-jax(-) 22:49:25
@深圳-rubin 是这样算的，我写的就是33.3 33.3 33.4, 这种是退费会有问题, 我们的业务会按照消费的比例去退费
北京-喜<-> 22:50:01
不是啊, 你退款规则写好, 前面是除, 最后1份是总额减已退, 你面向这个规则就可以了
3. [一张订单表的设计讨论]各种累加互斥规则, 重点是你促销引擎可用度. [上海-给你们]
北京-喜<-> 22:51:50
这是谁设计的表啊, 你这个是面向业务的啊 无法扩展, 第4方进来咋办
上海-给你们(-) 22:52:34
促销 和 命中 更新频率不高
成都-梅小西(-) 22:52:55
喜神，对于薅羊毛的用户，如何有效地址
北京-喜<-> 22:53:01
风控, 薅一笔没事
成都-梅小西(-) 22:53:23
有些人几千个微信号啊，或者手机啊什么的，你咋控制啊
北京-喜<-> 22:53:30
那没办法, 要不就改业务, 识别是识别不出来的, 还有1个是银行账号, 也可以控
北京-竹竿(-) 22:54:12
和防刷一个道理，防不住的
成都-梅小西(-) 22:54:21
听说有些app没做好控制，上线一个活动，直接被羊毛党刷了好几百万, 上次群里不是有个哥们说，他们银行的app活动也被羊毛党刷了
杭州－东子(-) 22:55:03
我之前不是说了么我们给别人做的微信公众号关注就送一块钱, 一个人有几千个微信号, 关注一波就赚了几千块, 后来业务流程上改了一下, 关注之后加了操作
成都-梅小西(-) 22:55:25
想起上次群里一个人说，小数点没处理好，直接让公司损失了300万
上海-给你们(-) 22:54:02
北京-喜<-> 22:55:02
这个表可以
上海-给你们(-) 22:55:25
这张表配置可以纵向扩张，我代码只需要增加责任链就够了
北京-喜<-> 22:55:27
rule condition要做成表达式或语法
成都-梅小西(-) 22:55:50
这种规则，你们都是可配置的？直接整表达式？
北京-喜<-> 22:56:00
@成都-梅小西 多数是业务漏洞, 很多雏鸟产品设计的，技术也没注意到
上海-给你们(-) 22:56:31
福建这边出差，3天写了一个促销引擎。 这表设计的稍微有点儿简陋。
成都-梅小西(-) 22:56:59
是不是促销啊这些都要涉及规则引擎？
北京-喜<-> 22:57:48
@成都-梅小西 必须啊
杭州-绝之(-) 22:57:02
促销引擎，高大上。。。
杭州-绝之(-) 22:57:20
俺们都是一类活动一种表
成都-梅小西(-) 22:58:22
我们的促销规则都是商户自己在平台输入，限定有点死。。有些商户直接说，你们的规则配置太麻烦了.
北京-喜<-> 22:58:27
每次都要加表的话 怎么去吹牛逼和晋升啊
成都-梅小西(-) 22:58:41
换成规则引擎岂不是更麻烦
北京-喜<-> 22:58:54
必须麻烦啊,堆人搞不定.
成都-梅小西(-) 22:59:20
我们组有几个人正好重构优惠券规则这块，具体我没参与，也不知道他们的逻辑
北京-喜<-> 22:59:22
专人才搞定 所以有价值啊
成都-梅小西(-) 23:00:01
其实我没觉得说明已经写的够简洁了，他们还觉得麻烦
北京-喜<-> 23:00:43
你们可以做得更好, 做好常用的20种规则组合,让它们直接选就完了, 没有再加，加完就是模版
深圳-二绿洲(-) 23:00:06
我们公司之前做活动，注册实名认证，然后一天被薅上百万，当天晚上紧急关闭了兑奖提现接口
成都-梅小西(-) 23:00:49
实名认证还被刷了？
深圳-二绿洲(-) 23:03:37
对呀！我们是推荐别人！注册实名认证后就能积分，然后积分可以对钱，钱可以直接提现。然后有人一天推荐上万个
北京-喜<-> 23:03:56
哈哈哈, 对积分控制, 或者对活动控制, 都能阻止
北京-喜<-> 23:04:31
你这个就是我说的业务漏洞
深圳-二绿洲(-) 23:04:42
是的！业务漏洞, 当天晚上，也许老大跑到技术部，守着关闭了积分兑奖钱的接口.
北京-喜<-> 23:06:08
一群菜啊 你该喷他们.
成都-梅小西(-) 23:06:23
积分对钱 这种业务就不应该出现
北京-喜<-> 23:06:27
内部review需求方案，没review出来
上海-水货(-) 23:06:58
几乎所有的p2p都有 积分对钱 这样的业务, 这个业务本身没错.
北京-漫游(-) 23:07:12
没卡上限, 应该对单人单日有上限限制。
深圳-二绿洲(-) 23:07:26
没想到有人能找到这么多身份信息, 我们本来是180万+的用户，然后那活动开始了一天，直接就超过了200万
深圳-二绿洲(-) 23:09:25
后面就学聪明了！必须投资才可以, 而且积分只能兑换抵用券，不能兑换可以直接提现的现金
北京-喜<-> 23:09:40
哈哈, 你们产品里 没有做过ugc的吧
北京-喜<-> 23:10:31
拿积分抽现金啊, 比如1/-的中奖率, 提给你们产品, 然后-积分兑100块, 分分钟积分就耗光了, 最刺激是现金
成都-凌落(-) 23:13:13
我们优惠券也可以被当做虚拟商品卖, 开始是一个运营人员配错了，然后相关上级就开始脑洞了，然后要求我们修改功能，让优惠券作为商品卖, 需求开展的太快，开始没做审批流, 然后出问题了, 表示已经开除了几个运营了, 这里在逐步完善审批流
北京-喜<-> 23:18:23
倒也不用工作liu, 如果是修改配置，就2个版本出个diff页面，高亮被修改项, 让他确认, 新增同理.
成都-凌落(-) 23:20:13
先前一个商品的销售关系被配成了零，被卖出了十几万件商品，我们跑到数据库查看更新语录看更新的用户id找出对应的人来着
北京-喜<-> 23:20:45
配置超过的时候 alert他一下, 二次确认, 一个意思, 办法肯定有
深圳-二绿洲(-) 23:21:56
预警阀值应该可以，到达阀值，要求重复确认，或者直接拒绝
北京-喜<-> 23:22:00
以前的阈值旧了，不满足新场景了，就修改一次阈值, 阈值也可以作为规则的规则, 对于屡教不改的运营, 只能配置比如预知1000块以内的活动, 就变成规则权限了, 建立一个阈值梯度, 配上权限, 其他的需要被控制的项 同理, 有风险就建权限, 开了权限就有权利了，并不影响使用, 牛逼就是这么吹出来的.
深圳-平凡(-) 23:43:16
@北京-喜 关于财务对账这个有没什么资料分享？
北京-喜<-> 23:44:07
这个找找支付、金融的试试, 我也是昨天找到1个内部资料
深圳-二绿洲(-) 23:44:59
你这个阀值梯度+权限。很好，能避免，只是能让人引起注意这样的场景。。我记得，之前有个很大的事件，一个证券公司的股票方面[光大证券 70亿事件]，如果有这么个阀值梯度+权限，肯定就不会发生了。。
北京-jax(-) 23:45:31
@深圳-平凡 哥们做 对账，分账？
深圳-平凡(-) 23:46:54
@北京-jax 只是对账
北京-喜<-> 23:47:14
和谁之间对账
北京-jax(-) 23:50:10
三方，比如支付宝，银联，招行什么的
北京-喜<-> 23:50:44
那得有对账文件
北京-jax(-) 23:50:50
阈值，我们之前对接一个支付，阈值一千万，导致我们所有分账分失败了. 是的，支付宝有rest接口，其他银行FTP.
北京-喜<-> 23:51:59
那个是个例, 你这个预知 要加告警和调整, 分账要能重试
深圳-平凡(-) 23:57:47
有点复杂，和自己对也和存管银行对。
业务场景是p2p，公司自己出了个产品（资金端），投资者资金端去匹配到真实标的。
比如产品期限是6个月，每月固定还息，到期还本。产品募集的资金匹配到了标的。但标的还息时间不定，产品每月固定还的息可能来自于标的还的，也可能属于公司垫息，垫息则等到标的还息以后再对冲
深圳-平凡(-) 23:59:07
由于自己不懂财务知识，所以无法建立起这个对账模型。。
成都-Sêiyǎ(-) 23:59:12
如果标的还可以转让就更复杂了
深圳-平凡(-) 23:59:36
肯定可以转让的
北京-喜<-> 23:59:41
先对总账, 出了问题就得对细账, 参与的角色 和 账户分类太多了, 比支付复杂
广州-端茶倒水(-) 0:02:14
内部只能对流水了, 除非交易有二级子账号概念
深圳-平凡(-) 0:02:29
我现在在建立账户体系，尝试从账户体系的资金流向中推出。但关键还是财务知识，我都不知道要看哪些资料了, 还有一个问题，你要去了解财务对账的模式。根据财务的要求对
广州-端茶倒水(-) 0:02:45
就可以以第三方为准对
深圳-平凡(-) 0:03:14
@深圳-二绿洲 我这边财务比较弱。。产品技术过去沟通了多次，都没能明白他们要什么
深圳-二绿洲(-) 0:04:08
本地商户记录跟存管银行记录应该是一致的！你先对总账，总账不对在对明细，这样应该就可以了啊
深圳-平凡(-) 0:04:41
和银行那边肯定是能对的，只是关于这个垫息，对冲的我理不清
深圳-二绿洲(-) 0:06:03
这个财务弱，也要拉着他们一起慢慢理清，要不然没办法玩下去的
深圳-二绿洲(-) 0:07:08
纬度很多的！不梳理清楚，你会凌乱的
北京-jax(-) 0:07:13
对账应该分两个维度, 一个是平台级别的，及你们和三方, 另一个维度就是你们和用户的
深圳-二绿洲(-) 0:09:04
他这个不是与银行的对账，仅仅是财务对账。他已经说了平台流水跟银行流水是一一对应的！那说明平台跟银行的没有问题了
北京-jax(-) 0:09:36
内部要做业务对账，和财务对账.
网友评论