12306难题可依靠dbshards和aicache解决

数据库拆分

12306难题可依靠dbshards和aicache解决

继春节订票高峰时12306系统崩溃之后，中秋国庆双节铁路订票系统再次让网友内伤到吐血。网友戏言，比钓鱼岛更难登的是12306订票网站，逢节就崩溃。一年以来，12306网站面临的难题也受到业内人士与专家的普遍关注。
随着中国互联网产业的发展，基础设施不断完善，2006年铁道部着手开发12306网站，2011年6月1日正式开通订票服务。越来越多的乘客倾向于借助这个平台为自己求得宝贵的一票。然而继春节订票高峰时12306系统崩溃之后，中秋国庆双节铁路订票系统再次让网友内伤到吐血。网友戏言，比钓鱼岛更难登的是12306订票网站，逢节就崩溃。一年以来，12306网站面临的难题也受到业内人士与专家的普遍关注。
12306网站的在线售票功能，其实就是个海量事务高速处理系统，这样一个系统，并不能简单地使用通用方案进行设计。多位技术层面专家均表示，无法看到12306的相关数据，也无法提供建议。

经常接触国外尖端技术的安久云计算(ungeo.com)有限公司董事长贾进熹认为：“12306网站数据库的问题更大一些。我们知道数据库扩展三级进阶：拆业务-〉拆列-〉拆行。我发现12306还没有到第三级：拆行。没有几年的研发功力，也难有所成就，这样的情况苦了12306，更可怜了广大的订票网民。谷歌、淘宝、百度有技术，但是开源遥遥无期，如果他们找找行拆扩展数据库的解决方案或许还有救。”

安久云计算有限公司dbShards(dbShards.cn)技术顾问/亚太区高级运营经理谌祥锐认为：12306网站需要解决的根本问题就是让数据库满足高并发的访问请求。中央数据库显然无法满足，基于Oracle的RAC由于share disk，依旧无法突破硬盘IO瓶颈。基于shared-nothing架构去做行拆分水平扩展，目前看来是解决这个问题的不二选择。

谌祥锐表示： “对于12306的数据拆分可以考虑两个部分，一部分的是用户信息拆分，另一部分是列车和票务的信息拆分。两者都拆分开就可以大大缓解数据库的压力，而前端web服务的压力比较好解决，增加服务器做负载均衡即可。”

    谌祥锐介绍：dbShards是业内第一款数据库拆分软件，可适用于已有的应用及数据库。使用dbShards的应用连接至多个数据库(子库)，数据通过一个或多个拆分策略分段存储在子库内。对于12306具体而言，需要拆分两类数据，一类是火车票票务信息，按照干线信息拆分到不同的分区中，分散用户的票务信息查询请求；另一类是用户的帐户信息，按照用户id将用户信息拆分到不同的分区中，同样达到分散用户的登陆/订票请求。
    对于12306问题其实还有另外一种解决方式：使用动态缓存aicache（aicache.cn）。几乎所有人都知道对于12306的问题主要在于web处理能力和数据库的处理能力。对于数据库又分为用户数据（12306特有的数据库）和列车票务数据库（铁道部现有的）。

用户数据库可以使用dbShards进行拆分。而对于列车票务数据库，可能调整的可能性不大（这不是技术问题，而是其他问题）。那么如何优化对列车票务数据库的访问呢？aicache可以做到，利用内存作为高速缓存，是一个多线程、轻量级、充分管道化、无堵塞的应用程序设计。因此，可处理的请求达到每秒25000个，并且管理数万个并发连接。访问用户就减少了连接时间，提高了连接效率。

    “aicache是反向代理服务器，它的处理能力可以达到每秒处理25万个请求，最大并发连接数65535。而且可以以集群方式部署或分别式部署。最主要的是它可以对列车票务信息进行缓存，也可以对用户对列车票务的搜索结果进行缓存。如果只是缓存5秒，就可以降低80％的对列车票务数据库的读操作。”
    在12306运营一年之后的今天，铁道部面对大家的质疑依然表示“我们有能力解决问题”。然而，眼看着离春节不远了，网友们希望铁道部以最快的速度去解决问题，自己解决不了，可以寻求合作，要不到了春节你又如何去面对汹涌而来的网络购票大军呢？另外有微博网友呼吁，铁道部公开招标透明化，给那些有真正技术实力的企业提供机会，让12306真正成为为乘客提供便利的网络平台。
原文:virseo.com/thread-2092-1-1.html