redis集群模式、持久化

短命女 2022-04-25 06:24 309阅读 0赞

**Redis特点：**  
        存取快速：Redis数据库完全在内存中，因此处理速度非常快，每秒能执行约11万集合，每秒约81000+条记录  
        数据持久化：Redis支持数据持久化，可以将内存中的数据存储到磁盘上，方便在宕机等突发情况下快速恢复  
        数据一致性：所有Redis操作是原子的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值  
        支持丰富的数据类型：相比许多其他的键值对存储数据库，Redis拥有一套较为丰富的数据类型，支持存储string、list、hash、set、SortedSet等  
        多功能实用工具：Redis是一个多实用的工具，可以用于如缓存、消息队列(Redis原生支持发布/订阅)、任何短暂的数据、应用程序、如Web应用程序会话、网页命中计数等

** redis主从模式：**  
        避免Redis单点故障，构建读写分离架构，满足读多写少的应用场景  
        在Redis中设置主从有2种方式：  
            在redis.conf中设置slaveof：如：slaveof <masterip> <masterport>  
            在启动从服务时设置：如：redis-server -h <slaveip> -p <slaveport> --slaveof <masterip> <masterport>   或  使用Redis客户端连接上slave服务，执行slaveof 192.168.29.128 6379，该种方式在重启后将失去主从复制关系  
            默认情况下redis数据库充当slave角色时是只读的不能进行写操作，可以在redis.conf配置文件中开启非只读：slave-read-only no  
        Redis主从的几种方式：  
            一主一从，一主多从（主从主从、主从从），Redis的主从架构的缺点是所有的slave节点数据的复制和同步都由master节点来处理，会照成master节点压力太大，所以可以使用主从从结构来处理  
            取消Redis主从关系，可以在对应的从库执行slaveof no one  
        主从复制的过程原理：  
            当从库和主库建立MS关系后，会向主数据库发送SYNC命令  
            主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存起来  
            当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis，从Redis接收到后会载入快照文件并且执行收到的缓存的命令  
            之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致  
        无磁盘复制：  
            通过前面的复制过程我们了解到，主库接收到SYNC的命令时会执行RDB过程，即使在配置文件中禁用RDB持久化也会生成，那么如果主库所在的服务器磁盘IO性能较差，那么这个复制过程就会出现瓶颈，Redis在2.8.18版本开始实现了无磁盘复制功能  
            原理为主Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘，而是直接通过网络发送给从数据库，避免了IO性能差问题  
            开启无磁盘复制：repl-diskless-sync yes

** redis哨兵(sentinel)模式：**  
        当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续提供服务，然而整个过程相对麻烦且需要人工介入，难以实现自动化，为此Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能  
        Redis-Sentinel是用于管理Redis主从，该系统执行以下三个任务：  
            监控主数据库和从数据库是否正常运行  
            当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器（根据优先级选，如果一样就选个id小的），并让失效主服务器的其他从服务器改为复制新的主服务器，当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器  
        哨兵配置：  
            按主从配置启动好Redis主从数据库  
            sentinel.conf文件配置   sentinel monitor mymaster1（主数据的名称,自定义即可,可以使用大小写字母和“.-\_”符号） <masterip> <masterport> <quorum>  
            可以三台主从服务都启动哨兵服务（哨兵间通讯保证高可用）  redis-sentinel sentinel.conf  
        Sentinel原理：  
            SDOWN：subjectively down，直接翻译的为”主观”失效，即当前sentinel实例认为某个redis服务为”不可用”状态  
            ODOWN：objectively down，直接翻译为”客观”失效，即多个sentinel实例都认为master处于”SDOWN”状态，那么此时master将处于ODOWN，ODOWN可以简单理解为master已经被集群确定为”不可用”，将会开启failover  
            SDOWN与ODOWN转换过程：  
                每个sentinel实例在启动后，都会和已知的master/slaves以及其他sentinels建立TCP连接，并周期性发送PING(默认为1秒)，在交互中如果redis-server无法在”down-after-milliseconds”时间内响应或者响应错误信息，都会被认为此redis-server处于SDOWN状态  
                若SDOWN的server为master，那么此时sentinel实例将会向其他sentinel间歇性(1秒)发送”is-master-down-by-addr <ip> <port>”指令并获取响应信息，如果足够多的sentinel实例检测到master处于SDOWN，那么此时当前sentinel实例标记master为ODOWN，其他sentinel实例做同样的交互操作，配置项中”sentinel monitor <mastername> <masterip> <masterport> <quorum>”，如果检测到master处于SDOWN状态的sentinel个数达到<quorum>，那么此时此sentinel实例将会认为master处于ODOWN  
                每个sentinel实例将会间歇性(10秒)向master和slaves发送”INFO”指令，如果master失效且没有新master选出时，每1秒发送一次”INFO”，”INFO”的主要目的就是获取并确认当前集群环境中master和slaves的存活情况  
                经过上述过程后，所有的sentinel对master失效达成一致后，开始failover  
            Sentinel与slaves”自动发现”机制：  
                在sentinel的配置文件中，都指定了port，此port就是sentinel实例侦听其他sentinel实例建立链接的端口，在集群稳定后，最终会每个sentinel实例之间都会建立一个tcp链接，此链接中发送”PING”以及类似于”is-master-down-by-addr”指令集，可用用来检测其他sentinel实例的有效性以及”ODOWN”和”failover”过程中信息的交互，在sentinel之间建立连接之前，sentinel将会尽力和配置文件中指定的master建立连接，sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息，发布的信息内容包括当前sentinel实例的侦听端口

**redis集群模式(redis Cluster)：**  
        由于Redis主从复制架构每个数据库都要保存整个集群中的所有数据，容易形成木桶效应，为了最大化利用内存，可以采用集群，就是分布式存储，即每台redis存储不同的内容  
        Cluster环境搭建：修改redis.conf  
            修改pidfile指向路径        pidfile /opt/redis/6379/redis\_6379.pid  
            开启允许集群    cluster-enabled yes  
            修改集群配置文件指向路径    cluster-config-file nodes-6379.conf  
            分别启动redis服务，查看redis状态，发现虽然已经是以集群方式启动了，但是redis之间关系还没确定下来  
            安装ruby环境：    yum -y install zlib ruby rubygems  
            安装集群工具：    gem install redis   
            执行命令：    redis-trib.rb  create --replicas 1 主ip:主端口 主ip:主端口 主ip:主端口 从ip:从端口 从ip:从端口 从ip:从端口  
        新增集群节点：  
            先启动需要增加的节点服务  
            执行以下命令，将这个新节点添加到集群中：redis-trib.rb add-node 主ip:主端口  
            增加了新的节点之后，这个新的节点可以成为主节点或者是从节点  
                变成从节点：redis-cli -c -p 7006 cluster replicate 某个主节点ID  
                变成主节点：redis-trib.rb reshard ip:端口，然后分配哈希槽  
        删除集群节点：  
            将这个节点上的所有插槽转移到其他节点上，执行命令：redis-trib.rb reshard 主ip:主端口  
            然后系统提示我们输入要接收这些哈希槽的节点的ID，这里选择一个或多个主节点ID

**redis持久化：**  
       ** RDB：**  
            RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储  
            优势：  
                一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的，比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据，通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复  
                对于灾难恢复而言，RDB是非常不错的选择，因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上  
                性能最大化，对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了  
                相比于AOF机制，如果数据集很大，RDB的启动效率会更高  
            劣势：  
                如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择，因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失  
                由于RDB是通过fork子进程来协助完成数据持久化工作的，因此如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟  
            常用配置：  
                save 900 1             在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照  
                save 300 10            在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照  
                save 60 10000        在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照  
        **AOF：**  
            AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录  
            优势：  
                该机制可以带来更高的数据安全性，即数据持久性，Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失，而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变 化都会被立即记录到磁盘中，可以预见，这种方式在效率上是最低的  
                由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容，然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题  
                Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写，重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合，整个重写操作是绝对安全的，因为Redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失，而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作  
                AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作，事实上，我们也可以通过该文件完成数据的重建  
            劣势：  
                对于相同数量的数据集而言，AOF文件通常要大于RDB文件，RDB在恢复大数据集时的速度比AOF的恢复速度要快  
            常用配置：  
                appendfsync always        每次有数据修改发生时都会写入AOF文件  
                appendfsync everysec    每秒钟同步一次，该策略为AOF的缺省策略  
                appendfsync no            从不同步，高效但是数据不会被持久化

**redis与memcache比较：**  
        Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储  
        memcached使用key-value形式存储和访问数据，在内存中维护一张巨大的HashTable，使得对数据查询的时间复杂度降低到O(1)，保证了对数据的高性能访问  
        Redis支持数据的备份，即master-slave模式的数据备份  
        Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用  
        memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述字pipe传递给worker线程，进行读写IO  
        redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单存只有IO操作来说，单线程可以将速度优势发挥到最大