Redis

 

　　Redis的整个运行处理过程中所需要的数据集都是在内存中进行，所以其性能是不逊于memcached的；并且Redis还支持数据持久化，可以将内存中的数据周期的存储到磁盘中，这是memcached所不具备的；但是Redi是单线程服务，也就是说其工作时只有一个线程在接收请求和响应，而memcached是具有多线程的；

　　下载地址：http://download.redis.io/releases/
　　Redis至基于Key/Value的模式进行数据存储的，且Key还支持自动过期机制；
　　Redis的持久化：
　　　　RDB：
　　　　　　类似于snapshot机制，以二进制格式存储，即按事先制定的策略周期性的将数据保存至磁盘中，数据文件默认为dump.rdb，也是默认使用的持久化机制；可以在配置文件中使用save参数指定周期长度（其中save ""表示关闭RDB机制）；
　　　　　　客户端可以显示的使用SAVE或BGSAVE命令启动快照保存机制；
　　　　　　　　SAVE：同步方式，在主线程中保存快照，此时会阻塞所有客户端的请求；
　　　　　　　　BGSAVE：异步方式，在后台自动完成备份，不会阻塞客户端的请求；
　　　　　　工作模式：
　　　　　　　　首先Redis会调用fork创建一个子进程，父进程自己会继续处理各客户端发来的请求，而子进程将内存中的数据快照到磁盘中；因为写时复制机制，父子进程会共享相同的物理页面；当父进程处理写请求时操作系统会为父进程要修改的页面创建一个副本，因此子进程实现的保存与父进程是时间点一致的；当子进程完成将数据写进临时文件后，会用临时文件替换原来的文件，最后子进程完成任务自动退出；
　　　　AOF：
　　　　　　Append Only FIle，记录每一次Redis的写操作至指定文件的尾部实现数据的持久化；当Redis重启时，可通过重新执行文件中的命令在内存重新构建数据库；且可以通过BGREWRITEAOF命令可以实现AOF文件的重写，重写时它不会读取正在使用的AOF文件，而是通过将内存（因为Redis是将所有数据都放在内存中处理的）中的数据以命令的方式保存到临时文件中，完成以后使用这个临时文件替换原来的AOF文件；
　　　　　　重写过程：
　　　　　　　　a.Redis主进程通过fork创建子进程
　　　　　　　　b.子进程根据Redis内存中的数据创建数据库重建命令序列于临时文件中；
　　　　　　　　c.父进程继续接受客户端的请求，并会把这其中的写请求操作继续追加至原来的AOF文件中；并且这些新的写操作还会被放置于一个缓冲队列中；
　　　　　　　　d.子进程重写完成会通知父进程，父进程接着会将缓冲中的新的写操作追加到临时文件中；
　　　　　　　　e.父进程用临时文件替换来的AOF文件；
　　　　　　写入周期：
　　　　　　　　通过配置文件中的appendfsync {always|everysec|no}参数来设置；
　　　　　　　　　　always：只要有相关的操作就写入磁盘；
　　　　　　　　　　everysec：每秒写入一次；
　　　　　　　　　　no：不使用append功能执行写入操作，而是通过操作系统自行决定什么时候进行写入磁盘操作；
　　　　　　通过配置文件中的appendonly参数来设置是否启用AOF持久化机制，默认为no；
　　　　Note：数据的持久化不能代替备份，所以定期备份Redis数据还是必要的；
　　　　RDB与AOF同时启用：
　　　　　　1.BGSAVE和BGREWRITEAOF不会同时执行；
　　　　　　2. 当Redis重新启动时会优先使用AOF中记录的数据，因为AOF的数据比较新；
　　Redis复制：
　　　　1.一个Master可以有多个Slave
　　　　2.支持链式复制，即一个Slave可以是另一个Slave的Master
　　　　3.Master以非阻塞方式同步数据至Slave；即Master会继续处理Slave的读写请求的；
　　　　复制机制：
　　　　　　1.Master会挺过PING探测Slave服务器是否在线，如果在线的话就同步数据文件（Slave也可以向Master请求同步数据文件）；
　　　　　　2.Master会将本地存储的数据快照文件发送给Slave，然后再由Slave中的Redis将文件中的数据加载到内存中，从而完成数据重建；
　　　　配置步骤：在Slave节点上操作
　　　　　　方法一：192.168.80.129:6379> SLAVEOF 192.168.80.128 6379（首先使用redis-cli进入redis）
　　　　　　方法二：在配置文件中添加slaveof 192.168.80.128 6379参数
　　　　　　然后可以在Slave中执行"KEYS *"测试一下是否同步完成；或者使用INFO Replication命令查看master_link_status是否up；
　　　　　　Note：在定义bind参数时，要把主从节点同步数据时使用的IP地址写在本地回环地址之前；
　　　　　　在Redis复制机制中还可以设置当从服务器的数量少于指定个数时，让主服务器停止接收写操作请求；
　　　　　　　　配置文件中的相关参数
　　　　　　　　　　min-salves-to-write NUM 指定最少的Slave个数
　　　　　　　　　　min-slaves-max-lag NUM 指定Slave的时间不能滞后于Master时间的秒数；
　　　　　　Note：如果Master节点使用requirepass参数开启了认证功能，则Slave节点在连入Master时要使用masterauth参数来指定密码；
　　　　Redis复制的sentinel机制：
　　　　　　sentinel可以用于监控主服务器，如果主服务器故障则选择另一个从服务器作为主服务器继续提供服务，并且sentinel还可以通知客户端新的主节点的地址；sentinel也可以搭建成集群，放置sentinel节点故障；
　　　　　　Note：为了放置分裂以后无法确定主从，一般集群中的节点数都为奇数，其仲裁作用；
　　　　　　执行过程：
　　　　　　　　1.服务器自身初始化，运行redis-server中专用于sentinel功能的代码；
　　　　　　　　2.初始化sentinel状态，根据给定的配置文件，初始化监控的Master服务器列表；
　　　　　　　　3.创建连向Master的连接；
　　　　配置方式：
　　　　　　配置参数：

sentinel monitor <master-name> <ip> <redis-port> <quorum>
指定Master节点；sentinel节点会通过主节点获取从节点信息；
　　<master-name>：指定主节点的名称，随意指定；
　　<ip>：主节点的IP地址；
　　<redis-port>：主节点中redis监听的端口号；
　　<quorum>：sentinel的法定票数；只有在sentinel集群具有指定数量的sentinel节点在线且可用时才认为集群是有效的；
sentinel down-after-milliseconds <master-name> <milliseconds>
指定Master节点在多长时间联系不上以后将其视为故障状态；单位默认为毫秒；
sentinel parallel-syncs <master-name> <numslaves>
指定当主服务器切换后，最多允许多少个从服务器同时来同步数据；
sentinel failover-timeout <master-name> <milliseconds>
指定将从服务器提升为主服务器时，如果超过指定时间还没有提升成功就认为提升失败；即故障转移的超时时间；

　　　　启动：
　　　　　　在启动redis服务时指定"--sentinel"参数且还需指定配置文件路径，或者直接启动redis-sentinel.service（Centos7中：systemctl status redis-sentinel.service）服务；
　　下线方式：
　　　　主观下线：一个sentinel节点联系不到主节点则主观认为Master节点故障：
　　　　客观下线：征求其他sentinel节点，如果其他sentinel也认为Master节点故障，则客观认为Master节点故障；
　　专用命令：

SENTINEL masters 列出所有监视的主服务器；
SENTINEL slaves <master name> 列出某主节点的从节点；
SENTINEL get-master-addr-by-name <master name> 根据Master名称获取其IP地址；
SENTINEL reset 清除服务器的状态；
SENTINEL failover <master name> 手动进行Master节点的故障转移；

　　　　Note：如果配置了sentinel节点，则要保证客户端到sentinel获取信息，从而使客户端获得Master节点的信息（IP地址）；
　　Redis的Cluster：
　　　　分布式数据库，通过分片机制进行数据分析，clustering内的每个节点仅存储整个数据库的一部分数据，但是每个节点持有全局的元数据；

 

注：根据马哥视频做的学习笔记，如有错误，欢迎指正；侵删