12306网站架构师，你会如何设计网站的软件架构和硬件系统架构？ （2）

一 静态资源的压缩优化及CDN分发策略

12306上涉及的图片及js、css等静态资源应进行压缩后传输，设置expires属性，在浏览器端缓存，减少对静态资源访问，提高页面访问速度。

同时高效使用CDN分发策略，像北上广等一线城市应尽量分流，减轻服务器压力，防止服务器因压力过大宕机或IO低效 崩溃。

二 缓存车次信息及余票

用户登上网站后，除了登录操作流程外最火的两个操作流程应该是购票和余票查询。余票查询应及时给用户返回查询信息。所以需要优化缓存结构。车次票价等信息因为不会发生经常性的变化，所以应常驻内存，结合cdn分发策略，将用户引导至最近服务器，返回查询信息。余票数据因为涉及到需要和当前售票情况相关，所以应在每卖出一张票后同步更新缓存数据.这里需要注意的是查询余票只需要读缓存即可，在缓存存在情况下不需要去访问数据库，同步缓存在买票阶段再说明。如果缓存没有可以直接访问数据库，如果访问分流设计到位，相信缓存穿透情况会比较少，也不会对数据库带来很大压力.

三 按车次进行购票队列设计

因为国内火车票热度关系，同时并发购票情况会非常突出,目前没有看到12306有队列的排队机制，难道网站设计者想让用户立即购买票么？！这个有些疯狂，这就导致很多人上去点购票，却打不开等等。

我的想法是按照车次进行队列设计，并在缓存中维护这些请求队列.一个用户过来比如买K51车次，系统应从后端缓存中获取该车次缓存信息，并将该用户id加入队列末端，设置时间戳，并返回给用户前面有多少人等信息。维护该队列的服务器应作为后端的一层进行设计，防止一个服务器崩溃导致用户无法访问或者直接穿透到下一层。用户浏览器可以1s为单位像这些缓存层访问，缓存队列接收到后同步更新队列中该用户时间戳。对于长久没有请求的id有过期清除机制.目前一般火车车厢15-20节左右。YW25G(硬卧)定员一般66人左右,YZ25G(硬座)定员118人,RZ25C(软座)定员80人，RW25(软卧)定员36人。所以每辆火车人数在1000-2000左右.当然买票的人数可能会超过这个数值，每天买同一车次人数也不会是一个天文数字。

四 售票逻辑

售票处理只负责从前面的队列中获取买票的用户id，并发卖多少张票视情况处理。这里涉及到铁道部以前的票务系统接口，很多业内人士也反映压力最大的就是该接口调用。假设并发处理可以容纳20个（这个值因为不是内部人士，无法确认，仅是假设），则取队列中20个id，进行并发处理。就像火车站开通了20个窗口一样，对来的20个人进行售票服务，直至完成.可能这个过程可以有优化的地方，因为毕竟每个用户花在真正买票的时间不一定，有的短，有的长。买票流程应尽可能优化，尽量缩短用户购票需要的时间，提高购票速度。

售票处理得到票务处接口返回后，即同步更新该车次余票缓存，返回给用户购票信息。

五 票数据库设计

火车票数据库层应该是使用铁道部以前的票务系统，这种底层的数据库就像银行一样不会随便变更，要知道很多银行系统等数据库设计基本是90年代由IBM等那时设计的，猜测铁道部可能也会类似这样。所以作为12306等这样的外层服务，只能调用其底层的接口做一些操作。

再回到上面谈到的票务系统接口，个人觉得应尽量减少该接口的调用。目前火车购票主要有三种渠道，售票窗口（火车站及各售票点）、电话购票、12306。下面设想可能不是合理，只供大家讨论。如果这三种渠道购票比例为40%，20%，40%（这个比例可能会调整），则完全可以确定网上购票每个车次票数。

如果确定，则可以根据车次进行分库。数据库层包含一些列数据库，每个数据库可能负责多个车次信息，具体车次数量由测试压力确定。售票操作由之前调用统一的票务接口转为了在各车次数据库操作。当然票务接口也会去访问后端数据库，貌似没有不同，但是这样处理后数据库压力已经分流，网站购票只要关心分配好的这些车次数据库就好。像热点车次也应该考虑请求会比其他普通车次要高很多情况，采用更高端的服务器进行处理，相信硬件在铁道部应该不缺.

售票层次应处理好对车次票额的同步机制。任何情况下，只允许同一车次同一个人来买，保证票数的稳定.

最后，总结一下自己的思想，主要是靠架构分层思想，将12306层次分为CDN分发层、静态资源处理层、动态资源的缓存层、排队缓存层、售票层及底层按照车次水平划分设计的数据库层，最终思想要靠分流、有效排队机制及车次水平划分设计数据库等减少对系统服务器的压力，同时保证购票的准确性。