请大侠看看所写方案能否解决并发性能上的问题

[ludingping]

问题表现：
某票务系统由于时间紧凑，在换票工作与验票工作交织在一起。就出现了系统反应变慢，部分客户端就出现了不能实时的完成所提交给系统的工作，出现延时或者掉线的问题。
主要的是在高峰期时系统所需处理的事务数。我们有4个换票客户端，1个零售客户端。以一个普通换10张门票的请求为例，需要创建一条换票订单交易记录和 10条门票交易记录，同时还要更新10门票状态记录，以及1条预订订单记录信息。期间为了验证门票的状态，还要进行10次门票的查询操作。因此该事务将会处理很长一段时间。 我们在此称这样的事务为大事务，5个客户端如果在同一秒都提交请求，将会产生5个大事务待处理。
同时验票过程中也会产生验票事务请求服务器响应。以6个验票客户端为例，在高峰期每个客户端每秒验票2张，就会产生12个验票小事务。
这时如果5个售票客户端同时都提交大事务的话，验票端将出现拥堵，就会出现延时的情况，同样的，由于验票速度很快，会源源不断的产生验票请求，这样就会让换票处的请求得不到响应，到一定时间内就会出现超时而掉线的现象。
原因分析：
通过分析，系统反应速度变慢主要由于两部分产生，一个是来自于中间服务程序，一个来自于数据库。
为了保持门票的状态的唯一性，在进行售票，换票时都进行了事务操作，加了锁，而在验票过程中，所提交的事务也加了锁。当系统负载过量时，系统就会出现拥挤的问题，一些客户端所提交的请求，会等待一段时间才执行，就造成了延时，还有一些甚至会一直拥堵，造成网络超时而掉线。
而SQL Server 2005在并发处理量上，性能存在相比较Oracle而言，差了很多。所以，客户端提交的请求因为数据库并发吞吐量的限制也是系统响应延时或掉线的一个重要原因。
解决方案：
1． 升级中间服务器层的性能，通过分流与缓存提升响应速度。
2． 升级数据库系统。将SQL Server 2005迁移到Oracle 11g数据库上
下面分别详细介绍两个方案的具体信息。
一、 升级中间服务器层性能
1． 通过添加服务器的方式将系统的请求进行分流操作
购买一台新的服务器，作为中间层服务器，这样就有两台中间层服务器，一台用于售票，换票等工作，另一台作为验票，统计结算等工作。这样在繁忙时，就不至于拥堵，换票与验票分开处理，提高系统响应速度。
实现分流就需要进行同步操作，需要修改中间服务程序的代码以实现两台服务器分开处理，数据统一的要求。
二、 升级数据库系统
1. 将SQL Server 2005数据库系统升级为Oracle 11g数据库系统
由于SQL Server 2005数据库对并发处理性能的瓶颈，建议将数据库系统升级到Oracle 11g的数据库系统上
2. 购买一台数据服务器，与现有数据服务器组成网格
Oracle 11g是网格数据库，系统提供网格功能，能将两台或多台服务器组成数据库网格，从而提交系统响应速度与反应时间，同时为以后的扩展提供更好的基础，因为以后要加数据库服务器只需添加硬件与修改数据库的配置而无需修改软件的代码就可以实现数据库性能的提升。

[langziqian]

1. SQL远可满足你现在的需求
2. 大事务往往锁住多个表，要尽量拆分成小事务
3. 尽量使用聚集索引
4. 详细排查，确定具体是哪个表，哪个操作耗时较长

[cc_net]

硬件上改善可考虑 AP和DB的集群

[l171147904]

小菜，，看仔细看！办法很好！
1,危险。。。
需要改 整个系统，原来的东西不动为好！改了。。照成不稳定

有个疑问，验票：按字面理解，固定 条件的 查询语句。在有索引的情况下，不至于很慢才是！（即使几十，上百万的数据）

[charles_y]

跟数据库没关系,系统设计问题
1秒钟几个数据,如果这个数据库处理不了的话,那....
锁数据库时间要尽量的短,如果锁住了,下面还要进行人工干预(比如需要人工操作完成之类的)才解锁得话,那问题就大了

[sundotLei]

楼主从系统设计和代码上找找原因，这点请求次数应该不会照成楼主所说的情况.

[ludingping]

把事务拆小后，如果遇到冲突的话，我进行回滚又如何操作呢？
我现在的做法是如检测到状态冲突，就回滚整个事务，如果拆小，那以前提交的事务不是又要回来把那些提交的数据清除掉吗？

[ludingping]

四楼所说锁数据库时间要尽量的短,如果锁住了,下面还要进行人工干预(比如需要人工操作完成之类的)才解锁得话,那问题就大了

不是这样，是用户提交整个请求后再处理，处理的时候才锁。不会干那种事的。

还有就是，延迟的机子出现在使用无线网络的机子。使用网线的机子没有出现。