一、单节点问题

二、持久化

持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。 在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。 当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

• RDB
• AOF

redis默认采用的是RDB的方式。

三、RDB 持久化

1、概念

RDB全称Redis Database Backup file(Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，回复数据，快照文件成为RDB文件，模式保存在当前运行目录。

在默认配置中，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。
可以配置持久化策略：save N M，让redis在“N秒内至少有M个改动”才会触发一次rdb持久化操作。
例如redis的默认策略有：
例如：

# 3600秒内至少有一个改动
save 3600 1
# 300秒内至少有10个改动
save 300 100
# 秒内至少有10000个改动
save 60 10000

还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，
每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

2、save 命令

Redis 处理命令的方式是以单线程形式来进行的，客户端的请求都会放入一个队列里。当执行 save 命令时，如果执行时间很长的话，后面的请求就会被阻塞，客户端发送的所有命令都会被拒绝。

3、bgsave 命令

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并是写入到RDB文件。

bgsave的基本流程：

• fork主进程得到一个子进程，共享内存空间
• 子进程读取内存数据并写入新的RDB文件
• 用新RDB文件替换旧的RDB文件

4、bgsave写时复制的（COW）机制

Redis借助了linux系统的写时复制（Copy-On-Write）技术，在生成快照的同时，仍然可以接收命令处理数据。简单来说，bgsave线程是由主线程fork生成的子线程，可以共享主线程所有的内存数据。bgsave线程运行后，开始读取主线程的内存数据，也就是redis的内存数据，将内存数据写入到dump.rdb文件中。此时，如果主线程处理的命令都是读操作，则bgsave线程不受影响。如果主线程处理了写操作，则会对该命令操作的数据复制一份，生成副本，bgsave线程会把这个副本写入到dump.rdb文件中，而在这个过程中，主线程仍可执行命令。

• 当主进程执行读操作时，访问共享内存
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作

5、RDB什么时间执行

• 默认是服务停止时执行
• 根据配置的save N M执行

6、RDB缺点

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程、压缩、写出RDB文件都比较耗时

四、 AOF 持久化

1、概念

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
例如下入，set num 123 先保存到redis，同时写入日志文件。重启redis把日志重新执行一遍即可。

2、开启方式

AOF默认是关闭的，需要修改redis.conf配置文件来开启。

# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
dir ./
# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配置。

3、记录频率

支持以下三种配置方式，性能越来越高，安全性越来越低

# 表示没执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓存区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

4、bgrewriteaof 重写命令

因为是记录命令，AOF文件比RDB文件大的多。而且AOF会记录对同一个key多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。
它是一个异步命令，后台运行的。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

五、RDB和AOF对比优缺点

前言：

金九银十刚刚过去了，不知道很多小伙伴都拿到自己心仪的offer没有，我这边也收到了一个粉丝投来的消息，说看到阿里的面试真题之后人都是懵的，发现自己一窍不通，下面给大家分享我这个粉丝的经历，以及我在这方面学习的经验。

阿里微服务面试真题

1.单片，SOA 和微服务架构有什么区别？

单片 SOA 和微服务之间的比较 – 微服务访谈问题

单片架构类似于大容器，其中应用程序的所有软件组件组装在一起并紧密封装。

一个面向服务的架构是一种相互通信服务的集合。通信可以涉及简单的数据传递，也可以涉及两个或多个协调某些活动的服务。

微服务架构是一种架构风格，它将应用程序构建为以业务域为模型的小型自治服务集合。

2.在使用微服务架构时，您面临哪些挑战？

开发一些较小的微服务听起来很容易，但开发它们时经常遇到的挑战如下。

• 自动化组件：难以自动化，因为有许多较小的组件。因此，对于每个组件，我们必须遵循 Build，Deploy 和 Monitor 的各个阶段。
• 易感性：将大量组件维护在一起变得难以部署，维护，监控和识别问题。它需要在所有组件周围具有很好的感知能力。
• 配置管理：有时在各种环境中维护组件的配置变得困难。
• 调试：很难找到错误的每一项服务。维护集中式日志记录和仪表板以调试问题至关重要。

3.SOA 和微服务架构之间的主要区别是什么？

4.什么是领域驱动设计？

5.为什么需要域驱动设计（DDD）？

6.什么是 REST / RESTful 以及它的用途是什么？

7.什么是 Spring 引导的执行器？

8.在 Spring MVC 应用程序中使用 WebMvcTest 注释有什么用处？

微服务面试学习路线

注意，注意，上面的学习路线都是自己总计的，需要的朋友关注+转发+私信【架构资料】获取思维导图以及面试答案

阿里Redis面试真题：

1.Redis 与其他 key-value 存储有什么不同？

Redis 有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis 的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。Redis 运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样 Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

2.Memcache 与 Redis 的区别都有哪些？

1、存储方式 Memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。 Redis 有部份存在硬盘上，这样能保证数据的持久性。

2、数据支持类型 Memcache 对数据类型支持相对简单。 Redis 有复杂的数据类型。

3、使用底层模型不同 它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。 Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

3.Redis持久化机制

4.缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题

5.热点数据和冷数据是什么

6.redis的数据类型，以及每种数据类型的使用场景

7.Redis 常见性能问题和解决方案？

8.为什么Redis的操作是原子性的，怎么保证原子性的？

Redis面试学习路线

注意，注意，上面的学习路线都是自己总计的，需要的朋友关注+转发+私信【架构资料】获取思维导图以及面试答案

阿里JVM面试真题：

1.Java 中 WeakReference 与 SoftReference 的区别？

虽然 WeakReference 与 SoftReference 都有利于提高 GC 和 内存的效率，但是 WeakReference ，一旦失去最后一个强引用，就会被 GC回收，而软引用虽然不能阻止被回收，但是可以延迟到 JVM 内存不足的时候。

2.JVM 选项 -XX:+UseCompressedOops 有什么作用？为什么要使用

当你将你的应用从 32 位的 JVM 迁移到 64 位的 JVM 时，由于对象的指针从32 位增加到了 64 位，因此堆内存会突然增加，差不多要翻倍。

这也会对 CPU缓存（容量比内存小很多）的数据产生不利的影响。因为，迁移到 64 位的 JVM主要动机在于可以指定最大堆大小，通过压缩OOP 可以节省一定的内存。通过-XX:+UseCompressedOops 选项，JVM 会使用 32 位的 OOP，而不是 64 位的 OOP。

3.怎样通过 Java 程序来判断 JVM 是 32 位 还是 64位？

4.32 位 JVM 和 64 位 JVM 的最大堆内存分别是多数？

5.JRE、JDK、JVM 及 JIT 之间有什么不同？

6.怎么获取 Java 程序使用的内存？堆使用的百分比？

7.描述一下 JVM 加载 class 文件的原理机制

8.GC 是什么？为什么要有 GC？

JVM面试学习路线

注意，注意，上面的学习路线都是自己总计的，需要的朋友关注+转发+私信【架构资料】获取思维导图以及面试答案

总结：

金九银十过去了也不要气馁，还有新的金三银四，主要是要总计自己在面试中不够的点，多增加自己实战项目的经验，然后也可以多刷刷面试题，以免面试的时候不知道说什么，上面的面试真题就没有把所有的答案都总结给大家了，需要答案以及上面高清思维导图的朋友，可以关注小编+转发文章+私信【架构资料】获取，最后祝大家都能拿到自己心仪的offer。

一、集群架构

1、集群部署图

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。主节点负责写入，从节点只能读

2、节点分配

本次搭建主从同步集群使用了三台Centos系统服务器，共包含三个节点，一个主节点，两个从节点。

二、准备实例节点和配置

1、修改三台redis.conf文件，将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态

# 开启RDB,注释下面语句
# save ""
# 3600秒内至少有一个改动
save 3600 1
# 300秒内至少有10个改动
save 300 100
# 秒内至少有10000个改动
save 60 10000
...
...
# 关闭AOF
appendonly no

2、修改持久化文件存储位置

如果是在单台机器安装三个redis，需要修改各自端口，各自持久化文件存储位置

# 持久化文件默认存储在redis安装目录下
dir .

3、修改每个实例的声明IP

虚拟机本身有很多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息，可以加在第一行格式如下：

replica-announce-ip 192.168.0.101

可以通过命令sed来加在第一行

sed -i '1a replica-announce-ip 192.168.0.101' redis.conf

4、启动

分别在三台机器执行如下，启动三个实例

redis-server redis.conf

三、开启主从关系

1、方法一：replicaof

我们分别进入192.168.0.102和192.168.0.103两个机器

# 连接
redis-cli -p 6379
# 执行replicaof
replicaof 192.168.0.101 6379

2、方法二：slaveof

我们分别进入192.168.0.102和192.168.0.103两个机器

# 连接
redis-cli -p 6379
# 执行slaveof
slaveof 192.168.0.101 6379

3、查看集群状态

进入master192.168.0.101

# 连接
redis-cli -p 6379
# 执行
INFO replication

看到类似如下信息：

四、主从同步原理

1、数据同步原理-全量同步

概念

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
主从同步第一次同步是全量同步
显示把快照RDB文件发送一次，因为bgsave是异步，所以过程中还会把其他的写入记录融baklog，后面同步baklog。

全量同步流程

• slave节点连接到master节点，并发送SYNC（请求增量同步）命令
• master节点判断replid，发现不一致，拒绝增量同步
• master将完整内存数据生成RDB快照，发送RDB到slave从节点
• slave清空本地数据，加载master发来的RDB
• master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
• slave执行接收到的命令，保持与master之间的同步

2、数据同步原理-增量同步

概念

主从第一次同步是全量同步，但如果slave重启后同步，则执行增量同步。而且repl_baklog是环形缓存，有大小上限，写满后会覆盖最早的数据。如果slave断开时间太久，导致数据被覆盖，则无法实现增量同步，只能再次全量同步。

五、优化Redis主从集群

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO
• Redis单节点上的的内存占用不要太大，减少RDB导致的过多磁盘IO
• 适当提高repl_backlog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
• 限制一个master节点上的slave的数量，如果实在太多slave，则采用主-从-从链式结构，减少master压力