*作者：子葵*

## 背景

在日常運維 ZooKeeper 中，經常會遇到長時間無法選主，恢復時程式啟動又退出，進而導致記憶體暴漲，CPU飆升，GC頻繁，影響業務可用性，這些問題有可能和 jute.maxbuffer 的設定有關。本篇文章就深入 ZooKeeper 原始碼，一起探究一下ZooKeeper 的 jute.maxbuffer 引數的最佳實踐。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2143081051d4166a1c009970a26ec19~tplv-k3u1fbpfcp-zoom-1.image "1.png")

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e7bdb12717964a969c0fbfece48284a6~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## 分析

首先我們透過 ZooKeeper 的官網上看到 jute.maxbuffer 的描述：

> jute.maxbuffer : 
> 
> (Java system property:**jute.maxbuffer**).
> 
> ......, It specifies the maximum size of the data that can be stored in a znode. The unit is: byte. The default is 0xfffff(1048575) bytes, or just under 1M.

> When jute.maxbuffer in the client side is greater than the server side, the client wants to write the data exceeds jute.maxbuffer in the server side, the server side will get **java.io.IOException: Len error**

> When jute.maxbuffer in the client side is less than the server side, the client wants to read the data exceeds jute.maxbuffer in the client side, the client side will get **java.io.IOException: Unreasonable length** or **Packet len is out of range!**

從官網的描述中我們可以知道，jute.maxbuffer 能夠限制 Znode 大小，需要在Server端和Client端合理設定，否則有可能引起異常。

但事實並非如此，我們在ZooKeeper的程式碼中尋找 jute.maxbuffer 的定義和引用：

```
public static final int maxBuffer = Integer.getInteger("jute.maxbuffer", 0xfffff);
```

在 org.apache.jute.BinaryInputArchive 型別中透過 System Properties 讀取到 jute.maxbuffer的值，可以看到預設值是1M，checkLength 方法引用了此靜態值：

```
// Since this is a rough sanity check, add some padding to maxBuffer to
// make up for extra fields, etc. (otherwise e.g. clients may be able to
// write buffers larger than we can read from disk!)
private void checkLength(int len) throws IOException {
    if (len < 0 || len > maxBufferSize + extraMaxBufferSize) {
        throw new IOException(UNREASONBLE_LENGTH + len);
    }
}
```

只要引數 len 超過maxBufferSize 和 extraMaxBufferSize的和，就會丟擲 Unreasonable length 的異常，在生產環境中這個異常往往會導致非預期的選主或者Server無法啟動。

再看一下 extraMaxBufferSize 的賦值：

```
static {
    final Integer configuredExtraMaxBuffer =
        Integer.getInteger("zookeeper.jute.maxbuffer.extrasize", maxBuffer);
    if (configuredExtraMaxBuffer < 1024) {
        extraMaxBuffer = 1024;
    } else {
        extraMaxBuffer = configuredExtraMaxBuffer;
    }
}
```

可以看到 extraMaxBufferSize 預設會使用maxBuffer的值，並且最小值為 1024 （這裡是為了和以前的版本相容），因此在預設的情況下，checkLength方法丟擲異常的閾值是 1M + 1K。

接著我們看一下 checkLength 方法的引用鏈：

有兩個地方引用到了 checkLength 方法：即 org.apache.jute.BinaryInputArchive 型別的 readString 和 readBuffer方法。

```
    public String readString(String tag) throws IOException {
        ......
        checkLength(len);
        ......
    }

public byte[] readBuffer(String tag) throws IOException {
        ......
        checkLength(len);
        ......
    }
```

而這兩個方法在幾乎所有的 org.apache.jute.Recod 型別中都有引用，也就是說 ZooKeeper 中幾乎所有的序列化物件在反序列化的時候都會進行 checkLength 檢查，因此可以得出結論 jute.maxbuffer 不僅僅限制 Znode 的大小，而是所有呼叫 readString 和 readBuffer 的 Record 的大小。

這其中就包含 org.apache.zookeeper.server.quorum.QuorumPacket 型別。

此型別是在 Server 進行 Proposal 時傳輸資料使用的序列化型別，包含寫請求產生的 Txn 在 Server 之間進行同步時傳遞資料都是透過此型別進行序列化的，如果事務太大就會導致 checkLength 失敗丟擲異常，如果是普通的寫請求，因為在請求收到的時候就會 checkLength，因此在預處理請求的時候就可以避免產生過大的 QuorumPacket，但是如果是 CloseSession 請求，在這種情況下就可能出現異常。

我們可以透過 PreRequestProcessor的processRequest方法看到生成CloseSessionTxn 的過程：

```
    protected void pRequest2Txn(int type, long zxid, Request request, Record record, boolean deserialize) throws KeeperException, IOException, RequestProcessorException {
        ......
        case OpCode.closeSession:
            long startTime = Time.currentElapsedTime();
            synchronized (zks.outstandingChanges) {
                Set<string> es = zks.getZKDatabase().getEphemerals(request.sessionId);
                for (ChangeRecord c : zks.outstandingChanges) {
                    if (c.stat == null) {
                        // Doing a delete
                        es.remove(c.path);
                    } else if (c.stat.getEphemeralOwner() == request.sessionId) {
                        es.add(c.path);
                    }
                }  
                if (ZooKeeperServer.isCloseSessionTxnEnabled()) {
                    request.setTxn(new CloseSessionTxn(new ArrayList<string>(es)));
                }
                ......
    }
```

CloseSession 請求很小一般都可以透過 checkLength 的檢查，但是 CloseSession 產生的事務卻有可能很大，可以透過 org.apache.zookeeper.txn.CloseSessionTxn 型別的定義可知此 Txn 中包含所有此 Session 建立的 ephemeral 型別的 Znode，因此，如果一個Session建立了很多 ephemeral 型別的 Znode，當此 Session 有一個 CloseSession 的請求經過 Server 處理的時候，Leader 向 Follower 進行 proposal 的時候就會出現一個特別大的 QuorumPacket，導致在反序列化的時候進行 checkLength 檢查的時候會丟擲異常，可以透過 Follower 的 followLeader 方法看到，在出現異常的時候，Follower 會斷開和 Leader 的連線：

```
void followLeader() throws InterruptedException {
        ......
        ......
        ......
                // create a reusable packet to reduce gc impact
                QuorumPacket qp = new QuorumPacket();
                while (this.isRunning()) {
                    readPacket(qp);
                    processPacket(qp);
                }
            } catch (Exception e) {
                LOG.warn("Exception when following the leader", e);
                closeSocket();

// clear pending revalidations
                pendingRevalidations.clear();
            }
        } finally {
        ......
        ......
    }
```

當超過半數的 follower 都因為 QuorumPacket 過大而無法反序列化的時候就會導致叢集重新選主，並且如果原本的 Leader 在選舉中獲勝，那麼這個 Leader 就會在從磁碟中 load 資料的時候，從磁碟中讀取事物日誌的時候，讀取到剛剛寫入的特別大的 CloseSessionTxn 的時候 checkLength 失敗，導致 Leader 狀態又重新進入 LOOKING 狀態，叢集又開始重新選主，並且一直持續此過程，導致叢集一直處於選主狀態

## 原因

叢集非預期選主，持續選主或者server 無法啟動，經過以上分析有可能就是在 jute.maxbuffer 設定不合理，連線到叢集的某一個 client 建立了特別多的 ephemeral 型別節點，並且當這個 session 發出 closesession 請求的時候，導致 follower 和 Leader 斷連。最終導致叢集選主失敗或者叢集無法正常啟動。

## 最佳實踐建議

首先如何發現叢集是因為jute.maxbuffer 設定不合理導致的叢集無法正常選主或者無法正常啟動 ？

1. 在checkLength方法檢查失敗的時候會丟擲異常，關鍵字是 Unreasonable length，同時 follower 會斷開和 Leader的連線，關鍵字是 Exception when following the leader，可以透過檢索關鍵字快速確認。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6fe854f0c9894d2ca16b406a5296634e~tplv-k3u1fbpfcp-zoom-1.image "3.png")

2. ZooKeeper 在新版本中提供了 last_proposal_size metrics 指標，可以透過此指標監控叢集的 proposal 大小資料，當有 proposal 大於 jute.maxbuffer 的值的時候就需要排查問題。

jute.maxbuffer 如何正確設定？

1. 官方文件首先建議我們在客戶端和服務端正確的設定 jute.maxbuffer ，最好保持一致，避免非預期的 checkLength 檢查失敗。

2. 官方文件建議 jute.maxbuffer 的值不宜過大，大的 Znode 可能會導致 Server 之間同步資料超時，在大資料請求到達 Server 的時候就被攔截掉。

3. 在實際的生產環境中，為了保證生產環境的穩定，如果 jute.maxbuffer 的值設定過小，服務端有可能持續不可用，需要需要更改 jute.maxbuffer 的值才能正常啟動，因此這個值也不能太小。

4. Dubbo 低版本存在重複註冊問題，當重複註冊達到一定的量級，就有可能觸發這個閾值（1M），Dubbo 單節點註冊的 Path 長度按照 670 位元組計算，預設閾值最多容納 1565 次重複註冊，因此在業務側需要規避重複註冊的問題。綜上，在使用的 ZooKeeper 的過程中，jute.maxbuffer 的設定還需要考慮到單個 session 建立過多的 ephemeral 節點這一種情況，合理配置 jute.maxbuffer 的值。

在 MSE ZooKeeper 中，可以透過控制檯快捷修改 jute.maxbuffer 引數：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/206f4c1aebe74aa4b9c7a0f36d40cb44~tplv-k3u1fbpfcp-zoom-1.image "4.png")

設定 MSE ZooKeeper 選主時間告警以及節點不可用告警。首先進入告警管理頁面，建立新的告警：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3cfbaeb0b8c8468c9e1fc2e11e69356f~tplv-k3u1fbpfcp-zoom-1.image "5.png")

分組選擇 ZooKeeper 專業版，告警項選擇選主時間，然後設定閾值：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/782bfe3c84b24044bd7358c425832889~tplv-k3u1fbpfcp-zoom-1.image "6.png")

POD 狀態告警，分組選擇 ZooKeeper 專業版，告警項選擇 ZooKeeper 單 POD狀態：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dc4eb1045ff846ccac7316c1c7300ad9~tplv-k3u1fbpfcp-zoom-1.image "6.png")

配置節點不可用和選主時間告警，及時發現問題進行排查。

## 運營活動

重磅推出 MSE 專業版，更具價效比，可直接從基礎版一鍵平滑升級到專業版！

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/74db48bdc61f45dca90b0e963bf8c263~tplv-k3u1fbpfcp-zoom-1.image "7.png")

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cd811e2714ff4cb39b0b4b21fbe10f52~tplv-k3u1fbpfcp-zoom-1.image "8.png")</string></string>

ZooKeeper 避坑實踐：如何調優 jute.maxbuffer

相關文章