一說起12306，大家總愛和淘寶、谷歌、京東之類的高訪問量網站比較。
他們真的一樣嗎？我們來分析一下：
先分析谷歌。假如同一時間我谷歌“蘋果”，從服務器 A 得到數據，你谷歌“橘子”，從服務器 B 得到數據，他同樣谷歌“蘋果”，卻是從服務器 C 得到數據。這就是所謂的分布式架構。
再來分析淘寶，你買一件衣服，我買一雙鞋子，業務請求很可能是從不同的服務器處理的。
淘寶、谷歌這類的網站，他們的特點是：
每個用戶的操作和其他用戶的相關性不大；也可能相關性可能很大，但是從時間上來說卻不需要立刻處理。在這個前提下，才有可能進行分布式架構。
12306的核心車票數據可以分布嗎？我們再來分析一下：
你購買了一張北京到廣州的車票，同一時間我也購買了一張北京到廣州的車票。
假如系統是分布式的，會出現什么情況呢。
服務器 A 給你出了一張票，服務器 B 給我出了一張票，結果等車的時候發現，我們兩個人的票是同一個座位，撞車了！
如何解決這個問題呢？那就是設置一個中心服務器！
外圍分布式服務器可以處理一切和車票無關的業務，比如說注冊、登陸、身份驗證、購票請求、款項支付等等等等，因為這些數據只和你自己相關，和任何其他人都沒有關系，這些數據可以用類似谷歌、淘寶之類的架構設計處理。
但是唯獨車票數據例外，因為
任何一張車票的數據發生了變化，系統必須立刻知道，並在緊接着的下一筆購票業務中反映出來，否則就會出現混亂。
會出現什么可怕的情況，大家想象一下。
真正可怕的不是一瞬間上億的訪問量，真正可怕的是
上億的訪問在同一時刻必須依賴同一個“核心”！
對，就是一個“核心”。這個核心可能是一台服務器，也可能是幾千台服務器。無論多少，
從邏輯上看，他們就是一個核心。
現在問題很清楚了，
購票的業務邏輯必然導致一個依賴核心！而上億的訪問同一時刻
依賴同一個“核心”必然導致崩潰！
似乎崩潰是必然的，但是如果我們將依賴反轉過來就發現一切問題迎刃而解。
打個比方吧，大家電腦里都有一個中心處理器 ，即CPU ，他是一個核心。假如我們讓幾萬個運算任務同一時間去搶 CPU 的控制權，CPU 必然會發呆的，給誰好呢？
CPU 想了一下發話了，大家都別搶了，都給勞資消停點！所有人，都把數據准備好：放到磁盤、內存、一二三級緩存中，然后等着。
你們誰也別來找我，我會一個一個找你們的，每人一個時間片，只要勞資還能運轉，大家的任務都能完成。
本來是海量請求依賴一個核心，現在成了核心主動去收集任務，依賴反轉了。
12306 完全可以這樣架構，外圍的分布式系統處理一切和車票無關的非核心業務，同時接受購票請求並將購票請求緩存起來。而“核心”對外圍分布式服務器進行時間片輪轉通訊，收集購票請求，並根據即時情況進行處理。秩序恢復了，高速公路終於不是停車場了。
當然了，無論怎么架構，總還是有很多人買不到票，但是秩序恢復了，這不正是我們要追求的嗎！