论坛首页 Java企业应用论坛

如果让你设计铁道部购票网站,你怎么做

浏览 27014 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-01-11  

最近铁道部购票已经成为了热点话题,毛病多得一塌糊涂,如果让你来设计铁道部购票网站,你会怎么做?

 

这样的网站属于实时性要求较高、并发性要求非常高、容量要求一般的类型,以下是我简单的想法:

 

1、部署是基于CDN的,对于车票查询的环节来说,这是没有问题的。

 

2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。

 

3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。

 

4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由于车票查询实时性有一定要求,可以设置每个查询页面有10分钟的生命周期,缓存文件管理算法用LRU就可以,被动更新。如果车票信息在本地,数据库节点应该会是瓶颈,好的缓存设计会很讨巧,可以大大减小数据库压力。

 

5、应用节点的负载分担是一定要做的,查询和订票操作可以分开集群,有条件的要做硬件负载。

 

6、静态资源合并,落到单独的域名服务器上。

 

7、流量控制部分,不能只给出用户提示,应当给出用户当前在等待队列中的位置,定时更新当前位置,在排队到达后,要页面通知到用户来完成操作。

 

8、订票当次处理成功以后,接下去的出票等等操作放在队列中进行,等待银行把款转过来,这部分也有一定实时性的要求,应当和响应用户的应用服务器分开,免得互相干扰。

 

还有一些疑问也值得讨论,很有意思,比如遇到那些抢票机器怎么处理。

 

  • 大小: 76.2 KB
   发表时间:2012-01-11  
2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。

严重设计上的错误, 区间票没有考虑。 比如从上海到北京的车, 有人只买了中间的一个区间票,那剩余的那段就浪费掉了。

3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。

当操作卡壳时有可能用户永远都买不到票, 极限票1张,查询时显示有,进行购票操作, 这时票已经被锁, 而卡壳发生后再查询时已经显示无票。

4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由于车票查询实时性有一定要求,可以设置每个查询页面有10分钟的生命周期,缓存文件管理算法用LRU就可以,被动更新。如果车票信息在本地,数据库节点应该会是瓶颈,好的缓存设计会很讨巧,可以大大减小数据库压力。

大哥10分钟是什么概念, 是实时性的概念吗? 10分钟前你看着还有20张票, 5分钟后看看还有20张票, 10分钟后你开始操作买票了, 票没了。 心凉了吧。

加大内存, 分布式数据缓存到内存当中。 查询票时直接到内存中取。 比如北京的缓存以北京为起点的票数据。 数量不会非常大。 直接内存缓存完全可以解决。需要预防的问题是断电。
0 请登录后投票
   发表时间:2012-01-11   最后修改:2012-01-11
1、前端负载均衡
   最好使用DNS负载均衡,比如ChinaCach
nslookup www.sohu.com
Server:  cnxadc01.asia.corp.platform.com
Address:  172.17.192.21

Non-authoritative answer:
Name:    fbjuni.a.sohu.com
Addresses:  61.135.181.166, 61.135.181.168, 61.135.181.170, 61.135.132.55
          61.135.132.60, 61.135.132.85
Aliases:  www.sohu.com, gs.a.sohu.com
2、后台数据处理
   Oralce、DB2或者MySQL 数据库集群
3、历史数据整理
   使用NoSQL数据库

4、最重要的
   一定要在上线之前做压力测试!!!

详细实现参考
http://www.amazon.cn/%E4%BA%91%E8%AE%A1%E7%AE%97-%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E5%AE%9E%E8%B7%B5-%E5%BE%90%E5%BC%BA/dp/B006TODQG6/ref=sr_1_1?ie=UTF8&qid=1325831840&sr=8-1
0 请登录后投票
   发表时间:2012-01-11  
joknm 写道
2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。

严重设计上的错误, 区间票没有考虑。 比如从上海到北京的车, 有人只买了中间的一个区间票,那剩余的那段就浪费掉了。

3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。

当操作卡壳时有可能用户永远都买不到票, 极限票1张,查询时显示有,进行购票操作, 这时票已经被锁, 而卡壳发生后再查询时已经显示无票。

4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由于车票查询实时性有一定要求,可以设置每个查询页面有10分钟的生命周期,缓存文件管理算法用LRU就可以,被动更新。如果车票信息在本地,数据库节点应该会是瓶颈,好的缓存设计会很讨巧,可以大大减小数据库压力。

大哥10分钟是什么概念, 是实时性的概念吗? 10分钟前你看着还有20张票, 5分钟后看看还有20张票, 10分钟后你开始操作买票了, 票没了。 心凉了吧。

加大内存, 分布式数据缓存到内存当中。 查询票时直接到内存中取。 比如北京的缓存以北京为起点的票数据。 数量不会非常大。 直接内存缓存完全可以解决。需要预防的问题是断电。

区间票那个说得很对。
后面的页面缓存的那部分确实有你说的问题,也许数据存放在内存里面会解决你说的这个问题。需要有专门的机制维护内存和数据库内的一致性。
0 请登录后投票
   发表时间:2012-01-11  
如果让我做,我转手外包给IBM 我只赚中间的插件,呵呵
0 请登录后投票
   发表时间:2012-01-12  
现在有个问题,就是大家都站在岸边纯粹以看笑话的心态来看待12306网站,就没想过如果把自己扔进河里去做12306的时候又该如何?

0 请登录后投票
   发表时间:2012-01-12  
不仅每趟车一张表而且要读写分离。查询分散到n个只读的数据库。(n约等于地市的数量)
0 请登录后投票
   发表时间:2012-01-12  
如果可能的话,就让那些逮到一个话题能墨迹几十天的人,节假回家永远卖不到票。
0 请登录后投票
   发表时间:2012-01-12  
vtrtbb 写道
如果让我做,我转手外包给IBM 我只赚中间的插件,呵呵

同意,本来就有成熟方案.不过IBM要的确实贵,贵的一米.
你外包给腾讯或者淘宝吧,可以多挣点.
0 请登录后投票
   发表时间:2012-01-12  
vtrtbb 写道
如果让我做,我转手外包给IBM 我只赚中间的插件,呵呵

咱俩想法一样。如果出事了还可以往下推。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics