Redis 是什么

Redis: REmote DIctionary Server(远程字典服务器)
完全开源免费，C语言编写遵守BSD协议，一个高性能的（key/value)分布式内存数据库。基于内存运行并支持持久化的NOSQL数据库被称为数据结构服务器。

与其他key-value缓存产品区别？

性能优秀，数据在内存中，读写速度非常快，支持并发- 10W QPS；
单进程单线程，是线程安全的，采用IO多路复用机制；
丰富的数据类型，支持字符串（strings）、散列（has- hes）、列表（lists）、集合（sets）、有序集合（so- rted sets）等；
支持数据持久化。可以将内存中数据保存在磁盘中，重- 启时加载；
主从复制，哨兵，高可用；
可以用作分布式锁；
可以作为消息中间件使用，支持发布订阅

五种数据类型

Redis如何管理

先来了解下Redis内部内存管理是如何描述这5种数据类型。

首先redis内部使用一个redisObject对象来表示所有的key和value，redisObject最主要的信息如上图所示：type表示一个value对象具体是何种数据类型;
encoding是不同数据类型在redis内部的存储方式。

比如：type=string表示value存储的是一个普通字符串，那么encoding可以是raw或者int。

5种数据类型

string是redis最基本的类型，可以理解成与memcached一模一样的类型，一个key对应一个value。 value不仅是string，也可以是数字。string类型是二进制安全的，意思是redis的string类型可以包含任何数据，比如jpg图片或者序列化的对象。string类型的值最大能存储512M。
Hash是一个键值（key-value）的集合。 redis的hash是一个string的key和value的映射表，Hash特别适合存储对象。常用命令：hget,hset,hgetall等。
list列表是简单的字符串列表，按照插入顺序排序。 可以添加一个元素到列表的头部（左边）或者尾部（右边）常用命令：lpush、rpush、lpop、rpop、lrange(获取列表片段)等。

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

数据结构：list就是链表，可以用来当消息队列用。redis提供了List的push和pop操作，还提供了操作某一段的api，可以直接查询或者删除某一段的元素。

实现方式：redis list的是实现是一个双向链表， 既可以支持反向查找和遍历，更方便操作，不过带来了额外的内存开销。
set是string类型的无序集合。 集合是通过hashtable实现的。set中的元素是没有顺序的，而且是没有重复的。

常用命令：sdd、spop、smembers、sunion等。

应用场景：redis set对外提供的功能和list一样是一个列表，特殊之处在于set是自动去重的，而且set提供了判断某个成员是否在一个set集合中。
zset和set一样是string类型元素的集合，且不允许重复的元素。 常用命令：zadd、zrange、zrem、zcard等。

使用场景：sorted set可以通过用户额外提供一个优先级（score）的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set结构。和set相比，sorted set关联了一个double类型权重的参数score，使得集合中的元素能够按照score进行有序排列，redis正是通过分数来为集合中的成员进行从小到大的排序。

实现方式：Redis sorted set的内部使用HashMap和跳跃表(skipList)来保证数据的存储和有序， HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

数据类型应用场景总结

Redis缓存

结合spring boot使用的。一般有两种方式，一种是直接通过RedisTemplate来使用，另一种是使用spring cache集成Redis（也就是注解的方式）

<dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.springframework.session</groupId><artifactId>spring-session-data-redis</artifactId></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><optional>true</optional></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency>
</dependencies>

Tips

spring-boot-starter-data-redis: 在spring boot 2.x以后底层不再使用Jedis，而是换成了Lettuce。
commons-pool2：用作redis连接池，如不引入启动会报错
spring-session-data-redis：spring session引入，用作共享session。

配置文件application.yml的配置：

server:port: 8082servlet:session:timeout: 30ms
spring:cache:type: redisredis:host: 127.0.0.1port: 6379password:# redis默认情况下有16个分片，这里配置具体使用的分片，默认为0database: 0lettuce:pool:# 连接池最大连接数(使用负数表示没有限制),默认8max-active: 100

RedisTemplate使用方式

默认情况下的模板只能支持RedisTemplate<String, String>，也就是只能存入字符串，所以自定义模板很有必要。

添加配置类RedisCacheConfig.java

@Configuration
@AutoConfigureAfter(RedisAutoConfiguration.class)
public class RedisCacheConfig {@Beanpublic RedisTemplate<String, Serializable> redisCacheTemplate(LettuceConnectionFactory connectionFactory) {RedisTemplate<String, Serializable> template = new RedisTemplate<>();template.setKeySerializer(new StringRedisSerializer());template.setValueSerializer(new GenericJackson2JsonRedisSerializer());template.setConnectionFactory(connectionFactory);return template;}
}

测试类

@RestController
@RequestMapping("/user")
public class UserController {public static Logger logger = LogManager.getLogger(UserController.class);@Autowiredprivate StringRedisTemplate stringRedisTemplate;@Autowiredprivate RedisTemplate<String, Serializable> redisCacheTemplate;@RequestMapping("/test")public void test() {redisCacheTemplate.opsForValue().set("userkey", new User(1, "张三", 25));User user = (User) redisCacheTemplate.opsForValue().get("userkey");logger.info("当前获取对象：{}", user.toString());}
}

使用spring cache集成redis

spring cache具备很好的灵活性，不仅能够使用SPEL(spring expression language) 来定义缓存的key和各种condition，还提供了开箱即用的缓存临时存储方案，也支持和主流的专业缓存如EhCache、Redis、Guava的集成。

定义接口UserService.java

public interface UserService {User save(User user);void delete(int id);User get(Integer id);
}

接口实现类UserServiceImpl.java

@Service
public class UserServiceImpl implements UserService{public static Logger logger = LogManager.getLogger(UserServiceImpl.class);private static Map<Integer, User> userMap = new HashMap<>();static {userMap.put(1, new User(1, "肖战", 25));userMap.put(2, new User(2, "王一博", 26));userMap.put(3, new User(3, "杨紫", 24));}@CachePut(value ="user", key = "#user.id")@Overridepublic User save(User user) {userMap.put(user.getId(), user);logger.info("进入save方法，当前存储对象：{}", user.toString());return user;}@CacheEvict(value="user", key = "#id")@Overridepublic void delete(int id) {userMap.remove(id);logger.info("进入delete方法，删除成功");}@Cacheable(value = "user", key = "#id")@Overridepublic User get(Integer id) {logger.info("进入get方法，当前获取对象：{}", userMap.get(id)==null?null:userMap.get(id).toString());return userMap.get(id);}
}

为了方便演示数据库的操作，这里直接定义了一个Map<Integer,User> userMap，这里的核心是三个注解 @Cachable、@CachePut和@CacheEvict

用缓存要注意，启动类要加上一个注解开启缓存

@SpringBootApplication(exclude=DataSourceAutoConfiguration.class)
@EnableCaching
public class Application {public static void main(String[] args) {SpringApplication.run(Application.class, args);}}

缓存注解

@Cacheable

根据方法的请求参数对其结果进行缓存

key：缓存的key，可以为空，如果指定要按照SPEL表达式编写，如果不指定，则按照方法的所有参数进行组合。
value：缓存的名称，必须指定至少一个（如 @Cacheable (value='user')或者@Cacheable(value={'user1','user2'})）
condition：缓存的条件，可以为空，使用SPEL编写，返回true或者false，只有为true才进行缓存。

@CachePut

根据方法的请求参数对其结果进行缓存，和@Cacheable不同的是，它每次都会触发真实方法的调用。参数描述见上。

@CacheEvict

根据条件对缓存进行清空

key：同上
value：同上
condition：同上
allEntries：是否清空所有缓存内容，缺省为false，如果指定为true，则方法调用后将立即清空所有缓存
beforeInvocation：是否在方法执行前就清空，缺省为false，如果指定为true，则在方法还没有执行的时候就清空缓存。缺省情况下，如果方法执行抛出异常，则不会清空缓存。

缓存问题

缓存和数据库数据一致性问题

分布式环境下非常容易出现缓存和数据库间数据一致性问题，针对这一点，如果项目对缓存的要求是强一致性的，那么就不要使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括合适的缓存更新策略，更新数据库后及时更新缓存、缓存失败时增加重试机制。

缓存雪崩？

目前电商首页以及热点数据都会去做缓存，一般缓存都是定时任务去刷新，或者查不到之后去更新缓存的，定时任务刷新就有一个问题。

举个栗子：如果首页所有Key的失效时间都是12小时，中午12点刷新的，我零点有个大促活动大量用户涌入，假设每秒6000个请求，本来缓存可以抗住每秒5000个请求，但是缓存中所有Key都失效了。此时6000个/秒的请求全部落在了数据库上，数据库必然扛不住，真实情况可能DBA都没反应过来直接挂了，此时，如果没什么特别的方案来处理，DBA很着急，重启数据库，但是数据库立马又被新流量给打死了。这就是我理解的缓存雪崩。

同一时间大面积失效，瞬间Redis跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的，你想想如果挂的是一个用户服务的库，那其他依赖他的库所有接口几乎都会报错，如果没做熔断等策略基本上就是瞬间挂一片的节奏，你怎么重启用户都会把你打挂，等你重启好的时候，用户早睡觉去了，临睡之前，骂骂咧咧“什么垃圾产品”。

怎么应对？

处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会再同一时间大面积失效。

setRedis（key, value, time+Math.random()*10000）;
如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效。或者设置热点数据永不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就好了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

缓存穿透和击穿？

先说下缓存穿透吧，缓存穿透是指缓存和数据库中都没有的数据，而用户（黑客）不断发起请求，举个栗子：我们数据库的id都是从1自增的，如果发起id=-1的数据或者id特别大不存在的数据，这样的不断攻击导致数据库压力很大，严重会击垮数据库。

至于缓存击穿嘛，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发直接落到了数据库上，就在这个Key的点上击穿了缓存。

怎么解决？

缓存穿透我会在接口层增加校验，比如用户鉴权，参数做校验，不合法的校验直接return，比如id做基础校验，id<=0直接拦截。
我记得Redis里还有一个高级用法布隆过滤器（Bloom Filter）这个也能很好的预防缓存穿透的发生，他的原理也很简单，就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查DB刷新KV再return。缓存击穿的话，设置热点数据永不过期，或者加上互斥锁就搞定了。作为暖男，代码给你准备好了，拿走不谢。

public static String getData(String key) throws InterruptedException {//从Redis查询数据String result = getDataByKV(key);//参数校验if (StringUtils.isBlank(result)) {try {//获得锁if (reenLock.tryLock()) {//去数据库查询result = getDataByDB(key);//校验if (StringUtils.isNotBlank(result)) {//插进缓存setDataToKV(key, result);}} else {//睡一会再拿Thread.sleep(100L);result = getData(key);}} finally {//释放锁reenLock.unlock();}}return result;
}

Redis为何这么快

redis作为缓存大家都在用，那redis一定很快咯？

当然了，官方提供的数据可以达到100000+的QPS（每秒内的查询次数），这个数据不比Memcached差！

redis这么快，它的“多线程模型”你了解吗？（露出邪魅一笑）

这是想问Redis这么快，为什么还是单线程的吧。Redis确实是单进程单线程的模型，因为Redis完全是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章的采用单线程的方案了（毕竟采用多线程会有很多麻烦）。

Redis是单线程的，为什么还能这么快吗？

Redis完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度是O(1)。
数据结构简单，对数据操作也简单。
采用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的CPU切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。
使用多路复用IO模型，非阻塞IO。

Redis和Memcached的区别

存储方式上：memcache会把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。redis有部分数据存在硬盘上，这样能保证数据的持久性。
数据支持类型上：memcache对数据类型的支持简单，只支持简单的key-value，，而redis支持五种数据类型。
性能对比，redis只使用单核而memcached使用多核，所以平均每一个核上Rdis在存储小数据时比Memcached性能更高。100k以上的数据中，memcached性能更高。
集群模式:memcached没有原生的集群模式，需要依靠客户端来实现向集群中分片写入数据；但是redis目前是原生支持cluster模式的，redis官方就是支持redis cluster集群模式的，比memcached来说要更好。
value的大小：redis可以达到1GB，而memcache只有1MB

Redis单线程模型

文件事件处理器

redis基于reactor模式开发了网络事件处理器，这个处理器叫做文件事件处理器，file event handler。这个文件事件处理器，是单线程的，redis才叫做单线程的模型，采用IO多路复用机制同时监听多个socket，根据socket上的事件来选择对应的事件处理器来处理这个事件。

Reactor模式首先是事件驱动的，有一个或多个并发输入源，有一个Service Handler，有多个Request Handlers；这个Service Handler会同步的将输入的请求（Event）多路复用的分发给相应的Request Handler。

如果被监听的socket准备好执行accept、read、write、close等操作的时候，跟操作对应的文件事件就会产生，这个时候文件事件处理器就会调用之前关联好的事件处理器来处理这个事件。

文件事件处理器是单线程模式运行的，但是通过IO多路复用机制监听多个socket，可以实现高性能的网络通信模型，又可以跟内部其他单线程的模块进行对接，保证了redis内部的线程模型的简单性。

文件事件处理器的结构包含4个部分：多个socket，IO多路复用程序，文件事件分派器，事件处理器（命令请求处理器、命令回复处理器、连接应答处理器，等等）。

多个socket可能并发的产生不同的操作，每个操作对应不同的文件事件，但是IO多路复用程序会监听多个socket，但是会将socket放入一个队列中排队，每次从队列中取出一个socket给事件分派器，事件分派器把socket给对应的事件处理器。

然后一个socket的事件处理完之后，IO多路复用程序才会将队列中的下一个socket给事件分派器。文件事件分派器会根据每个socket当前产生的事件，来选择对应的事件处理器来处理。

文件事件

当socket变得可读时（比如客户端对redis执行write操作，或者close操作），或者有新的可以应答的socket出现时（客户端对redis执行connect操作），socket就会产生一个AE_READABLE事件。

当socket变得可写的时候（客户端对redis执行read操作），socket会产生一个AE_WRITABLE事件。

IO多路复用程序可以同时监听 AE_REABLE和AE_WRITABLE 两种事件，要是一个socket同时产生AE_REABLE和AE_WRITABLE 两种事件，那么文件事件分派器优先处理AE_REABLE事件，然后才是AE_WRITABLE事件。

文件事件处理器

如果是客户端要连接redis，那么会为socket关联连接应答处理器
如果是客户端要写数据到redis，那么会为socket关联命令请求处理器
如果是客户端要从redis读数据，那么会为socket关联命令回复处理器

客户端与redis通信的一次流程

在redis启动初始化的时候，redis会将连接应答处理器跟AE_READABLE事件关联起来，接着如果一个客户端跟redis发起连接，此时会产生一个AE_READABLE事件，然后由连接应答处理器来处理跟客户端建立连接，创建客户端对应的socket，同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来。

当客户端向redis发起请求的时候（不管是读请求还是写请求，都一样），首先就会在socket产生一个AE_READABLE事件，然后由对应的命令请求处理器来处理。这个命令请求处理器就会从socket中读取请求相关数据，然后进行执行和处理。

接着redis这边准备好了给客户端的响应数据之后，就会将socket的AE_WRITABLE事件跟命令回复处理器关联起来，当客户端这边准备好读取响应数据时，就会在socket上产生一个AE_WRITABLE事件，会由对应的命令回复处理器来处理，就是将准备好的响应数据写入socket，供客户端来读取。

命令回复处理器写完之后，就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系。

过期策略

定期删除+惰性删除

定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。

假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。

但是问题是，定期删除可能会导致很多过期key到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。这就是说，在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。

并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下

通过上述两种手段结合起来，保证过期的key一定会被干掉。

淘汰策略

实际上，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了，咋整？

答案是：走内存淘汰机制

补充一下：
Redis4.0加入了LFU(least frequency use)淘汰策略，包括volatile-lfu和allkeys-lfu，通过统计访问频率，将访问频率最少，即最不经常使用的KV淘汰。

volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊
noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了

手写lru算法

public class LRUCache<K, V> extends LinkedHashMap<K, V> {private final int CACHE_SIZE;// 这里就是传递进来最多能缓存多少数据public LRUCache(int cacheSize) {// 这块就是设置一个hashmap的初始大小// 同时最后一个true指的是让linkedhashmap按照访问顺序来进行排序// 最近访问的放在头，最老访问的就在尾super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true); CACHE_SIZE = cacheSize;}@Overrideprotected boolean removeEldestEntry(Map.Entry eldest) {// 这个意思就是说当map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据return size() > CACHE_SIZE;}}

持久化

redis的持久化机制？

redis为了保证效率，数据缓存在了内存中，但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中，以保证数据的持久化。Redis的持久化策略有两种：

RDB：快照形式是直接把内存中的数据保存到一个dump的文件中，定时保存，保存策略。
AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。Redis默认是快照RDB的持久化方式。

当Redis重启的时候，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存。

RDB是怎么工作的？

默认Redis是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件dump.rdb。

工作原理

当Redis需要做持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处是可以copy-on-write。

RDB的优

这种文件非常适合用于备份：比如，你可以在最近的24小时内，每小时备份一次，并且在每个月的每一天也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB非常适合灾难恢复。RDB的缺点是：如果你需要尽量避免在服务器故障时丢失数据，那么RDB不合适你。

AOF是怎么工作的？

使用AOF做持久化，每一个写命令都通过write函数追加到appendonly.aof中，配置方式如下：

appendfsync yes
appendfsync always
#每次有数据修改发生时都会写入AOF文件。
#每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync everysec

工作原理

AOF可以做到全程持久化，只需要在配置中开启 appendonly yes。这样redis每执行一个修改数据的命令，都会把它添加到AOF文件中，当redis重启时，将会读取AOF文件进行重放，恢复到redis关闭前的最后时刻。

使用AOF的优点

让redis变得非常耐久。可以设置不同的fsync策略，aof的默认策略是每秒钟fsync一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。缺点是对于相同的数据集来说，AOF的文件体积通常要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。

该用哪一个呢？

如果你非常关心你的数据，但仍然可以承受数分钟内的数据丢失，那么可以额只使用RDB持久。

AOF将Redis执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能，不知道你是否可以接受。

数据库备份和灾难恢复：定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度快。当然了，redis支持同时开启RDB和AOF，系统重启后，redis会优先使用AOF来恢复数据，这样丢失的数据会最少。

主从复制

redis单节点存在单点故障问题，为了解决单点问题，一般都需要对redis配置从节点，然后使用哨兵来监听主节点的存活状态，如果主节点挂掉，从节点能继续提供缓存功能。

主从配置结合哨兵模式能解决单点故障问题，提高redis可用性。从节点仅提供读操作，主节点提供写操作。对于读多写少的状况，可给主节点配置多个从节点，从而提高响应效率。

redis replication核心机制

redis 采用异步方式 复制数据到slave节点，不过redis 2.8开始，slave node会周期性的确认自己每次复制的数据量。
一个master node是可以配置多个slave node的。
slave node也可以连接其他的slave node。
slave node做复制的时候，是不会block master node的正常工作的。
slave node在做复制的时候，也不会对自己的查询操作有影响，它会用旧的数据集来提供服务；但是，复制完成的时候，需要删除旧的数据集，加载新的数据集，这个时候就会暂停对外服务了。
slave node主要用来横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。

master持久化对主从架构的意义

如果采用了主从架构，那么建议必须开启master node持久化!!

不建议使用slave node作为master node的数据热备，因为那样的话，如果关掉master的持久化，可能在master宕机重启的时候数据是空的，然后经过复制，slave节点也丢失了。

master：RDB和AOF都关闭了，数据都存在内存中

master宕机，重启，是没有本地数据可以恢复的，然后就会认为自己的IDE数据是空的，然后将空的数据集同步到slave上去，所有slave的数据集全部清空。

造成100%数据丢失。

即使采用了高可用机制，slave node自动接管master node，但是也可能sentinal还没有检测到master failure，master node自动重启了，还是可能会造成slave node数据清空。

复制的过程

关于复制过程，是这样的：

从节点启动，执行slaveof [masterIP] [masterPort] (redis.cnf里边的slaveof配置的)，保存主节点信息
从节点中的定时任务 (每秒检查是否有新的master node要来连接和复制) 发现主节点信息，建立和主节点的socket连接
从节点发送Ping信号，主节点返回Pong，两边能互相通信
口令认证，如果master设置了requirepass，那么slave node必须发送masterauth的口令过去认证
连接建立后，主节点第一次会进行全量复制(将所有数据发送给从节点)
主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

数据同步的过程

redis2.8之前使用sync [runId] [offset] 同步命令，redis2.8之后使用psync [runId] [offset] 命令。

两者不同在于，sync命令仅支持全量复制过程，psync支持全量和部分复制。介绍同步之前，先介绍几个概念：

runId：每个redis节点启动都会生成唯一的uuid，每次redis重启后，runId都会发生变化。info server 可以看到master run id。如果只根据host+ip定位master node是不靠谱的。若发现slave node发送的同步请求中runId 不同，则触发全量复制，同步给slave node。如果需要不更改run id重启redis，可以使用redis-cli debug reload命令。
offset：主节点和从节点都各自维护自己的主从复制偏移量offset，当主节点有写入命令时，offset=offset+命令的字节长度。从节点在收到主节点发送的命令后，也会增加自己的offset，并把自己的offset发送给主节点。这样，主节点同时保存自己的offset和从节点的offset，通过对比offset来判断主从节点数据是否一致。
repl_backlog_size：保存在主节点上的一个固定长度的先进先出队列，默认大小是1MB。master node给slave node复制数据时，也会将数据在backlog中同步写一份。

psync的执行流程：

从节点发送psync[runId][offset]命令，主节点有三种响应：

FULLRESYNC：第一次连接，进行全量复制
CONTINUE：之后的连接，进行部分复制
ERR：不支持psync命令，进行全量复制

从节点第一次连接到主节点时，主节点会发送FULLRESYNC 进行全量复制，之后的每次复制都进行部分复制。

主节点响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。

全量复制和部分复制

全量复制的流程

从节点发送psync ? -1命令（因为第一次发送，不知道主节点的runId，所以为?，因为是第一次复制，所以offset=-1）。
主节点发现从节点是第一次复制，返回FULLRESYNC {runId} {offset}，runId是主节点的runId，offset是主节点目前的offset。
从节点接收主节点信息后，保存到info中。
主节点在发送FULLRESYNC后，启动bgsave命令，生成RDB文件（数据持久化）。
主节点发送RDB文件给从节点，如果rdb复制事件超过60s(repl-timeout)，那么slave node就会认为复制失败，可以适当调大这个参数。
主节点在生成rdb时，会将所有新的写命令缓存在内存中，在从节点保存了rdb之后，再将新的写命令复制给从节点。
client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败。
从节点收到rdb之后，清空自己的旧数据，然后重新加载RDB文件到内存中，同时基于旧的数据版本对外提供服务。
如果从节点开启了AOF，从节点会异步重写AOF文件。

如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗在1分半到2分钟。

部分复制(增量复制)

部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync [runId] [offset] 命令实现。当从节点正在复制主节点时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，主节点的复制积压缓冲区（backlog）将这部分数据直接发送给从节点，这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据。
主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内的复制积压缓冲区（backlog）依然可以保存最近一段时间的写命令数据。
当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当做psync参数发送给主节点，要求进行部分复制。
主节点接收到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数offset在复制积压缓冲区（backlog）中查找，如果offset之后的数据存在，则对从节点发送+CONTINUE命令，表示可以进行部分复制。因为缓冲区大小固定，若发生缓冲溢出，则进行全量复制。
主节点根据偏移量把复制积压缓冲区（backlog）里的数据发送给从节点，保证主从复制进入正常状态。

心跳机制

主从节点互相都会发送heartbeat信息

master默认每隔10秒发送一次heartbeat，slave node每隔1秒发送一次heartbeat。

主从复制断点续传

从redis2.8开始，支持主从复制断点续传，如果主从复制过程中，网络连接断了，那么可以接着上次复制的地方，继续复制下去，而不是重新开始。

master node会在内存中创建一个backlog，master和slave都会保存一个replicate offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络链接断掉了，slave会让master 从上次的replicat offset开始继续复制，如果没有找到对应的offset，那么就会执行一次resynchronization。

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会再自己本地落地磁盘

repl-diskless-sync
# 等待一定时间在开始复制，因为要等更多的slave重新连接过来
repl-diskless-sync-delay

过期Key

slave 不存在过期key，智慧等待master过期key。如果master过期或者LRU淘汰了一个key，那么会模拟一个del命令发送给slave。

主从复制会存在的问题

一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。
原生复制的弊端在早期的版本中也会比较突出，比如：redis复制中断后，从节点会发起psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

比较主流的解决方案？

哨兵。

哨兵

如图，是Redis Sentinel（哨兵）的架构图。Redis Sentinel（哨兵）主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。Redis Sentinel最小配置是一主一从。

Redis的Sentinel系统可以用来管理多个Redis服务器，该系统可以执行以下四个任务：

监控：不断检查主服务器和从服务器是否正常运行。
通知：当被监控的某个redis服务器出现问题，Sentinel通过API脚本向管理员或者其他应用程序发出通知。
自动故障转移：当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
配置提供者：在Redis Sentinel模式下，客户端应用在初始化时连接的是Sentinel节点集合，从中获取主节点的信息。

哨兵的工作原理

每个Sentinel节点都需要定期执行以下任务：每个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其他的Sentinel实例发送一个PING命令。（如图）

如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。（如图）

如果一个主服务器被标记为主观下线，那么正在监视这个服务器的所有Sentinel节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。

如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。

一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有主服务器和从服务器发送INFO命令，当一个主服务器被标记为客观下线时，Sentinel向下线主服务器的所有从服务器发送INFO命令的频率，会从10秒一次改为每秒一次。

Sentinel和其他Sentinel协商客观下线的主节点的状态，如果处于SDOWN状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制。

当没有足够数量的Sentinel同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除

生产环境中redis是怎么部署的

机器什么配置

32G内存 + 8核CPU + 1T磁盘。分配给redis是10g内存。(生产环境，redis内存尽量不超过10g)

redis cluster

10台机器，5台机器部署了redis主实例，另外5台机器部署了redis的从实例，每个主实例挂了一个从实例，5个节点对外提供写服务，每个节点的读写高峰QPS可能达到每秒5万，5台机器最多是每秒25万读写请求。

高峰请求 3500请求/s.

因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis从实例会自动变成主实例继续提供读写服务。

内存中写的是什么数据？每条数据大小是多少？

商品数据，每条数据10kb.100条是1mb，10万条数据是1g。常驻内存是200万条数据，占用内存是20g，仅仅不到中内存的50%。

redis基础和原理全覆盖相关推荐

Redis基础及原理详解
Redis基础及原理详解前言:以下是最近学习redis的一些笔记总结,文中如有不当的地方欢迎批评指正,重在记录与学习,笔芯~~ Nosql概述演进历史单机mysql Memcached(缓存)+ ...
JAVA基础知识学习全覆盖
文章目录一.JAVA基础知识 1.一些基本概念 1.Stringbuffer 2.局部变量成员变量 3.反射机制 4.protect 5.pow(x,y) 6.final ,finally,fina ...
CTF Misc(2)内存取证基础以及原理，覆盖了大部分题型
前言内存取证在ctf比赛中也是常见的题目,内存取证是指在计算机系统的内存中进行取证分析,以获取有关计算机系统当前状态的信息.内存取证通常用于分析计算机系统上运行的进程.网络连接.文件.注册表等信息, ...
通信网络基础实验报告_建设亚太信息枢纽港、实现5G网络全覆盖！临港新片区通信基础设施规划发布...
新民晚报讯 (驻临港记者杨欢)<临港新片区通信基础设施专项规划(2020-2025)>(以下简称<规划>)今日发布.根据<规划>,2020-2022年,临港新片区 ...
Redis 基础知识点总结
1. NoSQL 数据库简介 NoSQL 是为了解决性能问题产生的一种技术,Redis 就是一个典型的NoSQL 的数据库. 1.1 技术发展技术分类: 解决功能特性的问题:Java.Jsp.Tom ...
Redis基础用法、高级特性与性能调优以及缓存穿透等分析
目录一.Redis介绍二.Redis数据结构及常用的命令三.Redis持久化策略选择四.内存管理与数据淘汰机制五.Redis过期策略及实现原理 1 说明 2 设置过期时间 3 三种过期 ...
大型电商架构亿级流量电商详情页系统实战--redis基础票
亿级流量电商详情页系统实战-缓存架构+高可用服务架构+微服务架构 01_高并发高可用复杂系统中的缓存架构有哪些东西 (1)如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据 ...
mysql主从复制、redis基础、持久化和主从复制
一.mysql(mariadb)基础 1.基础命令(centos7操作系统下) 1.启动mysql systemctl start mariadb 2.linux客户端连接自己 mysql -uroo ...
Redis 基础、高级特性与性能调优 | 高薪必备
来源:http://c7.gg/fxqAK 本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍.之后概览Redis提供的高级能力,并在部署.维护 ...

redis基础和原理全覆盖

Redis 是什么

与其他key-value缓存产品区别？

五种数据类型

Redis如何管理

5种数据类型

数据类型应用场景总结

Redis缓存

Tips

RedisTemplate使用方式

使用spring cache集成redis

缓存注解

@Cacheable

@CachePut

@CacheEvict

缓存问题

缓存和数据库数据一致性问题

缓存雪崩？

怎么应对？

缓存穿透和击穿？

怎么解决？

Redis为何这么快

redis作为缓存大家都在用，那redis一定很快咯？

redis这么快，它的“多线程模型”你了解吗？（露出邪魅一笑）

Redis是单线程的，为什么还能这么快吗？

Redis和Memcached的区别

Redis单线程模型

文件事件处理器

文件事件

文件事件处理器

客户端与redis通信的一次流程

过期策略

淘汰策略

手写lru算法

持久化

redis的持久化机制？

RDB是怎么工作的？

工作原理

RDB的优

AOF是怎么工作的？

工作原理

使用AOF的优点

该用哪一个呢？

主从复制

redis replication核心机制

master持久化对主从架构的意义

复制的过程

数据同步的过程

psync的执行流程：

全量复制和部分复制

全量复制的流程

部分复制(增量复制)

心跳机制

主从复制断点续传

无磁盘化复制

过期Key

主从复制会存在的问题

比较主流的解决方案？

哨兵

哨兵的工作原理

生产环境中redis是怎么部署的

机器什么配置

redis cluster

内存中写的是什么数据？每条数据大小是多少？

redis基础和原理全覆盖相关推荐

最新文章

热门文章