做运维需要了解哪些Redis数据库知识?Redis管理实战

    /    2018-11-22

1. 基本数据类型

2. 全局Key操作

3. String(字符串)

string是redis最基本的类型,一个key对应一个value。一个键最大能存储512MB。

应用场景

常规计数:微博数,粉丝数等。

4. Hash(字典)

我们可以将Redis中的Hashes类型看成具有String Key和String Value的map容器。

所以该类型非常适合于存储值对象的信息。如Username、Password和Age等。如果Hash中包含很少的字段,那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储995701749 个键值对。

应用场景:存储部分变更的数据,如用户信息等。

5. LIST(列表)

List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样,我们可以在其头部(left)和尾部(right)添加新的元素。在插入时,如果该键并不存在,Redis将为该键创建一个新的链表。与此相反,如果链表中所有的元素均被移除,那么该键也将会被从数据库中删除。

List中可以包含的最大元素数量是4294967295。

应用场景:消息队列系统,比如sina微博。

在Redis中我们的最新微博ID使用了常驻缓存,这是一直更新的。但是做了限制不能超过5000个ID,因此获取ID的函数会一直询问Redis。只有在start/count参数超出了这个范围的时候,才需要去访问数据库。

系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

6. SET(集合)

Set类型看作为没有排序的字符集合。Set可包含的最大元素数量是4294967295。如果多次添加相同元素,Set中将仅保留该元素的一份拷贝。

应用场景:

在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。

Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

7. SortedSet(有序集合)

Sorted-Sets中的每一个成员都会有一个分数(score)与之关联,Redis正是通过分数来为集合中的成员进行从小到大的排序。成员是唯一的,但是分数(score)却是可以重复的。

集合是通过哈希表实现的,所以添加,删除,查找的复杂度都是O(1)。集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

应用场景:

排行榜应用,取TOP N操作这个需求与上面需求的不同之处在于,前面操作以时间为权重,这个是以某个条件为权重,比如按顶的次数排序,这时候就需要我们的sorted set出马了,将你要排序的值设置成sorted set的score,将具体的数据设置成相应的value,每次只需要执行一条ZADD命令即可。

8. 消息模式

Redis发布消息通常有两种模式:

• 队列模式(queuing)

• 发布-订阅模式(publish-subscribe)

任务队列:顾名思义,就是“传递消息的队列”。与任务队列进行交互的实体有两类,一类是生产者(producer),另一类则是消费者(consumer)。生产者将需要处理的任务放入任务队列中,而消费者则不断地从任务独立中读入任务信息并执行。

任务队列的好处:

• 松耦合。

生产者和消费者只需按照约定的任务描述格式,进行编写代码。

• 易于扩展。

多消费者模式下,消费者可以分布在多个不同的服务器中,由此降低单台服务器的负载。

9. Redis 发布订阅

其实从Pub/Sub的机制来看,它更像是一个广播系统,多个Subscriber可以订阅多个Channel,多个Publisher可以往多个Channel中发布消息。可以这么简单的理解:

• Subscriber:收音机,可以收到多个频道,并以队列方式显示

• Publisher:电台,可以往不同的FM频道中发消息

• Channel:不同频率的FM频道

1) 发布订阅模型

一个Publisher,多个Subscriber模型

如下图所示,可以作为消息队列或者消息管道。

主要应用:通知、公告。

多个Publisher,一个Subscriber模型

可以将PubSub做成独立的HTTP接口,各应用程序作为Publisher向Channel中发送消息,Subscriber端收到消息后执行相应的业务逻辑,比如写数据库,显示等等。

主要应用:排行榜、投票、计数。

多个Publisher,多个Subscriber模型

故名思议,就是可以向不同的Channel中发送消息,由不同的Subscriber接收。

主要应用:群聊、聊天。

2) 实践发布订阅

发布订阅实践命令

注意:使用发布订阅模式实现的消息队列,当有客户端订阅channel后只能收到后续发布到该频道的消息,之前发送的不会缓存,必须Provider和Consumer同时在线。

3) 消息队列系统对比

客户端在执行订阅命令之后进入了订阅状态,只能接收SUBSCRIBE 、PSUBSCRIBE、UNSUBSCRIBE、PUNSUBSCRIBE 四个命令。

开启的订阅客户端,无法收到该频道之前的消息,因为 Redis 不会对发布的消息进行持久化。

和很多专业的消息队列系统(例如Kafka、RocketMQ)相比,Redis的发布订阅略显粗糙,例如无法实现消息堆积和回溯。但胜在足够简单,如果当前场景可以容忍的这些缺点,也不失为一个不错的选择。

10. Redis事务管理

redis中的事务跟关系型数据库中的事务是一个相似的概念,但是有不同之处。

关系型数据库事务执行失败后面的sql语句不在执行,而redis中的一条命令执行失败,其余的命令照常执行。

redis中开启一个事务是使用multi,相当于begin\start transaction,exec提交事务,discard取消队列命令(非回滚操作)。

redis与mysql对比

1) Redis 事务命令

事务执行举例

ZADD salary 2000 user1
ZADD salary 3000 user2
ZRANGE salary 0 -1 WITHSCORES
MULTI
ZINCRBY salary 1000 user1
ZINCRBY salary -1000 user2
EXEC

2) Redis中事务中的锁机制

举例:我正在买票Ticket -1,money -100

而票只有1张,如果在我multi之后,和exec之前,票被别人买了,即ticket变成0了。

我该如何观察这种情景,并不再提交:

悲观的想法:

世界充满危险,肯定有人和我抢,给 ticket上锁,只有我能操作。[悲观锁]

乐观的想法:

没有那么人和我抢,因此,我只需要注意,有没有人更改ticket的值就可以了。[乐观锁]

Redis的事务中,启用的是乐观锁,只负责监测key没有被改动。

3) Redis服务管理命令

11. redis慢日志查询

Slow log 是 Redis 用来记录查询执行时间的日志系统。

slow log 保存在内存里面,读写速度非常快

可以通过改写 redis.conf 文件或者用 CONFIG GET 和 CONFIG SET 命令对它们动态地进行修改

slowlog-log-slower-than 10000 超过多少微秒
CONFIG SET slowlog-log-slower-than 100
CONFIG SET slowlog-max-len 1000 保存多少条慢日志
CONFIG GET slow*
SLOWLOG GET
SLOWLOG RESET

(4)

分享至