來源：cnblogs.com/flashsun

• 一、項目描述
• 二、第一版：面向過程——2個月
• 三、第二版：面向?qū)ο蟆?1天
• 四、第三版：完全解耦（隊列+多線程）——3天
• 五、第四版：高度抽象（一鍵啟動）——4小時
• 六、關(guān)于繼續(xù)優(yōu)化的思考

一直不知道性能優(yōu)化都要做些什么，從哪方面思考，直到最近接手了一個公司的小項目，可謂麻雀雖小五臟俱全。讓我這個編程小白學(xué)到了很多性能優(yōu)化的知識，或者說一些思考方式。真的感受到任何一點效率的損失放大一定倍數(shù)時，將會是天文數(shù)字。

最初我的程序計算下來需要跑2個月才能跑完，經(jīng)過2周不斷地調(diào)整架構(gòu)和細節(jié)，將性能提升到了4小時完成。整體性能提升了360倍

很多心得體會，希望和大家分享，也希望多多批評指正，共同進步。

一、項目描述

我將公司的項目內(nèi)容抽象，大概是要做這樣一件事情：

1、數(shù)據(jù)庫A中有2000萬條用戶數(shù)據(jù)；

2、將數(shù)據(jù)庫A中的用戶讀出，為每條用戶生成guid，并保存到數(shù)據(jù)庫B中；

3、同時在數(shù)據(jù)庫A中生成關(guān)聯(lián)表；

項目要求為：

1、將用戶存入數(shù)據(jù)庫B的過程需要調(diào)用sdk的注冊接口，不允許直接操作jdbc進行插入；

2、數(shù)據(jù)要求可恢復(fù)：再次運行要跳過已成功的數(shù)據(jù)；出錯的數(shù)據(jù)要進行持久化以便下次可以選擇恢復(fù)該部分?jǐn)?shù)據(jù)；

3、數(shù)據(jù)要保證一致性：在不出錯的情況下，數(shù)據(jù)庫B的用戶必然一一對應(yīng)數(shù)據(jù)庫A的關(guān)聯(lián)表。如果出錯，那么正確的數(shù)據(jù)加上記錄下來的出錯數(shù)據(jù)后要保證一致性；

4、速度要盡可能塊：共2000萬條數(shù)據(jù)，在保證正確性的前提下，至多一天內(nèi)完成；

二、第一版：面向過程——2個月

特征：面向過程、單一線程、不可拓展、極度耦合、逐條插入、數(shù)據(jù)不可恢復(fù)

最初的一版簡直是匯聚了一個項目的所有缺點。整個流程就是從A庫讀出一條數(shù)據(jù)，立刻做處理，然后調(diào)用接口插入B庫

然后在拼一個關(guān)聯(lián)表的sql語句，插入A庫。沒有計數(shù)器，沒有錯誤信息處理。

這樣下來的代碼最終預(yù)測2000萬條數(shù)據(jù)要處理2個月。如果中間哪怕一條數(shù)據(jù)出錯，又要重新再來2個月。簡直可怕。

這個流程圖就等同于廢話，是完全基于面向過程的思想，整個代碼就是在一個大main方法里寫的，實際業(yè)務(wù)流程完全等同于代碼的流程。

思考起來簡單，但實現(xiàn)和維護起來極為困難，代碼結(jié)構(gòu)冗長混亂。而且?guī)缀跏遣豢蓴U展的。暫且不談代碼的設(shè)計美觀，它的效率如此低下主要有一下幾點：

1、每一條數(shù)據(jù)的速度受制于整個鏈條中最慢的一環(huán)。

試想假如有一條A庫插入關(guān)聯(lián)表的數(shù)據(jù)卡住了，等待將近1分鐘（夸張了點），那這一分鐘jvm完全就在傻等，它完全可以繼續(xù)進行之前的兩步。

正如你等待雞蛋煮熟的過程中可以同時去做其他的事一樣。

2、向B庫插入用戶需要調(diào)用sdk（HTTP請求）接口

那每一次調(diào)用都需要建立連接，等待響應(yīng)，再釋放鏈接。正如你要給朋友送一箱蘋果，你分成100次每次只送一個，時間全搭載路上了。

三、第二版：面向?qū)ο蟆?1天

特征：面向?qū)ο?、單一線程、可拓展、略微耦合、批量插入、數(shù)據(jù)可恢復(fù)

3.1、架構(gòu)設(shè)計

根據(jù)第一版設(shè)計的問題，第二版有了一些改進。當(dāng)然最明顯的就是從面向過程的思想轉(zhuǎn)變?yōu)槊嫦驅(qū)ο蟆?/p>

我將整個過程抽離出來，分配給不同的對象去處理。這樣，我所分配的對象時這樣的：

1、一個配置對象：BatchStrategy。

負責(zé)從配置文件中讀取本次任務(wù)的策略并傳遞給執(zhí)行者，配置包括基礎(chǔ)配置如總條數(shù)，每次批量查詢的數(shù)量，每次批量插入的數(shù)量。

還有一些數(shù)據(jù)源方面的，如來源表的表名、列名、等，這樣如果換成其他數(shù)據(jù)庫的類似導(dǎo)入，就能供通過配置進行拓展了。

2、三個執(zhí)行者：

整個執(zhí)行過程可以分成三個部分：讀數(shù)據(jù)--處理數(shù)據(jù)--寫數(shù)據(jù)，可以分別交給三個對象Reader，Processor，Writer進行。

這樣如果某一處邏輯變了，可以單獨進行改變而不影響其他環(huán)節(jié)。

3、一個失敗數(shù)據(jù)處理類：ErrorHandler。

這樣每當(dāng)有數(shù)據(jù)出現(xiàn)異常時，便把改數(shù)據(jù)扔給這個類，在這給類中進行寫入日志，或者其他的處理辦法。在一定程度上將失敗數(shù)據(jù)的處理解耦。

這種設(shè)計很大程度上解除了耦合，尤其是失敗數(shù)據(jù)的處理基本上完全解耦。

但由于整個執(zhí)行過程仍然是需要有一個main來分別調(diào)用三個對象處理任務(wù)，因此三者之間還是沒有完全解耦

main部分的邏輯依然是面向過程的思想，比較復(fù)雜。即使把main中執(zhí)行的邏輯抽出一個service，這個問題依然沒有解決。

3.2、效率問題

由于將第一版的逐條插入改為批量插入。其中sdk接口部分是批量傳入一組數(shù)據(jù)，減少了http請求的次數(shù)。生成關(guān)聯(lián)表的部分是用了jdbc batch操作，將之前逐條插入的excute改為excuteBatch，效率提升很明顯。

這兩部分批量帶來的效率提升，將原本需要兩個月時間的代碼，提升到了21天，但依然是天文數(shù)字。

可以看出，本次效率提升僅僅是在減少http請求次數(shù)，優(yōu)化sql的插入邏輯方面做出來努力，但依然沒有解決第一版的一個致命問題

即一次循環(huán)的速度依然受制于整個鏈條中最慢的一環(huán)，三者沒有解耦也可以從這一點看出，在其他兩者沒有將工作做完時，就只能傻等，這是效率損失最嚴(yán)重的地方了。

四、第三版：完全解耦（隊列+多線程）——3天

特征：面向?qū)ο?、多線程、可拓展、完全解耦、批量插入、數(shù)據(jù)可恢復(fù)。

4.1、架構(gòu)設(shè)計

該版并沒有代碼實現(xiàn)，但確是過度到下一版的重要思考過程，故記錄在次。這一版本較上一版的重大改進之處有兩點：隊列和多線程。

**隊列：**其中隊列的使用使上一版未完全解耦的執(zhí)行類之間，實現(xiàn)了完全解耦，將同步過程變?yōu)楫惒?，同時也是多線程能夠使用的前提。

Reader做的事就是讀取數(shù)據(jù)，并放入隊列，至于它的下一個環(huán)節(jié)Processor如何處理隊列的數(shù)據(jù)，它完全不用理會，

這時便可以繼續(xù)讀取數(shù)據(jù)。這便做到了完全解耦，處理隊列的數(shù)據(jù)也能夠使用多線程了。

**多線程：**Processor和Writer所做的事情，就是讀取自身隊列中的數(shù)據(jù)，然后處理。只不過Processor比Writer還承擔(dān)了一個往下一環(huán)隊列里放數(shù)據(jù)的過程。

此處的隊列用的是多線程安全隊列ConcurrentLinkedQueue。因此可以肆無忌憚地使用多線程來執(zhí)行這兩者的任務(wù)。

由于各個環(huán)節(jié)之間的完全解耦，某一環(huán)上的偶爾卡主并不再影響整個過程的進度，所以效率提升不知一兩點。

還有一點就是數(shù)據(jù)的可恢復(fù)性在這個設(shè)計中有了保障，成功過的用戶被保存起來以便再次運行不會沖突，失敗的關(guān)聯(lián)表數(shù)據(jù)也被記錄下來

在下次運行時Writer會先將這一部分加入到自己的隊列里，整個數(shù)據(jù)的正確性就有了一個不是特別完善的方案，效率也有了可觀的提升。

4.2、效率問題

雖然效率從21天提升到了3天，但我們還要思考一些問題。實際在執(zhí)行的過程中發(fā)現(xiàn)，Writer所完成的數(shù)據(jù)總是緊跟在Processor之后。

這就說明Processor的處理速度要慢于Writer，因為Processor插入數(shù)據(jù)庫之前還要走一段注冊用戶的業(yè)務(wù)邏輯。

這就有個問題，當(dāng)上一環(huán)的速度慢過下一環(huán)時，還有必要進行批量的操作么？

答案是不需要的。

試想一下，如果你在生產(chǎn)線上，你的上一環(huán)2秒鐘處理一個零件，而你的速度是1秒鐘一個。這時即使你的批量處理速度更快，從系統(tǒng)最優(yōu)的角度考慮，你也應(yīng)該來一個零件就馬上處理，而不是等積攢到100個再批量處理。

還有一個問題是，我們從未考慮過Reader的性能。實際上我用的是limit操作來批量讀取數(shù)據(jù)庫

而mysql的limit是先全表查再截取，當(dāng)起始位置很大時，就會越來越慢。0-1000萬還算輕松，但1000萬到2000萬簡直是“寸步難行”。所以最終效率的瓶頸反而落到了讀庫操作上。

五、第四版：高度抽象（一鍵啟動）——4小時

特征：面向接口、多線程、可拓展、完全解耦、批量或逐條插入、數(shù)據(jù)可恢復(fù)、優(yōu)化查詢的limit操作

5.1、架構(gòu)的思考

優(yōu)雅的代碼應(yīng)該是整潔而美妙，不應(yīng)是冗長而復(fù)雜的。這一版將會設(shè)計出簡潔度如第一版，而性能和拓展性超越所有版本的架構(gòu)。

通過總結(jié)前三版特征，我發(fā)現(xiàn)不論是Reader，Processor，Writer，都有共同的特征：啟動任務(wù)、處理任務(wù)、結(jié)束任務(wù)。

而Reader和Processor又有一個共同的可以向下一道工序傳遞數(shù)據(jù)，通知下一道工序數(shù)據(jù)傳遞結(jié)束的功能。

他們就像生產(chǎn)線上的一個個工序，相互關(guān)聯(lián)而又各自獨立地運行著。每一道工序都可以啟動，瘋狂地處理任務(wù)，直到上一道工序通知結(jié)束為止。

而第一個發(fā)起通知結(jié)束的便是Reader，之后便一個通知下一個，直到整個工序停止，這個過程就是美妙的。

因此我們可以將這三者都看做是Job，除了Reader外又都有與上一道工序交互的能力（其實Reader的上一道工序就是數(shù)據(jù)庫），因此便有了如下的接口設(shè)計。

有了這樣的接口設(shè)計，不論實現(xiàn)類具體怎么寫，主方法已經(jīng)可以寫出了，變得異常整潔有序。

只提煉主干部分，去掉了一些細枝末節(jié)，如日志輸出、時間記錄等。

接下來就是具體實現(xiàn)類的問題了，這里實現(xiàn)類主要實現(xiàn)的是三個功能：

1、接收上一環(huán)的數(shù)據(jù)：

屬于Interactive接口的receive方法的實現(xiàn)，基于之前的設(shè)計，即是對象中有一個ConcurrentLinkedQueue類型的屬性，用來接收上一環(huán)傳來的數(shù)據(jù)。

2、處理數(shù)據(jù)并傳遞給下一環(huán)：

在每一個（有下一環(huán)的）對象屬性中，放入下一環(huán)的對象。如Reader中要有Processor對象，Processor要有Writer，一旦有數(shù)據(jù)需要加入下一環(huán)的隊列，調(diào)用其receiive方法即可。

3、告訴下一環(huán)我結(jié)束了：

本任務(wù)結(jié)束時，調(diào)用下一環(huán)對象的closeInteractive方法。而每個對象判斷自身結(jié)束的方法視情況而定

比如Reader結(jié)束的條件是批量讀取的數(shù)據(jù)超過了一開始設(shè)置的total，說明數(shù)據(jù)讀取完畢，可以結(jié)束。

而Processor結(jié)束的條件是，它被上一環(huán)通知了結(jié)束，并且從自己的隊列中poll不出東西了，證明應(yīng)該結(jié)束，結(jié)束后再通知下一環(huán)節(jié)。

這樣整個工序就安全有序地退出了。不過由于是多線程，所以Processor不能貿(mào)然通知Writer結(jié)束信號，需要在Processor內(nèi)部弄一個計數(shù)器，只有計數(shù)器達到預(yù)期的數(shù)量的那個線程的Processor，才能發(fā)起結(jié)束通知。

5.2、效率問題：

正如上一版提出的，Processor的處理速度要慢于Writer，所以Writer并不需要用batch去處理數(shù)據(jù)的插入，該成逐條插入反而是提高性能的一種方式。

大數(shù)據(jù)量limit操作十分耗時，由于測試部分只是在前幾百萬條測試，所以還是大大低估了效率的損失。在后幾百萬條可以說每一次limit的讀取都寸步難行。

考慮到這個問題，我選去了唯一一個有索引并且稍稍易于排序的字段“用戶的手機號”，（不想吐槽它們設(shè)計表的時候居然沒有自增id。。。）

每次全表將手機號排序，再limit查詢。查詢之后將最后一條的手機號保存起來，成為當(dāng)前讀取的最后一條數(shù)據(jù)的一個標(biāo)識。下次再limit操作就可以從這個手機號之后開始查詢了。

這樣每次查詢不論從哪里開始，速度都是一樣的。雖然前面部分的數(shù)據(jù)速度與之前的方案相比慢了不少，但卻完美解決了大數(shù)據(jù)量limit操作的超長等待時間，預(yù)防了危險的發(fā)生。

至此，項目架構(gòu)再次簡潔起來，但同第一版相比，已經(jīng)不是同一級別的簡潔了。

六、關(guān)于繼續(xù)優(yōu)化的思考

1、Reader部分是單線程在處理，由于讀取是從數(shù)據(jù)庫中，并不是隊列中，因此設(shè)計成多線程有些麻煩，但并不是不可，這里是優(yōu)化點

2、日志部分占有很大一部分比例，2000萬條讀、處理、寫就要有至少6000萬次日志輸出。如果設(shè)計成異步處理，效率會提升不少。