redis笔记(2)

1.redis.conf配置详解：

　　1.配置文件unit单位,对大小写不敏感

　　　　

　　2.包含配置,可以将多个配置引入

　　      

　　3.网络配置

             

涵义	命令	注释
绑定的ip地址	bind 127.0.0.1	默认绑定本地，需要远程访问的话设置 bind * 或指定访问的ip
保护模式	protected-mode yes
端口设置	prot 6379

　　4.通用配置

　　　　

涵义	命令	注释
以守护进程的方式进行运行	daemonize yes	默认是no,需要我们自己开启为yes,不然一退出进程就结束了
以后台方式运行需要的pid文件	pidfile /var/run/redis_pid
日志等级	loglevel notice	debug: 大量适用于开发 verbose：很少用 notice：用于生产（默认） warning：只记录非常重要的
日志生成位置	logfile ""	空输出到控制台
数据库数量	databases 16	默认16
是否显示log	always-show-logo yes	默认显示

　　

　　5.快照

　　　　持久化，在规定的时间内，执行了多少次操作,则会持久化到文件rdb.aof

　　　　redis是内存数据库,如果没有持久化那么数据断点就丢失

             

             

　　　  

　　　  

　　　  

 　　6.安全

　　　　

 　　　　配置文件设置密码：

　　　　　　requirepass 123

　　　　命令设置密码：

　　　　　　设置密码：　config set requirepass '123'

　　　　　　获取密码：config get requirepass (设置密码后需要登录才能使用这个命令)

　　　　　　使用密码登录：auth 123

　　7.限制

涵义	命令	注释
设置连接redis的最大客户端数量	maxclients 10000
redis配置最大内存容量	maxmemory <bytes>
内存达到上限之后的处理策略	maxmemory-policy noeviction	策略： volatile-lru :只对设置了过期时间的key进行LRU   allkeys-lru :删除lru算法的key   volatile-random :随机删除即将过期的key   allkeys-random :随机删除   volatile-ttl :删除即将过期   noeviction :永不过期，返回错误

　　

　　8.aof配置

涵义	命令	注释
是否开启aof模式	appendonly no	默认不开启，默认使用rdb方式持久化，在大部分情况下rdb就够用了
持久化文件的名字	appendfilename "appendonly.aof"
每秒执行一次同步	appendfsync everysec	always 每次修改都会执行sync，消耗性能   everysec 每秒执行一次sync，可能会丢失这1s的数据   no 不执行sync,这个时候操作系统自己同步数据，速度最快

2.redis持久化：

　　Redis是内存数据库，如果不将内存中的数据保存在磁盘，那么一旦服务器进程退出，服务器中的数据也会消失，所以redis提供了持久化功能

　　1.RDB（快照机制 直接恢复快照（默认））：优点：恢复快 缺点：数据容易丢失

             

　　在指定的时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot快照，他恢复时将快照文件直接读取到内存里。Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何io操作的，确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化数据可能会丢失。

 

　　rdb保存的文件名是：dump.rdb

　　rdb触发机制：

　　　　1.save 的规则满足的情况下，会自动触发rdb规则

 

　　　　2.执行flushall命令，也会触发rdb规则

 

　　　　3.退出redis，也会产生rdb文件

 

　　恢复rdb文件：

　　　　1.将rdb文件放在redis的启动目录就可以，redis在启动的时候会自动检查dump.rdb文件恢复其中的数据。

 

　　获取存放路径：config get dir

 

　　rdb优点：

　　　　1.如果对数据完整性不高，适合大规模的数据恢复

 

　　rdb缺点：

　　　　1.需要一定的时间间隔进行操作，如果redis进行宕机最后一次的数据会丢失

　　　　2.fork进程时会占用内存空间

 

　　2.AOF(日志机制)

　　　　以日志的形式将我们的每一个写的操作，记到一个日志文件中 ,只许追加文件不可用改写文件，redis启动之初会读取该文件重新构件数据。Aof保存的文件时appendonly.aof

 

　　　　优点：数据保持完整

　　　　缺点：恢复的慢 文件太大

　　　　　　　　　　

 

　　　　aof配置文件

　　　　　　

涵义	命令	注释
是否开启	appendonly no	默认不开启，开启改为yes
文件保存名称	appendfilename "appendonly.aof"
写入方式	appendfsync everysec	always：总是写入   everysec：每一秒写入一次   no：不写入

　　　　　　　　　　

　　　　　　 在aof模式下启动redis,如果aof文件有问题redis会启动失败，可以使用redis-check-aof 文件来恢复aof文件

 

　　　　　　恢复命令：

　　　　　　　　redis-check-aof --fix appendonly.aof

 

　　　　　　aof优点：

　　　　　　　　每一次修改都会同步，文件的完整会更好

 

　　　　　　缺点：

　　　　　　　　修复速度比rdb慢，运行的效率也比rdb速度慢

 

　　　　　　小结：

　　　　　　　　如果同时开启两种持久化方式，redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。

 

3.redis发布订阅：

　　　　　　　　　　　　　　

涵义	命令	注释
订阅频道	subscribe 频道名称
发送信息	publish 频道名称 消息
查询订阅与发布系统状态	pubsub subcommand argument
退订指定的频道	unsubscribe 频道名称

4.redis主从复制：

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

 

　　　 主从复制的作用：

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

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

　　　　　　3.负载均衡：在主从复制的基础上，配合读写分离，由主节点提供写服务，由从节点提供读服务，即写入数据时连接主节点，读取数据时连接从节点，分担服务器压力。

　　　　　　4.高可用的基础：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础

 

　　　　　　

 

主从复制配置：

　　只配置从库，不配置主库

 

　　查询当前库的状态：info replication

　　

 

　　配置单机多集群：

　　　　1.复制redis.conf文件

　　　　2.修改端口

　　　　　　

　　　　3.修改后台进程id(pidfile)

　　　　　　

　　　　4.输出的日志文件

　　　　　　

　　　　5.备份文件名称

　　　　　　

　　　　避免这些文件重复。

　　　　

　　　　使用 .conf 配置文件启动redis命令(在bin下)：redis-server kconfig/redis.conf

 

　　主从复制配置：

　　　　　1.命令配置从机(在从机上设置 )：slaveof 主机ip 主机端口 （命令配置的当redis重启后会失效）

　　　　　2.配置文件配置：

　　　　　　　　windows

　　　　　　　　

　　　　　　　　linux

　　　　　　　　

　　　　　　从机启动成功连接到主机后，从机会发送一个同步命令，主机接收到命令，启动存盘进程，将数据收集完毕后，主机将传送整个数据文件到从机，完成一次同步(全量复制)。

　　　　　　

　　　　　　全量复制：从机在接收到数据库文件数据后，将其存盘并加载到内存中

　　　　　　增量复制：主机继续将新的修改命令依次传给从机，完成同步

　　　　　　

　　　　　　从机只要从新连接主机，就会进行全量复制

5.redis哨兵模式：

　　主从切换：当主服务宕机后将一台从机变成主服务，redis2.8开始提供Sentinel（哨兵）模式来解决这个问题

　　哨兵模式是一种特殊的模式，redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程他会独立的运行。原理是哨兵通过发送命令等待redis服务器响应从而监控运行多个redis实例。

　　　　　

　　哨兵模式作用

　　　　1.通过发送命令，让redis服务器返回运行状态.

　　　　2.哨兵检测到master宕机后会自动将slave切换为master,然后通过发布订阅模式通知其他的服务器修改配置文件让他们切换主机

 

　　　　然而一个哨兵进程对redis服务进行监控可能出现问题，为此我们可以使用多个哨兵进行监控，各个哨兵之间还会进行监控形成了多哨兵模式

　　　　 

　　当部署多个哨兵时，主服务宕机，哨兵1先检测到这个结果系统并不会马上进行failover(故障转移)过程，仅仅一个哨兵主观认为服务器不可用的现象叫主观下线，当后面的哨兵也检测到主服务器不可用并且数量达到一定值时，那么哨兵之间会进行一次投票投票结果由一个哨兵发起，进行failover(故障转移)操作。切换成功后就会通过发布订阅模式，让各个哨兵把自己监控的服务切换主机，这个过程称为客观下线。

 　　哨兵配置：

　　　　1.创建哨兵配置文件(和redis的conf放一起)：sentinel.conf

　　　　2.配置文件内容：

　　　　　　sentinel monitor 被监控的名称(随便起) 监控的ip 监控的端口 1（数字1表示投的票）

　　　　3.启动哨兵：

　　　　　　redis-sentinel kconfig/sentinel.conf

　　　　　　 

　　　　　　如果宕机的主机回来了就会变成从机

　　　　　　

　　　　优点：

　　　　　　　1.哨兵集群基于主从配置，所有主从配置的优点他全有

　　　　　　　2.主从可以切换，故障可以转移，系统可用性好

　　　　　　　3.哨兵是主从模式的升级，手动到自动

　　　　缺点：

　　　　　　1.Redis不好在线扩容，集群容量一旦到达上限，在线扩容十分麻烦

　　　　　　2.哨兵模式的配置有很多

 

哨兵模式配置：

# Example sentinel.conf  
  
# 哨兵sentinel实例运行的端口 默认26379  
port 26379  
  
# 哨兵sentinel的工作目录  
dir /tmp  
  
# 哨兵sentinel监控的redis主节点的 ip port   
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。  
# quorum 配置sentinel哨兵认为master节点宕机数量，就切换master
# sentinel monitor <master-name> <ip> <redis-port> <quorum>  
  sentinel monitor mymaster 127.0.0.1 6379 2  
  
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码  
# sentinel auth-pass <master-name> <password>  
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd  
  
  
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒  
# sentinel down-after-milliseconds <master-name> <milliseconds>  
sentinel down-after-milliseconds mymaster 30000  
  
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，  
# 这个数字越小，完成failover所需的时间就越长，  
# 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。  
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。  
# sentinel parallel-syncs <master-name> <numslaves>  
sentinel parallel-syncs mymaster 1  
  
  
  
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：   
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。  
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。  
#3.当想要取消一个正在进行的failover所需要的时间。    
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了  
# 默认三分钟  
# sentinel failover-timeout <master-name> <milliseconds>  
sentinel failover-timeout mymaster 180000  
  
# SCRIPTS EXECUTION  
  
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。  
#对于脚本的运行结果有以下规则：  
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10  
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。  
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。  
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。  
  
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，  
这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，  
一个是事件的类型，  
一个是事件的描述。  
如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。  
#通知脚本  
# sentinel notification-script <master-name> <script-path>  
  sentinel notification-script mymaster /var/redis/notify.sh  
  
# 客户端重新配置主节点参数脚本  
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。  
# 以下参数将会在调用脚本时传给脚本:  
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>  
# 目前<state>总是“failover”,  
# <role>是“leader”或者“observer”中的一个。   
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的  
# 这个脚本应该是通用的，能被多次调用，不是针对性的。  
# sentinel client-reconfig-script <master-name> <script-path>  
 sentinel client-reconfig-script mymaster /var/redis/reconfig.sh