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