深入学习Redis笔记

参考文档：

https://www.cnblogs.com/kismetv/p/8654978.html#t6

https://blog.csdn.net/fouy_yun/article/details/81322536

https://blog.csdn.net/y277an/article/details/98342442

1.是什么：基于内存操作读写NOSQL数据库（热点数据缓存）

 

2.为什么使用:

     1)速度快

     2)并发量高

     3)单命令原子性

     4)数据结构的特性使用很多场景

     5)支持持久化，数据可靠

 

3.交互模式：

    串行请求/响应模式、双工的请求/响应模式(pipeline)、原子化的批量请求/响应模式（事务）、发布/订阅模式、脚本化的批量执行（Lua脚本）。

 

4.请求模型：

 

5.内存模型：（内存对于redis是重中之重）

（1）查看redis内存使用的情况：info memory；

（2）内存组成：数据、进程本身运行需要的内存、缓冲内存、内存碎片；

（3）关于Redis数据存储的细节，涉及到内存分配器（如jemalloc）、简单动态字符串（SDS）、5种对象类型及内部编码、redisObject

      jemalloc（内存空间划分为小、大、巨大三个范围，如：存储大小为130字节，实则分配160的内存）

typedef struct redisObject {

　　unsigned type:4;（类型）

　　unsigned encoding:4;（字符集）

　　unsigned lru:REDIS_LRU_BITS; （最近访问时间）

　　int refcount;（引用次数（共享对象的具体实现：redis初始化时分配**_SHARED_INTEGERS，节约空间））

　　void *ptr;（数据指针）

} robj;

（4）实际应用中应关注的问题：

利用jemalloc特性进行优化（大小控制对等的分配级别）（节省内存空间）

使用整型/长整型，自动转int，（节省内存空间）

共享对象（节省内存空间）

关注内存碎片（将占用 很大的空间）（重启+回收策略（maxmemory+maxmemory-policy））

 

6.单机备份：（持久化）

（1）.默认开启RDB+手动选择开启AOF

      RDB缺点：实时性不高

      AOF缺点：占用性能，少量的数据丢失（服务宕机），AOF文件会增大，需要定时重写

（2）.如何选择持久化策略（参考）

master不开启RDB、AOF（性能最佳）+slave开启AOF、关闭重写、定时重写+定时异地灾备（scp）

（3）注意事项： fork阻塞：CPU的阻塞（用Vmware或KVM虚拟机高效fork+单机内存不能过大+适度放宽重写策略）

                             AOF追加阻塞：硬盘的阻塞（监控info Persistence中的aof_delayed_fsync+阻塞次数频繁：更换硬盘）

监控redis运行状态：info Persistence，info stats（latest_fork_usec（越小越号好））

 

7.多机热备（主从复制：读写分离+负载均衡）

（1）实现原理：保存主节点信息--》建立socket连接--》发送ping命令--》身份验证--》发送从节点端口信息--》数据同步阶段||部分复制--》命令传播阶段

（2）造成的问题：

         延迟与不一致问题：slave-serve-stale-data no（数据一致性要求很高，必然可用性差）

         数据过期问题：Redis升级到3.2可以解决从节点读到过期数据问题

         故障需要手动转移

         复制超时问题：repl-timeout（根据bgsave耗时来调整），repl-ping-slave-period明显小于repl-timeout,慢查询阻塞带来的超时

          由复制超时/复制缓冲区溢出引发的复制中断：client-output-buffer-limit slave调大点

（3）各场景下复制的选择及优化技巧

安全重启：debug reload

适当调整复制积压缓冲区的大小

建议：主节点单机内存除了绝对量不能太大，其占用主机内存的比例也不应过大：最好只使用50%-65%的内存，留下30%-45%的内存用于执行bgsave命令和创建复制缓冲区等。

查看复制状态info Replication

 

8.故障自动转移（哨兵（配置提供者） ，基于主从复制）

过程：3个定时任务监控各个节点--》主管下线--》客观下线--》选举领导者哨兵节点--》故障转移--》通知客户端

配置：sentinel down-after-milliseconds根据网络情况和对可用性要求高低的不同场景进行调整，默认30s

           sentinel parallel-syncs允许故障转移后的复制并行度，根据主节点和可用性要求调整，默认1

           sentinel failover-timeout故障转移超时，默认180s，若超时，将翻倍

缺点：单机的写能力有限，存储有限

 

9，集群（数据分区+故障自动转移）

（1）设计：计算主节点数量（benchmark估算）、集群机器数量的控制

（2）核心：数据分区（哈希取余、一致性哈希分区、虚拟节点的一致性哈希）

（3）通信机制：广播+Gossip协议（meet消息、ping消息、pong消息、fail消息、publish消息）

（4）重要的数据结构：clusterNode（记录当前节点状态），clusterState（当前节点对集群状态的记录）

（5）redis-cli：moved重定向

（6）jedis：客户端自己缓存映射关系，发送失败，重新重试其他节点来刷新映射关系

（7）集群伸缩：

        增加节点：redis-trib.rb的add-node+reshard

         减少节点：reshard+del-node，客户端在此情况下通信会返回ASK错误

         故障转移时间：cluster-node-timeout 

          集群的限制和应对方法：批量key（Hash Tag解决{key}：1）

          参数优化：cluster_node_timeout：根据网络情况调整，减少误判

                              cluster-require-full-coverage：全部分配槽