近日，关于12306网站崩溃及登录缓慢的问题成为大家茶余饭后的谈资，而参与购票系统建设的两家上市公司太极股份和网宿科技也大为紧张。据悉，目前主营铁路网上售票业务的是铁道部下属企业，属于垄断行业国企，有人称“肥水不流外人田”（1月10日《第一财经日报》）。

日访问量最高达到14亿，看起来似乎是“人多为患”，但是我们这里不讨论人的问题，只讨论网站架构问题。

在2012年1月11日中午12点左右，打开12306的网站，第一感觉是速读挺快，UI很烂，以下面的查询余票功能为例：

首先我们看结果，从北京-石家庄的火车每天总共有80趟，也就是说应该返回80条结果；但也就是这80条结果让这个查询杳无音信（页面死了），对于电信4M的上网带宽来说不应该出现这个结果；

其次我们看界面：“北京->石家庄列车余票信息查询中……”这句话是的初衷是让用户等待查询结果，由于字体太小、不够明显，所以会导致绝大多数用户选择重新查询，这样又会增加了服务器压力；

另外在chrome下，选择日期的控件显的不够美观，兼容性不够好，页面使用图片稍多。

综上，如果按照10PV/人来算（刷票器的刷新频率绝对比人工刷票频率要高），充其量也就是刚到1一亿次的查询，这个水平比百度稍高，但是速度却比百度要慢上百倍。

一个成熟的、高负载的网站架构应该要考虑这些方面的问题：

· Cache：

         根据业务需求并结合数据库的设计，要提供相应的缓存机制，具体应该包括前端缓存、共享数据缓存、分布式缓存。按照12306的设计，共享缓存和分布式缓存应该是问题的关键所在，页面缓存其次，按照量子统计的用户系统设计方案，可以吧一些数据处理放在客户端来处理。

·  Database ：

        需要存储海量数据的时候数据库集群也不一定够，所以要用分割，把数据分割成若干块，按照需求可以按照功能、数据库进行数据分割。量子恒道日统计PV50亿，这个数据比12306要高的多。

· File System：

        对没必要存放在数据库里，也不适合存放在缓存中，

· Thread Management

        多线程的办法是由一根线程全权负责整套工序的操作。另外一个办法是把工序斩成几段，每一段由一根或几根线程负责，这种办法称为工作台。根据不同的业务需求选择多线程还是工作台。

· Scheduler

        同一个网站通常会提供多种服务，不同的服务需要调用不同的业务逻辑。有些业务逻辑可以在同一台服务器上完成，但是当业务逻辑复杂的时候，需要调用多台服务器合作完成。不同服务的受众对象不同，流量也不同，不同时段的流量也不同，同一时段不同服务的流量也不同，所以需要动态地分配计算资源。

· Signal Flow and Data Flow

        服务器与服务器之间时不时会发生数据交换，要区别数据流和控制流，Server与Server之间常设通道，专供控制流使用，传递指令去控制数据流的发送。数据流不占用控制流通道，只有在需要时才建立数据流的通道。控制流和数据流的组织，需要结合具体的业务逻辑去分配。

· Instrumentation

        哪里是瓶颈，哪里空闲。这些都需要实时监控。

所以不要说“12306.cn网站的很多链接都是用图片制作的，加载速度上，图片链接明显要比文字链接慢”，这样更显的不够专业。既然问题出来了就不要在隐瞒，要勇于面对群众的监督，不管是国企还是私企，先把问题解决了才能服务群众。

Ps：找到几年前的一个报道 《太极股份被疑瓜分国有资产》

转载请注明：26点的博客 » 从12306瘫痪看谈网站的架构