公司近期准备竟标一个连锁店储值方面的系统，客户要求是支持最少2000家店同时工作，要求操做流畅，并且支持高并发时的用户储值和用户持卡消费。现在公司做了个测试模型，当并发量将近100时，出现数据死锁，死锁引起无法持卡消费，无法储值。通过进一步优化sql 语句和程序。提升了一小部分的性能，但在并发大时，还是出现死锁，请问像这种高并发的实时储值系统应如何设计。请高手指教谢谢。
------解决方案--------------------------------------------------------
我猜所谓“并发100时”，你的问题并不是出自简单的读写数据库，而是过于复杂的存储过程的问题上。这类问题的解决方法有三个方面：
1. 查询数据时指定数据库事务级别为ReadUncommitted。（而不是默认值）
2. 从业务逻辑上要将基本数据的读写与一些复杂的计算分开。比如在数据库中使用 Service Block 方式执行计算，而不是同步计算；比如将一些计算调整到夜间，或者系统空闲的时候，而不是立刻开始计算；比如将数据库方面分隔为不同的SOA系统，而不是在一个系统上实现。
3. 缓存会大大减少读取数据库的压力。
------解决方案--------------------------------------------------------
查询数据时指定数据库事务级别为ReadUncommitted --> 查询数据时指定数据库事务级别为Snapshot
或者在sql语句中写上 with(nolock)。
------解决方案--------------------------------------------------------
我觉得你这个优化的空间应该在业务逻辑上。