湘潭做网站的公司,自助建站教程,wordpress重要插件,做网站卖彩票Redis的性能管理;
redis的数据保存在内存中
redis-cli info memory
redis内存使用info memory命令参数解析 used_memory:236026888 由 Redis 分配器分配的内存总量#xff0c;包含了redis进程内部的开销和数据占用的内存#xff0c;以字节#xff08;byte#xff09…Redis的性能管理;
redis的数据保存在内存中
redis-cli info memory
redis内存使用info memory命令参数解析 used_memory:236026888 由 Redis 分配器分配的内存总量包含了redis进程内部的开销和数据占用的内存以字节byte为单位 used_memory_rss:274280448 redis向操作系统申请的内存大小 used_memory_peak:458320936 redis的内存消耗峰值(以字节为单位) 内存碎片率
used_memory_rss/used_memory系统已经分配给了redis但是redis未能够有效利用的内存
如何查看内存碎片率
redis-cli info memory | grep ratio allocator frag ratio:1.19 分配碎片的比例redis 主进程调度时产生的内存比例越小值越高内存的浪费越多 allocator rss ratio:7.15 分配器占用物理内存的比例告诉你主进程调度执行时占用了多少物理内存 rss overhead ratio:0.31 rss是向系统申请的内存空间Redis占用物理空间额外的开销比例比例越低好redis实际占用的物理内存和向系统申请的内存月接近额外的开销越低 mem_fragmentation ratio:3.33 内存碎片的比例越低越好内存的使用率越高 如何自动清理碎片 vim /etc/redis/6379.conf ..... activedefrag yes #最后一行添加 如何手动清理碎片 redis-cli memory purge 设置redis的内存最大阈值:
一但到达阈值会自动清理碎片开启key的回收机制 vim /etc/redis/6379.conf ........ #568行添加 maxmemory 1gb key的回收策略 vim /etc/redis/6379.conf ....... #598行添加如下一般保留最后一个策略,根据需求添加 maxmemory-policy volatile-lru使用redis内资的lru算法把已经设置了过期时间的键值对对中淘汰数据移除最少使用的键值对。对已经设置了过期时间的键值对 maxmemory-policy volatile-ttl已经设置了时间的键值对从当中挑选一个即将过期的键值对针对有设置过期时间的键值对 maxmemory-policy-volatile-random:从已经设置了过期时间的键值对当中挑选数据随机淘汰键值对。对设置时间的键值对进行随机移除 mllkey-lru:lru算法当中对所有的键值对进行淘汰移除最少使用的键值对针对所有的键值对 allkeys-random:从所有键值对中任意选择键值对进行淘汰 maxmemory-policy noeciction:禁止键值对回收不删除任何键值对直到Redis内存塞满了 在工作中一定要 给redis占用内存设置阈值
面试
redis占用 内存的效率问题如何解决
1 日常巡检中。对redis 占用内存情况做监控
2 设置redis占用系统内存的阈值避免占用系统全部内存
3 内存碎片清理手动.自动清理
4 配置合适的Key的回收机制
Redis的报错问题
1 雪崩
缓存雪崩大量的应用请求无法在redis缓冲中处理会把所有的请求发送到后台数据库数据库的压力会大数据库本身并发能力差一旦高并发数据库会崩溃
redis集群大面积故障Redis缓存中大量数据同时过期大量的请求无法得到处理。Redis实例宕机
1.1解决方案
事前高可用架构防止整个缓存故障 主从复制和哨兵模式Redis集群。
事中在国内用的比较多的方式,hystrix,熔断限流三个手段来降低雪崩发生之后的损失数据库不死即可慢可以但是不能没有响应
事后Redis备份。快速缓存预热
2 redis的缓存击穿重要
主要是热点数据缓存过期或者删除多个请求并发访问热点数据请求转发到数据库导致数据库的性能下降经常请求的缓存数据最好设置为永不过期
3 Redis的缓存穿透
缓存中没有数据数据库也没有对应的数据但是有用户一直发起这个请求而且请求的数据是很大一般是被黑客利用 Redis的主从复制
主从复制的作用
是redis实现高可用的基础哨兵模式和集群都是在主从复制的基础之上实现高可用主从复制实现数据的多机备份以及读写分离主服务器负责写从服务器只读
缺陷故障无法自动恢复需要人工干预写操作的负载均衡 主从复制的工作原理
主节点从节点组成数据复制是单向只能从主节点到从节点
1 主节点主节点收到请求之后他不管slave是第一次连接还是重新连接主节点都会启动一个后台进程执行bgsave主节点会把所有修改数据记录的命令加载到缓存和数据文件之中
主从复制推荐使用AOF
建立连接slave向主发送一个syn command,请求和主节点建立连接
数据文件创建完毕之后master把数据文件传送到salveslave 会把这个数据文件先保存到硬盘然后在加载到内存 实验架构
192.168.233.7 主
192.168.233.8 从
192.168.233.9 从
依赖环境 Redis 先准备好
主 从1 和从2 查看日志是否建好 验证是否主从
同时登录redis ,主写入 从节点无法写 哨兵模式
先有主从,再有哨兵再主从复制的基础之上实现主节点故障的自动切换
哨兵模式的原理
哨兵是一个分布式系统用于在主从结构之间对每台redis的服务器进行监控主节点出现故障时从节点通过投票的方式选择一个新的master 哨兵模式也需要至少三个节点
哨兵模式的结构
哨兵节点监控节点不存储数据
数据节点主从节点都是数据节点
主节点的选举过程
1 已经下线的从节点不会被选为主节点
2 选择配置文件当中从节点优先级最高的replica-priority 100
3 选择一个复制数据最完整的从节点
哨兵节点通过raft算法选举算法每个节点共同投票选举出一个新的master然后新的master实现主节点转移和故障恢复通知
每个哨兵节点每隔一秒通过ping命令方式检测主从之间的心跳线主节点在一定时间内没有回复或者恢复了错误的信息这个时候哨兵就会主观的判断主节点下线了超过半数的节点哨兵认为主节点下线了这个时候才会认为主节点是客观下线 主 sentinel monitor mymaster 192.168.233.7 6379 2
#指向表示至少需要2台服务器认为主已经下线才会进行主从切换。 从1和从2 启动配置文件 先启动再启动从挨个执行一遍 查看状态信息 日志查看从节点的信息 Redis 集群
Redis3.0引入的分布式存储方案
工作模式
集群有多个node节点组成Redis数据分布在这些节点上在集群之中分为主节点和从节点
集群模式中 主从一一对应数据写的读取和主从模式一样主负责写从模式只能写集群模式自带哨兵模式可以自动实现故障切换但是故障切换中整个集群不能使用切换完毕之后集群会立刻恢复
集群模式是按照数据分片划分
1 数据分片是集群的核心功能每个主都要提供读写的功能但是数据一一对应写入对应的从节点在集群模式中可以容忍数据的不完整
2 高可用 集群的主要目的 数据分片的实现过程
redis集群引入了 哈希槽的概念
redis集群当中16384个哈希槽位0-16384
根据集群当中主节点从节点分配哈希槽位每个主从节点只负责一部分的
哈希槽位是连续的哈希槽位如果出现不连续的哈希值或者哈希槽位没有被分配集群将会报错
主宕机之后主节点原来负责的哈爷槽位将会不可用需要从节点代替主节点继续负责原有的哈希操作。保证集群正常工作故障切换的过程中会提示集群不可用。切换完成集群恢复继续工作。
每次读写都涉及到哈希槽位Keyt通过crc16验证之后对16384取余数余数值决定数据放入哪个哈希槽位通过这个值去找到对应的槽位所在的节点然后直接跳转到这个节点
集群的流程
1 集群自带主从和哨兵模式
2 每个主从是互相隔的可以容忍数据的不完整目的高可用
3 哈希槽位为决定每个节点的读写槽位在创建Key时系统已经分配好了指定槽位
4 如果是出现MOVED不是报错是提醒客户端取分配好的槽位节点获取数据 实验
实验需求需要6台装有redis的虚拟机 六台redis服务器都配置 vim /etc/redis/6379.conf ***************************************************************************************** 1、默认监听所有网卡-----70行 bind 0.0.0.0 2、关闭保护模式-----89行 protect-mode no 3、开启守护进程以独立进程启动-----137行 daemonize yes 4、开启AOF持久化-----700行 appendonly yes 5、开启集群功能-----833行 cluster-enabled yes 6、集群名称文件设置-----841行 cluster-config-file nodes-6003.conf 7、集群超时时间设置-----847行15000毫秒 cluster-node-timeout 15000 ***************************************************************************************** 创建集群redis-cli -h 所在服务器ip --cluster create ip地址:6379 --cluster-replicas 1 此时在192.168.10.80主机创建 redis-cli -h 192.168.10.80 --cluster create 192.168.10.80:6379 192.168.10.150:6379 179 192.168.10.152:6379 192.168.10.153:6379 192.168.10.154:6379 --cluster-replicas 1 [rootlocalhost ~]# redis-cli -h 192.168.10.80 --cluster create 192.168.10.80:6379 192.168.79 192.168.10.152:6379 192.168.10.153:6379 192.168.10.154:6379 --cluster-replicas 1 Performing hash slots allocation on 6 nodes... Master[0] - Slots 0 - 5460 Master[1] - Slots 5461 - 10922 Master[2] - Slots 10923 - 16383 Adding replica 192.168.10.153:6379 to 192.168.10.80:6379 Adding replica 192.168.10.154:6379 to 192.168.10.150:6379 Adding replica 192.168.10.152:6379 to 192.168.10.151:6379 M: f9a09e3ededa9767aafc6aca98fcaad8e28272b6 192.168.10.80:6379 slots:[0-5460] (5461 slots) master M: 508caf1dfeab313b2df0173dc015b62591b012fb 192.168.10.150:6379 slots:[5461-10922] (5462 slots) master M: 68d8e79f5b4478dcd8143ef024607f17d02820c6 192.168.10.151:6379 slots:[10923-16383] (5461 slots) master S: 6c1dc5ae608ca1c20f80f4762933ee07aa4a77c5 192.168.10.152:6379 replicates 68d8e79f5b4478dcd8143ef024607f17d02820c6 S: d82924c43dd5c907fda4abf35ffe33ad2b295abf 192.168.10.153:6379 replicates f9a09e3ededa9767aafc6aca98fcaad8e28272b6 S: 8ae774dce41372b08e38904ef81adba51413d072 192.168.10.154:6379 replicates 508caf1dfeab313b2df0173dc015b62591b012fb Can I set the above configuration? (type yes to accept): yes Nodes configuration updated Assign a different config epoch to each node Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join .... Performing Cluster Check (using node 192.168.10.80:6379) M: f9a09e3ededa9767aafc6aca98fcaad8e28272b6 192.168.10.80:6379 slots:[0-5460] (5461 slots) master 1 additional replica(s) S: 8ae774dce41372b08e38904ef81adba51413d072 192.168.10.154:6379 slots: (0 slots) slave replicates 508caf1dfeab313b2df0173dc015b62591b012fb S: 6c1dc5ae608ca1c20f80f4762933ee07aa4a77c5 192.168.10.152:6379 slots: (0 slots) slave replicates 68d8e79f5b4478dcd8143ef024607f17d02820c6 M: 68d8e79f5b4478dcd8143ef024607f17d02820c6 192.168.10.151:6379 slots:[10923-16383] (5461 slots) master 1 additional replica(s) S: d82924c43dd5c907fda4abf35ffe33ad2b295abf 192.168.10.153:6379 slots: (0 slots) slave replicates f9a09e3ededa9767aafc6aca98fcaad8e28272b6 M: 508caf1dfeab313b2df0173dc015b62591b012fb 192.168.10.150:6379 slots:[5461-10922] (5462 slots) master 1 additional replica(s) [OK] All nodes agree about slots configuration. Check for open slots... Check slots coverage... [OK] All 16384 slots covered. [rootlocalhost ~]# 查看hash槽位CLUSTER nodes 验证从节点不能读 此处error不是报错表明客户端尝试读取键值对test1但是实际槽位在4768因此集群要求客户端移动到4768槽位所在的主机节点获取数据
2验证从节点能不能写。不能 3验证分配hash槽位后不在相应的hash槽位上的主节点能不能写。不能只能到指定节点上操作
主 从 模拟故障
任意一台主服务器故障
主20.0.0.34——redis3故障从20.0.0.44——redis4成为新主 monitor 查看哨兵的ping命令
监控redis实时工作日志检测主从节点之间的心跳线
主 从
