cas4.0サービス・エンド・クラスタ

casサービス側クラスタは、ネット上の資料も多いと信じています.session共有、ticket共有にほかならありません.
セッション共有について前回tomcat redisセッションmanagerで具体的な解決策を示しましたが、ここでは主にticket共有の問題について説明します.
まず自分のticketRegistoryを以下のように定義します.
それを修正するxmlファイルマスク

 <!--  <bean id="ticketRegistry" class="org.jasig.cas.ticket.registry.DefaultTicketRegistry" /> -->
	
	<!-- Quartz
	TICKET REGISTRY CLEANER -->
	<!-- <bean id="ticketRegistryCleaner" class="org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner"
		p:ticketRegistry-ref="ticketRegistry"
		p:logoutManager-ref="logoutManager" />
	
	<bean id="jobDetailTicketRegistryCleaner" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean"
		p:targetObject-ref="ticketRegistryCleaner"
		p:targetMethod="clean" />
	
	<bean id="triggerJobDetailTicketRegistryCleaner" class="org.springframework.scheduling.quartz.SimpleTriggerBean"
		p:jobDetail-ref="jobDetailTicketRegistryCleaner"
		p:startDelay="20000"
		p:repeatInterval="5000000" /> -->

追加

  <bean id="ticketRegistry" class="com.cn.instai.cas.registry.RedisTicketRegistry" 
  	p:redisManager-ref="redisManager"
  	p:stMaxFreeTime="${st.timeToKillInSeconds}"
  	p:tgtMaxFreeTime="${tgt.timeToKillInSeconds}"
  />

${st.timeToKillInSeconds}    <span style="font-family: Arial, Helvetica, sans-serif;">${tgt.timeToKillInSeconds}         </span>

このチケットの共有完了
しかしテスト発見単点登出ticketははっきりしているが単点登出成功デバッグ発見このようにticketを共有する時logout時に要求システムにlogoutRequest要求を送信していない
4.0 logout-webflowプロセス構造を採用し、logout-webflowを表示する.xml

<action-state id="terminateSession">
    <evaluate expression="terminateSessionAction.terminate(flowRequestContext)" />
    <transition to="doLogout" />
  </action-state>

開始ノードが見つかりました
注意主に業務処理場所を登録して最初は無視されていましたが、logoutActionソースコードに従って最後に元の処理がterminateSessionであることに気づきました.
cas-server.xmlにおけるidがterminateSessionActionであるbeanクラスはorgである.jasig.cas.web.flow.TerminateSessionAction

<evaluate expression="terminateSessionAction.terminate(flowRequestContext)" />           TerminateSessionAction  terminate  

コードは次のとおりです.
発見されたdestroyTicketGrantingTicketはcentralAuthenticationServiceのtgt手形の破棄方法を呼び出したことを発見しました
メソッドの表示
logotoManagerのperformLogoutメソッドの表示
発見サービス=ticket.getServices(); デフォルトのticketRegistryを使用するとすべてのサービスを取得できますが、RedisTicketRegistryを使用して取得したサービスが空の場合
ここでは、2つのredisTicketRegistryに保存されているTGT手形にクライアントがログインしたservie情報が含まれていないことが、単一のログインができない理由をやっと見つけた.
そこでServiceValidateControllerを見てから、stチケットを認証するときに対応するサービス情報を保存したのかと思ったら、気づかなかったようです
後でCを見て
n t r a l AuthenticationServiceImplのgrantServiceTicketメソッド
///TGT手形対授権ST手形
 final ServiceTicket serviceTicket = ticketGrantingTicket.grantServiceTicket(generatedServiceTicketId, service,                 this.serviceTicketExpirationPolicy, credentials != null);         this.serviceTicketRegistry.addTicket(serviceTicket);
TGT手形grantServiceTicketメソッド
ブレークポイント比較2つのチケット格納方式の違いは、redisTicketRegistryがここでTGTチケットservicesに対する変更がredisに更新されないことを発見した.
そこでカスタマイズしました
C e n t r a l AuthenticationServiceの実装クラスは、TGT手形がST手形を許可した後、TGT手形をリフレッシュしました.
つまりticketGrantingTicket.grantServiceTicketの後にコードが1行追加されました
this.serviceTicketRegistry.addTicket(ticketGrantingTicket);
ここではredis keyと同じように実際の効果と更新を上書きします
このcasサービス側のクラスタで完了
      
大神たちがもっと良い解決策を与えることを望んでいます.