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.31rss是向系统申请的内存空间，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把数据文件传送到salve，slave 会把这个数据文件，先保存到硬盘，然后在加载到内存
实验架构：
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
[root@localhost ~]# 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.
[root@localhost ~]#
查看hash槽位CLUSTER nodes
验证从节点不能读
此处error不是报错，表明客户端尝试读取键值对test1，但是实际槽位在4768，因此集群要求客户端移动到4768槽位所在的主机节点获取数据
（2）验证从节点能不能写。不能
（3）验证分配hash槽位后，不在相应的hash槽位上的主节点能不能写。不能，只能到指定节点上操作
主
从
模拟故障
任意一台主服务器故障
主20.0.0.34------redis3故障，从20.0.0.44------redis4成为新主
monitor 查看哨兵的ping命令
监控redis实时工作日志，检测主从节点之间的心跳线
主
从
