日期:2014-05-20  浏览次数:20686 次

高并发实时储值消费系统应如何设计。
公司近期准备竟标一个连锁店储值方面的系统,客户要求是支持最少2000家店同时工作,要求操做流畅,并且支持高并发时的用户储值和用户持卡消费。现在公司做了个测试模型,当并发量将近100时,出现数据死锁,死锁引起无法持卡消费,无法储值。通过进一步优化sql 语句和程序。提升了一小部分的性能,但在并发大时,还是出现死锁,请问像这种高并发的实时储值系统应如何设计。请高手指教谢谢。

------解决方案--------------------
我猜所谓“并发100时”,你的问题并不是出自简单的读写数据库,而是过于复杂的存储过程的问题上。这类问题的解决方法有三个方面:
1. 查询数据时指定数据库事务级别为ReadUncommitted。(而不是默认值)
2. 从业务逻辑上要将基本数据的读写与一些复杂的计算分开。比如在数据库中使用 Service Block 方式执行计算,而不是同步计算;比如将一些计算调整到夜间,或者系统空闲的时候,而不是立刻开始计算;比如将数据库方面分隔为不同的SOA系统,而不是在一个系统上实现。
3. 缓存会大大减少读取数据库的压力。
------解决方案--------------------
查询数据时指定数据库事务级别为ReadUncommitted --> 查询数据时指定数据库事务级别为Snapshot

或者在sql语句中写上 with(nolock)。
------解决方案--------------------
我觉得你这个优化的空间应该在业务逻辑上。