redis主存,哨兵,集群的应用(生产环境可用)

启动
* redis的数据类型:
* 本质上是key-value的数据结构.而这个value分为:
* String  :单值和多值
* hash  :
* set
* zset
* list
* 核心: 具有业务标示的key.过期策略指的是key的过期,key过期,key对应的值就会失效(如分布式锁中,超时时间指的是key的失效时间
* 而非value的失效时间)
* 设计key:设计成为 具有业务标示的key;
* 用redis去实现功能.减少磁盘IO
*https://blog.csdn.net/weixin_33905756/article/details/94532850
* 社交app中用到的
* 1.set : 交集,并集,差集(以第一个为基准-(第二个和第三个的并集){过滤掉相同的远元素,剩余的是第一个的元素就是需要的数据}})
* 2.微信抽奖的应用,点赞的程序
* 3.放开数据库去做操作;
* 4.常用的api,减少数据库的查询
* zset:排行榜的热搜应用;
*
* 2.redis为什么快?
*   1.基于内存操作
*   2.单线程操作,避免了多线程的上下文操作;
*   3.为什么支持高并发?用到了io多路复用的技术
*3.持久化:
*    为了防止redis基于内存操作,当redis挂了之后,进行数据的保存,防止当redis重启时发生缓存雪崩或者缓存缓存穿透
*    两种:
*     rdb: 生成策略  自动
*         save 900 1    //900 时间  1 次数  set命令   900s时间改动了1次,会生成一次二进制的快照
*         save 300 10
*         save 60 10000
*        手动:
*          bgsave
*          save
*     aof:
*       指令级别:每执行一次就持久化到内存
*         appendfsync always    每执行一条命令,会直接到磁盘,对数据是安全的,对性能不好
*         appendfsync everysec   写到缓存里,当到达1s了,会直接持久化到磁盘,会丢失数据
*         appendfsync no      由操作系统决定,数据不安全
*          三个命令之间是或的关系
*      缓存的主要功能是:抗并发,大的流量直接在redis返回,而不去操作数据库
*      恢复数据:
*         rdb :二进制命令,恢复速度快
*         aof:一条指令指令的恢复,恢复速度慢
*         手动:
*          bgrewriteaof
*      默认情况下:会优先选用aof恢复数据,因为aof的数据完整性比较好
*      混合持久化:
*         rdb 和aof的结合:
*         aof-use-rdb-preamble yes   # 开启混合持久化
*          注意:写到aof文件中
*       主存复制原理:
*       防止数据丢失;
*       1.主存架构:
*         没有选举的,master和slave之间不能自动切换;一主两存;手动的去修改
*        数据复制: 全量同步: slave --->psyne --->master bgsave 生成rdb命令  ----->slave
*                 增量同步: 缓存区=---->buffer -->
*                   二者合并:关键点是bgsave
*                 存在一个偏移量:
*        2.哨兵架构:
*           主存架构的高级版.
*           java 连接的是哨兵.通过哨兵去获取java
*           解决的是:主存之间的切换,当主节点挂了之后,哨兵会从slave节点中选举为master节点,
*           哨兵去监听每一台redis(master+slave)
*           高可用架构
*           配置注意以下两点:
*           1.必须保证主存架构中配置好主存节点的关系
*           2.哨兵中配置相应的redis的主节点
*         存在的问题:
*         1. qps 只有一个节点提供写服务
*         2.访问瞬断
*        设置内存:
*           redis单节点设置的内存是:4g,不建议设置过大:
*               1.数据主存同步很慢
*               2.重启之后,持久化的数据加载很慢
*        集群:
*           主存结构构成了redis集群,那么数据是怎么保存的?
*             1.数据切片保存.  1)分片存储: 对key进行hash,进行路由,数据独立存储,不会重复,存在于其中的一个主存的主节点上,
*             分片只是在主节点,存节点只是数据备份的.
*             分片原理:
*             JedisClusterCRC16.getCRC16("zhoujian"); -->源码底层的可以直接取出来用
*             redis官方测试,水平扩展不要超过1000个节点,否则影响性能;
*             2.一个节点是10万的qps,
*             3.访问瞬断的问题:并没有彻底的解决掉,
*             搭建集群的关键点:
*             1.cluster-enabled yes
*             2.cluster-config-file nodes-8001.conf
*             3. cluster-node-timeout 5000   #网络抖动
*             启动集群:
*             4.../java/redis-5.0.3/src/redis-cli --cluster create --cluster-replicas 1 192.168.0.88:8001 192.168.0.88:8002 192.168.0.88:8003 192.168.0.88:8004 192.168.0.88:8005 192.168.0.88:8006
*             自动分配节点:实现主存节点以及集群搭建
*             5.../java/redis-5.0.3/src/redis-cli -c -h 192.168.0.88 -p 8001  集群信息 cluster info
*             6.节点信息  :cluster nodes
*             7.节点动态扩容:
*              ../java/redis-5.0.3/src/redis-cli --cluster add-node 192.168.0.88:8007 192.168.0.88:8001
*              分配slot
*              ../java/redis-5.0.3/src/redis-cli --cluster reshard 192.168.0.88:8001 (任意一个存在的主节点)
*               节点的Id :作为迁移的标准
*              8.把其中的一个节点作为另外一个节点的存节点
*                cluster replicate 7184228905566dc56e24acc3aca3ff6ec70ac85b (主节点的ID)
*                缩容:
*              9.删除节点(slave)
*              ../java/redis-5.0.3/src/redis-cli --cluster del-node 192.168.0.88:8008 9ed6c99d9a9dd0c8d618b2f2d8605f4960f9dbde
*              10.删除主节点;
*                  1.首先恢复slot槽位,然后在移除节点,不然会有数据的丢失
*                  2.删除节点
*             节点挂掉之后会自动选举为master,是一个虚拟的hash曹,只是给主节点
*             节点之间的通信机制:gossip协议 : ping  pong
*               通信的端口是:redis的节点的端口加1 比如:8001 --->100081
*             选举原理:
*               slave ->master
*               每一个节点之间是可以相互通信的.fail
*              选举原理:超过半数以上的节点通信,则为主节点 gossip
*              为什么需要奇数?
*                多个master就是为了达到高可用,节约机器,比如3和4个机器,挂掉两个,根据半数的选举原理,二者都是无法参与选举的;
*                核心就是:半数以上的选举原理.