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