Redis 快速入门

简介

Redis 是一个 Key-Value 存储系统。和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string(字符串)、 list(链表)、 set(集合)和 zset(有序集合)。这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上， Redis 支持各种不同方式的排序。与 memcached 一样，为了保证效率，数据都是缓存在内存中。区别的是 Redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了 master-slave(主从)同步。

原子性：一个操作的不可以再分，操作要么执行，要么不执行。

初识 Redis

Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

数据类型

作为 Key-value 型数据库， Redis 也提供了键（Key）和键值（Value）的映射关系。但是，除了常规的数值或字符串， Redis 的键值还可以是以下形式之一：

• Lists (列表)
• Sets (集合)
• Sorted sets (有序集合)
• Hashes (哈希表)

键值的数据类型决定了该键值支持的操作。 Redis 支持诸如列表、集合或有序集合的交集、并集、查集等高级原子操作；同时，如果键值的类型是普通数字，Redis 则提供自增等原子操作。

持久化

Redis 将数据存储于内存中，或被配置为使用虚拟内存。通过两种方式可以实现数据持久化：使用截图的方式，将内存中的数据不断写入磁盘；或使用类似 MySQL 的日志方式，记录每次更新的日志。前者性能较高，但是可能会引起一定程度的数据丢失；后者相反。

主从同步

Redis 支持将数据同步到多台从库上，这种特性对提高读取性能非常有益。

性能

相比需要依赖磁盘记录每个更新的数据库，基于内存的特性无疑给 Redis 带来了非常优秀的性能。读写操作之间有显著的性能差异。

适用场合

毫无疑问， Redis 开创了一种新的数据存储思路，使用 Redis，我们不用在面对功能单调的数据库时，把精力放在如何把大象放进冰箱这样的问题上，而是利用 Redis 灵活多变的数据结构和数据操作，为不同的大象构建不同的冰箱。

下面是 Redis 适用的一些场景:

1. 取最新 N 个数据的操作 比如典型的取你网站的最新文章，通过下面方式，我们可以将最新的 5000 条评论的 ID 放在Redis 的 List 集合中，并将超出集合部分从数据库获取。 使用 LPUSH latest.comments<ID>命令，向 list 集合中插入数据 插入完成后再用 LTRIM latest.comments 0 5000 命令使其永远只保存最近 5000 个 ID
2. 排行榜应用，取 TOP N 操作 需要使用到 sorted set ，将你要排序的值设置成 sorted set 的 score(仅限支持float型 )，将具体的数据设置成相应的 value，每次只需要执行一条 ZADD 命令即可。
3. 需要精准设定过期时间的应用 比如你可以把上面说到的 sorted set 的 score 值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除 Redis 中的过期数据，你完全可以把 Redis 里这个过期时间当成是对数据库中数据的索引，用 Redis 来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。
4. 计数器应用 Redis 的命令都是原子性的，你可以轻松地利用 INCR， DECR 命令来构建计数器系统。 redis中incr、incrby、decr、decrby属于string数据结构,它们是原子性递增或递减操作。
   • incr递增1并返回递增后的结果；
   • incrby根据指定值做递增或递减操作并返回递增或递减后的结果(incrby递增或递减取决于传入值的正负)；
   • decr递减1并返回递减后的结果；
   • decrby根据指定值做递增或递减操作并返回递增或递减后的结果(decrby递增或递减取决于传入值的正负)；
5. Uniq 操作，获取某段时间所有数据排重值 这个使用 Redis 的 set 数据结构最合适了，只需要不断地将数据往 set 中扔就行了， set 集合会自动排重。
6. 实时系统，反垃圾系统 通过上面说到的 set 功能，你可以知道一个终端用户是否进行了某个操作，可以找到其操作的集合并进行分析统计对比等。
7. Pub/Sub 构建实时消息系统 Redis 的 Pub/Sub 系统可以构建实时的消息系统，比如很多用 Pub/Sub 构建的实时聊天系统的例子。
8. 构建队列系统 使用 list 可以构建队列系统，使用 sorted set 甚至可以构建有优先级的队列系统
9. 缓存 数据都是缓存在内存中，效率更高。

Redis 安装

使用 Docker 安装方式，运行下面命令：

# 安装命令
docker run -itd --name redis -p 6379:6379 redis
# 查看 Redis 运行信息
docker ps
# 连接 redis 服务
docker exec -it redis /bin/bash
redis-cli

Redis 配置

• daemonize: 默认情况下， redis 不是在后台运行的，如果需要在后台运行，把该项的值更改为 yes。
• pidfile 当 Redis 在后台运行的时候， Redis 默认会把 pid 文件放在/var/run/redis.pid，你可以配置到其他地址。当运行多个 redis 服务时，需要指定不同的 pid 文件和端口。
• bind 指定 Redis 只接收来自于该 IP 地址的请求，如果不进行设置，那么将处理所有请求，在生产环境中最好设置该项。
• port 监听端口，默认为 6379。
• timeout 设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接。
• loglevel log 等级分为 4 级，debug, verbose, notice, 和 warning。生产环境下一般开启 notice。
• logfile 配置 log 文件地址，默认使用标准输出，即打印在命令行终端的窗口上。
• databases 设置数据库的个数，可以使用 SELECT <dbid>命令来切换数据库。默认使用的数据库是 0。
• save 设置 Redis 进行数据库镜像的频率。 if(在 60 秒之内有 10000 个 keys 发生变化时){ 进行镜像备份 }else if(在 300 秒之内有 10 个 keys 发生了变化){ 进行镜像备份 }else if(在 900 秒之内有 1 个 keys 发生了变化){ 进行镜像备份 }
• rdbcompression 在进行镜像备份时，是否进行压缩。
• dbfilename 镜像备份文件的文件名。
• dir 数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为 Redis 在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中。
• slaveof 设置该数据库为其他数据库的从数据库。
• masterauth 当主数据库连接需要密码验证时，在这里指定。
• requirepass 设置客户端连接后进行任何其他指定前需要使用的密码。警告：因为 redis 速度相当快，所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行 150K 次的密码尝试，这意味着你需要指定非常非常强大的密码来防止暴力破解。
• maxclients 限制同时连接的客户数量。当连接数超过这个值时， redis 将不再接收其他连接请求，客户端尝试连接时将收到 error 信息。
• maxmemory 设置 redis 能够使用的最大内存。当内存满了的时候，如果还接收到 set 命令， redis 将先尝试剔除设置过 expire 信息的 key，而不管该 key 的过期时间还没有到达。**在删除时，将按照过期时间进行删除，最早将要被过期的 key 将最先被删除。如果带有 expire 信息的 key 都删光了，那么将返回错误。**这样， redis 将不再接收写请求，只接收 get 请求。maxmemory 的设置比较适合于把 redis 当作于类似 memcached 的缓存来使用。
• appendonly 默认情况下， redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁，如果发生诸如拉闸限电、拔插头等状况，那么将造成比较大范围的数据丢失。所以 redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。开启 append only 模式之后， redis 会把所接收到的每一次写操作请求都追加到appendonly.aof 文件中，当 redis 重新启动时，会从该文件恢复出之前的状态。但是这样会造成 appendonly.aof 文件过大，所以 redis 还支持了 BGREWRITEAOF 指令，对appendonly.aof 进行重新整理。所以我认为推荐生产环境下的做法为关闭镜像，开启appendonly.aof，同时可以选择在访问较少的时间每天对 appendonly.aof 进行重写一次。
• appendfsync 设置对 appendonly.aof 文件进行同步的频率。 always 表示每次有写操作都进行同步，everysec 表示对写操作进行累积，每秒同步一次。这个需要根据实际业务场景进行配置
• vm-enabled 是否开启虚拟内存支持。因为 redis 是一个内存数据库，而且当内存满的时候，无法接收新的写请求，所以在 redis 2.0 中，提供了虚拟内存的支持。但是需要注意的是， redis中，所有的 key 都会放在内存中，在内存不够时，只会把 value 值放入交换区。这样保证了虽然使用虚拟内存，但性能基本不受影响，同时，你需要注意的是你要把vm-max-memory 设置到足够来放下你的所有的 key
• vm-swap-file 设置虚拟内存的交换文件路径
• vm-max-memory 这里设置开启虚拟内存之后， redis 将使用的最大物理内存的大小。默认为 0， redis 将把他所有的能放到交换文件的都放到交换文件中，以尽量少的使用物理内存。在生产环境下，需要根据实际情况设置该值，最好不要使用默认的 0
• vm-page-size 设置虚拟内存的页大小，如果你的 value 值比较大，比如说你要在 value 中放置博客、新闻之类的所有文章内容，就设大一点，如果要放置的都是很小的内容，那就设小一点。
• vm-pages 设置交换文件的总的 page 数量，需要注意的是， page table 信息会放在物理内存中，每8 个 page 就会占据 RAM 中的 1 个 byte。总的虚拟内存大小 ＝ vm-page-size * vm-pages。
• vm-max-threads 设置 VM IO 同时使用的线程数量。因为在进行内存交换时，对数据有编码和解码的过程，所以尽管 IO 设备在硬件上本上不能支持很多的并发读写，但是还是如果你所保存的 vlaue 值比较大，将该值设大一些，还是能够提升性能的。
• glueoutputbuf 把小的输出缓存放在一起，以便能够在一个 TCP packet 中为客户端发送多个响应，具体原理和真实效果我不是很清楚。所以根据注释，你不是很确定的时候就设置成 yes。
• hash-max-zipmap-entries 在 redis 2.0 中引入了 hash 数据结构。当 hash 中包含超过指定元素个数并且最大的元素没有超过临界时， hash 将以一种特殊的编码方式（大大减少内存使用）来存储，这里可以设置这两个临界值
• activerehashing 开启之后， redis 将在每 100 毫秒时使用 1 毫秒的 CPU 时间来对 redis 的 hash 表进行重新 hash，可以降低内存的使用。当你的使用场景中，有非常严格的实时性需要，不能够接受 Redis 时不时的对请求有 2 毫秒的延迟的话，把这项配置为 no。如果没有这么严格的实时性要求，可以设置为 yes，以便能够尽可能快的释放内存。

简单操作数据库

• 插入数据 127.0.0.1:6379> set name Jacob OK
• 查询数据 127.0.0.1:6379> get name "Jacob"
• 删除数据 127.0.0.1:6379> del name (integer) 1 127.0.0.1:6379> del name3 (integer) 0 其中 integer 表示：被删除 key 的数量。
• 验证 key 是否存在 127.0.0.1:6379> exists name (integer) 1 127.0.0.1:6379> exists name2 (integer) 0 其中 0，代表此 key 不存在； 1 代表存在。