12306 铁路购票服务是与大家生活和出行相关的关键系统,包括会员、购票、订单、支付和网关等服务,该项目包含了缓存、消息队列、分库分表、设计模式等代码,通过这些代码可以全面了解分布式系统的核心知识点
为了方便学习,该系统提供了两种版本:
SpringBoot 聚合服务版本:适合测试和部署,可以直接启动?aggregation-service
?聚合服务和网关服务? ? (侧重测试部署)
SpringCloud 微服务版本:适合学习微服务设计,可以分别启动支付、订单、用户、购票和网关服务? ? ? ? ? ? ? ?(侧重学习设计)
在系统设计中,采用最新 JDK17 + SpringBoot3&SpringCloud 微服务架构,构建高并发、大数据量下仍然能提供高效可靠的 12306 购票服务?
下方的架构图全面描述了项目的服务集合、组件库列表和基础设置层等要素,有助于用户快速了解 12306 平台的顶层设计和业务细节,从零到一进行构建?
如图所示,可以看到12306的基础业务有:会员服务、网关服务、购票服务以及订单服务、支付服务
说些大家对于 12306 购票时没有考虑到的一些业务点,或者存在误区的地方
背景:假设,有一站列车,途径北京南、济南西、南京南、杭州东
查询站点对应的列车车次信息
你以为:通过搜索引擎技术 ElasticSearch 技术解决,因为涉及大量的查询条件。比如:车次、车组、出发车站、到达车站、出发时间等
实际上 :当海量并发查询时,ElasticSearch 的并发能力以及资源占用情况来说,并不适用。而且,大家如果仔细思考,发现这些查询条件都是可以通过类似于 Redis 的缓存技术存储,并在内存中进行组装
买一张北京南到南京南的车票
你以为:只扣减北京南到南京南单趟的票
实际上:会扣减北京南-济南西,北京南-南京南,济南西-南京南的三趟车票。如果其中有任意条件不满足都不会购买成功
买一张济南西到南京南的车票
你以为:按照上述的逻辑,我如果通过软件恶意刷票,只买济南西-南京南的票,是不是北京南-杭州东就买不到了?
实际上:每个站数之间的数量都有规则。虽然放票时间都是一致的,但是优先大站之间的票量,避免因为大量用户购买了中间站的车票导致始发站和终点站的购票困难。该问题通过动态放票解决,比如刚开始放票时对小站之间仅开放少量票,大站之间放出来多数票。如果后续接近发车时间,再开放小站间的车票