2024年春节来啦，在这里，我们祝愿每一位读者都能开开心心，过一个愉快祥和的春节。
2024年春运从1月26日开始，到3月5日结束，共计40天。是疫情防控转段后的第一个常态化春运，预计全国跨区域人员流动量将达到90亿人次，铁路、公路、水路、民航等营业性客运量将超过18亿人次。
这种国民抢票系统，100w每秒的高并发，高达700张每秒的售票能力，堪称世界顶级应用系统架构，我们通过调研、向相关工作人员咨询（非保密内容）等，对整个售票系统进行一些架构上的复现。
12306 VS 美国Amtrak售票系统
这一次，我们把西方的单层架构按在地上狠狠摩擦！
中国抓住了云计算的尾巴，把云原生玩得炉火纯青，当然，在12306这样的国民级应用上也运用了分布式云原生系统。
云原生系统在操作系统层面屏蔽了底层的物理硬件，包括cpu调度、gpu计算调度、优化，屏蔽了地理条件，能够根据不同的用户进行具体的负载均衡。并且将服务部署在云上、能够将系统交给统一的运营商进行管理、防止了因为电力问题导致的服务宕机问题。
美国的Amtrak使用的是老式的单集群但服务架构，传统BS架构，这种架构其实也有一定的好处，在分布式问题上能最小程度的保证事务问题，就算是多线程问题，也是比较简单的。但是这种问题在高并发高带宽场景下直接死亡！
抢票系统的性能瓶颈在于分布式事务
大家都知道，分布式事务就是解决：ACID问题，最终能不能把票抢到手，卖10张票是不是真的只卖了10张，而不是卖了100张（数据并发问题），
其实将这些问题解决好已经有很好的解决方案了，各类程序设计框架都有实现，但是其实我们知道一个哲学观点：普适性和契合性不可兼得，虽然java的spring boot 或者spring cloud上都有对事务的处理和较好的实现，但是其实这些普世框架都是有一定性能瓶颈，像C++的Apache Thrift、Atomix等和Java一样会存在以下问题：
两阶段提交的开销
两阶段提交（2PC）需要在准备阶段和提交阶段进行两次网络通信，并且在准备阶段需要锁定资源，这都会增加事务处理的开销。此外，如果协调者在提交阶段失败，参与者将无法确定事务的状态，需要额外的机制来恢复。
数据一致性检查
为了保证数据的一致性，分布式事务可能需要在提交前进行一致性检查。这可能需要读取和比较多个节点的数据，增加了事务处理的复杂性和时间。
其实上述两种阶段是非常耗费时间的，所以在具体的抢票场景中，我们可能会对某些实现进行重写或者自己完整实现一套。比如阿里巴巴在自己的电商系统上自己实现了一套分布式框架：Seata，研究Seata对12306的事务重写有重要意义，研究完Seata我们也基本知道12306如何入手重写相关框架。
Seata框架解析
Seata的核心思想是基于两阶段提交协议，事务处理，对于电商系统而言，Seata就能在电商交易上比自带的事务处理速度快。详细研究Seata对我们研究12306的抢票系统有指导性作用。
Seata的执行流程大致如下
-
TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。 -
XID在微服务调用链路的上下文中传播。 -
RM向TC注册分支事务，将其纳入XID对应全局事务的管辖。 -
TM向TC发起针对XID的全局提交或回滚决议。 -
TC调度XID下管辖的全部分支事务完成提交或回滚请求。
Seata与Java自带的事务框架主要区别
分布式事务支持
事务传播行为
全局事务管理
故障恢复和容错
透过seata看12306的基本事务结构
NEW YEAR
点个在看你最好看
原文始发于微信公众号（代码小铺）：世界之最，超级并发抢票平台-----深入解析12306购票系统(上)
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论