自從2012開始那天，網路購買火車票成了國內最火的話題，12306.cn的alexa排名從三個月前的全球萬位以外迅速竄公升至今日的全球排名1560位、中國排名102位。並且成為第11大電商**。但是由於鐵道部公開的種種原因，12306也讓人詬病不止。
其中最大的原因就是登陸12306慢，頁面打不開，好不容易開啟了，無法查詢票額，無法購買票，甚至只收錢不吐票:),在放票時間更是非常突出。
網上很多網友及專業人士都給出了自己的見解，一下是一些建議截圖：
這些都是業內的專業人士根據其多年經驗給出的自己建議。本人雖沒有他們那麼高深的學問和經驗，但是因為也要購買火車票的原因及稍有些經驗，所以也考慮了些架構方面的問題，希望和大家分享並討論。
在水木社群看到一些人談記憶體資料庫可以怎樣提高多大速度的話題，自己不太支援，首先12306並不像普通的網際網路**，可以允許一些差錯，只要誤差在合理範圍內，不會影響很大。但是像銀行及12306這種涉及使用者錢或者珍貴的火車票，我想很難容忍因為記憶體資料庫崩潰導致的一系列問題。
一 靜態資源的壓縮優化及cdn分發策略
12306上涉及的及js、css等靜態資源應進行壓縮後傳輸，設定expires屬性，在瀏覽器端快取
，減少對靜態資源訪問，提高頁面訪問速度。
同時高效使用cdn分發策略，像北上廣等一線城市應盡量分流，減輕伺服器壓力，防止伺服器因壓力過大宕機或io低效 崩潰。
二 快取車次資訊及余票
使用者登上**後，除了登入操作流程外最火的兩個操作流程應該是購票和餘票查詢。餘票查詢應及時給使用者返回查詢資訊。所以需要優化快取結構。車次票價等資訊因為不會發生經常性的變化，所以應常駐記憶體，結合cdn分發策略，將使用者引導至最近伺服器，返回查詢資訊。餘票資料因為涉及到需要和當前售票情況相關，所以應在每賣出一張票後同步更新快取資料.這裡需要注意的是查詢餘票只需要讀快取即可，在快取存在情況下不需要去訪問資料庫，同步快取在買票階段再說明。如果快取沒有可以直接訪問資料庫，如果訪問分流設計到位，相信快取穿透情況會比較少，也不會對資料庫帶來很大壓力.
三 按車次進行購票佇列設計
因為國內火車票熱度關係，同時併發購票情況會非常突出,目前沒有看到12306有佇列的排隊機制，難道**設計者想讓使用者立即購買票麼？！這個有些瘋狂，這就導致很多人上去點購票，卻打不開等等。
我的想法是按照車次進行佇列設計，並在快取中維護這些請求佇列.乙個使用者過來比如買k51車次，系統應從後端快取中獲取該車次快取資訊，並將該使用者id加入佇列末端，設定時間戳，並返回給使用者前面有多少人等資訊。維護該佇列的伺服器應作為後端的一層進行設計，防止乙個伺服器崩潰導致使用者無法訪問或者直接穿透到下一層。使用者瀏覽器可以1s為單位像這些快取層訪問，快取佇列接收到後同步更新佇列中該使用者時間戳。對於長久沒有請求的id有過期清除機制.目前一般火車車廂15-20節左右。yw25g(硬臥)定員一般66人左右,
yz25g(硬座)定員118人,
rz25c(軟座)定員80人，rw25(軟臥)定員36人。所以每輛火車人數在1000-2000左右.當然買票的人數可能會超過這個數值，每天買同一車次人數也不會是乙個天文數字。
四 售票邏輯
售票處理只負責從前面的佇列中獲取買票的使用者id，併發賣多少張票視情況處理。這裡涉及到鐵道部以前的票務系統介面，很多業內人士也反映壓力最大的就是該介面呼叫。假設併發處理可以容納20個（這個值因為不是內部人士，無法確認，僅是假設），則取佇列中20個id，進行併發處理。就像火車站開通了20個視窗一樣，對來的20個人進行售票服務，直至完成.可能這個過程可以有優化的地方，因為畢竟每個使用者花在真正買票的時間不一定，有的短，有的長。買票流程應盡可能優化，盡量縮短使用者購票需要的時間，提高購票速度。
售票處理得到票務處介面返回後，即同步更新該車次餘票快取，返回給使用者購票資訊。
五 票資料庫設計
火車票資料庫層應該是使用鐵道部以前的票務系統，這種底層的資料庫就像銀行一樣不會隨便變更，要知道很多銀行系統等資料庫設計基本是90年代由ibm等那時設計的，猜測鐵道部可能也會類似這樣。所以作為12306等這樣的外層服務，只能呼叫其底層的介面做一些操作。
再回到上面談到的票務系統介面，個人覺得應儘量減少該介面的呼叫。目前火車購票主要有三種渠道，售票視窗（火車站及各售票點）、**購票、12306。下面設想可能不是合理，只供大家討論。如果這三種渠道購票比例為40%，20%，40%（這個比例可能會調整），則完全可以確定網上購票每個車次票數。
如果確定，則可以根據車次進行分庫。資料庫層包含一些列資料庫，每個資料庫可能負責多個車次資訊，具體車次數量由測試壓力確定。售票操作由之前呼叫統一的票務介面轉為了在各車次資料庫操作。當然票務介面也會去訪問後端資料庫，貌似沒有不同，但是這樣處理後資料庫壓力已經分流，**購票只要關心分配好的這些車次資料庫就好。像熱點車次也應該考慮請求會比其他普通車次要高很多情況，採用更高階的伺服器進行處理，相信硬體在鐵道部應該不缺.
售票層次應處理好對車次票額的同步機制。任何情況下，只允許同一車次同乙個人來買，保證票數的穩定.
最後，總結一下自己的思想，主要是靠架構分層思想，將12306層次分為cdn分發層、靜態資源處理層、動態資源的快取層、排隊快取層、售票層及底層按照車次水平劃分設計的資料庫層，最終思想要靠分流、有效排隊機制及車次水平劃分設計資料庫等減少對系統伺服器的壓力，同時保證購票的準確性。
12306網上購票進行身份核驗的步驟
12306自從開始身份核驗後，引起很多爭議，而且新的政策出來後總要去研究解讀，導致很多人不知如何去做。相信很多人會問 12306註冊之後，賬號啟用了,但是身份有待核驗，請問這個需要多長時間呢 然後很多人說7天15天什麼的，其實可以看到12306中的 鐵路網際網路購票身份核驗須知 裡根本沒有提到時間期...
iOS架構篇 3 網路介面封裝
關鍵字 ios,網路介面封裝,alamofire,swift 網路介面api通常都需要自己封裝一套管理，這裡以swift版的alamofire為例.實現功能 1.暴露引數請求位址url 請求方法method 請求引數params 請求頭header 請求響應response 響應資料 響應頭resp...
Python3網路程式設計2 網路檔案的寫入和讀取
1 檔案開啟模式 r 以讀寫模式開啟 w 以讀寫模式開啟 a 以讀寫模式開啟 rb 以二進位制讀模式開啟 wb 以二進位制寫模式開啟 ab 以二進位制追加模式開啟 rb 以二進位制讀寫模式開啟 wb 以二進位制讀寫模式開啟 ab 以二進位制讀寫模式開啟 2 寫入檔案 with open file n...