12306，因为系统问题，成了IT业界内大家茶余饭后经常谈论的话题。
先分享一个真实故事，我同事看了12306这个网站，他说，这个网站做下来只要5万，我反驳，被他嘲笑。笑话终归笑话，没有讽刺铁道部，以及12306研发方的意思，我同事是实习生，他不懂12306。
近日，我们在一个技术群里讨论了一个开放式话题：如果我是12306架构师，该怎样设计系统架构？
讨论的内容太多，我只将讨论的最终结果做些简单梳理，并在我的blog：zouhui.blog.51cto.com上与大家分享。
背景：12306，需要解决的一个核心问题是，千万级并发的问题。同时，12306应该有自己的特色，与新浪的千万级PV很不一样。根绝目前12306的业务，12306对带宽的要求其实并不大。
架构：与其他大型网站一样，需要采用分布式设计。
前端应该有CDN，尽量将静态内容放到这一级，并配合其他CDN的应用模式；下一级负载均衡应该是DNS，将流量均匀分配到不同的IP；再下一级应该是LVS，将访问请求分发到不同的物理服务器，然后再下一层才是存储层。采用分布式貌似能解决12306的并发问题，为什么12306还是这么慢呢？
瓶颈在哪里？
瓶颈在数据库。尽可能减少到达存储层的访问请求，这才是12306问题的关键所在。
12306底层的数据库应首选Oracle.
我们假设：单数据库+单服务器的方式，用比较好的Unix服务器，使用OCI方式，对于非大字段(clob,blog字段)，每秒的入库可以达到10W。
离千万并发还差两个数量级，因此数据库也必须采用分布式。
10万的并发，WebServer有风险，实际单机apache很可能顶不住10W级并发，apache或iis很可挂了。
解决办法：采用N个服务器M个数据库的架构方式。
将服务器与数据库分开，N个服务器皆可访问M个数据库。服务器负责处理不同物理链路上的请求，服务器上采用任务均衡迁移服务，同时负责与各个数据库交互。
感性地认识这个架构，数据库按照地区划分，每个数据库做备分并做warehouse（数据仓库）将不同地域的IP分配到对应地域的服务器集群上，比如10.0.0.x网段的集群负责处理成都铁路局始发的列车订票业务，那么这个网段的集群只需要维护成都铁道部辖区内的始发列车数据即可，对于IP解析与数据分发，需要重写一个LVS分发算法。对于上海，北京，广东这种热门地区，需要做任务迁移处理。
按照以上的架构，大约需要400个数据库，1000台服务器。
最后，对于查票，定票，付宽，多学习支付宝的佳构，对于任务处理，多学习银行的任务分发。
特别感谢本群的：薛定谔的猫，那时花开，/bs暗夜未冥/bs，he,狼鱼，涛涛，等多为朋友对该话题的关注，并积极参与了讨论。
如果你是12306架构师，该怎样设计系统架构？