Twitter Storm源代码分析之TimeCacheMap
2013-12-20 10:25
387 查看
Twitter Storm源代码分析之TimeCacheMap
发表于 2011年 12 月 27 日 由 xumingming
作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://xumingming.sinaapp.com/395/twitter-storm-code-analysis-timecahcemap/
TimeCacheMap是Twitter
Storm里面一个类, Storm使用它来保存那些最近活跃的对象,并且可以自动删除那些已经过期的对象。这个类设计的很巧妙, 我们来看一下。
TimeCacheMap里面的数据是保存在内部变量
_bucket里面的:
帮助
ConcurrentHashMap是利用多个bucket来缩小锁的粒度, 从而实现高并发的读写。而TimeCacheMap则是利用多个bucket来使得数据清理线程占用锁的时间最小。
首先来看看TimeCacheMap的构造函数, 它的构造函数首先是生成numBuckets个空的HashMap:
帮助
帮助
expirationSecs / (numBuckets - 1)秒钟的时间去把最后一个bucket里面的数据全部都删除掉
— 这些被删除掉的数据其实就是过期的数据。(为什么不是每隔expirationSecs就来删除一次呢?我们下面会说)。这里值得注意的是:正是因为这种分成多个桶的机制, 清理线程对于
_lock的占用时间极短。只要把最后一个bucket从_buckets解下,并且向头上面添加一个新的bucket就好了:
帮助
同时对于每条过期的数据TimeCacheMap会执行我们的callback函数:
帮助
expirationSecs / (numBuckets - 1)秒的时间来检查,这样对吗?TimeCacheMap的内部有多个桶, 当你向这个TimeCacheMap里面添加数据的时候,数据总是添加到第一个桶里面去的。
帮助
numBuckets = 3, expirationSecs = 2。
我们先往里面填一条数据
{1: 1}, 这条数据被加到第一个桶里面去, 现在TimeCacheMap的状态是:
帮助
expirationSecs / (numBuckets - 1)= 2 / (3 - 1) = 1)。清理线程干掉最后一个HashMap,并且在头上添加一个新的空HashMap,
现在TimeCacheMap的状态是:
帮助
帮助
所以从
{1:1}被加入到这个TimeCacheMap到被干掉一共用了3秒,其实这个3秒就等于
帮助
Expires keys that have not been updated in the configured number of seconds.
The algorithm used will take between expirationSecs and
expirationSecs * (1 + 1 / (numBuckets-1)) to actually expire the message.
那为什么说时间是
expirationSecs到
expirationSecs * (1 + 1 / (numBuckets-1))之间呢?因为线程调度的不确定性。
相关文章推荐
- Storm配置项详解
- Twitter Storm 安装篇
- storm 删数据后上传topology无法启动?
- TowerMadness之Brewing Storm攻略 Blizzardgale
- Storm框架使用详解 搭建篇
- Twitter Storm: storm的一些常见模式
- Twitter Storm: 在生产集群上运行topology
- Twitter Storm的一些关键概念
- Twitter Storm如何保证消息不丢失
- Twitter Storm入门
- Twitter Storm: 配置开发环境
- Twitter Storm: 创建一个新的storm项目
- Twitter Storm: 本地模式简介
- Twitter Storm: Maven配置
- storm 配置项
- storm常见问题及解决方法收集【持续更新中】
- Storm集群安装部署步骤【详细版】
- Twitter Storm 安装实战
- Storm安装配置(单机版)笔记
- storm启动过程