Redis入门一：Redis实战读书笔记

Redis提供5种不同类型的数据结构，并存储键与5种不同类型的值之间的映射，各式各样的问题都可以自然地映射到这些数据结构上。通过复制、持久化和客户端分片等特性，可以将存储在内存的键值对数据持久化到硬盘，可以使用复制特性来扩展读性能，还可以使用客户端分片来扩展写性能，用户可以很方便地将Redis扩展成一个能够包含数百GB数据、每秒处理上百万次请求的系统。（分片是一种将数据划分为多个部分的方法，对数据的划分可以基于键包含的ID、基于键的散列值，或者基于以上两者的某种组合。通过对数据进行分片，用户可以将数据存储到多台机器里，也可以从多台机器里获取数据，这种方法在解决某些问题时可以获得线性级别的性能提升。）
在这里插入图片描述
Redis拥有两种不同形式的持久化方法，它们都可以用小而紧凑的格式将存储在内存中的数据写入硬盘：第一种持久化方法为时间点转储(point-in-time dump)，转储操作既可以在“指定时间段内有指定数量的写操作执行”这一条件被满足时执行，又可以通过调用两条转储到硬盘(dump-to-disk)命令中的任何一条来执行；第二种持久化方法将所有修改了的数据库的命令都写入一个只追加(append-only)文件里面，用户可以根据数据的重要程度，将只追加写入设置为从不同步、每秒同步一次或者每写入一个命令就同步一次。为了扩展Redis的读性能，并为Redis提供故障转移支持，Redis实现了主从复制特性：执行复制的从服务器会连接上主服务器，接收主服务器发送的整个数据库的初始副本；之后主服务器执行的写命令，都会被发送给所有连接着的从服务器去执行，从而实时地更新从服务器的数据集。因为从服务器包含的数据会不断地进行更新，所以客户端可以向任意一个从服务器发送读请求，以此来避免对主服务器进行集中式的访问。

Redis数据结构

STRING（字符串） LIST（列表） SET（集合） HASH（散列） ZSET（有序集合），同时在字符串的基础上演变出了位图(Bitmaps)和HyperLogLog，并且随着LBS(Location Based Service，基于位置服务)的不断发展，Redis3.2版本中加入有关GEO(地理信息定位)的功能。

在这里插入图片描述

Redis中的字符串

在这里插入图片描述

set、get和del的使用示例：

字符串类型的值实际可以是字符串（简单的字符串、复杂的字符串（例如JSON、XML）、数字（整数、浮点数））、甚至是二进制（图片、音频、视频）但是值最大不能超过512MB。

在这里插入图片描述

Redis中的列表

在这里插入图片描述
LPUSH和RPUSH命令分别用于将元素推入列表的左端(left end)和右端(right end)；LPOP和RPOP命令分别用于从列表的左端和右端弹出元素；LINDEX命令用于获取列表在给定位置上的一个元素；LRANGE命令用于获取列表在给定范围上的所有元素。
在这里插入图片描述

Redis中的集合

在这里插入图片描述
列表可以存储多个相同的字符串，而集合则通过使用散列表来保证自己存储的每个字符串都是各不相同的（这些散列表只有键，但没有与键相关联的值）。因为Redis的集合使用无序方式存储元素，所以用户不能像使用列表那样，将元素推入集合的某一端，或者从集合的某一端弹出元素。不过用户可以使用SADD命令将元素添加到集合，或者使用SREM命令从集合里面移除元素。另外还可以通过SISMEMBER命令快速地检查一个元素是否已经存在于集合中，或者使用SMEMBERS命令获取集合包含的所有元素。
在这里插入图片描述

Redis中的散列

在这里插入图片描述
Redis的散列可以存储多个键值对之间的映射。和字符串一样，散列存储的值既可以是字符串又可以是数字值，并且用户同样可以对散列存储的数字值执行自增操作或自减操作。

Redis中的有序集合

有序集合和散列一样，都用于存储键值对：有序集合的键被称为成员(member)，每个成员都是各不相同的；有序集合的值称为分值(score)，分值必须为浮点数。有序集合是Redis里面唯一一个既可以根据成员访问元素（这一点和散列一样），又可以根据分值以及分值的排列顺序来访问元素的结构。
在这里插入图片描述

发布与订阅
发布与订阅（又称pub/sub）的特点是订阅者(listener)负责订阅频道(channel)，发送者(publisher)负责向频道发送二进制字符串消息(binary string message)。每当有消息被发送至给定频道时，频道的所有订阅者都会收到消息。
在这里插入图片描述

Redis有5个命令可以让用户在不被打断的情况下对多个键执行操作，它们分别是WATCH、MULTI、EXEC、UNWATCH和DISCARD。
Redis的基本事务(basic transaction)需要用到MULTI命令和EXEC命令，这种事务可以让一个客户端在不被其他客户端打断的情况下执行多个命令。在Redis里面，被MULT命令和EXEC命令包围的所有命名会一个接一个地执行，直到所有命令都执行完毕为止。当一个事务执行完毕后，Redis才会处理其他客户端的命令。要在Redis里面执行事务，首先需要执行MULTI命令，然后输入那些我们想要在事务里面执行的命令，最后再执行EXE命令。当Redis从一个客户端那里接收到MULTI命令时，Redis会将这个客户端之后发送的所有命令都放入到一个队列里面，直到这个客户端发送EXEC命令为止，然后Redis会在不被打断的情况下，一个接一个地执行存储在队列里面的命令。
在用户使用WATCH命令对键进行监视之后，直到用户执行EXEC命令的这段时间里面，如果有其他客户端抢先对任何被监视的键进行了替换、更新或删除等操作，那么当用户尝试执行EXEC命令的时候，事务将失败并返回一个错误。通过使用WATCH、MULTI/EXEC、UNWATCH/DISCARD等命令，程序可以执行某些重要操作的时候，通过确保自己正在使用的数据没有发生变化来避免数据出错。

键的过期时间：在使用Redis存储数据的时候，有些数据可能在某个时间点之后就不再有用了，用户可以使用DEL命令显式地删除这些无用数据，也可以通过Redis的过期时间(expiration)特性来让一个键在给定的时限之后自动被删除。
在这里插入图片描述
分布式锁
一般来说，在对数据进行“加锁”时，程序首先需要通过获取锁来得到对数据进行排他性访问的能力，然后才能对数据执行一系列操作，最后还要将锁释放给其他程序。Redis使用WATCH命令来代替对数据进行加锁，因为WATCH只会在数据被其他客户端抢先修改了的情况下通知执行了这个命令的客户端，而不会阻止其他客户端对数据进行修改，所以这个命令被称为乐观锁。分布式锁也有类似的首先获取锁，然后执行操作，最后释放锁动作，但这种锁既不是给同一进程中的多个线程使用，也不是给同一台机器上的多个进程使用，而是由不同机器上的不同Redis客户端进行获取和释放。

粗粒度锁和细粒度锁

Redis提供了两种不同的持久化方法来将数据存储到硬盘里。一种方法叫快照(snapshotting)，它可以将存在于某一时刻的所有数据都写入硬盘里面。另一种方法叫只追加文件(append-only file, AOF)，它会在执行写命令时，将被执行的写命令复制到硬盘里面。Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。
创建快照的办法有以下几种：
在这里插入图片描述

AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。因此，Redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。随着Redis不断运行，AOF文件的体积会不断增长，在极端情况下，体积不断增大的AOF文件甚至可能会用完硬件的所有可用空间。还有另一个问题就是，因为Redis在重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，所以如果AOF文件的体积非常大，那么还原操作执行的时间就可能会非常长。为了解决AOF文件体积不断增大的问题，用户可以向Redis发送BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重写AOF文件，使AOF文件的体积变得尽可能地小。跟快照持久化可以通过设置save选项来自动执行BGSAVE一样，AOF持久化也可以通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRITEAOF。

复制可以让其他服务器拥有一个不断地更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。关系数据库通常会使用一个主服务器(master)向多个从服务器(slave)发送更新，并使用从服务器来处理所有读请求。Redis也采用了同样的方法来实现自己的复制特性，并将其用作扩展性能的一种手段。
在这里插入图片描述

Redis不支持主主复制(master-master replication)，因为Redis允许用户在服务器启动之后使用SLAVEOF命令来设置从服务器(slaving options)，所以可能会有读者误以为可以通过将两个Redis实例互相设置为对方的主服务器来实现多主复制(multi-master replication)，甚至可能会在一个循环里面将多个实例互相设置为主服务器。遗憾的是，这种做法是不行的：被互相设置为主服务器的两个Redis实例只会持续地占用大量处理器资源并且连续不断地尝试与对方进行通信，根据客户端连接的服务器的不同，客户端的请求可能会得到不一致的数据，或者完全得不到数据。