@wangliran1121 #51

1. 是因为害怕，交易过程有 BUG ，会算多余额。失之毫厘，往后谬以千里吗？
所以需要设定，支出上限为昨日余额？那会不会也害怕，今日交易过程也有 BUG 呢。。

2. 用户看余额，应该是《实时》余额吧。。但汇总频率加快成几分钟，应该就不太介意了。。

3. 交易过程只写在一处，甚至写成存储过程，再疯狂并发测试几十上百亿次，可以尽量保证正确性吗？

4. 单个用户是串行，但可以多个用户同时交易吧。。（间隙锁范围，只是该用户现在 ~ 未来？）


5. 现在有点怀疑，会不会只支持串行化，并发数量能更高呢？（免去了很多锁之类的开销？）

我半个月前测试过，SQLite 在 1.3 亿 100 GB 数据时，仍能 1W 随机写事务 / 秒。。

设备是六七年前的轻薄本 + SATA 低端固态，Python 单线程 16 MB 内存完成的。。

源码发在当时的[帖子]( /1075881#reply68 )里了，可以去测试一下。

@zhady009 #26

连 wrk 都能用 10 线程，Vertx 本身是用了二三十个线程吗？

100 个 TCP 连接，占不了啥内存吧。。每个 4KB ，也就是 400 KB 这样？

@wangliran1121 #48

1. 为啥不直接在用户表里，记录实时余额呢？是因为 支出次数 <<< 收入次数，写压力小，还满足风控吗？

2. 23:00 时，用户查看余额，你要汇总当天 1.66 亿条流水，计算余额吗？

3. @sujin190 的思路，在有支出时，user_balance 也是不变的。而是每笔支出，都查 (SELECT SUM(amount) + 该笔支出 FROM user_transaction WHERE uid = ... AND create_time >= 今天) 是否 <= balance 。。

4. 你觉得 45 楼，流水表里记录实时余额，完全免除额外写压力，思路如何？

@NewYear #12

那现在能稳定找到，支持 XP 的新硬件（主板、CPU 等）吗？

如果不能，工厂、银行等的机器一出故障，岂不就要停摆好久？



使用新硬件、系统、软件，能获得优越感的原因，我猜测可能有：

1. 新硬件性能更强。身手快的，就是瞧不起慢吞吞的。
2. 新设备能使用更广泛的软硬件。人无我有的稀缺性，能得到其他人的羡慕。
3. 厂商赋予的情绪价值。比如更安全、更潮流、更方便等，再来个停止旧用户更新，让新用户高旧用户一等。
4. 展示财力。新东西往往更吃配置，设备更贵。
5. 展示能力。表示自己能及时适应新设备、功能等，学习能力更强。

@reea #10 这年头，还有这么多支持 XP 的主板、CPU 吗？

超出年限这么多，也不更换吗？不怕机器故障坏掉，数据出错啥的吗。。

@fengYH8080 #40 不是《一次》汇总，是当天《每一笔》都要这么汇总一次，来查余额。。


@sujin190 #39
@fengYH8080 #40

你们觉得，在存储每笔流水时，顺便在这笔流水存当前余额，如何？

根据 5 楼，啊哩云对 MySQL 的测试，读速大约是写速的 3 ~ 4 倍。

因此每写一条流水时，额外读一下最新流水记录，取其中余额，加上本次金额组成最新余额，性能损耗应该不大？

而且，最新流水记录，和即将新生成的流水记录，大概率是临近位置的，应该能利用上 Buffer Pool 里的缓存？所以读损耗进一步减小？



具体来说，主键设成（用户 ID << 42 | 毫秒时间戳），那么添加一笔支出，SQL 大致如下。

要知道是否添加成功，可以检查插入了 0 行还是 1 行。前者大概率是余额不够所致。


```sql
INSERT INTO 流水 (流水 ID, 金额, 这笔流水后用户余额, ...)
SELECT
　(用户 ID << 42 | ${当前毫秒时间戳}),
　${金额}, -- 支出，应该是负数
　(该用户最新流水记录.这笔流水后用户余额 + ${金额}) AS 该笔支出后余额
FROM (
　 SELECT 这笔流水后用户余额
　 FROM 流水
　 WHERE 流水 ID BETWEEN (用户 ID << 42) AND (((用户 ID + 1) << 42) - 1)
　 ORDER BY 流水 ID DESC
　 LIMIT 1
) AS 该用户最新流水记录
WHERE 该笔支出后余额 >= 0
```

@xxss0903 #6 这年头，还有这么多支持 XP 的主板、CPU 吗？

超出年限这么多，也不更换吗？不怕机器故障坏掉，数据出错啥的吗？

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

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



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

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

另外，商户看到的余额，也是（已清算 1W 余额 + 当天 1.66 亿笔流水余额）吗。。这。。https://i.imgur.com/krir4IG.png

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


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

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

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

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


https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@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

@BarackLee #4

1 核 1G 的机器，MySQL 能跑 40W QPS ？

还是 40W Q/Minute ？即，6000 QPS ？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

不懂就问，`d.set('name', 'tom')` 比 `d['name'] = 'tom'` 好在哪儿呢？

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@supergeek1 #9
@PRStarDust #11

小米三指划一下屏幕，就能截图了。。

@icaolei #175

查了下，烟民有 3.5 亿，司机有 4.8 亿，B 站月活用户 3.4 亿，应该是同一数量级的呀？

其他文字图片站，带宽需求比视频站小多了，影响应该不大？

@old9 #168 同意。

很多人以码率为准，真看到二十多年前 10 Mbps 的 480p MPEG2 的 DVD ，还看得下去吗？

我挺推崇更小码率，达到更好清晰度的。（是叫《高压》吗？）

@icaolei #167 烟、汽油等税高，好像也没见禁止讨论呀。。

甚至还经常见到，航母是烟友抽出来的这种说法。。

带宽为何就特殊了呢？

@rick13 #76 挖到就挖到呗，烟、汽油等税也高，也没咋样呀。。宽带又能特殊到哪儿去呢

@tool2dx #51
@winterbells #130

对平台来说，转码成本还很高昂吗？

发展了这么久，还没有高质量硬件转码方案吗。。

民用最舒服的，是 Intel 的核显了吧。。能媲美 x265 medium 质量