Redis

Redis

[官方地址][https://www.redis.net.cn/]

---

数据类型

类型	简介	特性	场景
String(字符串)	二进制安全	可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M	—
Hash(字典)	键值对集合,即编程语言中的Map类型	适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值	存储、读取、修改用户属性
List(列表)	链表(双向链表)	增删快,提供了操作某一段元素的API	1、最新消息队列 2、消息队列
Set(集合)	哈希表实现,元素不重复	1、添加、删除、查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作	1、共同好友 2、利用唯一性,统计访问网站的所有独立 IP 3、好友推荐
Sorted Set(有序集合)	将Set中的元素增加一个权重参数score,元素按score有序排列	数据插入集合时,已经进行天然排序	1、排行榜 2、带权重的消息队列

具体查看：【 Redis 数据结构 】

---

优势特点

• 性能极高 – Redis能读的速度是110000次/s，写的速度是81000次/s 。

• Redis支持事务，操作都是原子性，所谓原子性就是对数据的更改要么全部执行，要不全部不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来，不可回滚。

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

• Redis不仅仅支持简单的key-value类型的数据，同时还提供 String，List，Hash，Set 及 Sorted Sets等数据结构的存储。

• Redis支持数据的备份，即master-slave模式的数据备份。

• Redis还支持 publish/subscribe，通知，key 过期等等特性。

---

分布式

支持主从的模式。

原则：

Master 会将数据同步到 Slave ，而 Slave 不会将数据同步到 Master 。Slave 启动时会连接 Master 来同步数据。典型的读写分离模型。利用 Master 来插入数据，Slave 提供检索服务。有效减少单个机器的并发访问数量。

缺陷：

（1）主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主。

（2）主从复制主节点的写能力单机，能力有限。

（3）单机节点的存储能力也有限。

哨兵机制：

当主节点出现故障时，由 Redis Sentinel （哨兵）自动完成故障发现和转移，并通知应用方，实现高可用性。

Redis Sentinal 着眼于高可用，在Master 宕机时会自动将Slave 提升为Master ，继续提供服务。

Redis Cluster 着眼于扩展性，在单个 Reids 内存不足时，使用 Cluster 进行分片存储。

具体查看：【 Redis 主从复制 】

---

分布式锁

​ 采用 redis 命令setnx（set if not exist）、setex（set expire value）实现。

​ 先拿 setnx 来争抢锁，抢到之后，再用 setex 给锁加一个过期时间防止锁忘记释放。

---

回收策略

Redis 内存回收机制主要体现在以下两个方面：

1. 删除到达时间的键对象。
2. 内存使用达到 maxmemory 上限时触发内存溢出控制策略。

（1）删除过期键对象

Redis所有的键都可以设置过期属性，内部保存在过期字典中。由于进程内保存了大量的键，维护每个键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此Redis采用惰性删除和定时任务删除机制实现过期键的内存回收。

惰性删除：惰性删除用于当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空，这种策略是出于节省CPU成本考虑，不需要单独维护TTL链表来处理过期键的删除。但是单独用这种方式存在内存泄露的问题，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。正因为如此，Redis还提供另一种定时任务删除机制作为惰性删除的补充。

定时任务删除：Redis内部维护一个定时任务，默认每秒运行10次（通过配置控制）。定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例，使用快慢两种速率模式回收键。

比如：

1. 定时任务在每个数据库空间随机检查20个键，当发现过期时删除对应的键。
2. 如果超过检查数25%的键过期，循环执行回收逻辑直到不足25%或运行超时为止，慢模式下超时时间25ms。
3. 如果之前回收键逻辑超时，则在每次Redis触发内部事件之前再次以快模式运行回收过期键任务，快模式下超时时间为1ms且2s内只能运行1次。
4. 快慢两种模式内部删除逻辑相同，只是执行的超时时间不同。

（2）内存溢出控制策略

当Redis所用内存达到 maxmemory 上限时会触发相应的溢出控制策略。具体策略受 maxmemory-policy 参数控制，Redis支持6种策略，如下所示：

1. noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。不推荐。

2. allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。推荐使用，目前项目在用这种。

3. allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。不推荐，不删最少使用 Key，去随机删。

4. volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。

5. volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。不推荐。

6. volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。不推荐。如果没有对应的键，则回退到noeviction策略。

---

持久化

Redis 提供了不同级别的持久化方式，一种是RDB，一种AOF。可以同时开启两种持久化方式,。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

具体查看：【 Redis 持久化 】

---

事务

关系型数据中的事务都是原子性的，而redis 的事务是非原子性的。（出现错误不会回滚，将会继续执行）

Redis 事务相关命令：

• MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用 EXEC 命令顺序执行这个命令系列。

• EXEC： 执行事务中的所有操作命令。

• DISCARD： 取消事务，放弃执行事务块中的所有命令。

• WATCH： 监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。

• UNWATCH： 取消WATCH对所有key的监视。

---

消息队列

队列模式

队列支持多个生产者和消费者并发进出消息，每个消费者拿到都是不同的列表元素。

一般使用 list 结构作为队列，rpush 生产消息，lpop 消费消息。当 lpop 没有消息的时候，要适当 sleep 一会再重试（防止空轮询）。另一个更好的解决方法是使用 blpop，在没有消息的时候，它会阻塞住直到消息到来。阻塞读在队列没有数据的时候进入休眠状态，一旦数据到来则立刻醒过来，消息延迟几乎为零。

注意

如果线程一直阻塞在那里，Redis客户端的连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用，会抛出异常，所以生产者和消费者需要捕获到异常，然后进行重试。

缺点：

• 不能做广播模式，消息发布/订阅模型，多个消费者重复消费，以及分组消费等。

• 消费者确认 ACK 麻烦，不能保证消费者消费消息后是否成功处理的问题（宕机或处理异常等），通常需要维护一个 Pending列表，保证消息处理确认。

生产者：

public class MQProducerTest {
    private StringRedisTemplate redisTemplate;
    private ListOperations<String, String> listRedis;
    
    @PostConstruct
    private void init(){
        listRedis = redisTemplate.opsForList();
    }
    
    @Test
    public void test() {
        for(int i=1; i<=10; i++){
     
            listRedis.leftPush("storage", i + "");
        }
    }
}

消费者：

public class MQConsumerTest {
    @Autowired
    private StringRedisTemplate redisTemplate;

    private ListOperations<String, String> listRedis;
    
    @PostConstruct
    private void init(){
        listRedis = redisTemplate.opsForList();
    }
    
    @Test
    public void test() {
        while(true){
            String msg = listRedis.rightPop("storage");
            if(StringUtils.isEmpty(msg)){
                System.out.println("消息已全部取出");
                break;
            }
            System.out.println(msg);
        }
    }
}

订阅/发布模式

优点

典型的广播模式，一个消息可以发布到多个消费者。

多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息。

消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息。

缺点

在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如RocketMQ等。

不能保证每个消费者接收的时间是一致的。

若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外丢失。通常发生在消息的生产远大于消费速度时。

Pub/Sub 模式不适合做消息存储，消息积压类的业务，而是擅长处理广播，即时通讯，即时反馈的业务

订阅监听：

public class SubscribeListener implements MessageListener {
    @Override
    public void onMessage(Message message, byte[] pattern) {
        System.out.println(new String(pattern) + "发布" + new String(message.getBody()));
    }
}

发布服务：

public class PublishService {

    StringRedisTemplate redisTemplate;
    
    public void publish(String channel, Object message) {
        redisTemplate.convertAndSend(channel, message);
    }
}

定义监听主题：

@Configuration
public class RedisConfig {
    @Autowired
    private JedisConnectionFactory jedisConnectionFactory;

    @Bean
    public RedisMessageListenerContainer redisMessageListenerContainer() {

        RedisMessageListenerContainer container = new RedisMessageListenerContainer();

        container.setConnectionFactory(jedisConnectionFactory);

        container.addMessageListener(new SubscribeListener(), new PatternTopic("topic"));
        
        return container;
    }
}

测试：

public class PublishTest {

    @Autowired
    private PublishService publishService;

    @Test
    public void test() {
        for(int i=1; i<=10; i++){
            publishService.publish("topic", "like " + i + " 次");
        }
    }
}