redis数据类型详解

- 日理万妓 2022-07-13 04:21 200阅读 0赞

原文地址: [http://www.cnblogs.com/qunshu/p/3196972.html][http_www.cnblogs.com_qunshu_p_3196972.html]

1.  MySql+Memcached 架构的问题
    
    实际 MySQL 是适合进行海量数据存储的,通过 Memcached 将热点数据加载到 cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:
    
    1.MySQL 需要不断进行拆库拆表,Memcached 也需不断跟着扩容,扩容和维护工作占据大量开发时间。  
    2.Memcached 与 MySQL 数据库数据一致性问题。  
    3.Memcached 数据命中率低或 down 机,大量访问直接穿透到 DB,MySQL 无法支撑。  
    4.跨机房 cache 同步问题。
    
    众多 NoSQL 百花齐放,如何选择
    
    最近几年,业界不断涌现出很多各种各样的 NoSQL 产品,那么如何才能正确地使用好这些产品,最大化地发挥其长处,是我们需要深入研究和思考的问题,实 际归根结底最重要的是了解这些产品的定位,并且了解到每款产品的 tradeoffs,在实际应用中做到扬长避短,总体上这些 NoSQL 主要用于解决以下几 种问题  
    1.少量数据存储,高速读写访问。此类产品通过数据全部 in-momery 的方式来保证高速访问,同时提供数据落地的功能,实际这正是 Redis 最主要的适用场景。  
    2.海量数据存储,分布式系统支持,数据一致性保证,方便的集群节点添加/删除。  
    3.这方面最具代表性的是 dynamo 和 bigtable 2 篇论文所阐述的思路。前者是一个完全无中心的设计,节点之间通过 gossip 方式传递集群信息,数据保证最终一致性,后者是一个中心化的方案设计,通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和 redo log,然后定期 compat 归并到磁盘上,将随机写优化为顺序写,提高写入性能。  
    4.Schema free,auto-sharding 等。比如目前常见的一些文档数据库都是支持 schema-free 的,直接存储 json 格式数据,并且支持 auto-sharding 等功能,比如 mongodb。
    
    面对这些不同类型的 NoSQL 产品,我们需要根据我们的业务场景选择最合适的产品。  
    Redis 最适合所有数据 in-momory 的场景,虽然 Redis 也提供持久化功能,但实际更多的是一个disk-backed 的功能,跟传统意义上 的持久化有比较大的差别,那么可能大家就会有疑问,似乎 Redis 更  
    像一个加强版的 Memcached,那么何时使用 Memcached, 何时使用 Redis 呢?  
    如果简单地比较 Redis 与 Memcached 的区别,大多数都会得到以下观点:

1 、Redis 不仅仅支持简单的 k/v 类型的数据,同时还提供 list,set,zset,hash 等数据结构的存储。  
2 、Redis 支持数据的备份,即 master-slave 模式的数据备份。  
3 、Redis 支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。

1.  Redis 常用数据类型

Redis 最为常用的数据类型主要有以下:  
• String  
• Hash  
• List  
• Set  
• Sorted set  
• pub/sub  
• Transactions  
在具体描述这几种数据类型之前,我们先通过一张图了解下 Redis 内部内存管理中是如何描述这些不同数据类型的:  
首先 Redis 内部使用一个 redisObject 对象来表示所有的 key 和 value,redisObject 最主要的信息如上图所示:  
type 代表一个 value 对象具体是何种数据类型,encoding 是不同数据类型在 redis 内部的存储方式,比如:type=string 代表 value 存储的是一个普通字符串,那么对应的 encoding 可以是 raw 或者是int,如果是 int 则代表实际 redis 内部是按数值型类存储和表示这个字符串的,当然前提是这个字符串本身可以用数值表示,比如:”123” “456”这样的字符串。  
这里需要特殊说明一下 vm 字段,只有打开了 Redis 的虚拟内存功能,此字段才会真正的分配内存,该功能默认是关闭状态的,该功能会在后面具体描述。通 过上图我们可以发现 Redis 使用 redisObject 来表示所有的 key/value 数据是比较浪费内存的,当然这些内存管理成本的付出主要也是为了 给 Redis 不同数据类型提供一个统一的管理接口,实际作者也提供了多种方法帮助我们尽量节省内存使用,我们随后会具体讨论。

1.  各种数据类型应用和实现方式

String:  
Strings 数据结构是简单的 key-value 类型, value 其实不仅是 String ,也可以是数字 .  
常用命令 : set,get,decr,incr,mget 等。  
应用场景: String 是最常用的一种数据类型,普通的 key/ value 存储都可以归为此类 . 即可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受 Redis 的定时持久化,操作日志及Replication 等功能。除了提供与 Memcached 一样的 get 、 set 、 incr 、 decr 等操作外, Redis 还提供了下面一些操作:  
获取字符串长度  
往字符串 append 内容  
设置和获取字符串的某一段内容  
设置及获取字符串的某一位( bit )  
批量设置一系列字符串的内容

实现方式: String 在 redis 内部存储默认就是一个字符串,被 redisObject 所引用,当遇到incr,decr 等操作时会转成数值型进行计算,此时 redisObject 的 encoding 字段为 int 。

• Hash  
常用命令: hget,hset,hgetall 等。  
应用场景:在 Memcached 中,我们经常将一些结构化的信息打包成 HashMap ,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而 Redis 的 Hash 结构可以使你像在数据库中 Update 一个属性一样只修改某一项属性值。  
我们简单举个实例来描述下 Hash 的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:  
用户 ID 为查找的 key ,存储的 value 用户对象包含姓名,年龄,生日等信息,如果用普通的key/value 结构来存储,主要有以下 2 种存储方式:  
第一种方式将用户 ID 作为查找 key, 把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化 / 反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入 CAS 等复杂问题。  
第二种方法是这个用户信息对象有多少成员就存成多少个 key-value 对儿,用用户 ID+ 对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户 ID 为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。  
那么 Redis 提供的 Hash 很好的解决了这个问题, Redis 的 Hash 实际是内部存储的 Value 为一个 HashMap ,并提供了直接存取这个 Map 成员的接口,如下图:也 就是说, Key 仍然是用户 ID, value 是一个 Map ,这个 Map 的 key 是成员的属性名,value 是属性值,这样对数据的修改和存取都可以直接通过其内部 Map 的 Key(Redis 里称内部 Map 的 key 为 field), 也就是通过 key( 用户 ID) + field( 属性标签 ) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。很好的解决了问题。  
这 里同时需要注意, Redis 提供了接口 (hgetall) 可以直接取到全部的属性数据 , 但是如果内部Map 的成员很多,那么涉及到遍历整个内部 Map 的操 作,由于 Redis 单线程模型的缘故,这个遍历操作可能会比较耗时,而另其它客户端的请求完全不响应,这点需要格外注意。  
实现方式:  
上 面已经说到 Redis Hash 对应 Value 内部实际就是一个 HashMap ,实际这里会有 2 种不同实现,这个 Hash 的成员比较少时 Redis 为了节省内存会采用类似一维数 组的方式来紧凑存储,而不会采用真正的 HashMap 结构,对应的 value redisObject 的 encoding 为zipmap, 当成员数量增大时会自动转成真正的 HashMap, 此时 encoding 为 ht 。

• List  
常用命令: lpush,rpush,lpop,rpop,lrange 等。  
应用场景:  
Redis list 的应用场景非常多,也是 Redis 最重要的数据结构之一,比如 twitter 的关注列表,粉丝列表等都可以用 Redis 的 list 结构来实现。Lists 就是链表,相信略有数据结构知识的人都应该能理解其结构。使用 Lists 结构,我们可以轻松地实现最新消息排行等功能。 Lists 的另一个应用就是消息队列,可以利用 Lists 的 PUSH 操作,将任务存在 Lists 中,然后工作线程再用 POP 操作将任务取  
出进行执行。 Redis 还提供了操作 Lists 中某一段的 api ,你可以直接查询,删除 Lists 中某一段的元素。  
实现方式:  
Redis list 的实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销, Redis 内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。

• Set  
常用命令:  
sadd,spop,smembers,sunion 等。  
应用场景:  
Redis set 对外提供的功能与 list 类似是一个列表的功能,特殊之处在于 set 是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时, set 是一个很好的选择,并且set 提供了判断某个成员是否在一个 set 集合内的重要接口,这个也是 list 所不能提供的。Sets 集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Sets 数据结构,可以存储一些集合性的数据,比如在微博应用中,可以将一个用户所有的关注人存 在一个集合中,将其所有粉丝存在一个集合。 Redis 还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功 能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。  
实现方式:  
set 的内部实现是一个 value 永远为 null 的 HashMap ,实际就是通过计算 hash 的方式来快速排重的,这也是 set 能提供判断一个成员是否在集合内的原因。

• Sorted Set  
常用命令:  
zadd,zrange,zrem,zcard 等  
使用场景:  
Redis sorted set 的使用场景与 set 类似,区别是 set 不是自动有序的,而 sorted set 可以通过用户额外提供一个优先级 (score) 的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,那么 可以选择 sorted set 数据结构,比如twitter 的 public timeline 可以以发表时间作为 score 来存储,这样获取时就是自动按时间排好序的。  
另外还可以用 Sorted Sets 来做带权重的队列,比如普通消息的 score 为 1 ,重要消息的score 为 2 ,然后工作线程可以选择按 score 的倒序来获取工作任务。让重要的任务优先执行。  
实现方式:Redis sorted set 的内部使用 HashMap 和跳跃表 (SkipList) 来保证数据的存储和有序,HashMap 里放的是成员到 score 的映射,而跳跃表里存放的 是所有的成员,排序依据是HashMap 里存的 score, 使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

• Pub/Sub  
Pub/Sub 从字面上理解就是发布( Publish )与订阅( Subscribe ),在 Redis 中,你可以设定对某一个 key 值进行消息发布及消息订阅,当一个 key 值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

• Transactions  
谁 说 NoSQL 都不支持事务,虽然 Redis 的 Transactions 提供的并不是严格的 ACID 的事务(比如一串用 EXEC 提交执行的命令,在执行中服 务器宕机,那么会有一部分命令执行了,剩下的没执行),但是这个 Transactions 还是提供了基本的命令打包执行的功能(在服务器不出问题的情况 下,可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行)。 Redis 还提供了一个 Watch 功能,你可以对一个 key 进行 Watch ,然后再执行 Transactions ,在这过程中,如果这个 Watched 的值进行了修改,那么这个Transactions 会发现并拒绝执行。

[http_www.cnblogs.com_qunshu_p_3196972.html]: http://www.cnblogs.com/qunshu/p/3196972.html