单用户余额高并发支出收入有啥好方案？

[glaz]

比如一个商户一秒一千笔收入记录和一千笔支出记录，咋处理比较好。

[fengYH8080]

@crysislinux 他这个没有余额的意思是不存储于持久化数据库中，也就不存在频繁的余额变更数据库操作，只有流水的写入操作，在需要的时候通过流水汇总出来余额这个值，就能在内存里根据这个余额去做逻辑限制。
两种设计方式适用不同性质的系统，我之前就设计过不需要记录余额的系统，处理逻辑会稍微复杂点，好处就是系统中只有流水这一个概念

[snitfk]

同一个商户在一秒内这么高的并发？这是给量化服务吗？你们这系统就只服务一个商户？如果商户量增加了，你这架构要处理的量级就马上上升了。

[8355]

不要瞎想，这种业务就是流水插库，你只需要保证执行顺序符合预期就行，使用消息队列进行消费即可。
收入是流水表字段正数
首先你要从客观上去理解这个业务，按正常来说是收入大于支出还是支出大于收入，不可能两个一直差不多数量。
交易类的业务会有一个结算周期，不可能实时结算，包括提现都是有周期的，就是为了减少因为银行/网络延迟等客观原因导致的延迟存在。

[ForMrFang]

@xuanbg 交易时实时从流水汇总查询余额的话,会不会比较慢.

[wxf666]

@fengYH8080 #21 每一笔支出，都需要余额吧？否则咋知道，能否继续花钱呢？


@sujin190 #15 意思是说，只能花已清算账目后余额内的钱吗？

如果每天清算一次，清算后还剩 1W 块，第二天可以花无数笔 < 1W 元的支出？

还是说，23:00 的一笔支出，需要计算（ 00:00 ~ 22:59 的余额 + 已清算余额）>= 支出金额，才能花钱？

按楼主所说，每秒 1000 笔收入 / 支出，那该笔支出，就要算当天 1.66 亿次交易，得出未清算余额？？？

[sujin190]

@wxf666 #25 只能花已经清算的余额 1w ，也就是<=1w 的钱，这个就是账期，1 天其实大多数商户都能接受

如果你做的是收单那风控和清算是必需的，否则你很可能会面临法律风险
如果你只是对接支付宝微信支付，这么大流水清算对账也是应该考虑的，虽然风控的事情支付宝微信帮你干了，但是毕竟我们自己的服务器和微信支付宝并不是在一起的，万一程序有点啥未知 bug ，那就有可能直接要破产倒闭了还可能面临债务
通过清算对账延迟一点对大家都好，商户看到的余额反正是实时的，并不会收这个账期影响，只是并不能立刻支出这部分钱罢了，而且现实中正常交易都是要么小额收入大额支出，要么大额收入小额支出，小额大量收入同时支出的貌似大都不是正常生意哈

[fengYH8080]

@wxf666 #25 可以简单理解为余额从持久化数据库抽到了内存中，可以解绑掉流水 + 余额的数据库层原子操作。看到这种设计第一印象都会觉得每次汇总一个人的余额非常耗资源，很多处理方式都可以避免的，简单点的可以通过中间表固定时间汇总好之前的余额，汇总实时余额只要这个时间点的余额记录和这个时间点之后的流水做汇总就好了。所以才说这个设计逻辑会复杂点。

[julyclyde]

@crysislinux 确实不能保证不扣成负的
所以信用卡有所谓超限费（罚款）这么个项目

[guanhui07]

高并发最终就是队列处理 顺序 消费 慢慢排队

[Jackm]

收付款用微信支付宝呀，他们有提供接口。像这种级别的给别人交点手续费就交点吧。

[dapang1221]

高并发收入可以理解，但高并发支出……？比如高并发 10 笔的峰值，那这 10 笔其实可以排队在 1 秒内处理完成。但如果说连续 1 小时，每秒里都有上百笔支出……真的有这种场景吗，除了券商高频交易这种

[ivvei]

这也不多啊，你要设计啥？

[wxf666]

@fengYH8080 #27 《汇总实时余额 = 上次汇总余额记录 + 上次汇总时间点之后的流水累计余额》，

像上面所说，每天汇总一次的话，23:00 时，当天有 1.66 亿 笔未汇总流水。那计算一次余额的代价，是不是太大了。。



@sujin190 #26 是第二天内，能花无数笔 <= 1W 的钱吗？还是累计最多 1W 的钱？

前者不可接受。后者怎么实现呢？每一笔支出，都检查当天流水吗？像上面所说，23:00 时，当天有 1.66 亿 笔流水，这。。

另外，商户看到的余额，也是（已清算 1W 余额 + 当天 1.66 亿笔流水余额）吗。。这。。

[fengpan567]

kafka 消费

[sujin190]

@wxf666 #33 你这个提的就没道理好吧，当天能有 1.66 亿笔流水么！！每天数百亿上千亿的流水？瞎想可不行，真有这么多，清算对账流程还需要比这复杂得多得多，我说的这种能可靠风险低每天处理数百万千万级流水就不错了，想着小学数学解决登月这就不显然扯淡么
每天几万笔可以用余额加减，这种上亿笔的流水就不可能有简单有可靠又风险低的方案，毕竟就算百万级的异常率，每天损失也高达数百万，亿级别的异常率可不是轻易就能做出来的，不要想着有银弹解决所有问题

[qh666]

@sujin190 标题说的 一个商户一秒一千笔收入记录和一千笔支出记录 24x60x60x1000x2 不就是 1.7 亿多么

[luckyrayyy]

@dapang1221 有的，大主播的退款

[dapang1221]

@luckyrayyy 哪种退款呀，打赏充值还是商品退款。一般退款不是支付，是冲正，用户发起退款，平台接受，平台向支付发退款请求，支付平台给这一单直接标记退款不结算就行了，不涉及主播余额变化

[sujin190]

@qh666 #36 虽然如此，但是有实际工程经验的都知道没有这么算的吧，峰值容量 1000 但是能稳定维持这量级 7 、8 小时都已经牛逼顶天了，实际情况也就 3 、4 小时能有这量级，我们设计不是在这空中阁楼的瞎意淫而是需要充分考虑实际工程情况和使用场景的，不考虑实际工程情况和使用场景的设计必定是不靠谱的，再说按你这每天数百亿上千亿的流水，就在这几句话就讨论出可靠的解决方方案这也不现实啊，楼主估计想问的也不是这使用场景吧

[fengYH8080]

@wxf666 #33 就按你这个说法，你觉得 1.66 亿次的数据库级别的余额变更消耗大点还是一次的汇总消耗大点。再细抠技术细节，到达了这个数量级的系统，已经不是单机能解决的了，需要多机分布式计算。一个人一天都有这么大的量，存储必是要分库分表，汇总时定好时间节点多机后台计算，在具体写入中间汇总表的时候锁一下，把汇总结果和增量未汇总的记录再汇总一下写入内存余额。