這些天來，很多網友給我來信，表達了他們的願望，就是讓我給出乙份設計方案。我本庸才，不敢在眾多
專家學者面前班門弄大斧，但對網友的熱情難卻，湊個熱鬧，也吼兩聲自己的醜陋看法，純屬瞎寫，別見笑。
但我還是那句話，在高效能系統不宜使用資料庫，只在資料管理中才會使用。
由於我對該系統的具體需求不清楚，只能假設一些需求，但基本思路都是一樣的。
首先，由後台系統生成乙個靜態頁面，上面標註了票的資訊，比如那些有下拉框的地方，決不能通過資料庫
查詢出來，而是直接生成靜態頁面。頁面上的所有的選項都是這樣的方案。保證大家在開啟網頁時，
不會運算元據庫。
例如：某個列表是這樣的
id info
0 羽毛球
1 兵乓球
2 足球
3 籃球
4 拳擊
然後在中間伺服器的地方開闢乙個大陣列。如下構成：
int info[5];
0 2000
1 1000
2 20000
3 10000
4 2000
0表示陣列下標，2000表示0代表的羽毛球的票數。當執行緒處理乙個請求時，會判斷報文的包頭的協議型別，只要該
協議型別表示「我要訂羽毛球票」1張，立刻將0對應的2000減1變成1999，如果另外的1999個同樣的報文
傳送過來，第2001個就會直接返回失敗，表示羽毛球票已經定完。
接著，上述的報文會再根據「比賽專案」分發到對應的伺服器上，可以用tcp協議，
例如ip指向192.168.128.111,port:9000的羽毛球資料儲存伺服器
在後台羽毛球資料儲存伺服器當中，為比賽專案，如羽毛球單建乙個我稱之為「陣列鍊錶」的資料結構。
如下結構
若干執行緒同時操作以下結構。p*為指向「羽毛球資訊」的指標。
0 p*
1 p*
2 p*
3 p*
4 p*
5 p*
6 p*
7 p*
8 p*
9 p*
隨機選擇乙個陣列下標，把記錄連線到後面的指標上，使每個陣列下表後面都接乙個鍊錶。其實完全
可以用乙個鍊錶，只是這樣做會減少執行緒同步帶來的效能瓶頸（但是每個小一些的鍊錶不能避免執行緒同步）。
如果設計時間充足，我覺得應該還有更好的演算法。
這樣，關於羽毛球的訂票報文就全部被奧運門票系統接收了。接下來，羽毛球資料儲存伺服器就不會接收
報文了，可以從容的向資料庫插入資料了，這一點可以人工控制，也可以批處理，總而言之就好辦了。
最後，資料庫歸檔以後，通過郵件向每個購買者確認即可。
建議類似羽毛球，兵乓球，籃球，110公尺欄熱門專案單建伺服器，其他像拳擊等專案可以一起放到乙個
伺服器上。
建議後台資料儲存的分布以專案來分，這樣便於評估壓力和效能需求。在上面沒有用到任何資料庫技術，用
單獨設計的演算法和資料儲存結構即可實現高效能。這也是我一直強調的不要在高效能系統中使用資料庫的原因。
在高效能系統設計當中，一般情況下真是很少使用資料庫的。這個設計是隨便想到的，如果給足夠時間，
應該能設計出更好的系統。
DBMS一種設計方案（原）
一 整體架構 乙個資料 採用資料集 索引集分開的儲存方式，分別為資料檔案和索引檔案，有可能還需要乙個關鍵字檔案。資料 必須指定乙個主關鍵字，主關鍵字在資料表內不允許重複。資料 還可以有若干索引，索引可以重複。只有第乙個索引 主索引 能影響資料檔案內的資料分布，所有相同主索引的資料會存放於同乙個資料檔...
離線應用的一種設計方案
程式快取比較容易設定，只要寫乙個.manifest檔案，再把它寫到html元素的屬性就可以了。我遇到的一些問題 因此對離線應用而言，我認為程式快取的作用就是儲存靜態檔案。據說瀏覽器限制本地儲存為5m，所以就不考慮了。主要是利用瀏覽器支援的indexeddb來完成資料操作。方式1的測試成本要比方式2高...
iOS中一種網路層與業務層的設計方案
提起ios架構,免不了要談到現在很火的mvvm和mvcs,但萬變不離其宗,這兩個概念其實也都基於mvc,它們的主要思想簡而言之就是mvc中的c controller裡面的 太多,在專案不斷新增功能逐漸變大時,不利於開發也不利於維護.xbbusinessmanager 戳這裡 僅僅舉例個人入行兩年來所...