这种数据库设计 要专门算峰值的
有一套算法，我怀疑他们有没有算。
8000万次一小时 不是非常大的数据量
以广东移动的营帐系统来说 数据库处理超过这个
用的是Oracle 也没有使用内存数据库，没什么问题。

我倒觉得瓶颈不是在数据库上，Ｗｅｂ架构本身使得ＤＢＭＳ很难构成瓶颈，倒是ＡＰＰ　Ｓｅｒｖｅｒ的并发能力值得怀疑，当然ｊｄｂｃ的本身效能与直连和ＯＤＢＣ相比应该是稍弱的，但应不是主要问题。Ｗｅｂ开发模式下，开发人员倾向于重视语言架构，而多不擅长业务逻辑设计和数据库合理规划，很多系统整体性能差强人意。就象文中后部分所说的一些策略原则值得重温和借鉴。
当然，通道等问题其实造成“先到先得”本身并不公平。
歪想：压力实在太大，不如做成取号系统得了，压力最小，又满足先到先得的业务需求，得号后（申报成功后），可自行择取时间进行凭证获取、支付、购票……哈哈

8000万次一小时是访问量，真正的事务量公布只有每小时12万。目前没有哪个主流数据库不能支持这么小的事务量。访问量的压力还得看前端webserver，网络部署等等是否合理，访问应用程序是否够优，就算这些都很完美，可硬件如果只用些pc server一样没戏（谁知道会不会有人借机卡油）。
所以说，在什么都不知道的情况下瞎猜网站为什么会瘫一点意义都没有。