Java應用伺服器之tomcat session server msm搭建配置
在上一篇部落格中，我們介紹了tomcat自帶的cluster元件配置session replication cluster，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13363590.html；session複製叢集的原理就是通過多播通訊的方式，把節點的session資訊傳送給叢集其他節點；這種session複製叢集有一個缺陷，如果後端tomcat server 一旦增多，那麼對於後端用於傳送session資訊的網路會非常擁擠，到達一定的量以後，後端網路就可能癱瘓，這樣一來session複製叢集就失效了；這其中的原因就是因為各個節點通過多播通訊的方式傳送session；為了解決這樣的問題，我們需要重新想辦法把使用者的session存起來；常用的解決方案就是找一臺伺服器或一組伺服器用來存使用者的session，在使用者訪問tomcat伺服器時，後端tomcat伺服器都到我們指定的伺服器存取session，這樣一來不管前端排程器把請求排程到後端任何一臺server上，後端server都會去session伺服器上存取session，通過這樣的方式，我們可以把使用者的資訊共享給其他節點；但是我們需要注意一點後端儲存session的伺服器可能存在單點；常用作為session伺服器的有memcached和redis;它們都是鍵值型別的資料庫，不同的是memcached它的值是流式化型別的資料，什麼意思呢？也就是說往memcached資料庫裡存放資料，必須把資料先通過流式化工具編碼成資料流，然後存入到memcached中，如果需要取資料出來，它需要再通過流式化工具還原成之前的資料；而redis的值相比memcached的值要豐富很多，它不需要流式化工具將資料編碼成資料流，它可以直接存到redis中；
msm是什麼？它都全稱叫memcached session manager 該元件的作用就是用來解決session共享的；以下是官方介紹：memcached-session-manager是一個tomcat會話管理器，用於將會話保持在memcached或Redis中，用於高可用性，可伸縮性和容錯性的Web應用程式。它支援粘性和非粘性配置，並且當前與tomcat 6.x，7.x，8.x和9.x一起使用。對於粘性會話，支援會話故障轉移（tomcat崩潰），對於非粘性會話，這是預設設定（預設情況下，不同的tomcat為不同的請求提供會話服務）。此外，通過會話遷移也支援memcached故障轉移（memcached崩潰）。也不應有任何單點故障，因此當memcached失敗時，會話不會丟失；簡單講就是把tomcat的session資訊存放在memcached中，當後端tomcat宕機，它上面存放的session不會丟失，因為都存放到memcached中了，如果memcached是單點，它也支援多節點；其實memcached到多節點不是memcached自身到功能，它是通過使用memcached客戶端來實現到，其原理很簡單，就是通過客戶端把session同時寫到多個節點上去，預設情況只有一臺memcached工作，當或當節點故障時，它會立即切換到備用節點；
msm搭建
環境說明
| 名稱 | IP地址 | 埠 |
| 代理伺服器nginx | 192.168.16.197 | 80 |
| tomcatA+memcached1 | 192.168.16.196 | 8080,11211 |
| tomcatB+memcached2 | 192.168.16.198 | 8080,11211 |
首先配置nignx 負載均衡tomcatA和tomcatB，然後在tomcatA和tomcatB上部署一個測試應用，部署的過程和配置可以參考前邊的部落格，我這裡就不闡述了；https://www.cnblogs.com/qiuhom-1874/p/13337003.html；
在tomcatA，tomcatB上安裝memcached，並啟動memcached
[root@node01 ~]# yum install -y memcached Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.com base | 3.6 kB 00:00:00 docker-ce-stable | 3.5 kB 00:00:00 epel | 4.7 kB 00:00:00 extras | 2.9 kB 00:00:00 mariadb | 2.9 kB 00:00:00 updates | 2.9 kB 00:00:00 (1/2): epel/x86_64/updateinfo | 1.0 MB 00:00:00 (2/2): epel/x86_64/primary_db | 6.9 MB 00:00:01 Resolving Dependencies --> Running transaction check ---> Package memcached.x86_64 0:1.4.15-10.el7_3.1 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================================================================== Package Arch Version Repository Size ================================================================================================================================== Installing: memcached x86_64 1.4.15-10.el7_3.1 base 85 k Transaction Summary ================================================================================================================================== Install 1 Package Total download size: 85 k Installed size: 176 k Downloading packages: memcached-1.4.15-10.el7_3.1.x86_64.rpm | 85 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : memcached-1.4.15-10.el7_3.1.x86_64 1/1 Verifying : memcached-1.4.15-10.el7_3.1.x86_64 1/1 Installed: memcached.x86_64 0:1.4.15-10.el7_3.1 Complete! [root@node01 ~]# systemctl start memcached [root@node01 ~]# ss -tnl State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:11211 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 100 [::]:8009 [::]:* LISTEN 0 128 [::]:11211 [::]:* LISTEN 0 100 [::]:8080 [::]:* LISTEN 0 128 [::]:22 [::]:* LISTEN 0 100 [::1]:25 [::]:* LISTEN 0 1 [::ffff:127.0.0.1]:8005 [::]:* [root@node01 ~]#
提示：在node02上也是上面的操作，啟動memcached後，如果能夠看到11211埠啟動起來了，說明memcached的環境就準備好了；
準備連線memcached所需要用到的jar包
#!/bin/bash wget https://repo1.maven.org/maven2/de/javakaffee/msm/memcached-session-manager/2.3.2/memcached-session-manager-2.3.2.jar wget https://repo1.maven.org/maven2/de/javakaffee/msm/memcached-session-manager-tc7/2.3.2/memcached-session-manager-tc7-2.3.2.jar wget https://repo1.maven.org/maven2/de/javakaffee/msm/msm-kryo-serializer/2.3.2/msm-kryo-serializer-2.3.2.jar wget https://repo1.maven.org/maven2/de/javakaffee/kryo-serializers/0.45/kryo-serializers-0.45.jar wget https://repo1.maven.org/maven2/com/esotericsoftware/kryo/3.0.3/kryo-3.0.3.jar wget https://repo1.maven.org/maven2/com/esotericsoftware/minlog/minlog/1.2/minlog-1.2.jar wget https://repo1.maven.org/maven2/com/esotericsoftware/reflectasm/reflectasm/1.09/reflectasm-1.09.jar wget https://repo1.maven.org/maven2/org/ow2/asm/asm/5.2/asm-5.2.jar wget https://repo1.maven.org/maven2/org/objenesis/objenesis/2.6/objenesis-2.6.jar wget https://repo1.maven.org/maven2/net/spy/spymemcached/2.12.3/spymemcached-2.12.3.jarView Code
提示：我上面是把jar包的連線都整理到一個指令碼中，我們可以直接進入到tomcat存放jar的位置，執行指令碼，即可把對對應jar包下載到tomcat存放jar包的目錄下；通常yum安裝到tomcat它的jar存放地是/usr/share/java/tomcat/；msm的文件地址https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration；
提示：這裡需要注意點，我們點選對應名稱時，它跳轉的地址是http，會導致我們訪問不到，解決辦法就是把http改成https就可以訪問到了；上面紅框中的jar包是msm中核心包，除了上面的三個包以外，還需要下載序列化的工具包元件，如下
提示：msm序列化工具支援kryo,javolution,xstream,flexjson，根據自己的需求下載對應的序列化工具元件包就行了；
下載好上面的核心包，驅動包，以及序列化工具包，接下來就可以在tomcat中配置連線memcached(tomcatA和tomcatB都要下載上面的jar包)
tomcatA上的配置
提示：以上配置表示，在訪問/myapp這個uri時啟動MemcachedBackupSessionManager的管理器，這個管理器就是用於存放session的；其中對於這個管理來說，裡面有幾個屬性，memcachedNodes表示指定memcached節點的標識，IP地址和埠，如果是多個節點，節點和節點之間用逗號隔開即可；failoverNodes用於指定失敗轉移節點的標識，如上配置的是m1，這也就意味m2是活動節點；只有當m2宕機後，m1才會接替m2；requestUriIgnorePattern表示忽略匹配指定模式的請求uri資源；transcoderFactoryClass用於指定序列化工具的類，這個需要同我們之前的序列化工具名稱來；比如我們使用的是javolution虛擬化工具，我們需要把寫成transcoderFactoryClass="de.javakaffee.web.msm.serializer.javolution.javolutionTranscoderFactory";
對於tomcatB的server.xml的配置除了jvmRoute的值不一樣外，其他配置都是一樣的；到此基於msm的session伺服器就配置好了；
驗證：重啟tomcatA和tomcatB，然後用瀏覽器訪問nginx地址，看看通過nginx負載均衡後，訪問到後端server是怎麼響應客戶端的？
訪問nginx所在主機地址的/myapp，看看會怎麼響應客戶端？
首次訪問
第二次訪問
第三次訪問
第四次訪問
提示：從上面的訪問結果來看，第一次訪問會在響應報文新增一個set-cookie的首部。第二次訪問時，客戶端會通過請求首部cookie把之前的set-cookie的值攜帶上去訪問服務端，此時服務端收到客戶端傳送過來的cookie，給客戶端響應了一個和第一次訪問時一樣的頁面；但是第二次並沒有響應首部set-cookie；第三次客戶端訪問服務端，攜帶之前的cookie，此時被排程到node02上進行響應了，在響應首部又給客戶端了一個set-cookie，和之前的值，變化的只有後面的jvmRoute的標識；頁面響應的中的sessionid的值和前一個session的值一樣；第四次訪問，客戶端就把第三次訪問響應的set-cookie的值攜帶上去訪問服務端，服務端又給它響應一個set-cookie的值，sessionID的值沒有變化，變化的只有後面的jvmRoute的值，此時頁面顯示的sessionID第三次的頁面一樣；不一樣的是一個是node01響應的，一個是node02響應的，說明排程器在輪詢的排程請求；這個和我們之前的session replication cluster 訪問結果一樣；
把memcached2停掉看看客戶端是否還可以訪問後端server？
用瀏覽器訪問看看會有什麼變化？用剛才訪問的瀏覽器，接著訪問
提示：可以看到我們剛才的訪問並沒有什麼影響；
換個瀏覽器訪問或者關閉之前的訪問，從新開啟瀏覽器訪問
提示：可以看到換了一個瀏覽器後，我們再次訪問後面的memcached就是m1，說明本次訪問的session存放在m1上；
從新斷開原有的連線，重新啟動瀏覽器訪問服務端
提示：可以看到，從新開啟瀏覽器訪問，響應的sessionID 還是以前的，只是m2變成了m1；這說明在m1上找到了對應的session，所以當之前訪問過服務端的客戶端再次訪問時，服務端會根據客戶端提供的cookie去session伺服器上查詢，如果session又對應的sessionID，那麼就把之前的狀態響應給客戶端；這同時也說明了m1和m2上都存在之前客戶端訪問的所有session資訊；
恢復m2，看看對應訪問是否會從m2上取session?
提示：可以看到當m2存活後，m1又會自動處於備份狀態，客戶端訪問服務端也會從m2上面取session信