Redian新闻
>
12306 我太土了 都不知道这是啥玩意
avatar
12306 我太土了 都不知道这是啥玩意# Programming - 葵花宝典
S*b
1
CPU:
Intel Pentium Dual-Core E6500 Wolfdale 2.93GHz 65W - 79.99
cpu不需要太好吧,这个我听说看下载的高清片源和blue ray dvd足够了,我不打算搞
什么encoding, video editing之类的。
motherboard:
Intel BOXDG43GT LGA 775 Intel G43 HDMI Micro ATX - 79.99
这个板有集成显卡,有hdmi
memory:
A-DATA 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 - 44.99
Harddrive:
Western Digital AV-GP WD10EVDS 1TB 32MB Cache SATA 3.5" - 79.99
Blueray:
SAMSUNG Black 8X BD-ROM 16X DVD-ROM 48X CD-ROM SATA Internal Blu-ray Combo
Drive - 79.99
keyboard+mice:
Lenovo 57Y6336 Black USB
avatar
t*l
2
google一下 才知道是铁道部订票的
这玩意没那么 复杂吧
用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
是关键?用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处
理能力再大 你也架不住再来一个什么老师写一个超牛的客户端 然后把程序搬到离铁道
部网站机房最近的节点上 疯狂的刷 甚至给其他人代理刷票业务 一样把网站搞堵车。
Business logic其实不复杂 优化这个还不如把流程理顺 杜绝最大的问题。要想交通顺
畅 加多少lane都没用。还是要有红绿灯 包括上freeway的红绿灯。
avatar
D*3
3
cpu E5XXX 也可以.
memory 用20,30的就够了.
Harddrive 1TB 有50,60的.
keyboard+mice 特价时也就20,30.
avatar
v*u
4
有道理!

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住。一切都好办。 要不你服务器端的业务处

avatar
c*2
5
楼主用newegg吗?
整合的270w理论上是够了,不过一般电源峰值功率越高,机器相对越稳定。
其实最好是机箱/电源分开,一点不麻烦,十几块也有很不错的4/500w电源。
avatar
n*7
6
你说的block狂刷根本不是个问题,就是基本的DDoS,技术很成熟了。这种请求很早就
可以被挡下来,根本到不了查票出票阶段。



【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键?用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处

avatar
c*2
7
挺漂亮的机箱,评价也还不错。
先用吧,一般不会有问题,有问题再去搞电源也不迟.
avatar
t*l
8
楼上的。这和ddos attack 有个毛线关系。本来就是legitimate 请求过多。这里面的
请求 包括有人用鼠标手动点击的 也用购买app 自动反复执行查票购票再退票的。而后
者是要杜绝的。
解决的办法无非是 一是partition 业务流程 另外杜绝程序自动查票购票更关键。也就
是把本来“合法“ 的机器自动提交的请求改成 “非法“。
这又不是股市 非要支持 high freq trading or algorithm trading. 订票系统没有
必要支持客户端通过机器自动执行操作 产生不必要的网络负担。 有的是办法来判断是
人点鼠标还是机器。ai还没那么强大。
刚才看了下 新版系统及竟然主动提供 一个自动刷票系统 每5秒刷一次。这不是吃饱了
撑的嘛。 赶上今年网站没崩溃 就得瑟了。
还有 洋洋大国的铁道部网站 竟然ssl 的证书都不是trusted。我浏览器还报warning。
这又比这个还要业余的了嘛?
[在 totalctrl (沾衣十八跌+降龙十八涨) 的大作中提到:]
:google一下 才知道是铁道部订票的

:...........
avatar
c*2
9
对于高清软解压能力而言,x2 250以微弱的优势领先e6500;
对于高清硬解压能力而言,785g全面领先于g43(实际上785g甚至优于g45);
功耗,intel平台应该小幅领先;
价格,即便无法用到MC的活动,amd平台也还是明显更便宜。
不好意思,我又跳出来了,呵呵。
avatar
f*t
10
每个客户端每秒只允许进行一个操作就能基本杜绝刷票机的影响了
avatar
m*d
11
2g内存够不够?集显用掉一些后就没多少了

【在 S**b 的大作中提到】
: CPU:
: Intel Pentium Dual-Core E6500 Wolfdale 2.93GHz 65W - 79.99
: cpu不需要太好吧,这个我听说看下载的高清片源和blue ray dvd足够了,我不打算搞
: 什么encoding, video editing之类的。
: motherboard:
: Intel BOXDG43GT LGA 775 Intel G43 HDMI Micro ATX - 79.99
: 这个板有集成显卡,有hdmi
: memory:
: A-DATA 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 - 44.99
: Harddrive:

avatar
k*l
12
查票有没有决定于票有没有卖光,读和写就 race 了,另外铁道部放票早不放,到点一
下放好多,弄得大家非抢不可



【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键?用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处

avatar
c*2
13

用xp很好,用win7也够,一般显存设256m就很多了。

【在 m*****d 的大作中提到】
: 2g内存够不够?集显用掉一些后就没多少了
avatar
p*n
14
我也不知道这是啥?
avatar
r*o
15
上次不到50刀的biostar AM3 microATX主板没有跳?
用这个主版开30刀的sempron 140到dual core的4400e,开不成也没关系,作htpc也足够
了。现在combo后是78+shipping
http://www.newegg.com/Product/ComboDealDetails.aspx?ItemList=Combo.499331
用DDR3内存,不要用DDR2了,4G ddr3也就65刀了现在,ddr2已经停产,慢而且贵。
http://www.newegg.com/Product/Product.aspx?Item=N82E16820220436&nm_mc=EMC-IGNEFL091410&cm_mmc=EMC-IGNEFL091410-_-EMC-091410-Index-_-DesktopMemory-_-20220436-L010B
With Promo Code
EMCYXZR56
$64.99 After $20.00 MIR

【在 S**b 的大作中提到】
: CPU:
: Intel Pentium Dual-Core E6500 Wolfdale 2.93GHz 65W - 79.99
: cpu不需要太好吧,这个我听说看下载的高清片源和blue ray dvd足够了,我不打算搞
: 什么encoding, video editing之类的。
: motherboard:
: Intel BOXDG43GT LGA 775 Intel G43 HDMI Micro ATX - 79.99
: 这个板有集成显卡,有hdmi
: memory:
: A-DATA 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 - 44.99
: Harddrive:

avatar
c*3
16
这里讨论的12306是有历史原因的。
你说的限制客户端刷,铁道部早做了,图像验证码,大家都破解不了,现在的人工智能
没这个本事。网上都是说这个图像验证码坑爹的,其实都是破解不了的公司,请的5毛

【在 f*******t 的大作中提到】
: 每个客户端每秒只允许进行一个操作就能基本杜绝刷票机的影响了
avatar
c*2
17
lenovo的球拍今天半价,code:USPCS36336, 好像22号过期.
avatar
m*5
18
区分人和机器没那么容易



【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键?用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处

avatar
v*e
19
方案一:对每一个客户ip 限制每半小时查询次数 超出次数就倒计时。对这样一个系统
,我觉得可以分为用户网页和合作商api. 和合作商的票是有保障的,可以在合作商本
地做计数,然后剩下来的座位给12306网站本身的用户买票。
方案二:另一种办法是做信用卡预授权,先授权然后告诉用户是不是买成功了。这样的
好处在于可以减少用户去纠结最后是剩下一座位还是两个座位。只剩少量余票的情况下
,交易成功本来概率就是低的,客户会有失败的预期。
现在的12306技术上的问题在于用户只要开始订,这个位子就被占上了,而不是等到买
完再减数。如果交易失败,才会把数字加回去。这样读写竞争很大。即使这样,数字变
动太频繁,也无法保证客户看到的数字是正确的,只能给出一个大概的数字。
查询上需要知道火车全程中的某一段有多少空位,用sql nolock爬爬看要多久,我没试
过但估计性能不乐观。只能用并行脏读的方式加速查询过程并缓存结果。
[在 totalctrl (沾衣十八跌+降龙十八涨) 的大作中提到:]
:google一下 才知道是铁道部订票的

:...........
avatar
P*A
20
你这种拍脑袋的货要是真有了话语权,上网吧订票的民工就得在你家过年了

【在 v****e 的大作中提到】
: 方案一:对每一个客户ip 限制每半小时查询次数 超出次数就倒计时。对这样一个系统
: ,我觉得可以分为用户网页和合作商api. 和合作商的票是有保障的,可以在合作商本
: 地做计数,然后剩下来的座位给12306网站本身的用户买票。
: 方案二:另一种办法是做信用卡预授权,先授权然后告诉用户是不是买成功了。这样的
: 好处在于可以减少用户去纠结最后是剩下一座位还是两个座位。只剩少量余票的情况下
: ,交易成功本来概率就是低的,客户会有失败的预期。
: 现在的12306技术上的问题在于用户只要开始订,这个位子就被占上了,而不是等到买
: 完再减数。如果交易失败,才会把数字加回去。这样读写竞争很大。即使这样,数字变
: 动太频繁,也无法保证客户看到的数字是正确的,只能给出一个大概的数字。
: 查询上需要知道火车全程中的某一段有多少空位,用sql nolock爬爬看要多久,我没试

avatar
v*e
21
问题是12306自己说解决方法就是用了gemfire,从硬盘数据库改成了内存数据库,这个
话题还有什么好讨论的。。。如果系统都可以朝更第一层挖掘潜力,那不用在这里讨论
了,直接用寄存器存储数据好了。

【在 P*A 的大作中提到】
: 你这种拍脑袋的货要是真有了话语权,上网吧订票的民工就得在你家过年了
avatar
p*g
22
国内不想这里。基本都是内部IP.
出到外面一个公有IP很可能是几百个人在用。

【在 v****e 的大作中提到】
: 方案一:对每一个客户ip 限制每半小时查询次数 超出次数就倒计时。对这样一个系统
: ,我觉得可以分为用户网页和合作商api. 和合作商的票是有保障的,可以在合作商本
: 地做计数,然后剩下来的座位给12306网站本身的用户买票。
: 方案二:另一种办法是做信用卡预授权,先授权然后告诉用户是不是买成功了。这样的
: 好处在于可以减少用户去纠结最后是剩下一座位还是两个座位。只剩少量余票的情况下
: ,交易成功本来概率就是低的,客户会有失败的预期。
: 现在的12306技术上的问题在于用户只要开始订,这个位子就被占上了,而不是等到买
: 完再减数。如果交易失败,才会把数字加回去。这样读写竞争很大。即使这样,数字变
: 动太频繁,也无法保证客户看到的数字是正确的,只能给出一个大概的数字。
: 查询上需要知道火车全程中的某一段有多少空位,用sql nolock爬爬看要多久,我没试

avatar
b*g
23
zTPF 就好了, gds, visa 啥的处理这点东西毫无压力。
avatar
a9
24
感觉你跟别人讨论的东西根本不在一个层次的。典型的前端程序猿



【在 t*******l 的大作中提到】
: google一下 才知道是铁道部订票的
: 这玩意没那么 复杂吧
: 用户访问的确是量大。但是关键是无数的人用机器刷票查询阻塞了网络节点 这个是不
: 是关键?用机器人自动刷票我认为可以算是攻击了。完全可以拒绝服务。
: 要我做。上用户注册啊。上个ldap。支持几千万个用户账号认证不成问题吧。不通过
: ldap认证的 连查询都不让。通过的 也不让你一秒查好多次。客票资源 更新的次数少
: 查询座位是否空的次数极多 也符合ldap应用模式 也可以建一个ldap 让你随便查 反正
: 对查票来说是read only 。买票交易还是要在后台上数据库。一旦票卖出要 后台和
: ldap 数据 sync。对于换车买联票产生的race condition 通过数据库解决。
: 这个事情关键是把client端的机器人block住。一切都好办。 要不你服务器端的业务处

avatar
t*l
25
楼上 这点话题还能整出高大上来 还分层次 还真是无语。本来不复杂的事情 无非就是
发现问题 解决问题。解决问题手段也有很多。DBA 有DBA的手段 ,Programmer 有
programmer 的手段, IT也有IT的手段. 业务流程上也可以有自己的优化手段。甚至
ISP那里也有手段可以优化。
用LDAP来存储空票状态,来支持readonly 的查票请求,从而offload 数据库的压力 绝
对可行,也可以scale。信不信随你。
这个订票系统以前年年崩溃 其实服务器端的处理能力不是最最关键的root cause。最
关键的是没有throttling的手段。比如一个电话系统 toll free 接线员哪怕只有两条
线路可以同时开通,就算上百万人同时打电话也不会造成系统崩溃。要么你是忙音 要
么被甩到q里面. 把throttling 按照处理能配置好比其他都重要。这个问题解决了 起
码保证网站不崩溃。
avatar
c*3
26
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 按照处理能配置好比其他都重要。这个问题解决了 起

avatar
t*l
27
看了上面的链接 我服了。在中国 真是干什么都能搞成抢白菜一样。还能不能好好的过
日子了?
数学界未解决问题还有不少 我建议铁道部加上去做验证码。黄牛党的智商不差 在利益
驱动下 说不定还真能对人类有贡献。
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。