a*f 发帖数: 1790 | 1 一年前就看到这个版讨论这个问题了
1)以前很多人都提到按车次分割数据库,虽然还有些细节问题,毕竟是一种降低复杂
度可行办法
还有一些其他人没有讨论的技巧
2)延迟订单
前端系统在接受发送每个订单前延迟几秒钟,后台瓶颈容量能够增大。有文章用泊松分
布模拟过延迟订单来减缓瓶颈的压力。但是延迟太多会对用户体验造成不好影响。
3)分离下单和确认
极端情况下下单不加锁。这样速度会很快。但是下单成不成功等确认。其实是业务模式
调整,下单等于只是排号,确认是定时根据排号先后自动派票。各自都是独立进程。
4)按时间配票。比如上午是买票高峰,如果出票进程是每个小时一次,那么平均分配
到晚上,保证下午和晚上的流量能和上午均衡。
5)要提供拒绝订票的策略 - 比如机器人批量发订票请求自动拒绝该IP
6)在北京上海广州成都武汉等大站设立CDN订票服务器?
还有啥可以考虑考虑的? |
x****d 发帖数: 1766 | 2 rest api 是王道。不上rest api都是权宜之计而已。 |
w*******r 发帖数: 34 | 3 1. 分库的问题fzzh24问了几个问题,你可以看看,临客增加怎么办,要买联票跨库检
索交易怎么办,都是很实实在在的问题。板上一堆人拿taobao分库来说事,淘宝的货品
都是独立个体,跟车票这种根本没得比,淘宝我买不成牙刷还可以买牙膏,火车票你要
是买不到北京到上海的,压根就不会买第二天上海到南京的。
2. 延迟订单这个淘宝今年双11有用的好像,至少我是看到成交的时候多了一个页面,
板上有阿里的人的话可以出来说说。
3. goodbug已经说了这个思路,sms确认成交,减轻最后一步交易压力。
4. 一直都这么干,但早上八点放票那时候的压力还是很恐怖
5/6. 这是前段webserver的事,跟讨论的问题不在一个方向上。 |
a*f 发帖数: 1790 | 4 5这两年有major impact,铁道部的人还没有做任何防御措施,比如webserver要求每秒
最多点击一次就不拒绝,买票软件的点击频率就始终低于这个限度,每次请求还要发到
数据库端。
6是为了改进高峰期发生了几次web server crash的情况。和5也有关系。
【在 w*******r 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 1. 分库的问题fzzh24问了几个问题,你可以看看,临客增加怎么办,要买联票跨库检 : 索交易怎么办,都是很实实在在的问题。板上一堆人拿taobao分库来说事,淘宝的货品 : 都是独立个体,跟车票这种根本没得比,淘宝我买不成牙刷还可以买牙膏,火车票你要 : 是买不到北京到上海的,压根就不会买第二天上海到南京的。 : 2. 延迟订单这个淘宝今年双11有用的好像,至少我是看到成交的时候多了一个页面, : 板上有阿里的人的话可以出来说说。 : 3. goodbug已经说了这个思路,sms确认成交,减轻最后一步交易压力。 : 4. 一直都这么干,但早上八点放票那时候的压力还是很恐怖 : 5/6. 这是前段webserver的事,跟讨论的问题不在一个方向上。
|
l*****9 发帖数: 9501 | 5 WEB SERVER,上多个,最大容量的
订票要求写入多个文件。每个订票要求都有防机器人过滤器。
后台处理订票要求,按车次分发工作到许多单机:每个车次都去同一个单机,每
个单机处理多个车次。
1。不卖联票,用户分段买票;
2。区分 ticket request, ticket booked and ticket purchased
Ticket booked auto expire
1,2不够user friendly,可以在以后版本改进 |
c****3 发帖数: 10787 | 6 5算是请求hammer,很多普通应用程序能防hammer。比如每分钟请求超过几次,就封IP
几分钟。
但是商用系统很多没有这个功能。这也是商业系统的一个缺陷。
【在 a*f 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 5这两年有major impact,铁道部的人还没有做任何防御措施,比如webserver要求每秒 : 最多点击一次就不拒绝,买票软件的点击频率就始终低于这个限度,每次请求还要发到 : 数据库端。 : 6是为了改进高峰期发生了几次web server crash的情况。和5也有关系。
|
a*f 发帖数: 1790 | 7 这个问题看似简单,做好不容易。比如8点的时候你多刷新几次就被封了,或者赶着提
交结果跳出一个验证码,做不好要被很多人砸砖头的。
IP
【在 c****3 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 5算是请求hammer,很多普通应用程序能防hammer。比如每分钟请求超过几次,就封IP : 几分钟。 : 但是商用系统很多没有这个功能。这也是商业系统的一个缺陷。
|
c****3 发帖数: 10787 | 8 但这个貌似简单的功能其实在紧急情况下,能解决一多半问题。封住大部分不喜欢的流
量。
很奇怪大部分主流web服务器居然从来不提供这个功能,虽然类似功能早在20年前在一
些程序上就有了。不知道设计主流web服务器的人是什么心理。
【在 a*f 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个问题看似简单,做好不容易。比如8点的时候你多刷新几次就被封了,或者赶着提 : 交结果跳出一个验证码,做不好要被很多人砸砖头的。 : : IP
|
c****3 发帖数: 10787 | 9 这里面其实可以做出很多花样。比如你的IP总来连,我给你个302 redirect,到另一页
,说系统繁忙,过十分钟再试。另外的IP来连就没事。用户根本看不出问题。
这是简单方法能解决问题的一个例子,可惜没啥web服务器提供这种功能
【在 a*f 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个问题看似简单,做好不容易。比如8点的时候你多刷新几次就被封了,或者赶着提 : 交结果跳出一个验证码,做不好要被很多人砸砖头的。 : : IP
|
m******t 发帖数: 550 | 10 提前半年预定加实名制才是王道。至少学生客流可以从高峰中分走,民工也是。
【在 a*f 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 一年前就看到这个版讨论这个问题了 : 1)以前很多人都提到按车次分割数据库,虽然还有些细节问题,毕竟是一种降低复杂 : 度可行办法 : 还有一些其他人没有讨论的技巧 : 2)延迟订单 : 前端系统在接受发送每个订单前延迟几秒钟,后台瓶颈容量能够增大。有文章用泊松分 : 布模拟过延迟订单来减缓瓶颈的压力。但是延迟太多会对用户体验造成不好影响。 : 3)分离下单和确认 : 极端情况下下单不加锁。这样速度会很快。但是下单成不成功等确认。其实是业务模式 : 调整,下单等于只是排号,确认是定时根据排号先后自动派票。各自都是独立进程。
|
T****i 发帖数: 46 | 11 同意,不上rest api都是权宜之计:
http://phdtree.org/
http://phdtree.org/toplist/field/math/
【在 a*f 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 一年前就看到这个版讨论这个问题了 : 1)以前很多人都提到按车次分割数据库,虽然还有些细节问题,毕竟是一种降低复杂 : 度可行办法 : 还有一些其他人没有讨论的技巧 : 2)延迟订单 : 前端系统在接受发送每个订单前延迟几秒钟,后台瓶颈容量能够增大。有文章用泊松分 : 布模拟过延迟订单来减缓瓶颈的压力。但是延迟太多会对用户体验造成不好影响。 : 3)分离下单和确认 : 极端情况下下单不加锁。这样速度会很快。但是下单成不成功等确认。其实是业务模式 : 调整,下单等于只是排号,确认是定时根据排号先后自动派票。各自都是独立进程。
|
c********p 发帖数: 1969 | |