t*******l
发帖数: 3662 | 1 google一下 才知道是铁道部订票的
这玩意没那么 复杂吧
用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
理能力再大 你也架不住再来一个什么老师写一个超牛的客户端 然后把程序搬到离铁道
部网站机房最近的节点上 疯狂的刷 甚至给其他人代理刷票业务 一样把网站搞堵车。
Business logic其实不复杂 优化这个还不如把流程理顺 杜绝最大的问题。要想交通顺
畅 加多少lane都没用。还是要有红绿灯 包括上freeway的红绿灯。 |
v*****u
发帖数: 1796 | 2 有道理！
google一下 才知道是铁道部订票的
这玩意没那么 复杂吧
用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
理能力再大 你也架不住再来一个什么老师写一个超牛的客户端 然后把程序搬到离铁道
部网站机房最近的节点上 疯狂的刷 甚至给其他人代理刷票业务 一样把网站搞堵车。
Business logic其实不复杂 优化这个还不如把流程理顺 杜绝最大的问题。要想交通顺
畅 加多少lane都没用。还是要有红绿灯 包括上freeway的红绿灯。
【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
|
n*******7
发帖数: 181 | 3 你说的block狂刷根本不是个问题，就是基本的DDoS，技术很成熟了。这种请求很早就
可以被挡下来，根本到不了查票出票阶段。
少
【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
|
t*******l
发帖数: 3662 | 4 楼上的。这和ddos attack 有个毛线关系。本来就是legitimate 请求过多。这里面的
请求 包括有人用鼠标手动点击的 也用购买app 自动反复执行查票购票再退票的。而后
者是要杜绝的。
解决的办法无非是 一是partition 业务流程 另外杜绝程序自动查票购票更关键。也就
是把本来“合法“ 的机器自动提交的请求改成 “非法“。
这又不是股市 非要支持 high freq trading or algorithm trading. 订票系统没有
必要支持客户端通过机器自动执行操作 产生不必要的网络负担。 有的是办法来判断是
人点鼠标还是机器。ai还没那么强大。
刚才看了下 新版系统及竟然主动提供 一个自动刷票系统 每5秒刷一次。这不是吃饱了
撑的嘛。 赶上今年网站没崩溃 就得瑟了。
还有 洋洋大国的铁道部网站 竟然ssl 的证书都不是trusted。我浏览器还报warning。
这又比这个还要业余的了嘛？
[在 totalctrl (沾衣十八跌+降龙十八涨) 的大作中提到：]
：google一下 才知道是铁道部订票的
：
：........... |
f*******t
发帖数: 7549 | 5 每个客户端每秒只允许进行一个操作就能基本杜绝刷票机的影响了 |
k**l
发帖数: 2966 | 6 查票有没有决定于票有没有卖光，读和写就 race 了，另外铁道部放票早不放，到点一
下放好多，弄得大家非抢不可
少
【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
|
p********n
发帖数: 3367 | |
c****3
发帖数: 10787 | 8 这里讨论的12306是有历史原因的。
你说的限制客户端刷，铁道部早做了，图像验证码，大家都破解不了，现在的人工智能
没这个本事。网上都是说这个图像验证码坑爹的，其实都是破解不了的公司，请的5毛
【在 f*******t 的大作中提到】
: 每个客户端每秒只允许进行一个操作就能基本杜绝刷票机的影响了
|
m******5
发帖数: 224 | 9 区分人和机器没那么容易
少
【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
|
v****e
发帖数: 145 | 10 方案一：对每一个客户ip 限制每半小时查询次数 超出次数就倒计时。对这样一个系统
，我觉得可以分为用户网页和合作商api. 和合作商的票是有保障的，可以在合作商本
地做计数，然后剩下来的座位给12306网站本身的用户买票。
方案二：另一种办法是做信用卡预授权，先授权然后告诉用户是不是买成功了。这样的
好处在于可以减少用户去纠结最后是剩下一座位还是两个座位。只剩少量余票的情况下
，交易成功本来概率就是低的，客户会有失败的预期。
现在的12306技术上的问题在于用户只要开始订，这个位子就被占上了，而不是等到买
完再减数。如果交易失败，才会把数字加回去。这样读写竞争很大。即使这样，数字变
动太频繁，也无法保证客户看到的数字是正确的，只能给出一个大概的数字。
查询上需要知道火车全程中的某一段有多少空位，用sql nolock爬爬看要多久，我没试
过但估计性能不乐观。只能用并行脏读的方式加速查询过程并缓存结果。
[在 totalctrl (沾衣十八跌+降龙十八涨) 的大作中提到：]
：google一下 才知道是铁道部订票的
：
：........... |
|
|
P*A
发帖数: 7996 | 11 你这种拍脑袋的货要是真有了话语权，上网吧订票的民工就得在你家过年了
【在 v****e 的大作中提到】
: 方案一：对每一个客户ip 限制每半小时查询次数 超出次数就倒计时。对这样一个系统
: ，我觉得可以分为用户网页和合作商api. 和合作商的票是有保障的，可以在合作商本
: 地做计数，然后剩下来的座位给12306网站本身的用户买票。
: 方案二：另一种办法是做信用卡预授权，先授权然后告诉用户是不是买成功了。这样的
: 好处在于可以减少用户去纠结最后是剩下一座位还是两个座位。只剩少量余票的情况下
: ，交易成功本来概率就是低的，客户会有失败的预期。
: 现在的12306技术上的问题在于用户只要开始订，这个位子就被占上了，而不是等到买
: 完再减数。如果交易失败，才会把数字加回去。这样读写竞争很大。即使这样，数字变
: 动太频繁，也无法保证客户看到的数字是正确的，只能给出一个大概的数字。
: 查询上需要知道火车全程中的某一段有多少空位，用sql nolock爬爬看要多久，我没试
|
v****e
发帖数: 145 | 12 问题是12306自己说解决方法就是用了gemfire，从硬盘数据库改成了内存数据库，这个
话题还有什么好讨论的。。。如果系统都可以朝更第一层挖掘潜力，那不用在这里讨论
了，直接用寄存器存储数据好了。
【在 P*A 的大作中提到】
: 你这种拍脑袋的货要是真有了话语权，上网吧订票的民工就得在你家过年了
|
p*********g
发帖数: 911 | 13 国内不想这里。基本都是内部IP.
出到外面一个公有IP很可能是几百个人在用。
【在 v****e 的大作中提到】
: 方案一：对每一个客户ip 限制每半小时查询次数 超出次数就倒计时。对这样一个系统
: ，我觉得可以分为用户网页和合作商api. 和合作商的票是有保障的，可以在合作商本
: 地做计数，然后剩下来的座位给12306网站本身的用户买票。
: 方案二：另一种办法是做信用卡预授权，先授权然后告诉用户是不是买成功了。这样的
: 好处在于可以减少用户去纠结最后是剩下一座位还是两个座位。只剩少量余票的情况下
: ，交易成功本来概率就是低的，客户会有失败的预期。
: 现在的12306技术上的问题在于用户只要开始订，这个位子就被占上了，而不是等到买
: 完再减数。如果交易失败，才会把数字加回去。这样读写竞争很大。即使这样，数字变
: 动太频繁，也无法保证客户看到的数字是正确的，只能给出一个大概的数字。
: 查询上需要知道火车全程中的某一段有多少空位，用sql nolock爬爬看要多久，我没试
|
b**********g
发帖数: 460 | 14 zTPF 就好了， gds, visa 啥的处理这点东西毫无压力。 |
a9
发帖数: 21638 | 15 感觉你跟别人讨论的东西根本不在一个层次的。典型的前端程序猿
少
【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键？用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
|
t*******l
发帖数: 3662 | 16 楼上 这点话题还能整出高大上来 还分层次 还真是无语。本来不复杂的事情 无非就是
发现问题 解决问题。解决问题手段也有很多。DBA 有DBA的手段 ，Programmer 有
programmer 的手段， IT也有IT的手段. 业务流程上也可以有自己的优化手段。甚至
ISP那里也有手段可以优化。
用LDAP来存储空票状态，来支持readonly 的查票请求，从而offload 数据库的压力 绝
对可行，也可以scale。信不信随你。
这个订票系统以前年年崩溃 其实服务器端的处理能力不是最最关键的root cause。最
关键的是没有throttling的手段。比如一个电话系统 toll free 接线员哪怕只有两条
线路可以同时开通，就算上百万人同时打电话也不会造成系统崩溃。要么你是忙音 要
么被甩到q里面. 把throttling 按照处理能配置好比其他都重要。这个问题解决了 起
码保证网站不崩溃。 |
c****3
发帖数: 10787 | 17 http://pcedu.pconline.com.cn/732/7321330.html
【在 t*******l 的大作中提到】
: 楼上 这点话题还能整出高大上来 还分层次 还真是无语。本来不复杂的事情 无非就是
: 发现问题 解决问题。解决问题手段也有很多。DBA 有DBA的手段 ，Programmer 有
: programmer 的手段， IT也有IT的手段. 业务流程上也可以有自己的优化手段。甚至
: ISP那里也有手段可以优化。
: 用LDAP来存储空票状态，来支持readonly 的查票请求，从而offload 数据库的压力 绝
: 对可行，也可以scale。信不信随你。
: 这个订票系统以前年年崩溃 其实服务器端的处理能力不是最最关键的root cause。最
: 关键的是没有throttling的手段。比如一个电话系统 toll free 接线员哪怕只有两条
: 线路可以同时开通，就算上百万人同时打电话也不会造成系统崩溃。要么你是忙音 要
: 么被甩到q里面. 把throttling 按照处理能配置好比其他都重要。这个问题解决了 起
|
t*******l
发帖数: 3662 | 18 看了上面的链接 我服了。在中国 真是干什么都能搞成抢白菜一样。还能不能好好的过
日子了？
数学界未解决问题还有不少 我建议铁道部加上去做验证码。黄牛党的智商不差 在利益
驱动下 说不定还真能对人类有贡献。 |
