订票系统的特点
- 抢票，抢座位失败出的是其他座位的票
- 组合购票
- 平时访问量不高，节假日会出现高峰
- 订单的事务性要求较高
- 票数精准
- 瞬间访问量大
- 个人信息安全问题
在T31训练中，实现的仅仅是基本功能，这些可以作为需要优化的点。
针对访问量高峰引发的思考
（1）请求高峰（类似于秒杀）响应迟缓
- 请求高峰响应迟缓，放票时高并发的下单集中在一起，形成请求高峰（类似于秒杀），请求导致订单 / 电子客 票数据库负载过高，引起交易响应时间过长，造成AS的交易线程池拥堵。
下单长时间不响应，同一次购买，用户会反复重试，从而加剧拥堵。 由于响应时间过程，用户进而反复重试，一次操作变成多次，操作此时倍数增长，进一步 造成 AS的查询线程池拥堵, 导致响应时间进一步拉长。
（2）请求高峰时 数据库负载过高
- 放票时下单请求、查询请求过多， 导致订单 / 电子客票数据库负载过高，造成数据库连接数会被占满。
订单 / 电子客票数据库负载过高时，对线下车站的换票业务产生影响。
（3）级联雪崩：
- AS 线程池的拥堵进一步造成 Web 对外服务线程的拥堵，影响页面打开及业务逻辑处理，造成页面打开速度缓慢和超时错误。
（4）连接过多，性能下降
- 响应时间拉长之后，导致内外网安全平台上在活动及新建连接过多，性能下降，也导致Web访问AS出错。
针对访问量高峰引发的措施
（1）使用缓存
- 使用内存计算 NoSQL 数据库取代传统数据 库，大幅提升车票并发查询能力，车票查询的 TPS/QPS（Transaction/Query per Second）由不足 1000 次 /s 提升至超过 20000 次 /s，RT（Response Time）由原来的 1 s 缩减至 10 ms，使用户可以快速 获取到车次及余票情况。
（2）队列削峰
- 构建交易处理排队系统，系统先通过队列接收用户的下单请求，再根据后端处理能力异步地处理队列中的下单请求。
队列的下单请求接收能力超过 10 万笔 / 秒，用户可以在售票高峰期迅速完成下单操作，等候系统依次处理，等候过程中可以查询排队状态（等候处理的时间）。
（3）分库分表
- 对订单 / 电子客票进行分节点分库分表改造，将原有的 1 个节点 1 个库 1 张表物理拆分为 3 个节点 30 个库 30 张表，线上相关操作按用户名 HASH 的方式被分散到各个节点和库表中，有效提升了核心交易的处理能力并具备继续横向扩充能力，使用 户在队列中的订票请求可以得到更快的响应和处理。
（4）读写分离
- 对订单 / 电子客票生成和查询进行了读写分离：
使用内存计算 NoSQL 数据库集中存 储订单 / 电子客票，提供以 Key-Value 为主的查询服 务，订单查询的 TPS 由 200 次 /s 左右提升至 5000 次 /s 以上，大幅提升了订单 / 电子客票的查询效率。
