Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

你会怎样设计铁道部购票网站?

Posted on 01/09/201206/23/2019 by 四火

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

——————————————————————————————————————————-

 

2012-1-14,根据大家的讨论摘选有意义的进行补充:

1、车次票需要包含若干个区间票。

2、倘若按照 10 分钟的页面缓存过期时间,用户很可能还是不愿意接受的,需要把数据直接写到内存里面,查询在内存里面查询,数据库只做适当时机下的持久化和数据同步用。

3、关于和淘宝相比的访问量,不见得有淘宝的大,见日均 IP 的统计:image

关于 PV,这句话很有道理:

“12306 真的有这么大的 PV 量吗?现在的 PV 这么大,那是因为我查询 100 次,1 次也查不成功,所以我就不断的刷,这本身就是在逼迫全国人民对其进行 Dos 攻击。如果查询的成功率、订单的成功率提升了,估计 PV 会直线下降。”
所谓恶性循环变指此吧。

4、关于数据库要不要集群,从目前的系统看,瓶颈不在此,而在考虑了采用内存数据存储和直接命中以后,似乎还没有这个必要。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. Flash Scope
  2. DAO 的演进
  3. 程序的库设计
  4. 对象转换的问题
  5. 重新发明轮子

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme