请教高手：消息队列排队处理繁忙如何处理？

[guqs]

我的系统的服务程序，一个程序（5个进程）负责接受TCP/IP交易请求，并写入消息队列；另外有一个程序（5个进程）读出消息队列并提交的数据库处理，当数据库处理慢时，等待超时就丢弃并取下一个消息，超时设为30秒。
现在的问题是，有时数据库由于其他应用的原因，交易阻塞，连续多个交易超时，很快占满了所有进程。当30秒进程超时放弃，取下一个消息时，下一个消息已经超时，于是再取下一个消息，同时前端还一直有消息进来，这样，进程每次取到的消息都是已经等待了30秒以上的交易，都不断的放弃。这样一来，后面的新消息一直就没有机会处理，一直等到可以处理时又超时了。除非停止前端提交请求，否则一直没有机会恢复到可以正常提交到数据库处理。但前端用户很多，每个用户都在不断提交，超时了又重提交....
我怎样处理才能使程序自动跳出这个排队的僵局？系统能自动恢复。现在每次发生这种现象我只有重起程序（重起会杀掉所有的消息）。
另外：我的系统程序是Unix 下C编写的。

[yang7999]

消息队列可以采用双向的方式

[sunshinethinking]

1。优化数据库的处理，提高处理速度（这是最重要的一点，否则怎么也解决不了）
2。增加服务进程数目（由5个增加到另外一个数量级别），这样同时提交给数据库操作的服务就多了，消息队列阻塞的情况就少些

不过总的来说，一般都是对数据库的操作进行优化，这才是问题的症结所在

[shenxinyu]

1、优化数据库处理速度，减少多表查询
2、数据库分库，读写分开，甚至分布到不同机器
3、更换更快的机器

[guqs]

1、数据库是因为其他业务的原因导致这边业务的处理超时，是偶发的，
也没办法解决。因为另外业务的确很占用数据库，数据库已经用的oracle和
小型机，我也知道数据库是关键，但也没办法。不受其他业务影响的情况下，
我的系统是不会出现这种情况的。我这块业务数据处理非常快。
2、目前只有加大进程数。我现在想到的办法是，前端接受请求的进程安排10
个，而负责读取消息并提交后台处理的进程增加到20个，这样也许就不会出
现解不开。只要数据库恢复性能，就立即能接受并处理新的请求是我的目的。
现在正在观察看是否解决了这个问题。检测了几天，目前一直没有出现问题，
也许解决了吧？