Apache Ignite之集羣應用測試

時間 2019-12-13

原文原文鏈接

集羣發現機制

在Ignite中的集羣號稱是無中心的，並且支持命令行啓動和嵌入應用啓動，因此按理說很簡單。並且集羣有自動發現機制感受對於懶人開發來講太好了，抱着試一試的心態測試一下吧。html

在Apache Ignite中有三種自有的發現機制：組播、靜態IP、組播+靜態IP。下面就這幾種來試一試吧。java

測試方法簡述

測試的方法主要是經過搭建2臺tomcat服務器，使用nginx來代理這2臺tomcat，tomcat服務器裏有一個web應用，此應用內經過Apache Ignite webSession cluster來完成集羣。具體的配置與方法能夠參考《Apache Ignite高性能分佈式網格框架-初探》。nginx

集羣發現機制測試-組播模式

按照Ignite的手冊組播是不須要作太多的配置的，默認便可，我在本機搭建兩個tomcat發現確實是能夠實現自動發現的，啓動後確實完成用戶登陸，關閉其中一臺tomcat發現用戶登陸狀態仍是保持了。web

可是我把這種場景搬到服務器上發現就不靈了，緣由多是局域網禁用了組播。組播這塊我也不是很瞭解就跳過了。spring

靜態ip發現的一些問題研究

節點都是服務端模式

爲了達到集羣的目的，因而仍是使用靜態IP的方式吧，下面是個人xml配置文件：apache

<!-- Provide configuration bean. -->
  <bean id="cacheManager" class="org.apache.ignite.cache.spring.SpringCacheManager">
      <property name="configuration">
          <bean class="org.apache.ignite.configuration.IgniteConfiguration">
            <!-- 客戶端模式設置，爲true時開啓客戶端模式 -->
            <property name="clientMode" value="false"/>
            <property name="cacheConfiguration">
                   <bean class="org.apache.ignite.configuration.CacheConfiguration">
                       <property name="name" value="partitioned"/>
                       <property name="cacheMode" value="PARTITIONED"/>
                       <property name="backups" value="1"/>
                   </bean>
                </property>
                <property name="discoverySpi">
                        <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
                          <property name="ipFinder">
                            <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
                              <property name="multicastGroup" value="224.0.0.100"/>
                              <property name="addresses">
                      <list>
                        <value>192.168.36.116:47500..47509</value>
                        <value>192.168.49.204:47500..47509</value>
                      </list>
                    </property>
                            </bean>
                           </property>
              </bean>
            </property>             
          </bean>
       </property>
  </bean>

我是直接在spring中作的配置，其中啓動了一個緩存叫partitioned，用於存websession，並且使用了PARTITIONED模式，數據會分片存儲且備份，而且設定了備份數爲1，也就是說每個session都至少有一個備份。緩存

另外我指定了一個發現器是TcpDiscoveryMulticastIpFinder，這個發現器能夠指定組播地址和靜態地址，前面已經測試過了組播地址不生效，因此下面就加了兩臺tomcat的ip及端口範圍。tomcat

這樣配置後，發現Ignite的集羣組建成功了，我隨便找了一個日誌：服務器

2016-11-23 15:45:00,570 INFO [org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] - Topology snapshot [ver=4, servers=2, clients=0, CPUs=8, heap=3.4GB]session

這裏發現已經有2臺server鏈接上了，其中可用8個CPU和3.4GB內存。此時客戶端經過nginx訪問OK了，說明這種集羣是能夠的。

節點中一個服務端一個客戶端

由於Ignite能夠配置爲客戶端模式，因此將其中192.168.49.204這臺設置爲客戶端模式，而後先啓動192.168.36.116這臺tomcat，再啓動192.168.49.204這臺。

查看192.168.46.116的日誌發現：

2016-11-23 15:52:54,454 INFO [org.apache.ignite.internal.managers.discovery.GridDiscoveryManager] - Topology snapshot [ver=8, servers=1, clients=1, CPUs=8, heap=3.4GB]

發現已經有變成了一臺server和一臺client，這說明集羣也成功了。

而後訪問nginx的地址並登陸系統，正常。爲了測試一下咱們並了49.204這臺client機，再訪問登陸的會話是保持的，這說明狀態已經保留。

下面再啓動49.204，測試一下關閉server的狀況，接着訪問系統會發現報錯了：

2016-11-23 15:59:38,819 ERROR [root] - Failed to update web session: null
class org.apache.ignite.IgniteException: Failed to wait for retry: class org.apache.ignite.lang.IgniteFutureTimeoutException: Timeout was reached before computation completed.
    at org.apache.ignite.cache.websession.WebSessionFilter.handleCacheOperationException(WebSessionFilter.java:903)
    at org.apache.ignite.cache.websession.WebSessionFilter.handleLoadSessionException(WebSessionFilter.java:596)
    at org.apache.ignite.cache.websession.WebSessionFilter.doFilterV2(WebSessionFilter.java:522)
    at org.apache.ignite.cache.websession.WebSessionFilter.doFilterDispatch(WebSessionFilter.java:406)
    at org.apache.ignite.cache.websession.WebSessionFilter.doFilter(WebSessionFilter.java:382)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at com.hundsun.jresplus.web.servlet.SimpleOncePerRequestFilterChain$SimpleFilterChain.doFilter(SimpleOncePerRequestFilterChain.java:77)
    at com.hundsun.jresplus.web.contain.ContainFilter.doFilter(ContainFilter.java:59)
    at com.hundsun.jresplus.ui.contain.HornContainFilter.doFilter(HornContainFilter.java:46)
    at com.hundsun.jresplus.web.servlet.SimpleOncePerRequestFilterChain$SimpleFilterChain.doFilter(SimpleOncePerRequestFilterChain.java:79)
    at com.hundsun.jresplus.web.nosession.NoSessionFilter.doFilterInternal(NoSessionFilter.java:96)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
    at com.hundsun.jresplus.web.servlet.SimpleOncePerRequestFilterChain$SimpleFilterChain.doFilter(SimpleOncePerRequestFilterChain.java:79)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
    at com.hundsun.jresplus.web.servlet.SimpleOncePerRequestFilterChain$SimpleFilterChain.doFilter(SimpleOncePerRequestFilterChain.java:79)
    at com.hundsun.jresplus.web.servlet.SimpleOncePerRequestFilterChain.doFilter(SimpleOncePerRequestFilterChain.java:49)
    at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
    at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:957)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:722)

從新啓動36.116服務器，發現訪問頁面不報錯了，可是登陸會話丟失。這說明客戶端模式的節點不保存數據。

測試一下靜態IP指定

在以前的測試中靜態IP是指定了所有的機器，那麼若是隻指定一個IP會如何呢？對節點啓動順序是否有影響。下面將ip保住192.168.36.116，另外一個刪除掉：

<property name="addresses">
  <list>
    <value>192.168.36.116:47500..47509</value>
  </list>
</property>

先啓動49.204——>系統登陸——>再啓動36.116

結果啓動49.204，發現訪問系統頁面失敗，返回的是nginx的報錯頁面，說明沒有代理到49.204上。查看日誌發現：

2016-11-23 16:07:56,932 WARN [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] - Failed to connect to any address from IP finder (will retry to join topology every 2 secs): [/192.168.36.116:47500, /192.168.36.116:47501, /192.168.36.116:47502, /192.168.36.116:47503, /192.168.36.116:47504, /192.168.36.116:47505, /192.168.36.116:47506, /192.168.36.116:47507, /192.168.36.116:47508, /192.168.36.116:47509]

說明這種設置了靜態Ip狀況下若是發現指定的節點找不到則會卡住，致使tomcat也不往下走了。因此說這種狀況不用再測試了直接over。

先啓動36.116-——>系統登陸——>再啓動49.204
這種模式沒問題，訪問nginx的服務地址能夠訪問到兩臺服務器。因此必須有一個服務器節點。並且啓動順序也必須是先啓動服務器節點再啓動客戶端節點才行。

測試服務器模式只配置靜態IP192.168.36.116

上面測試了一個靜態IP分服務端+客戶端的模式，若是兩臺都是服務端呢？會不會有什麼影響，爲了驗證，把49.204的模式改成服務端模式，而後配置做以下修改

<!-- 客戶端模式設置，爲true時開啓客戶端模式 -->
            <property name="clientMode" value="false"/>
            
            
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
                              <property name="multicastGroup" value="224.0.0.100"/>
                              <property name="addresses">
                      <list>
                        <value>192.168.36.116:47500..47509</value>
                      </list>
                    </property>
                            </bean>

下面步驟：