wangliran1121 最近的时间轴更新 wangliran1121 最近的时间轴更新 |
wangliran1121V2EX 第 418540 号会员，加入于 2019-06-04 10:44:39 +08:00 |
wangliran1121 最近回复了
27 天前 回复了 lolicondmw 创建的主题 › Android › 小米狠狠的羡慕 VIVO 用户了 |
@ririliu 我建议你先别急，好好体验一番，originOS 够小米澎湃 OS 学一阵
27 天前 回复了 lolicondmw 创建的主题 › Android › 小米狠狠的羡慕 VIVO 用户了 |
@ririliu “难道全网就我一个人用到真小米？”
33 天前 回复了 lolicondmw 创建的主题 › Android › 小米狠狠的羡慕 VIVO 用户了 |
@ririliu 急什么呢？我不是真金白银买了小米和 vivo 认真体验了一番下的结论吗
目前国产最优解就是 OV
37 天前 回复了 lolicondmw 创建的主题 › Android › 小米狠狠的羡慕 VIVO 用户了 |
曾经小米 14pro 用户，换成 vivo x100 ultra 后，就是一种解脱，非常舒服
321 天前 回复了 Hatter 创建的主题 › Java › 请教下 Java 的 volatile 以及一点多线程的疑问 |
2024-10-17 09:30:59 +08:00 回复了 glaz 创建的主题 › 程序员 › 单用户余额高并发支出收入有啥好方案？ |
@wxf666
1 、对于这种交易场景，对账是必须存在的过程，这是一种风控手段，T+1 只是举例子，也可以 T+1min ，所以用户看到的余额清算是稍微不准确的，有些延迟的，这点业务上一般可以接受；
2 、另外，另一种风控要求就是政策和法律，每一笔入账可能都要经过企业内部的风控模型审核完后才能入账，可以是机审，也可以是人审，总之无论政策还是企业都会有这样的要求（换句话说，企业必须要有能力判断一笔账是否异常）
3 、你担心正确性，一般事务性可以保证，但是应付一些极端问题，你通过对账也能修正回来
4 、题目意思就是单个商户高并发读写的场景，因此按照你的设计，只能是串行，设计思路可行，但是于题意而言，不太符合场景；
5 、你测试的只是写请求，但是按照你 45 楼的设计思路，实际上一次入库是需要经历一次完整的读写的，你不读上一笔流水的余额，怎么计算下一笔流水的余额呢？另外，你也不支持并发读，意味着你整套读写过程是串行的，代价十分高昂
1 、对于这种交易场景，对账是必须存在的过程，这是一种风控手段，T+1 只是举例子，也可以 T+1min ，所以用户看到的余额清算是稍微不准确的，有些延迟的，这点业务上一般可以接受；
2 、另外，另一种风控要求就是政策和法律，每一笔入账可能都要经过企业内部的风控模型审核完后才能入账，可以是机审，也可以是人审，总之无论政策还是企业都会有这样的要求（换句话说，企业必须要有能力判断一笔账是否异常）
3 、你担心正确性，一般事务性可以保证，但是应付一些极端问题，你通过对账也能修正回来
4 、题目意思就是单个商户高并发读写的场景，因此按照你的设计，只能是串行，设计思路可行，但是于题意而言，不太符合场景；
5 、你测试的只是写请求，但是按照你 45 楼的设计思路，实际上一次入库是需要经历一次完整的读写的，你不读上一笔流水的余额，怎么计算下一笔流水的余额呢？另外，你也不支持并发读，意味着你整套读写过程是串行的，代价十分高昂
2024-10-16 19:29:03 +08:00 回复了 glaz 创建的主题 › 程序员 › 单用户余额高并发支出收入有啥好方案？ |
@wxf666 补充一点，高并发的思路是尽可能少串行化。
2024-10-16 19:26:41 +08:00 回复了 glaz 创建的主题 › 程序员 › 单用户余额高并发支出收入有啥好方案？ |
@sujin190 是的，redis 会引入更大的系统复杂度和风险，如果业务真这样，其实不需要考虑成本问题，其实金融级别的分布式数据库可以解决这些潜在的事务问题，比如 TiDB 之类的
2024-10-16 19:24:50 +08:00 回复了 glaz 创建的主题 › 程序员 › 单用户余额高并发支出收入有啥好方案？ |
@wxf666
1. 为啥不直接在用户表里，记录实时余额呢？是因为 支出次数 <<< 收入次数，写压力小，还满足风控吗？
--------
我理解，直接用用户表也是需要一个对账过程，增加 T+1 的限制，仅仅是因为给对账留足冗余时间。因此每日或者说定时从明细流水中计算余额这一步操作（对账操作），实际上是不可少的。
2. 23:00 时，用户查看余额，你要汇总当天 1.66 亿条流水，计算余额吗？
--------
定时汇总，自然不必每次都汇总查询当天所有流水，因为 T+1 的限制，只需要查 balance 字段就可以知道余额了，当然实际业务不一定是 T+1 ，这里只是举例子，可以是 10min 延迟，可以是 1min 延迟，看业务可接受度。
3. @sujin190 的思路，在有支出时，user_balance 也是不变的。而是每笔支出，都查 (SELECT SUM(amount) + 该笔支出 FROM user_transaction WHERE uid = ... AND create_time >= 今天) 是否 <= balance 。
--------
每次汇总查在应付大并发读的场景下，肯定不太合适，我理解 @sujin190 他说的尽可能保证正确性的同时再考虑性能优化，首先不可否认，从明细中查询余额的做法，正确性是可以保障的
4. 你觉得 45 楼，流水表里记录实时余额，完全免除额外写压力，思路如何？
--------
这种思路也是可行的，但是要求是数据绝对串行，流水务必一条一条入库，这样最新一条流水即可表示最终余额，如果放到大并发写场景下，也不太合适，总之一切，“看菜吃饭”
1. 为啥不直接在用户表里，记录实时余额呢？是因为 支出次数 <<< 收入次数，写压力小，还满足风控吗？
--------
我理解，直接用用户表也是需要一个对账过程，增加 T+1 的限制，仅仅是因为给对账留足冗余时间。因此每日或者说定时从明细流水中计算余额这一步操作（对账操作），实际上是不可少的。
2. 23:00 时，用户查看余额，你要汇总当天 1.66 亿条流水，计算余额吗？
--------
定时汇总，自然不必每次都汇总查询当天所有流水，因为 T+1 的限制，只需要查 balance 字段就可以知道余额了，当然实际业务不一定是 T+1 ，这里只是举例子，可以是 10min 延迟，可以是 1min 延迟，看业务可接受度。
3. @sujin190 的思路，在有支出时，user_balance 也是不变的。而是每笔支出，都查 (SELECT SUM(amount) + 该笔支出 FROM user_transaction WHERE uid = ... AND create_time >= 今天) 是否 <= balance 。
--------
每次汇总查在应付大并发读的场景下，肯定不太合适，我理解 @sujin190 他说的尽可能保证正确性的同时再考虑性能优化，首先不可否认，从明细中查询余额的做法，正确性是可以保障的
4. 你觉得 45 楼，流水表里记录实时余额，完全免除额外写压力，思路如何？
--------
这种思路也是可行的，但是要求是数据绝对串行，流水务必一条一条入库，这样最新一条流水即可表示最终余额，如果放到大并发写场景下，也不太合适，总之一切，“看菜吃饭”
Select Language