Redis中5种数据结构的使用场景介绍

  • String 数据结构是简单的 key-value 类型,value 不仅可以是 String，也可以是数字。redis 的字符串是动态字符串，内部为当前字符串实际分配的空间 capacity 一般要高于实际字符串长度 len。当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间。字符串最大长度为 512M。使用 Strings 类型，除了提供与 Memcached 一样的 get、set、incr、decr 等操作外，Redis 还提供了下面一些操作
    • APPEND niushuai redis：往字符串 append 内容，而且采用智能分配内存（每次2倍）
    • 设置和获取字符串的某一段内容
    • 设置及获取字符串的某一位（bit）
    • 批量设置一系列字符串的内容
    • 原子计数器
    • GETSET 命令的妙用，等于清空旧值的同时设置一个新值，配合原子计数器使用
      • 用途
        • 缓存用户信息，结构体序列化成字符串
    • 其结构有 Tcapacity 数组容量; T len 数组长度; byte flags 特殊标识位; byte[] content; 数组内容 字节数组,真正内容
    • Redis 的字符串有两种存储方式，在长度特别短时，使用 emb 形式存储(embeded)，当长度超过 44 时，使用 raw 形式存储 。
  • Hash——字典
    • 在 Memcached 中，将一些结构化的信息打包成 hashmap，在客户端序列化后存储为一个字符串的值（一般是 JSON 格式），比如用户的昵称、年龄、性别、积分等。这时候在需要修改其中某一项时，通常需要将字符串（JSON）取出来，然后进行反序列化，修改某一项的值，再序列化成字符串（JSON）存储回去。简单修改一个属性就干这么多事情，消耗必定是很大的，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而 Redis 的 Hash 结构可以使你像在数据库中 Update 一个属性一样只修改某一项属性值。存储、读取、修改用户属性。每个hash能存2的32次方-1 键值对 （HMSET runoob field1 “Hello” field2 “World”）
  • List——列表
    • List 说白了就是链表（redis 使用双端链表实现的List），使用 List 结构，可以轻松地实现最新消息排行等功能（比如新浪微博的 TimeLine ）。List 的另一个应用就是消息队列，可以利用 List 的 *PUSH 操作，将任务存在 List 中，然后工作线程再用 POP 操作将任务取出进行执行。Redis 还提供了操作 List 中某一段元素的 API，直接查询，删除 List 中某一段的元素 列表最多可存储 232 - 1 元素 。
    • 使用场景
      • 微博 TimeLine
      • 消息队列
      • Redis 的列表相当于 Java 语言里面的 LinkedList，注意它是链表而不是数组。当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收。
      • Redis 的列表结构常用来做异步队列使用。将需要延后处理的任务结构体序列化成字符串塞进 Redis 的列表，另一个线程从这个列表中轮询数据进行处理。
  • Set——集合
    • Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。比如抽奖等，去重的功能。因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
    • 使用场景
      • 共同好友、二度好友
      • 利用唯一性，可以统计访问网站的所有独立 IP
      • 好友推荐的时候，根据 tag 求交集，大于某个 threshold 就可以推荐
  • zset——有序集合
    • 和Sets相比，zset是将 Set 中的元素增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，比如一个存储全班同学成绩的 Sorted Sets，其集合 value 可以是同学的学号，而 score 就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用 Sorted Sets 来做带权重的队列，比如普通消息的 score 为1，重要消息的 score 为2，然后工作线程可以选择按 score 的倒序来获取工作任务。让重要的任务优先执行。 基本是 O(log(N))复杂度。
    • Redis使用两种结构存储zset，在数据个数较少时使用ziplist，数量超出阈值时使用skiplist，阈值通过zset-max-ziplist-entries and zset-max-ziplist-value设置。
    • 使用场景
      • 带有权重的元素，比如一个游戏的用户得分排行榜
    • ziplist
      • ziplist使用连续空间存储双向链表，相比基于堆空间指针的链表前后向移动速度更快。
    • skiplist
  • HyperLogLog 基数统计
    • HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身
    • PFADD runoobkey “mysql”
    • pfcount runoobkey
  1. typedef struct zskiplist {
  2.     struct zskiplistNode *header, *tail;
  3.     unsigned long length;
  4.     int level;
  5. } zskiplist;
  7. typedef struct zskiplistNode {
  8.     sds ele;
  9.     double score;
  10.     struct zskiplistNode *backward;
  11.     struct zskiplistLevel {
  12.         struct zskiplistNode *forward;
  13.         unsigned int span;
  14.     } level[];
  15. } zskiplistNode;

image.png

  1.   - （其1说法）每个节点用数据结构 zskiplistNode 表示，head 和 tail 分别指向最底层链表的头尾节点。length 表示当前跳表最底层链表有多少个节点，level 记录当前跳表最高索引层数。
  2.   - （其2说法）
  3.      - 表头（head）：负责维护跳跃表的节点指针。
  4.      - 跳跃表节点：保存着元素值，以及多个层。
  5.      - 层：保存着指向其他元素的指针。高层的指针越过的元素数量大于等于低层的指针，为了提高查找的效率，程序总是从高层先开始访问，然后随着元素值范围的缩小，慢慢降低层次。
  6.      - 表尾：全部由 `NULL` 组成，表示跳跃表的末尾。
  7.   - （其3，比较说书）跳跃列表保存一个有序排列的链表，通过采用多层存储且保持每一层链表是其上一层链表的自己，从最稀疏的层开始搜索，从而达到比链表O(N)更优的查找和插入性能O(log(N))。

Redis其他功能使用场景

  • 订阅-发布系统
    • Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在 Redis 中，你可以设定对某一个 key 值进行消息发布及消息订阅，当一个 key 值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。
  • 事务——Transactions
    • 虽然 Redis 的 Transactions 提供的并不是严格的 ACID 的事务（比如一串用 EXEC 提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个 Transactions 还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis 还提供了一个 Watch 功能，你可以对一个 key 进行 Watch，然后再执行 Transactions，在这过程中，如果这个 Watched 的值进行了修改，那么这个 Transactions 会发现并拒绝执行。
    • Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
      • 批量操作在发送 EXEC 命令前被放入队列缓存。
      • 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
      • 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。
  • 会话缓存
    • 使用 Redis 进行会话缓存。例如，将 web session 存放在 Redis 中。
  • 时效性
    • 验证码，token
  • 访问频率
    • 出于减轻服务器的压力或防止恶意的洪水攻击的考虑，需要控制访问频率，例如限制 IP 在一段时间的最大访问量。（令牌桶）
  • 缓存
    • 对于热点数据，缓存以后可能读取数十万次，因此，对于热点数据，缓存的价值非常大。例如，分类栏目更新频率不高，但是绝大多数的页面都需要访问这个数据，因此读取频率相当高，可以考虑基于 Redis 实现缓存。
  • 计数器
    • 数据统计的需求非常普遍，通过原子递增保持计数。例如，应用数、资源数、点赞数、收藏数、分享数等。
  • 社交列表
    • 社交属性相关的列表信息，例如，用户点赞列表、用户分享列表、用户收藏列表、用户关注列表、用户粉丝列表等，使用 Hash 类型数据结构是个不错的选择。
  • 排行榜
    • 展示最热、点击率最高、活跃度最高等条件的排名列表

Redis的内存淘汰机制

  • 最近最少使用LRU
  • 最不经常使用算法LFU
  • volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
  • allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
  • no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。
    1. 配置方法：maxmemory-policy volatile-lru   #默认是noeviction，即不进行数据淘汰

Redis持久化机制

  1. RDB(snapshotting，快照)
  • RDB
    • RDB方式的持久化几乎不损耗Redis本身的性能，在进行RDB持久化时，Redis主进程唯一需要做的事情就是fork出一个子进程，所有持久化工作都由子进程完成
    • 采用RDB持久方式，Redis会定期保存数据快照至一个rbd文件中，并在启动时自动加
      载rdb文件，恢复之前保存的数据。可以在配置文件中配置Redis进行快照保存的时机：save [seconds] [changes].
    • 可以配置多条save指令，让Redis执行多级的快照保存策略。
    • 也可以通过BGSAVE命令手工触发RDB快照保存。
  • RDB的优点
    • 对性能影响小
    • RDB恢复数据的速度比AOF快
  • RDB的缺点
    • 快照是定期生成的，Redis crash多少会丢一些数据
    • 如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间（长至1秒），影响这期间的客户端请求。
  1. AOF(append-only file，追加文件)
  • AOF
    • 采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。
    • AOF采用三种策略：
      • appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快
      • appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
      • appendfsync everysec：折中的做法，交由后台线程每秒fsync一次
    • Redis提供AOF rewrite来重写AOF文件，改功能能去除无用的日志（例如：某个时间点执行了命令SET key1 “abc”，在之后某个时间点又执行了SET key1 “bcd”）
      AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：
      • auto-aof-rewrite-percentage 100;
      • auto-aof-rewrite-min-size 64mb;
  • AOF的优点
    • 最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。
    • AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。
    • AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。
  • AOF的缺点
    • AOF文件通常比RDB文件更大
    • 性能消耗比RDB高
    • 数据恢复速度比RDB慢
  • Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化
  • AOF的同步策略
    • 是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：
    • 为了提高文件写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

image.png

Pipelining

Pipelining将多条命令组合在一起，用于减少维护网络连接和传输数据所消耗的资源和时间。

  • Pipelining的局限性
  • Pipelining只能用于执行连续且无相关性的命令，当某个命令的生成需要依赖于前一个命令的返回时，就无法使用Pipelining了。

Redis性能调优

针对Redis的性能优化，主要从下面几个层面入手：

  • 最初的也是最重要的，确保没有让Redis执行耗时长的命令
  • 使用pipelining将连续执行的命令组合执行
  • 操作系统的Transparent huge pages功能必须关闭
  • 如果在虚拟机中运行Redis，可能天然就有虚拟机环境带来的固有延迟。可以通过./redis-cli —intrinsic-latency 100命令查看固有延迟。同时如果对Redis的性能有较高要求的话，应尽可能在物理机上直接部署Redis。
  • 检查数据持久化策略
  • 考虑引入读写分离机制

避免在使用这些O(N)命令时发生问题主要有几个办法：

  • 不要把List当做列表使用，仅当做队列来使用
  • 通过机制严格控制Hash、Set、Sorted Set的大小
  • 可能的话，将排序、并集、交集等操作放在客户端执行
  • 绝对禁止使用KEYS命令
  • 避免一次性遍历集合类型的所有成员，而应使用SCAN类的命令进行分批的，游标式的遍历

redis知识

  1. list/set/hash/zset 这四种数据结构是容器型数据结构，它们共享下面两条通用规则：
  • create if not exists
    • 如果容器不存在，那就创建一个，再进行操作。比如 rpush 操作刚开始是没有列表的，Redis 就会自动创建一个，然后再 rpush 进去新元素。
  • drop if no elements
    • 如果容器里元素没有了，那么立即删除元素，释放内存。这意味lpop操作到最后一个元素，列表就消失了。

redis技巧

  • redis关闭保护模式
    • 进入redis安装目录 vi redis.conf 注释bind 127.0.0.1这一行
    • 启动redis 登入客户端 执行下面命令 config set protected-mode “no”

Redis 集群方案与实现

Redis支持三种集群方案

  • 主从复制模式
  • Sentinel（哨兵）模式
  • Cluster模式

主从复制模式

主从复制模式中包含一个主数据库实例（master）与一个或多个从数据库实例（slave），如下图

image.png

客户端可对主数据库进行读写操作，对从数据库进行读操作，主数据库写入的数据会实时自动同步给从数据库。
具体工作机制为：

  1. slave启动后，向master发送SYNC命令，master接收到SYNC命令后通过bgsave保存快照（即上文所介绍的RDB持久化），并使用缓冲区记录保存快照这段时间内执行的写命令
  2. master将保存的快照文件发送给slave，并继续记录执行的写命令
  3. slave接收到快照文件后，加载快照文件，载入数据
  4. master快照发送完后开始向slave发送缓冲区的写命令，slave接收命令并执行，完成复制初始化
  5. 此后master每次执行一个写命令都会同步发送给slave，保持master与slave之间数据的一致性

redis.conf的主要配置

  1. ###网络相关###
  2. # bind 127.0.0.1 # 绑定监听的网卡IP，注释掉或配置成0.0.0.0可使任意IP均可访问
  3. protected-mode no # 关闭保护模式，使用密码访问
  4. port 6379  # 设置监听端口，建议生产环境均使用自定义端口
  5. timeout 30 # 客户端连接空闲多久后断开连接，单位秒，0表示禁用
  7. ###通用配置###
  8. daemonize yes # 在后台运行
  9. pidfile /var/run/redis_6379.pid  # pid进程文件名
  10. logfile /usr/local/redis/logs/redis.log # 日志文件的位置
  12. ###RDB持久化配置###
  13. save 900 1 # 900s内至少一次写操作则执行bgsave进行RDB持久化
  14. save 300 10
  15. save 60 10000 
  16. # 如果禁用RDB持久化，可在这里添加 save ""
  17. rdbcompression yes #是否对RDB文件进行压缩，建议设置为no，以（磁盘）空间换（CPU）时间
  18. dbfilename dump.rdb # RDB文件名称
  19. dir /usr/local/redis/datas # RDB文件保存路径，AOF文件也保存在这里
  21. ###AOF配置###
  22. appendonly yes # 默认值是no，表示不使用AOF增量持久化的方式，使用RDB全量持久化的方式
  23. appendfsync everysec # 可选值 always， everysec，no，建议设置为everysec
  25. ###设置密码###
  26. requirepass 123456 # 设置复杂一点的密码

部署主从复制模式只需稍微调整slave的配置，在redis.conf中添加

  1. replicaof 127.0.0.1 6379 # master的ip，port
  2. masterauth 123456 # master的密码
  3. replica-serve-stale-data no # 如果slave无法与master同步，设置成slave不可读，方便监控脚本发现问题

本示例在单台服务器上配置master端口6379，两个slave端口分别为7001,7002，启动master，再启动两个slave

进入master数据库，写入一个数据，再进入一个slave数据库，立即便可访问刚才写入master数据库数据。如下所示

  1. [root@dev-server-1 master-slave]# redis-cli 
  2. 127.0.0.1:6379> auth 123456
  3. OK
  4. 127.0.0.1:6379> set site blog.jboost.cn
  5. OK
  6. 127.0.0.1:6379> get site
  7. "blog.jboost.cn"
  8. 127.0.0.1:6379> info replication
  9. # Replication
  10. role:master
  11. connected_slaves:2
  12. slave0:ip=127.0.0.1,port=7001,state=online,offset=13364738,lag=1
  13. slave1:ip=127.0.0.1,port=7002,state=online,offset=13364738,lag=0
  14. ...
  15. 127.0.0.1:6379> exit
  17. [root@dev-server-1 master-slave]# redis-cli -p 7001
  18. 127.0.0.1:7001> auth 123456
  19. OK
  20. 127.0.0.1:7001> get site
  21. "blog.jboost.cn"

主从复制的优缺点

优点：

  1. master能自动将数据同步到slave，可以进行读写分离，分担master的读压力
  2. master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

缺点：

  1. 不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复
  2. master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题
  3. 难以支持在线扩容，Redis的容量受限于单机配置

Sentinel（哨兵）模式

哨兵模式基于主从复制模式，只是引入了哨兵来监控与自动处理故障。如图

image.png

哨兵顾名思义，就是来为Redis集群站哨的，一旦发现问题能做出相应的应对处理。其功能包括

  1. 监控master、slave是否正常运行
  2. 当master出现故障时，能自动将一个slave转换为master（大哥挂了，选一个小弟上位）
  3. 多个哨兵可以监控同一个Redis，哨兵之间也会自动监控

哨兵模式的具体工作机制：
在配置文件中通过 sentinel monitor <master-name> <ip> <redis-port> <quorum> 来定位master的IP、端口，一个哨兵可以监控多个master数据库，只需要提供多个该配置项即可。哨兵启动后，会与要监控的master建立两条连接：

  1. 一条连接用来订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息
  2. 另一条连接定期向master发送INFO等命令获取master本身的信息

与master建立连接后，哨兵会执行三个操作：

  1. 定期（一般10s一次，当master被标记为主观下线时，改为1s一次）向master和slave发送INFO命令
  2. 定期向master和slave的_sentinel_:hello频道发送自己的信息
  3. 定期（1s一次）向master、slave和其他哨兵发送PING命令

发送INFO命令可以获取当前数据库的相关信息从而实现新节点的自动发现。所以说哨兵只需要配置master数据库信息就可以自动发现其slave信息。获取到slave信息后，哨兵也会与slave建立两条连接执行监控。通过INFO命令，哨兵可以获取主从数据库的最新信息，并进行相应的操作，比如角色变更等。
接下来哨兵向主从数据库的sentinel:hello频道发送信息与同样监控这些数据库的哨兵共享自己的信息，发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用处：

  1. 其他哨兵可以通过该信息判断发送者是否是新发现的哨兵，如果是的话会创建一个到该哨兵的连接用于发送PING命令。
  2. 其他哨兵通过该信息可以判断master的版本，如果该版本高于直接记录的版本，将会更新
  3. 当实现了自动发现slave和其他哨兵节点后，哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。

如果被PING的数据库或者节点超时（通过 sentinel down-after-milliseconds master-name milliseconds 配置）未回复，哨兵认为其主观下线（sdown，s就是Subjectively —— 主观地）。如果下线的是master，哨兵会向其它哨兵发送命令询问它们是否也认为该master主观下线，如果达到一定数目（即配置文件中的quorum）投票，哨兵会认为该master已经客观下线（odown，o就是Objectively —— 客观地），并选举领头的哨兵节点对主从系统发起故障恢复。若没有足够的sentinel进程同意master下线，master的客观下线状态会被移除，若master重新向sentinel进程发送的PING命令返回有效回复，master的主观下线状态就会被移除
哨兵认为master客观下线后，故障恢复的操作需要由选举的领头哨兵来执行，选举采用Raft算法：

  1. 发现master下线的哨兵节点（我们称他为A）向每个哨兵发送命令，要求对方选自己为领头哨兵
  2. 如果目标哨兵节点没有选过其他人，则会同意选举A为领头哨兵
  3. 如果有超过一半的哨兵同意选举A为领头，则A当选
  4. 如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点等待一个随机时间后再次发起参选请求，进行下一轮投票竞选，直至选举出领头哨兵

选出领头哨兵后，领头者开始对系统进行故障恢复，从出现故障的master的从数据库中挑选一个来当选新的master,选择规则如下：

  1. 所有在线的slave中选择优先级最高的，优先级可以通过slave-priority配置
  2. 如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越完整）的当选
  3. 如果以上条件都一样，选取id最小的slave

挑选出需要继任的slave后，领头哨兵向该数据库发送命令使其升格为master，然后再向其他slave发送命令接受新的master，最后更新数据。将已经停止的旧的master更新为新的master的从数据库，使其恢复服务后以slave的身份继续运行。

哨兵模式基于前文的主从复制模式。哨兵的配置文件为sentinel.conf，在文件中添加

  1. sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定义一个master数据库的名称，后面是master的ip， port，1表示至少需要一个Sentinel进程同意才能将master判断为失效，如果不满足这个条件，则自动故障转移（failover）不会执行
  2. sentinel auth-pass mymaster 123456 # master的密码
  3. sentinel down-after-milliseconds mymaster 5000 # 5s未回复PING，则认为master主观下线，默认为30s
  4. sentinel parallel-syncs mymaster 2  # 指定在执行故障转移时，最多可以有多少个slave实例在同步新的master实例，在slave实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
  5. sentinel failover-timeout mymaster 300000 # 如果在该时间（ms）内未能完成故障转移操作，则认为故障转移失败，生产环境需要根据数据量设置该值

一个哨兵可以监控多个master数据库，只需按上述配置添加多套

分别以26379,36379,46379端口启动三个sentinel

  1. [root@dev-server-1 sentinel]# redis-server sentinel1.conf --sentinel
  2. [root@dev-server-1 sentinel]# redis-server sentinel2.conf --sentinel
  3. [root@dev-server-1 sentinel]# redis-server sentinel3.conf --sentinel

我们来模拟master挂掉的场景，执行 kill -9 3017 将master进程干掉，进入slave中执行 info replication查看，

  1. [root@dev-server-1 sentinel]# redis-cli -p 7001
  2. 127.0.0.1:7001> auth 123456
  3. OK
  4. 127.0.0.1:7001> info replication
  5. # Replication
  6. role:slave
  7. master_host:127.0.0.1
  8. master_port:7002
  9. master_link_status:up
  10. master_last_io_seconds_ago:1
  11. master_sync_in_progress:0
  12. # 省略
  13. 127.0.0.1:7001> exit
  14. [root@dev-server-1 sentinel]# redis-cli -p 7002
  15. 127.0.0.1:7002> auth 123456
  16. OK
  17. 127.0.0.1:7002> info replication
  18. # Replication
  19. role:master
  20. connected_slaves:1
  21. slave0:ip=127.0.0.1,port=7001,state=online,offset=13642721,lag=1
  22. # 省略

可以看到slave 7002已经成功上位晋升为master（role：master），接收一个slave 7001的连接。此时查看slave2.conf配置文件，发现replicaof的配置已经被移除了，slave1.conf的配置文件里replicaof 127.0.0.1 6379 被改为 replicaof 127.0.0.1 7002。重新启动master，也可以看到master.conf配置文件中添加了replicaof 127.0.0.1 7002的配置项，可见大哥（master）下位后，再出来混就只能当当小弟（slave）了，三十年河东三十年河西。

  1. 哨兵模式的优缺点
    优点：

  2. 哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有

  3. 哨兵模式下，master挂掉可以自动进行切换，系统可用性更高

缺点：

  1. 同样也继承了主从模式难以在线扩容的缺点，Redis的容量受限于单机配置
  2. 需要额外的资源来启动sentinel进程，实现相对复杂一点，同时slave节点作为备份节点不提供服务

Cluster模式

  1. 基本原理
    哨兵模式解决了主从复制不能自动故障转移，达不到高可用的问题，但还是存在难以在线扩容，Redis容量受限于单机配置的问题。Cluster模式实现了Redis的分布式存储，即每台节点存储不同的内容，来解决在线扩容的问题。如图

image.png

Cluster采用无中心结构,它的特点如下：

  1. 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽
  2. 节点的fail是通过集群中超过半数的节点检测失效时才生效
  3. 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

Cluster模式的具体工作机制：

  1. 在Redis的每个节点上，都有一个插槽（slot），取值范围为0-16383
  2. 当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作
  3. 为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点
  4. 当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了

Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Cluster模式的部署比较简单，首先在redis.conf中

  1. port 7100 # 本示例6个节点端口分别为7100,7200,7300,7400,7500,7600 
  2. daemonize yes # r后台运行 
  3. pidfile /var/run/redis_7100.pid # pidfile文件对应7100,7200,7300,7400,7500,7600 
  4. cluster-enabled yes # 开启集群模式 
  5. masterauth passw0rd # 如果设置了密码，需要指定master密码
  6. cluster-config-file nodes_7100.conf # 集群的配置文件，同样对应7100,7200等六个节点
  7. cluster-node-timeout 15000 # 请求超时 默认15秒，可自行设置

分别以端口7100,7200,7300,7400,7500,7600 启动六个实例(如果是每个服务器一个实例则配置可一样)

  1. [root@dev-server-1 cluster]# redis-server redis_7100.conf
  2. [root@dev-server-1 cluster]# redis-server redis_7200.conf
  3. ...

然后通过命令将这个6个实例组成一个3主节点3从节点的集群，

  1. redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7100 127.0.0.1:7200 127.0.0.1:7300 127.0.0.1:7400 127.0.0.1:7500 127.0.0.1:7600 -a passw0rd

可以看到 7100， 7200， 7300 作为3个主节点，分配的slot分别为 0-5460， 5461-10922， 10923-16383， 7600作为7100的slave， 7500作为7300的slave，7400作为7200的slave。
我们连接7100设置一个值

  1. [root@dev-server-1 cluster]# redis-cli -p 7100 -c -a passw0rd
  2. Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
  3. 127.0.0.1:7100> set site blog.jboost.cn
  4. -> Redirected to slot [9421] located at 127.0.0.1:7200
  5. OK
  6. 127.0.0.1:7200> get site
  7. "blog.jboost.cn"
  8. 127.0.0.1:7200>

注意添加 -c 参数表示以集群模式，否则报 (error) MOVED 9421 127.0.0.1:7200 错误， 以 -a 参数指定密码，否则报(error) NOAUTH Authentication required错误。
从上面命令看到key为site算出的slot为9421，落在7200节点上，所以有Redirected to slot [9421] located at 127.0.0.1:7200，集群会自动进行跳转。因此客户端可以连接任何一个节点来进行数据的存取。
通过cluster nodes可查看集群的节点信息

  1. 127.0.0.1:7200> cluster nodes
  2. eb28aaf090ed1b6b05033335e3d90a202b422d6c 127.0.0.1:7500@17500 slave c1047de2a1b5d5fa4666d554376ca8960895a955 0 1584165266071 5 connected
  3. 4cc0463878ae00e5dcf0b36c4345182e021932bc 127.0.0.1:7400@17400 slave 5544aa5ff20f14c4c3665476de6e537d76316b4a 0 1584165267074 4 connected
  4. dbbb6420d64db22f35a9b6fa460b0878c172a2fb 127.0.0.1:7100@17100 master - 0 1584165266000 1 connected 0-5460
  5. d4b434f5829e73e7e779147e905eea6247ffa5a2 127.0.0.1:7600@17600 slave dbbb6420d64db22f35a9b6fa460b0878c172a2fb 0 1584165265000 6 connected
  6. 5544aa5ff20f14c4c3665476de6e537d76316b4a 127.0.0.1:7200@17200 myself,master - 0 1584165267000 2 connected 5461-10922
  7. c1047de2a1b5d5fa4666d554376ca8960895a955 127.0.0.1:7300@17300 master - 0 1584165268076 3 connected 10923-16383

我们将7200通过 kill -9 pid杀死进程来验证集群的高可用，重新进入集群执行cluster nodes可以看到7200 fail了，但是7400成了master，重新启动7200，可以看到此时7200已经变成了slave。

  1. Cluster模式的优缺点
    优点：

  2. 无中心架构，数据按照slot分布在多个节点。

  3. 集群中的每个节点都是平等的关系，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
  4. 可线性扩展到1000多个节点，节点可动态添加或删除
  5. 能够实现自动故障转移，节点之间通过gossip协议交换状态信息，用投票机制完成slave到master的角色转换

缺点：

  1. 客户端实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度。目前仅JedisCluster相对成熟，异常处理还不完善，比如常见的“max redirect exception”
  2. 节点会因为某些原因发生阻塞（阻塞时间大于 cluster-node-timeout）被判断下线，这种failover是没有必要的
  3. 数据通过异步复制，不保证数据的强一致性
  4. slave充当“冷备”，不能缓解读压力
  5. 批量操作限制，目前只支持具有相同slot值的key执行批量操作，对mset、mget、sunion等操作支持不友好
  6. key事务操作支持有线，只支持多key在同一节点的事务操作，多key分布不同节点时无法使用事务功能
  7. 不支持多数据库空间，单机redis可以支持16个db，集群模式下只能使用一个，即db 0

Redis Cluster模式不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。

其中主从复制模式能实现读写分离，但是不能自动故障转移；哨兵模式基于主从复制模式，能实现自动故障转移，达到高可用，但与主从复制模式一样，不能在线扩容，容量受限于单机的配置；Cluster模式通过无中心化架构，实现分布式存储，可进行线性扩展，也能高可用，但对于像批量操作、事务操作等的支持性不够好。三种模式各有优缺点，可根据实际场景进行选择。

  1. 数据淘汰策略
  3. Redis哈希槽
  5. Redis集群的主从复制模型
  7. Redis集群最大节点个数是多少

位图数据结构

它的内容其实就是普通的字符串，也就是 byte 数组。

布隆过滤器

布隆过滤器可以理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。

scan 相比 keys 具备有以下特点:

  1. 复杂度虽然也是 O(n)，但是它是通过游标分步进行的，不会阻塞线程;
  2. 提供 limit 参数，可以控制每次返回结果的最大条数，limit 只是一个 hint，返回的结果可多可少;
  3. 同 keys 一样，它也提供模式匹配功能;
  4. 服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数;
  5. 返回的结果可能会有重复，需要客户端去重复，这点非常重要;
  6. 遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的;
  7. 单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零;

redis性能测试

参考