一 12306深度优化整体架构
在节假日和春节时候，火车票提前预售。在预售的点会有大量人们抢购车票。由于高并发，导致服务瘫痪。
1.1 解决方案
内存计算余票
异步交易系统(削峰方案)
数据库进行高可用搭建(读写分离)
1.1.1 削峰解决方案
1. 削峰方案:
对于瞬时流量我们最先想到的是中间件进行削峰，把直接调用转化为间接异步推送。中间队列在一瞬间接受流量锋，在另外一端平滑的将消息推送。
2. 答题：
在下单时候，我们需要答题。因为每个人的答题速度不一样，错开抢票时间。
3. 分时间段发放票：
将票分多个时间段进行发放
1.1.2 数据同步方案架构
后台管理员按照日期生成乘车计划、座位信息、车次信息，并通过logstash将数据同步到ES和redis中。
二 用户下单分析
用户在下单时候，用户经历下单、扣库存、支付。在高并发场景下保证，车票不多买也不少卖，且支付后车票真实有效。
2.1 对下单操作分析(异步下单的优势)
1. 方案一
用户在下单完，立马扣除库存，等待用户支付。且创建订单和扣除库存是原子操作。能保证不超卖问题。
方案问题：
在极度并发请求下，每次创建订单对内存操作对性能影响很大。订单数据需要保存到数据库，对数据库压力很大。
如果很多人下了订单，但是不支付。会导致很多票没有卖掉。
2. 方案二
在极度并发场景下，库存减为0时候，很多用户抢到订单却不能支付。而且也不能避免数据的IO操作。
3. 方案三
用户选择乘车计划，点击下单-->进入下单服务集群中，--》判断redis库存是否充足，否(直接响应票已售空)、是(预扣库存)-》把下单信息
发送给mq，es同步库存信息-》如果用户支付，订单处理服务进行订单信息入库，并响应成功信息。如果超时未支付，redis进行库存回退，es进行库存回退。
2.1 下单操作
2.1.1 nginx进行限流配置
为了防止一些抢票助手发送无用请求，采用nginx进行限流操作。
1. 限制访问频率：
limit_req_zone:单位时间内请求数，采用漏斗算法。
2. 限制并发连接数：
limit_conn_zone：同一时间的连接数。
2.1.2 下单流程
1. 订单生成：
预扣库存
找对应日期对应车次对应座位类型的乘车计划库存(站票，坐票，硬卧、软卧等)，进行库存扣减。
分配座位
遍历所有指定座位类型车厢的key（集合）。
遍历集合获取每个车厢的座位(集合)。
遍历集合获取每一个座位对应状态。
如果座位没有售出，标记座位并更改座位的状态。
生成订单
在创建订单时候，我们可以采用一个线程完成。且线程执行完毕，我们要获取线程的执行结果，采用Callable执行订单创建。
在线程中创建订单对象。
将指定日期的乘车计划封装到一个对象中。
生成订单。
Redis排队
采用 Redis 中的 ZSet 集合存储排队信息，使用：列车编号 + 乘车日期 + 用户 id 作为 key，使用当前系统时间的纳秒值作为 value
2. 同步ES库存：
下单服务发送同步信息(乘车日期、座位性质、列车车次)到mq中。
es同步服务监听mq,获取发送信息。根据搜索条件查询到数据，并进行库存扣减。
3. 发送订单数据：
创建订单和用户信息，并设置交换机和队列。
发送订单信息，发送完订单数据，跳转到下单成功界面。下单成功界面调用排队接口，显示排队信息。
2.1.3 订单处理流程
1. 环境准备：
因为下单，写的操作远大于读的操作，因此mysql采用双主双从搭建模式。
2. 保存订单：
下单服务监听mq，如果有订单生成，对订单信息进行入库。
3. 删除排队信息：
订单保存成功后，删除排队信息。
4. 将下单结果通过websocket发送给客户端：
保存完订单数据以后，调用 WebSocketServer ，完成消息推送。
2.2 下单优化
用户已经下单了，再次提交订单是否扣除订单？
用户虽然下单了但是一直没有支付。
预扣减库存是否存在线程安全问题。
2.2.1 预扣库存优化
当该用户已经购买了指定列车的火车票，那么我们就不能再进行预扣库.
根据用户信息和乘车计划id查询订单信息，查询到信息，不进行库存扣减。
2.2.2 库存回退
1. 方案一(延迟队列)：
延迟队列：消息发送后，特定时间后消费者才能拿到消息进行消费。
2. 方案二(死信队列)：
死信队列：一个消息在队列中变成死信队列之后，消息会被从新发送到另外一个交换机中，这个交换机就是死信队列。一个消息成为死信队列情况：
消息被拒绝，并且设置 requeue 参数为 false
消息过期
队列达到最大长度
2.2.3 库存安全性判断(分布式锁)
在进行库存扣减时候，加锁。因为扣除库存是多服务，因此需要用分布式锁来解决(mysql实现，zookeeper实现，redis实现)。