铁路售票系统: 仿中国某铁路售票系统，使用本地锁+分布式锁、MQ、令牌桶限流、令牌大闸、分库分表等技术，实现高并发高可用售票，分为两个版本v1.0与v2.0，主master分支就是v2.0

<p align="center">
<h1 align="center" style="margin: 30px 0 30px; font-weight: bold;">仿铁路12306购票系统 v2.0</h1>
<h4 align="center">基于 Vue/SpringCloud 前后端分离架构</h4>

## 项目简介
12306购票服务项目旨在提供一套完整而高效的火车票购票系统，灵感源于马哥的开源12306项目。
通过封装若干**基础组件**库，如规约、缓存、日志、消息队列、设计模式等，以Starter形式提供，实现项目的松耦合和更便捷的使用。
在系统设计中，采用最新 JDK17 + **SpringBoot3**&SpringCloud 微服务架构，分为**支付、订单、用户、购票和网关**服务等五大模块，构建**高并发、大数据量**下仍然能提供**高效可靠**的 12306 购票服务。

## 技术栈
- 基础框架：Spring Boot 3.0.3 ✌️
- 持久层框架：Mybatis-plus、ShardingSphere ⭐
- 缓存框架：redis、redisson、Caffeine ⭐
- 微服务框架: Gateway、Nacos、Sentinel等 ⭐
- 中间件：RocketMq、Canal ⭐
- 其他框架：Hippo4j、crane4j、XxlJob等 ⭐

## 基础业务
![](https://pic.imgdb.cn/item/65c21c929f345e8d03fd9e93.png)
## 亮点难点
### 设计模式
设计模式组件库（index12306-designpattern-spring-boot-starter）中封装了策略、责任链、构建者等多种设计模式，在项目中多处使用。例如：
1. **策略模式**：用户购票时根据不同座位类型（一等、二等、商务）自动分配对应的选座策略，体现了策略模式。策略模式允许定义一系列算法，将它们封装成独立的策略类，并使得这些策略类可以互相替换，从而使得客户端可以独立于具体的算法变化。这种设计带来了高度的代码复用和可维护性，因为每个座位类型都有自己独立的实现，当需要添加新的座位类型或者调整分配逻辑时，只需增加或修改相应的策略类，而不会影响到其他部分的代码。这实现了座位分配的灵活性和可扩展性，使得系统更容易应对未来的变化和需求，同时也提高了代码的清晰度和可读性。
2. **责任链模式**：当一个用户发起请求时，顺利的话请求会经过所有拦截器，最终到达业务代码逻辑；或者也可以实现不满足某种条件时被打回，不进行业务逻辑处理，项目中对用户信息的校验，车票信息的校验等多处都采用了这种模式。在责任链模式中，多个处理器（参照上述拦截器）依次处理同一个请求。一个请求先经过 A 处理器处理，然后再把请求传递给 B 处理器，B 处理器处理完后再传递给 C 处理器，以此类推，形成一个链条，链条上的每个处理器各自承担各自的处理职责。
3. **构建者模式**：对实体对象的封装采用了构建者模式，这种设计模式使得对象的构建过程更加灵活和可读。通过构建者模式，可以通过链式调用的方式设置对象的属性，而不必依赖多个构造函数。这提高了代码的可维护性，同时允许逐步构建对象，避免了过多的构造器参数。构建者模式为实体对象的创建提供了一种优雅而清晰的解决方案，使得项目中的各种对象的构建过程更加简洁、可扩展。
### 海量数据和高并发
为了实现特定情况下可能出现的高并发，项目采取了一系列关键技术和策略：
1. **分布式架构：** 引入了Spring Cloud用于构建分布式系统，通过微服务架构实现各个模块的解耦，将服务拆分成支付、订单、用户、购票和网关服务等五大模块，提高系统的可伸缩性和弹性。
2. **数据库优化：** 使用ShardingSphere进行数据库分库分表，水平扩展数据库，提高数据存储和检索效率。采用缓存机制，如Redis缓存热点数据，减轻数据库压力。同时在底层的缓存组件库种采用了双重校验锁机制，进一步减少访问数据库的次数。在极大并发情况下，还采用了分布式锁+令牌校验机制限流，最大程度保证系统的可靠性。
3. **异步消息队列：** 应用消息队列实现异步处理，将一些操作异步化，提高系统的响应速度和并发处理能力。例如通过RocketMQ延时消息特性，完成用户购票 10 分钟后未支付情况下取消订单功能。
4. **定时任务：** 将缓存更新时查询数据库的任务交由定时任务自动处理，例如：查询地区列表和站点关联关系和站点详细信息定时任务，构建缓存数据，并设置有效期，保证系统在运行期间能够迅速获取和提供地区站点信息。采用定时任务的方式，能够保证这一操作是自动、高效且可靠的。
5. **负载均衡和高可用：** 使用负载均衡技术确保流量均匀分布到不同的服务器，通过集群和容器化技术提高系统的可用性和稳定性。在压力过大情况下，可以部署redis集群，实现系统的高可用。
### 缓存一致性
为了满足用户对一趟列车不同站点不同座位类型的余量查询需求，本项目将这些余量信息存储在缓存中，以便用户可以快速查询。然而，在用户创建订单并完成支付时，需要同时从数据库和缓存中扣减相应的列车站点余票。这种设计不仅提高了查询效率，也保证了数据的一致性，确保订单操作的准确性。在这个过程中，**缓存与数据库的一致性**问题也需要解决，采用的方案是通过 Binlog 异步更新列车缓存，也就是使用 Canal 监听 Binlog ，该方案将数据库的数据变更通过 Canal 转发给消息队列的特定 Topic。客户端应用程序需要监听该消息队列的 Topic，以保持缓存与数据库的一致性。
### 消息幂等性
消息中间件是分布式系统中常用的组件，它具有广泛的应用价值，例如实现异步化、解耦、削峰等功能。通常情况下，消息中间件是一个可靠的组件。这里的可靠性指的是，只要消息被成功投递到了消息中间件，它就不会丢失，至少能够被消费者成功消费一次。然而，这种可靠性特性也会导致消息被多次投递的情况。因此，需要**保证消息的幂等性**，即每条消息被执行且只执行一次。
本项目采用的方案是定义幂等注解+AOP，结合策略模式+模板方法模式，提供参数方式、SpEL 方式、Token方式实现幂等接口，可通过注解中的”type“指定。底层通过分布式缓存保存消息的消费次数，在消息消费一次后设置标识为不可再次消费，并在600s后移除，达到保证消息幂等性的目的。

## 分支说明
- master分支：与v2.0分支基本一致
- v1.0：目前功能最完整的分支，但是东西堆的比较多，因此重构出2.0
- v2.0：开发完成的v1.0升级版，重构项目框架，并加入其他新技术支持
- simple分支：v1.0，实现所有的业务以及高并发，但未引用微服务中间件等
- primary分支：v.1.0，最原始的分支，甚至没有预防超卖，也没有处理高并发

## 快速开始
12306 项目中包含了缓存、消息队列、分库分表、设计模式等代码，该系统提供了两种独立版本：
- **SpringBoot 聚合服务版本**：适合测试和部署，可以直接启动 `aggregation-service` 聚合服务和网关服务。
- **SpringCloud 微服务版本**：微服务设计，可以分别启动支付、订单、用户、购票和网关服务。
### 环境准备
- clone代码到本地（尽量避免放在中文路径之下）
- 检查`java`环境，`node`版本，`Redis`，`mysql`，`RocketMq`，`Nacos`，没有的请自行搭建，注意node和mysql版本
- 导入源码中的DB脚本，聚合服务就只要导入data和db中带有springboot标识的SQL文件，微服务版本则导入带有springcloud标识的SQL文件
- 修改`application-dev.yml`中的`mysql`、`redis`等配置

### 后端
- 聚合版本就只要启动聚合服务和网关服务
- 微服务版本除了聚合服务都启动

### 用户端
- yarn serve

### 跑不起來？
- 配置文件中是否修改为自己的账号密码
- 项目是否指定JDK17
- Nacos是否为2.1.1

## 注意事项
- 如果座位买完了请调用座位重置接口
- 微信服务中有AI调用，如果要使用请更改api-key，注意调用收费
- canal要在配置文件中配置后才会在代码中生效

## 当前缺陷
- 缺少管理端
- 微信服务还未整合进入聚合服务

## 其他
- QQ ：3212636833 （请注明来意）

山沐与山/铁路售票系统

简介

发行版

贡献者

近期动态

山沐与山/铁路售票系统 .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

山沐与山/铁路售票系统