Oracle-大型交易系统中帐户更新锁等待的解决方案

Question

现在有一个大型交易系统，用户的交易频率非常高，达到每秒上千条甚至更多，数据库用的是ORACLE11.1.0.7.0，在更新用户的帐户余额时经常会发生锁等待的情况，请教各位大虾有没有什么好的解决方案？

Answer 1

memcached对于数据的更新应该是它自己定义的，一般在读取数据是从缓存中读取，当写数据也是写在缓存，等到数据库压力较小的时候，在写入数据库。当时，使用memcached会有一点问题，就是缓存中的数据丢失的问题，而且你的业务需求还是和金钱有关的，所以，我可能不太偏向于memcached.本人对memcached的了解比较浅，有不对的地方，欢迎指出。
关于你的问题，我的想法是，将数据服务器做成集群，多台主从服务器，利用读写分离，来降低死锁问题。个人想法，请指正。
还有一种方法就是，表分区。这是听我老师给讲的，但是当表跨分区查询时，就会遇到一些问题，这一条只是提个参考方案。

Answer 2

设计上就存在点问题，余额为什么要更新呢！要从设计思路上解决的

Answer 3

赞同 成俊熠 的,这么频繁的交易放到缓存或者内存数据库中操作吧,然后异步回写到数据库中.只把数据库当做信息存储的载体,账户信息的获取和处理都和缓存或内存数据库进行交互

Answer 4

这个不建议用缓存。。。

Answer 5

上面看到一个方案是把更新数据放到memcache，感觉签稳妥。因为没有持久化的数据很可能会丢失。就算是用activemq这类消息队列（有持久化功能）也需要小心，也可能会丢失消息。我不知道你账户余额是否是真正的金钱，如果是的话，我建议更严谨些。

你的锁等待，影响的业务是读，还是写。我觉得应该是读的应用。

其实我觉得这个问题关键会是 显示的数据的一致性。我会把读写数据分离，读可以读内存数据，写的话是写数据库，当写数据库完成后，再触发更新业务数据。这样既保证业务数据一致性（利用事务），也保证了显示数据一致性。但这样是显示数据更新是准实时的，会有轻微延时。

Answer 6

优化索引、拆分表、批处理事务，批量处理提交事务比处理一条提交一条效率高很多。

Answer 7

oracle 是行存数据库，据我所知锁也是行级别的，难道你所说的交易是指同一账户每秒上千条交易？如果是这样你可以尝试修改oracle的MVCC相关参数以提高并发数量。了解不深，希望能够帮助你

Answer 8

我有一个bitcask型构思，仅供参考：
帐号余额放在内存cache中，可供并发读；对余额值的修改，以binlog或类似形式insert到db中，insert成功再修改内存的值，然后再定时（可选择交易量低时）做merge操作。这样可以保证数据一致性之余，对磁盘的随机写（update）变成顺序写（insert），性能提高不是一点半点的

Answer 9

在需要更新数据的时候，先将要更新的操作存储在队列，又或者像memcache那样的内存数据库。
然后定时批量执行。

Answer 10

我的观点是既然是余额这么重要的数据，为什么不去控制特定时间点只能一个事务去更新访问呢？在记录余额的表中加上版本号，每个进程来处理这个账户时取版本，结束后+1，如果结束是发现版本好不正确，则证明在本次计算过程中已经有其他的进程来处理过这个数据了，需要重新发出交易的请求。