本篇內(nèi)容主要講解“KAFKA是如何處理粘包拆包的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“KAFKA是如何處理粘包拆包的”吧!

創(chuàng)新互聯(lián)公司長期為上1000+客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為忠縣企業(yè)提供專業(yè)的成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)，忠縣網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

一、為什么會出現(xiàn)粘包拆包現(xiàn)象？

我們知道，TCP數(shù)據(jù)包都是按照協(xié)議進(jìn)行拆包、編號然后分批發(fā)送的；
那么對應(yīng)我們應(yīng)用層有意義的數(shù)據(jù)包，傳輸層的協(xié)議并不了解其含義，更不會去根據(jù)你的業(yè)務(wù)內(nèi)容去分包和發(fā)送，只會按照自己的協(xié)議棧去進(jìn)行數(shù)據(jù)發(fā)送。
因此，就出現(xiàn)了網(wǎng)絡(luò)數(shù)據(jù)的粘包，拆包問題。
究其本質(zhì)，其實就是傳輸層并不了解上層應(yīng)用的數(shù)據(jù)含義，只會按照協(xié)議棧進(jìn)行數(shù)據(jù)發(fā)送。

二、通常有哪些解決粘包拆包問題的方法？

在了解出現(xiàn)這個問題的本質(zhì)后，那么要想解決這個問題就很簡單了。
不就是在進(jìn)行數(shù)據(jù)接收的時候，我們應(yīng)用層收到數(shù)據(jù)后根據(jù)標(biāo)識判斷一下，數(shù)據(jù)是否完整，如果完整了我們再進(jìn)行數(shù)據(jù)包解析，最后交給業(yè)務(wù)代碼不就好了？
通常解決粘包拆包的問題有三種方案：

1. 定長，例如我保證我每一條數(shù)據(jù)都是200b，那么我每接收到200b就認(rèn)為是一條完整的數(shù)據(jù)，接著就可以進(jìn)行解析，并向業(yè)務(wù)代碼交付。

2. 分隔符，一樣的意思，我每條數(shù)據(jù)末尾都用一個分隔符例如換行符，制表符這種來標(biāo)識這條數(shù)據(jù)寫完了，那么我們收到數(shù)據(jù)判找一下這個分割符在哪兒，最后進(jìn)行切割就可以得到完整的數(shù)據(jù)包了。

3. 自定義協(xié)議，這個也很簡單，就是定義一個你的完整數(shù)據(jù)包的內(nèi)容格式是什么樣子的，例如 len + data，其中l(wèi)en是代表data的字節(jié)長度。這樣每次根據(jù)前面4個字節(jié)的len，就能得到后面還需要多少數(shù)據(jù)才是一條完整的數(shù)據(jù)，少了就等，多了就截取。

最后，可能很多不熟悉網(wǎng)絡(luò)編程的同學(xué)會納悶，那萬一TCP的數(shù)據(jù)包丟失了，亂序了，上面這種方法不就出問題了嘛？
其實不是的，TCP一個可靠的消息傳輸協(xié)議，其協(xié)議的根本思想就是提供可靠的數(shù)據(jù)傳輸服務(wù)。
翻譯一下就是，你可以相信TCP傳輸?shù)臄?shù)據(jù)是可靠的，在交付給應(yīng)用層數(shù)據(jù)的時候，是不會出現(xiàn)上述這種情況的。
出現(xiàn)這種情況只會在傳輸層出現(xiàn)，而TCP協(xié)議也為對應(yīng)的情況設(shè)計了分批、編號、去重、校驗和、超時重傳等一系列的操作，來保證數(shù)據(jù)可靠。

三、kakfa是如何解決粘包拆包問題的呢？

最后，讓我們來看下kafka是如何解決粘包拆包問題的呢？是以上面提到的哪種方式來解決的呢？
首先看粘包，也就是接收到了多余的數(shù)據(jù)，該如何拆分?jǐn)?shù)據(jù)包，讀取到正確完整的數(shù)據(jù)包？
如下面代碼所示，分為三個階段：

1. 先讀取前4字節(jié)，轉(zhuǎn)換為一個int，即長度。

2. 根據(jù)長度申請內(nèi)存buffer。

3. 最后讀取指定大小的數(shù)據(jù)到申請好的buffer

由此，就完整了一整條數(shù)據(jù)的正確讀取。整個過程其實就是上面提到的 len+data 這么一個簡單的自定義協(xié)議。

public NetworkReceive read() throws IOException {
    NetworkReceive result = null;    // 新建一個receive    if (receive == null) {receive = new NetworkReceive(maxReceiveSize, id, memoryPool);    }    // 真正的數(shù)據(jù)read    receive(receive);    // 數(shù)據(jù)讀取完成的后置操作    if (receive.complete()) {        // 倒帶，等待讀receive.payload().rewind();        // 直接引用賦值        result = receive;        // 最后清空當(dāng)前引用，然后等待下次進(jìn)入read的時候，執(zhí)行new 操作        receive = null;    } else if (receive.requiredMemoryAmountKnown() && !receive.memoryAllocated() && isInMutableState()) {//pool must be out of memory, mute ourselves.        mute();    }return result;}

public long readFrom(ScatteringByteChannel channel) throws IOException {int read = 0;
    // 存在數(shù)據(jù)if (size.hasRemaining()) {        // len + dataint bytesRead = channel.read(size);        if (bytesRead < 0)throw new EOFException();        read += bytesRead;
        // 如果讀滿了長度，則直接倒帶得到具體的len值
        // 這里的size是一個byteBuffer類型的，也就是接收到的數(shù)據(jù)        if (!size.hasRemaining()) {size.rewind();            int receiveSize = size.getInt();            if (receiveSize < 0)throw new InvalidReceiveException("Invalid receive (size = " + receiveSize + ")");            if (maxSize != UNLIMITED && receiveSize > maxSize)throw new InvalidReceiveException("Invalid receive (size = " + receiveSize + " larger than " + maxSize + ")");            requestedBufferSize = receiveSize; //may be 0 for some payloads (SASL)            if (receiveSize == 0) {buffer = EMPTY_BUFFER;            }
        }
    }    // 如果長度已經(jīng)就緒了，那么就需要接下來的data需要多少空間，在這里進(jìn)行申請if (buffer == null && requestedBufferSize != -1) { //we know the size we want but havent been able to allocate it yet        buffer = memoryPool.tryAllocate(requestedBufferSize);        if (buffer == null)log.trace("Broker low on memory - could not allocate buffer of size {} for source {}", requestedBufferSize, source);    }
    // 申請完畢之后，就調(diào)用read函數(shù)，直接read出來即可。if (buffer != null) {        int bytesRead = channel.read(buffer);        if (bytesRead < 0)throw new EOFException();        read += bytesRead;    }    // 返回讀取的總字節(jié)數(shù)return read;}

再先看拆包，也就是接收到數(shù)據(jù)不夠組成一條完整的數(shù)據(jù)，該如何等待完整的數(shù)據(jù)包？
下面代碼最核心的就是receive.complete()函數(shù)的判斷邏輯，這個判斷的三個條件分別意味著：

• !size.hasRemaining()：接收到的buffer數(shù)據(jù)已經(jīng)讀取完成。

• buffer != null：buffer已經(jīng)創(chuàng)建。

• !buffer.hasRemaining()：buffer已經(jīng)讀取完成。

翻譯一下，其實就是只要一條數(shù)據(jù)沒讀完整，那么receive.complete()函數(shù)返回值就是false，那么最終返回的結(jié)果就是null，等待下一次OP_READ事件的時候再接著上次沒讀完的數(shù)據(jù)讀取，直到讀取一條完整的數(shù)據(jù)為止。

public NetworkReceive read() throws IOException {
    NetworkReceive result = null;    if (receive == null) {receive = new NetworkReceive(maxReceiveSize, id, memoryPool);    }

    receive(receive);    if (receive.complete()) {receive.payload().rewind();        result = receive;        receive = null;    } else if (receive.requiredMemoryAmountKnown() && !receive.memoryAllocated() && isInMutableState()) {//pool must be out of memory, mute ourselves.        mute();    }return result;}

public boolean complete() {    return !size.hasRemaining() && buffer != null && !buffer.hasRemaining();}

最后，我們再補(bǔ)充一點，當(dāng)我們一次性收到很多條數(shù)據(jù)的時候，會如何處理呢？
下面的源碼告訴了我們答案，就是一次性全部讀取出來，然后存入stageReceives這個數(shù)據(jù)結(jié)構(gòu)中等待下一步業(yè)務(wù)處理。

private void attemptRead(SelectionKey key, KafkaChannel channel) throws IOException {//if channel is ready and has bytes to read from socket or buffer, and has no    //previous receive(s) already staged or otherwise in progress then read from it    if (channel.ready() && (key.isReadable() || channel.hasBytesBuffered()) && !hasStagedReceive(channel)
        && !explicitlyMutedChannels.contains(channel)) {
        NetworkReceive networkReceive;        // 一次性讀取所有的receives，暫存到stageReceives中        while ((networkReceive = channel.read()) != null) {            madeReadProgressLastPoll = true;            addToStagedReceives(channel, networkReceive);        }// isMute是判斷當(dāng)前channel是否關(guān)注了OP_READ事件        if (channel.isMute()) {outOfMemory = true; //channel has muted itself due to memory pressure.        } else {madeReadProgressLastPoll = true;        }
    }
}

到此，相信大家對“KAFKA是如何處理粘包拆包的”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！