每天会扣前一天租客产生的水电费用。有一个账户余额表,需要每天进行扣除。
因为每位租客产生的水电都是不一样的,假如有一千万位租客,那就是一千万条账户余额扣费的 UPDATE 语句,请问有什么办法进行优化这段处理逻辑吗,还是必须只能用要产生一千万条 SQL 的 UPDATE 语句方法
1
chotow 2022-08-08 13:16:00 +08:00
我会考虑改为插入一千万条费用记录,每个用户查看自己余额的时候再实时计算一下
|
2
Fuor 2022-08-08 13:34:04 +08:00
有记录每天产生水电费的客户记录的话,扔到队列一个个单独计算?
|
3
08110920 2022-08-08 13:35:36 +08:00
队列处理
|
4
baobaoyinshen OP @chotow 这个方法不太行,因为有时候运营人员需要导出账户欠费人员,不能导出的时候再来实时计算把
|
5
jackma0571 2022-08-08 13:39:22 +08:00
没错,0 点过后一个一个计算
|
6
lakehylia 2022-08-08 13:43:57 +08:00
半夜跑批处理
|
7
eason1874 2022-08-08 13:54:08 +08:00
都有一千万租客了,难道买不起像样的服务器吗,数据库事务分批处理就行了
|
8
fiypig 2022-08-08 13:54:49 +08:00
凌晨跑就可以了
后期可以使用预付费水电表,也蛮方便的 |
9
reallynyn 2022-08-08 15:02:45 +08:00 1
无外乎业务逻辑优化,系统架构优化,数据库优化三种办法。
业务逻辑优化,就是尽量不要做这种大规模 update 业务。 系统架构优化,比如增加缓存层,数据先写到 redis 这种内存库里面,再慢慢 flush 。 数据库优化,就是引入分布式数据库,或者分库分表的方式,提升数据库并发性。 再往下,就是数据库 feature 了。比如有的数据库会利用 B+树大块读写的特性,把硬盘中一个簇的数据尽量收集起来写,减少磁头寻道次数。 |
10
xuelu520 2022-08-08 15:08:25 +08:00
半夜跑。
扣费+扣费日志,update+insert 少不了。 另外扣费还得开启事务。所以只能队列跑了。 |
11
bk201 2022-08-08 15:22:56 +08:00
你也不需要 update 吧,借贷记帐就行,最后要拉出来的时候借贷差值计算下就行
|
12
Jooooooooo 2022-08-08 15:24:38 +08:00
一个一个算有啥问题吗, 只更新一千万次也并不多.
|
13
james2013 2022-08-08 15:37:59 +08:00
凌晨定时任务跑
批量处理,比如每次批量处理 100,甚至 1000 的租客扣费操作 |
14
singerll 2022-08-08 15:46:50 +08:00 via Android
一千万租户你知道什么概念吗。
|
15
Light3 2022-08-08 16:29:35 +08:00 2
大哥 咱估计就 500 的量 就不要想 1000w 的事了..
|
16
imn1 2022-08-08 16:46:31 +08:00
每天每人一条记录,其实频度极低
|
17
xiaochong0302 2022-08-08 18:09:18 +08:00
@Light3 扎心
|