redis各数据类型应用概述

前言

  1. redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存、亦可持久化的日志型、key-value数据库,并提供多种语言的API。
  2. 它是内存存储的数据结构服务器,可用作数据库、高速缓存和消息队列代理。
  3. 通过数据全部in-momery的方式保证高速访问,同时提供数据落地的功能,这是redis最主要的适用场景。
  4. reids内置复制、Lua脚本、LRU收回、事物以及不同级别磁盘持久化功能,同时通过redis Sentinel提供高可用,通过Redis Cluster提供自动分区。
  5. redis支持字符串、哈希表、列表、集合、有序集合、位图、hyperloglogs等数据类型。
  6. redis最为常用的数据类型:stirng、hash、list、set、sorted set、pub/sub、transactions。

String类型

  1. string类型就是简单的key-value类型,value不仅仅是string,也可以是数字。
  2. 常用命令:set、get、decr、incr、mget等。
  3. 除了提供与memcached一样的get、set、incr、decr 等操作外,redis还提供了下面的一些操作:

    (1)获取字符串长度;
    (2)往字符串append内容;
    (3)设置和获取字符串的某一段内容;
    (4)设置及获取字符串的某一位(bit);
    (5)批量设置一系列字符串的内容;

Hash类型

  1. hash特别适合用于存储对象。
  2. 常用命令:hget、hset、hgetall等。
  3. 应用场景:存储一些结构化的数据,比如用户的昵称、年龄、性别、积分等,存储一个用户信息对象数据。
  4. 我们举个简单的实例来描述下Hash的应用场景,比如我们存储一个用户信息对象数据,包含以下信息:

    (1)用户id为查找的key;
    (2)存储的value包括姓名、年龄、生日等信息
  5. 实例解析:

    (1)key是用户id,value是一个Map。
    (2)这个Map的key是成员的属性名,value是属性值;
    (3)这样对数据的修改和存取都可以直接通过其内部的Map的key(redis里称内部Map的key为field),也就是key(用户名id)+field(属性名)就可以操作对应属性数据了。
  6. 注意:

    (1)redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多,那么涉及到遍历整个Map的操作。
    (2)由于redis单线程模型的缘故,这个遍历操作可能会比较耗时,而令其他客户端的请求完全响应不到,这点需要注意。

List类型

  1. list类型实质是一个每个元素都是string类型的双向链表,这使得list既可以用作栈,也可以用作队列。
  2. list类型经常会被用于消息队列的服务,以完成多程序之间的消息交换。
  3. 常用命令:lpush、rpush、lpop、rpop、lrange等。
  4. lpush是插入到链表的左边,也就是头部;rpush是插入到链表的右边,也就是尾部;lrange(key,start,end)返回指定区间内的元素,从头部(左端)start开始到尾部(右端)区间内。
  5. 应用场景:实现最新消息排行等功能,还有消息队列。
  6. 简单消息队列举例分析:

    (1)假设一个应用程序执行lpush向链表中添加新的元素,我们通常将这样的程序称之为“生产者(producer)”;
    (2)而另外一个应用程序正在执行rpop操作从链表中取出元素,我们称这样的程序为“消费者(consumer)”;
    (3)在消费者消费消息的过程中,需要不停调用rpop查看list中是否有待处理消息。每调用一次都会发起一次链接,造成不必要的浪费。
    (4)另外,如果生产者速度大于消费者速度,消息队列长度会一直增大,时间久了会占用大量内存空间;
    (5)所以,可以使用brpop命令,这个命令只有在有元素时返回,没有则会阻塞直到超时返回null。

Set类型

  1. set类型是string类型的无序集合。
  2. set集合的概念就是一堆不重复值的组合。
  3. set元素最大可以包含(2的32次方-1)个元素。
  4. set内部实现是一个value永远为null的HashMap。
  5. set对外提供的功能与list类似是一个列表的功能,特殊之处在于set时可以自动排重的。
  6. 常用命令:sadd、spop、smembers、sunion等。
  7. 当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择。
  8. 并且set提供了判断某个成员是否在一个set集合内的重要接口,这个是list不能提供的。
  9. 利用set数据结构,可以存储一些集合性的数据,比如在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。
  10. redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能。

Zset类型

  1. 和set一样,sorted set也是stirng类型元素的集合。不同的是每个元素都会关联一个double类型的score,元素顺序由score决定。
  2. sorted set是插入有序的,即自动排序。
  3. 常用命令:zadd、zrange、zrem、zcard等。
  4. zRange(key,start,end)返回指定范围内的score从低到高顺序的所有元素;zRevRange(key,start,end)返回key对应的有序集合中指定区间的按照score从高到低的顺序的所有元素。
  5. 当你需要一个有序的并且不重复的集合列表时,那么可以选择sorted set数据结构。
  6. 应用举例:

    (1)例如存储全班同学的成绩,其集合value可以是同学的学号,而score就可以是成绩。
    (2)排行榜应用,根据得分列出topN的用户等。

pub/sub

  1. subscribe、unsubscribe和publish三个命令实现了发布与订阅泛型。
  2. 发送者(发送信息的客户端)不是直接将信息发给特定的接收者(接受信息的客户端),而是将信息发给频道(channel),然后由频道将信息转发给所有对这个频道感兴趣的订阅者。
  3. 发送者无需知道任何关于订阅者的信息,而订阅者也无需知道是哪个客户端给它发送信息,它只要关注自己感兴趣的频道即可。
  4. 发布/订阅在redis中,被设计的非常轻量级和简洁,它做到了消息的发布和订阅的基本能力;但是尚未提供关于消息持久化等各种企业级的特性。
  5. 一个redis client发布消息,其他多个redis client订阅消息,发布的消息即发即失,redis不会持久保存发布的消息;消息订阅者也只能得到订阅后的消息,通道中此前的消息无从获得。
  6. 消息发布者,即publish客户端,无需独占链接,你可以在publish消息的同时,使用同一个redis-client链接进行其他操作(如incr等);
  7. 消息订阅者,即subscribe客户端,需要独占链接,即进行subscribe期间,redis-client无法穿插其他操作。
  8. 此时client以阻塞的方式等待publish端的消息,因此subscribe需要使用单独的链接,甚至需要在额外的线程中使用。
  9. tcp默认连接时间固定,如果在这世间内sub端没有接收到pub端消息,或pub端没有消息产生,sub端的连接都会强制回收。
  10. 这就需要特殊手段解决,用定时器来模拟pub和sub之间的保活机制,定时器时间不能超过tcp最大连接时间。
  11. 一旦subscribe端断开链接,将会失去部分消息,即链接失效期间的消息将会被丢失,所以,这里需要考虑redis的list来持久化;
  12. 如果你非常关注每个消息,那么你应该基于redis做一些额外的补充工作,如果你希望订阅是持久的,那么如下设计思路可以借鉴:

    (1)subscribe端:首先向一个set集合中增加“订阅者id”,此set集合保存了“活跃订阅”者;订阅者id标记每个唯一的订阅者,此set为“活跃订阅者集合”。
    (2)subscribe端开启订阅操作,并基于redis创建一个以订阅者id为key的list数据结构,此list中存储了所有的尚未消费的消息,此list称为“订阅者消息队列”;
    (3)publish端:每发布一条消息之后,publish端都需要遍历活跃订阅者集合,并依次向每个“订阅者消息队列”尾部追加此次发布的消息;
    (4)到此为止,我们基本可以保证,发布的每一条消息,都会持久的保存在每个“订阅者消息队列”中;
    (5)subscribe端,每接收到一个订阅消息,在消费周后,必须删除自己的“订阅者消息队列”头部的一条消息;
    (6)subscribe端启动时,如果发现自己的“订阅者消息队列”中有残存记录,那么将会首先消费这些消息,然后再去订阅。
  13. 以上方法可以保证成功到达的消息必消费不丢失

transactions

  1. redis事务可以一次执行多个命令。
  2. 一个事务从开始到执行会经历三个阶段:

    (1)开始事务
    (2)命令入队
    (3)执行事务
  3. 事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序执行。
  4. 事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
  5. 单个redis命令的执行时原子性的,但redis没有在事务上增加任何维持原子性的机制,所以redis事务的执行并不是原子性的。
  6. 事务可以理解为一个打包的批量执行脚本,但批量指令并非原子化的操作,中间某条指令的失败不会导致前面已做指令的回滚,也不会造成后续的指令不做。
  7. multi、exec、discard和watch命令是redis事务的基础。
  8. multi:

    (1)multi命令用于开启一个事务,它总是返回ok。
    (2)multi命令执行之后,客户端可以继续向服务器发送任意多条命令;
    (3)这些命令不会立即被执行,而是被放到一个队列中;
    (4)当exec命令被调用时,所有队列中的命令才会被执行。
  9. exec:

    (1)exec命令负责触发并执行事务中的所有命令;
    (2)如果客户端在使用multi开启了一个事务后,却因为断线而没有成功执行exec命令,那么事务中所有的命令都不会被执行。
    (3)另一方面,如果客户端成功在开启事务之后执行exec命令,那么事务中的所有命令都会被执行。
  10. discard:

    (1)通过调用discard,客户端可以清空事务队列,并放弃执行事务。
  11. watch:

    (1)watch命令可以为redis事务提供check-and-set (CAS)行为。 
    (2)watch使得exec命令有条件的执行:事务只能在所有被监控健都没有被修改的前提下执行,如果这个前提不能满足,事务就不会执行。
    (3)如果你用watch监视来一个带过期时间的健,那么即使这个健过期了,事务仍然可以执行。
    (4)watch可以被调用多次,对健的监视从watch被执行之后就生效,直到调用exec为止。
    (5)当exec被调用时,不管事务是否被成功执行,对所有健的监视都会被取消。
    (6)当客户端断开链接时,该客户端对健的监视也会被取消。
    原文作者:繁星落眼眶
    原文地址: https://segmentfault.com/a/1190000016374634
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞