策略一：選擇緩存系統ECS機型

性能估算

分布式文件緩存系統能夠聚合多個節點上的存儲資源和帶寬資源，為上層應用提供更大的緩存容量和更高的可用帶寬。關于緩存容量、可用帶寬以及應用數據訪問的最大帶寬的理論上限值可根據以下公式估算：

• 緩存可用容量 = 每個分布式緩存Worker Pod提供的緩存容量 * 分布式緩存Worker Pod副本數

• 緩存可用帶寬 = 分布式緩存Worker Pod副本數 * min{Worker Pod所在ECS節點的最大可用帶寬, Worker Pod使用的緩存介質I/O吞吐}。另外，緩存可用帶寬不代表數據訪問過程中的實際帶寬，數據訪問過程的實際帶寬受客戶端ECS節點可用帶寬，以及數據訪問模式（順序讀、隨機讀）影響。

• 應用Pod數據訪問過程的理論最大帶寬 = min{應用Pod所在ECS節點的可用帶寬，緩存可用帶寬}。另外，當多個應用Pod并發訪問數據時，緩存可用帶寬將被這些應用Pod共享占用。

示例

例如，在ACK集群中擴容2臺ecs.g7nex.8xlarge規格的ECS實例用于構建分布式緩存集群，分布式緩存集群包含2個緩存Worker Pod，每個Pod設置的緩存容量為100 GiB內存，兩個Pod分別運行于兩臺ECS實例上。應用Pod部署于一臺ecs.gn7i-c8g1.2xlarge（8 vCPU，30 GiB內存，16 Gbps帶寬）規格的ECS實例，其緩存容量、可用帶寬以及最大帶寬的理論值如下所示：

• 緩存可用容量 = 100GiB * 2 = 200 GiB

• 緩存可用帶寬 = 2 * min{40 Gbps, 內存訪問I/O吞吐} = 80 Gbps

• 緩存命中時，應用Pod數據訪問最大可用帶寬 = min{80Gbps, 16Gbps} = 16 Gbps

推薦ECS機型規格

分布式緩存集群的可用帶寬取決于集群中各個ECS節點的最大可用帶寬和所使用的緩存介質，為提升分布式緩存系統性能，推薦您使用高帶寬的ECS實例規格，并使用內存或本地HDD或本地SSD盤作為緩存介質。推薦使用的ECS實例規格如下所示。

關于ECS實例的詳細信息，請參見實例規格族。

策略二：選擇緩存介質

分布式緩存集群的可用帶寬取決于集群中各個ECS節點的最大可用帶寬和所使用的緩存介質，為提升分布式緩存系統性能，推薦您使用高帶寬的ECS實例規格，并使用內存或本地SSD盤作為緩存介質。在Fluid中，可以通過配置Runtime資源對象的spec.tieredstore參數來設置不同的緩存介質以及緩存容量。

spec:
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 30Gi # 為單個分布式緩存Worker副本所能提供的緩存容量。
        high: "0.99"
        low: "0.95"

策略三：配置數據緩存與應用間調度親和性

當數據訪問請求命中緩存時，應用Pod從緩存系統中讀取數據。因此，如果應用Pod與緩存系統分別部署在不同的可用區內，應用需要跨可用區訪問緩存數據。如果希望降低跨可用區網絡波動對數據訪問過程的影響，需要考慮應用Pod與緩存系統相關Pod之間的調度親和性，具體而言：

• 緩存系統Worker Pod盡量親和部署在相同可用區內。

• 應用Pod與緩存系統Worker Pod盡量親和部署在相同可用區內。

在Fluid中，可以通過配置Dataset資源對象的spec.nodeAffinity，設置緩存系統Worker Pod的調度親和性，如下所示：

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - <ZONE_ID> # 所在的可用區，例如cn-beijing-i。

上述配置將分布式緩存系統Worker Pod均部署在<ZONE_ID>可用區的ECS節點。

另外，Fluid可以在應用Pod中自動注入該應用Pod所需緩存的親和性信息，實現應用Pod與緩存系統Worker Pod盡量同可用區親和部署。更多信息，請參見數據緩存親和性調度優化。

策略四：大文件全量順序讀場景參數配置優化

許多數據密集型場景中涉及大文件全量順序讀的數據訪問模式，例如，基于TFRecord或Tar格式的數據集進行模型訓練、AI模型推理服務啟動時加載1個或多個模型參數文件、讀取Parquet文件格式進行分布式數據分析等。針對此類場景，可以使用更加激進的預讀策略，提升數據訪問性能，例如適當增大緩存系統預讀的并發度、預讀數據量等。

在Fluid中，不同分布式緩存運行時在預讀策略方面的配置需要有不同的參數配置，如下所示：

kind: JindoRuntime
metadata:
  ...
spec:
  fuse:
    properties:
      fs.oss.download.thread.concurrency: "200"
      fs.oss.read.buffer.size: "8388608"
      fs.oss.read.readahead.max.buffer.count: "200"
      fs.oss.read.sequence.ambiguity.range: "2147483647" # 約2G。

kind: JuiceFSRuntime
metadata:
  ...
spec:
  fuse:
    options:
      buffer-size: "2048"
      cache-size: "0"
      max-uploads: "150"
  worker:
    options:
      buffer-size: "2048"
      max-downloads: "200"
      max-uploads: "150"
  master:
    resources:
      requests:
        memory: 2Gi
      limits:
        memory: 8Gi
  ...

策略一：避免掛載包含大量文件的目錄作為底層數據源

緩存系統需要維護掛載底層存儲目錄下全部文件的元信息，并記錄各文件的緩存狀態等額外元信息。如果緩存系統掛載了包含大量文件的底層存儲目錄（例如：大規模存儲系統的根目錄），緩存系統必須使用大量內存資源存儲相關元信息，并使用更多CPU資源處理相關的元信息訪問請求。

Fluid定義了Dataset的抽象概念，Dataset是面向上層特定應用，邏輯上是一組相關數據的集合。一個Dataset會對應啟動一個分布式緩存系統，并且一個Dataset應當僅為一個或某些相關的數據密集型任務提供數據訪問加速服務。因此，推薦您創建多個Dataset，并在每個Dataset中分別定義底層數據源的不同子目錄，具體子目錄級別與業務應用所需的數據集合相關，不同的業務應用可以使用不同的Dataset綁定的緩存系統訪問數據，這將使得各業務應用間有著更好的隔離性，保證系統穩定性和性能。Dataset配置示例如下：

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  mounts:
  - mountPoint: oss://<BUCKET>/<PATH1>/<SUBPATH>/
    name: sub-bucket

創建多個緩存系統可能導致額外的運維復雜性，可根據實際業務需求靈活選擇架構方案，例如：

• 如果所需緩存的數據集存儲在單一后端存儲系統中，且規模不大，文件數量不多，有較強的相關性，推薦創建單個Fluid Dataset和分布式緩存系統提供服務。

• 如果所需緩存的數據集規模較大、文件數量較多，推薦根據數據目錄的業務含義，分拆為多個Fluid Dataset和分布式緩存系統提供服務，應用Pod可聲明掛載一個或多個Fluid Dataset到指定目錄下。

• 如果所需緩存的數據集來自于多個用戶的不同的存儲系統，并且業務要求保證用戶間的數據隔離性。推薦為每個用戶或用戶的一系列數據相關的作業創建有著較短生命周期的Fluid Dataset，通過開發Kubernetes Operator靈活運維集群中多個Fluid Dataset。

策略二：使用元信息持久化提升緩存系統穩定性

許多分布式緩存系統采用Master-Worker的分布式架構，它們依賴于Master Pod組件維護掛載的后端存儲系統目錄的文件元信息，并記錄各文件的緩存狀態。當應用通過此類緩存系統訪問數據時，首先需要從Master Pod組件中獲取文件元信息，接著從底層文件存儲或緩存Worker組件中獲取數據。因此，緩存Master Pod組件的穩定性對緩存系統的高可用性至關重要。

如果使用JindoRuntime作為緩存運行時，在Fluid中推薦使用以下配置提升緩存Master Pod組件的可用性：

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: sd-dataset
spec:
  ...
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta
  master:
    resources:
      requests:
        memory: 4Gi
      limits:
        memory: 8Gi
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofs-meta
    properties:
      namespace.meta-dir: "/root/jindofs-meta"

在上述YAML示例中，demo-jindo-master-meta為提前創建的PVC，該PVC使用ESSD云盤作為存儲卷，這意味著Master Pod組件維護的元信息能夠持久化存儲，并能夠隨Pod遷移。更多信息，請參見通過配置JindoRuntime實現Master Pod組件狀態持久化存儲。

策略三：合理配置FUSE Pod資源

緩存系統客戶端程序運行于FUSE Pod中，FUSE Pod在節點上掛載FUSE文件系統，該文件系統將被掛載到應用Pod的指定路徑上，并暴露POSIX文件訪問接口。這使得應用Pod往往不需要修改應用代碼，即可像訪問本地存儲一樣訪問遠程存儲系統中的數據，并享受到緩存帶來的加速效果。FUSE程序維持了應用和緩存系統之間的數據通道，因此推薦對FUSE Pod所使用的資源進行配置。

在Fluid中，可以通過配置Runtime資源對象的spec.fuse.resources設置FUSE Pod的資源使用。為避免因FUSE程序OOM導致的文件掛載點斷裂問題，推薦您對FUSE Pod不設置或設置較大的內存限制。例如，可以設置FUSE Pod的內存限制接近ECS節點的可分配內存大小。

spec:
  fuse:
    resources:
      requests:
        memory: 8Gi
    # limits:
    #   memory: <ECS_ALLOCATABLE_MEMORY>

策略四：開啟FUSE自愈功能提升數據訪問客戶端可用性

FUSE程序維持了應用和緩存系統之間的數據通道。默認情況下，如果FUSE程序因某些預期之外的行為崩潰，即使FUSE程序重啟后恢復正常，應用容器也無法再通過該FUSE文件系統掛載點訪問數據。為解決該問題，應用容器必須重啟（重新觸發FUSE文件系統掛載點到應用Pod的綁定掛載邏輯）來恢復數據訪問，這將影響應用Pod的可用性。

Fluid提供了FUSE自愈機制，開啟該機制后應用容器無需重啟，即可在FUSE程序重啟后的一段時間后，自動恢復應用容器內FUSE掛載點的數據訪問。

如需開啟并使用FUSE自愈功能，請參見如何開啟FUSE自動恢復能力。FUSE自愈能力存在較多限制，推薦僅在某些具有明確需求且業務適合的應用場景選擇性開啟此能力，例如：交互式編程開發場景，即使用在線Notebook或其他環境交互式開發調試某些應用程序。