锁定老帖子 主题:如果让你设计铁道部购票网站,你怎么做
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-01-11
最近铁道部购票已经成为了热点话题,毛病多得一塌糊涂,如果让你来设计铁道部购票网站,你会怎么做?
这样的网站属于实时性要求较高、并发性要求非常高、容量要求一般的类型,以下是我简单的想法:
1、部署是基于CDN的,对于车票查询的环节来说,这是没有问题的。
2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。
3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。
4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由于车票查询实时性有一定要求,可以设置每个查询页面有10分钟的生命周期,缓存文件管理算法用LRU就可以,被动更新。如果车票信息在本地,数据库节点应该会是瓶颈,好的缓存设计会很讨巧,可以大大减小数据库压力。
5、应用节点的负载分担是一定要做的,查询和订票操作可以分开集群,有条件的要做硬件负载。
6、静态资源合并,落到单独的域名服务器上。
7、流量控制部分,不能只给出用户提示,应当给出用户当前在等待队列中的位置,定时更新当前位置,在排队到达后,要页面通知到用户来完成操作。
8、订票当次处理成功以后,接下去的出票等等操作放在队列中进行,等待银行把款转过来,这部分也有一定实时性的要求,应当和响应用户的应用服务器分开,免得互相干扰。
还有一些疑问也值得讨论,很有意思,比如遇到那些抢票机器怎么处理。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-01-11
2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。
严重设计上的错误, 区间票没有考虑。 比如从上海到北京的车, 有人只买了中间的一个区间票,那剩余的那段就浪费掉了。 3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。 当操作卡壳时有可能用户永远都买不到票, 极限票1张,查询时显示有,进行购票操作, 这时票已经被锁, 而卡壳发生后再查询时已经显示无票。 4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由于车票查询实时性有一定要求,可以设置每个查询页面有10分钟的生命周期,缓存文件管理算法用LRU就可以,被动更新。如果车票信息在本地,数据库节点应该会是瓶颈,好的缓存设计会很讨巧,可以大大减小数据库压力。 大哥10分钟是什么概念, 是实时性的概念吗? 10分钟前你看着还有20张票, 5分钟后看看还有20张票, 10分钟后你开始操作买票了, 票没了。 心凉了吧。 加大内存, 分布式数据缓存到内存当中。 查询票时直接到内存中取。 比如北京的缓存以北京为起点的票数据。 数量不会非常大。 直接内存缓存完全可以解决。需要预防的问题是断电。 |
|
返回顶楼 | |
发表时间: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 |
|
返回顶楼 | |
发表时间:2012-01-11
joknm 写道 2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。
严重设计上的错误, 区间票没有考虑。 比如从上海到北京的车, 有人只买了中间的一个区间票,那剩余的那段就浪费掉了。 3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。 当操作卡壳时有可能用户永远都买不到票, 极限票1张,查询时显示有,进行购票操作, 这时票已经被锁, 而卡壳发生后再查询时已经显示无票。 4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由于车票查询实时性有一定要求,可以设置每个查询页面有10分钟的生命周期,缓存文件管理算法用LRU就可以,被动更新。如果车票信息在本地,数据库节点应该会是瓶颈,好的缓存设计会很讨巧,可以大大减小数据库压力。 大哥10分钟是什么概念, 是实时性的概念吗? 10分钟前你看着还有20张票, 5分钟后看看还有20张票, 10分钟后你开始操作买票了, 票没了。 心凉了吧。 加大内存, 分布式数据缓存到内存当中。 查询票时直接到内存中取。 比如北京的缓存以北京为起点的票数据。 数量不会非常大。 直接内存缓存完全可以解决。需要预防的问题是断电。 区间票那个说得很对。 后面的页面缓存的那部分确实有你说的问题,也许数据存放在内存里面会解决你说的这个问题。需要有专门的机制维护内存和数据库内的一致性。 |
|
返回顶楼 | |
发表时间:2012-01-11
如果让我做,我转手外包给IBM 我只赚中间的插件,呵呵
|
|
返回顶楼 | |
发表时间:2012-01-12
现在有个问题,就是大家都站在岸边纯粹以看笑话的心态来看待12306网站,就没想过如果把自己扔进河里去做12306的时候又该如何?
|
|
返回顶楼 | |
发表时间:2012-01-12
不仅每趟车一张表而且要读写分离。查询分散到n个只读的数据库。(n约等于地市的数量)
|
|
返回顶楼 | |
发表时间:2012-01-12
如果可能的话,就让那些逮到一个话题能墨迹几十天的人,节假回家永远卖不到票。
|
|
返回顶楼 | |
发表时间:2012-01-12
vtrtbb 写道 如果让我做,我转手外包给IBM 我只赚中间的插件,呵呵
同意,本来就有成熟方案.不过IBM要的确实贵,贵的一米. 你外包给腾讯或者淘宝吧,可以多挣点. |
|
返回顶楼 | |
发表时间:2012-01-12
vtrtbb 写道 如果让我做,我转手外包给IBM 我只赚中间的插件,呵呵
咱俩想法一样。如果出事了还可以往下推。 |
|
返回顶楼 | |