Redis

Redis是一个开源的，先进的key-value持久化产品。它通常被称为数据结构服务器，它的值可以是字符串（String）、哈希（Map）、列表（List）、集合（Sets）和有序集合（Sorted sets）等类型。可以在这些类型上面做一些原子操作，如：字符串追加、增加Hash里面的值、添加元素到列表、计算集合的交集，并集和差集；或者区有序集合中排名最高的成员。为了取得好的性能，Redis是一个内存型数据库。不限于此，Redis也可以把数据持久化到磁盘中，或者把数据操作指令追加了一个日志文件，把它用于持久化。也可以用Redis容易的搭建master-slave架构用于数据复制。其它让它像缓存的特性包括，简单的check-and-set机制，pub/sub和配置设置。Redis可以用大部分程序语言来操作：C、C++、C#、Java、Node.js、php、ruby等等。Redis是用ANSIC写的，可以运行在多数POSIX系统，如：Linux，*BSD，OS X和Soloris等。官方版本不支持Windows下构建，可以选择一些修改过的版本，照样可以使用Redis。

Redis五种数据类型

【String类型】

String是最基本的类型，而且string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如 jpg 图片或者序列化的对象。从内部实现来看其实 string 可以看作 byte 数组，最大上限是 1G 字节。

string类型数据操作指令简介

1.        set keyvalue设置key对应string类型的值，返回1表示成功，0失败。

2.        setnx keyvalue如果key不存在，设置key对应string类型的值。如果key已经存在，返回0。

3.        get key获取key对应的string值,如果key不存在返回nil

4.        getsetkey value先获取key的值，再设置key的值。如果key不存在返回nil。

5.        mget key1key2 ...... keyN一次获取多个key的值，如果对应key不存在，则对应返回nil

6.        mset key1value1 ...... keyN valueN一次设置多个key的值，成功返回1表示所有的值都设置了，失败返回0表示没有任何值被设置。

7.        msetnxkey1 value1 ...... keyN valueN一次设置多个key的值，但是不会覆盖已经存在的key incr key 对key的值做++操作，并返回新的值。注意incr一个不是int的value会返回错误，incr一个不存在的key，则设置key值为1。

8.        decr key: 对key的值做--操作，decr一个不存在key，则设置key值为-1。

9.        incrbykey integer对key加上指定值，key不存在时候会设置key，并认为原来的value 是0。

10.    decrbykey integer对key减去指定值。decrby完全是为了可读性，我们完全可以通过incrby一个负值来实现同样效果，反之一样。

【hash类型】

hash是一个string类型的field和value的映射表。添加，删除操作都是O(1)（平均）。 hash特别适合用于存储对象。相对于将对象的每个字段存成单个string类型。将一个对象存储在hash类型中会占用更少的内存，并且可以更方便的存取整个对象。省内存的原因是新建一个hash对象时开始是用 zipmap（又称为 small hash）来存储的。这个 zipmap 其实并不是hashtable，但是zipmap相比正常的hash实现可以节省不少hash本身需要的一些元数据存储开销。尽管zipmap的添加，删除，查找都是 O(n)，但是由于一般对象的field 数量都不太多。所以使用zipmap也是很快的,也就是说添加删除平均还是O(1)。如果field 或者 value的大小超出一定限制后，redis会在内部自动将zipmap替换成正常的hash实现.这个限制可以在配置文件中指定。

hash类型数据操作指令简介

1.        hset keyfield value 设置hash field为指定值，如果key不存在，则创建。

2.        hget keyfield 获取指定的hash field。

3.        hmget keyfiled1....fieldN 获取全部指定的hash filed。

4.        hmset keyfiled1 value1 ...... filedN valueN 同时设置hash的多个field。

5.        hincrbykey field integer 将指定的hashfiled 加上指定值。成功返回hashfiled变更后的值。

6.        hexistskey field 检测指定field是否存在。 hdelkey field 删除指定的hash field。

7.        hlen key 返回指定hash的field数量。 hkeys key 返回hash的所有field。

8.        hvals key 返回hash的所有value。

9.        hgetall 返回hash的所有filed和value。

【List类型】

list是一个链表结构，可以理解为一个每个子元素都是 string 类型的双向链表。主要功

能是push、pop、获取一个范围的所有值等。操作中key理解为链表的名字。

List类型数据操作指令简介

1.        lpush keystring 在key对应list的头部添加字符串元素，返回1表示成功，0表示key存在且不是list类型。

2.        rpush keystring 在key对应list的尾部添加字符串元素。

3.        llen key 返回key对应list的长度，如果key不存在返回0，如果key对应类型不是list 返回错误。

4.        lrangekey start end 返回指定区间内的元素，下标从0开始，负值表示从后面计算，-1表示倒数第一个元素 ，key不存在返回空列表。

5.        ltrim keystart end 截取list指定区间内元素，成功返回1，key不存在返回错误。

6.        lset keyindex value 设置list中指定下标的元素值，成功返回1，key或者下标不存在返回错误。

7.        lrem keycount value 从 List 的头部（count正数）或尾部（count负数）删除一定数量（count）匹配value的元素，返回删除的元素数量。count为0时候删除全部。

8.        lpop key 从list的头部删除并返回删除元素。如果key对应list不存在或者是空返回nil，如果key对应值不是list返回错误。

9.        rpop key从list的尾部删除并返回删除元素。

10.    blpopkey1 ...... keyN timeout 从左到右扫描，返回对第一个非空list进行lpop操作并返回，比如blpop list1 list2 list3 0 ,如果list不存在list2,list3都是非空则对list2做 lpop并返回从list2中删除的元素。如果所有的list都是空或不存在，则会阻塞timeout秒，timeout为0表示一直阻塞。当阻塞时，如果有client对key1...keyN中的任意key 进行push操作，则第一在这个key上被阻塞的client会立即返回。如果超时发生，则返回 nil。有点像unix的select或者poll。

11.    brpop 同blpop，一个是从头部删除一个是从尾部删除。

【Set类型】

set是无序集合，最大可以包含(2的 32 次方-1)个元素。set 的是通过 hash table 实现的，所以添加，删除，查找的复杂度都是 O(1)。hash table 会随着添加或者删除自动的调整大小。需要注意的是调整 hash table 大小时候需要同步（获取写锁）会阻塞其他读写操作。可能不久后就会改用跳表（skip list）来实现。跳表已经在 sorted sets 中使用了。关于 set 集合类型除了基本的添加删除操作，其它有用的操作还包含集合的取并集(union)，交集(intersection)，差集(difference)。通过这些操作可以很容易的实现 SNS 中的好友推荐和 blog 的 tag 功能。

 set类型数据操作指令简介

1.        sadd keymember 添加一个string元素到key对应set集合中，成功返回1,如果元素以及在集合中则返回0，key对应的set不存在则返回错误。

2.        srem keymember 从key对应set中移除指定元素，成功返回1，如果member在集合中不存在或者key不存在返回0，如果key对应的不是set类型的值返回错误。

3.        spop key 删除并返回key对应set中随机的一个元素,如果set是空或者key不存在返回 nil。

4.        srandmemberkey 同spop，随机取set中的一个元素，但是不删除元素。

5.        smovesrckey dstkey member 从srckey对应set中移除member并添加到dstkey对应set中，整个操作是原子的。成功返回1,如果member在srckey中不存在返回0，如果key不是set 类型返回错误。

6.        scard key 返回set的元素个数，如果set是空或者key不存在返回0。

7.        sismemberkey member 判断member是否在set中，存在返回1，0表示不存在或者key不存在。

8.        sinterkey1 key2 …… keyN 返回所有给定key的交集。

9.        sinterstoredstkey key1 ....... keyN 返回所有给定key的交集，并保存交集存到dstkey下。

10.    sunionkey1 key2 ...... keyN 返回所有给定key的并集。

11.    sunionstoredstkey key1 ...... keyN 返回所有给定key的并集，并保存并集到dstkey下。

12.    sdiffkey1 key2 ...... keyN 返回所有给定key的差集。

13.    sdiffstoredstkey key1 ...... keyN 返回所有给定key的差集，并保存差集到dstkey下。

14.    smemberskey 返回key对应set的所有元素，结果是无序的。

【 Sorted Set】

sorted set是有序集合，它在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，会自动重新按新的值调整顺序。可以理解了有两列的 mysql表，一列存value，一列存顺序。操作中key理解为sorted set的名字。

Sorted Set类型数据操作指令简介

1.        add keyscore member 添加元素到集合，元素在集合中存在则更新对应score。

2.        zrem keymember 删除指定元素，1 表示成功，如果元素不存在返回 0。

3.        zincrbykey incr member 增加对应 member 的 score 值，然后移动元素并保持skip list 保持有序。返回更新后的 score 值。

4.        zrank keymember 返回指定元素在集合中的排名（下标），集合中元素是按 score 从小到大排序的。

5.        zrevrankkey member 同上,但是集合中元素是按score 从大到小排序。

6.        zrangekey start end 类似 lrange 操作从集合中去指定区间的元素。返回的是有序结果

7.        zrevrangekey start end 同上，返回结果是按 score 逆序的。

8.        zrangebyscorekey min max 返回集合中 score 在给定区间的元素。

9.        zcountkey min max 返回集合中 score 在给定区间的数量。

10.    zcard key 返回集合中元素个数。

11.    zscorekey element 返回给定元素对应的 score。

12.    zremrangebyrankkey min max 删除集合中排名在给定区间的元素。

13.    zremrangebyscorekey min max 删除集合中 score 在给定区间的元素。

Redis主从复制

1、redis为什么还要主从复制？

和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

2、什么是主从复制？

下图为级联结构

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

1.  主从复制介绍
Redis支持将数据同步到多台从库上，这种特性对提高读取性能非常有益。master可以有多个slave。除了多个slave连到相同的master外，slave也可以连接其它slave形成图状结构。主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理客户端发来的请求。相反slave在初次同步数据时则会阻塞不能处理客户端的请求。

主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于客户端的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余。可以在 master 禁用数据持久化，只需要注释掉 master 配置文件中的所有 save 配置，然后只在 slave 上配置数据持久化。

2. 主从复制过程
当设置好 slave 服务器后，slave 会建立和 master 的连接，然后发送 sync命令。无论是第一次同步建立的连接还是连接断开后的重新连接，master 都会启动一个后台进程，将数据库快照保存到文件中，同时 master 主进程会开始收集新的写命令并缓存起来。后台进程完成写文件后，master 就发送文件给 slave，slave 将文件保存到磁盘上，然后加载到内存恢复数据库快照到 slave 上。接着 master 就会把缓存的命令转发给 slave。而且后续 master 收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从客户端发送的命令使用相同的协议格式。当 master 和 slave 的连接断开时 slave 可以自动重新建立连接。如果 master 同时收到多个 slave 发来的同步连接命令，只会启动一个进程来写数据库镜像，然后发送给所有 slave。

配置 slave服务器很简单，只需要在配置文件中加入如下配置

slaveof  192.168.1.1 6379     #指定 master的 ip 和端口。

3、主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4. 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；

5. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

4、主从复制的方式

4.1 全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
-  从服务器连接主服务器，发送SYNC命令；
-  主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
-  主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
-  从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
-  主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
-  从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。

4.2 增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
 
Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
 
5、主从复制的一些特点：
1）采用异步复制；
2）一个主redis可以含有多个从redis；
3）每个从redis可以接收来自其他从redis服务器的连接；
4）主从复制对于主redis服务器来说是非阻塞的，这意味着当从服务器在进行主从复制同步过程中，主redis仍然可以处理外界的访问请求；
5）主从复制对于从redis服务器来说也是非阻塞的，这意味着，即使从redis在进行主从复制过程中也可以接受外界的查询请求，只不过这时候从redis返回的是以前老的数据，如果你不想这样，那么在启动redis时，可以在配置文件中进行设置，那么从redis在复制同步过程中来自外界的查询请求都会返回错误给客户端；（虽然说主从复制过程中对于从redis是非阻塞的，但是当从redis从主redis同步过来最新的数据后还需要将新数据加载到内存中，在加载到内存的过程中是阻塞的，在这段时间内的请求将会被阻，但是即使对于大数据集，加载到内存的时间也是比较多的）；
6）主从复制提高了redis服务的扩展性，避免单个redis服务器的读写访问压力过大的问题，同时也可以给为数据备份及冗余提供一种解决方案；
7）为了编码主redis服务器写磁盘压力带来的开销，可以配置让主redis不在将数据持久化到磁盘，而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘，不过这样会存在一个问题，就是主redis服务器一旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从redis服务器上的数据也被清空；

Redis大概主从同步是怎么实现的？
====全量同步====
master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件，与此同时，服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该rdb文件传递给slave服务器，而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后master服务器会将在此期间缓存的命令通过redis传输协议发送给slave服务器，然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。

====部分同步=====
从redis 2.8版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master服务器和slave服务器之间都是进行全量数据同步，但是从redis 2.8开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了一份同步日志和同步标识，每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave服务器隔断时间（默认1s）主动尝试和master服务器进行连接，如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中，那么就从slave发送的偏移量开始继续上次的同步操作，如果slave发送的偏移量已经不再master的同步备份日志中（可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作），则必须进行一次全量更新。在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

主从同步中需要注意几个问题
4）关于slave服务器上过期键的处理，由master服务器负责键的过期删除处理，然后将相关删除命令已数据同步的方式同步给slave服务器，slave服务器根据删除命令删除本地的key。

当主服务器不进行持久化时复制的安全性
在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。

为什么不持久化的主服务器自动重启非常危险呢？
为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。

设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。

Redis主从复制是如何工作的
如果设置了一个从服务器，在连接时它发送了一个SYNC命令，不管它是第一次连接还是再次连接都没有关系。然后主服务器开始后台存储，并且开始缓存新连接进来的修改数据的命令。当后台存储完成后，主服务器把数据文件发送到从服务器，从服务器将其保存在磁盘上，然后加载到内存中。然后主服务器把刚才缓存的命令发送到从服务器。这是作为命令流来完成的，并且和Redis协议本身格式相同。可以通过telnet自己尝试一下。在Redis服务器工作时连接到Redis端口，发送SYNC命令，会看到一个批量的传输，并且主服务器接收的每一个命令都会通过telnet会话重新发送一遍。当主从服务器之间的连接由于某些原因断开时，从服务器可以自动进行重连接。当有多个从服务器同时请求同步时，主服务器只进行一个后台存储。当连接断开又重新连上之后，一般都会进行一个完整的重新同步，但是从Redis2.8开始，只重新同步一部分也可以。

===== 部分重新同步 =====
从Redis 2.8开始，如果遭遇连接断开，重新连接之后可以从中断处继续进行复制，而不必重新同步。

它的工作原理是这样：
主服务器端为复制流维护一个内存缓冲区（in-memory backlog）。主从服务器都维护一个复制偏移量（replication offset）和master run id ，当连接断开时，从服务器会重新连接上主服务器，然后请求继续复制，假如主从服务器的两个master run id相同，并且指定的偏移量在内存缓冲区中还有效，复制就会从上次中断的点开始继续。如果其中一个条件不满足，就会进行完全重新同步（在2.8版本之前就直接进行完全重新同步）。因为主运行id不保存在磁盘中，如果从服务器重启的话就只能进行完全同步了。

部分重新同步这个新特性内部使用PSYNC命令，旧的实现中使用SYNC命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令，不支持的话使用SYNC命令。

===== 无磁盘复制 =====
通常来讲，一个完全重新同步需要在磁盘上创建一个RDB文件，然后加载这个文件以便为从服务器发送数据。

如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

===== 配置 =====
主从复制的配置十分简单：把下面这行加入到从服务器的配置文件中即可。
slaveof 192.168.1.1 6379

当然你需要把其中的192.168.1.1 6379替换为你自己的主服务器IP（或者主机名hostname）和端口。另外你可以调用SLAVEOF命令，
主服务器就会开始与从服务器同步。

关于部分重新同步，还有一些针对复制内存缓冲区的优化参数。查看Redis介质中的Redis.conf示例获得更多信息。

使用repl-diskless-sync配置参数来启动无磁盘复制。使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间，以便等待
更多的从服务器连接上来。查看Redis介质中的Redis.conf示例获得更多信息。

===== 只读从服务器 ======
从Redis 2.6开始，从服务器支持只读模式，并且是默认模式。这个行为是由Redis.conf文件中的slave-read-only 参数控制的，可以在运行中通过CONFIG SET来启用或者禁用。

只读的从服务器会拒绝所有写命令，所以对从服务器不会有误写操作。但这不表示可以把从服务器实例暴露在危险的网络环境下，因为像DEBUG或者CONFIG这样的管理命令还是可以运行的。不过你可以通过使用rename-command命令来为这些命令改名来增加安全性。

你可能想知道为什么只读限制还可以被还原，使得从服务器还可以进行写操作。虽然当主从服务器进行重新同步或者从服务器重启后，这些写操作都会失效，还是有一些使用场景会想从服务器中写入临时数据的，但将来这个特性可能会被去掉。

===== 限制有N个以上从服务器才允许写入 =====
从Redis 2.8版本开始，可以配置主服务器连接N个以上从服务器才允许对主服务器进行写操作。但是，因为Redis使用的是异步主从复制，没办法确保从服务器确实收到了要写入的数据，所以还是有一定的数据丢失的可能性。

这一特性的工作原理如下：
1）从服务器每秒钟ping一次主服务器，确认处理的复制流数量。
2）主服务器记住每个从服务器最近一次ping的时间。
3）用户可以配置最少要有N个服务器有小于M秒的确认延迟。
4）如果有N个以上从服务器，并且确认延迟小于M秒，主服务器接受写操作。

还可以把这看做是CAP原则（一致性，可用性，分区容错性）不严格的一致性实现，虽然不能百分百确保一致性，但至少保证了丢失的数据不会超过M秒内的数据量。

如果条件不满足，主服务器会拒绝写操作并返回一个错误。
1）min-slaves-to-write（最小从服务器数）
2）min-slaves-max-lag（从服务器最大确认延迟）

通过redis实现服务器崩溃等数据恢复
由于redis存储在内存中且提供一般编程语言常用的数据结构存储类型，所以经常被用于做服务器崩溃宕机的数据恢复处理。服务器可以在某些指定过程中将需要保存的数据以json对象等方式存储到redis中，也就是我们常说的快照，当服务器运行时读取redis来判断是否有待需要恢复数据继续处理的业务。当一次业务处理结束后再删除redis的数据即可。redis提供两种将内存数据导出到硬盘实现数据备份的方法：

1）RDB方式 (默认)
RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。RDB是redis默认采用的持久化方式，在配置文件中已经预置了3个条件：
save 900 1 #900秒内有至少1个键被更改则进行快照
save 300 10 #300秒内有至少10个键被更改则进行快照
save 60 10000 #60秒内有至少10000个键被更改则进行快照

可以存在多个条件，条件之间是"或"的关系，只要满足其中一个条件，就会进行快照。 如果想要禁用自动快照，只需要将所有的save参数删除即可。
Redis默认会将快照文件存储在当前目录(可CONFIG GET dir来查看)的dump.rdb文件中，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。

Redis实现快照的过程
->  Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
->  父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
->  当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。
->  在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩（可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

除了自动快照，还可以手动发送SAVE或BGSAVE命令让Redis执行快照，两个命令的区别在于，前者是由主进程进行快照操作，会阻塞住其他请求，后者会通过fork子进程进行快照操作。 Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20～30秒钟。 通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。

2）AOF方式
默认情况下Redis没有开启AOF(append only file)方式的持久化，可以在redis.conf中通过appendonly参数开启：
appendonly yes
在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：
appendfilename appendonly.aof
配置redis自动重写AOF文件的条件

auto-aof-rewrite-percentage 100 # 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据

auto-aof-rewrite-min-size 64mb # 允许重写的最小AOF文件大小
配置写入AOF文件后，要求系统刷新硬盘缓存的机制

# appendfsync always # 每次执行写入都会执行同步，最安全也最慢
appendfsync everysec # 每秒执行一次同步操作

# appendfsync no # 不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），最快也最不安全

Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少

主从复制启用

从节点开启主从复制，有3种方式：

1. 配置文件： 在从服务器的配置文件中加入：slaveof <masterip> <masterport>

2. 启动命令： redis-server启动命令后加入 --slaveof <masterip> <masterport>

3. 客户端命令： Redis服务器启动后，直接通过客户端执行命令：slaveof <masterip>
<masterport>，则该Redis实例成为从节点。

通过 info replication 命令可以看到复制的一些信息

主从复制原理

主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示大概可以看到，
从图中可以看出复制过程大致分为6个过程

主从配置之后的日志记录也可以看出这个流程

1）保存主节点（master）信息。
执行 slaveof 后 Redis 会打印如下日志：

2）从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接

从节点与主节点建立网络连接

从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveof no one 取消复制

关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：

# Error condition on socket for SYNC: {socket_error_reason}

3）发送 ping 命令。
连接建立成功后从节点发送 ping 请求进行首次通信，ping 请求主要目的如下：
·检测主从之间网络套接字是否可用。
·检测主节点当前是否可接受处理命令。
如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：

4）权限验证。如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。

5）同步数据集。主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

6）命令持续复制。当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

Redis持久化

通常Redis将数据存储在内存中或虚拟内存中，但它提供了数据持久化功能可以把内存中的数据持久化到磁盘。持久化有什么好处呢？比如可以保证断电后数据不会丢失，升级服务器也会变得更加方便。Redis提供了两种数据持久化的方式。

1. RDB Snapshotting方式持久化（默认方式）
这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dump.rdb。客户端也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写操作会比较多，必然会引起大量的磁盘IO操作，可能会严重影响性能。

这种方式的缺点也是显而易见的，由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外当机的话，就会丢失最后一次快照后的所有数据修改。

2. AOF方式持久化
这种方式 redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于操作系统会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样的持久化还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis我们想要通过fsync函数强制操作系统写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）

appendonly  yes     //启用日志追加持久化方式

1.        appendfsync always     //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全持久化，不推荐使用。

2.        appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐使用。

3.        appendfsync no    //完全依赖操作系统，性能最好,持久化没保证。

日志追加方式同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test 命令 100 次，文件中必须保存全部 100 条命令，其实有 99 条都是多余的。因为要恢复数据库状态其实文件中保存一条 set test 100 就够了。为了压缩这种持久化方式的日志文件。 redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的持久化日志文件。

 Redis虚拟内存

        redis的虚拟内存与操作系统虚拟内存不是一码事，但是思路和目的都是相同的。就是暂时把不经常访问的数据从内存交换到磁盘中，从而腾出宝贵的内存空间。对于 redis这样的内存数据库，内存总是不够用的。除了可以将数据分割到多个redis 服务器以外。另外的能够提高数据库容量的办法就是使用虚拟内存技术把那些不经常访问的数据交换到磁盘上。如果我们存储的数据总是有少部分数据被经常访问，大部分数据很少被访问，对于网站来说确实总是只有少量用户经常活跃。当少量数据被经常访问时，使用虚拟内存不但能提高单台redis数据库服务器的容量，而且也不会对性能造成太多影响。

redis没有使用操作系统提供的虚拟内存机制而是自己在用户态实现了自己的虚拟内存机制。主要的理由有以下两点，操作系统的虚拟内存是以4k/页为最小单位进行交换的。而redis的大多数对象都远小于4k，所以一个操作系统页上可能有多个redis对象。另外redis的集合对象类型如 list,set可能存在于多个操作系统页上。最终可能造成只有10%的key被经常访问，但是所有操作系统页都会被操作系统认为是活跃的，这样只有内存真正耗尽时操作系统才会进行页的交换。相比操作系统的交换方式。redis可以将被交换到磁盘的对象进行压缩,保存到磁盘的对象可以去除指针和对象元数据信息。一般压缩后的对象会比内存中的对象小 10倍。这样redis的虚拟内存会比操作系统的虚拟内存少做很多IO操作。

 虚拟内存相关设置

vm-enabled  yes    开启虚拟内存功能

vm-swap-file  /tmp/redis.swap     交换出来value保存的文件路径/tmp/redis.swapvm-max-memory268435456  redis使用的最大内存上限（256MB），超过上限后 redis开始交换value到磁盘swap文件中。建议设置为系统空闲内存的60 %-80%

vm-page-size  32  每个redis页的大小32个字节

vm-pages  134217728  最多在文件中使用多少个页,交换文件的大小 =（vm-page-size* vm-pages）4 GB

vm-max-threads  8 用于执行value对象换入换出的工作线程数量。0 表示不使用工作线程

参考链接：https://www.cnblogs.com/duanxz/p/15894023.html

Redis集群及节点通信原理

Redis最新稳定版还不支持集群，会在以后的V3.0提供集群功能，现在进度是V3.0已经发布Beta-7版，计划今年年底正式推出稳定版。Redis提供了Partitioning（类似于Memcached在客户端进行Hash映射）机制以支持多实例，下面介绍下Partitioning目标：

1.        突破了单一计算机内存限制，可以利用到多个计算机的内存和

2.        通过配置多个计算机来拓展计算能力，解决网络、网卡瓶颈 

Partitioning支持：

1.        通过Client端实现Partitioning，即Client端在读写数据的时候根据自己的选择算法自动选择合适的Redis实例

2.        代理Partitioning，即客户端把读写请求发到代理，由来自选择合适的实例，twitter为Redis和Memcached专门写了一个代理 Twemproxy

3.        查询时自动routing：客户端随机发送命令到任何一个实例，这个实例会把请求转发给合适的实例，这个功能现在还不支持，3.0版本实现的集群功能支持

Redis集群搭建中，数据如何在节点分布的原理，下面来介绍一下节点之间是如何进行通信(节点握手)

一、基础通讯原理

1、维护集群的元数据的两种方案介绍及对比

在分布式存储中需要提供维护节点元数据信息的机制，所谓元数据是指：节点负责哪些数据，是否出现故障等状态信息。常见的元数据维护方式分为：集中式和P2P方式。

1. 集中式：
   • 优点 ：元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中。
   • 缺点 ：所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储有压力。
2. gossip：
   • 优点 ：元数据的更新比较分散，不是集中在同一个地方，更新请求会陆陆续续到达所有节点上去更新，有一定的延时，降低了压力。
   • 缺点 ：元数据更新有延时，可能会导致集群的一些操作会有一些滞后。

集中式示例图-1：

集群元数据集中式存储的典型代表就是storm：

集中式示例图-2：假如redis cluster采用集中式存储元数据如下图：

P2P方式的gossip的redis cluster方式示例图-3：

 2、redis cluster节点间采用gossip协议进行通讯

回到redis cluster，Redis集群采用P2P的Gossip（流言）协议，跟集中式不同，不是将集群元数据（节点信息、hashslot->node之间的映射表关系，还有master->slave之间关系，故障的信息等）集中存储在某个节点上，Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间后集群的所有的节点都会有完整的（集群）信息，这种方式类似流言传播

节点之间通信示意图

3、10000端口

每个节点都有一个专门用于节点间通信的端口号，就是自己提供服务的端口号+10000。每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他节点接收到ping之后会返回pong消息。

4、节点间交换的信息

包含故障信息，节点的增加和移除，hash slot信息等等。

二、Gossip消息

Gossip协议的主要职责就是信息交换。信息交换的载体就是节点彼此发送的Gossip消息，常用的Gossip消息可分为：ping消息、pong消息、meet消息、fail消息

• meet消息：用于通知新节点加入(某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信)。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换
  • 　　例如：执行redis-trib.rb add-node 命令时，其实内部就是发送了一个gossip meet消息，给新加入的节点，通知那个节点去加入我们的集群
• ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息。ping消息发送封装了自身节点和部分其他节点的状态数据
  • 　　ping消息深入

    ping很频繁，而且要携带一些元数据，所以可能会加重网络负担

    每个节点每秒会执行10次ping，每次会选择5个最久没有通信的其他节点

    当然如果发现某个节点通信延时达到了cluster_node_timeout / 2，那么立即发送ping，避免数据交换延时过长，落后的时间太长了

    比如说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题

    所以cluster_node_timeout可以调节，如果调节比较大，那么会降低发送的频率

    每次ping，一个是带上自己节点的信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换

    至少包含3个其他节点的信息，最多包含总节点-2个其他节点的信息

• pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新，也可以用于信息广播和更新
• fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态

接收节点会解析消息内容并根据自身的识别情况做出相应处理，对应流程：

• 解析消息头过程：消息头包含了发送节点的信息，如果发送节点是新节点且消息是meet类型，则加入到本地节点列表；如果是已知节点，则尝试更新发送节点的状态，如槽映射关系、主从角色等状态
• 解析消息体过程：如果消息体的clusterMsgDataGossip数组包含的节点是新节点，则尝试发起与新节点的meet握手流程；如果是已知节点，则根据cluster MsgDataGossip中的flags字段判断该节点是否下线，用于故障转移

三、节点通讯优化

节点选择
由于内部需要频繁地进行节点信息交换，而ping/pong消息会携带当前节点和部分其他节点的状态数据，势必会加重带宽和计算的负担。Redis集群内节点通信采用固定频率（定时任务每秒执行10次）。因此节点每次选择需要通信的节点列表变得非常重要。通信节点选择过多虽然可以做到信息及时交换但成本过高。节点选择过少会降低集群内所有节点彼此信息交换频率，从而影响故障判定、新节点发现等需求的速度。因此Redis集群的Gossip协议需要兼顾信息交换实时性和成本开销，

选择发送消息的节点数量

集群内每个节点维护定时任务默认每秒执行10次，每秒会随机选取5个节点找出最久没有通信的节点发送ping消息，用于保证Gossip信息交换的随机性。每100毫秒都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster_node_timeout/2，则立刻发送ping消息，防止该节点信息太长时间未更新。根据以上规则得出每个节点每秒需要发送ping消息的数量=1+10*num（node.pong_received>cluster_node_timeout/2），因此cluster_node_timeout参数对消息发送的节点数量影响非常大。当我们的带宽资源紧张时，可以适当调大这个参数，如从默认15秒改为30秒来降低带宽占用率。过度调大cluster_node_timeout会影响消息交换的频率从而影响故障转移、槽信息更新、新节点发现的速度。因此需要根据业务容忍度和资源消耗进行平衡。同时整个集群消息总交换量也跟节点数成正比。

消息数据量

每个ping消息的数据量体现在消息头和消息体中，其中消息头主要占用空间的字段是myslots[CLUSTER_SLOTS/8]，占用2KB，这块空间占用相对固定。消息体会携带一定数量的其他节点信息用于信息交换，消息体携带数据量跟集群的节点数息息相关，更大的集群每次消息通信的成本也就更高，因此对于Redis集群来说并不是大而全的集群更好
 

四、面向集群的jedis内部实现原理

1.基于重定向的客户端
redis-cli c，自动重定向

①请求重定向
客户端可能会挑选任意一个redis实例去发送命令，每个redis实例接收到命令之后，都会接受key对应的hash slot，如果在本地就在本地处理，否则返回moved给客户端，让客户端进行重定向。
cluster keyslot mykey ，可以查看一个key对应的hash slot是什么。
用redis-cli的时候，可以加入-c参数，支持自动的请求重定向，redis-cli接收到moved之后，会自动重定向到对应的节点执行命令。

②计算hash slot
计算hash slot的算法，就是根据key计算CRC16值，然后对16384取模，拿到对应的hash slot。
用hash tag可以手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，比如set mykey1:{100}和set mykey2:{100}。

③hash slot查找
节点间通过gossip协议进行数据交换，就知道每个hash slot在那个节点上面了

2.smart jedis
①什么是smart jedis：
基于重定向的客户端，很消耗网络IO，因为大部分情况下，可能都会出现一次请求重定向，才能找到正确的节点。

所以大部分的客户端，比如java redis客户端，就是jedis，都是smart的。

本地维护一份hashslot -> node的映射表，缓存，大部分情况下，直接走本地缓存就可以找到hashslot -> node，不需要通过节点进行moved重定向。

②JedisCluster的工作原理
A：在JedisCluster初始化的时候，就会随机选择一个node，初始化hash slot到node的映射表，同时为每个节点创建一个JedisPool连接池。
B：每次基于JedisCluster执行操作，首先会在本地计算key的hash slot，然后在本地映射表中找到节点。
C：如果那个node真好还是持有那个hash slot，那么就OK。
D：如果JedisCluster API返回的是moved，那么利用该节点的数据，更新本地的hash slot 和node的映射表。
E：重复上面的步骤，知道找到对应的节点，如果重试超过5次，就会报错，抛出JedisClusterMaxRedirectionException异常。

jedis老版本，可能会出现在集群某个节点故障还没完成自动切换恢复时，频繁更新hash slot，频繁ping节点检查活跃，导致大量网络IO开销。

jedis最新版本，对于这些过度的hash slot更新和ping，都进行了优化，避免了类似问题。

③hash slot迁移和ask重定向
A：如果hash slot正在进行迁移，那么会返回ask重定向给jedis，
B：jedis接收到ask重定向之后，会重新定位到目标节点去执行。
C：但是因为ask发生在hash slot迁移过程中，所以收到ask是不会更新hash slot本地缓存。
D：已经可以确定说hash slot已经迁移完了，moved是会更新本地hash slot到node的映射缓存的。

(3)高可用与主备切换原理

redis cluster的高可用原理，几乎和哨兵时类似的。
1.判断节点宕机
①如果一个节点认为另一个节点道济，那么就是pfail，主观宕机。

②如果多个节点都认为另外一个 节点宕机了，那就是fail，客观宕机。

③在cluster-node-timeout内，某个几点一直没有返回pong，那么就认为pfail。

④如果一个节点认为某个节点pfail了，那么会在gossip ping消息中，发送给其他节点，如果超过半数的节点都认为pfail了，那就好变成fail。

2.从节点过滤
①对宕机的master node，从其所有的slave node中，选择一个切换成master node。

②检查每个slave node与master node断开连接的时机，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么这个节点就没有资格切换成 master node，直接被过滤。

3.从节点选举
①每个从几点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大的从节点，选举时间越靠前，优先进行选举。

②所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node(N/2 + 1)都投票给了某个从节点，那么选举通过，那个从节点可以切换成master node。

③从节点执行主备切换，从节点切换为主节点。

4.与哨兵进行比较
整个流程跟哨兵相比，非常类似，所以说，redis cluster功能强大，直接集成了replication和sentinal的功能

其它参考资料
所有特性请参考：http://redis.io/documentation

所有命令请参考：http://redis.io/commands#sorted_set

参考链接：https://www.cnblogs.com/duanxz/p/15893958.html

安装与使用

$ wget http://download.redis.io/releases/redis-2.8.13.tar.gz
$ tar xzf redis-2.8.13.tar.gz
$ cd redis-2.8.13
$ make
 
启动Redis实例
$ src/redis-server

通过内置客户端进行测试
$ src/redis-cli
如果配置密码需要认证

        127.0.0.1:6379> auth imas@ICS2o22
        127.0.0.1:6379> keys *   //获取所有key
        127.0.0.1:6379> get license_exist
        127.0.0.1:6379> set license_exist true
具体请参考：http://redis.io/download    

    redis application.yml配置

redis:
  database: 0
  host: imas.bigdata.cn
  port: 6379
  #password:
  timeout: 5000
  jedis:
    pool:
      max-active: 8 #连接池最大连接数（负值表示没有限制）
      max-idle: 8   #连接池最大空闲连接数
      min-idle: 0   #连接池最小空闲连接数
      max-wait: -1  #连接池最大阻塞等待时间（负值表示没有限制）
      timeout=5000ms：连接超时时间，单位ms
  
配置文件
1.        Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程

daemonize yes

2.        当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

pidfile/usr/local/redis/var/redis.pid

3.        指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字。

port 6379

4.        绑定的主机地址

bind 127.0.0.1

5.        当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能

timeout 0

6.        对客户端发送ACK信息，linux中单位为秒

tcp-keepalive 0

7.        指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice

loglevel notice

8.        日志记录位置，默认为标准输出

logfile/usr/local/redis/var/redis.log

9.        设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

databases 16

10.    指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

Save分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。

Redis默认配置文件中提供了三个条件：

save 900 1

save 300 10

save 60 10000

11.    持久化失败以后，redis是否停止

stop-writes-on-bgsave-erroryes

12.    指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

rdbcompression yes

rdbchecksum yes

13.    指定本地数据库文件名，默认值为dump.rdb

dbfilename dump.rdb

14.    指定本地数据库存放目录

dir /usr/local/redis/var

15.    设置当本机为slave服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步

 slaveof

16.    当master服务设置了密码保护时，slave服务连接master的密码

 masterauth

17.    设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭

 requirepass foobared

18.    设置同一时间最大客户端连接数，在 Redis2.4中，最大连接数是被直接硬编码在代码里面的，而在2.6版本中这个值变成可配置的。maxclients 的默认值是 10000，你也可以在 redis.conf 中对这个值进行修改。当然，这个值只是 Redis 一厢情愿的值，Redis 还会照顾到系统本身对进程使用的文件描述符数量的限制。在启动时 Redis 会检查系统的 soft limit，以查看打开文件描述符的个数上限。如果系统设置的数字，小于咱们希望的最大连接数加32，那么这个 maxclients 的设置将不起作用，Redis 会按系统要求的来设置这个值。（加32是因为 Redis 内部会使用最多32个文件描述符，所以连接能使用的相当于所有能用的描述符号减32）。当上面说的这种情况发生时（maxclients 设置后不起作用的情况），Redis 的启动过程中将会有相应的日志记录。比如下面命令希望设置最大客户端数量为10000，所以 Redis 需要 10000+32 个文件描述符，而系统的最大文件描述符号设置为10144，所以 Redis 只能将maxclients 设置为 10144 – 32 = 10112。

 maxclients 10000

19.    指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

 maxmemory

slave-serve-stale-data yes

slave-read-only yes

repl-disable-tcp-nodelay no

slave-priority 100

20.    指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为Redis本身同步数据文件是按上面slave条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no

appendonly no

21.    指定更新日志文件名，默认为appendonly.aof

 appendfilename appendonly.aof

22.    指定更新日志条件，共有3个可选值：

no：表示等操作系统进行数据缓存同步到磁盘（快）

always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）

everysec：表示每秒同步一次（折衷，默认值）

appendfsync everysec

23.    指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）

vm-enabled no

24.    虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

25.    将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。

vm-max-memory 0

26.    Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不确定，就使用默认值

vm-page-size32

27.    设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。

vm-pages 134217728

28.    设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4

vm-max-threads 4

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

lua-time-limit 5000

slowlog-log-slower-than 10000

slowlog-max-len 128

29.    指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

30.    指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）

activerehashing yes

client-output-buffer-limit normal 0 00

client-output-buffer-limit slave256mb 64mb 60

client-output-buffer-limit pubsub32mb 8mb 60

hz 10

31.    指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

具体请参考：https://raw.githubusercontent.com/antirez/redis/2.6/redis.conf

redis分布式之codis，twemproxy

一、codis

1.什么是Codis？

Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别(不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作,所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。

2.codis介绍

Codis是一个分布式Redis解决方案,对于上层的应用来说,连接到Codis Proxy和连接原生的RedisServer没有明显的区别,有部分命令不支持。
Codis底层会处理请求的转发,不停机的数据迁移等工作,所有后边的一切事情,对于前面的客户端来说是透明的,可以简单的认为后边连接的是一个内存无限大的Redis服务。

Codis由四部分组成
Codis-proxy    实现redis协议,由于本身是无状态的,因此可以部署很多个节点
Codis-config    是codis的管理工具,包括添加/删除redis节点添加/删除proxy节点,发起数据迁移等操作,自带httpserver,支持管理后台方式管理配置
Codis-server    是codis维护的redis分支,基于2.8.21分支,加入了slot的支持和原子的数据迁移指令; codis-proxy和codis-config只能和这个版本的redis交互才能正常运行
Zookeeper    用于codis集群元数据的存储,维护codis集群节点

3.Codis的架构

4.Codis的优缺点

1）优点

• 对客户端透明,与codis交互方式和redis本身交互一样
• 支持在线数据迁移,迁移过程对客户端透明有简单的管理和监控界面
• 支持高可用,无论是redis数据存储还是代理节点
• 自动进行数据的均衡分配
• 最大支持1024个redis实例,存储容量海量
• 高性能

2）缺点

• 采用自有的redis分支,不能与原版的redis保持同步
• 如果codis的proxy只有一个的情况下, redis的性能会下降20%左右
• 某些命令不支持,比如事务命令muti
• 国内开源产品,活跃度相对弱一些

5.Codis 3.x 的各个组件的说明

Codis Server    基于 redis-3.2.8 分支开发，增加了额外的数据结构，以支持 slot 有关的操作以及数据迁移指令。具体的修改可以参考文档 redis 的修改
Codis Proxy    客户端连接的 Redis 代理服务, 实现了 Redis 协议。 除部分命令不支持以外(不支持的命令列表)，表现的和原生的 Redis 没有区别（就像 Twemproxy）。对于同一个业务集群而言，可以同时部署多个 codis-proxy 实例；不同 codis-proxy 之间由 codis-dashboard 保证状态同步
Codis Dashboard    集群管理工具，支持 codis-proxy、codis-server 的添加、删除，以及据迁移等操作。在集群状态发生改变时，codis-dashboard 维护集群下所有 codis-proxy 的状态的一致性。对于同一个业务集群而言，同一个时刻 codis-dashboard 只能有 0个或者1个；所有对集群的修改都必须通过 codis-dashboard 完成
Codis Admin    集群管理的命令行工具。可用于控制 codis-proxy、codis-dashboard 状态以及访问外部存储
Codis FE    集群管理界面。多个集群实例共享可以共享同一个前端展示页面；通过配置文件管理后端 codis-dashboard 列表，配置文件可自动更新
Storage    为集群状态提供外部存储。提供 Namespace 概念，不同集群的会按照不同 product name 进行组织；目前仅提供了 Zookeeper、Etcd、Fs 三种实现，但是提供了抽象的 interface 可自行扩展。
 

二、twemproxy

twemproxy是支持memcached和redis协议的轻量级代理中间件，能用于高速缓存服务器集群的搭建。为此，twemproxy是高速缓存服务器集群的核心组件之一，也是业界较为成熟的高速缓存服务器集群解决方案之一。

twemproxy是搭建分布式缓存集群的重要组件之一。他能将来自客户端的redis包通过key分片发送到不同的redis服务器，而不是发到单个redis服务器上。因此，可以使本来集中到一个redis上的信息被分流到多个redis上，这就使得 twemproxy能支持redis集群。

不难想到，因为twemproxy的分片功能，可以轻松地对redis集群进行水平扩展（简单地理解成在一个业务中加入更多的redis服务器），同时对于代码稍加改造，我们就可以得到能读写分离的redis集群，这大大将提高了redis集群的性能。这使得各大公司如豌豆荚、阿里、百度等都对于这份代码进行了修改，能使其满足分布式缓存集群的要求。当然，twemproxy并不负责数据一致性的工作。

源码下载地址：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

twemproxy架构

为了能更好地了解twemproxy的代码结构，我们就需要了解twemproxy的架构，明白与它交互的组件。下面就是一般twemproxy的架构图

client是客户端，这里的客户端可以是很多应用，如网页，也可以是一些需要redis支持的服务器。LVS是Linux虚拟服务器，它主要用于负载均衡以及数据冗余，当然这一个层的负载均衡以及数据冗余也可以通过其他手段完成，如HAproxy等，当然也可以不需要这一层，可以让客户端直连twemproxy。memchache和redis是twemproxy目前支持的两种高速缓存服务器，但是考虑到高可用性和具体功能，一般会选用redis服务器。

我们可以看到在这种架构下，由于所有的通信都是用redis或者memchache协议完成。为此，client根本不知道和它通信的是高速缓存服务器还是twemproxy,高速缓存服务器memchache或redis也不知道和它联系的的是client还是twemproxy。

这样业务量一旦提升，我们只需要添加适量的高速缓存服务器和twemproxy服务器就可以满足业务需求。在这期间，几乎不需要对原先的client端的代码或者原先的高速缓存服务器的配置做任何修改，就可以完成业务上的水平扩容，这样就大大提高了高速缓存服务器的可用性。同时，由于不用修改client端的代码，我们可以进行平滑升级，即用户根本感知不到我们对业务进行了扩容，线上的client端不会因为我们的扩容而停止服务。同样地，我们可以对业务进行缩容处理。因此在业务量急剧变化的时候，这种架构的灵活性和可用性是原先单一的高速缓存服务器集群不能比拟的。

从这幅架构图上，我们也能开始逐一说明twemproxy的特性，阅读源码文件夹下的《README.md》的features，至于他是如何实现的，就需要我们去解读代码，这不是这一章要完成的任务。

1.Fast，即快速，据测试，直连twenproxy和直连redis相比几乎没有性能损失，这已经很逆天了，最重要的是他还没有进行读写分离就能达到这样的效果，确实fast

2.Lightweight，即轻量级，就我个人而言，它代码量就是轻量级的，解压后仅仅1.8MB!!!!因为透明连接池，内存零拷贝以及epoll模型的使用，使得它足够快速和轻量级。

3.Enables pipelining of requests and responses，Keeps connection count on the backend caching servers low，即保持前端的连接数，减少后端的连接数，这里主要得益于透明连接池的使用，前端主要指的是client和lvs，后端指的是redis和memchache，这个好处特别明显，既可以减少了redis的连接负载，又保持了保持了前端的功能。

4.Enables pipelining of requests and responses，即将请求和回复管道化，这里我的理解是他将请求包和回复包一一对应起来后，使得它的请求和回复更明确。

5.Supports multiple server pools simultaneously，Shard data automatically across multiple servers，即它可以支持多个高速缓存服务器，以及能对高速缓存服务器的数据进行共享，这是通过我在前面讲到过twemproxy的分片功能来实现的。

6.Implements the complete memcached ascii and redis protocol，它支持memchache和redis这两个协议，当然现在只支持其中大部分的协议而不是全部，这个会在后面开章节专门说明。

7.Supports multiple hashing modes including consistent hashing and distribution.就是它支持很多哈希算法来哈希key，如crc32，crc16，MD5等等。

8.Easy configuration of server pools through a YAML file.它的配置文件是通过YAML文件来配置的，YAML文件好处是简单易懂，容易学习配置。

9.Can be configured to disable nodes on failures. 它会自动指出连接失败的节点并报警，就是一旦某个高速缓存服务器发生故障，它能感知到并报警。

10.Observability via stats exposed on the stats monitoring port.这是他的监控功能，一般比较少用，但是它提示的信息却有统计的价值，如统计发送了多少读写命令。

通过上述的功能分析，我们可以理出一个我们值得关注的实现上的功能列表：

1.内存管理，这是导致特性1和4的关键之一，他通过一些方法，如内存用完后不立即释放将其放入内存队列里以备它用，内存零拷贝等手段使内存使用效率大幅提高。对应源码中的nc_mbuf 文件。

2.透明连接池，这是导致特性1,3的关键之一，当然连接池内的连接同样的是使用完后不立即释放将其放入连接队列里以备它用。对应源码中的nc_connection 文件。

3.分片，这是导致特性5，6的关键，也是twenproxy的核心功能。当然后面的7,8也导致了分片能得以进行。对应源码中的proto文件夹、hashkit文件夹。

4.配置文件，这影响了特性8，同时这份代码在配置上的代码风格非常简约，对应源码中的nc_conf 文件。

5.监控，不是特别了解但是它完成了9,10特性，对应源码中的nc_proxy 、nc_stats 文件。

参考链接：https://www.cnblogs.com/duanxz/p/15893958.html