高速數(shù)據(jù)處理 400萬數(shù)據(jù)處理最低

1. 從接收這個(gè)項(xiàng)目開始，了解數(shù)據(jù)報(bào)之間的內(nèi)容解析，到跟同事后面解決一部分的問題，到現(xiàn)在快一個(gè)月的時(shí)間了，這段時(shí)間一直沒有寫東西，感覺自己已經(jīng)飄了起來，但是這一段時(shí)間 是給了自己很大的巴掌，需要學(xué)習(xí)的東西太多了。下面就為這一段時(shí)間做個(gè)總結(jié)。讓自己回顧下。
2. 從接收項(xiàng)目來看 首先自己分配是數(shù)據(jù)解析，數(shù)據(jù)報(bào)解析原先沒有接觸過，而且在大數(shù)據(jù)處理上 也是了解的不多，導(dǎo)致了在解析的時(shí)候還是按照原先的思路進(jìn)行開發(fā),接下來是幾個(gè)的問題匯總。

• 創(chuàng)建對象過多導(dǎo)致gc緩慢
  1. 這個(gè)數(shù)量級剛開始是200萬的數(shù)據(jù)量，沒有達(dá)到400.每秒的速度。我原先的思路是根據(jù)文檔我寫了多個(gè)對象進(jìn)行編程， 消息頭，中間消息體，消息體基本為三部分，但是消息體里面還有 其他消息內(nèi)容需要進(jìn)行剝離 。但是也需要提前解決掉。我們 的數(shù)據(jù)都是byte 數(shù)據(jù) 解析是按照字節(jié) 進(jìn)行解析。
  2. 我第一個(gè)思路是 把消息頭 消息體都轉(zhuǎn)為對象，然后轉(zhuǎn)換的時(shí)候 方便數(shù)據(jù)解析，然后再把byte數(shù)據(jù)進(jìn)行轉(zhuǎn)成json .方便數(shù)據(jù)利用。 在這里開始我就思路錯(cuò)誤了，因?yàn)槲覀償?shù)據(jù)量每秒需要處理的幾百萬。java虛擬的gc 需要消耗很多時(shí)間，這樣的話我們需要的性能就會(huì)下降。再次基礎(chǔ)上 為了性能 ，那么我們就利用基本對象來解決問題，而不是用包裝對象了。byte 數(shù)據(jù)直接利用。我現(xiàn)在的理解是基礎(chǔ)數(shù)據(jù)類型再方法中是存放再棧中不是存放在堆中 減少了 gc的壓力 。當(dāng)然我們選擇這個(gè)方法是因?yàn)槲覀兪嵌M(jìn)制進(jìn)行數(shù)據(jù)轉(zhuǎn)換 。如果是其他方式的話那么我們這就不能用這種方式了。然后測試我們單線程解析能力一個(gè)1430的數(shù)據(jù)包 應(yīng)該解析能力在10萬左右。機(jī)器型號記不清了。但是這個(gè)是跟機(jī)器性能有關(guān)的。
  3. 我們在系統(tǒng)中使用了disruptor 這個(gè)隊(duì)列，雖然這個(gè)隊(duì)列是號稱最好的高性能隊(duì)列，但是在系統(tǒng)中，首先我們在測試中發(fā)現(xiàn)該單個(gè)性能測試能達(dá)到900萬/s的速度 ，但是加上業(yè)務(wù)后。還有其中消費(fèi)者能力跟不上的節(jié)奏，導(dǎo)致性能急劇下降。我們一直在加線程 后來發(fā)現(xiàn)，單生產(chǎn)者 加三個(gè)消費(fèi)者的能力已經(jīng)達(dá)到頂峰，再加消費(fèi)者或者生產(chǎn)者 ，性能就提不上去了。那么我們一直以為是我們在disruptor 的使用方式不對。最后在換成其他java隊(duì)列嘗試后發(fā)現(xiàn) 是放隊(duì)列的時(shí)候造成的性能損耗，雖然我們想的時(shí)候 這邊隊(duì)列放，那邊取這樣應(yīng)該是不會(huì)有多大的性能損耗的，但是在我們每秒40萬的數(shù)據(jù)包的發(fā)送下 ，系統(tǒng)只能撐住20萬左右每秒的速度。并且我們還把linux系統(tǒng)中的緩存也增加。但是就是達(dá)不到我們需要的效果。最后請教了別的組同事，才明白隊(duì)列在使用的時(shí)候入隊(duì)和出隊(duì)。沒有我們想的性能損失很小的情況。性能損失是很強(qiáng)大的。我們一直都知緩存 。那么在程序中我們應(yīng)該怎么用緩存。也知道批量提交，也知道線程池的東西，但是在我們自己寫程序的時(shí)候還是沒有應(yīng)用到。我們最終在我們接收的程序中加了一個(gè)對象池的概念，就是創(chuàng)建了一個(gè)通用的容器，創(chuàng)建好對象byte[] 我們只加入就好 ，但是我們這個(gè)思路跟disruptor 里面的對象復(fù)用類似，但是沒有他那個(gè)高級。每次加入容器中，然后達(dá)到一定的數(shù)量后，我們把這一批數(shù)據(jù)換成另外一個(gè)容器數(shù)據(jù)放到disruptor中。這樣的話每次提交的數(shù)據(jù)就多了。而且減少的提交次數(shù)減少了爭奪標(biāo)志位的方式。最終我們現(xiàn)在整個(gè)流程已經(jīng)能走通。當(dāng)然最大性能還沒有測試。這個(gè)思路挺好的?？偨Y(jié)就是 復(fù)用對象，增加對象緩沖池的方式。但是我自己的一個(gè)疑問 是。我們自己怎么實(shí)現(xiàn) 類似disruptorf方式的對象復(fù)用。如果是創(chuàng)建java自帶的隊(duì)列的話 ，是不是也造成類似的隊(duì)列性能的問題。但是線程池里面還是用的自帶的隊(duì)列來實(shí)現(xiàn)的。
  4. 需要根據(jù)書上的內(nèi)容看下相關(guān)容器的知識總結(jié)寫 。還有隊(duì)列的信息。這樣更好的方便自己在選擇容器方面的使用。