[大数据]Redis-实习期笔记

Redis

简介：

• 高性能key-value数据库，缓存产品

  1. 数据持久化，数据从内存存储到磁盘，重启时可再次加载
  2. 提供了list，set，zset，hash等数据结构的存储
  3. 支持master-slave模式的数据备份

• 优势

  1. 极高性能
  2. 丰富数据类型
  3. 原子-单操作原子性，多操作支持事务
  4. 丰富特性

配置：

启动与连接：

• 远程连接：redis-cli -h host -p port -a password

配置语法：

获取配置信息
redis 127.0.0.1:6379> CONFIG GET 'CONFIG_SETTING_NAME' 例子:CONFIG GET * 获取所有配置信息
设置配置信息
redis 127.0.0.1:6379> CONFIG SET 'CONFIG_SETTING_NAME' 'CONFIG' 例子：CONFIG SET loglevel "notice" 指定日志记录级别

数据结构：

字符串

• 最基本类型，一个key对应一个value，最大512MB
• 二进制安全，可以包含任何数据

• 场景：常规key-value缓存应用

Hash

• 键值对的集合
• string类型的field和value的映射表，hash特别适合存储对象
• 每个 hash 可以存储 2³² -1 键值对（40多亿）

• **使用场景：**存储部分变更数据，如用户信息等。

List

• 简单的字符串列表，按照插入顺序排序。可添加元素到头或尾
• 使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。

• 使用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。

Set

• Redis Set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的
• Set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
• Set可以取交集(sinter)、并集(sunion)、差集(sdiff)
• 使用场景：数据需要去重的情况

sorted set

• 同集合一样是string类型元素的集合，不允许重复成员
• 每个元素会关联一个double类型的分数，通过该分数从小到大排列
• 有序集合的成员是唯一的,但分数(score)却可以重复。
• 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
• 集合中最大的成员数为 2³² - 1

Redis HyperLogLog

• 用来做基数统计的算法，再输入元素的数量或者体积非常大时，计算基数所需的空间总是固定且很小的
• HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。
• 每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。
• 基数：基数估计就是在误差可接受的范围内，快速计算基数。

ps：注意这里的数量为估计数，并非准确数值，在量非常大并且不需要保存数据本身的适合使用

例子：

1. 按照ip统计计算网站每日的用户访问数量，并不在乎ip具体数据，在量非常大的适合也不需要非常准确的数字
2. 统计在线用户人数
3. 用户每天搜索不同词条的数量

发布和订阅

• 发送者发送消息，订阅者接收消息
• 客户端可以订阅任意数量的频道

GEO

• 用于存储地理位置信息

  • geoadd：添加地理位置的坐标。
  • geopos：获取地理位置的坐标。
  • geodist：计算两个位置之间的距离。
  • georadius：根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
  • georadiusbymember：根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
  • geohash：返回一个或多个位置对象的 geohash 值。

事务

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

特点：

• 单命令具备原子性，而事务并不具备。执行A,B,C三条命令，B失败了，A不会被回滚，C依旧执行，不影响

数据备份

把备份文件复制到安装目录即可

安全

1. 默认下没有密码，可以设置。设置密码后连接都需要输入密码验证，否则语法运行命令

   

Redis实际应用场景举例

1. 显示最新的项目列表

   比如首页展示最新的50条文章，如果每次都去数据库使用排序LIMIT查询，随着文章数量增多效率可想而知，况且在插入数据的时候就是按找时间顺序的。

   解决：可以使用使用Redis的list在每次有新文章发布时将文章的唯一标识ID push 进list，并且可以通过裁剪list长度来指定保存的数量

2. 取TOP操作

   当数据需要以某些条件为权重的时候，比如点赞数、收藏数。并且有的时候需要实时更新排名，比如游戏排名，此时在硬盘上进行数据库的频繁读写就更不实际了。

   解决：使用sorted set，设置score为排序权重，数据设置为value。sset不管是截取还是取得所有排名都非常容易。

3. 删除和过滤

   我们可以使用LREM来删除评论。如果删除操作非常少，另一个选择是直接跳过评论条目的入口，报告说该评论已经不存在。 有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制，你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目，但Redis却能够使用非常少的内存来处理几百万条项目。

4. 按照用户投票和时间排序

5. 处理过期项目

6. 计数

7. 特定时间内的特定项目

8. 查找某个值所在的区间

Redis主从配置

• 为了使得集群在一部分节点下线或者无法与集群的大多数节点进行通信的情况下，仍然能够正常运行，Redis集群使用了主从复制功能。 集群中的每个节点都有 1 个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1 个复制品为从节点（slave）。

  

• 特点：

1.一主可多从
2.除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构
3.主从复制不会阻塞master，但是会阻塞slave。当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。
4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余
5.可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。
6.可以用于读写分离和容灾恢复。

实现(Windows环境下)：

1. 三个服务，模拟一主二从

2. 配置从服务下的配置文件，指定端口以及主服务

3. 启动三个服务

   对应文件夹下cmd：redis-server.exe redis.windows.conf

4. info replication查看节点信息

5. 读写

   

   

   原理介绍：

   1. 当设置好slave服务器后,slave会建立和master的连接，然后发送sync命令。
   2. Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。
   3. 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。（第一次全量）
   4. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。（之后增量）
   5. 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。

   问题：

   • IO剧增
     每次slave断开以后（无论是主动断开，还是网路故障）再连接master都要将master全部dump出来rdb，在aof，即同步的过程都要重新执行一遍；所以要记住多台slave不要一下都启动起来，否则master可能IO剧增（间隔1-2分）

   • 复制延迟
     由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

   • 可用性不高
     当有主节点发生异常情况，就会导致不能写入，导致业务出错！

Redis-sentinel

• 使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。
• Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

环境：

• 主从服务配置同上

• 哨兵配置：

  /#当前Sentinel服务运行的端口
  port 26379
  /# 哨兵监听的主服务器
  sentinel monitor mymaster 127.0.0.1 6379 2
  /# 3s内mymaster无响应，则认为mymaster宕机了
  sentinel down-after-milliseconds mymaster 3000
  /#如果10秒后,mysater仍没启动过来，则启动failover
  sentinel failover-timeout mymaster 10000
  /# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
  sentinel parallel-syncs mymaster 1

  ps:

  sentinel monitor [master-group-name] [ip] [port] [quorum]

  • master-group-name：master名称（可以自定义）
  • ip port : IP地址和端口号
  • quorun：票数，Sentinel需要协商同意master是否可到达的数量。

• 启动哨兵：

  redis-server.exe redis.windows.conf --sentinel

情况一：主服务器关闭

1. 首先关闭主服务器 （shutdown指令）

2. 查看哨兵的日志

   • 主观下线：一部分哨兵联系不上了
   • 客观下线：大部分哨兵（人为设置的投票数）都联系不上了
   • 哨兵之间也会互相监控，有哨兵下线了其他哨兵也会知道

   

   

   • 最后选出了新的主服务器，形成了新的主从关系，哨兵也都重新指定到了新的主服务器上。
   • 此时进入各服务的config也可以看到指向的主服务已经变了
   3. 原主服务重启后并不会恢复关系，该服务会成为新的主服务器的从服务

场景二：从服务器重启

• 从服务器重启后哨兵会监控到，并且重新上线后会恢复主从状态
• 即使哨兵不开也是可以做到的

淘汰策略

maxmemory 配置指令

maxmemory 用于指定 Redis 能使用的最大内存。既可以在 redis.conf 文件中设置, 也可以在运行过程中通过 CONFIG SET 命令动态修改。

例如, 要设置 100MB 的内存限制, 可以在 redis.conf 文件中这样配置：maxmemory 100mb

达到最大内存限制时(maxmemory), Redis 根据 maxmemory-policy 配置的策略, 来决定具体的行为。

• noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。 大多数写命令都会导致占用更多的内存(有极少数会例外, 如 DEL )。
• allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
• volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
• allkeys-random: 所有key通用; 随机删除一部分 key。
• volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。
• volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。

如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

选择：

1. 如果分为热数据与冷数据, 推荐使用 allkeys-lru 策略。 也就是, 其中一部分key经常被读写. 如果不确定具体的业务特征, 那么 allkeys-lru 是一个很好的选择。
2. 如果需要循环读写所有的key, 或者各个key的访问频率差不多, 可以使用 allkeys-random 策略, 即读写所有元素的概率差不多。
3. 假如要让 Redis 根据 TTL 来筛选需要删除的key, 请使用 volatile-ttl 策略。

集群

介绍：

• 集群由多个节点(Node)组成，Redis 的数据分布在这些节点中。

• 集群中的节点满足主从关系。

作用：

• **数据分区：**数据可以分散到不同节点存储
• **负载均衡：**所有主节点，都可以处理读写，提高并发能力
• **高可用：**拥有故障转移的能力，提升集群稳定性

环境：

1. 6个服务

   

2. 6个服务节点的config需要修改以下配置

   cluster-enabled yes

   cluster-config-file nodes-6379.conf

   cluster-node-timeout 15000

   appendonly yes

3. 启动6个服务

4. 开启命令（Redis5不再依赖ruby，可以使用指令直接构建集群）

   redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

   ps：

   • –cluster-replicas 1表示每个主服务有一个从服务
   • 至少不要3个主服务（最好为奇数），共6个节点
   • cluster-enabled yes 不能和 slaveof 同用

5. 运行集群

   

6. 操作

   1. 读写

   

   • 在一个集群不同的主服务间可以读写在集群上的数据，不一定是各自分到的槽位

   2. 加入主节点并分片

      添加节点命令：redis-cli --cluster add-node 新节点ip:新节点port 集群中以存在的节点ip:集群中已存在的节点port

      

      分片命令：redis-cli --cluster reshard 需要分片的节点ip:需要分片的节点端口

      

      添加后的节点并不会自动分配槽位，需要分片命令手动分配槽位

   3. 添加从节点

      第一步：将新节点添加到集群中，命令参考上一条
      第二步：进入新节点，执行命令 cluster replicate 主服务id
      命令：1、redis-cli -c -p 7008 -h 172.19.206.207 进入新节点
      ? ? 2、cluster replicate 0197892b29048155077ee4d23dd5517737f40377 这一串为主服务的节点id
      可以执行 cluster nodes 命令查看情况

   4. 删除节点

      删除主节点稍微麻烦一点，如果主节点中存在槽，那么需要先将槽分配给其它的主节点。

      如删除主节点 127.0.0.1:6379

      1. 归还槽位 参考上面分片操作
      2. 命令: redis-cli --cluster del-node 127.0.0.1:6379 节点id

      删除从节点没有归还槽位的操作

SpringBoot整合Redis

基本配置

1. 导入依赖

   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-data-redis</artifactId>
   </dependency>
   

2. 配置连接

   application.propertis

   # 配置Redis连接
   spring.redis.host=localhost
   spring.redis.port=6379
   # 密码别忘了，如有的话
   spring.redis.password=123456
   

3. 测试

   @Autowired
   // 获取Redis操作对象
   private RedisTemplate redisTemplate;
   
   @Test
   public void connectTest() {
       // 获取连接对象
       RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
       // 对应了Redis的PING命令
       logger.info("PING:" + connection.ping());
       logger.info("CONNECT IS CLOSED:" + connection.isClosed());
   }
   

   

SpringBoot的Redis自动配置类

自定义RedisTemlate类

@Configuration
public class RedisConfig {
    
    /**
     *   redisTemplate固定模板
     * @param redisConnectionFactory 连接工厂
     * @return 自定义redisTemplate
     */
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 为了方便使用，一般直接使用<String, Object>
        RedisTemplate<String, Object> template = new RedisTemplate<>();

        // 设置连接工厂
        template.setConnectionFactory(redisConnectionFactory);

        // Json序列化配置
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        objectMapper.activateDefaultTyping(
            LaissezFaireSubTypeValidator.instance ,
            ObjectMapper.DefaultTyping.NON_FINAL,
            JsonTypeInfo.As.WRAPPER_ARRAY);
        jackson2JsonRedisSerializer.setObjectMapper(objectMapper);

        // String的序列化
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();

        // key采用String序列化方式
        template.setKeySerializer(stringRedisSerializer);
        // value采用jackson序列化
        template.setValueSerializer(jackson2JsonRedisSerializer);
        // hash的value序列化方式采用jackson
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();

        return template;
    }
}

问题和解决：

1. 想要读取Redis中控制台创建的列表 ，但是出错的问题

开启控制台一查发现，java没有访问已有的list列（由控制台创建的），而是新建了一个奇奇怪怪的，且key和value前面都多了一串编码

解决：查阅后发现，是序列化的问题，解决方式是自己自定义一个redisTemlate

整合Redis集群

1. 添加依赖

   <!--去看了一眼spring-boot-starter-data-redis，其实已经有jedis了，就不用再导了-->
   <dependency>
       <groupId>redis.clients</groupId>
       <artifactId>jedis</artifactId>
   </dependency>
   

2. 配置

   spring:
     redis:
       cluster:
         #设置key的生存时间，当key过期时，它会被自动删除；
         expire-seconds: 120
         #设置命令的执行时间，如果超过这个时间，则报错;
         command-timeout: 5000
         #设置redis集群的节点信息，配置相应的地址;
         nodes: localhost:6379,localhost:6380,localhost:6381,localhost:6382,localhost:6383,localhost:6384
       # 服务地址
       host: localhost
       # 连接端口
       port: 6379
       # 连接超时
       connect-timeout: 5000
   

3. 使用同前面的使用方式

   运行前面的测试代码，分别插入hash和set类型的数据

   插入的信息会自动插入到集群的槽位中

   

附录

配置参考：

Redis日志参数

+reset-master ：主服务器已被重置。
+slave ：一个新的从服务器已经被 Sentinel 识别并关联。
+failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
+failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
+slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器。
+slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
+slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。
-dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
+sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
+sdown ：给定的实例现在处于主观下线状态。
-sdown ：给定的实例已经不再处于主观下线状态。
+odown ：给定的实例现在处于客观下线状态。
-odown ：给定的实例已经不再处于客观下线状态。
+new-epoch ：当前的纪元（epoch）已经被更新。
+try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
+elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。
+failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。
failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
+switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
+tilt ：进入 tilt 模式。
器的从服务器。
no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。
failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
+switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
+tilt ：进入 tilt 模式。
-tilt ：退出 tilt 模式。