铁道部售票网站怎么啦？

乐淘CTO李勇：库存同步是难点

 

我的判断，除了一般的优化之外，最大的难点应该是库存同步问题。推测应该有一个全国唯一的核心库，负责维护所有车次所有座位的票务状态，完成库存查询、锁定、出入库操作。之前只是对内部的各售票点开放（估计有几万个），波动小的情况。突然对公众开放就出问题了，会达到百万并发，根本无法承受。做这种系统的，应该是跟铁道部有多年合作经验，善于做内部系统的集成公司（网上看是太极），不去评判其他，单纯从技术上看，他们对互联网大规模应用并没有经验，要知道淘宝、京东到应对这种压力经历了多少年的试错和优化，而他们一上来就搞这个，出问题是必然的。

 

莱诺斯科技(北京) 副总经理周琛: 外包带来的技术问题

 

技术层面上看应该是在web前端负载均衡、业务逻辑处理算法、业务数据缓存机制、数据库架构这些点上存在的问题；终极原因：层层外包及不愿意求助于真正的业界精英；稍有点实力的架构师，做满足一个每天百万单的系统的架构，前端性能体验要做到这么差是很有难度的。

 

Ithuriel只兌冰的白蘭地：充分使用客户端的处理能力

 

图片请求太多是个问题。但是页面加载数据JS我觉得可以考虑。图片问题可以考虑用base64对图像编码存成字符串写入页面，使用浏览器的功能做解析。毕竟，和服务器端相比，客户端的处理能力在峰值期应该要充分使用。

 

 软件工程师howardsu：问题出现在接口上

 

目前的分布式架构中每种都有自己擅长和不擅长的地方，在我看来，铁路售票系统目前出现这问题是在两个接口上写的有问题 ：

 1.是对身份证的校验动作，目前看来似乎所有需要做这个动作的系统都有问题，如果只是用算法做本地校验当然没问题，但是铁路系统售票这个活动必然要和公安系统追逃有接口，所以校验这个动作会比较慢。 

2.是票务系统本身，如果按部就班的写个资源占用的话，我想不会瘫痪，以我以前参与过的项目中抢票的系统经验看，似乎所有这种订票系统都有权重设计，所有请求并非都排在一个队列里，而且很多情况下，都是这个倒霉的算法拖了系统的后腿。

3.支付接口我估计也是个问题，但是我没有做过这方面的具体开发，有待专业人士补充。 

 

章平 ：订票系统需要整套稳定的数据组来保证

 

铁道网上订票系统，我认为不应该是一个简单的网站形式或是一个简单的项目形式然后使用负载均衡或是当前的一般矩阵就可以完成的，他需要的是一整套从上到下，从下到上的数据组矩阵来完成，设备矩阵化的同时系统也矩阵化，但是一定要从网络和技术上保障整个矩阵的稳定，数据的传输无障碍。这种矩阵搭建起来会比较麻烦，类似于企业信息化C/S向B/S系统数据之间的交互，但一定要逻辑清楚。当然单说订票前台来说数据还是简单的，但是如果后台管理的东西比较负责的话，这个数据组矩阵的不稳定性将直线上升。这种矩阵组一旦确立将会类似宿主系统类似，但是之间的协调和数据传递的效率必须保证。 

 

WalkerLin：售票网站存在的性能问题：1) 所有的静态元素都没有Expire头, 所以每次请求都会重新下载所有CSS, 2) 静态元素和动态元素使用同一域名，造成CDN无法分发静态元素 3)太多的404链接, 阻塞了浏览器的执行。

 

陈加兴：Content Distribution Network理解为分布式内容，传输HTML+CSS没问题，是技术选型不对。核心业务数据对象的设计是基本功，从序列化对象、XML到JSON，太多可用的了。铁路订票系统扩展一直是个经典设计案例，这次推出互联网订票，看似简单，实则需要兼容原有的遗留系统，不那么容易，他们正在敏捷。

 

架构师周建春：问题出在：1)开始对用户量的估算上；2)技术架构的扩容性和负载均衡布局上；3)没有预备紧急方案。硬件应该都不是大问题，买硬件加带宽现在都很方便。