目录一、单节点redis的问题二、Redis持久化1.RDB2.AOF三、Redis主从集群1.主从集群结构2.全量同步3.增量同步四、Redis哨兵1.哨兵作用2.RedisTemplate连接哨兵五、Redis分片集群1.分片集群结构2.搭建分片集群3.散列插槽4.集群伸缩5.主从切换2.RedisTemplate连接分片集群一、单节点redis的问题1.Redis是内存存储数据容易丢失2.由于是内存存储且采用单线程 多路 I/O 复用模型避免线程切换开销redis的并发能力远强于多线程磁盘mysql但是单结点redis仍无法满足高并发场景3.现代项目对redis依赖非常高如果redis宕机将造成非常严重的损失所以需要一种自动的故障恢复手段单节点redis无法实现。4.redis基于内存存储单节点存储的数据量难以满足海量数据需求。二、Redis持久化1.RDB将内存中的所有数据记录到磁盘的rdb文件中当redis重启后从磁盘读取rdb快照文件恢复数据。Redis正常停机时的持久化机制redis在停机前会自动保存rdb数据到磁盘当前项目工作目录下然后才会执行停机指令。当启动redis时会自动读取当前工作目录下的rdb文件并加载到内存中。实现数据快照的命令savesave命令由redis主进程来执行会阻塞所有命令因为redis是单线程的适合正常redis手动停机时使用bgsavebgsave命令会开启异步子进程执行持久化不影响主进程适合redis运行过程中持久化内存数据异常停机时缓解数据丢失的解决方案redis的redis.conf配置文件中可以修改bgsave命令的触发频率save 900 1900s内如果至少有1个key被修改save 300 10300s内如果至少有10个key被修改save 60 1000060s内如果至少有10000个key被修改则执行bgsave命令bgsave执行流程操作系统forkredis主进程得到一个子进程与主进程共享内存空间fork过程中主进程阻塞子进程创建后主进程正常工作子进程读取内存数据写入一个新的rdb文件将新的rdb文件覆盖旧的rdb文件bgsave读到的数据是当前时刻的快照主线程仍然能够执行写操作所以数据并不是最新的。RDB缺点bgsave的触发频率如果时间设置太短那么频繁创建子进程和写rdb文件非常影响性能时间设置太长会出现向内存写入数据后触发还未执行redis就宕机导致数据丢失。2.AOF与RDB将内存数据存储到磁盘中不同AOF是将redis执行的每一条写命令以追加的方式记录在磁盘的aof日志文件中当服务宕机重启后通过重新执行这些写命令来完成数据恢复与RDB的bgsave一样也是一种缓解异常停机导致数据丢失的解决方案。AOF的触发频率在redis.conf中配置appendfsync always每执行一条写命令立即写入aof文件中appendfsync everysec将写命令暂存到OS为redis分配的缓冲区每隔1s将缓冲区的所有命令写入aof文件默认方案appendfsync no将写命令暂存到缓冲区由操作系统决定何时将缓冲区内容写回磁盘bgrewriteaof命令aof文件会记录一些没有意义的命令例如对同一个key执行多次set操作那么所有的set操作都会被记录到aof文件中但是实际上只有最后一次set才有意义其余set没必要记录。有点马后炮的意思bgrewriteaof可以对aof文件执行重写功能减少无效命令的记录也是使用fork开辟异步线程来执行覆写功能避免影响主线程redis的redis.conf配置文件中可以修改bgrewriteaof命令的触发频率auto-aof-rewrite-percentage 100aof文件相比上次触发文件体积增长超过百分之多少才会触发重写auto-aof-rewrite-min-size 64mbaof文件体积达到多少mb以上才触发重写总结三、Redis主从集群1.主从集群结构由于redis业务读多写少所以主从集群的多个从节点用来处理读请求主节点完成写请求并将数据同步到从节点主从集群主要是解决redis高并发读问题。在redis中通过slaveof ip port命令来为某个主节点色值从节点多个节点位于不同端口主节点写的数据可以被从节点读取数据同步但是从节点不可以修改主节点的数据只能读。从节点数据是主节点的异步复制结果存在毫秒级延迟强一致性要求的读请求如支付、订单必须走主节点。主节点写:设置从节点、从节点读2.全量同步执行slaveof时会确定节点之间的主从关系此时需要进行全量同步将主节点的数据全部发送给从节点。只有在主从节点第一次确定关系时才进行全量同步。全量同步分为三个阶段第一阶段负责建立主从关系。从节点首先发送replid和offset给主节点。主节点判断replid是否是自己如果不是那么就是第一次同步需要全量同步并返回自己的replid和offset给从节点如果是自己的那么根据offset做增量同步。如果是第一次同步从节点保存返回的replid和offset确定主从关系。第二阶段主节点将RDB文件发送给从节点从节点清空本地数据后读取主节点的RDB文件。由于第二阶段耗时较长所以第二阶段执行期间主节点可能会进行其他数据操作第三阶段就是将第二阶段主节点执行的其他数据操作命令发送给从节点确保数据一致。3.增量同步确定主从关系后从节点每次重启后都需要做一次增量同步。repl_backlog_buffer文件大小固定采用线性队列环形数组的方式实现如果增量同步不及时可能会出现尚未同步的数据被覆盖此时可能需要重新做全量同步无法准确判断是否需要做全量同步只能是写操作较多且从节点断连太久时认定为有数据覆盖。主节点维护自己的repl_backlog_buffer记录的是指令同时为每个从节点维护一个repl buffer当执行写操作时主节点有数据变更增量同步立即触发主节点检查repl buffer和repl_backlog_buffer从而确定每个从节点的offset将新的指令发送给从节点。四、Redis哨兵1.哨兵作用哨兵sentinel用来解决主节点断连的数据一致性问题。从节点断连后可以使用全量同步或增量同步找主节点更新数据哨兵会监控主节点和从节点的运行状态当master故障sentinel会将一个slave提升为master并通知SpringRedisTemplate新的主从关系。当原master恢复后也以新的master为主。哨兵也是集群防止单一哨兵故障影响全局。1.集群状态监控sentinel每隔1s向集群的每个节点通过ICMP协议发送ping命令若哨兵集群中超过指定数量quorum的sentinel都未收到该节点的响应则认定该节点客观下线。2.选举新的master首先排除与master断开时间超过指定值down-after-millisceonds*10的slave节点然后根据优先级slave-prority筛选出优先级最高的一批节点最后选出offset最大数据与master最接近的slave作为master节点。3.建立新的主从关系sentinel向选中的slave节点发送slaveof no one命令让该节点成为新的master向其他所有节点发送slaveof newIp newPort命令修改这些slave节点的master并强制修改故障节点为slave节点。Redis修改主节点时无法做到数据零丢失也就是说晋升为主节点的从节点只能尽可能保证最新的数据但无法保证数据的完整性所以需要依靠MQKafka/RabbitMQ来恢复数据。2.RedisTemplate连接哨兵1.引入SpringRedisTemplate依赖dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactId/dependency2.在application.yml配置文件中指定sentinel信息原来的单结点模式下配置的是redis结点的ip和port而现在需要配置哨兵的ip和port通过哨兵来自动获取redis主从结点的ip和port不需要显示配置。spring:redis:sentinel:master:mymasternodes:-192.168.50.128:27001-192.168.50.128:27002-192.168.50.128:27003# host: 192.168.150.101# port: 6379# password: 123321# lettuce:# pool:# max-active: 8# max-idle: 8# min-idle: 0# max-wait: 100ms3.配置主从节点读写分离BeanpublicLettuceClientConfigurationBuilderCustomizerclientConfigurationBuilderCustomizer(){returnnewLettuceClientConfigurationBuilderCustomizer(){Overridepublicvoidcustomize(LettuceClientConfiguration.LettuceClientConfigurationBuilderclientConfigurationBuilder){clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);}};}MASTER从master节点读MASTER_PREFERRED优先从master节点读master不可用则从slave节点读REPLICA从slave节点读REPLICA_PREFERRED优先从slave节点读所有slave不可用则从master节点读五、Redis分片集群1.分片集群结构Redis主从集群解决了redis高并发读问题Redis分片集群为了解决redis高并发写问题。每个master能存储单独数据可以解决海量数据存储问题。分片集群中有多个master每个master独立保存数据。每个master都可以搭建主从集群分配多个slave节点。master之间通过ping监测彼此状态不需要哨兵就能自动实现主从切换。2.搭建分片集群实现3master集群并配备一主一从1.创建节点目录mkdir7001700270038001800280032.编写redis.conf文件port6379# 开启集群功能cluster-enabledyes# 集群的配置文件名称不需要我们创建由redis自己维护cluster-config-file /usr/local/src/6379/nodes.conf# 节点心跳失败的超时时间cluster-node-timeout5000# 持久化文件存放目录dir/usr/local/src/6379# 绑定地址bind0.0.0.0# 让redis后台运行daemonizeyes# 注册的实例ipreplica-announce-ip192.168.50.128# 保护模式protected-mode no# 数据库数量databases1# 日志logfile /usr/local/src/6379/run.log3.将redis.conf拷贝到每个节点目录下echo700170027003800180028003|xargs-t-n1cpredis.conf4.批量修改每个节点的端口号printf%s\n700170027003800180028003|xargs-I{}-tsed-is/6379/{}/g{}/redis.conf5.启动所有节点printf%s\n700170027003800180028003|xargs-I{}-tredis-server{}/redis.conf6.查看节点启动状态ps-ef|grepredis7.建立主从关系redis-cli--clustercreate --cluster-replicas1192.168.50.128:7001192.168.50.128:7002192.168.50.128:7003192.168.50.128:8001192.168.50.128:8002192.168.50.128:8003redis-cli --cluster或者./redis-trib.rb代表集群操作命令create代表是创建集群--replicas 1或者--cluster-replicas 1指定集群中每个master的副本个数为1此时节点总数 ÷ (replicas 1)得到的就是master的数量。因此节点列表中的前n个就是master其它节点都是slave节点随机分配到不同master8.关闭进程printf%s\n700170027003800180028003|xargs-I{}-tredis-cli-p{}shutdown3.散列插槽散列插槽解决了并发写的数据一致性问题通过固定的哈希映射规则让每个key绑定唯一的哈希槽而每个哈希槽在集群中仅由一个主节点负责从根本上保证key的唯一性归属。分片集群下多个master节点平分163840~16383个插槽hash slot每个master节点只能操作自己的slot。数据key不与master节点绑定而是与插槽绑定。当操作某个key时先对key使用CRC16计算hash值再取余16384得到slot值然后判断该插槽属于哪个master节点redirect到该节点来操作key避免了手动选择master同时某一master故障时直接由从节点继承这部分数据保证数据不会丢失。如果key中有{}那么只根据{}中的内容计算hash值而非整个key为了实现同一类数据由同一个master管理4.集群伸缩单个master拥有的插槽数量和插槽位置可以动态修改集群中的节点数量也可以动态修改。添加节点到集群需要指定集群中的一个ip和端口来确定该节点添加到哪个集群。redis-cli--clusteradd-node newIp:newPort existedIp:existedPort分配插槽给指定masterredis-cli--clusterreshard ip:port5.主从切换分片集群master之间通过ping监测彼此状态在主节点出现故障时能够自动主从切换。也可以手动进行主从切换cluster failover[force takeover]缺省默认流程如下force省略对offset的一致性校验takeover强制替换省略一致性校验、master状态校验2.RedisTemplate连接分片集群1.引入SpringRedisTemplate依赖dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactId/dependency2.在application.yml配置文件中指定sentinel信息单结点模式下配置的是redis结点的ip和port哨兵模式下配置的是哨兵的ip和port分片集群模式下配置的是所有主从redis节点的ip和port。spring:redis:cluster:nodes:-192.168.50.128:7001-192.168.50.128:7002-192.168.50.128:7003-192.168.50.128:8001-192.168.50.128:8002-192.168.50.128:8003# 哨兵下主从集群的配置# sentinel:# master: mymaster# nodes:# - 192.168.50.128:27001# - 192.168.50.128:27002# - 192.168.50.128:27003# 单redis结点配置# host: 192.168.150.101# port: 6379# password: 123321# lettuce:# pool:# max-active: 8# max-idle: 8# min-idle: 0# max-wait: 100ms3.配置主从节点读写分离BeanpublicLettuceClientConfigurationBuilderCustomizerclientConfigurationBuilderCustomizer(){returnnewLettuceClientConfigurationBuilderCustomizer(){Overridepublicvoidcustomize(LettuceClientConfiguration.LettuceClientConfigurationBuilderclientConfigurationBuilder){clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);}};}MASTER从master节点读MASTER_PREFERRED优先从master节点读master不可用则从slave节点读REPLICA从slave节点读REPLICA_PREFERRED优先从slave节点读所有slave不可用则从master节点读