掃描下方海報二維碼,試聽課程:
mysql
(課程詳細大綱,請參見文末)面試
=========================================sql
來源:https://www.cnblogs.com/flashsun數據庫
===================================================編程
一直不知道性能優化都要作些什麼,從哪方面思考,直到最近接手了一個公司的小項目,可謂麻雀雖小五臟俱全。讓我這個編程小白學到了不少性能優化的知識,或者說一些思考方式。真的感覺到任何一點效率的損失放大必定倍數時,將會是天文數字。安全
最初個人程序計算下來須要跑2個月才能跑完,通過2周不斷地調整架構和細節,將性能提高到了4小時完成。總體性能提高了360倍性能優化
不少心得體會,但願和你們分享,也但願多多批評指正,共同進步。多線程
我將公司的項目內容抽象,大概是要作這樣一件事情:架構
一、數據庫A中有2000萬條用戶數據;異步
二、將數據庫A中的用戶讀出,爲每條用戶生成guid,並保存到數據庫B中;
三、同時在數據庫A中生成關聯表;
項目要求爲:
一、將用戶存入數據庫B的過程須要調用sdk的註冊接口,不容許直接操做jdbc進行插入;
二、數據要求可恢復:再次運行要跳過已成功的數據;出錯的數據要進行持久化以便下次能夠選擇恢復該部分數據;
三、數據要保證一致性:在不出錯的狀況下,數據庫B的用戶必然一一對應數據庫A的關聯表。若是出錯,那麼正確的數據加上記錄下來的出錯數據後要保證一致性;
四、速度要儘量塊:共2000萬條數據,在保證正確性的前提下,至多一天內完成;
特徵:面向過程、單一線程、不可拓展、極度耦合、逐條插入、數據不可恢復
最初的一版簡直是匯聚了一個項目的全部缺點。整個流程就是從A庫讀出一條數據,馬上作處理,而後調用接口插入B庫
而後在拼一個關聯表的sql語句,插入A庫。沒有計數器,沒有錯誤信息處理。
這樣下來的代碼最終預測2000萬條數據要處理2個月。若是中間哪怕一條數據出錯,又要從新再來2個月。簡直可怕。
這個流程圖就等同於廢話,是徹底基於面向過程的思想,整個代碼就是在一個大main方法裏寫的,實際業務流程徹底等同於代碼的流程。
思考起來簡單,但實現和維護起來極爲困難,代碼結構冗長混亂。並且幾乎是不可擴展的。暫且不談代碼的設計美觀,它的效率如此低下主要有一下幾點:
一、每一條數據的速度受制於整個鏈條中最慢的一環。
試想假若有一條A庫插入關聯表的數據卡住了,等待將近1分鐘(誇張了點),那這一分鐘jvm徹底就在傻等,它徹底能夠繼續進行以前的兩步。
正如你等待雞蛋煮熟的過程當中能夠同時去作其餘的事同樣。
二、向B庫插入用戶須要調用sdk(HTTP請求)接口
那每一次調用都須要創建鏈接,等待響應,再釋放連接。正如你要給朋友送一箱蘋果,你分紅100次每次只送一個,時間全搭載路上了。
特徵:面向對象、單一線程、可拓展、略微耦合、批量插入、數據可恢復
3.一、架構設計
根據初版設計的問題,第二版有了一些改進。固然最明顯的就是從面向過程的思想轉變爲面向對象。
我將整個過程抽離出來,分配給不一樣的對象去處理。這樣,我所分配的對象時這樣的:
一、一個配置對象:BatchStrategy。
負責從配置文件中讀取本次任務的策略並傳遞給執行者,配置包括基礎配置如總條數,每次批量查詢的數量,每次批量插入的數量。
還有一些數據源方面的,如來源表的表名、列名、等,這樣若是換成其餘數據庫的相似導入,就能供經過配置進行拓展了。
二、三個執行者:
整個執行過程能夠分紅三個部分:讀數據--處理數據--寫數據,能夠分別交給三個對象Reader,Processor,Writer進行。
這樣若是某一處邏輯變了,能夠單獨進行改變而不影響其餘環節。
三、一個失敗數據處理類:ErrorHandler。
這樣每當有數據出現異常時,便把改數據扔給這個類,在這給類中進行寫入日誌,或者其餘的處理辦法。在必定程度上將失敗數據的處理解耦。
這種設計很大程度上解除了耦合,尤爲是失敗數據的處理基本上徹底解耦。
但因爲整個執行過程仍然是須要有一個main來分別調用三個對象處理任務,所以三者之間仍是沒有徹底解耦
main部分的邏輯依然是面向過程的思想,比較複雜。即便把main中執行的邏輯抽出一個service,這個問題依然沒有解決。
3.二、效率問題
因爲將初版的逐條插入改成批量插入。其中sdk接口部分是批量傳入一組數據,減小了http請求的次數。生成關聯表的部分是用了jdbc batch操做,將以前逐條插入的excute改成excuteBatch,效率提高很明顯。
這兩部分批量帶來的效率提高,將本來須要兩個月時間的代碼,提高到了21天,但依然是天文數字。
能夠看出,本次效率提高僅僅是在減小http請求次數,優化sql的插入邏輯方面作出來努力,但依然沒有解決初版的一個致命問題
即一次循環的速度依然受制於整個鏈條中最慢的一環,三者沒有解耦也能夠從這一點看出,在其餘二者沒有將工做作完時,就只能傻等,這是效率損失最嚴重的地方了。
特徵:面向對象、多線程、可拓展、徹底解耦、批量插入、數據可恢復。
4.一、架構設計
該版並無代碼實現,但確是過分到下一版的重要思考過程,故記錄在次。這一版本較上一版的重大改進之處有兩點:隊列和多線程。
隊列:其中隊列的使用使上一版未徹底解耦的執行類之間,實現了徹底解耦,將同步過程變爲異步,同時也是多線程可以使用的前提。
Reader作的事就是讀取數據,並放入隊列,至於它的下一個環節Processor如何處理隊列的數據,它徹底不用理會,
這時即可以繼續讀取數據。這便作到了徹底解耦,處理隊列的數據也可以使用多線程了。
多線程:Processor和Writer所作的事情,就是讀取自身隊列中的數據,而後處理。只不過Processor比Writer還承擔了一個往下一環隊列裏放數據的過程。
此處的隊列用的是多線程安全隊列ConcurrentLinkedQueue。所以能夠肆無忌憚地使用多線程來執行這二者的任務。
因爲各個環節之間的徹底解耦,某一環上的偶爾卡主並再也不影響整個過程的進度,因此效率提高不知一兩點。
還有一點就是數據的可恢復性在這個設計中有了保障,成功過的用戶被保存起來以便再次運行不會衝突,失敗的關聯表數據也被記錄下來
在下次運行時Writer會先將這一部分加入到本身的隊列裏,整個數據的正確性就有了一個不是特別完善的方案,效率也有了可觀的提高。
4.二、效率問題
雖然效率從21天提高到了3天,但咱們還要思考一些問題。實際在執行的過程當中發現,Writer所完成的數據老是緊跟在Processor以後。
這就說明Processor的處理速度要慢於Writer,由於Processor插入數據庫以前還要走一段註冊用戶的業務邏輯。
這就有個問題,當上一環的速度慢過下一環時,還有必要進行批量的操做麼?
答案是不須要的。
試想一下,若是你在生產線上,你的上一環2秒鐘處理一個零件,而你的速度是1秒鐘一個。這時即便你的批量處理速度更快,從系統最優的角度考慮,你也應該來一個零件就立刻處理,而不是等積攢到100個再批量處理。
還有一個問題是,咱們從未考慮過Reader的性能。實際上我用的是limit操做來批量讀取數據庫
而mysql的limit是先全表查再截取,當起始位置很大時,就會愈來愈慢。0-1000萬還算輕鬆,但1000萬到2000萬簡直是「步履維艱」。因此最終效率的瓶頸反而落到了讀庫操做上。
特徵:面向接口、多線程、可拓展、徹底解耦、批量或逐條插入、數據可恢復、優化查詢的limit操做
5.一、架構的思考
優雅的代碼應該是整潔而美妙,不該是冗長而複雜的。這一版將會設計出簡潔度如初版,而性能和拓展性超越全部版本的架構。
經過總結前三版特徵,我發現不管是Reader,Processor,Writer,都有共同的特徵:啓動任務、處理任務、結束任務。
而Reader和Processor又有一個共同的能夠向下一道工序傳遞數據,通知下一道工序數據傳遞結束的功能。
他們就像生產線上的一個個工序,相互關聯而又各自獨立地運行着。每一道工序均可以啓動,瘋狂地處理任務,直到上一道工序通知結束爲止。
而第一個發起通知結束的即是Reader,以後便一個通知下一個,直到整個工序中止,這個過程就是美妙的。
所以咱們能夠將這三者都看作是Job,除了Reader外又都有與上一道工序交互的能力(其實Reader的上一道工序就是數據庫),所以便有了以下的接口設計。
有了這樣的接口設計,不論實現類具體怎麼寫,主方法已經能夠寫出了,變得異常整潔有序。
只提煉主幹部分,去掉了一些細枝末節,如日誌輸出、時間記錄等。
接下來就是具體實現類的問題了,這裏實現類主要實現的是三個功能:
一、接收上一環的數據:
屬於Interactive接口的receive方法的實現,基於以前的設計,便是對象中有一個ConcurrentLinkedQueue類型的屬性,用來接收上一環傳來的數據。
二、處理數據並傳遞給下一環:
在每個(有下一環的)對象屬性中,放入下一環的對象。如Reader中要有Processor對象,Processor要有Writer,一旦有數據須要加入下一環的隊列,調用其receiive方法便可。
三、告訴下一環我結束了:
本任務結束時,調用下一環對象的closeInteractive方法。而每一個對象判斷自身結束的方法視狀況而定
好比Reader結束的條件是批量讀取的數據超過了一開始設置的total,說明數據讀取完畢,能夠結束。
而Processor結束的條件是,它被上一環通知告終束,而且從本身的隊列中poll不出東西了,證實應該結束,結束後再通知下一環節。
這樣整個工序就安全有序地退出了。不過因爲是多線程,因此Processor不能貿然通知Writer結束信號,須要在Processor內部弄一個計數器,只有計數器達到預期的數量的那個線程的Processor,才能發起結束通知。
5.二、效率問題:
正如上一版提出的,Processor的處理速度要慢於Writer,因此Writer並不須要用batch去處理數據的插入,該成逐條插入反而是提升性能的一種方式。
大數據量limit操做十分耗時,因爲測試部分只是在前幾百萬條測試,因此仍是大大低估了效率的損失。在後幾百萬條能夠說每一次limit的讀取都步履維艱。
考慮到這個問題,我選去了惟一一個有索引而且稍稍易於排序的字段「用戶的手機號」,(不想吐槽它們設計表的時候竟然沒有自增id。。。)
每次全表將手機號排序,再limit查詢。查詢以後將最後一條的手機號保存起來,成爲當前讀取的最後一條數據的一個標識。下次再limit操做就能夠從這個手機號以後開始查詢了。
這樣每次查詢不論從哪裏開始,速度都是同樣的。雖然前面部分的數據速度與以前的方案相比慢了很多,但卻完美解決了大數據量limit操做的超長等待時間,預防了危險的發生。
至此,項目架構再次簡潔起來,但同初版相比,已經不是同一級別的簡潔了。
一、Reader部分是單線程在處理,因爲讀取是從數據庫中,並非隊列中,所以設計成多線程有些麻煩,但並非不可,這裏是優化點
二、日誌部分佔有很大一部分比例,2000萬條讀、處理、寫就要有至少6000萬第二天志輸出。若是設計成異步處理,效率會提高很多。
END
《21天互聯網Java進階面試訓練營(分佈式篇)》詳細目錄,掃描圖片末尾的二維碼,試聽課程