我设计的12306

feed系统和火车票售卖系统是2个高访问高并发状况下具体很大挑战的系统。
在低访问，低并发的状况下feed系统会变的很是简单，数据模型和业务功能都比较容易设计和实现，主要的挑战就剩如何面对层出不穷的敏感词和花样百出的广告语。相比之下，火车票售卖系统在低并发时也颇有趣，假设我是12306的架构师，我会如何设计12306那。

数据模型

先将系统进行拆分，独立成用户，车票，下单3个系统，每一个系统内部封闭成多个服务，运行在独立的集群上面。这里只对车票系统进行数据模型设计。

先上ER图

数据分红动静2部分，车次，站点，座位的数据都是静态的基本不会变，能够经过运营系统提早进行录入生成；车票则根据以上三张表天天动态生成，每条车票记录一个车次上的一个座位号，初始化的始发站，终点站为该车次的始发站和终点站，数据在下单时进行更新。肯定了数据模型后进行数据库的垂直和水平拆分，首先按照车次进行分库，将不一样的车次hash到几个数据库中，减小每一个数据库的负载；而后车票表按天拆分，提早生成3个月的车票表，每张车票表只存储当天发车的车票。

用例

• case1：查询
  假设有一列从北京到深圳的火车D911，途经共20站。用户查询北京到杭州的列车，从cache中取出符合用户查询条件的车次（车次类型，始发站，终点站，始发时间，到站时间），按照车次从cache中取出北京和杭州的站点id和站序，北京站序为0，杭州站序为11。车票表中用
  ‘始发站序<=0 and 终点站序>=11 and 车次=D911 group by 座位类型’
  的查询条件便可获得每种座位的剩余票数，能够将查询的结果作一个10s的缓存，若是前端展现的不是具体的剩余票量，而是有无票，可使用一个更长时间的缓存，缓存的失效由服务端控制。
• case2：车票分拆
  假设有一列从北京到深圳的火车D911，用户购买了一张从北京到杭州的车票，按照规则优先级随机取出一张车票，车票数据为 北京-深圳，始发站序0，终点站序20，将该车票状态置为无效，插入一张数据为杭州-深圳，始发站序11，终点站序20的车票，向下单系统发起请求，写入一张北京-杭州的订单。
• case3：车票合并
  假设有一列从北京到深圳的火车D911，用户预订了北京-杭州的车票，从下单系统收到该订单失败或者超时或者退票的消息，取出其中和车票相关的信息，车次D911，北京-杭州，始发站序0，终点站序11，和车票表中该车次该座位的数据进行关联，合并数据，从新生成一条北京-深圳的车票。

队列·流控·异步·无锁实现

系统的抗压能力和是吞吐量成正比的，这也就是为何静态页面能够支持超高的QPS，查询的性能优化也比较容易，事务处理的性能提高最困难，系统处理时会保持tcp连接，占用系统资源，最终致使系统的崩溃，响应时间越快，资源的占用时间越短，吞吐能力也就越强，系统的可用性也就越高。
在某宝某猫作话费充值系统的思路彻底能够用来作火车售票系统，将下单请求持久化，系统间经过消息解耦，经过多线程队列异步处理请求。具体的实现能够在收到下单购票请求后持久化，返回给用户一个排队中的提示(1-x分钟处理完成)，按照车次放到不一样的队列中进行排队(期间能够作过滤/去重/合并处理），系统从队列中取数据进行处理。最终一致性就能够知足业务需求的地方，服务尽可能减小事务和锁的使用，提升并发处理能力。

降级

为啥要把降级单独拉出来讲，我以为本质上讲降级并非因为架构设计上的充分考虑带来的可用性和伸缩性的提升，而是牺牲一部分的用户体验换来的系统的可用性，是对峰值事件的应对策略。基本实现就是在系统埋好各类开关，能够由人工控制也能够由系统触发，保证最基本的核心功能可用，其余的非核心功能和部分用户体验能够暂时舍弃。

数据模型和业务功能就是这样，不论实现的多扭曲基本上你们均可以作出来，功能实现以后无bug是一个挑战，可以知足将来变化是一个挑战，在某个量级以后依然可用又是一个挑战。