redis 持久化 哨兵 主从

                            Redis搭建步骤

环境：

三台机器  centos7

关闭防火墙 selinux

Redis版本 3.0.5

依赖环境

yum install gcc-c++ ruby rubygems –y

把版本包上传到服务器上，redis-3.0.5.tar.gz

解压tar -zxvf redis-3.0.5.tar.gz

而后进入目录

cd redis-3.0.5

直接make

而后进入

cd /redis/redis-3.0.5/src/

make install

而后把启动文件还有配置文件移除到其余地方方便管理

   mkdir -p/usr/local/redis/bin

   mkdir -p /usr/local/redis/bin

   mkdir -p /usr/local/redis/etc

移动文件

mv redis.conf /usr/local/redis/etc/

如下文件在src目录里：

mv mkreleasehdr.sh redis-benchmark redis-check-aof redis-check-dump redis-cli redis-server /usr/local/redis/bin/

方便后台启动须要改动redis.conf 配置文件

Vim redis.conf首先编辑conf文件，将daemonize属性改成yes（代表须要在后台运行）

redis-server /usr/local/redis/etc/redis.conf  完成单点

 

经常使用命令：

 

Redis：

Redis-server /usr..../redis.conf 启动redis服务，并指定配置文件

Redis-cli 启动redis 客户端

Pkill redis-server 关闭redis服务

Redis-cli shutdown 关闭redis客户端

Netstat -tunpl|grep 6379 查看redis 默认端口号6379占用状况

 

Redis集群模式（主从）

     主库不须要动

     从库修改salveof 后面添加主库IP + redis端口号

     配置主服务器

一、进入192.168.2.100服务器，打开redis配置文件

[root@localhost redis-4.0.10]# vim /etc/redis/6379.conf

1

二、将bind 127.0.0.1这行注释或者指定ip。（本例是注释，即全部ip都能链接）

 

 

 

三、开启守护进程

 

 

 

 

四、设置访问密码（因为redis性能很是高，撞库风险极大，建议线上把密码设置很是复杂，最好能在第2步中指定ip）

 

 

 

 

注意：

固然，既然用到主从了，那说明对redis依赖很是高，还有几个参数须要根据服务器配置来设置

第一个就是客户端最大链接数（maxclients），默认是10000，可根据需求更改

 

 

 

第二个就是最大内存（默认不受限制，但若是有多个从服务器，建议仍是设置个低于服务器内存的值）

 

 

 

第三个是内存策略，若是内存足够用则不用管，若是内存不够用，建议设置最近最少使用策略（LRU）,默认是内存不够则报错

 

 

 

至此主服务器配置完毕！

 

3、配置从服务器

前四步与主服务器配置基本一致

五、配置所属主服务器ip和端口

 

 

 

六、配置所属主服务器的密码（再次强调，要将密码设置很是复杂，这里只是演示）

 

 

 

须要注意的是，从服务器一般是只读，因此要配置只读（默认是只读，不要更改便可）

 

 

 

配置完成，启动服务

1

4、测试

使用redis客户端或者telnet均可以

本次使用redis客户端

 

 

 

一、进入主服务器（192.168.2.100）

进入redis客户端

 

[root@localhost redis-4.0.10]# /usr/local/redis/bin/redis-cli

1

因为设置了密码，因此须要鉴权

 

 

 

设置一个值

 

 

 

 

二、进入从服务器（192.168.2.101）

使用get命令获取name的值，能够看到

 

 

 

表明配置成功

若是在从服务器上写，则会报错，以下图

 

 

 

 

至此，redis主从复制配置完成，若是须要配置多台从服务器，能够重复第三步

 

主从复制原理：

　　　1.当从库和主库创建MS关系后,会向主数据库发送SYNC命令

　　   2.主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来

          3.当快照完成后,主Redis会将快照文件和全部缓存的写命令发送给从Redis

         4.从Redis接收到后,会载入快照文件而且执行收到的缓存的命令

         5.以后,主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致

 

 Redis Sentinel (哨兵)部署

　　　　Sentinel介绍：Sentinel是Redis的高可用性（HA）解决方案，由一个或多个Sentinel实例组成的Sentinel系统能够监视任意多个主服务器，以及这些主服务器属下的全部从服务器，并在被监视的主服务器进行下线状态时，

　　自动将下线主服务器属下的某个从服务器升级为新的主服务器，而后由新的主服务器代替已下线的主服务器继续处理命令请求。Redis提供的sentinel（哨兵）机制，经过sentinel模式启动redis后，

　　自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决（每一个sentinel只有一次选举的机会，当主库出现故障，哨兵会投票从库中选出一个承担主库的任务，剩下的仍是从库）

　　　　Sentinel做用:

1. 监控：监控主从是否正常
   2. 通知：出现问题时，能够通知相关人员
   3. 自动故障迁移：自动主从切换
   4. 统一的配置管理：链接者询问sentinel取得主从的地址

部署哨兵

yum install gcc-c++ ruby rubygems –y

须要单独一个机器作哨兵部署

配置文件在redis包里名字sentinel.conf

配置以下

          protected-mode no      （去掉注释）
            daemonize yes          （自行添加守护进程）
            dir /tmp
            logfile "/var/log/redis/redis_26379.log"    （自行添加哨兵的日志）
            sentinel monitor mymaster 192.168.52.138 6379 2   （原基础上更改）
            sentinel down-after-milliseconds mymaster 30000   （默认）
            sentinel parallel-syncs mymaster 1                （默认）
            sentinel failover-timeout mymaster 180000         （默认）  ）

 

 

 

 

 

 

Redis持久化

都在redis.conf中配置

 

  1、RDB持久化

1.1介绍

RDB方式是经过快照完成的,当符合必定的条件时,redis会自动将内存中的全部数据进行快照而且存储到硬盘上，默认存储在redis根目录的dump.rdb文件中(文件名在配置文件中dbfilename),进行快照的条件在redis.conf配置文件中指定，有两个参数构成，时间和改动的键的个数，当在指定时间被更改的键的个数大于指定数值时就会进行快照，RDB是redis默认的持久化方式

1.2快照过程

当redis须要作持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉,而后子进程退出

1.3RDB持久化配置

RDB是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：
save 900 1
save 300 10
save 60 10000

save 开头的一行就是持久化配置，能够配置多个条件（每行配置一个条件），每一个条件之间是“或”的关系，“save 900 1”表示15分钟（900秒钟）内至少1个键被更改则进行快照，“save 300 10”表示5分钟（300秒）内至少10个键被更改则进行快照。"60 10000"表示60秒内有10000个key出现变动  作一次快照

在redis.conf中：

配置dir指定rdb快照文件的位置

配置dbfilenam指定rdb快照文件的名称

1.4RDB的优缺点

RDB的优势：

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是很是完美的。好比，你可能打算每一个小时归档一次最近24小时的数据，同时还要天天归档一次最近30天的数据。经过这样的备份策略，一旦系统出现灾难性故障，咱们能够很是容易的进行恢复。

2). 对于灾难恢复而言，RDB是很是不错的选择。由于咱们能够很是轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它惟一须要作的只是fork出子进程，以后再由子进程完成这些持久化的工做，这样就能够极大的避免服务进程执行IO操做了。

4). 相比于AOF机制，若是数据集很大，RDB的启动效率会更高。

RDB的缺点：

1). 若是你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。由于系统一旦在定时持久化以前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 因为RDB是经过fork子进程来协助完成数据持久化工做的，所以，若是当数据集较大时，可能会致使整个服务器中止服务几百毫秒，甚至是1秒钟。

2、AOF持久化

1.1介绍

redis会将每个收到的写命令都经过write函数追加到文件中(默认是 appendonly.aof)。AOF就能够作到全程持久化，只须要在配置文件中开启（默认是no不开启的）,开启AOF以后，（默认是：每秒fsync一次）

1.2持久化过程

Redis 执行 fork() ，如今同时拥有父进程和子进程。子进程开始将新 AOF 文件的内容写入到临时文件。对于全部新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即便在重写的中途发生停机，现有的 AOF 文件也仍是安全的。当子进程完成重写工做时，它给父进程发送一个信号，父进程在接收到信号以后，将内存缓存中的全部数据追加到新 AOF 文件的末尾。如今 Redis 原子地用新文件替换旧文件，以后全部命令都会直接追加到新 AOF 文件的末尾。

1.3AOF的配置

开启AOF持久化

appendonly yes #启用aof持久化方式

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不一样步。高效可是数据不会被持久化。

AOF持久化文件的名称

appendfilename “appendonly.aof”

1.4如何修复坏损的AOF文件：

将现有已经坏损的AOF文件额外拷贝出来一份

执行”redis-check-aof –fix ”命令来修复坏损的AOF文件。

用修复后的AOF文件从新启动Redis服务器。

1.5AOF的优缺点

AOF的优势：

1). 该机制能够带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不一样步。事实上，每秒同步也是异步完成的，其效率也是很是高的，所差的是一旦系统出现宕机现象，那么这一秒钟以内修改的数据将会丢失。而每修改同步，咱们能够将其视为同步持久化，即每次发生的数据变化都会被当即记录到磁盘中。能够预见，这种方式在效率上是最低的。至于无同步，无需多言，我想你们都能正确的理解它。
2). 因为该机制对日志文件的写入操做采用的是append模式，所以在写入过程当中即便出现宕机现象，也不会破坏日志文件中已经存在的内容。然而若是咱们本次操做只是写入了一半数据就出现了系统崩溃问题，不用担忧，在Redis下一次启动以前，咱们能够经过redis-check-aof工具来帮助咱们解决数据一致性的问题。
3). 若是日志过大，Redis能够自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会建立一个新的文件用于记录此期间有哪些修改命令被执行。所以在进行rewrite切换时能够更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录全部的修改操做。事实上，咱们也能够经过该文件完成数据的重建。

AOF的劣势：

1). 对于相同数量的数据集而言，AOF文件一般要大于RDB文件。 2). 根据同步策略的不一样，AOF在运行效率上每每会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB同样高效。