90%的12306项目面试都挂了？这些核心业务难题根本没准备

最近做校招同学的面试，看到很多同学写了12306这个项目，根据简历的描述来看应该大多数是来自某星球或者慕课的学习项目，对于12306本身来说是有很多技术亮点的。

但从面试的情况来看，不尽如人意。核心问题主要就是根本没想到12306的核心业务问题到底在哪里，比如这个简历，堆叠了很多技术栈（分布式锁、MQ、限流、Sentinel、动态线程池），基本上就是在堆叠 八股文。面试官要的是你对于业务的理解，以及基于业务问题的技术方案能够自圆其说，有一些扩展当然更好。

这里我说几个12306核心业务问题：

1. 余票扣减的写扩散问题

12306的余票库存扣减，跟普通商城的商品库存扣减是不一样的。例如买了武汉-》成都的票，不仅仅要减掉这两个车站间余票，杭州到成都的余票也要扣减，这就是12306特有的余票扣减写扩散问题。站点越多，写扩散问题越严重。如何优化这种写扩散带来的性能问题，另外多站点的余票扣减也要保证事务性，很多同学讲到用Redis lua脚本，但lua脚本本身存在安全性问题，很多企业都禁止了，而且lua脚本也无法保障绝对的原子性，这又该如何解决？

1. 支付和库存的一致性问题

一般支付都是通过外网穿透到三方支付（如支付宝、微信）进行支付的，三方支付成功后再回调12306通知成功，然后真正扣减。如果三方支付成功，但回调失败，就导致支付和库存不一致，这该如何解决。

这时候部分同学说，引入分布式事务，二阶段、三阶段、TCC等等，但这是一个外网不太可靠的环境，用这些强一致的方案是不行的。一般我们都是通过本地消息表这种方案来做的，支付前先插入一条待支付的订单记录，然后再发起支付，支付成功回调再把状态改为已支付，如果回调失败，我们可以通过定时任务轮询这张表，找到状态还没变成已支付的记录，然后回查三方支付，进行状态的补偿。

但这个方案，有两个问题：

1. 定时任务的间隔，不好把握；间隔时间长了，补偿不及时，面临用户投诉；间隔时间短了，扫描太频繁，影响性能。这个问题如何解决?
2. 大表的扫描性能问题；订单表可能上10亿，怎么提高性能；很多同学说分库分表，那怎么分，分之后的读扩散问题如何解决；分表后，比如分了10张表，后面发现又不够用了，这时候怎么扩容？
3. 千万级并发的挑战问题

很多同学，一上来就说限流、消息队列、分库分表；开始背八股文，还是前面讲到的，面试官要的不是八股文，要结合业务来讲。比如引入消息队列，MQ的峰值也就10万，所有的用户都放进MQ吗，放不进来又该怎么放。同样的这么大数据量，缓存也是承载不了的，怎么办？如何拆分数据，哪些是冷数据，哪些是热数据？

当然实际12306中用到的IDC双活、候补购票、变态的验证码机制、分时段放票、机器上云。以及里面关键引入的存算一体化分布式数据库GemFire也是没有讲到的

鉴于很多同学都写了这个项目，我把这个项目涉及的所有核心技术问题、解决方案以及怎么给面试官讲述的面试话术逐字稿，花了30个小时以及还专门去问了当年参与过12306的阿里同事给大家整理出来了，。基本上面试官能想到的问题，都在这里了。有些同学可能买了某星球的这个项目，我也购买看了下。咱们这个面试话术，有这么几个优点：

1. 技术问题更全面更核心

星球上的项目主要讲了12306的基本问题， 比如车票搜索、下订单、三方支付的对接、分库分表、缓存一致性等；但比如写扩散问题、最短换乘问题、候补购票实现方案、如何筛选相邻座位算法优化、灰产问题、12306的真实架构分析等等是没有涉及到的。大家可以看看我们这个简历模板和你的简历区别：

1. 背就完事了

原有星球或者慕课项目可能讲了项目如何实现的技术方案，但整体比较繁琐。我本身在做面试官，面试官要的是

你按照“业务场景 -> 面临问题 -> 解决方案 -> 权衡思考 -> 潜在优化”的结构来阐述，但很多同学的总结和理解能力有限，很多时候表达的含糊不清或者理解错误，而这份面试话术将这些方案进行再消化，直击面试要点，通俗易懂的给面试官讲述出来，理解后，背就完事了，准确又快速！

1. 节约大量宝贵时间

可能有的同学会说，我自己也可以从网上去搜，去问deepseek啊。先不谈受限于个人经验问题，辨别答案准确性的能力有限，导致面试回答的是错误的答案，白白浪费了宝贵的面试机会。而且搜索这些答案也需要大量的时间精力，可能你费劲巴拉找资料的时候，别人都背了几遍答案了。

有了这份面试话术，没有买星球项目的，也都不用买了，我把所有的技术问题、业务背景、解决方案都系统整理了，秋招时间宝贵，花2，3天这个项目就解决了，多腾出时间背背八股文，早点拿offer，它不香吗？

后面我会持续更新这个面试话术，欢迎大家点赞和免费订阅，你们的点赞、评论、订阅就是我持续更新的动力！