1

放内存或者 redis ，定期写入数据库

2

时序数据库或不可变数据库？反正用插入替代修改应该就能解决。

3

1

1. 放内存或者 redis 。不过保持数据一致性需要额外开销
2. 数据库存储用本地高速磁盘，比如 NVME
3. 如果是 pgsql 数据库
3.1 字段 FILLFACTOR 设定很小值（比如 1 ）提高写入性能
3.2 关闭 full page write 开关（需要磁盘磁层有相应的安全措施，比如 ZFS 文件系统）
3.3 关闭 sync 同步写入（需要磁盘磁层有相应的安全措施，比如 UPS 、阵列卡电池）

4

2

6

1

有没有大佬解释下为什么 1 秒更新上百次就会卡顿死锁

7

8

可不可以请假下是什么业务场景，怎么压力都堆到 DB 来了？

11

12

@CEBBCAT 确实没见过这种，这种高频数据写入场景只在物联网中遇见过，用的也是时序数据库。。。

13

这不跟交易系统一样了，已经不适合用 mysql 实时存储了，都是放内存数据库，再延时落地 mysql 。

15

楼上大佬给的方案已经足够多，但是刚又想到一种。如果价格是可预知的，提前生成出来所有可能的值应该也能解决。具体的最好能把场景贴的太详细一点

16

18

@lasuar 写内存不好保持一致性吧。 如果内存突然挂了，交易丢失是很严重的事故。 不是很懂，望讨论。

19

可以维护一个 token 池子 这个池子的 token 可以一次性生成, 可以随时补充, 每个 token 对应一个价格, 然后预扣, 最后统计池子中没用的 token 余额加回就好了..

20

1

@pony2335 #18 既然是写内存，那这种数据肯定是允许丢失的，比如 1s 中变化上百次的字段，丢失其中第 99 次的数据并不影响什么，因为系统恢复后，马上又会收到最新的数据。
如果发生交易，那交易记录是从内存中获取实时价格，然后记录本身要入持久化数据库的（而不是写内存）。

21

3

设计的就有问题，为啥都要并发修改在数据库层面，正常不是缓存层面加锁控制数量金额等，业务交互在数据库之前走完了，数据库只是记录最终结果。然后再改数据库，而不是直接操作数据库，任何性能问题都是架构层面的问题，不是改个啥代码能解决的，除非屎山代码

22

@miaomiaotu Redis 不是单线程执行的吗，为什么要在缓存层面加锁控制？如果确实要做业务流程编排，感觉可以把这部分的控制放到 Lua 脚本里面去控制。

23

@miaomiaotu 再就是 Redis 和 数据库数据的一致性该如何保证咧 ？ 就是存在 Redis 挂了的情况？

25

@godall 更新改为插入新记录无法解决并发写入的一致性问题吧：UPDATE SET val+10 ，这个 val 怎么确保是最新记录呢？

27

用 hazelcast 或 redis

28

用 redis 然后 定期刷入 db

31

1

把你的问题拿去问 deepseek R1 ， 给的答案比评论区大部分方案靠谱。

32

同一个字段没关系，不是同一行的就没问题，降低锁的粒，表到行到页。前提能准确定位，又不产生共享锁。

33

34

肯定是股票~期货~外汇~数字货币呗，报价随买卖单对挂单的撮合而动，mysql 做不到的，直接用缓存之类的放内存里面。

35

将多次 update 的行锁请求合并到一次上。比如启动一个异步线程和引入一个时间窗口，对这个窗口内的所有请求扣减金额进行相加，进行一次 update 。然后进行多次 insert 操作记录扣减日志，发生异常根据日志情况进行回滚

36

@Asheet 如果合并请求后预计总共扣减的金额和超过了表里面这个字段上的值，那该怎么处理

38

换一个技术牛逼点的架构师

39

@mark2025 #25 楼主想表达的可能是引入“账单”概念，以此把并发 update 写转化为并发 insert ，从根源上规避了高并发操作同一行的场景，计算余额对所有操作行做累加即可

41

要是设计表的时候，主键字段设置的是数据库自增，那还能提升写入的并发吗

42

确定有死锁，那就排查一下死锁原因，正常情况每秒几百次的单行 update 是吃得消的

44

AliSQL 这个源码不建议用了，没人维护的，一定要用，可以用 PolarDB-X Engine 这个代码，我走的时候还有团队在负责。

45

@nicoley 加分布式锁，先改缓存，缓存成功再改数据库，一致性保证就行，查询什么的走缓存，然后数据库做主主复制或者主从，再加读写分离，这样方案扩展性强，前提是技术到位再加上服务器到位，完美方案，最主要的是把数据库的读压力和写压力分开，数据库在并发读时候出现锁表问题很低，但是加上并发写就会出现，所以最终目的还是数据库读写分离加上压力在缓存层解决，完美，服务器要给力，不然是累赘这个方案

46

@nicoley 如果架构层次解决不了，只能改业务代码那块，那么就使用乐观锁机制，把事务内部代码减少，尽量一个事务内就是单独修改哪个金额数字，减少事务时间，再加上修改时候尽量走索引这样行锁，避免锁表，这样也可以，但是都是拆东墙补西墙方案，不是最终的，最终的还是之前架构方案

48

49

1 秒上百次的写，肯定也得 1 秒上百次读出来，纯 update 写本身毫无意义的。纯数据库方案即便各种方式写进去了，也是读不出来。比如 1 2 3 4 5 6 7 ，读出来就可能是 1 1 1 6 6 。读写都不落数据库是最好的方案，然后再搞个消息队列往数据库里塞海量的价格变动日志，供离线分析。

50

1

@CEBBCAT 感觉是和景区对接，并不是单行过百，而是该字段更新频率过百。国内这个体系的盲猜长隆集团对接

51

只是高频更新不会导致死锁, 建议先把死锁的问题修好再看.