12306的数据库设计.pdf

12306的数据库设计 原⽂地址：http://blog.csdn.net/hnkontecna/article/details/61672983 标签 标签 PostgreSQL , 12306 , 春节 , ⼀票难求 , 门禁⼴告 , 数组 , 范围类型 , 抢购 , 排他约束 , ⼤盘分析 , ⼴告查询 , ⽕车票 背景 背景 马上春节了，⼜到了⽕车票的销售旺季，⼀票难求的问题依旧存在吗？ 还记得10年前春节前买⽕车票得在放票前1天搬个⼩板凳去排队，对于热门路线，排⼀个晚上都有可能买不到票。 随着互联⽹的发展，⼏年前建设了12306⽹上购票系统，可以从电脑上买票，但是不要以为在电脑上就能买到票。 我记得12306刚推出时，经常发⽣12306⽹站打不开，⽆法付款的问题。 为什么呢？ 原因很简单，春节期间⽹上购票的⼈可能达到⼏亿的级别，⽽且放票⽇期是同⼀天同⼀个时间点，也就是说同⼀时刻12306要接受⼏亿⽤ 户的访问。 处理能⼒和实际的访问需求更不上，带来的结果就是⽹站打不开，系统不稳定的现象。 后来12306想了分线路分时段开启的办法，想办法把不同线路的⽤户错开时间来访问12306的⽹站，但是这个⽅法起初的效果不明显，并 不是所有⽤户都知道的（就好像你临时通知今天不上班，但还是有⽤户会来单位的），所以⼤多数⽤户还是集中在⼀个点去访问12306的 ⽹站。 随着硬件的发展，技术的演进，12306的系统越来越趋于成熟，稳定性和响应速度也越来越好。 据说现在很多商家还开通了云抢票业务，本质上是让你不要冲击12306系统了，把需求提前收集，在放票时，这些系统会进⾏排队与合并 购买，这种⼿段可以减少12306的访问并发。 抢⽕车票是很有意思的⼀个课题，对IT⼈的智商以及IT系统的健壮性，尤其是数据库的功能和性能都是⼀种挑战。 接下来我们⼀起来缕⼀缕有哪些难点，⼜有怎样的解决⼿段。 ⼀、铁路售票系统 ⼀、铁路售票系统 - 西天取经之路开始啦 西天取经之路开始啦 铁路售票系统最基本的功能包括 查询余票、余票统计、购票、车次变化、退票、改签、中转乘车规划 等。 每个需求都有各⾃的特点，例如 1. 查询余票，⽤户在购票前通常会查⼀下到达⽬的地有哪些余票，它属于⼀个⾼并发的操作，同时需要统计余票张数，需要很强的CPU来 ⽀撑实时的查询。 2. 购票，购票和查询不⼀样，购票是会改变库存的，所以对数据库来说是更新的操作。 ⽽且购票很可能发⽣冲突，例如很多⼈要买同⼀趟车的票，那就出现冲突了，到底卖给谁呢？ 需要考虑锁冲突，尽量的让不同的⼈购买时可并⾏，或者可以合并多⼈的购票请求，来减少数据库的更新操作。 3. 中转乘车，当⽤户需要购买的起点和到达站⽆票时，需要计算中转的搭乘⽅案。 ⽐如从北京到上海，如果没有直达车，是不是该转车呢？转哪趟，在哪⾥转就成了问题，简单⼀点就是买票的⼈⾃⼰想。 ⾼级⼀点的话，可以让12306给你推荐路线，这个涉及的是数据库的路径规划功能。 我们来逐⼀分析⼀下这些需求的特点。 1 查询余票 查询余票 1. 普通的余票查询需求 你如果要买从北京到上海的⽕车票，通常会查⼀下哪些车次还有余票。 查询的过滤条件可能很多，⽐如 1.1. 上车站、下车站、中转站 1.2. 车次类型（⾼铁、动车、直达、快速、普客、...） 1.3. 出发⽇期、时段 1.4. 到达⽇期、时段 1.5. 席别（硬座、硬卧、...站票） 1.6. 过滤掉没有余票的车次 展⽰给⽤时还要考虑到怎么排序（是按始发时间排呢，还是按票价，或者按余票数量排？），怎么分页。 眼见不⼀定为实 查询余票通常不是实时的、或者说不⼀定是准确的，有可能是后台异步统计的结果。 即使是实时统计的结果，在⾼并发的抢票期间，你看到的信息对你来说也许很快就会失效。 ⽐如你看到某趟车还有100张票，很可能等你付款的时候，已经卖光了。 所以在⾼峰期，余票信息的参考价值并不⼤，不要被迷惑了。 2. 查询余票的另⼀个更⾼级的需求是路径规划, ⾃动适配(根据⽤户输⼊的中转站点s) 这个功能以前可能没有，但是总有⼀天会暴露出来，特别是车票很紧张的情况下。 就⽐如从北京到上海，直达的没有了，系统可以帮你看看转⼀趟车的，转2趟车的，转N趟车的。（当然，转的越多越复杂）。 从中转这个⾓度来讲，实际上已经扯上路径规划的技术了。 怎么中转是时间最短的、价格最低的、中转次数最少的等等。（⾥⾯还涉及转车的输⼊要求（⽐如⽤户要求在⼀线城市转车，或者必须要转 ⾼铁））。 关于路径规划，可以参考⼀下PostgreSQL pgrouting，已⽀持多种路径规划算法，⽀持算法的⾃定义扩展。 简直是居家旅⾏，杀⼈灭⼝的必备良药。 师⽗⼩⼼，有妖怪。。。 师⽗⼩⼼，有妖怪。。。 1. ⼤多数⽤户是有选择综合症的，通常来说，⽤户可能会查 随着一年一度的春节临近，我国铁路运输部门又将迎来一年一度的客流高峰，对于广大乘客而言，能否在短时间内顺利购买到一张返乡的火车票，无疑是他们最为关心的问题之一。近年来，随着12306网站的正式上线，网络购票成为可能，然而，如何设计一个既能够满足用户需求又能够稳定运行的铁路售票系统数据库，却成为了一个极具挑战性的任务。 铁路售票系统的基本功能包括查询余票、购票、车次变化处理、退票、改签以及中转乘车规划等。每一个功能的实现都对数据库提出了不同的技术挑战。 查询余票功能要求数据库系统能够应对高并发的查询请求。用户在选择车次时会进行大量的查询操作，包括筛选条件如出发地、目的地、车次类型、出发时间和席别等。这些条件的组合将产生海量的查询请求，给数据库带来巨大的压力。为了确保系统的稳定性和查询的实时性，数据库系统必须拥有强大的CPU支持和高效的实时查询能力。然而，由于查询结果可能不是实时更新的，用户在高峰期间看到的余票信息可能存在延迟，即信息的时效性是有限的。因此，系统应采取异步统计和结果缓存机制，以及负载均衡策略，来提升查询效率和系统的稳定性。 购票是第二个核心功能，其操作涉及到数据库中库存数据的更新。由于同一车次的车票数量有限，用户在购票过程中很可能遇到票源紧张导致的并发冲突问题。为了减少并发冲突，数据库系统需要支持高效的并发控制机制，比如使用行级锁或乐观锁技术来避免数据不一致的发生。同时，系统可以采用合并购票请求的策略，减少数据库更新操作的频率和数量，从而提高整体的系统性能。 中转乘车规划则是一个更为复杂的功能，需要考虑到用户起点和终点之间可能存在的多种乘车方案。当用户的目的地没有直接的车次时，系统需提供有效的中转方案供用户选择。例如，从北京到上海没有直达车时，系统应能够根据用户的需求和偏好，推荐转车次数较少、耗时较短、价格合理的路线。这需要数据库具备高效复杂的路径规划能力，PostgreSQL的pgrouting扩展为此提供了解决方案，支持多种路径规划算法，以满足不同用户的需求。 在面对春节这样的高流量时段，12306系统数据库的设计与优化显得尤为重要。对于数据库系统而言，能否通过技术手段解决高并发问题、保证数据的准确性与系统的稳定性，是其能否顺利支撑春节售票的关键。目前，12306系统通过技术升级和策略调整，如分线路分时段放票，减轻了服务器的压力。此外，引入的云抢票服务也进一步分散了高峰期的访问压力，提高了用户的购票体验。 12306系统的数据库设计需要综合考虑高并发数据处理、并发控制、路径规划和大数据分析等多方面的需求，不仅对数据库系统的性能提出了挑战，也对IT团队在高并发场景下设计和优化数据库的能力提出了考验。随着技术的不断进步和数据库技术的不断创新，我们有理由相信，未来的12306系统将能够更好地满足广大用户的需求，提供更稳定、更高效的在线购票体验。