25
1月

高并发交易驱动系统方案

我在知乎就《现在有这样一个需求,在一秒中有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

没有评论

第一个在本文留言。

发表评论

名字(必须)
邮箱(不会被公布)(必须)
网址

字体为 粗体 是必填项目,邮箱地址 永远不会 公布。

允许部分 HTML 代码:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
URLs must be fully qualified (eg: http://www.yeeach.com),and all tags must be properly closed.

超出部分系统将会自动分段及换行。

请保证评论内容是与日志或 Blog 内容相关的,灌水、攻击性或不恰当的评论 可能 会被编辑或删除。

    RSS订阅

    近期文章

    近期评论

    文章归档

    分类目录