扒一扒12306的开发难度

1. 引言

前些天不知道大家有没收到一条短信“中宣部授予单杏花同志‘时代楷模’称号，褒扬她是‘科技创新赋能交通强国建设的铁路先锋，号召全社会向她学习：

然后就是各大权威官媒的争相报道：


那么，你知道12306的开发难度到底有多大？今天本博文就来深度扒一扒。

2. 12306开发难度

12306 的开发难度主要体现在以下几个方面：

2.1 业务逻辑复杂

1. 车票库存计算： 一趟列车经停多个站点，车票种类繁多，如北京南到上海虹桥站经停 24 个车站的高铁，车票销售方式有 276 种，且售出一张票后库存变化复杂，涉及多个站点车票库存的增减，再叠加选座、退票、改签等功能，计算量呈几何级数增长.
2. 多种业务规则： 需考虑区间限售，按区间由长到短顺序放票，保证长途旅客席位；候补购票要按申请先后顺序处理；还要兼顾选座、退票、改签等业务规则，各规则相互影响，增加了系统设计和实现的难度.

2.2 高并发处理要求高

1. 流量巨大： 春运等高峰期，12306 系统的日页面浏览量和售票量极高，如 2024 年春运，单日售票量最高达 2091.6 万张，日页面浏览量最高达 898.3 亿次，高峰时每秒售票量达 700 张，对系统的并发处理能力是巨大挑战.

2. 实时性要求强： 大量用户同时查询、购票，系统需在短时间内完成交易处理和余票信息更新，确保各渠道数据的一致性和准确性，传统的分布式数据库、缓存、负载均衡技术难以满足需求.

2.3 数据一致性维护难

旅客每查一次票，线上网站和线下高铁车站的电脑都要同步更新车次和剩余票等信息，以避免一票多售，这需要在高并发环境下实现大量数据的实时更新与同步，保证数据的一致性和准确性，技术难度较大.

2.4 安全防护压力大

作为全国性的票务交易系统，12306 涉及大量用户的个人信息和出行数据，如姓名、身份证号、联系方式等，一旦数据泄露，将对用户的人身财产安全造成极大威胁，因此需建立高强度的安全防护机制，如加密传输、访问控制、数据备份等，防止数据被窃取、篡改或滥用.

2.5 系统集成与兼容性挑战大

12306 需要与铁道部原有的信息数据库、电话售票系统、窗口售票系统等进行数据对接和集成，实现线上线下业务的协同，同时还要兼容不同的操作系统、浏览器、设备终端等，确保系统的稳定性和可用性.

3. 12306的主要技术架构

12306 的主要技术架构包括以下几个重要部分：

3.1 分布式集群部署

1. 服务器集群： 通过大量服务器组成集群，共同承担系统的各项任务。如将查询服务、购票服务、订单处理服务等分别部署在不同的服务器集群上，当用户发起请求时，可根据请求类型分配到相应的服务器集群进行处理，避免单点故障，提高系统的可靠性和处理能力.

2. 数据分布式存储： 采用分布式数据库技术，把车票数据、用户数据等分散存储在多个数据库节点上。例如，按照车次、车站等信息进行数据分片，不同的分片存储在不同的数据库服务器中，这样在处理大量并发请求时，可以并行地从多个数据库节点获取数据，提高数据查询和处理的效率.

3.2 多层负载均衡

1. 网络层负载均衡： 在网络层面，利用 OSPF 等路由协议自动计算路由接口的 cost 值，将流量均衡到不同链路，实现网络带宽的合理利用，确保系统在高并发时网络的稳定性和流畅性 。

2. 服务器层负载均衡： 采用 LVS 等技术实现服务器层的负载均衡，根据预设的负载均衡算法，如轮询、加权轮询、IP 哈希等，将用户请求均匀地分发到后端的多个服务器上，避免某些服务器负载过高，而其他服务器闲置的情况，提高整个系统的资源利用率和响应速度.

3. 应用层负载均衡： 使用 Nginx 等反向代理服务器作为应用层负载均衡器，进一步对请求进行分发和处理。Nginx 可以根据请求的内容、URL 等信息，将请求转发到不同的后端服务器或服务器集群，同时还能提供缓存、SSL 加密等功能，增强系统的性能和安全性.

3.3 微服务架构

1. 服务拆分与独立部署： 按照业务功能将系统划分为多个微服务，如用户服务、车票查询服务、购票服务、订单服务、支付服务等。每个微服务都可以独立开发、测试、部署和扩展，便于根据不同业务的负载特点进行灵活的资源调配和优化.

2. 服务治理与协作： 借助 Spring Cloud 等微服务框架，实现服务的注册与发现、配置管理、熔断限流、分布式事务等功能。通过服务注册中心，各个微服务可以自动注册和发现其他服务的地址，实现服务之间的动态调用和协作。同时，利用熔断限流机制，可以在某个服务出现故障或高负载时，及时切断对该服务的调用，避免故障扩散，保障整个系统的稳定性.

3.4 数据库优化

1. 数据分片与读写分离： 数据分片是将数据按照一定的规则分布到多个数据库节点上，如按照车次、车站等维度进行分片，以分担查询压力。读写分离则是将数据库的读操作和写操作分别部署在不同的服务器上，通过主从复制等技术，将写操作同步到从库，读操作则主要由从库承担，提高数据库的读写性能.

2. 缓存技术应用： 使用 Redis 等内存数据库作为缓存，将热门车次信息、常用查询结果等频繁访问的数据缓存到内存中。当用户再次查询时，直接从缓存中获取数据，大大减少了对数据库的访问次数，提高了系统的响应速度。同时，还可以采用分布式缓存技术，进一步提高缓存的可用性和扩展性.
3. B + 树索引查询： 对数据库中的车票信息、用户信息等数据表，根据常用的查询条件，如车次编号、出发地、目的地、乘车日期等字段建立 B + 树索引。B + 树索引可以快速定位到符合条件的数据记录，提高查询效率，尤其在处理大量并发查询时，能够显著缩短查询响应时间 。

3.5 异步处理机制

1. 消息队列异步处理： 引入 RabbitMQ 等消息队列，将一些不需要立即返回结果的操作，如订单生成、支付通知等放入消息队列中异步处理。用户在提交购票请求后，系统先快速响应用户请求，告知用户购票请求已受理，然后将购票相关的业务逻辑放入消息队列中，由后台的消费者进程慢慢处理，这样可以提高系统的并发处理能力，避免用户长时间等待.

2. 异步交易排队： 在购票过程中，采用异步交易排队机制，当同一时间有大量用户抢购同一车次的车票时，系统先将用户的购票请求放入队列中，按照先后顺序依次处理，确保车票的销售不会出现超卖等异常情况，同时也能提高系统的并发处理能力和稳定性.

3.6 混合云架构

公有云与私有云结合： 在平时，系统主要运行在铁科院的私有云环境中，以保障数据的安全性和隐私性。而在春运等业务高峰期，将部分非核心业务，如查询服务等，迁移到阿里云等公有云平台上，借助公有云的弹性扩展能力，快速增加系统的资源，分担私有云的负载，确保系统能够稳定运行，满足高并发的业务需求。

4. 12306算法难度

4.1 库存计算复杂

以一列从 A 站到 Z 站经停多个站点的列车为例，若有 3 种座位，车票的种类会远多于座位种类。如北京西到深圳北的 G71 次高铁，有 17 个站，仅按上下车站点算就有 136 种车票，每种座位对应一种车票，共 408 种商品。售出一张票，库存变化复杂，如售出北京西到保定东的票，不仅该票种库存减一，北京西到后续多个站点的车票库存也要减一，若售出北京西到深圳北的全程票，需减库存的商品数更多.

4.2 高并发处理困难

春运等高峰期，12306 系统面临巨大流量压力。2024 年春运，单日售票量最高达 2091.6 万张，日页面浏览量最高达 898.3 亿次。大量用户同时查询、购票，对系统的并发处理能力要求极高，传统的分布式数据库、缓存、负载均衡技术难以满足需求.

4.3 余票实时更新与同步要求高

旅客每查一次票，线上网站和线下高铁车站的电脑都要更新车次和剩余票等信息，以避免一票多售。系统需在短时间内完成大量数据的实时更新与同步，确保各渠道余票信息的准确性和一致性.

4.4 多种业务规则需综合考虑

需考虑区间限售，为保证长途旅客席位，会先限售部分短区间车票，之后再按区间由长到短顺序放票。候补购票需按申请先后顺序处理，且不能部分满足候补需求。此外，还需考虑选座、退票、改签等业务规则，这些规则相互影响，增加了算法的复杂性.

4.5 智能分配与优化难度大

系统要综合考虑乘客购票历史、乘车偏好、当前购票需求热度等多种因素来智能分配票源，以提高资源利用率和旅客满意度，这需要复杂的算法模型和大量的数据支持.

5. 12306如何应对高并发处理需求

5.1 分布式集群部署

将系统的不同功能模块部署在多个服务器上，形成集群，共同承担用户请求的处理任务，实现负载均衡，提高系统的整体处理能力和可靠性.

5.2 多层负载均衡

在用户请求到达服务器的过程中，设置多层负载均衡机制。如使用 OSPF 自动计算路由接口的 cost 值，将流量均衡到不同链路；采用 LVS 技术的 IP 负载均衡和基于内容请求分发技术，将请求转移到不同服务器；利用 Nginx 的加权轮询等方式，进一步优化请求分配，确保各服务器的负载相对均衡，避免单点故障.

5.3 微服务架构

按照业务特性将系统划分为不同的微服务模块，如购票服务、余票查询服务、用户服务等，每个模块独立开发、部署和扩展，提高了系统的可扩展性和维护性，便于针对不同业务模块的高并发特点进行优化.

5.4 数据库优化

1. 数据分片： 将数据分布在多个存储节点上，分散查询压力，解决单个数据库服务器无法承受高并发压力的问题.

2. 读写分离： 将数据库的读和写操作分别在不同的服务器上执行，把大部分查询请求分配到读服务器，提高查询性能.

3. 使用缓存： 借助 Redis 等缓存技术，将经常查询的数据存储在内存中，减少直接对数据库的访问，提高查询性能.
4. B + 树索引查询： 利用 B + 树作为索引结构，对车次、出发地、目的地等字段建立索引，提高查询效率.

5.5 异步处理机制

采用异步交易排队等异步处理方式，先扣除库存，然后异步生成用户订单，这样既能保证不超卖，又能快速响应给用户，提高系统的并发处理能力.

5.6 混合云架构

在春运等高峰期，将查询功能等部分业务分担到阿里云等公有云平台，减轻铁科院核心数据库的负担，实现资源的灵活调配和高效利用.

6. 12306的支付架构

6.1 支付架构概述

12306的支付架构是一个集成了多种支付方式和安全防护措施的复杂系统。它旨在为用户提供多样化的支付选择，同时确保支付过程的安全性和可靠性。该支付架构与12306的购票系统紧密集成，实现了从购票到支付的无缝衔接。

6.2 支付架构核心组件

1. 支付网关
   支付网关是12306支付架构的核心组件之一。它负责接收用户的支付请求，并将其转发给相应的支付渠道进行处理。支付网关还具备对支付请求进行验证和授权的功能，确保支付请求的真实性和合法性。
2. 支付渠道
   12306支持多种支付方式，如银行卡支付、第三方支付平台（如支付宝、微信支付等）以及铁路e卡通等。这些支付方式通过不同的支付渠道实现，支付网关会根据用户的支付选择将请求转发到相应的支付渠道。
3. 支付清算系统
   支付清算系统是12306支付架构中的重要组成部分。它负责处理支付渠道返回的支付结果，并根据支付结果进行资金清算和账务处理。支付清算系统还具备对支付异常情况进行处理的功能，如退款、撤销等。
4. 安全防护系统
   12306支付架构中配备了完善的安全防护系统。这包括数据加密技术、防火墙技术、入侵检测系统等，旨在保护用户的支付信息和资金安全。安全防护系统还具备对支付行为进行实时监控和预警的功能，以及时发现和应对潜在的安全风险。

6.3 支付流程

1. 用户选择支付方式
   在购票过程中，用户可以选择自己习惯的支付方式，如银行卡支付、支付宝、微信支付等。
2. 支付请求生成与验证
   用户选择支付方式后，12306系统会生成一个包含支付信息的支付请求。该请求会经过支付网关的验证和授权，以确保其真实性和合法性。
3. 支付请求转发与处理
   经过验证的支付请求会被转发到相应的支付渠道进行处理。支付渠道会根据支付请求中的信息，如支付金额、支付账户等，进行扣款操作。
4. 支付结果处理
   支付渠道处理完支付请求后，会将支付结果返回给12306的支付清算系统。支付清算系统会根据支付结果进行资金清算和账务处理，如更新用户余额、记录支付日志等。
5. 支付结果通知与展示
   最后，支付清算系统会将支付结果通知给用户和12306的购票系统。用户可以在购票页面上看到支付结果，并根据结果进行后续操作，如打印车票、申请退款等。

6.4 技术特点与优势

1. 多样化支付方式
   12306支付架构支持多种支付方式，满足了不同用户的支付需求。
2. 高安全性
   通过采用数据加密技术、防火墙技术等安全措施，12306支付架构确保了用户支付信息和资金的安全性。
3. 实时性与可靠性
   12306支付架构具备实时处理支付请求和反馈支付结果的能力，确保了支付过程的及时性和可靠性。
4. 可扩展性与灵活性

7. 总结

12306作为中国铁路客户服务中心的官方网站及移动应用，其整体开发难度相当高，主要体现在以下几个方面：首先，系统需要处理海量的用户并发访问，确保在高峰期也能稳定运行，这对服务器的承载能力和系统的优化水平提出了极高要求。其次，12306涉及复杂的票务逻辑和数据处理，包括座位分配、退票改签等功能，需要精确且高效的技术实现。此外，系统还需保障用户数据的安全性和隐私保护，进一步增加了开发的技术难度。综合来看，12306的开发展现了高超的技术水平和强大的系统架构设计能力。可以说12306代表了中国软件开发的最高水平。

码字不易，宝贵经验分享不易，请各位支持原创，转载注明出处，多多关注作者，家人们的点赞和关注是我笔耕不辍的动力。