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

[glaz]

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

[mooyo]

合并批量提交？

[yinmin]

通过消息队列扔给多个微服务子系统并发处理

[kirory]

一个商户一个表，每个记录一行数据

[cooltechbs]

假如有 N 个虚拟服务节点，每个商户就分 N 行，每个服务实例的请求汇总到其中一行，再加一个定时更新的整体汇总行

[wxf666]

@glaz 用高性能机子，直接在数据库上操作，可行吗？


啊哩云的 MySQL 测试[^1]说：

- 1 核 1G 机器，MySQL 能 6200 读 / 秒，1800 写 / 秒。
- 16 核 64G 机器，MySQL 能 7.6W 读 / 秒，2.2W 写 / 秒。

第一种小机子，支持你 2 个类似商户，每秒千次收付款，
第二种大机子，支持你 22 个。。


[^1]: https://help.aliyun.com/zh/rds/support/test-results-of-apsaradb-rds-instances-that-run-mysql-8

[xuanbg]

哪有什么余额记录，从来都只有流水记录。余额都是在需要的时候，从流水中汇总出来的。无论你并发有多高，只要数据库能顶住写入就行。

[ymmud]

内存库

[csys]

如果你的数据库能比较好的做到单行高并发，可以测下能不能满足要求，我记得是有相关数据库方案的

不过最好还是在应用来做，在应用实现方案这边来解决这个问题，不然业务规模扩大后很难处理，这样的话技术难度会比较高一些
https://suraciii.github.io/posts/hot-spot-balance-reduce

类似#1 所说的合并批量提交，拿延迟和失败率换并发吞吐
把多个交易一起结账落库，用 actor 来控制并发冲突

[csys]

这里有个简单的数学题，如果你每次处理一个交易需要 1 毫秒，那么在最理想情况下，一个商户 1 秒就只能处理 1000 个交易，实际上远远不到

所以就不要“每次处理一个交易”

[crysislinux]

@xuanbg 没余额怎么保证不扣成负的？

[isnullstring]

消息队列

数据库内做减法

[lcy630409]

前端综合处理 前端给一个时差出来
比如 等待 转圈圈，1-2s 一般都能忍受

[jimrok]

从券商这段的系统设计来看，在报盘的时候就验证余额可用后才报单给交易所，最终账户的日终清算是从中登那边的交割记录和交易所的流水记录一起清算的。所以盘中只是对一个临时账户进行控制，并不是最终账户的数据落地。

[InDom]

实时余额通过 redis / 内存 储存计算, 初步计算通过的交易记录丢队列. 然后前端等待后端处理结果后再返回.

后端不间断扫描,每次取走积压的一批处理完毕后任务交还给队列, 前端拿到结果返回.

哪怕后端每秒扫描一次,也足够用了.

[sujin190]

6 楼说的对，这种商户收款付款的打开收支，应该流水优先，一般设计中这种场景都是需要有对账清算的流程的，所以为了提高获取余效率，可以把余额分成已清算余额和未清算余额，已清算的余额可以在对账清算时更新，未清算余额也实时通过流水获取，流水都是不可改的

关于余额扣负这个问题，单个账号流水很大的，大多数系统都存在未清算金额不可以支出的限制，这个既是技术处理的困难，同时也是你还要过风控不可以立即支出，否则反洗钱啥的法律问题叔叔分分钟找上你

对账清算可以自动也可以手动，单账户高并发大量流水没有清算对账无论从技术上看还是从法律上看都是不现实的

[qweruiop]

@InDom 高手的意思，需要做减法和检查余额够不够的时候，这个余额都丢 redis ，然后流水记录丢 db ，是这样嘛？

[jorneyr]

架构简单，逻辑简单，更多的硬件支持。

高并发的事情尽量避免复杂设计。

[yc8332]

根本不可能有你说的这种问题。。。高并发最终就是队列处理

[jonsmith]

瓶颈在哪里？如果是数据库，就上 redis 、消息队列

[InDom]

@qweruiop #16 不全对, redis 是先过滤明确不合理的请求(可能导致余额为负数的请求), 如果符合条件, 才会进入 db 层的计算, 一批一批的处理,而不是一个一个的处理.

最终数据还是以 db 为准, 另外, 我也是菜鸡, 这个方案也是我臆想的, 没有实际项目支撑.