Redis 入门学习笔记

本文介绍

本文主要记录了 Redis 学习过程中归纳的知识点笔记，使用环境为 Windows10，Redis为 5.0.1 版本。

Nosql概述

为什么要用 NoSQL

90年代,一个基本的网站访问量一般不会太大,单个数据库完全足够!

那个时候，更多的去使用静态网页Html ~服务器根本没有太大的压力!

思考一下,这种情况下:整个网站的瓶颈是什么?

1. 数据量如果太大、一个机器放不下了!
2. 数据的索引(B+Tree),一个机器内存也放不下
3. 访问量(读写混合) , -个服务器承受不了~

只要你开始出现以上的三种情况之一，那么你就必须要晋级 !

Memcached(缓存) +MySQL + 垂直拆分 （读写分离）

分库分表 + 水平拆分 + MySQL集群

本质：数据库(读,写)

早些年MyISAM:表锁,十分影响效率!高并发下就会出现严重的锁问题

转战Innodb : 行锁

为什么要用Nosql

关系型数据库无法处理如此巨大的数据量。

什么是 NoSQL

NoSQL

Not Only SQL 不仅仅是 SQL

泛指非关系型数据库

用 Map<String, Object> 存储

关系型数据库： 表格， 行，列

NoSQL特点

解耦!

1、方便扩展(数据之间没有关系,很好扩展!

2、大数据量高性能( Redis 一秒写8万次,读取11万, NoSQL的缓存记录级,是一种细粒度的缓存,性能会比较高! )
3、数据类型是多样型的! (不需要事先设计数据库!随取随用!如果是数据量十分大的表,很多人就无法设计了! )
4、传统RDBMS和NoSQL

传统的RDBMS
- 结构化组织
- SQL
- 数据和关系都存在单独的表中		row col 
- 操作操作，数据定义语言
- 严格的一致性
- 基础的事务

Nosq1
- 不仅仅是数据
- 没有固定的查询语言
- 键值对存储，列存储，文档存储，图形数据库(社交关系)
-最终一致性，
- CAP定 理和BASE (异地多活)

了解 3V + 3高

大数据时代的3V ：主要是描述问题的

1. 海量Volume

2. 多样Variety

3. 实时Velocity

大数据时代的3高：主要是对程序的要求

1. 高并发.

2. 高可拓 (随时水平拆分)

3. 高性能

一起使用

NoSQL四大分类

KV键值对:

• 新浪:Redis
• 美团: Redis + Tair
• 阿里、百度: Redis + memecache

文档型数据库( bson格式和json一样) :

• MongoDB (- 般必须要掌握)
  • MongoDB是一个基于分布式文件存储的数据库，C++编写,主要用来处理大量的文档!
  • MongoDB是一个介于关系型数据库和非关系型数据中中间的产品! MongoDB是非关系型数据库中功能最丰富,最像关系型数据库的!

列存储数据库

• HBase
• 分布式文件系统

图关系数据库

• 社交网络，广告推荐
• Neo4j，Infogrid

Redis 入门

Redis 是什么

Redis（Remote Dictionary Server )，即远程字典服务

结构化数据库

redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步

Redis能干什么

1. 持久化存储（rdb，aof）
2. 效率高,可以用于高速缓存
3. 发布订阅系统
4. 地图信息分析
5. 计时器、计数器(浏览量!)

特性

1. 多样的数据类型
2. 持久化
3. 集群
4. 事务

官网：https://redis.io/

中文官网：https://www.redis.net.cn/

安装 windows, 5.0.1

推荐使用 linux系统，但是不做底层会用就行，在习惯的系统上使用即可

https://github.com/tporadowski/redis/releases

解压后，打开 server 和 cli ，即可在 cli 服务上使用

基本指令

默认有 16 个数据库，使用的是第 0 个， 可以通过 select 切换

select index	// 选择 [index] 数据库

DBSIZE	// 查看当前库的大小
keys *	// 查看所有的 key
FLUSHDB	// 清空当前库
FLUSHALL // 清空所有库
move key db	// 将 key 移动到 db
set key value	// 将 key 的值设为 value
get key value   // 获取 key 的 value
EXPIRE key seconds  // 让 key 在 seconds 后过期
TTL key		// 查看 key 的 time to live 时间
TYPE key 	// 查看 key

基础知识

Redis是单线程的！

Redis是很快的,官方表示, Redis是基于内存操作, CPU不是Redis性能瓶颈, Redis的瓶颈是根据机器的内存和网络带
宽,既然可以使用单线程来实现,就使用单线程了!所有就使用了单线程了!

Redis是C语言写的,官方提供的数据为100000+ 的QPS ,完全不比同样是使用key-vale的Memcache差!

Redis为什么单线程还这么快？

误区1 :高性能的服务器一 定是多线的

误区2:多线程( CPU上下文会切换) 一定比单线程效率高

速度： CPU>内存>硬盘

核心： redis是将所有的数据全部放在内存中的,所以说使用单线程去操作效率就是最高的,多线程( CPU上下文会切换:耗时的操作) , 对于内存系统来说,如果没有上下文切换效率就是最高的。多次读写都在同一个CPU上，在内存上，单线程是最佳方案

五大基本类型

官方文档

Redis是一个开源（BSD许可），内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列代理MQ。它支持字符串、哈希表、列表、集合、有序集合，位图，hyperloglogs等数据类型。内置复制、Lua脚本、LRU收回、事务以及不同级别磁盘持久化功能，同时通过Redis Sentinel提供高可用，通过Redis Cluster提供自动分区。

Redis-Key

Key - value 操作

String

APPEND key value // 在 key 的 value 后追加 value  如果 key 不存在，则相当于 set key value
STRLEN key 	// 查看 key 的 value 长度
INCR key 	// key++ 自增1
DECR key 	// key-- 自减1
INCRBY key increment 	// 使 key 增加 increment  设置步长

-------------------------------------------------

GETRANGE key start end	// 获取 key 的 [start, end]。注意 闭区间。
					  // 如果 end < 0， 则取到倒数第 end 个
SETRANGE key offset value	// 将 key 从 key[offset] 开始替换 value

SETEX key seconds value // 设置 key value 在 seconds 后过期
SETNX key value		   // 当 key 不存在时设置 value	(分布式时常用)

--------------------------------------------------

mset [key value...]		// 可以一次设置多个 key-value
msetnx [key value...]	// 同时设置多个值，当且仅当所有 key 都不存在
mget [key...]		    // 一次获取多个 key

getset key value	// 先 get key 的值，然后将 key 设置为 value 如果不存在则返回 nil

------------------------------------------------------------
# 
127.0.0.1:6379> mset user:1:name zjz user:1:age 18
127.0.0.1:6379> keys *
1) "user:1:age"
2) "user:1:name"
127.0.0.1:6379> mget user:1:name user:1:age
1) "zjz"
2) "18"

计数器

List

列表

LPUSH key value	// 向列表 key 左侧推入一个 value
RPUSH key value	// 向列表 key 右侧推入一个 value
LRANGE key start end 	// 从左边开始获取 key [start, end]

------------------------------------------------------------

LPOP key	// 从左侧弹出一个值
RPOP key	// 从右侧弹出一个值
LINDEX key index	// 获取 list[index]
LLEN key	// 获取 list 的长度
LREM key count value 	// 从 key 中移除 count 个 value	返回实际移除个数
LSET key index value 	// 设置 key[index] 为 value
LINSERT key BEFORE / AFTER pivot value 	// 向 key 的 pivot 前 / 后 插入 value

LTRIM key start stop	// 将 key 截断， 剩下 k[start, stop]

实际上是一个双向链表

• key 不存在，创建新链表
• 两头操作 O(1)

应用

• 消息队列，缓存，栈

Set

SADD key [members...]		// 向 key 中加入多个 member
SMEMBERS key	// 查询 key 的所有成员
SISMEMBER key value		// 查询 value 是否存在于 key
SCARD key	// 查询set集合的元素个数
SREM key [values]	 // 移除 values
SRANDMEMBER key	(count)	// 从 key 中随机抽取 count 个元素
SPOP key (count)	// 随机删除一个元素
SMOVE source dest value	// 将 source 中的 value 移动到 dest 中

------------------------------------------------------------

SDIFF key [keys...]		// 查询 key 中与 keys 中不同的元素
SINTER [keys...]		// 查询 keys 的交集
SUNION [keys...]		// 查询 keys 的并集

Hash

Map集合

和 String 差不多，还是 key-value

HSET hash feild value	//	往 hash 中添加键值对
HMSET hash [feild value...]	//	往 hash 中添加键值对
HSETNX hash feild value	// 如果不存在则插入
HGET hash feild		// 获取 feild 的 value
HMGET hash [feilds]		// 获取 feild 的 value
HGETALL hash	// 获取所有键值对
HDEL hash feild	// 删除键值对
HLEN hash	// 获取 hash 的键值对个数
HEXISTS hash feild 	// 判断 feild 是否存在
HKEYS hash	// 获取所有的 key
HVALS hash	// 获取所有的 value
HINCRBY hash feild increment	// 指定自增
HDECRBY hash feild decrement	// 指定自减

hash 更适合对象的存储

ZSet

有序集合

ZADD zset score member	// 添加一个元素，权值为 score
ZRANGE zset start end	// 获取 zset 中的元素
ZREVRANGE zset start end // 返回从大到小排序的 [start, end]
ZRANGEBYSCORE zset min max (withscores)	// 返回 [min, max] 之间升序排列的数据，(并展示 scores)
ZREM zset member	// 移除 member
ZCARD zset	// 获取元素个数
-inf +inf	// 正负无穷
ZCOUNT zset start end	// 返回 score 在 [start, end] 之间的元素个数

应用： 成绩表等排序表，带权重的消息，排行榜

Hyperloglog

什么是基数

集合中不重复的元素，可以接受误差

简介

Redis 2.8.9版本就更新了Hyperloglog 数据结构!
Redis Hyperloglog基数统计的算法

优点：占用的内存是固定的， 2^64不同的元素的基数,只需要用12KB内存!

网页的UV (网页浏览量 一个人访问一个网站多次,但是还是算作一个人 )

传统的方式：set 保存用户的id ,然后就可以统计set中的元素数量作为标准判断!

这个方式如果保存大量的用户id ,就会比较麻烦!我们的目的是为了计数,而不是保存用户id ;

Hyperloglog 有 0.81% 错误率，用作统计 UV 等 可以接受

指令

PFADD key [element...]	// 添加元素
PFCOUNT [key...]	// 统计不重复元素数量
PFMERGE	destkey [sourcekey...]	
// 将 [sourcekey...] 中的不重复元素合并为 destkey

允许容错的话，建议使用 hyperloglog

不允许容错，使用set等数据结构

Bitmaps

位存储

统计信息：登录/未登录，打卡/不打卡， 两个状态的都可以使用

指令

SETBIT key offset value	// 设置 offset 的 value  非0即1
GETBIT key offset	    // 获取 offset 的 value

事务

事务本质：一组命令的集合，事务中的所有命令都会被序列化，按照顺序执行

一次性，顺序性，排他性

Redis 单条命令保证原子性，但事务不保证原子性

Redis事务没有隔离级别的概念!

所有的命令在事务中,并没有直接被执行!只有发起执行命令的时候才会执行!

Redis事务

• 开启事务 ( multi )
• 命令入队 ( set )
• 执行事务 ( exec )

正常执行事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> mset k2 v2 k3 v3
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) "v2"

执行事务后，事务消失，需要重新开启事务

放弃事务

127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get k4
(nil)

编译型异常( 代码有错 ) ，事务中所有命令都不会被执行

127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> getset	# 语法错误
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.

运行时异常( RE )， 其他命令正常执行，错误命令抛异常

127.0.0.1:6379> set k1 "v1"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range
2) OK
3) "v2"

监控

Watch

• 悲观锁
  • 认为什么时候都会出问题，无论做什么都枷锁
• 乐观锁
  • 认为什么时候都不出问题，不上锁！更新数据时判断一下，是否被修改过。
  • 比较 version，更新数据时更新 version

监视测试

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> Decrby money 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

多线程修改时，使用 watch 可以当做 redis 乐观锁操作

# 线程1
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
# 此时执行线程2 修改

127.0.0.1:6379> exec
(nil)	# 值被修改，执行失败

# 线程2
127.0.0.1:6379> get money
"80"
127.0.0.1:6379> set money 1000
OK

如果修改失败，重新监控获取新的值即可

Jedis

Jedis 是 Redis 官方推荐的 java 连接开发工具，是 java 操作 Redis 的中间件。

public class TestPing {
    public static void main(String[] args) {
        Jedis jedis = new Jedis("127.0.0.1", 6379);
        // 所有命令和 Redis 一样
        String ping = jedis.ping();
        System.out.println(ping);
    }
}

常用API

Key

String

List

Hash

Set

和之前指令一样

集成 SpringBoot

在 SpringBoot 2.x 之后，Jedis 被替换为了 lettuce

jedis :采用的直连,多个线程操作的话,是不安全的,如果想要避免不安全的,使用jedis pool 连接池! BIO

lettuce :采用 netty ,实例可以再多个线程中进行共享,不存在线程不安全的情况! 可以减少线程数据，更像 NIO 模式

源码

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(RedisOperations.class)
@EnableConfigurationProperties(RedisProperties.class)
@Import({ LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class })
public class RedisAutoConfiguration {
    @Bean
    // 后续可以自定义一个 RedisTemplate，替换
    @ConditionalOnMissingBean(name = "redisTemplate")
    @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 默认的 Template 没有过多的设置，redis 对象都需要序列化
        // 两个泛型都是 Object ，后续使用需要强转 <String, Object>
        RedisTemplate<Object, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    // String是常用类型，单独有一个 Template
    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        return new StringRedisTemplate(redisConnectionFactory);
    }

}

整合

1. 导入依赖

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

2. 配置

   spring.redis.host=127.0.0.1
   spring.redis.port=6379
   # 不要用 redis 连接池，官方没有注入这些类使其生效
   

3. 测试

默认方式是以 JDK 方式序列化，使得在控制台看到中文乱码。

所有对象保存需要序列化

JSON方式序列化

User user = new User("zjz", 18);
String jsonUser = new ObjectMapper().writeValueAsString(user);

redisTemplate.opsForValue().set("user", user);

或者类直接实现 Serializable 接口

RedisTemplate 模板

@Configuration
public class RedisConfig {

    @Bean
    // 后续可以自定义一个 RedisTemplate，替换
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 默认的 Template 没有过多的设置，redis 对象都需要序列化
        // 两个泛型都是 Object ，后续使用需要强转 <String, Object>
        RedisTemplate<String, Object> template = new RedisTemplate<>();

        template.setConnectionFactory(redisConnectionFactory);

        Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);

        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
        template.setKeySerializer(stringRedisSerializer);

        template.setHashKeySerializer(stringRedisSerializer);

        template.setValueSerializer(jackson2JsonRedisSerializer);

        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();

        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }
}

接口一般使用 RedisUtils 封装

Redis.config 详解

大小写不敏感

可以包含其他文件

网络

bind 127.0.0.1	# IP
protected-mode yes	# 保护模式
port 6379		# 端口

通用

# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice	# 日志

# Specify the log file name. Also 'stdout' can be used to force
# Redis to log on the standard output.
logfile ""	# 日志文件

databases 16	# 默认数据库个数
always-show-logo yes	 # 是否显示 logo

快照

持久化，在规定的时间内,执行了多少次操作,则会持久化到文件 .rdb .aof

Redis 是内存数据库，断电即失，需要持久化

# 如果 900s 内 至少对 1 个 key 修改，就进行持久化操作
save 900 1
# 如果 300s 内 至少对 10 个 key 修改，就进行持久化操作
save 300 10
# 如果 60s 内 至少对 10000 个 key 修改，就进行持久化操作
save 60 10000
# 可以自己配置

stop-writes-on-bgsave-error yes	# 如果持久化出错，是否继续工作

rdbcompression yes	# 是否压缩 rbd 文件，会占用 cpu 资源
rdbchecksum yes		# 保存 rdb 文件时，是否进行检查校验

dir ./		# rdb 文件的保存目录

REPLICATION 主从复制时介绍

SECURITY

默认没有密码

# 设置密码
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass root	# 设置密码
OK
127.0.0.1:6379> ping
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth root	# 登录
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "root"

限制 CLIENTS

maxclients 10000	# 最多同时连10000个客户端
maxmemory <bytes>	# Redis 最大内存容量
maxmemory-policy noeviction	# 内存满后 Redis 的处理策略

------------------------------------------------------------

# 1、volatile-lru：只对设置了过期时间的key进行LRU算法进行删除
# 2、allkeys-lru ： 对所有key执行LRU算法进行删除
# 3、volatile-lfu：只对设置了过期时间的key进行LFU算法进行删除
# 4、allkeys-lfu：对所有key执行LFU算法进行删除
# 5、volatile-random：随机删除设置有过期时间的key
# 6、allkeys-random：随机删除
# 7、volatile-ttl ： 删除即将过期的
# 8、noeviction ： 永不过期，返回错误

APPEND ONLY MODE aof 配置

appendonly no	# 默认不开启 aof 模式，大部分情况下 rdb 模式够用
appendfilename "appendonly.aof"	  # 持久化文件名

# appendfsync always	# 每次写入都执行一次 sync	消耗
appendfsync everysec	# 每秒执行一次 sync，但是可能丢失这一秒的数据
# appendfsync no		# 不执行 sync，由操作系统自己同步数据，速度最快

RDB (Redis DataBase)

什么是 RDB

在主从复制中，rdb 一般用作备用

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

Redis会单独创建( fork ) - -个子进程来进行持久化,会先将数据写入到一一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失

默认持久化方式就是 RDB ， 不需要修改配置

生产环境中，有时候我们会将这个文件进行备份

rdb保存的文件是 dump.rdb 在配置文件 快照 中可以设置

触发机制

1. save 命令
2. flushall 命令
3. 退出 Redis 时

如何恢复

config get dir# 获取存储路径
1) "dir"
2) "D:\\environment\\redis-5.0.14"	# 在这个目录下的所有 dump.rdb 文件会在 redis 启动时自动加载

优缺点

优点

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高

缺点

1. 需要一定的时间间隔进程操作， 如果 redis 意外宕机了,这个最后一次修改数据就没有了
2. fork 进程的时候，会占用一定内存空间

AOF

将我们的所有命令都记录下来, history ,恢复的时候就把这个文件全部在执行一遍!

是什么

以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件, redis 启动之初会读取该文件重新构建数据,换言之, redis重启的话就根据日志文件的内容将写指令从前到后执行- -次以完成数据的恢复

Aof保存的是 appendonly.aof 文件

append

配置文件中手动开启 appendonly yes

如果 aof 文件错位，则无法启动 redis，可通过 redis-check-aof 工具修复

重写机制

aof 默认是文件无限追加

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

超过最大限制时就会新开一个进程，写入新的文件。

优点和缺点

优点:

1. 每一次修改都同步,文件的完整会更加好!
2. 每秒同步-次,可能会丢失一-秒的数据
3. 从不同步,效率最高的!

缺点:

1. 相对于数据文件来说， aof远远大于rdb ,修复的速度也比rdb慢!
2. Aof 运行效率也要比rdb慢,所以我们redis默认的配置就是rdb持久化!

扩展:

1. RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以Redis协议追加保存每次写的操作到文件末尾, Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
3. 只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化
4. 同时开启两种持久化方式
   • 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB
     文件保存的数据集要完整。
   • RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?作者建议不要,因为RDB更适合用于备份数据库( AOF在不断变化不好备份) , 快速重启,而且不会有AOF可能潜在的Bug ,留着作为-一个万- -的手段。
5. 性能建议
   • 因为RDB文件只用作后备用途,建议只在Slave.上持久化RDB文件,而且只要15分钟备份一 次就够了,只保留save 9001这条
     规则。
   • 如果Enable AOF , 好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来了持续的 IO 操作 ,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率, AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小.
     100%大小重写可以改到适当的数值。
   • 如果不Enable AOF , 仅靠Master-Slave Repllcation实现高可用性也可以,能省掉一大笔I0 ,也减少了rewrite时带来的系统性能波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据 ,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是这种架构。

Redis 消息订阅

Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。

Redis客户端可以订阅任意数量的频道。

127.0.0.1:6379> SUBSCRIBE zjz	# 订阅频道
Reading messages... (press Ctrl-C to quit)	# 自动监听读取消息
1) "subscribe"
2) "zjz"
3) (integer) 1
1) "message"
2) "zjz"
3) "hello, zjz"
1) "message"
2) "zjz"
3) "hello, redis

127.0.0.1:6379> PUBLISH zjz "hello, zjz"
(integer) 1
127.0.0.1:6379> PUBLISH zjz "hello, redis"
(integer) 1

原理

Redis是使用C实现的,通过分析Redis源码里的pubsubl.c文件，了解发布和订阅机制的底层实现,借此加深对Redis的理解。

Redis通过PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令实现发布和订阅功能。

通过SUBSCRIBE命令订阅某频道后, redis-server里维护了-一个字典,字典的键就是一个个channel , 而字典的值则是一-个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE命令的关键,就是将客户端添加到给定channel的订阅链表中。

通过PUBLISH命令向订阅者发送消息, redis-server 会使用给定的频道作为键,在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表,遍历这个链表,将消息发布给所有订阅者。

Pub/Sub从字面上理解就是发布( Publish )与订阅( Subscribe ) , 在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一-功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

应用场景

1. 实时消息系统
2. 聊天室
3. 订阅，关注系统

稍微复杂的场景，使用消息队列中间件做。

Redis 主从复制

概念

主从复制：是指将一台Redis服务器的数据 ,复制到其他的Redis服务器。前者称为主节点(master/leader) ,后者称为从节点(slave/follower)

数据的复制是单向的,只能由主节点到从节点. Master以写为主, Slave以读为主。

默认情况下，每台Redis服务器都是主节点。

且一个主节点可以有多个从节点(或没有从节点) ,但-一个从节点只能有一个主节点。

主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点) , 分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用基石（集群）：除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不能的,原因如下:

1. 从结构上,单个Redis服务器会发生单点故障,并且一 台服务器需要处理所有的请求负载,压力较大;
2. 从容量上,单个Redis服务器内存容量有限,就算一 台Redis服务器内存容量为256G ,也不能将所有内存用作Redis存储内存。一般来说 ,单台Redis最大使用内存不应该超过20G。

电商网站上的商品， 一般都是一次上传,无数次浏览的,说专业点也就是"多读少写"。

主从复制，读写分离，最低配，一主二从

启动命令

在 redis 目录下打开 cmd，shift + 右键 打开 shell

否则配置文件可能不生效

.\redis-server.exe redis.windows.conf	# 手动加载配置文件

.\redis-cli.exe -h 127.0.0.1 -p 6379	# 端口号

环境配置

只配置从库，不配置主库，因为默认为主机

127.0.0.1:6379> info replication	# 查看
# Replication
role:master		# 角色 主机
connected_slaves:0	# 从机 0个
master_replid:15d1a0ba1bff72d3d3dee5508fbdb8bd0333006b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

修改配置文件

1. 端口号
2. logfile
3. dump

配置从机

正常情况下应该在 配置文件 中配置

一般情况下只要配置从机就好了，

找一个当自己的主机即可

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379	# 认一个当主机
OK
127.0.0.1:6380> info replication

# Replication
role:slave	# 角色，从机
master_host:127.0.0.1	# 可以看到主机信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:70
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:660a9a0d54859ea86391a05ebf1d5dc4d098ca09
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:70

主机信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=350,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=350,lag=0
master_replid:660a9a0d54859ea86391a05ebf1d5dc4d098ca09
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:350
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:350

主从复制

细节

主机可以写,从机不能写只能读。主机中的所有信息和数据，都会自动被从机保存!

127.0.0.1:6380> set k1 1
(error) READONLY You can't write against a read only replica.

测试：主机断开连接,从机依旧连接到主机的,但是没有写操作,这个时候,主机如果回来了,从机依旧可以直接获取到主机写的

如果是使用命令行,来配置的主从,这个时候如果重启了,就会变回主机。只要变为从机,立马就会从主机中获取值。

复制原理

Slave启动成功连接到master后会发送一个sync命令

Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传送整个数据文件到slave ,并完成一次完全同步。

全量复制：而slave服务在接收到数据库文件数据后, 将其存盘并加载到内存中。

增量复制： Master继续将新的所有收集到的修改命令依次传给slave ,完成同步

但是只要是重新连接master , 一次完全同步( 全量复制)将被自动执行，所有数据一定可以在从机中获取到

链路

了解即可

上一个主机连接下一个从机

slave no one # 使自己变为主机

主机如果挂了，只能手动配置

哨兵模式

自动选取主机

概述

主从切换技术的方法是:当主服务器宕机后，需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供 了Sentinel (哨兵)架构来解决这个问题。

哨兵结点在后台监控多个进程，如果主机故障了，根据投票数自动选取新的主机

哨兵模式是一种特殊的模式 ,首先Redis提供了哨兵的命令,哨兵是一个独立的进程 ,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

这里的哨兵有两个作用：

• 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
• 当哨兵监测到master宕机,会自动将slave切换成master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

1、配置哨兵配置文件sentinel.conf

# sentinel monitor 被监控的名称 host port num	# num： 最少几个哨兵同意
sentine1 monitor myredis 127.0.0.1 6379 1

如果主机挂了，自动选取一个主机

如果此时原来的主机回来了，自动当现在主机的从机

优缺点

优点：

1. 哨兵集群,基于主从复制模式,所有的主从配置优点,它全有
2. 主从可以切换,故障可以转移，系统的可用性就会更好
3. 哨兵模式就是主从模式的升级，手动到自动,更加健壮!

缺点:

1. Redis不好啊在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦!
2. 实现哨兵模式的配置其实是很麻烦的,里面有很多选择

Redis缓存穿透和雪崩

不详细分析底层

Redis缓存的使用,极大的提升了应用程序的性能和效率,特别是数据查询方面。但同时,它也带来了- -些问题。 其中,最要害的问题,就是数据的一致性问题,从严格意义上讲,这个问题无解。如果对数据的一致性要求很高 ,那么就不能使用缓存。

另外的一些典型问题就是,缓存穿透、缓存雪崩和缓存击穿。目前,业界也都有比较流行的解决方案。

缓存穿透(查不到)

概念

缓存穿透的概念很简单,用户想要查询一-个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发现也没有,于是本次查询失败。当用户很多的时候,缓存都没有命中,于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透。

解决方案

布隆过滤器

布隆过滤器是一种数据结构,对所有可能查询的参数以 hash 形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;

缓存空对象

当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间 ,之后再访问这个数据将会从缓存中获取,保护了后端数据源;

存在问题

但是这种方法会存在两个问题:

1. 如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键;
2. 即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿(量太大，缓存过期)

概述

这里需要注意和缓存击穿的区别。

缓存击穿，是指一个key非常热点（比如热搜），在不停的扛着大并发，大并发集中对这一个点进行访问,当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库, 就像在一个屏障上凿开了一个洞。

当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面来看,没有设置过期时间,所以不会出现热点key过期后产生的问题。但是带来了内存消耗问题

加互斥锁

分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。

缓存雪崩

概念

缓存雪崩，是指在某-个时间段缓存集中过期失效，或 redis 宕机。

产生雪崩的原因之一,，比如马上就要到双十二零点，很快就会迎来一波抢购,这波商品时间比较集中的放入了缓
存,假设缓存一个小时。那么到了凌晨一点钟的时候 ，这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上，对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩, 一定是在某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。

服务降级：停掉一些服务，保证主要服务可用。

而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。

解决方案

高可用

这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之 后其他的还可以继续工作,实就是搭建的集群。(异地多活!)

服务降级

这个解决方案的思想是,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。

数据预热

数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问- -遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key ,设置不同的过期时间,让缓存失效的时间点尽量均匀。