12306终极版-这个视频告诉你：12306架构到底有多牛逼？

热门回复：

• 下次-----定:cdn不是均匀分摊是就近访问原则（你在那就访问哪里） 12306抗并发原理是网络层负载均衡，路由器用路由协议ospf负载，将流量负载到负载到服务器的VIP（虚拟IP地址） 服务器用的集群负载lsv，将从VIP得到的流量在负载到nginx，应用层负载用的是nginx，这个nginx负载为后端开发做准备 后端得到web服务器的负载流量，将数据库本地化处理，处理结果交给总库（相当于又一次负载均衡） 最后是前端，前端应尽量提升软件的代码质量为后端做准备 总结:12306的思路是负载均衡1负载好后交给负载均衡2，负载均衡2负载均衡好后交给负载均衡3，以此类推 那一层最重要的负载？当然是底层，就像盖楼，外表好看但是地基不牢是不行的，所以铁路以后很有可能像电力那样建设专网 最后说下12306即便做了大量的负载均衡，但仍然怕频繁查票不下单，或频繁下单不支付，以及DOS攻击等 对于DOS/DDOS攻击，用秘钥方式，你想访问12306吗，那先输入账号密码，当然流量清洗和抗D手段也肯定有 对于频繁查票不下单，那么你的端口可能临时被封堵，所以小心抢票软件，这类抢票软件工作原理有2种，一是频繁查票，那么这类抢票软件的结果很有可能在高峰不如手动，另一种是看票，发现有空票代你下单，这类还算靠谱 对于频繁下单取消不支付，12306设置了取消购票3次当日不能购票
• 阿成希望顺心意:不知道12306架构具体是啥样，但是12306的需求是地狱难度
• 雅韵-:12306在被大量爬数据前是更流弊的，那时候不仅仅是实时显示是否有余票，而是显示余有几张，现在没有了，这样是可以对抗一下只查列表不下订单的爬虫，因为只读缓存不读库。 另外出候补票系统出现之前，一趟车所有站点是几乎一起放票的，那个余票计算量和瞬时io可想而知，每次放票就是巨卡的时候，现在明显的放票先把除全程之外的所有订单一股脑全扔候补队列里，因为放票就是无票，后面再异步的去慢慢计算余票。整个系统的瞬时计算量瞬间就下来了。
• shadowone:光余票算法，就想不通[脸红]
• 不太重要的NPC:其实没那么复杂，主要难点在并发。 业务逻辑没难度，12306的业务逻辑是现成的。并不是让你开发一套火车票预订系统，只是按照现有的业务逻辑把它搬到网上而已。至于具体细节就不展开说了，毕竟hotel的预订系统也有很多类似的客房贩卖管理系统，而且booking系统天生就有多平台多售卖渠道的业务需求。