展开

关键词

Redis 如何存储上亿级别用户状态?

1 ---- 前段时间,在网上看到一道面试题: 如何用redis存储统计1亿用户一年的登陆情况,并快速检索任意时间窗口内的活跃用户数量。 觉得很有意思,就仔细想了下 。 用来存储一些对核心业务弱影响的用户状态信息还是非常不错的。 对于这题,有2个重要的点需要考虑: 1.如何用合适的数据类型来存储1亿用户的数据,用普通的字符串来存储肯定不行。 因为bitmap的每一位只占据1bit的空间 ,所以利用这个特性我们可以把每一天作为key,value为1亿用户的活跃度状态。假设一个用户一天内只要登录了一次就算活跃。 把用户Id作为偏移量(offset)。这样我们一个key就可以存储1亿用户的活跃状态。 ? 我们再来算下,这样一个位图结构的值对象占据多少空间。每一个位是1bit,一亿用户就是一亿bit。 O(1)] 如果要统计某一天的所有的活跃用户数,使用bitcount命令,bitcount可以统计1的个数,也就是活跃用户数: bitcount 2019-01-01 [时间复杂度为O(N)] 如果要统计某一段时间内的活跃用户

50540

Redis 如何存储上亿级别用户状态?

前段时间,在网上看到一道面试题: 如何用redis存储统计1亿用户一年的登陆情况,并快速检索任意时间窗口内的活跃用户数量。 觉得很有意思,就仔细想了下 。并做了一系列实验,自己模拟了下 。 用来存储一些对核心业务弱影响的用户状态信息还是非常不错的。 对于这题,有2个重要的点需要考虑: 1.如何用合适的数据类型来存储1亿用户的数据,用普通的字符串来存储肯定不行。 因为bitmap的每一位只占据1bit的空间 ,所以利用这个特性我们可以把每一天作为key,value为1亿用户的活跃度状态。假设一个用户一天内只要登录了一次就算活跃。 把用户Id作为偏移量(offset)。这样我们一个key就可以存储1亿用户的活跃状态。 我们再来算下,这样一个位图结构的值对象占据多少空间。每一个位是1bit,一亿用户就是一亿bit。 O(1)] 如果要统计某一天的所有的活跃用户数,使用bitcount命令,bitcount可以统计1的个数,也就是活跃用户数: bitcount 2019-01-01 [时间复杂度为O(N)] 如果要统计某一段时间内的活跃用户

12220
  • 广告
    关闭

    腾讯云618采购季来袭!

    腾讯云618采购季:2核2G云服务器爆品秒杀低至18元!云产品首单0.8折起,企业用户购买域名1元起,还可一键领取6188元代金券,购后抽奖,iPhone、iPad等你拿!

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Redis 如何存储上亿级别用户状态?

    1 ---- 前段时间,在网上看到一道面试题: 如何用redis存储统计1亿用户一年的登陆情况,并快速检索任意时间窗口内的活跃用户数量。 觉得很有意思,就仔细想了下 。 用来存储一些对核心业务弱影响的用户状态信息还是非常不错的。 对于这题,有2个重要的点需要考虑: 1.如何用合适的数据类型来存储1亿用户的数据,用普通的字符串来存储肯定不行。 因为bitmap的每一位只占据1bit的空间 ,所以利用这个特性我们可以把每一天作为key,value为1亿用户的活跃度状态。假设一个用户一天内只要登录了一次就算活跃。 把用户Id作为偏移量(offset)。这样我们一个key就可以存储1亿用户的活跃状态。 ? 我们再来算下,这样一个位图结构的值对象占据多少空间。每一个位是1bit,一亿用户就是一亿bit。 O(1)] 如果要统计某一天的所有的活跃用户数,使用bitcount命令,bitcount可以统计1的个数,也就是活跃用户数: bitcount 2019-01-01 [时间复杂度为O(N)] 如果要统计某一段时间内的活跃用户

    24830

    引用级别

    引用级别 意义:用来标记对角是否可以被回收 级别: 强 > 软 > 弱 > 虚 1.强引用 即一般普通的引用。 返回时否被 GC 回收的标记 } 这时候 softReference 是对obj的一个软引用,通过sf.get()方法可以取到这个对象,当然,当这个对象被标记为需要回收的对象时,则返回null; 软引用主要用户实现类似缓存的功能

    21250

    启动级别

    multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) 0 系统停止 1 单用户系统 ,不需要登陆 2 多用户系统但不支持NFS,命令行模式登陆 3 完整多用户模式,命令行模式登陆 4 未用 5 X11图形模式,图形模式登陆 6 重新启动系统 启动对应级别下的服务如: init 3 级别

    39880

    Java对象级别与类级别的同步锁

    对象级别的锁可以防止多个线程在运行时同时进入当前(或某一个)实例化对象的 synchronized代码块中。 1. 对象级别的同步锁 对象级别的同步锁:当我们想要在多线程环境下同步执行一个非静态方法或非静态代码块时,在类的方法或代码块加上synchronized关键字,可以保证对象实例级别数据的线程安全。 (比较后文的类级别的同步锁,回头来理解这句话) 对象级别的加锁的代码如下,如:在方法上加锁,锁对象为当前类的实例化对象 public class DemoClass{ public synchronized 类级别的同步锁 类级别的锁可以防止多个线程在运行时进入该类所有实例化对象的 "synchronized块中。 为了保障静态数据线程安全,应该使用类级别的锁定。我们知道static关键字将方法的数据关联到类的级别上,所以在静态方法上使用锁。

    21220

    事物隔离级别

    事务隔离级别: @Transactional(isolation = Isolation.READ_UNCOMMITTED):读取未提交数据(会出现脏读, 不可重复读) 基本不使用 @Transactional Isolation.SERIALIZABLE):串行化 1.READ UNCIMMITTED(未提交读) 事务中的修改,即使没有提交,其他事务也可以看得到,比如说上面的两步这种现象就叫做脏读,这种隔离级别会引起很多问题 2.READ COMMITTED(提交读) 大多数数据库系统的默认隔离级别是READ COMMITTED,这种隔离级别就是一个事务的开始,只能看到已经完成的事务的结果,正在执行的,是无法被其他事务看到的 这种级别会出现读取旧数据的现象 例子:还是小明小华销售员,余票3张,A来小华那里请求3张订票单,小华接受订单,要卖出3张票,上面的销售步骤执行中的时候,B也来小明那里买票,由于小华的销售事务执行到一半, ,由于他大量加上锁,导致大量的请求超时,因此性能会比较底下,再特别需要数据一致性且并发量不需要那么大的时候才可能考虑这个隔离级别 脏读 :所谓的脏读,其实就是读到了别的事务回滚前的脏数据。

    19700

    python日志级别

    logging.warning(‘This is warning message’) ”’ 想关参数介绍: logging.basicConfig函数各参数: level总共分5个级别 :debug < info< warning< error< critical 日志信息低于设置的级别时,不予显示:如此处为最低级别debug,所以显示所以信息 filename: 指定日志文件名 显示的条目可以是以下内容: %(levelname):日志级别的名字格式 %(levelno)s:日志级别的数字表示 %(name)s:日志名字 %(funcName

    19530

    WPF 渲染级别

    很少人会知道 WPF 也可以知道当前的显卡能支持的渲染级别。 根据显卡的不同,包括显存、纹理等的支持是否打到要求,指定渲染级别。 使用 System.Windows.Media.RenderCapability 可以拿到 WPF 的渲染级别 var renderingTier = System.Windows.Media.RenderCapability.Tier >> 16; 因为直接拿到 RenderCapability.Tier 是不能用的,参见WPF 渲染级别 (Tier) 通过 renderingTier 的值就可以判断当前显卡渲染级别 0 没有显卡加速功能

    44820

    MySQL隔离级别

    MySQL事务隔离级别 事务隔离级别 脏读 不可重复读 幻读 读未提交(read-uncommitted) 是 是 是 不可重复读(read-committed) 否 是 是 可重复读(repeatable-read 但是在应用程序中,我们得代码可能会把18700提交给用户了,如果你一定要避免这情况小概率状况的发生,那么就要采取下面要介绍的事务隔离级别“串行化” mysql> select sum(balance) serializable时会锁表,因此不会出现幻读的情况,这种隔离级别并发性极低,开发中很少会用到。 事务隔离级别为读提交时,写数据只会锁住相应的行 事务隔离级别为可重复读时,如果有索引(包括主键索引)的时候,以索引列为条件更新数据,会存在间隙锁间隙锁、行锁、下一键锁的问题,从而锁住一些行;如果没有索引 事务隔离级别为串行化时,读写数据都会锁住整张表 隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大,鱼和熊掌不可兼得啊。

    53410

    PHP爬虫源码:百万级别知乎用户数据爬取与分析

    本程序是抓取知乎的用户数据,要能访问用户个人页面,需要用户登录后的才能访问。 当我们在浏览器的页面中点击一个用户头像链接进入用户个人中心页面的时候,之所以能够看到用户的信息,是因为在点击链接的时候,浏览器帮你将本地的cookie带上一齐提交到新的页面,所以你就能进入到用户的个人中心页面 可以看到,用户关注了的页面的url是: ? 不同的用户的这个url几乎是一样的,不同的地方就在于用户名那里。 因此就想到了使用Redis缓存来保存已经处理好的用户以及待抓取的用户。 这样每次执行完的时候都把用户push到一个already_request_queue队列中,把待抓取的用户(即每个用户的关注者和关注了的用户列表)push到request_queue里面,然后每次执行前都从

    1.7K81

    linu运行级别

    一.介绍 0:关机 1:单用户[找回丢失密码] 2:多用户状态[无网络服务] 3:多用户状态[有网络服务] 4:保留级别 5:图形界面 6:系统重启 二.命令行运行级别 比如说关机 init 0 三.修改默认运行级别 vim /etc/inittab 修改最后一行: id:5:initdefault: 四.引导界面修改运行级别 ?

    14410

    GCC 优化级别

    1. gcc中指定优化级别的参数有:-O0、-O1、-O2、-O3、-Og、-Os、-Ofast。 2. 在编译时,如果没有指定上面的任何优化参数,则默认为 -O0,即没有优化。 3.

    4.2K10

    隔离级别、SI 和 SSIACID隔离级别Snapshot IsolationSerializable Snapshot Isolation

    权衡安全和性能,数据库一般会有多个隔离级别。 隔离级别 SQL 标准里定义了四个隔离级别: 读未提交(Read Uncommitted):会出现脏读(Dirty Read)—— 一个事务会读到另一个事务的中间状态。 SQL 标准定义的的这四个隔离级别,只适用于基于锁的事务并发控制。 后来有人写了一篇论文 A Critique of ANSI SQL Isolation Levels 来批判 SQL 标准对隔离级别的定义,并在论文里提到了一种新的隔离级别 —— 快照隔离(Snapshot 虽然大部分应用场景下,Snapshot Isolation 可以很好地运行,但是 Snapshot Isolation 依然没有达到可串行化的隔离级别,因为它会出现写偏序(write skew)。

    1.4K40

    事务的隔离级别

    事务隔离级别 SQL 标准定义了四个隔离级别: READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读; READ-COMMITTED ,完全服从 ACID 的隔离级别。 × MySQL 的默认隔离级别 MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读)。 可以说,InnoDB 存储引擎默认支持的隔离级别 REPEATABLE-READ(可重读) ,已经可以完全保证事务的隔离性要求,即达到了 SQL 标准的 SERIALIZABLE(可串行化) 隔离级别。 隔离级别越低,事务请求的锁越少,所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):,但 InnoDB 存储引擎默认使用的 REPEATABLE-READ(可重读)并不会有任何性能损失

    27040

    Bug 级别定义标准

    缺陷种类 缺陷级别 详细说明 功能缺陷 Urgent (V级) 1.操作系统无法正常使用,死机,出现致命错误 2.数据丢失 3.被测试系统频繁崩溃,程序出错,使功能不能继续使用 4.性能与需求不一致

    96420

    事务隔离级别总结

    很多时候我们有些业务对事务的要求是不一样的,所以数据库中设计了四 种隔离级别,供用户基于业务进行选择。 注:MySQL中查看、设置事务隔离级别: #查看事务隔离级别 SELECT @@tx_isolation; #设置隔离级别为read-uncommitted set tx_isolation='read-uncommitted 不可重复读与幻读在概念上容易混淆,其不同在于:不可重复读侧重的是另一个事务对数据的修改,是行级别的操作。而幻读侧重的是另一个事务对数据的新增或删除,是整个表级别的操作。 采用不同的事务隔离级别,可解决不同的问题,总结如下: 隔离级别 脏读 不可重复读 幻读 read uncommitted 不可解决 不可解决 不可解决 read committed 可解决 不可解决 不可解决 repeatable read 可解决 可解决 不可解决 serializable 可解决 可解决 可解决 可以看到,隔离级别越高,事务的安全性就越高,但是对性能的影响也越大,实际应用中应根据不同业务场景选择不同的隔离级别

    33430

    mysql事务隔离级别

    1、并发事务带来的问题 在典型的应用程序中,多个事务并发运行,经常会操作相同的数据来完成各自的任务(多个用户对同一数据进行操作)。并发虽然是必须的,但可能会导致以下的问题。 MySQL的默认隔离级别是? 为了解决事务隔离性的问题,数据库一般会有不同的隔离级别来解决相应的读写影响。 SQL 标准定义了四个隔离级别: READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。 ,完全服从ACID的隔离级别。 所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读 需要注意的是,这是标准事务隔离级别下的定义。

    11910

    linux之运行级别

    0:关机 1:单用户:找回丢失密码 2:多用户无网络服务 3:多用户有网络服务 4:保留 5:图形界面 6:重启 常用的运行级别是3和5.。

    24020

    gulp入门(小白级别

    在该项目路径下,我们独立安装gulp:npm install gulp 。此时会生成一个 node_modules 文件夹和一个 package-lock.j...

    26220

    相关产品

    • 智能数据分析

      智能数据分析

      智能数据分析( IDA)基于安全、低成本、高可靠、可弹性的云端大数据架构,帮助企业客户实现从数据采集、建模、挖掘、效果分析、用户标签画像到自动化营销等全场景的数据服务,快速实现数据驱动业务增长的目标。

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      扫码关注云+社区

      领取腾讯云代金券