我在知乎就《现在有这样一个需求，在一秒中有3万的支付订单请求，有什么比较好的解决方案吗？》做的回答。
从交易角度来看，各种高并发系统可以粗略分为两大类：交易驱动的系统，内容驱动的系统。其中：
交易驱动的系统：包括支付系统、电信计费系统、银行核心交易系统等，此类系统强调数据库事务的ACID原则。
内容驱动的系统：包括SNS、微博、门户、视频、搜索引擎等系统，此类系统对数据库事务ACID的关注不是第一位的，更强调CAP原则：Consistency（一致性）， Availability（可用性），Partition tolerance（分区容错性）。
与此对应，交易驱动的系统与内容驱动的系统在系统优化方法最大的差异在于：
交易驱动的系统：强调事务的ACID，按照CAP原则做选择，更强调CA（Consistency（一致性）和Availability（可用性）；因此交易驱动的系统一般在核心交易上选择关系型数据库（包括采用内存数据库、缓存等涉及事务问题），当然这就导致交易系统最大的瓶颈一般都在关系数据库上。
内容驱动的系统：可以在CAP之间根据业务需要做选择三选二，因此一般选择NOSQL为主、RDBMS为辅的方案。
在优化策略上，内容驱动的系统采用的诸多优化手段交易驱动的系统也可以采用，上面各位回答都有所提及，这里重点说一下因事务导致的业务复杂性的处理。
3万笔/每秒这个级别的交易订单这个量级说实话挺大，但即便如此，也有诸多可优化的空间。由于题主未对具体场景说明，只能假定是典型的交易驱动系统，一些思考点：
1、3万笔/每秒是峰值最大交易量还是持续交易量？
2、3万笔/每秒是同一类型的订单还是诸多种类型的订单？
3、业务能否做拆分，例如从功能、从区域、从优先级等角度？
4、支付订单是实时交易还是非实时交易，能否延时入库？
5、支付订单能否延时批量处理？
6、支付订单是否涉及热点账户问题，也即对同一账户会有多个并发请求对其属性（例如账户余额）进行操作？
由此可以展开诸多优化策略，不在此处细述。
以前写过一篇 交易系统“热点账户”处理 ，供参考
热点账户
知乎回答原文链接：http://www.zhihu.com/question/27590048/answer/38025567
转载请注明：出家如初,成佛有余 » 高并发交易驱动系统方案