補習系列(15)-springboot 分散式會話原理

摘要： 目錄 一、背景 在 補習系列(3)-springboot 幾種scope 一文中，筆者介紹過 Session的部分，如下： 對於伺服器而言，Session 通常是儲存在本地的，比如Tomcat 預設將Session 儲存在記憶體(ConcurrentHashMap)中...

目錄

一、背景

在 ofollow,noindex" target="_blank">補習系列(3)-springboot 幾種scope 一文中，筆者介紹過 Session的部分，如下：

對於伺服器而言，Session 通常是儲存在本地的，比如Tomcat 預設將Session 儲存在記憶體(ConcurrentHashMap)中。

但隨著網站的使用者越來越多，Session所需的空間會越來越大，同時單機部署的 Web應用會出現效能瓶頸。

這時候需要進行架構的優化或調整，比如擴充套件Web 應用節點，在應用伺服器節點之前實現負載均衡。

那麼，這對現有的會話session 管理帶來了麻煩，當一個帶有會話表示的Http請求到Web服務器後，需求在請求中的處理過程中找到session資料，

而 session資料是儲存在本地的，假設我們有應用A和應用B，某使用者第一次訪問網站，session資料儲存在應用A中；

第二次訪問，如果請求到了應用B，會發現原來的session並不存在！

一般，我們可通過集中式的 session管理來解決這個問題，即分散式會話。

[圖 - ] 分散式會話

二、SpringBoot 分散式會話

在前面的文章中介紹過Redis 作為快取讀寫的功能，而常見的分散式會話也可以通過Redis來實現。

在SpringBoot 專案中，可利用 spring-session-data-redis 元件來快速實現分散式會話功能。

引入框架

<!-- redis -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
<version>${spring-boot.version}</version>
</dependency>
<!-- redis session -->
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
<version>1.3.3.RELEASE</version>
</dependency>

同樣，需要在 application.properties 中配置 Redis連線引數：

spring.redis.database=0 
spring.redis.host=127.0.0.1
spring.redis.password=
spring.redis.port=6379
spring.redis.ssl=false
#
## 連線池最大數
spring.redis.pool.max-active=10 
## 空閒連線最大數
spring.redis.pool.max-idle=10
## 獲取連線最大等待時間(s)
spring.redis.pool.max-wait=600

接下來，我們需要在JavaConfig中啟用分散式會話的支援：

@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 24
* 3600, redisNamespace = "app", redisFlushMode = RedisFlushMode.ON_SAVE)
public class RedisSessionConfig {

屬性解釋如下：

屬性	說明
maxInactiveIntervalInSeconds	指定時間內不活躍則淘汰
redisNamespace	名稱空間(key的部分)
redisFlushMode	重新整理模式

至此，我們已經完成了最簡易的配置。

三、樣例程式

通過一個簡單的例子來演示會話資料生成：

@Controller
@RequestMapping("/session")

@SessionAttributes("seed")
public class SessionController {

private static final Logger logger = LoggerFactory.getLogger(SessionController.class);

/**
* 通過註解獲取
*
* @param counter
* @param response
* @return
*/
@GetMapping("/some")
@ResponseBody
public String someSession(@SessionAttribute(value = "seed", required = false) Integer seed, Model model) {

logger.info("seed:{}", seed);

if (seed == null) {
seed = (int) (Math.random() * 10000);
} else {
seed += 1;
}
model.addAttribute("seed", seed);

return seed + "";
}

上面的程式碼中，我們聲明瞭一個seed屬性，每次訪問時都會自增(從隨機值開始)，並將該值置入當前的會話中。

瀏覽器訪問 http://localhost:8090/session/some?seed=1，得到結果：

2153
2154
2155
...

此時推斷會話已經寫入 Redis，通過後臺檢視Redis，如下：

127.0.0.1:6379> keys *
1) "spring:session:app:sessions:expires:732134b2-2fa5-438d-936d-f23c9a384a46"
2) "spring:session:app:expirations:1543930260000"
3) "spring:session:app:sessions:732134b2-2fa5-438d-936d-f23c9a384a46"

如我們的預期產生了會話資料。

示例程式碼可從 碼雲gitee 下載。

https://gitee.com/littleatp/springboot-samples/

四、原理進階

A. 序列化

接下來，繼續嘗試檢視 Redis 所儲存的會話資料

127.0.0.1:6379> hgetall "spring:session:app:sessions:8aff1144-a1bb-4474-b9fe-593
a347145a6"
1) "maxInactiveInterval"
2) "\xac\xed\x00\x05sr\x00\x11java.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02
\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b
\x02\x00\x00xp\x00\x01Q\x80"
3) "sessionAttr:seed"
4) "\xac\xed\x00\x05sr\x00\x11java.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02
\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b
\x02\x00\x00xp\x00\x00 \xef"
5) "lastAccessedTime"
6) "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x
01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x
00\x00xp\x00\x00\x01gtT\x15T"
7) "creationTime"
8) "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x
01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x
00\x00xp\x00\x00\x01gtT\x15T"

發現這些資料根本不可讀，這是因為，對於會話資料的值，框架預設使用了JDK的序列化！

為了讓會話資料使用文字的形式儲存，比如JSON，我們可以宣告一個Bean：

@Bean("springSessionDefaultRedisSerializer")
public Jackson2JsonRedisSerializer<Object> jackson2JsonSerializer() {
Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(
Object.class);

ObjectMapper mapper = new ObjectMapper();
mapper.setSerializationInclusion(Include.NON_NULL);
mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
jackson2JsonRedisSerializer.setObjectMapper(mapper);
return jackson2JsonRedisSerializer;
}

需要 RedisSerializer 定義為 springSessionDefaultRedisSerializer 的命名，否則框架無法識別。

再次檢視會話內容，發現變化如下：

127.0.0.1:6379> hgetall "spring:session:app:sessions:d145463d-7b03-4629-b0cb-97c
be520b7e2"
1) "lastAccessedTime"
2) "1543844570061"
3) "sessionAttr:seed"
4) "7970"
5) "maxInactiveInterval"
6) "86400"
7) "creationTime"
8) "1543844570061"

RedisHttpSessionConfiguration 類定義了所有配置，如下所示：

@Bean
public RedisTemplate<Object, Object> sessionRedisTemplate(
RedisConnectionFactory connectionFactory) {
RedisTemplate<Object, Object> template = new RedisTemplate<Object, Object>();
template.setKeySerializer(new StringRedisSerializer());
template.setHashKeySerializer(new StringRedisSerializer());
if (this.defaultRedisSerializer != null) {
template.setDefaultSerializer(this.defaultRedisSerializer);
}
template.setConnectionFactory(connectionFactory);
return template;
}

可以發現，除了預設的值序列化之外，Key/HashKey都使用了 StringRedisSerializer (字串序列化)

B. 會話代理

通常SpringBoot 內嵌了 Tomcat 或 Jetty 應用伺服器，而這些HTTP容器都實現了自己的會話管理。

儘管容器也都提供了會話管理的擴充套件介面，但實現各種會話管理擴充套件會非常複雜，我們注意到

spring-session-data-redis依賴了 spring-session 元件；

而 spring-session 實現了非常豐富的 session管理功能介面。

RedisOperationsSessionRepository是基於Redis實現的Session讀寫類，由 spring-data-redis 提供；

在呼叫路徑搜尋中可以發現， SessionRepositoryRequestWrapper 呼叫了會話讀寫類的操作，而這正是一個實現了HttpServletRequest介面的代理類！

原始碼片段：

private S getSession(String sessionId) {
S session = SessionRepositoryFilter.this.sessionRepository
.getSession(sessionId);
if (session == null) {
return null;
}
session.setLastAccessedTime(System.currentTimeMillis());
return session;
}

@Override
public HttpSessionWrapper getSession(boolean create) {
HttpSessionWrapper currentSession = getCurrentSession();
if (currentSession != null) {
return currentSession;
}
String requestedSessionId = getRequestedSessionId();
if (requestedSessionId != null
&& getAttribute(INVALID_SESSION_ID_ATTR) == null) {
S session = getSession(requestedSessionId);

至此，代理的問題得到了解答：

spring-session通過過濾器實現 HttpServletRequest 代理；

在代理物件中呼叫 會話管理器 進一步進行Session的操作。

這是一個代理模式的巧妙應用！

C. 資料老化

我們注意到在檢視Redis資料時發現了這樣的 Key

1) "spring:session:app:sessions:expires:732134b2-2fa5-438d-936d-f23c9a384a46"
2) "spring:session:app:expirations:1543930260000"

這看上去與 Session 資料的老化應該有些關係，而實際上也是如此。

我們從 RedisSessionExpirationPolicy 可以找到答案：

當 Session寫入或更新時，邏輯程式碼如下：

public void onExpirationUpdated(Long originalExpirationTimeInMilli,
ExpiringSession session) {
String keyToExpire = "expires:" + session.getId();
//指定目標過期時間的分鐘刻度(下一分鐘)
long toExpire = roundUpToNextMinute(expiresInMillis(session));

...

long sessionExpireInSeconds = session.getMaxInactiveIntervalInSeconds();

//spring:session:app:sessions:expires:xxx"
String sessionKey = getSessionKey(keyToExpire);
...
//spring:session:app:expirations:1543930260000
String expireKey = getExpirationKey(toExpire);
BoundSetOperations<Object, Object> expireOperations = this.redis
.boundSetOps(expireKey);
//將session標記放入集合
expireOperations.add(keyToExpire);
 
//設定過期時間5分鐘後再淘汰
long fiveMinutesAfterExpires = sessionExpireInSeconds
+ TimeUnit.MINUTES.toSeconds(5);

expireOperations.expire(fiveMinutesAfterExpires, TimeUnit.SECONDS);
...
this.redis.boundValueOps(sessionKey).expire(sessionExpireInSeconds,
TimeUnit.SECONDS);
}
//設定會話內容資料(HASH)的過期時間
this.redis.boundHashOps(getSessionKey(session.getId()))
.expire(fiveMinutesAfterExpires, TimeUnit.SECONDS);

而為了達到清除的效果，會話模組啟用了定時刪除邏輯：

public void cleanExpiredSessions() {
long now = System.currentTimeMillis();
//當前刻度
long prevMin = roundDownMinute(now);
String expirationKey = getExpirationKey(prevMin);
//獲取到點過期的會話表
Set<Object> sessionsToExpire = this.redis.boundSetOps(expirationKey).members();
this.redis.delete(expirationKey);
//逐個清理
for (Object session : sessionsToExpire) {
String sessionKey = getSessionKey((String) session);
touch(sessionKey); //觸發exist命令，提醒redis進行資料清理
}
}

於是，會話清理的邏輯大致如下：

• 在寫入會話時設定超時時間，並將該會話記錄到時間槽形式的超時記錄集合中；
• 啟用定時器，定時清理屬於當前時間槽的會話資料。

這裡 存在一個疑問 ：

既然 使用了 時間槽集合 ，那麼集合中可以直接存放的是 會話ID，為什麼會多出一個"expire:{sessionID}"的鍵值。

在定時器執行清理時並沒有涉及會話資料(HASH)的處理，而僅僅是對Expire鍵做了操作，是否當前存在的BUG?

有了解的朋友歡迎留言討論

小結

分散式會話解決了分散式系統中會話共享的問題，集中式的會話管理相比會話同步(Tomcat的機制)更具優勢，而這也早已成為了常見的做法。

SpringBoot 中推薦使用Redis 作為分散式會話的解決方案，利用 spring-session 元件可以快速的完成分散式會話功能。

這裡除了提供一個樣例，還對 spring-session 的序列化、代理等機制做了梳理，希望能對讀者有所啟發。

歡迎繼續關注"美碼師的補習系列-springboot篇" ，期待更多精彩內容^-^