今天看到这篇关于处理并发的文章很有收获,给大家分享一下。
在session中牧劳为我们介绍了淘宝下单部分的技术方案变迁,我不介绍变迁,而只对现有系统做介绍。
要优化下单,提高下单的TPS (Transaction per second),我们首先要做的是对下单的逻辑剥离,只保留核心部分,而把附加功能剔除出去。比如说下单要考虑库存量,考虑发短信,要给卖家发旺旺消息通知,要对订单做统计,要做销售额统计等等,这些功能是必要的,但是也是附加的功能,要最大程度提高下单这一步的TPS,就要先不考虑这些东西。
下单必然会涉及到买家查看订单,和卖家查看收到的订单,修改订单价格等,这是下单的核心。 在下单这个操作中有买家和卖家两个密切关联而有不同的视角。牧劳称为两个不同的维度。据牧劳的介绍下单这一步只有5张表,这5张表涵盖了这两个维度的操作。
下单是在一个数据库事务中进行的,要提高数据库的事务并发数,最有效的办法是拆分,拆分有两种,一是对库进行拆分,另一种是在同一个库中对表进行拆分。要做拆分首先就要考虑拆分依据的字段,淘宝是根据订单号做拆分的,而下单中有两个维度,买家和卖家,对订单做拆分之后,必须还是可以通过买家,卖家方便的查询着两个维度的数据。该怎么办呢?这里留个疑问,我先介绍淘宝拆分的规模,淘宝将订单表拆分到16个mysql库中,而在每个库中又将订单表横向拆分为64份,相当于将一个表拆分为1024份。拆分之后事务会分散到1024套表中,这必然会很大程序上增加并发的事务处理能力(这儿我说是必然,但是淘宝在使用这种方案之前是要经过压力测试,实际测试出这种方案的TPS之后,才会逐步采用这种方案的)。上面留了一个疑问,经过拆分之后如何保证买家卖家快速的查询其下的订单呢?最好的办法是保证买家,卖家下的订单在一张表中,如何保证呢?淘宝的做法是将买家的id取模后放到订单号中。假定一个订单号是142424594267664;这个订单号对应的订单该放在哪台服务器上的哪个表中,是根据订单的后四位7667,对1024取模之后决定的;同时7667是买家id的后四位。这样买家在查询其订单时就可以通过其id获得其订单所在库以及表,就可以方便有效的查询买家订单了。这里会带来另外一个问题,卖家查询订单时怎么办?前面我们已经提到卖家和买家被分成两个不同的维度来做表设计,卖家查询时不是直接查订单表,而是通过卖家维度的表来做查询。卖家维度的表的插入,更新是通过在订单插入时发一个消息来通知插入的。同样对于发短信、发旺旺也是通过消息来处理的,这些附加功能不参与到下单的事务中去。
即使这样做了库,表的拆分,依然会有问题。淘宝在双11时的一天的交易量就达到了5000多万,这样几个月过去后,这些拆分后的表中的数据量也会达到很大的一个量,处理速度就会下降。淘宝的做法是把三个月之前的老数据迁移到其他库中,这样就避免了数据量增大导致的系统响应时间降低的问题。但是会带来另外一个问题,用户在查询订单时需要同时查两个库,一个是历史数据表,另一个是近期数据表;这个问题无可避免,就是通过查询两次解决。
也许有的朋友会想到拆分之后对全数据做统计会有问题。如果在拆分后的表上做统计,是肯定会有问题的。怎么做呢?其实很简单,把数据迁移到别的库中去做统计。
表做拆分可以大大的提高TPS,但是也会带来一些问题,需要通过可靠的消息通知机制通知其他模块做非核心处理的事情,需要通过高效的搜索系统保证搜索数据的及时更新。
以上是我个人对淘宝下单高并发设计的理解。这是肤浅的,实际做的时候肯定还需要考虑更多的问题,比如数据库的调优,磁盘IO方式,服务器稳定性;方案的可测试性,可量化等等。
上周六的技术还分享介绍了很多其他方面的精彩内容。感谢主办方,主持人! 期待@淘宝技术嘉年华 更多精彩的技术沙龙。
订单号介绍勘误:
文中对于订单号的表述有点问题,对于16台服务器,每台服务器64张表只需要2位买家或卖家id的后两位数字就可以准确定位到具体的库和表。订单号中同时存在买家id的最后两位和卖家id的最后两位。分别在订单号的倒数第3,4位数和最后两位数。
假定买家id为123456789,那么在订单号中的最后两位就是89,通过89对16取模就可以定位到具体的库上,通过对64取模就可以定位到具体的表上。
转载:http://www.cnblogs.com/yukaizhao/archive/2012/04/23/taobao_order_design.html
相关推荐
总的来说,Hmily是一个强大且灵活的分布式事务解决方案,它的出现弥补了传统事务处理方案在高并发、大规模分布式环境下的不足,为企业构建高可用、高一致性的分布式系统提供了有力保障。通过深入理解并合理运用Hmily...
4. **V2.1 (2004.10–2007.01)**:为进一步提高性能和降低成本,淘宝继续优化技术栈,比如在Web服务器方面从WebLogic转向更轻量级的解决方案。 #### 四、淘宝技术架构的关键组成部分 - **WebX**:基于规则的MVC...
为了确保高并发下的稳定性,代码可能采用了异步处理、队列服务等技术,以防止系统因大量用户同时操作而崩溃。 【团购模板】标签进一步强调了模板的主要应用场景,即用于搭建团购活动的页面。团购页面通常需要展示...
5. 高并发解决方案 淘宝为了解决高并发的问题,采取了以下几种方法: * 对下单逻辑剥离,只保留核心部分,而把附加功能剔除出去。 * 拆分数据库,将订单表拆分到多个库中,每个库中又将订单表横向拆分为多份。 * ...
3. **反爬虫策略**:淘宝等电商平台有反爬虫机制,所以“破流”可能涉及到如何绕过这些机制,例如使用代理IP、随机User-Agent、滑动验证码解决方案等。 4. **数据抓取**:可能需要实时获取商品信息,比如库存、价格...
WebKit对网页内容的快速解析和高效渲染,使得早早省能够在短时间内快速加载和处理秒杀页面,从而提高用户在高并发环境下抢购商品的成功率。 淘宝答题秒杀是早早省的一项特色功能,它能够帮助用户自动完成秒杀过程中...
综上所述,淘宝大秒系统设计是一套复杂而精细的解决方案,它结合了多种技术手段,以应对电商秒杀活动中的高并发挑战,保证了系统的稳定性和用户满意度。通过不断优化和迭代,该系统能够为商家提供可靠的营销平台,...
再者,"TopDO.sln"和"TopDO.suo"是Visual Studio解决方案文件和用户选项文件,它们分别包含了项目的整体配置和用户特定设置。开发者可以使用这些文件在IDE中打开和管理项目,进行编译和调试。 "DataBase"目录可能...
总结,基于PHP的新版京东淘宝拼多多自动Q单系统源码全开源接单返佣是一个全面的电商解决方案,涵盖了用户管理、商品展示、订单处理、接口对接、数据分析等多个核心模块,体现了PHP在电商系统开发中的强大能力。...
例如,用户在淘宝下单后,订单信息会通过消息队列发送到库存系统和物流系统,确保系统间的同步。 7. **数据一致性**:在分布式环境中,保持数据一致性是个挑战。CAP定理指出,分布式系统不能同时满足一致性、可用性...
3. 安全稳定:软件系统经过严格测试,确保在高并发环境下也能稳定运行,避免因系统问题导致的订单延误或错误。 4. 广泛的商品种类:涵盖全国各地的手机话费、多种网络游戏点卡、QQ业务等多种充值产品,满足不同用户...
#### 实现难点与解决方案 1. **平台反作弊策略应对**:电商平台为防止不正当竞争行为会采取一系列技术手段限制自动化工具的使用,如IP地址限制、验证码验证等。针对这一问题,可通过更换代理IP、OCR识别技术破解...
6. **异常处理**:设计机制来应对高并发访问、服务器故障等突发情况,保证活动平稳运行。 ### 免费版聚划算代码的可能含义 提到“免费版”的聚划算代码,这通常指的是可供开发者学习或二次开发的开源代码库。这类...
《不一样的双11,不一样的技术创新》是阿里巴巴集团在2016年...《不一样的技术创新》电子书为读者提供了一个深入了解和学习这些先进技术的窗口,让人们得以窥见大型互联网公司在应对高强度技术挑战时的思考和解决方案。
1. **JAVA商城**:基于Java技术开发的电子商务平台,Java以其稳定性和跨平台性受到广泛青睐,适合大型、高并发的电商系统。Java商城通常采用Spring Boot、MyBatis等框架,提供强大的安全性和可维护性。 2. **PHP...
通过以上案例分析和技术实践,我们可以看到,电商秒杀活动不仅需要合理的营销策略,还需要强大的技术支持来应对突发的高并发访问。从秒杀架构的设计到实施,每一步都需要精心规划和不断优化。未来,随着技术的进步,...
随着携程账号数据库从MySQL的迁移,这个问题变得更加紧迫,需要设计一个能够支持高并发、体现一定属性、高可靠并能容错单点故障的用户ID生成方案。以下是几种常见的ID生成方法及其优缺点: 1. **数据库递增**:...