使用上述配置將啓用所有節點間的會話複製，使用 DeltaManager 複製會話增量。所謂的全對全，是指每個會話都會複製到集羣中的所有其他節點。這在較小的集羣中效果很好，但我們不建議在較大的集羣中使用 — 多於 4 個節點左右。此外，當使用 DeltaManager 時，Tomcat 將會話複製到所有節點，甚至那些未部署應用的節點。

爲了解決這些問題，您將希望使用 BackupManager。BackupManager 僅將會話數據複製到一個備用節點，並且僅複製到已部署應用的節點。一旦您使用 DeltaManager 運行了簡單的集羣，隨着您增加集羣中節點的數量，您可能希望遷移到 BackupManager。

以下是一些重要的默認值：

多播地址爲 228.0.0.4
多播端口爲 45564（端口和地址一起確定了集羣成員身份）
廣播的 IP 是 java.net.InetAddress.getLocalHost().getHostAddress()（確保不要廣播 127.0.0.1，這是一個常見的錯誤）
監聽複製消息的 TCP 端口是範圍在 4000-4100 的第一個可用服務器套接字
配置了監聽器 ClusterSessionListener
配置了兩個攔截器 TcpFailureDetector 和 MessageDispatchInterceptor

以下是默認的集羣配置：

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
         channelSendOptions="8">

  <Manager className="org.apache.catalina.ha.session.DeltaManager"
           expireSessionsOnShutdown="false"
           notifyListenersOnReplication="true"/>

  <Channel className="org.apache.catalina.tribes.group.GroupChannel">
    <Membership className="org.apache.catalina.tribes.membership.McastService"
                address="228.0.0.4"
                port="45564"
                frequency="500"
                dropTime="3000"/>
    <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
              address="auto"
              port="4000"
              autoBind="100"
              selectorTimeout="5000"
              maxThreads="6"/>

    <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
      <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
    </Sender>
    <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
    <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
  </Channel>

  <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
         filter=""/>
  <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

  <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
            tempDir="/tmp/war-temp/"
            deployDir="/tmp/war-deploy/"
            watchDir="/tmp/war-listen/"
            watchEnabled="false"/>

  <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

我們將在本文檔後面更詳細地介紹這一部分。

安全性

集羣實現是基於在所有集羣相關的網絡流量中使用安全、可信任的網絡的前提下編寫的。在不安全、不可信任的網絡上運行集羣是不安全的。

爲 Tomcat 集羣提供安全、可信任的網絡有許多選項，包括：

私有 LAN
虛擬專用網絡（VPN）
IPSEC

EncryptInterceptor 提供了機密性和完整性保護，但它不能保護免受在不可信任網絡上運行 Tomcat 集羣時可能發生的所有風險，特別是 DoS 攻擊。

集羣基礎知識

要在您的 Tomcat 11 容器中運行會話複製，應完成以下步驟：

所有會話屬性都必須實現 java.io.Serializable
在 server.xml 中取消註釋 Cluster 元素
如果您定義了自定義集羣閥門，請確保在 server.xml 中的 Cluster 元素下也定義了 ReplicationValve
如果您的 Tomcat 實例運行在同一臺機器上，請確保 Receiver.port 屬性對於每個實例是唯一的，在大多數情況下，Tomcat 能夠自動檢測到範圍在 4000-4100 的可用端口
確保您的 web.xml 中有 <distributable/> 元素
如果您使用 mod_jk，請確保在 Engine <Engine name="Catalina" jvmRoute="node01" > 中設置了 jvmRoute 屬性，並且該 jvmRoute 屬性值與 workers.properties 中的 worker 名稱匹配
確保所有節點具有相同的時間並與 NTP 服務同步！
確保您的負載均衡器配置爲粘性會話模式

負載均衡可以通過多種技術實現，如負載均衡章節所述。

注意：請記住，您的會話狀態由 cookie 跟蹤，因此您的 URL 在外部必須看起來相同，否則會創建一個新的會話。

集羣模塊使用 Tomcat JULI 日誌框架，因此您可以通過常規的 logging.properties 文件配置日誌記錄。要跟蹤消息，您可以在鍵 org.apache.catalina.tribes.MESSAGES 上啓用日誌記錄。

概述

爲了在 Tomcat 中啓用會話複製，可以採取三種不同的路徑來實現相同的目標：

使用會話持久性，並將會話保存到共享文件系統（PersistenceManager + FileStore）
使用會話

持久性，並將會話保存到共享數據庫（PersistenceManager + JDBCStore）

使用內存複製，使用隨 Tomcat 一起提供的 SimpleTcpCluster（lib/catalina-tribes.jar + lib/catalina-ha.jar）

Tomcat 可以使用 DeltaManager 執行會話狀態的全對全複製，也可以使用 BackupManager 執行僅將會話複製到一個節點的備份複製。全對全複製是一種僅在集羣較小時纔有效的算法。對於較大的集羣，您應該使用 BackupManager，以使用主要 - 次要會話複製策略，其中會話僅存儲在一個備份節點上。

目前，您可以使用 domain worker 屬性（mod_jk > 1.2.8）構建具有更高可伸縮性的集羣解決方案，以使用 DeltaManager 配置域攔截器（您將需要爲此配置域攔截器）。爲了在全對全環境中減少網絡流量，在多個組之間拆分集羣。這可以通過爲不同的組使用不同的多播地址輕鬆實現。一個非常簡單的設置如下所示：

DNS 輪詢
       |
  負載均衡器
   /           \
集羣1        集羣2
  /     \        /     \
Tomcat1 Tomcat2  Tomcat3 Tomcat4

這裏重要提及的是，會話複製只是集羣的開始。用於實現集羣的另一個流行概念是 farming，即將應用程序僅部署到一個服務器，然後集羣將在整個集羣中分佈部署。這是 FarmWarDeployer 可以實現的所有功能（請參閱 server.xml 中的集羣示例）。

在下一節中，我們將更深入地介紹會話複製的工作原理和配置方法。

集羣信息

通過多播心跳建立成員資格。因此，如果您希望將您的集羣細分，可以通過更改 <Membership> 元素中的多播 IP 地址或端口來實現。

心跳包包含 Tomcat 節點的 IP 地址和 Tomcat 用於複製流量的 TCP 端口。所有數據通信都在 TCP 上進行。

ReplicationValve 用於在請求完成後查找並啓動複製（如果有）。僅當會話已更改（通過對會話調用 setAttribute 或 removeAttribute）時，纔會複製數據。

其中一個最重要的性能考慮因素是同步與異步複製。在同步複製模式下，請求在複製的會話通過網絡並在所有其他集羣節點上重新實例化之前不會返回。同步與異步是通過 channelSendOptions 標誌進行配置的，它是一個整數值。SimpleTcpCluster/DeltaManager 組合的默認值爲 8，即異步。有關各種 channelSendOptions 值的更多討論，請參閱配置參考。

爲方便起見，channelSendOptions 可以通過名稱設置，而不是整數值，這些名稱在啓動時將被翻譯爲其整數值。有效的選項名稱爲："asynchronous"（別名 "async"），"byte_message"（別名 "byte"），"multicast"，"secure"，"synchronized_ack"（別名 "sync"），"udp"，"use_ack"。使用逗號分隔多個名稱，例如，傳遞 "async, multicast" 作爲選項 SEND_OPTIONS_ASYNCHRONOUS | SEND_OPTIONS_MULTICAST。

您可以在send flag(overview) 或 send flag(javadoc) 上閱讀更多關於 send flag 的信息。在異步複製期間，請求在數據被複制之前返回。異步複製可縮短請求時間，而同步複製可確保在請求返回之前複製會話。

在崩潰後將會話綁定到故障轉移節點

如果您正在使用 mod_jk 並且未使用粘性會話，或者由於某些原因粘性會話不起作用，或者您只是在故障轉移，那麼會話 ID 將需要修改，因爲它先前包含了前一個 Tomcat 的 worker ID（由 Engine 元素中的 jvmRoute 定義）。爲解決此問題，我們將使用 JvmRouteBinderValve。

JvmRouteBinderValve 會重寫會話 ID，以確保下一個請求在故障轉移後仍然保持粘性（並且不會退回到隨機節點，因爲該 worker 不再可用）。該閥門將在 cookie 中將 JSESSIONID 值重寫爲同名。如果沒有這個閥門，那麼在 mod_jk 模塊發生故障時確保粘性會變得更加困難。

請注意，如果您在 server.xml 中添加了自定義閥門，則默認值將不再有效，請確保您添加了所有適當的閥門，這些閥門由默認定義。

提示：
通過屬性 sessionIdAttribute，您可以更改包含舊會話 ID 的請求屬性名稱。默認屬性名稱爲 org.apache.catalina.ha.session.JvmRouteOriginalSessionID。

技巧：
您可以在將節點丟棄到所有備用節點之前通過 JMX 啓用此 mod_jk 轉換模式！將 JvmRouteBinderValve 備份的 enable 屬性設置爲 true，禁用 mod_jk 中的 worker，然後丟棄節點並重新啓動它！然後再次啓用 mod_jk Worker 並禁用 JvmRouteBinderValves。這種用法意味着僅遷移請求的會話。

web server apache tomcat11-18-clusting 集羣

前言

開源項目

系列文章

clusting

急於求成

安全性

集羣基礎知識

概述

集羣信息

在崩潰後將會話綁定到故障轉移節點

web server apache tomcat11-29-Windows Authentication

web server apache tomcat11-26-maven jars

web server apache tomcat11-24-Virtual Hosting and Tomcat

web server apache tomcat11-22-logging 日誌

web server apache tomcat11-21-monitor and management 監控與管理

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結