【Redis】Redis基础---排版一点乱

Redis内部使用一个redisObject对象来表示所有的key和value,redisObject包含数据类型、编码方式、数据指针、虚拟内存

数据类型【源】

String、List、Set、Hash、Zset
1. String :字符串、整数、浮点数
       最基础的,基于C语言字符数组实现的简单动态字符串
2. List:链表,每个节点包含一个字符串
       每一个元素都是String类型的双向链表(可栈、可队列)
3. Set:包含(唯一)字符串的无序收集器
      无序的String类型数据的集合,类似list列表,不能重复,内部用HashMap的key列存储对象(value列为null)
4. Hash:包含键值对无序散列表
      String类型的field和value之间的映射表,内部存储的是一个HashMap,适合存储对象(将对象属性存储为String类型,更少内存)
5. Zset:字符串成员与浮点数分值间有序映射,排序由分值大小决定
      SortSet:set基础上添加顺序属性score,添加修改元素可指定,每次指定SortSet自动重新按新值排序
      内部用HashMap和跳跃表SkipList保证数据的存储和有序:HashMap存放成员到score的映射,跳跃表存放所有成员,排序依据是HashMap中的score

RedisTemplate使用的是JdkSerializationRedisSerializer
      存入数据会将数据先序列化成字节数组然后在存入Redis数据库
      获取数据的时候默认转化、当数据不是字节存储时无法获取数据,null值
      数据是复杂的对象类型,而取出的时候又不想做任何的数据转换
      JDK序列化策略,
StringRedisTemplate(继承redisTemplate)使用的是StringRedisSerializer
      存的是字符串数据或者你要存取的数据就是字符串类型数据
      String序列化策略

主从复制:


      配置文件中slaveof masterip masterport或者启动时加命令:
            redis-server –port 6380 –slaveof 127.0.0.1 6379 (开始了同步)
            slave-read-only”为”no”从库可写,主库更新对应数据覆盖从库改动
            Slave on one 停止收集接收其他数据库同步并转为主库

从库持久化:
    主库禁用持久化,从库崩溃主库自动将数据同步过来,无须担心数据丢失;主库崩溃:1、从库提升为主库,2、启动崩溃的主库使用slaveof设置成从库
    不能使用supervisor及类似工具令主库崩溃后自动重启、避免重新启动(数据会被清空、从库持久化失去意义)

对此哨兵(独立进程):实现自动化系统监控、故障恢复功能
      哨兵:监控redis的运行状况,监控主从库是否正常运行,主库故障自动将从库转换为主库
      配置:建立sentinel.conf文件
            sentinel monitor 要监控的主库的名字 127.0.0.1 6379 1(最低通过票数) 自动发现所有复制该主库的从库
      启动 redis-sentinel /root/sentinel.conf
             +slave 新发现了从库,+sdown 主观认为主停止服务 +odown客观认为主库停止服务(此时将执行故障恢复:挑从为主) +try-failover哨兵开始进行故障恢复 +failover-end完成恢复(期间领头哨兵选举、备选从的选择)
            更新实例信息保留停止的服务实例的信息当其重新加入后按照当前信息继续对外提供服务

        原理:
            哨兵启动时读取配置文件信息,提供
                sentinel monitor master-name ip redis-port quorum 
                Master-name是主库的名字,quorum故障操作前至少需要几个哨兵节点同意
                一个哨兵节点可以同时监控多个redis主从系统,提供多个上面的配置
                sentinel monitor mymaster 127.0.0.1 6379 2   
                sentinel monitor othermaster 192.168.1.3 6380 4   

启动后:与监控主库建立两条连接
            一条定于主库的“sentinel:hello”获取其他同样监控该数据库哨兵节点信息
            也定期向主库发送info等命令来获取主库本身信息

主库建立连接后哨兵定时执行:
   每10秒向主从库发送info命令
      获取当前数据库的相关信息(运行ID、复制信息)实现新节点自动发现,info命令得到从库列表,对从库同样建立两个连接
      2秒向主从“sentinel:hello”发送自己信息(其他哨兵获取自己的信息)
       内容为:<哨兵的地址>,<哨兵的端口>, <哨兵运行ID>, <哨兵的配置版本>, <主库的名字>, <主库的地址>, <主库的端口>, <主库的配置版本>
      判断是不是新加入的哨兵,是、加入队列创建到其的连接同时判断主库配置版本
1秒向主从库其他哨兵节点发送ping命令

这个1秒与down-after-milliseconds相关,最长1s、小于1、每隔down-after-milliseconds”发送ping,大于1s,隔1s发送一次ping,如果超过down-a-m时间,平节点未回复则哨兵认为其主管下线(从当前哨兵进程看来该节点已经下线,如果该节点是主库哨兵进一步判断是否需要进行故障恢复:发送SENTINEL is-master-down-by-addr询问其他哨兵以了解他们是否也认为该主库主观下线,如果达到指定数量哨兵认为其客观下线,选举领头哨兵节点发起故障恢复)

发现主库客观下线的哨兵节点(A)向每个哨兵节点发送命令,要求对方选自己为领头哨兵
目标哨兵节点没有选过其他人,则同意A设置为领头哨兵
A发现超过半数且超过quorum参数值的哨兵节点同意自己为领头则成为领头哨兵
如果多个哨兵节点同时参选,会出现没有任何节点当选的可能,每个参选节点将等待一个随机事件重新发起参数请求,下一轮选举知道选举成功

选出领头哨兵,开始故障恢复
    在线从库中,选择优先级高(slave-priority)的从库,如果多个则命令偏移量越大越优先,还不行选择运行id较小的从库
    选出从库后向从库发送slaveof no one命令升级为主库,向其他从库发送slaveof命令成为新主库的从库
    更新内部记录、将已经停止服务的旧的主库更新为新主的从库,使得其恢复服务时自动以从库身份继续服务

哨兵的部署:
   以独立进程的方式对主从系统进行监控,效果好坏取决于哨兵的视角是否有代表性,如果哨兵较少,对整个系统判定可靠性降低,只有一个哨兵、单点故障;推荐:哨兵视角尽可能地与每个节点的视角一致
   每个节点部署一个哨兵,每个哨兵与其对应的节点的网络环境相同、近;同时设置quorum=哨兵节点数量/2+1(大部分哨兵节点同意才故障恢复)
   节点较多,每个哨兵都会和系统中的所有节点建立连接,产生较多连接:冗余连接(不支持连接复用);节点负载较高一定程度上影响对哨兵的回复及与其同机的哨兵与其他节点的通信,根据环境选择

全量同步:reids全量复制发生在slave初始化阶段
   从连接主,发送sync;主接收到sync开始执行bgsave生成rdb,将此后执行写命令存在缓冲区;主BGSAVE向从发送快照文件,记录被执行的写命令;从收到快照文件丢弃旧数据、载入快照;主快照发送完毕后开始向从发送缓冲区中写命令;从完成快照载入接收写命令并执行
这里写图片描述
   增量同步:slave初始化后开始正常工作时主的写操作同步到从的过程
      主执行写、向从发送、从接收执行写

Redis主从同步策略
      主从刚刚开始连接全量同步,结束后增量同步,slave任何时候都可以全量同步;首先尝试增量、不成功全量同步;
       Redis2.6及之前版本重新进行复制初始化(效率低下)
      2.8断线重连后,主库只将断线期间的写命令送给从,提供实用性

扫描二维码关注公众号,回复: 1216310 查看本文章

注意:
      多个slave断线,slave启动发送sync请求(全量同步)多个同时出现导致Master IO剧增宕机
      乐观复制策略,一定时间内内容可以不同最终会同步
      一个从只能一个主
      配置主库可写的条件:
         Min-slaves-to-write 3 只有当3个以上从库连接到主库,可写否报错 min-slaves-max-lag 10 容许从库最长失去连接的时间,
   上面的复制基于RDB方式的持久化实现(主库在后头保存RDB快照,从库接收并载入快照文件)
      简化逻辑
         缺:主库禁用RDB快照时,执行复制初始化操作redis仍生成RDB快照,受制于硬盘性能

因此从2.8.18引入“无硬盘复制”repl-diskless-sync yes ,与从库复制初始化时不会将快照内容存储到硬盘上,直接通过网络发送给从库

从库保存主库运行(唯一)ID,实例重启自动生成新的
复制同步阶段、主库向从库发命令时同时把该命令存放到一个积压队列backlog中并记录队列中存放命令的偏移量范围
从库接收主库传来的命令时会记录下该命令的偏移量

2.8后psync发送给sync,格式为psync 主库运行的ID 断开前最新的命令偏移量
   主库收到psync:
      主库判断从库传来的ID是否和自己运行的ID是否相同:确保从库之前是和自己同步,以免从库拿错误的数据
      判断从库最后同步成功的命令偏移量是否在积压队列中,如果在则增量复制,并将积压队列中相应命令发送给从库,不满足增量条件、全量同步
         注:设置积压队列大小,本质是固定长度的循环队列,默认1M,通过repl-backlog-size调整,越大、容许主从断线的时间越长

感谢分享:
Redis数据类型
https://www.cnblogs.com/hepingqingfeng/p/7263782.html
https://blog.csdn.net/gqtcgq/article/details/50273431

猜你喜欢

转载自blog.csdn.net/ma15732625261/article/details/80388756