像银联的刷卡消费pos系统，在软件架构上是怎么解决并发量大时死锁问题的。，是用lock(){所执行的代码。。。},类似这种的锁来解决并发时的死锁吗。有没有更好的方法。
------解决方案--------------------------------------------------------
数据库分区
虽然整体系统是并发的。但是对于某个账户，同时请求的并不多。
------解决方案--------------------------------------------------------
（1）现在的数据库大部分都是行级别锁
（2）刷卡消费的并发不大呀。好像有个主副卡，也就2个并发吧。
------解决方案--------------------------------------------------------
刷卡都有大量并发就该报案了...
------解决方案--------------------------------------------------------
从描述上看，最好检查一下在数据库写入过程中事务中的相关select操作， 这时是加锁的时候，尽量把select移出到事务外面，或者使用nolock脏读，（不做脏读可能引起逻辑问题），如果你使用了事务嵌套，那整个嵌套中的select都要查，这多半是业务逻辑的bug。