基于Redis bitmap实现签到功能

作者:zhanhailiang 日期:2014-12-21

需求场景

Bitmap 对于一些特定类型的计算非常有效。

假设现在我们希望记录自己网站上的用户的上线频率,比如说,计算用户A上线了多少天,用户B上

线了多少天,诸如此类,以此作为数据,从而决定让哪些用户参加beta测试等活动——这个模式可以使

用SETBIT和BITCOUNT来实现。

比如说,每当用户在某一天上线的时候,我们就使用SETBIT,以用户名作为key,将那天所代表的网站

的上线日作为offset 参数,并将这个offset 上的为设置为1。

举个例子,如果今天是网站上线的第100天,而用户(uid=10086)在今天阅览过网站,那么执行命令SETBIT sign:10086 100 1;如果明天用户(uid=10086)也继续阅览网站,那么执行命令SETBIT sign:10086 101 1,以此类推。

当要计算用户(uid=10086)总共以来的上线次数时,就使用BITCOUNT命令:执行BITCOUNT sign:10086,得出的结果就是用户(uid=10086)上线的总天数。

性能

以上线次数统计例子,即使运行10年,占用的空间也只是每个用户10*365比特位(bit),也即是每个

用户456字节。对于这种大小的数据来说,BITCOUNT的处理速度就像GET和INCR这种O(1)复杂度的

操作一样快。

如果你的bitmap数据非常大,那么可以考虑使用以下两种方法:

1. 将一个大的bitmap分散到不同的key中,作为小的bitmap来处理。使用Lua脚本可以很方便地完成这一工作。
2. 使用BITCOUNT的start和end参数,每次只对所需的部分位进行计算,将位的累积工作(accumulating)放到客户端进行,并且对结果进行缓存(caching)。

代码实现

https://github.com/billfeller/billfeller.github.io/blob/master/code/ISign.php

参考文档:

《Redis.pdf》
时间: 2024-08-05 11:16:02

基于Redis bitmap实现签到功能的相关文章

基于Redis bitmap实现开关配置功能

作者:zhanhailiang 日期:2014-12-21 bitmap api SETBIT key offset value 对key所储存的字符串值,设置或清除指定偏移量上的位(bit). 位的设置或清除取决于value参数,可以是0也可以是1. 当key不存在时,自动生成一个新的字符串值. 字符串会进行伸展(grown)以确保它可以将value保存在指定的偏移量上. 当字符串值进行伸展时,空白位置以0填充. offset参数必须大于或等于0,小于2^32(bit映射被限制在512MB之内

Sprint Boot如何基于Redis发布订阅实现异步消息系统的同步调用?

前言 在很多互联网应用系统中,请求处理异步化是提升系统性能一种常用的手段,而基于消息系统的异步处理由于具备高可靠性.高吞吐量的特点,因而在并发请求量比较高的互联网系统中被广泛应用.与此同时,这种方案也带来了调用链路处理上的问题,因为大部分应用请求都会要求同步响应实时处理结果,而由于请求的处理过程已经通过消息异步解耦,所以整个调用链路就变成了异步链路,此时请求链路的发起者如何同步拿到响应结果,就需要进行额外的系统设计考虑. 为了更清晰地理解这个问题,小码哥以最近正在做的共享单车的IOT系统为例,给

基于 Redis 构建数据服务

今天我们来聊聊如何基于redis数据库扩展数据服务,如何实现分片(sharding)以及高可用(high availability). 分布式系统不存在完美的设计,处处都体现了trade off. 因此我们在开始正文前,需要确定后续的讨论原则,仍然以分布式系统设计中的CAP原则为例.由于主角是redis,那性能表现肯定是最高设计目标,之后讨论过程中的所有抉择,都会优先考虑CAP中的AP性质. 两个点按顺序来,先看分片. 何谓分片?简单来说,就是对单机redis做水平扩展. 当然,做游戏的同学可能

Redis Geo: Redis新增位置查询功能

转载于:http://www.itxuexiwang.com/a/shujukujishu/redis/2016/0216/144.html 移动互联网增进了人与人之间的联系,其中基于位置信息的服务(Location Based Service,LBS)起到很重要的促进作用.在移动互联网的大环境下,每个手机都变成了一个位置追踪设备,为人们提供了非常丰富的位置服务.无论是附近的人,还是摇一摇等耳熟能详的应用都需要LBS在后台的支撑.但是,目前位置信息的使用过程中存在诸多挑战如相邻计算不准确等.由于

基于Redis的三种分布式爬虫策略

前言: 爬虫是偏IO型的任务,分布式爬虫的实现难度比分布式计算和分布式存储简单得多. 个人以为分布式爬虫需要考虑的点主要有以下几个: 爬虫任务的统一调度 爬虫任务的统一去重 存储问题 速度问题 足够"健壮"的情况下实现起来越简单/方便越好 最好支持"断点续爬"功能 Python分布式爬虫比较常用的应该是scrapy框架加上Redis内存数据库,中间的调度任务等用scrapy-redis模块实现. 此处简单介绍一下基于Redis的三种分布式策略,其实它们之间还是很相似

基于Redis的分布式锁到底安全吗(上)?

网上有关Redis分布式锁的文章可谓多如牛毛了,不信的话你可以拿关键词"Redis 分布式锁"随便到哪个搜索引擎上去搜索一下就知道了.这些文章的思路大体相近,给出的实现算法也看似合乎逻辑,但当我们着手去实现它们的时候,却发现如果你越是仔细推敲,疑虑也就越来越多. 实际上,大概在一年以前,关于Redis分布式锁的安全性问题,在分布式系统专家Martin Kleppmann和Redis的作者antirez之间就发生过一场争论.由于对这个问题一直以来比较关注,所以我前些日子仔细阅读了与这场争

转:Redis Geo: Redis新增位置查询功能

原文来自于:http://www.infoq.com/cn/news/2015/07/redis-geo 移动互联网增进了人与人之间的联系,其中基于位置信息的服务(Location Based Service,LBS)起到很重要的促进作用.在移动互联网的大环境下,每个手机都变成了一个位置追踪设备,为人们提供了非常丰富的位置服务.无论是附近的人,还是摇一摇等耳熟能详的应用都需要LBS在后台的支撑.但是,目前位置信息的使用过程中存在诸多挑战如相邻计算不准确等.由于经常面对海量数据请求,通常位置服务的

基于Redis的在线用户列表解决方案

前言: 由于项目需求,需要在集群环境下实现在线用户列表的功能,并依靠在线列表实现用户单一登陆(同一账户只能一处登陆)功能: 在单机环境下,在线列表的实现方案可以采用SessionListener来完成,当有Session创建和销毁的时候做相应的操作即可完成功能及将相应的Session的引用存放于内存中,由于持有了所有的Session的引用,故可以方便的实现用户单一登陆的功能(比如在第二次登陆的时候使之前登陆的账户所在的Session失效). 而在集群环境下,由于用户的请求可能分布在不同的Web服

基于redis排行榜的实战总结

前言: 之前写过排行榜的设计和实现, 不同需求其背后的架构和设计模型也不一样. 平台差异, 有的立足于游戏平台, 为多个应用提供服务, 有的仅限于单个游戏.排名范围差异, 有的面向全局排名, 有的只做朋友圈排名. 实时性差异, 离线统计有之, 实时排名更常见. 不管如何, 本文将结合之前写的网页闯关游戏, 来具体阐述基于redis排行榜的实战过程. 相关文章系列: 之前写过两篇关于排行榜的文章, 不过那是针对游戏平台(类似微信, 手Q等)而言的. 每个用户都有自己的排行榜, 不是全局性的. •