复习电商笔记-33-Redis功能介绍

 

Redis实现消息队列

 

 

为何Redis可以做消息队列

首先redis它的设计是用来做缓存的,但是由于它自身的某种特性(下面会详细讨论)使得它可以用来做消息队列。它有几个阻塞式的API可以使用,正是这些阻塞式的API让他有做消息队列的能力。

试想一下在”数据库解决所有问题“的思路下,不使用消息队列也是可以完成你的需求的。我们把任务全部存放在数据库然后通过不断的轮询方式来取任务处理。这种做法虽然可以完成你的任务但是做法很粗劣。但是如果你的数据库接口提供一个阻塞的方法那么就可以避免轮询操作了,你的数据库也可以用来做消息队列,只不过目前的数据库还没有这样的接口。

另外做消息队列的其他特性例如FIFO也很容易实现,只需要一个List对象从头取数据,从尾部塞数据即可实现。

redis能做消息队列得益于

他list对象blpop brpop接口以及Pub/Sub(发布/订阅)的某些接口。

他们都是阻塞版的,所以可以用来做消息队列。

 

 

耗内存

尽管redis对一些数据结构采用了压缩法存储,但是用内存量还是过高。

 

Redis实现唯一计数的3种方法

唯一计数是网站系统中十分常见的一个功能特性,例如网站需要统计每天访问的人数 unique visitor (也就是 UV)。计数问题很常见,但解决起来可能十分复杂:一是需要计数的量可能很大,比如大型的站点每天有数百万的人访问,数据量相当大;二是通常还希望扩展计数的维度,比如除了需要每天的 UV,还想知道每周或每月的 UV,这样导致计算十分复杂。

在关系数据库存储的系统里,实现唯一计数的方法就是 select count(distinct <item_id>),它十分简单,但是如果数据量很大,这个语句执行是很慢的。用关系数据库另外一个问题是插入数据性能也不高。

Redis 解决这类计数问题得心应手,相比关系数据库速度更快,消耗资源更少,甚至提供了 3 种不同的方法。

 

 

基于 set

Redis 的 set 用于保存唯一的数据集合,通过它可以快速判断某一个元素是否存在于集合中,也可以快速计算某一个集合的元素个数,另外和可以合并集合到一个新的集合中。

SISMEMBER key member        # 判断 member 是否存在

SADD key member          # 往集合中加入 member

SCARD key                   # 获取集合元素个数

基于 set 的方法简单有效,计数精确,适用面广,易于理解,它的缺点是消耗资源比较大(当然比起关系数据库是少很多的),如果元素个数很大(比如上亿的计数),消耗内存很恐怖。

 

 

基于 bit

Redis 的 bit 可以用于实现比 set 内存高度压缩的计数,它通过一个 bit 1 或 0 来存储某个元素是否存在信息。例如网站唯一访客计数,可以把 user_id 作为 bit 的偏移量 offset,设置为 1 表示有访问,使用1MB的空间就可以存放800 多万(1024*1024*8=8388608)用户的一天访问计数情况。

SETBIT key offset value  # 设置位信息

GETBIT key offset         # 获取位信息

BITCOUNT key [start end] # 计数

BITOP operation destkey key [key ...]  # 位图合并

基于 bit 的方法比起 set 空间消耗小得多,但是它要求元素能否简单映射为位偏移,适用面窄了不少,另外它消耗的空间取决于最大偏移量,和计数值无关,如果最大偏移量很大,消耗内存也相当可观。

 

 

基于 HyperLogLog

实现超大数据量精确的唯一计数都是比较困难的,但是如果只是近似的话,计算科学里有很多高效的算法,其中 HyperLogLog Counting 就是其中非常著名的算法,它可以仅仅使用 12 k左右的内存,实现上亿的唯一计数,而且误差控制在百分之一左右。

PFADD key element [element ...]  # 加入元素

PFCOUNT key [key ...]   # 计数

这种计数方法真的很神奇,我也没有彻底弄明白,有兴趣可以深入研究相关文章。

 

Redis的缺点

持久化

redis直接将数据存储到内存中,可通过两种方式持久化:定时快照和基于语句的追加。

定时快照的方法是指每隔一段时间将整个数据库的数据写到磁盘上,很明显,每次均是写全部数据,代价非常高;

而基于语句的追加方法值追踪变化的数据,这类似于MySQL的binlog方法,但追加log可能过大,同时所有操作均要重新执行一遍,回写速度慢。

 

 

耗内存

尽管redis对一些数据结构采用了压缩法存储,但是用内存量还是过高。

 

Redis应用举例

  1. 缓存(数据查询、短连接、新闻内容、商品内容等等)。(最多使用)

2)分布式集群架构中的session分离。

3)聊天室的在线好友列表。

4)任务队列。(秒杀、抢购、12306等等)(先进先出)

5)应用排行榜。(可以给每个元素设置一个打分,这样就可以排序)

6)网站访问统计。

7)数据过期处理(可以精确到毫秒)。

 

 

取最新N个数据的操作

比如典型的取你网站的最新文章,通过下面方式,我们可以将最新的5000条评论的ID放在Redis的List集合中,并将超出集合部分从数据库获取

1)使用LPUSH latest.comments<ID>命令,向list集合中插入数据

2)插入完成后再用 LTRIM latest.comments 0 5000 命令使其永远只保存最近5000个ID

 

 

短连接

这样就可以通过一个比较短的URL来访问相同的地址。它是将连接地址通过一个算法进行简化变短。http://dwz.cn/NJfGa最后面这实际就是一个key,在它的数据库中这个key就对应一个URL。当访问http://dwz.cn/NJfGa这个地址时dwz.cn中的服务对这个后面的ID进行解析,从数据库查询出真正的地址。然后重定向访问真正的链接。

 

 

聊天室好友在线列表

假设A存放你的好友,B存放所有在线的人,它们的交集就是你的在线好友。

 

 

应用排行

 

Redis配置文件以及内存清理策略

 

 

Redis配置文件

在windows平台下默认的配置文件是:redis.windows.conf,这里面配置了非常多的信息,一般配置保持默认,在一些特定的场景下可以自定义配置,常用到的配置项如下:

port 服务端口

bind 绑定ip其他ip不能访问(多个ip空格隔开)

databases 数据库数量,默认16个

daemonize设置为守护进程(linux平台)

maxmemory最大的内存大小(1MB、1GB、1m、1g)

maxmemory-policy达到内存限制后的处理策略(后面详细说明)

注意:修改后配置文件需要重启redis服务才能生效。

 

 

内存的清理策略Maxmemory-policy策略

Volatile-lru:使用LRU算法删除一个键(只对设置了生存时间的键)

Allkeys-lru:使用LRU算法删除一个键

Volatile-random:随机删除一个键(只对设置了生存时间的键)

Allkeys-random:随机删除一个键

Volatile-ttl:删除生存时间最近的一个键

Noeviction:不删除键,只返回错误

            LUR(Least Recently Used)算法:最近最少使用

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值