13.安心技术梳理 - Redis集群同步问题和Redis知识点

0.Redis事务
Redis中的事务（transaction）是一组命令的集合，事务同命令一样，都是Redis的最小执行单位，一个事务中的命令，要么都执行，要么都不执行。
Redis事务的实现需要用到MULTI和EXEC两个命令，事务开始的时候先向Redis服务器发送 MULTI 命令，然后依次发送需要在本次事务中处理的命令，最后再发送 EXEC 命令表示事务命令结束。
Redis的事务是下面4个命令来实现：
multi：开启Redis的事务，置客户端为事务态；
exec：提交事务，执行从multi到此命令前的命令队列，置客户端为非事务态；
discard：取消事务，置客户端为非事务态；
watch：监视键值对。作用时，如果事务提交exec时发现监视的键值对发生变化，事务将被取消。

1.Redis是一个基于内存的高性能key-value数据库

redis之所以能解决高并发的原因是它可以直接访问内存，而以往我们用的是数据库(硬盘),提高了访问效率,解决了数据库服务器压力。
为什么redis的地位越来越高，我们为何不选择memcache，这是因为memcache只能存储字符串，而redis存储类型很丰富（例如有字符串、LIST、SET等），memcache每个值最大只能存储1M,存储资源非常有限,十分消耗内存资源,而redis可以存储1G,最重要的是memcache它不如redis安全,当服务器发生故障或者意外关机等情况时,redsi会把内存中的数据备份到硬盘中,而memcache所存储的东西全部丢失;这也说明了memcache不适合做数据库来用,可以用来做缓存。

Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符）

文件事件处理器使用 I/O 多路复用模块同时监听多个 FD，当 accept、read、write 和 close 文件事件产生时，文件事件处理器就会回调 FD 绑定的事件处理器。

虽然整个文件事件处理器是在单线程上运行的，但是通过 I/O 多路复用模块的引入，实现了同时对多个 FD 读写的监控，提高了网络通信模型的性能，同时也可以保证整个 Redis 服务实现的简单。

I/O 多路复用模块

I/O 多路复用模块封装了底层的 select、epoll、avport 以及 kqueue 这些 I/O 多路复用函数，为上层提供了相同的接口。

在这里我们简单介绍 Redis 是如何包装 select 和 epoll 的，简要了解该模块的功能，整个 I/O 多路复用模块抹平了不同平台上 I/O 多路复用函数的差异性，提供了相同的接口，在 I/O 多路复用模型中，最重要的函数调用就是 select，该方法的能够同时监控多个文件描述符的可读可写情况，当其中的某些文件描述符可读或者可写时，select 方法就会返回可读以及可写的文件描述符个数。

2.Redis基本数据类型及应用场景

string(字符串)  

String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。 
常规key-value缓存应用；

list(列表)  

list就是链表，略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。List的另一个应用就是消息队列，可以利用List的PUSH操作，将任务存在List中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段的api，你可以直接查询，删除List中某一段的元素。 
Redis的list是每个子元素都是String类型的双向链表，可以通过push和pop操作从列表的头部或者尾部添加或者删除元素，这样List即可以作为栈，也可以作为队列。

消息队列系统 
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。 
比如：将Redis用作日志收集器 
实际上还是一个队列，多个端点将日志信息写入Redis，然后一个worker统一将所有日志写到磁盘。

hash(散列)   

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 
存储部分变更的数据，如用户信息等。

sets (集合)  

set就是一个集合，集合的概念就是一堆不重复值的组合。利用Redis提供的set数据结构，可以存储一些集合性的数据。set中的元素是没有顺序的。

sorted set(有序集合)

和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列，比如一个存储全班同学成绩的sorted set，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。可以用sorted set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

3.Redis分布式支持主从的模式（保证最终一致性，不能保证强一致性）

原则：

Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。

典型的读写分离模型。利用master来插入数据，slave提供检索服务。有效减少单个机器的并发访问数量。

读写分离模型：

通过增加Slave DB的数量，读的性能可以线性增长，为了避免Master DB的单点故障，集群一般都会采用两台Master DB 做双机热备，所以整个集群的读和写的可用性都非常高。

缺陷：

不管是Master还是Slave，每个节点都必须保存完整的数据，如果在数据量很大的情况下，集群的扩展能力是受限于单个节点的存储能力，而且对于Write-intensive类型的应用，读写分离架构并不适合。

为了解决读写分离模型的缺陷，可以将数分片模型应用进来。可以将每个节点看成都是master，然后通过业务实现数据分片。结合两种模型，可以将每个master设计成由一个master和多个slave组成的模型。
 

4.Redis优点：

a.单线程，利用redis队列技术并将访问变为串行访问，消除了传统数据库串行控制的开销
b.redis具有快速和持久化的特征，速度快，因为数据存在内存中。
c.分布式 读写分离模式
d.支持丰富数据类型
e.支持事务，操作都是原子性，所谓原子性就是对数据的更改要么全部执行，要不全部不执行。
f.可用于缓存，消息，按key设置过期时间，过期后自动删除

5.回收策略

从最近最少使用的数据淘汰,挑选将要过期的数据淘汰
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据

6.Redis和memcache对比和区别

a.memcache所有的值均是简单的字符串，redis支持更为丰富的数据类型
b.redis速度比memcached快很多
c.redis支持持久化
d.存储方式 memcache存在内存中，redis存在硬盘中，保证数据持久化
e.使用底层模型不同:底层实现方式以及客户端之间通信的应用协议不一样
f.redis最大可以达到1G而memcache只有1MB

7.Redis持久化和快照

redis提供了不同级别的持久化方式，一种是RDB，一种AOF。可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB：在指定的时间间隔能对数据进行快照存储(隔一段时间,把内存里的数据转存在硬盘里的文件)
优点：
RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如您可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题您也可以根据需求恢复到不同版本的数据集.
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.
缺点：
如果您希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合您.虽然您可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,您通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,您可能会丢失几分钟的数据.
RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是您可以调节重写日志文件的频率来提高数据集的耐久度.

AOF：每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
优点：
使用AOF 会让您的Redis更加耐久: 您可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，您最多丢失1秒的数据.
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,您也也可使用redis-check-aof工具修复这些问题.
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果您不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
缺点：
对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
 

快照：

在默认情况下,Redis 将数据库快照保存在名字为dump.rdb的二进制文件中。您可以对 Redis 进行设置,让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时,自动保存一次数据集.您也可以通过调用SAVE或者BGSAVE,手动让 Redis 进行数据集保存操作
比如说,以下设置会让Redis在满足“60秒内有至少有1000个键被改动”这一条件时， 自动保存一次数据集:save 60 1000
这种持久化方式被称为快照snapshotting

 

Redis集群中主从数据同步是从库异步读取主库，那么Redis集群其他主与主之间的数据是怎么共享的呢？或者说是怎么同步的？

以下为同步流程图：

 

纸上得来终觉浅，绝知此事要躬行