"過時不候"--具有生命週期的數據的技術實現方案

"過時不候"--具有生命週期的數據的技術實現方案

1   引言

本文能夠做爲以前的一個 原理性文章 對應的 技術實現部分 。

此處給出其上文的直達電梯：

http://www.cnblogs.com/beer/p/6029861.html

基於token的多平臺身份認證架構設計

2   數據生命週期

所謂的 「數據生命週期」 是指：爲數據設定必定的生存期限,過了這個時間後， 此數據就被刪除掉（失效）。

在進行web開發的時候,有不少需求場景是要求數據是具備必定的生命週期，好比:

• 具備必定時效的用戶登陸會話
• 邀請碼系統的時效控制
• 具備時效的二維碼/短信/郵件驗證系統
• 接口調用認證的token有效期
• 第三方受權的期限控制
• 分享內容的時效控制
• 記錄一段時間的日誌

本文將以以下兩種數據庫特性爲例子來對此功能的實現進行介紹:

• mongodb
• redis

3   mongodb

3.1   實現方法

在mongodb中有個 TTL（Time To Live 生存時間）索引 功能:

TTL索引是一種特殊索引，經過這種索引 MongoDB 會過一段時間後自動移除集合中的文檔。 這對於某些類型的信息來講是一個很理想的特性，例如: 機器生成的事件數據，日誌，會話信息等，這些數據都只須要在數據庫中保存有限時間。

• 若是你能夠設定這個生命週期是多久他只要過了這段時間以後，它就會自動刪除掉
• 刪除的週期就是一分鐘左右（和mongodb服務的負載有關），mongodb後臺會進行週期性地檢查這些索引字段

在 mongodb 中的實現方式:

db.ttl_log_session.createIndex( { "lastModifiedDate": 1 }, { expireAfterSeconds: 3600 } )

主要解釋以下:

• 對 ttl_log_session 合集創建索引
• 索引字段爲 lastModifiedDate
• 索引順序是 升序
• 有效生存週期爲 3600 秒

達到的效果:以 lastModifiedDate 時刻開始,通過 3600 秒以後,此文檔會失效被刪除掉。

3.2   過時時間精度

刪除操做的一些注意事項:

• TTL索引  不能 保證過時數據會被馬上刪除

  在文檔過時和MongoDB從數據庫中刪除文檔之間，可能會有延遲。

• 刪除過時數據的後臺任務每隔60秒運行一次

  在文檔過時以後和後臺任務運行或者結束以前，文檔會依然存在於集合中（刪除操做尚未完成）。

• 刪除操做的持續實際取決於您的 mongod 實例的負載

  在兩次後臺任務運行的間隔間，過時數據可能會繼續留在數據庫中超過60秒。

4   redis

redis是一個內存數據庫,它具有快速IO的特色。在性能上會比Mongodb進行大幅度提高。

4.1   實現方式

經過以下方式:

EXPIRE key seconds

爲給定的key設置生存時間,當key過時時（生存時間爲0）,它會被自動刪除。

以下是一些設置生存時間相關的基本操做:

redis> SET cache_page "www.google.com"
OK

redis> EXPIRE cache_page 30  # 設置過時時間爲 30 秒
(integer) 1

redis> TTL cache_page    # 查看剩餘生存時間
(integer) 23

redis> EXPIRE cache_page 30000   # 更新過時時間
(integer) 1

redis> TTL cache_page
(integer) 29996

注意事項:

• 生存時間能夠經過使用 DEL 命令來刪除整個 key 來移除，或者被 SET 和 GETSET 命令覆寫(overwrite)
• 若是使用 RENAME 對一個 key 進行更名，那麼更名後的 key 的生存時間和更名前同樣
• 將一個帶生存時間的 key 更名成另外一個帶生存時間的 another_key ，這時舊的 another_key (以及它的生存時間)會被刪除，而後舊的 key 會更名爲 another_key

4.2   過時時間精度

• 在 Redis 2.4 版本中，過時時間的延遲在  1s 以內

  就算key已通過期，但它仍是可能在過時以後一秒鐘以內被訪問到

• 在新的 Redis 2.6 之後的版本中，延遲被下降到 1ms 以內

5   小結

在進行web開發過程當中,不少場合都須要用到數據的生命週期的功能。 關於如何實現此功能時,能夠參考以下結論後再進行相應的技術選型:

本文關於 "數據生命週期" 主題的主要結論以下:

• 能夠經過在web應用層上面作一些定時任務,可是那樣的效率遠沒有直接在數據庫層作操做要效率高
• 內存數據庫（Reids）在過時時間精度上面的控制要遠比磁盤數據庫（MongoDB）要強得多,可能達到6萬倍

在進行技術選型時注意在以下幾個特性上進行比較：

1. IO速度
2. 數據持久化
3. 數據的備份和複製集
4. 數據庫對多核心的利用
5. 數據庫集羣的部署的成本和難度
6. 開發的成本和難度

最終可以得出合適本身的技術方案，實現本身系統的功能。

 

---

做者:	Harmo哈莫
做者介紹:	https://zhengwh.github.io
技術博客:	http://www.cnblogs.com/beer
Email:	dreamzsm@gmail.com
QQ:	1295351490
時間:	2016-02
版權聲明:	歡迎以學習交流爲目的讀者隨意轉載，可是請 【註明出處】
支持本文:	若是文章對您有啓發，能夠點擊博客右下角的按鈕進行 【推薦】