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 的大作中提到】
: 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 的大作中提到】
: 5这两年有major impact，铁道部的人还没有做任何防御措施，比如webserver要求每秒
: 最多点击一次就不拒绝，买票软件的点击频率就始终低于这个限度，每次请求还要发到
: 数据库端。
: 6是为了改进高峰期发生了几次web server crash的情况。和5也有关系。
|
a*f
发帖数: 1790 | 7 这个问题看似简单，做好不容易。比如8点的时候你多刷新几次就被封了，或者赶着提
交结果跳出一个验证码，做不好要被很多人砸砖头的。
IP
【在 c****3 的大作中提到】
: 5算是请求hammer，很多普通应用程序能防hammer。比如每分钟请求超过几次，就封IP
: 几分钟。
: 但是商用系统很多没有这个功能。这也是商业系统的一个缺陷。
|
c****3
发帖数: 10787 | 8 但这个貌似简单的功能其实在紧急情况下，能解决一多半问题。封住大部分不喜欢的流
量。
很奇怪大部分主流web服务器居然从来不提供这个功能，虽然类似功能早在20年前在一
些程序上就有了。不知道设计主流web服务器的人是什么心理。
【在 a*f 的大作中提到】
: 这个问题看似简单，做好不容易。比如8点的时候你多刷新几次就被封了，或者赶着提
: 交结果跳出一个验证码，做不好要被很多人砸砖头的。
:
: IP
|
c****3
发帖数: 10787 | 9 这里面其实可以做出很多花样。比如你的IP总来连，我给你个302 redirect，到另一页
，说系统繁忙，过十分钟再试。另外的IP来连就没事。用户根本看不出问题。
这是简单方法能解决问题的一个例子，可惜没啥web服务器提供这种功能
【在 a*f 的大作中提到】
: 这个问题看似简单，做好不容易。比如8点的时候你多刷新几次就被封了，或者赶着提
: 交结果跳出一个验证码，做不好要被很多人砸砖头的。
:
: IP
|
m******t
发帖数: 550 | 10 提前半年预定加实名制才是王道。至少学生客流可以从高峰中分走，民工也是。
【在 a*f 的大作中提到】
: 一年前就看到这个版讨论这个问题了
: 1）以前很多人都提到按车次分割数据库，虽然还有些细节问题，毕竟是一种降低复杂
: 度可行办法
: 还有一些其他人没有讨论的技巧
: 2）延迟订单
: 前端系统在接受发送每个订单前延迟几秒钟，后台瓶颈容量能够增大。有文章用泊松分
: 布模拟过延迟订单来减缓瓶颈的压力。但是延迟太多会对用户体验造成不好影响。
: 3）分离下单和确认
: 极端情况下下单不加锁。这样速度会很快。但是下单成不成功等确认。其实是业务模式
: 调整，下单等于只是排号，确认是定时根据排号先后自动派票。各自都是独立进程。
|
T****i
发帖数: 46 | 11 同意，不上rest api都是权宜之计：
http://phdtree.org/
http://phdtree.org/toplist/field/math/
【在 a*f 的大作中提到】
: 一年前就看到这个版讨论这个问题了
: 1）以前很多人都提到按车次分割数据库，虽然还有些细节问题，毕竟是一种降低复杂
: 度可行办法
: 还有一些其他人没有讨论的技巧
: 2）延迟订单
: 前端系统在接受发送每个订单前延迟几秒钟，后台瓶颈容量能够增大。有文章用泊松分
: 布模拟过延迟订单来减缓瓶颈的压力。但是延迟太多会对用户体验造成不好影响。
: 3）分离下单和确认
: 极端情况下下单不加锁。这样速度会很快。但是下单成不成功等确认。其实是业务模式
: 调整，下单等于只是排号，确认是定时根据排号先后自动派票。各自都是独立进程。
|
c********p
发帖数: 1969 | |
