12306项目，被问麻了！

最近在做校招面试，收到的很多同学都在写12306这个项目，对于校招来说，我们不谈是否烂大街这个问题，毕竟大部分同学在没有实习的情况下是无法接触系统全面的企业级项目的，能够自圆其说，有自己的思考就是好项目。这个项目还是有很多技术亮点的，但实际上从我收到的简历来看，90%的简历都是不合格的，绝大部分就像这个简历一样华而不实，有可能就是照着同一份模板抄的，根本没考虑合理性。

像这个简历我站在面试官角度谈几个主要缺点：

技术栈堆叠严重：大部分学生觉得我做的项目引入的技术栈或者微服务框架越多，简历越高大上，这个简历也不例外，每条的开头都在将引入什么框架（比如Redisson、Caffeine、Sentinel、动态线程池）。而实际上，很多时候毫无意义，甚至适得其反。技术框架的引入会带来系统的复杂性，运维成本的增加。面试官多半会反问，基于什么考虑要引入，不引入这个框架能不能解决问题，同类其他方案的优缺点对比。给自己埋了不少坑
没有抓住核心业务：我说几个12306的核心业务，

余票扣减的复杂性：比如A->B->C->D（贴图），B->C站点的余票减了1，那么所有经过C点的余票都要扣减，这种单一站点更新带来的写扩散问题，如何优化？车次表、座位表、余票表如何设计？
支付的一致性：重复支付了怎么办？支付和余票如何保证一致性？支付方式如何快速扩展？
大规模购票的并发问题：这个是12306最大的难点，峰值期qps在上千万，比双11淘宝的峰值还要高出几倍。怎么解决，不是套几个通用的方案就可以的，什么限流、缓存、消息队列。是需要深入业务的，比如引入消息队列，MQ的峰值也就10万，所有的用户都放进MQ吗，放不进来又该怎么放。同样的这么大数据量，缓存也是承载不了的，怎么办？如何拆分数据，哪些是冷数据，哪些是热数据？。在实际的12306中，是通过GemFire这个分布式内存数据库（贴图）来解决的，有没去研究过呢。

3.技术方案漏洞：这个简历里还有一些方案是有技术漏洞的，比如第三点车次+坐席做分布式锁，我理解是想保证并发情况下一人一座，但这会导致严重的性能问题，企业里面真的会这样做吗？还有lua脚本避免超卖，也是有问题，先不谈lua脚本在很多企业因为安全漏洞问题已经禁用，lua脚本本身是无法保证原子性的。还有第4点，通过分布式锁来解决缓存击穿，这个方案一样的导致严重性能问题，到底是什么业务场景会导致缓存击穿也没说清楚。

4.指标数据乱用：什么QPS从300提升到1000，99.9%成功率，任务拒绝率1%以下。纯属给自己挖坑，数据怎么来的，怎么压测的，部署了多少台机器，多大的用户量啊，一问就会懵逼！

12306的技术亮点还是比较多的，但要会抓住核心业务特点，技术方案也要在合理范围内，不是照着星球或者网上的模板抄了就不管了。

后面空了我会分享下12306中的核心技术亮点及技术解决方案，欢迎大家关注