数据库是12306系统优化重点

　　有人说：“有人说，春运，是世界范围内规模最大的一年一度的人口迁徙运动”，小小的一张火车票，使得12306订票网站在节前成为各方关注的焦点。“当前访问用户过多，请稍后重试!”这是大量用户会碰上的无法登录;还有不少用户登录之后，却无法打开二级、三级页面，只有在不停地刷新;一些幸运的用户登录后成功付款，但却功亏一篑，却无法买票了。

　　根据徐海的分析，12306订票网站因为没有太多的图片、视频等呈现，更多的是后端的订票计算，因此在技术上数据库会面临很大压力，容易形成瓶颈。因为订票操作本身涉及到系统的实时交易，对数据库读写操作压力会比较大。徐海认为，从12306反映的问题，例如登录受限、访问速度慢、订票无响应等问题，可能都涉及到数据库部署优化问题，因此，数据库优化应该是下一步改进12306的性能需要重点考虑的一个方面。具体可以从多库数据库部署、多层数据库访问、读写分离等多个方面来进行优化。

　　首先，从数据库的选择部署来说，徐海推荐采用成熟的LAMP开源架构(Linux+Apache+Mysql+PHP)，考虑到数据库性能提升的需要，可以考虑采用多库的形式，做负载分担。也可以根据数据的安全级别、类型不同，将MySQL与Oracle等不同的数据库结合起来一起使用。

　　“一般如果要构架一个系统，通常来说是一个数据库支撑后端。对于超大型的网站来说，可以考虑把数据库切割成几个部分。有多种切割方式可供使用，例如按地域划分是一种方式，北京用户来访问的时候可以访问一个数据库，上海用户访问的时候则访问另一个库。另外也可以考虑按车票类型来划分，订票的时候T字头的可以在一个库，Z字头的可以在另一个库，这样通过多个数据库来保证整体系统的应用性能更好。”徐海认为。

　　和前面的多库数据库部署相关联，铁道部还可以借鉴一些网站的多层次数据中心设计。目前整个订票系统都是集中在铁道部的数据中心中，全国所有的订票压力都用这一个数据中心来应付，是一个典型的集中式系统。当集中式数据中心在无法应付的时候，就可以向分布式系统过渡。打个比方可以分成2层， 第一层可用来接收用户请求，判断用户请求的来源，将工作流分配到不同的数据中心，同时在全国各地构建数据中心，多个数据中心之间做定期的数据同步和容灾，构成一种分层次的数据中心。

　　另外，就12306的访问特性来说，很可能的一种情况是存在大量的读操作，写操作在其中只占较小的部分，针对这类型访问特性，可以考虑的是读写分离技术。“在大部分应用状况下，通常数据库的读、写都是一起的，就是说，一台服务器或者一个服务器组同时承担数据库读写操作，但对于订票的用户来说，很可能开始的时候需要多番查询车次而未必订票，对于一个用户来说，很可能多次的查询才会涉及到一次订票的行为，整体系统中粗略估计读操作占80%以上，写操作不到20%，对于这种情况，为了系统扩展性更好，也可以考虑读写分离。用单独的服务器组支撑读操作，写的时候，交易的时候，把写请求传到另外的服务器组中，这种架构现在已经在很多网站中应用，例如国内的一些知名大型网站。”

　　此外徐海还谈到，订票系统超过80%都是查询和检索，今天已经有一些非常适合检索应用的云计算技术，例如基于Map/Reduce的Hadoop。类似google这样的大型搜索引擎就使用了Hadoop的技术。12306订票系统中也应该使用Hadoop来进行优化。