买票难，难在供需关系，除了数量上，还有可获得性上。一个回家的火车联运方案，从某个始发站到某个终点站，票的供给在于放给该始发站的所有可到终点站的票数，当然还可能包括始发站之前的一些站到终点站的票数。而需求更大。更关键的，是需求释放的时间较短，构成并发。而网站需要在较短时间内，处理这些并发，按先到先得原则，给各请求预放票，生成订单，支付成功后放票，支付不成功不放票。
我们具体来看看用户的操作行为:
1, 登录12306网站，或app；
2, 用户注册;
3, 用户登录;
4, 用户选择日期，始发站，终点站，查询车次，车票，座次，铺次，价格，历时等信息;
5, 客户预购票;
6, 排队，预放票;
7, 支付，放票;
逐个进行分析:
1, 登录12306网站，或app；
输入一个域名，经过dns解析，指向到某ip地址和端口，通过负载均衡，跳转到对应的web服务器。这里可以在全国部署sdn分布式集群，让不同的用户根据物理距离或ip源，经过一个统一的负载均衡策略，指向离客户端最近的一个web服务器，以节省传输的速度。
这种部署有地域性和时效性问题。地域性是指我国幅员辽阔，如果在全国所有地区都自费建立分布式机房的话，成本会非常大，可以集中在几个大的站点进行部署。时效性是指这种并发主要集中在重大节假日，可以只在这个时期使用这种策略，或者在这段时期把这种策略部署得更全面，平时可以不进行使用。还可以通过市场化方式，临时购买一些云服务器或者租用一些稳定的服务器进行部署。
另一个是将买票卖票的业务数据单独剥离出来，作为一个独立域名，将12306现有的其他辅助功能通过链接的方式跳转出去，让网站专注于查询和购票。
同时将网站的很多资源静态化，减少使用图片，动画，特效等，减少带宽压力，最好做成纯文本类型（图片校验除外）。
2, 用户注册;
增加注册和校验难度，实名制，手机，身份证验证，防止机器人。
3, 用户登录;
用redis-Hash缓存session，账号信息，登录时间和次数，单点，防止恶意登录，浪费资源。
4, 用户查询;
这个是第一个重点。我的想法是，把每个车次都作为key，而这个车次的其他信息作为value存入redis-Hash中。缓存有效期可以根据需要设为5-15-30秒。
单列火车的查询，在火车表中，建立起始站和终点站的索引，从起始站到其他站的车票数量，是起始站到该站的所有站与站之间的车票数量最少的那个值觉得的，类似于木桶理论。
多式联运（转车）的查询，需要在每列火车之间简历簇索引，具体可参见 https://new.qq.com/omn/20180423/20180423G08ZGL.html
每次成功放票后，集中一个时间点如15-30秒去更新一次缓存，主要是票数，还有车厢，座位号等。
还需要思考，明天再写。