對一個“失敗”項目的審視--分析
洋洋灑灑寫了好多字啊，我都沒想到我能寫這么多字來。看了上面的架構一定有人會想“不對吧，你在***篇中可是寫的是11種服務器啊，你數一數上面的架構圖上才幾個？老兄啊，你別是為了點擊率而忽悠我們吧”。對于存有這種看法的看客，我只能說“您看的可真細致啊！”上面的這個架構圖的確和我***篇中寫的11種服務器的架構不同，那是因為上面的圖是目前的架構圖，而11種服務器則是***版的產品架構。大家可以來看看***版和目前版本架構圖的區別。
后來將網關服務器和邏輯處理服務器合并；帳號服務器和認證服務器合并；統計服務器、公告服務器、在線服務器砍掉；計費服務器拆分成上報服務器和同步服務器。所以大家就看到了上一篇中的架構圖。
看到上面的架構圖以后不知道大家會有何感想，反正我聽到領導好幾次用Perfect來形容。當時自己也沾沾自喜了好久。
不過隨著項目的完成，以及性能測試和壓力測試的開展，卻發現了一個非常大的問題—性能低下。更有甚者當網吧的一個結賬業務發送到上報服務器以后，上報服務器竟然需要2-3秒鐘才能處理完畢。這幾乎是災難性的，要知道每個網吧我們的評估是每天上報2000條數據，這樣一來，一組服務器所能支持的網吧數量則少的可憐。同時處理速度過慢，會在業務上出現很大的漏洞。例如以連鎖網吧為例，用戶1在連鎖網吧中的A進行消費100塊錢以后，搶在連鎖網吧數據同步之前（由于處理速度太慢，而造成了延遲）又在連鎖網吧B中進行消費，這樣以來相當于用戶1進行了重復性消費。容易造成網吧賬目出現大量的負帳（用戶1消費完后，不再進行消費），這對目前薄利的網吧行業的打擊無疑是巨大的。
究其原因，我覺得主要是因為我們在處理所有業務的時候都是采取了先從SQL SERVER數據庫中查詢數據，然后再進行計算，并將SQL SERVER數據庫中的相關數據進行修改的方式。要知道對于一個復雜的業務，這種查詢是多次的。修改的內容也會涉及到好幾張不同的表。
就拿網吧用戶表為例，一張表中會存放將近3000萬條的數據，即便是通過分庫分表的方式，雖然可以緩解，但也只能指標不能治本。
第二個問題是由于網吧數據是放在網吧服務器上，網吧每次交班時的交班金額是按照網吧本地數據計算出來的。而網吧的每一條業務都上報給中心服務器，中心服務器會重新對數據計算一次；并且當網吧服務器重啟的時候，對于網吧服務器和中心服務器上不一致的數據進行強制更新。這個流程中出現了兩次計算，并且在不同的業務中以不同的計算結果作為依據（網吧中的交班和中心服務器中的強制數據更新）。這樣一來勢必會出現數據不正確的問題（事實上，在產品剛上線不久的時候，我們的DBA都是在進行數據的修正，即將中心服務器的數據修改成網吧的數據）。
以上兩個問題一直困擾著我很久，因為如果產品做成這樣的話，在市場上就幾乎無法進行推廣的。直到后來我離開這家公司以后，才想到了使用NOSQL來實現。
