一直不知道性能優化都要做些什麼,從哪方面思考,直到最近接手了一個公司的小項目,可謂麻雀雖小五臟俱全。讓我這個編程小白學到了很多性能優化的知識,或者說一些思考方式。真的感受到任何一點效率的損失放大一定倍數時,將會是天文數字。最初我的程序計算下來需要跑2個月才能跑完,經過2周不斷地調整架構和細節,將性能提升到了4小時完成。
很多心得體會,希望和大家分享,也希望多多批評指正,共同進步。
項目描述
我將公司的項目內容抽象,大概是要做這樣一件事情。
項目要求爲:
第一版,面向過程——2個月
特徵:面向過程、單一線程、不可拓展、極度耦合、逐條插入、數據不可恢復
最初的一版簡直是匯聚了一個項目的所有缺點。整個流程就是從A庫讀出一條數據,立刻做處理,然後調用接口插入B庫,然後在拼一個關聯表的sql語句,插入A庫。沒有計數器,沒有錯誤信息處理。這樣下來的代碼最終預測2000萬條數據要處理2個月。如果中間哪怕一條數據出錯,又要重新再來2個月。簡直可怕。
這個流程圖就等同於廢話,是完全基於面向過程的思想,整個代碼就是在一個大main方法裏寫的,實際業務流程完全等同於代碼的流程。思考起來簡單,但實現和維護起來極爲困難,代碼結構冗長混亂。而且幾乎是不可擴展的。暫且不談代碼的設計美觀,它的效率如此低下主要有一下幾點:
第二版,面向對象——21天
特徵:面向對象、單一線程、可拓展、略微耦合、批量插入、數據可恢復
架構設計
根據第一版設計的問題,第二版有了一些改進。當然最明顯的就是從面向過程的思想轉變爲面向對象。
我將整個過程抽離出來,分配給不同的對象去處理。這樣,我所分配的對象時這樣的:
這種設計很大程度上解除了耦合,尤其是失敗數據的處理基本上完全解耦。但由於整個執行過程仍然是需要有一個main來分別調用三個對象處理任務,因此三者之間還是沒有完全解耦,main部分的邏輯依然是面向過程的思想,比較複雜。即使把main中執行的邏輯抽出一個service,這個問題依然沒有解決。
效率問題
由於將第一版的逐條插入改爲批量插入。其中sdk接口部分是批量傳入一組數據,減少了http請求的次數。生成關聯表的部分是用了jdbc batch操作,將之前逐條插入的excute改爲excuteBatch,效率提升很明顯。這兩部分批量帶來的效率提升,將原本需要兩個月時間的代碼,提升到了21天,但依然是天文數字。
可以看出,本次效率提升僅僅是在減少http請求次數,優化sql的插入邏輯方面做出來努力,但依然沒有解決第一版的一個致命問題,就是一次循環的速度依然受制於整個鏈條中最慢的一環,三者沒有解耦也可以從這一點看出,在其他兩者沒有將工作做完時,就只能傻等,這是效率損失最嚴重的地方了。
第三版,完全解耦(隊列+多線程)——3天
特徵:面向對象、多線程、可拓展、完全解耦、批量插入、數據可恢復
架構設計
該版並沒有代碼實現,但確是過度到下一版的重要思考過程,故記錄在次。這一版本較上一版的重大改進之處有兩點:隊列和多線程。
隊列:其中隊列的使用使上一版未完全解耦的執行類之間,實現了完全解耦,將同步過程變爲異步,同時也是多線程能夠使用的前提。Reader做的事就是讀取數據,並放入隊列,至於它的下一個環節Processor如何處理隊列的數據,它完全不用理會,這時便可以繼續讀取數據。這便做到了完全解耦,處理隊列的數據也能夠使用多線程了。
多線程:Processor和Writer所做的事情,就是讀取自身隊列中的數據,然後處理。只不過Processor比Writer還承擔了一個往下一環隊列裏放數據的過程。此處的隊列用的是多線程安全隊列ConcurrentLinkedQueue。因此可以肆無忌憚地使用多線程來執行這兩者的任務。由於各個環節之間的完全解耦,某一環上的偶爾卡主並不再影響整個過程的進度,所以效率提升不知一兩點。
還有一點就是數據的可恢復性在這個設計中有了保障,成功過的用戶被保存起來以便再次運行不會衝突,失敗的關聯表數據也被記錄下來,在下次運行時Writer會先將這一部分加入到自己的隊列裏,整個數據的正確性就有了一個不是特別完善的方案,效率也有了可觀的提升。
效率問題
雖然效率從21天提升到了3天,但我們還要思考一些問題。實際在執行的過程中發現,Writer所完成的數據總是緊跟在Processor之後。這就說明Processor的處理速度要慢於Writer,因爲Processor插入數據庫之前還要走一段註冊用戶的業務邏輯。
這就有個問題,當上一環的速度慢過下一環時,還有必要進行批量的操作麼?答案是不需要的。試想一下,如果你在生產線上,你的上一環2秒鐘處理一個零件,而你的速度是1秒鐘一個。這時即使你的批量處理速度更快,從系統最優的角度考慮,你也應該來一個零件就馬上處理,而不是等積攢到100個再批量處理。
還有一個問題是,我們從未考慮過Reader的性能。實際上我用的是limit操作來批量讀取數據庫,而mysql的limit是先全表查再截取,當起始位置很大時,就會越來越慢。0-1000萬還算輕鬆,但1000萬到2000萬簡直是「寸步難行」。所以最終效率的瓶頸反而落到了讀庫操作上。
第四版,高度抽象(一鍵啓動)——4小時
特徵:面向接口、多線程、可拓展、完全解耦、批量或逐條插入、數據可恢復、優化查詢的limit操作
架構的思考
優雅的代碼應該是整潔而美妙,不應是冗長而複雜的。這一版將會設計出簡潔度如第一版,而性能和拓展性超越所有版本的架構。
通過總結前三版特徵,我發現不論是Reader,Processor,Writer,都有共同的特徵:啓動任務、處理任務、結束任務。而Reader和Processor又有一個共同的可以向下一道工序傳遞數據,通知下一道工序數據傳遞結束的功能。
他們就像生產線上的一個個工序,相互關聯而又各自獨立地運行着。每一道工序都可以啓動,瘋狂地處理任務,直到上一道工序通知結束爲止。而第一個發起通知結束的便是Reader,之後便一個通知下一個,直到整個工序停止,這個過程就是美妙的。
因此我們可以將這三者都看做是Job,除了Reader外又都有與上一道工序交互的能力(其實Reader的上一道工序就是數據庫),因此便有了如下的接口設計。
/** * 工作步驟接口. */ public interface Job { void init(); void start(); void stop(); void finish(); }
/** * 可交互的(傳入,通知結束). */ public interface Interactive<T> { /** * 開放與外界交互的通道 */ void openInteract(); /** * 接收外界傳來的數據 * @param t */ void receive(T t); /** * 關閉交互的通道 */ void closeInteract(); /** * 是否處於可交互的狀態 * @return true可交互的 false不可交互的活已關閉交互狀態 */ boolean isInteractive(); }
有了這樣的接口設計,不論實現類具體怎麼寫,主方法已經可以寫出了,變得異常整潔有序。
只提煉主幹部分,去掉了一些細枝末節,如日誌輸出、時間記錄等。
public static void main(String[] args) { Job reader = Reader.getInstance(); Job processor = Processor.getInstance(); Job writer = Writer.getInstance(); reader.init(); processor.init(); writer.init(); start(reader, processor, processor, processor, writer, writer); } private static void start(Job... jobs){ for (Job job:jobs) { Thread thread = new Thread(new Runnable() { @Override public void run() { job.start(); } }); thread.start(); } }
接下來就是具體實現類的問題了,這裏實現類主要實現的是三個功能:
效率問題:
正如上一版提出的,Processor的處理速度要慢於Writer,所以Writer並不需要用batch去處理數據的插入,該成逐條插入反而是提高性能的一種方式。
大數據量limit操作十分耗時,由於測試部分只是在前幾百萬條測試,所以還是大大低估了效率的損失。在後幾百萬條可以說每一次limit的讀取都寸步難行。考慮到這個問題,我選去了唯一一個有索引並且稍稍易於排序的字段「用戶的手機號」,(不想吐槽它們設計表的時候居然沒有自增id。。。),每次全表將手機號排序,再limit查詢。
查詢之後將最後一條的手機號保存起來,成爲當前讀取的最後一條數據的一個標識。下次再limit操作就可以從這個手機號之後開始查詢了。這樣每次查詢不論從哪裏開始,速度都是一樣的。雖然前面部分的數據速度與之前的方案相比慢了不少,但卻完美解決了大數據量limit操作的超長等待時間,預防了危險的發生。
至此,項目架構再次簡潔起來,但同第一版相比,已經不是同一級別的簡潔了。
關於繼續優化的思考