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

合并批量提交？

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

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

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

用高性能机子，直接在数据库上操作，可行吗？啊哩云的 MySQL 测试¹说：- 1 核 1G 机器，MySQL 能 6200 读 / 秒，1800 写 / 秒。- 16 核 64G 机器，MySQL 能 7.6W 读 / 秒，2.2W 写 / 秒。第一种小机子，支持你 2 个类似商户，每秒千次收付款，第二种大机子，支持你 22 个。。¹: help.aliyun.com/zh/rds/support/test-results-of-apsaradb-rds-instances-that-run-mysql-8

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

内存库

如果你的数据库能比较好的做到单行高并发，可以测下能不能满足要求，我记得是有相关数据库方案的不过最好还是在应用来做，在应用实现方案这边来解决这个问题，不然业务规模扩大后很难处理，这样的话技术难度会比较高一些 suraciii.github.io/posts/hot-spot-balance-reduce类似＃1 所说的合并批量提交，拿延迟和失败率换并发吞吐把多个交易一起结账落库，用 actor 来控制并发冲突

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

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

消息队列数据库内做减法

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

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

实时余额通过 redis / 内存 储存计算, 初步计算通过的交易记录丢队列. 然后前端等待后端处理结果后再返回.后端不间断扫描,每次取走积压的一批处理完毕后任务交还给队列, 前端拿到结果返回.哪怕后端每秒扫描一次,也足够用了.

6 楼说的对，这种商户收款付款的打开收支，应该流水优先，一般设计中这种场景都是需要有对账清算的流程的，所以为了提高获取余效率，可以把余额分成已清算余额和未清算余额，已清算的余额可以在对账清算时更新，未清算余额也实时通过流水获取，流水都是不可改的关于余额扣负这个问题，单个账号流水很大的，大多数系统都存在未清算金额不可以支出的限制，这个既是技术处理的困难，同时也是你还要过风控不可以立即支出，否则反洗钱啥的法律问题叔叔分分钟找上你对账清算可以自动也可以手动，单账户高并发大量流水没有清算对账无论从技术上看还是从法律上看都是不现实的

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

架构简单，逻辑简单，更多的硬件支持。高并发的事情尽量避免复杂设计。

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

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

＃16 不全对, redis 是先过滤明确不合理的请求(可能导致余额为负数的请求), 如果符合条件, 才会进入 db 层的计算, 一批一批的处理,而不是一个一个的处理.最终数据还是以 db 为准, 另外, 我也是菜鸡, 这个方案也是我臆想的, 没有实际项目支撑.

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

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

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

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