2020-02-04 10:09:36 佚名

老许

首先是分布式架构，全网CDN加速技术，数据库应该是oracle或者DB2的，数据库应该是订单数据库，用户数据库，车辆运行线路库，车票库，代理商窗口管理用户库，日志库，通过几个库的关联查询，并下单购票。

每个库都有备份。这样相当于几个数据库同时协作，小型系统一般就一个库，几个表，也能做到高并发。它这样的架构部署，既高效又节省费用。

i吕不为

个人简单谈一下百万QPS下的12306如何架构，算是抛砖引玉，下图是我画的一张网络拓扑图：

我们知道当国庆节、春节来临的时候，12306会在每天的早上8点、12点、16点等各个时间点放票，这时候在极短的时间内涌入大量的流量请求，可是说是中国互联网甚至世界互联网上最大的高并发请求量了。

网络要承受的住

那首先要保证的就是网络不能挂，大家都先不用考虑服务端具体业务怎么实现的，应该首先要考虑的是多大的网络带宽能够承受住这么大的请求量？

我们常用的方式就是一个域名解析到一个ip地址，这个ip有可能是SLB，或者我们自己装的nginx，然后通过slb再将请求均衡分发到我们的服务器上，这是最简单常见的负载均衡策略。

但是这样的单台机器负载均衡是不可能承受的住12306千百万级高并发的。所以必须在域名解析处做好DNS负载均衡，再搭建好SLB集群和Nginx集群，且是多个集群，不同的集群去处理不同的业务。大家可以看到图中网络层，第一步也是最重要的一步就是要把所有的流量均摊出来，避免单机器甚至单集群无法承受住网络流量的瞬时轰炸导致网站瘫痪。

车票查询

车票查询是最核心的业务，也是请求量最大的业务，不仅仅自家网站的大量请求查询，还有一个第三方开发的抢票软件也在不断地请求12306的车票查询业务。

下面有别的答主回答说需要用缓存，这是必然的，但也在抱怨明明有票但是就是显示没票，或者显示有票下单时候就提示没票了。这不是说12306的缓存一致性有问题，或者说这块只保证高并发了，对一致性就肯定做不到强一致性了。

分布式系统中的CAP理论大家应该都知道，CAP理论只能同时满足CP和AP或者CA，其中分区容忍性不可抛弃，那就剩CP和AP了。所以无法做到高并发高可用的同时还得做到强一致性。

另外12306也不是一次就放票出来的，需要保证车站有票、各个小站点保留一部分票，再分时间段逐次发放，既然做不到所有人都可以买到自己最想买到的那一张票，那就保证整体大部分用户买票体验嘛。

核心就是分流

大家都知道国家在治理洪水的时候，会在河流的各个地方设立大坝，逐级控制水流量，而不会把所有的水都蓄在一个地方，水位低的时候，一个大坝就搞定了，水位高的时候，各级大坝都储蓄一部分水，控制整体的洪流，这样就很少发生严重的大范围的洪灾了。

网络也是如此，将整体的网络流量请求逐级分发、均衡到各层，能在这层处理的就不要在传递到下一层，尽量保证整体的服务高可用，即使损失一些强一致性，只要保证最终的一致性就好了。

这里我没有讲各个点的技术细节，只说了个人理解的一个整体思想，按照这个思路去做整体的架构，每一个环节做到编码质量最优、高可用、高并发，再整体串起来，即可承载百万QPS的访问。

以上就是个人的一些拙见，当然实际上的12306远比我说的这些要复杂的多。这里就当抛砖引玉了，欢迎各位大佬批评指正，讨论学习，共同成长！

我是【Java架构设计】，关注我，持续为您提供优质内容！

java架构设计

我想从两个方面回答这个问题：

1、缓存的使用。大部分通过12306买票的人都有这样的经历，明明显示有票，但是下单的时候就提示余票不足，这就是缓存的副作用。不过使用缓存却也有很大的好处，极大降低了数据库的读取压力，可以支持更大的读吞吐量。对于买票这种场景也是读远高于写，特别是节假日的车票，很多人一直在刷，实际能下单的却很少。不过个人认为12306的缓存更新机制应该还有提升空间，目前的缓存更新还是有点慢。

2、队列的使用。购买节假日车票的时候也会经常遇到排队的情况，最终有可能买不到票。12306将买票需求加入到队列，然后一个个的处理，先到先得，这样可以极大的降低数据库的并发写压力，而且没有破坏公平原则。

还有一些朋友提到12306使用了阿里云，阿里云因为本身拥有很多的云计算资源，可以按需购买，对于节假日的购票高峰，12306服务可以很快速的水平扩展，满足业务需要，这也是其能够支撑百万并发的一个很重要因素。