Redis学习手册，从入门到精通(附赠redis学习电子书)

 

前言:

在过去的几年中，NoSQL 数据库一度成为高并发、海量数据存储解决方案的代名词，与之相应的产品也呈现出雨后春笋般的生机。然而在众多产品中能够脱颖而出的却屈指可数，如 RedisMongoDB、BerkeleyDB 和 CouchDB 等。

 

 

 

Redis的优势

1). 和其他 NoSQL 产品相比，Redis 的易用性极高，因此对于那些有类似产品使用经验的开发者来说，一两天，甚至是几个小时之后就可以利用 Redis 来搭建自己的平台了。

2). 在解决了很多通用性问题的同时，也为一些个性化问题提供了相关的解决方案，如索引引擎、统计排名、消息队列服务等。

 

目前版本中redis存在的主要问题

1). 在官方版本中没有提供 Windows 平台的支持，已发布的正式版本中只是支持类 Unix 和MacOSX 台。

2). 没有提供集群的支持，然而据官网所述，预计在 2.6 版本中会加入该特征。

3). Publication/Subscription 功能中，如果 master 宕机，slave 无法自动提升为 master。

 

Redis 学习手册(String 数据类型)

概述

字符串类型是 Redis 中最为基础的数据存储类型，它在 Redis 中是二进制安全的，这便意味着该类型可以接受任何格式的数据，如 JPEG 图像数据或 Json 对象描述信息等。在 Redis 中字符串类型Value最多可以容纳的数据长度是 512M。

 

 

 

 

由于内容过多，文末会分享出此电子书，需要的自取

 

Redis 学习手册(List 数据类型)

概述

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

从元素插入和删除的效率视角来看，如果我们是在链表的两头插入或删除元素，这将会是非常高效的操作，即使链表中已经存储了百万条记录，该操作也可以在常量时间内完成。然而需要说明的是，如果元素插入或删除操作是作用于链表中间，那将会是非常低效的。相信对于有良好数据结构基础的开发者而言，这一点并不难理解

 

 

 

 

 

 

Redis 学习手册(Set 数据类型)

概述

在 Redis 中，我们可以将 Set 类型看作为没有排序的字符集合，和 List 类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为 O(1)，即常量时间内完成次操作。Set 可包含的最大元素数量是 4294967295。和 List 类型不同的是，Set 集合中不允许出现重复的元素，这一点和 C++标准库中的 set 容器是完全相同的。换句话说，如果多次添加相同元素，Set 中将仅保留该元素的一份拷贝。和 List 类型相比，Set

类型在功能上还存在着一个非常重要的特性，即在服务器端完成多个 Sets 之间的聚合计算操作，如unions、intersections 和 differences。由于这些操作均在服务端完成，因此效率极高，而且也节省了大量的网络IO 开销。

 

 

Redis 学习手册(Hashes 数据类型)

概述

我们可以将 Redis 中的 Hashes 类型看成具有 String Key 和 String Value 的 map 容器。所以该类型非常适合于存储值对象的信息。如 Username、Password 和 Age 等。如果 Hash 中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个 Hash 可以存储 4294967295 个键值对。

 

 

 

 

Redis 学习手册(Sorted-Sets 数据类型)

概述

Sorted-Sets 和 Sets 类型极为相似，它们都是字符串的集合，都不允许重复的成员出现在一个 Set中。它们之间的主要差别是 Sorted-Sets 中的每一个成员都会有一个分数(score)与之关联，Redis 正是通过分数来为集合中的成员进行从小到大的排序。然而需要额外指出的是，尽管 Sorted-Sets 中的成员必须是唯一的，但是分数(score)却是可以重复的。

在 Sorted-Set 中添加、删除或更新一个成员都是非常快速的操作，其时间复杂度为集合中成员数量的对数。由于 Sorted-Sets 中的成员在集合中的位置是有序的，因此，即便是访问位于集合中部的成员也仍然是非常高效的。事实上，Redis 所具有的这一特征在很多其它类型的数据库中是很难实现的，换句话说，在该点上要想达到和 Redis 同样的高效，在其它数据库中进行建模是非常困难的

 

 

 

 

 

总结:

由于篇幅限制剩下的一些知识点我就不一一列举出来了，需要这份电子书的朋友自取哦

领取方式，关注我的供种号 Java周某人 即可领取