Redis相关

单节点安装

安装依赖  yum -y install gcc gcc-c++ tcl

下载tar包，解压，编译：make MALLOC=libc

安装：make PREFIX=/opt/redis/ install （想要安装的目录）

启动服务：./src/redis-server redis.conf

启动客户端：./src/redis-cli

 

因为常用命令都在 ./src 目录下，所有将该目录配置到环境变量中

export  REDIS_HOME=

修改配置文件redis.conf

 

 

Redis多库与redis实例

注意：Redis支持多个数据库，并且每个数据库的数据是隔离的不能共享，并且基于单机才有，如果是集群就没有数据库的概念。

Redis是一个字典结构的存储服务器，而实际上一个Redis实例提供了多个用来存储数据的字典，客户端可以指定将数据存储在哪个字典中。这与我们熟知的在一个关系数据库实例中可以创建多个数据库类似，所以可以将其中的每个字典都理解成一个独立的数据库。

 

每个数据库对外都是一个从0开始的递增数字命名，Redis默认支持16个数据库（可以通过配置文件支持更多，无上限），可以通过配置databases来修改这一数字。客户端与Redis建立连接后会自动选择0号数据库，不过可以随时使用SELECT命令更换数据库；

 

然而这些以数字命名的数据库又与我们理解的数据库有所区别。首先Redis不支持自定义数据库的名字，每个数据库都以编号命名，开发者必须自己记录哪些数据库存储了哪些数据。另外Redis也不支持为每个数据库设置不同的访问密码，所以一个客户端要么可以访问全部数据库，要么连一个数据库也没有权限访问。最重要的一点是多个数据库之间并不是完全隔离的，比如FLUSHALL命令可以清空一个Redis实例中所有数据库中的数据。综上所述，这些数据库更像是一种命名空间，而不适宜存储不同应用程序的数据。比如可以使用0号数据库存储某个应用生产环境中的数据，使用1号数据库存储测试环境中的数据，但不适宜使用0号数据库存储A应用的数据而使用1号数据库B应用的数据，不同的应用应该使用不同的Redis实例存储数据。由于Redis非常轻量级，一个空Redis实例占用的内在只有1M左右，所以不用担心多个Redis实例会额外占用很多内存。

 

Redis为什么这么快：

总体来说快速的原因如下：
1）绝大部分请求是纯粹的内存操作（非常快速）
2）采用单线程, 保证了每个操作的原子性，避免了不必要的上下文切换和竞争条件
3）非阻塞IO , IO多路复用，
内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间

 4. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

Redis请求应答模型

Redis是一个CS结构的TCP服务器，使用”请求-应答”的模式。，客户端发起一个请求是这样的步骤：

客户端发送一个请求给服务器，然后等待服务器的响应，一般客户端使用阻塞模式来等待服务器响应。服务器收到请求并处理完毕后，发送结果给客户端。

客户端和服务器通过网络连接，网速可以非常快, 也可以非常慢。不管是快还是慢，消息包从客户端到服务器，再从服务器返回到客户端，总是要需要时间的。这个时间被称之为RTT(Round Trip Time，往返延时)。显然，当客户端需要发送多条请求时（比如往一个list中加很多元素，或者往一个数据库中填充很多keys），这个往返延时会影响到性能。假设网络非常慢，往返延时达到250毫秒，就算服务器每秒可以处理10万个请求，客户端也只能每秒处理4个请求。就算使用环回接口，往返延时非常小，如果需要执行很多写的操作, 也是要浪费许多时间的。

Redis Pipelining管道化

      “请求-响应”模式的服务器在处理完一个请求后就开始处理下一个请求，不管客户端是否读取到前一个请求的响应结果。这让客户端不需要发一个请求等一个响应的串行，可以一次发送多个请求，再最后一次性读取所有响应。这就叫pipelining（管道化），这种技术几十年来广泛的使用。比如很多POP3协议支持这个特性，大大的加速了从服务器上下载新邮件的速度。

　我们的第一个例子，如果使用pipeline，客户端的请求和服务器的响应顺序就是如下：

客户端发送: INCR X

客户端发送: INCR X

客户端发送: INCR X

客户端发送: INCR X

服务器响应: 1

服务器响应: 2

服务器响应: 3

服务器响应: 4

　　注意：当客户端使用pipelining发送很多请求时，服务器将在内存中使用队列存储这些指令的响应。所以批量发送的指令数量，最好在一个合理的范围内，比如每次发1万条指令，读取完响应后再发送另外1万条指令。2万条指令，一次性发送和分2次发送，对客户端来说速度是差不多的，但是对服务器来说，内存占用差了1万条响应的大小。

管道化 VS 脚本

 大部分使用pipelining的情况都可以用Redis脚本（2.6或高于2.6的版本才支持）来代替，使之更高效的在服务器端执行。使用脚本的最大好处是，在最小的延迟下可以读和写，比如可以：让“读，计算，写”这样一个流程非常快(pipeling不能处理这种情景,因为客户端需要得到响应之后才能计算和写)。有时候，应用程序可能需要在一个pipeline中发送多个EVAL或EVALSHA指令，redis的SCRITP LOAD指令能很好的满足这种需求（它保证了EVALSHA不会有调用失败的风险）。

Redis做消息队列

Redis提供了两种方式来作消息队列。

1. 生产者消费模式: 生产者将消息放入队列，多个消费者共同监听，谁先抢到资源，谁就从队列中取走消息去处理。注意，每个消息只能最多被一个消费者接收。

结合队列的特点: 只允许在一端插入新元素只能在队列的尾部FIFO:先进先出原则

redis中list的push和pop操作=lpush头入(rpop尾出)或rpush尾入(lpop头出)可以满足要求,对象需要转换成byte[] 

1. 发布订阅者模式: 发布者发送消息到队列，每个订阅者都能收到一样的消息。 
   Redis提供了发布订阅功能，可以用于消息的传输，Redis的发布订阅机制包括三个部分，发布者，订阅者和Channel。 

发布者和订阅者都是Redis客户端，Channel则为Redis服务器端，发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息。Redis的这种发布订阅机制与基于主题的发布订阅类似，Channel相当于主题。

Redis采用PUBLISH命令发送消息，其返回值为接收到该消息的订阅者的数量。 
 Redis采用SUBSCRIBE命令订阅某个频道，其返回值包括客户端订阅的频道，目前已订阅的频道数量，以及接收到的消息，其中subscribe表示已经成功订阅了某个频道。 

模式匹配功能允许客户端订阅符合某个模式的频道，Redis采用PSUBSCRIBE订阅符合某个模式所有频道，用“”表示模式，“”可以被任意值代替。 
 

假设客户端同时订阅了某种模式和符合该模式的某个频道，那么发送给这个频道的消息将被客户端接收到两次，只不过这两条消息的类型不同，一个是message类型，一个是pmessage类型，但其内容相同。 
Redis采用UNSUBSCRIBE和PUNSUBSCRIBE命令取消订阅，其返回值与订阅类似。 
由于Redis的订阅操作是阻塞式的，因此一旦客户端订阅了某个频道或模式，就将会一直处于订阅状态直到退出。在SUBSCRIBE，PSUBSCRIBE，UNSUBSCRIBE和PUNSUBSCRIBE命令中，其返回值都包含了该客户端当前订阅的频道和模式的数量，当这个数量变为0时，该客户端会自动退出订阅状态。

Redis做分布式锁

Redis因为是单线程的，所以本身没有锁的概念。

所以分布式锁的实现原理是SETNX key value/expire()来设置超时时间，写入成功相当于获取锁成功。写入失败也即是setnx方法返回0，获取锁失败。注意锁的失效时间，否则容易造成死锁。

SETNX key value    SETNX =SET if Not Exists

将 key 的值设为 value，当且仅当 key 不存在。 
若给定的 key 已经存在，则 SETNX 不做任何动作。 

Redis排序

sort默认的排序方式（asc）是从小到大排的,当然也可以按照逆序或者按字符顺序排。逆序可以加上desc选项，想按字母顺序排可以加alpha选项，当然alpha可以和desc一起用。如：

sort mylist alpha   对mylist按字母顺序排序

sort mylist desc alpha  对mylist按字母顺序降序排序

怎么扩容？扩容难点在哪里

Hash一致性的保证

Redis主从

主从切换：Sentinel参数设置可以实现自动切换

主从复制：内存快照

当一个从数据库启动时，会向主数据库发送SYNC命令，主数据库收到命令后会开始在后台保存快照（即RDB持久化过程），并将保存快照期间接收到的命令缓存起来。当快照完成后，Redis会将快照文件和缓存的命令发给从数据库，从数据库收到数据后，会载入快照文件并执行缓存的命令。以上过程称为复制初始化。复制初始化之结束后，主数据库每收到写命令时就会将命令同步给从数据库，从而保证主从数据库数据一致，这一过程称为复制同步阶段。

同步策略：每隔N秒自动同步  每执行N条自动同步