如何看待春运票务系统的架构优化?

  • 回答 (9)
  • 关注 (0)
  • 查看 (304)

最近,很热的问题应该就是春运的购票系统了。疯狂堆砌的“加速包”,七零八碎的“抢票‘’APP,其实最核心的问题应该就是需求大于供给了。

如何合理的分配票务资源,保证票务系统的正常运转,成了春运票务系统的核心需求。

其实票务系统架构步骤无非在于:

1、 检查是否有剩余的票

2、 购票后票数减一

3、 账户上扣除金额

4、 获得火车票

在这些步骤的基础上,购票系统又该如何进行架构优化呢?

TaborTabor

CM-Z.net · 站长 (已认证)

提问于
Ne_biubiubiu这就是世界结束的方式回答于

其实上面,所说应该都是现有架构的分析,如何优化,还得看我这篇回答:

首先,要明确下为什么购票系统难做:

12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存。读写冲突,锁非常严重,这是抢票业务难的地方。

其次,是优化方向:

优化方向有两个:

(1)将请求尽量拦截在系统上游(不要让锁冲突落到数据库上去)。传统票务系统之所以挂,请求都压倒了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,流量虽大,下单成功的有效流量甚小。以12306为例,一趟火车其实只有2000张票,200w个人来买,基本没有人能买成功,请求有效率为0。

(2)充分利用缓存,春运买票,这是一个典型的读多些少的应用场景,大部分请求是车次查询,票查询,下单和支付才是写请求。一趟火车其实只有2000张票,200w个人来买,最多2000个人下单成功,其他人都是查询库存,写比例只有0.1%,读比例占99.9%,非常适合使用缓存来优化。

春运购票架构:

(1)浏览器端,最上层,会执行到一些JS代码

(2)站点层,这一层会访问后端数据,拼html页面返回给浏览器

(3)服务层,向上游屏蔽底层数据细节,提供数据访问

(4)数据层,最终的库存是存在这里的,mysql是一个典型(当然还有会缓存)

这个图虽然简单,但能形象的说明大流量高并发的票务业务架构

第一层,浏览器怎么优化?

问大家一个问题,大家都玩过微信的摇一摇抢红包对吧,每次摇一摇,就会往后端发送请求么?回顾我们下单抢票的场景,点击了“查询”按钮之后,系统那个卡呀,进度条涨的慢呀,作为用户,我会不自觉的再去点击“查询”,对么?

继续点,继续点,点点点。。。有用么?

平白无故的增加了系统负载,一个用户点5次,80%的请求是这么多出来的,怎么整?

(第一点)产品层面,用户点击“查询”或者“购票”后,按钮置灰,禁止用户重复提交请求;

(第二点)JS层面,限制用户在x秒之内只能提交一次请求;

APP层面,可以做类似的事情,虽然你疯狂的在摇微信,其实x秒才向后端发起一次请求。这就是所谓的“将请求尽量拦截在系统上游”,越上游越好,浏览器层,APP层就给拦住,这样就能挡住80%+的请求,这种办法只能拦住普通用户(但99%的用户是普通用户)对于群内的高端程序员是拦不住的。firebug一抓包,http长啥样都知道,js是万万拦不住无良抢票软件写for循环,调用http接口的,这部分请求怎么处理?

第二层,站点层面的请求拦截

怎么拦截?怎么防止程序员写for循环调用,有去重依据么?ip?cookie-id?…想复杂了,这类业务都需要登录,用uid即可。在站点层面,对uid进行请求计数和去重,甚至不需要统一存储计数,直接站点层内存存储(这样计数会不准,但最简单)。一个uid,5秒只准透过1个请求,这样又能拦住99%的for循环请求。

5s只透过一个请求,其余的请求怎么办?缓存,页面缓存,同一个uid,限制访问频度,做页面缓存,x秒内到达站点层的请求,均返回同一页面。同一个item的查询,例如车次,做页面缓存,x秒内到达站点层的请求,均返回同一页面。如此限流,既能保证用户有良好的用户体验(没有返回404)又能保证系统的健壮性(利用页面缓存,把请求拦截在站点层了)。

这个方式拦住了写for循环发http请求的程序员,有些高端程序员(黑客)控制了10w个肉鸡,手里有10w个uid,同时发请求,这下怎么办,站点层按照uid限流拦不住了。

第三层 服务层来拦截(反正就是不要让请求落到数据库上去)

服务层怎么拦截?大哥,我是服务层,我清楚的知道一列火车只有2000张车票,我透10w个请求去数据库有什么意义呢?没错,请求队列!

对于写请求,做请求队列,每次只透有限的写请求去数据层(下订单,支付这样的写业务)

3k张火车票,只透3k个下单请求去db

如果均成功再放下一批,如果库存不够则队列里的写请求全部返回“已售完”。

对于读请求,怎么优化?cache抗,不管是memcached还是redis,单机抗个每秒10w应该都是没什么问题的。如此限流,只有非常少的写请求,和非常少的读缓存mis的请求会透到数据层去,又有99.9%的请求被拦住了。

当然,还有业务规则上的一些优化。回想12306所做的,分时分段售票,原来统一10点卖票,现在8点,8点半,9点,...每隔半个小时放出一批:将流量摊匀。

其次,数据粒度的优化:你去购票,对于余票查询这个业务,票剩了58张,还是26张,你真的关注么,其实我们只关心有票和无票?流量大的时候,做一个粗粒度的“有票”“无票”缓存即可。

第三,一些业务逻辑的异步:例如下单业务与 支付业务的分离

最后是数据库层

浏览器拦截了80%,站点层拦截了99.9%并做了页面缓存,服务层又做了写请求队列与数据缓存,每次透到数据库层的请求都是可控的。db基本就没什么压力了。

全部透到数据库,100w个下单,0个成功,请求有效率0%。透3k个到数据,全部成功,请求有效率100%。

总结下购票流程的优化大概是这样的:

(1)尽量将请求拦截在系统上游(越上游越好);

(2)读多写少的常用多使用缓存(缓存抗读压力);

浏览器和APP:做限速

站点层:按照uid做限速,做页面缓存

服务层:按照业务做写请求队列控制流量,做数据缓存

数据层:坐等吃鸡

结合业务做优化

回答过的其他问题

云数据库MYSQL 如何设置 AUTOCOMMIT=0?

Ne_biubiubiu这就是世界结束的方式

OCR 身份证识别 要授权吗 很急,很急,很急?

Ne_biubiubiu这就是世界结束的方式
应该是签名问题把: 签名分为多次有效签名和单次有效签名: 多次有效签名:签名中绑定或者不绑定文件 fileid,需要设置大于当前时间的有效期,有效期内此签名可多次使用,有效期最长可设置三个月。 单次有效签名:签名中绑定文件 fileid,有效期必须设置为0,此签名只可使用一次...... 展开详请

拉取直播推流地址失败,Error:-1?

Ne_biubiubiu这就是世界结束的方式
-1,是一般性错误,按照下面步骤调出来log定位下问题把: 业务服务器代码里的log:如果请求能返回,但是回包的json里的returnValue非0,表示该请求失败,请查看php代码所在目录/log目录下的文件,如果log目录不存在,请创建log目录(老版本的代码没有默认创建...... 展开详请

我使用了印刷体识别功能,怎么查询当期需要支付多少钱?

Ne_biubiubiu这就是世界结束的方式
查询调用次数在控制台https://console.cloud.tencent.com/ai/ocr/idcard 具体价格是这样的: [图片] ... 展开详请

创建子网是什么?我无法购买VPS?

Ne_biubiubiu这就是世界结束的方式
据下图提示或者教程动手创建一个 腾讯云 VPC 和子网,并将一个可以连接到 Internet 的云服务器部署到你的子网中,最后通过安全组对进出该云服务器的流量进行筛选,保证主机通信的安全。在该部署中的云服务器能够与 Internet 通信,并且能够从本地计算机访问您的云服务器。...... 展开详请

小程序套餐里面的云数据库有没有oracle?

Ne_biubiubiu这就是世界结束的方式
好像确实如此,只提供mysql数据库选择,不过肯定其他数据库也会相继开放的。 [图片] ... 展开详请

关于作者

Ne_biubiubiu

这就是世界结束的方式

所属标签

扫码关注云+社区