"过期不候"--具备生命周期的数据的技术实现方案

"过期不候"--具备生命周期的数据的技术实现方案

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

Email:

dreamzsm@gmail.com

QQ:

1295351490

时间:

2016-02

版权声明:

欢迎以学习交流为目的读者随意转载,但是请 【注明出处】

支持本文:

如果文章对您有启发,可以点击博客右下角的按钮进行 【推荐】

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯技术工程官方号的专栏

科普:QUIC 协议原理分析

本文将主要介绍 QUIC 协议产生的背景和核心特性。

2.9K10
来自专栏携程技术中心

干货 | Qunar全链路跟踪及Debug

作者简介 王克礼,去哪儿平台事业部基础架构Java开发工程师,参与开发和维护去哪儿内部中间件,包括配置中心、消息队列、日志收集及链路跟踪系统QTracer等。 ...

4366
来自专栏Golang语言社区

转--Stackful 协程库 libgo(单机100万协程)

libgo 是一个使用 C++ 编写的协作式调度的stackful协程库, 同时也是一个强大的并行编程库。 设计之初是为高并发分布式Linux服务端程序开发提供...

4539
来自专栏一英里广度一英寸深度的学习

Flume 日志收集系统 Spooldir-Source HDFS-sink

消息 Record,Source封装Event(事件)成为Record对象,并保存到Channel中,Sink拉取Record并保存到目标系统中。

1214
来自专栏杨建荣的学习笔记

通过celery提高crontab配置效率

今天在接入备份任务配置的时候也是一波三折,解决了业务元数据的问题,也逐步熟悉了业务,对于现有的备份情况会越来越有把握。

652
来自专栏解Bug之路

解Bug之路-串包Bug

笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后...

571
来自专栏QQ会员技术团队的专栏

告知你不为人知的 UDP:疑难杂症和使用

本文承接《告知你不为人知的UDP:连接性和负载均衡》文章的下文,本文主要从UDP疑难杂症、UDP协议与TCP协议高效性的对比以及UDPd的使用场合这三个方面描述...

3.7K4
来自专栏IMWeb前端团队

now.js 迷你版发布

迷你版 迷你版即0.3.0版。 0.2.0版没加新功能,只增加eadme内容和修正package.json上的一些错误。 0.3.0同样没加新功能,但是却是...

1987
来自专栏逸鹏说道

Web前端性能优化教程01:减少Http请求和使用内容分发网络

性能黄金法则 只有10%-20%的最终用户响应时间花在接收请求的HTML文档上,剩下的80%-90%时间花在HTML文档所引用的所有组件(图片,script,c...

3567
来自专栏数据和云

【新书连载】一波三折:释放内存导致数据库崩溃

编辑说明:《Oracle性能优化与诊断案例精选》出版以来,收到很多读者的来信和评论,我们会通过连载的形式将书中内容公布出来,希望书中内容能够帮助到更多的读者朋友...

3558

扫码关注云+社区