票.今天是个神奇的网站。

它将本身完全不透明的中国铁路票务给变得公开化起来了。

虽然还是得靠用户的力量才行，但是明显的能让更多人知道中国铁路票务到底是个什么情况。

网站大概的意思就是——从12306上每五分钟抓取一次用户请求（日期，发站，到站）的数据，存到我自己的服务器里（包含所有该日该区间车次以及所有的当时的余票数据&抓取时间），可以随时绘图出来余票数量的走势。

为什么想要写票.今天呢？

因为SCat最近忙，没有时间打理余票网……

于是我觉得我干脆写一个功能类似但又不同的网站好了……

顺便当做练练手。

同时，在这里感谢SCat，Q神，沈仙，各种原火车Wiki用户以及#模拟售票官方群的各位帮忙进行了测试。

 

下面我来说说票.今天的大概架构吧。

作为一个大一学生（写网站的时候处于高三毕业状态，还没有上大学），也就是懂一些基本的网站运营维护技术。

火车Wiki在1月份的时候改写成php，公交Wiki啥时候改写的我都给忘了……总之给我积攒了不少php经验。

手机版和电脑版几乎没有区别，唯一的区别就是界面区别；后台处理的代码几乎完全可以通用。

但是，票.今天作为一个抓数据的网站，明显需要后台值守的进程。

那么问题来了——后台值守哪家强？

C太麻烦、C++同样的道理（而且我还不会C++）……其它很多语言更别说了。

最后，两个选择——坚持已经会的滚瓜烂熟的php和完全一点儿不会的Python.

想了想以前曾经做过的一些项目，php做后台进程的稳定性真心不敢恭维……想了想还是现学Python现卖吧。

 

Python毕竟是C族语言，还是有很多地方可以和php通用的。

之前我已经用php写好了一个完整版的抓取全国铁路余票数据的程序，用了大概一天时间改成了Python（在此之前我一点儿Python不会）。

结果发现了个大问题——全国一共有2000多个车站，2000*2000=四百万次循环……四百万次啊！！而且还有以后的数据压力有木有！！！（我知道12306上有个js有全国所有车次，分析下就能抓取到全国所有的车次了，但是数据压力啊数据压力啊……）

想了想，还是算了……还是改成了用户添加什么车就监控什么车。

很好改，十几分钟就搞定了。

为了应对大量请求，我另外买了两个服务器专门用来抓取余票数据和发送邮件（简称甲乙服务器吧）。

甲服务器每五分钟Crontab一个抓取的Client，读取用户请求然后发送到本机的Gearman Server。甲乙服务器各跑着25个值守Worker读取甲服务器请求，当Gearman有新任务立刻抓取数据。

乙服务器每五分钟Crontab一个邮件的Client，读取用户请求然后发送到本机的Gearman Server。甲乙服务器各跑着25个值守Worker读取乙服务器请求，当Gearman有新任务立刻发送邮件。

为了防止Worker进程异常退出，两个服务器每五分钟Crontab一个脚本，该脚本的作用是若发现每种Worker脚本正在运行进程数量小于25个时，自动补全回25个。对两种Worker均有效。

 

然后是前台的php，给用户看的，这都好办，就是时间问题；一点儿点儿写就行了。

数据库么——有以下表：

用户表

车站&电报码对应表

用户添加请求表（简称A表）

每个请求有一个表（去A表的重，简称B表）（在一个月之前是一天一张表，但是有的时候一张表上千万数据效率极低于是分表）

大概就这样了。

每次Python脚本从A表读取用户请求，然后12306抓取数据存到B表。

A表中同时存储每条请求的拥有的所有车次，网页先从A表读取信息，只有点击了查看趋势图才会从B表读取数据绘出图表（Highcharts绘制图表真心不错，怪不得那么些大网站都在用Highcharts）。

邮件处理么……也是每五分钟crontab（跟抓取的py一样），从数据库读取最新数据（直接抓的资源消耗太高）然后发送给用户。

用户在网站上可以选择关注的席位。

系统判断该车次的席位是通过在B表中随意找出一行（就说是直接找出来第一行就完了呗），每一个列代表一个席位。若列为NULL那么说明无该席位，反之同理。

感觉这个系统真心做的不错。（王婆卖瓜自卖自夸啊这是……）

现在的问题就是：一亿两千八百六十四万条记录，什么时候能有个好点儿的安家之地？

写了这么多，也该吃饭去了。学校的招牌印度咖喱鸡肉卷我来也~