本文可以應對海量併發業務請求的問題思想的解答
**：其實鐵路訂票系統面臨的技術難點無非就是春運期間可能發生的海量併發業務請求。這個加上乙個排隊系統就可以輕易解決的。
本來我在 weibo 上閒扯兩句，這麼簡單的方案，本以為大家一看就明白的。沒想到還是許多人有疑問。好吧，寫篇 blog 來解釋一下。
簡單說，我們設定幾個閘道器伺服器，用動態 dns 的方式，把併發的訂票請求分攤開。模擬現實的話，就是把人分流到不同的購票大廳去。每個購票大廳都可以買到所有車次的票。ok ，這一步的負載均衡怎麼做我就不詳細說了。
每個閘道器其實最重要的作用就是讓訂票的使用者排隊。其實整個系統也只用做排隊，關於實際訂票怎麼操作，就算每個閘道器後坐一排售票員，在螢幕上看到有人來買票，輸入到內部訂票系統中出票，然後再把票號敲回去，這個系統都能無壓力的正常工作。否則，以前春運是怎麼把票賣出去的？
我們來說說排隊系統是怎麼做的：
其實就類似我們去熱門館子吃飯拿號。只不過要防止別人偽造號插隊而已。
如果你來乙個人（一次 http 請求），我就隨機產生乙個我做過一些簽名處理的號碼返回給你。暫時稱為 ticket id 。這個 ticked id 是很難偽造的。
系統在記憶體裡開乙個大陣列（32g 記憶體夠排上億人了吧），就是一迴圈佇列。把這個 ticket id 放在佇列尾。
使用者現在拿著 ticket id 向閘道器發起請求。閘道器利用一次 hash 查詢，在記憶體中的陣列佇列里查到它的位置，立刻返回給使用者。使用者的前端就可以看到，他在這個閘道器（售票大廳）前面還有多少人等著。
這裡的關鍵是，整個佇列都在本機的記憶體中，查詢返回佇列中的位置，可以實現的比乙個處理靜態檔案的 web server 還要高效。靜態檔案至少還要去呼叫檔案 io 呢。靜態檔案 web server 可以處理多少併發量，不用我介紹了。
同時，前端會控制使用者拿著 ticket id 查詢佇列位置的頻率。高負載時可以 1s 一次，甚至更長時間。為了防止使用者自己寫指令碼刷這個請求（雖然沒有太大意義，因為刷的多也不會排到前面去），如果見到同乙個 ticket id 過於頻繁的查詢。比如 10s 內查詢了 20 次以上。就直接把這個 ticket id 作廢。持有這個 ticket 的人就需要重新排隊了。
對於最後排到的人，系統會生成乙個唯一的不可偽造的 session id ，使用者下面就可以通過這個 session id 去做實際的購票流程了。可以連去真正的購票伺服器，也可以通過閘道器中轉。非法的 session id 會立刻斷掉，使用者一旦知道偽造 session id 幾乎不可能，只有通過 ticket id 排隊拿到，除非是惡意攻擊系統，不然不會有人亂拿 session id 去試。
我們再給每個 session id 設定乙個最長有效時間，比如半小時。如果超過半小時還沒有完整購票流程，那麼就重新去排隊。
至於同時開放多少個 session id ，也就是相當於開放多少個購票視窗，就取決於購票系統能承受的負載了。不過簡單計算一下，就知道有排隊系統保證了良好的次序，再以計算機的吞吐能力，解決不過幾億人的購票請求，即使這些人都同來排隊，也就是一組機器幾小時的處理量而已。
這票 blog 也就是隨便寫寫，可能不太嚴謹，但意思達到了。中間有很多資料需要估算，也不是太難的事情。
為什麼現在的購票系統這麼濫？關鍵在於大量的網路頻寬，計算力浪費在了「維持次序」上。系統不穩定時，大量的只做了一半的無效的購票流程浪費掉了這些。要響應高併發的 http 請求，關鍵就在於迅速反應，不要什麼都想著從資料庫繞一圈。排隊的隊伍維持就完全不需要使用資料庫。如果所有 http 請求都立刻返回，在短時間內可以處理的 http 請求量也會非常大。而如果你一下處理不了這個請求，又把 tcp 連線保持在那裡，就莫怪系統支援不住了。
另外，使用者看到了不斷在減少的佇列前面的人數，他們也會安心等待。只要**頁面重新整理流暢（只處理佇列資訊很容易保證），使用者體驗會很好。
最後補充幾句廢話：因為鐵路購票系統很多年前就實現了內部網路化，有成熟系統支撐，運作多年。這次做網際網路版本，一定不能放棄原有系統新來一套。不然實體購票點也在網頁上刷不出票就崩潰了。
所以要做的僅僅是怎麼做乙個系統和原有系統對接。這樣風險最小。兩套系統可以分別優化處理能力。基於這個設計起點，所以我才不看好所有企圖取代原有系統的方案。
模組簡單設計 設計簡單的賬號系統
下面考慮 乙個簡化版使用者賬戶系統，從註冊，登入，使用，登出四個方面做個簡單的設計 account表包含下面三個字段 id 乙個表唯一的id，標識使用者 user 使用者名稱 passwd 使用者密碼 為了防止資料庫被侵入洩露密碼，需要如md5 passwd 或者crypt單向加密 1，使用者註冊 ...
系統許可權的設計之簡單設計
工作時間也不長，但是總想寫一些自己的收穫。公司利用的技術也比較單純，asp.net,js也不怎麼需要用，唯一寫的多的就是sql語句。好了，廢話不多說了，開始談談我在做專案中一些對系統許可權的收穫，不過很多都是專案中看到的，我就想自己重新做一遍。也許會有 很多的問題和考慮不全的地方，但是我還是要寫出來...
反饋系統簡單設計
反饋系統 原始碼和部署說明參見 talk e r模型 user角色 普通使用者 專業人員 管理員 專業人員 根據type 區域或問題型別 檢視對應分配的問題列表 解決問題，更改問題狀態 管理員 維護系統，使用者，模組，專業人員 使用者 提交問題使用者端 1.提交反饋輸入框 問題標題 text 問題詳...