这里写目录标题
一、分布式架构概述
微服务架构属于分布式架构的一种。
1、单体、集群、分布式区别
2、分布式架构优点
3、分布式架构缺点
4、分布式架构设计原则
分布式系统架构的强大，不仅仅是“拆”，还因为可以融合各种“中间件”，容错高可用。
- 异步解耦
- 不仅仅模块代码解耦， 模块间通信也要尽可能解耦。【消息队列实现通信解耦】
- 幂等一致性
- 用户的请求有可能经过多个子系统，要保证最终对数据库的操作只有一份，即要保证数据库数据一致性（主要针对数据库的“增”、“改”而言）。
- 拆分原则
- 可以按照各种标准拆分，比如：门户子系统、用户中心子系统、搜索子系统、文件处理子系统…
- 融合分布式中间件
- 比如：Redis缓存中间件、Zookeeper中间件、 消息队列
- 容错高可用
二、Redis介绍、安装、配置【Linux系统】
1、为什么引入Redis
Keepalived + LVS + Nginx “高可用”集群架构弊端
当系统访问量增大后，数据库压力会非常大。使用分布式缓存Redis数据库，提供系统的并发量。
2、什么是NoSql
3、什么是分布式缓存，什么是Redis
3.1 分布式缓存
3.2 Redis是什么
4、分布式缓存方案与技术选型
4.1 Ehcache（适合单体应用）
4.2 Memcache（Nosql、分布式、不可持久化、只存字符串）
4.3 Redis（Nosql、分布式、可持久化、数据结构丰富）
5、安装与配置Redis
5.1 下载Redis
官网：https://redis.io/download
选择下载稳定版本，不稳定版本可以尝鲜，但是不推荐在生产使用。
上传至linux
5.2 安装 Redis
解压redis：
tar -zxvf redis-5.0.5.tar.gz
安装gcc编译环境，如果已经安装过了，那么就是 nothing to do
yum install gcc-c++
进入到 redis-5.0.5 目录，进行安装：
make && make install
执行完毕后安装成功
5.3 配置redis
- 在utils下，拷贝 redis_init_script 到 /etc/init.d 目录，目的要把redis作为开机自启动
详细步骤。。。
6、Redis命令行客户端基本使用
redis-cli -a password shutdown ：关闭redis
./redis_init_script stop ：关闭redis
redis-cli ：进入到redis客户端
auth pwd ：输入密码
set key value ：设置缓存
get key ：获得缓存
del key ：删除缓存
redis-cli -a password ping ：查看是否存活
7、Redis的数据类型
string、hash、list、set、zset…
8、阻塞、非阻塞（使用多路复用器）
9、Redis 架构单线程模型原理
10、Redis可视化工具
Redis Desktop Manager
三、SpringBoot整合Redis
Java后端作为Client去连接Linux系统中的Redis的Server服务，去操作Redis。
在Java的代码中，调用数据库进行查询的接口中，添加Redis操作。
- 当用户查询数据时，如果在Redis（整个系统有专门的Redis节点服务器）中查找到用户查询的内容，则直接返回Redis中的内容，不再访问数据库；
- 如果Redis中没有用户要查询的内容，则查询数据库，同时将查询的内容保存到Redis中。
四、Redis的持久化机制
1、RDB: Redis DataBase
RDB：每隔一段时间，把内存中的数据写入磁盘的临时文件，作为快照，恢复的时候把快照文件读进内存。如果宕机重启，那么内存里的数据肯定会没有的，那dis后，则会恢复。
- 内存备份 --> 磁盘临时文件
- 临时文件 --> 恢复到内存
优势
- 每隔一段时间备份，全量备份
- 灾备简单，可以远程传输
- 子进程备份的时候，主进程不会有任何io操作（不会有写入修改或删除），保证备份数据的的完整性
- 相对AOF来说，当有更大文件的时候可以快速重启恢复
劣势
- 发生故障是，有可能会丢失最后一次的备份数据
- 子进程所占用的内存比会和父进程一模一样，如会造成CPU负担
- 由于定时全量备份是重量级操作，所以对于实时备份，就无法处理了。
RDB的配置
-
保存位置，可以在redis.conf自定义：
/user/local/redis/working/dump.rdb -
保存机制：
save 900 1 save 300 10 save 60 10000 save 10 3* 如果1个缓存更新，则15分钟后备份 * 如果10个缓存更新，则5分钟后备份 * 如果10000个缓存更新，则1分钟后备份 * 演示：更新3个缓存，10秒后备份 * 演示：备份dump.rdb，删除重启
2、AOF: Append Only File
RDB会丢失最后一次备份的rdb文件，但是其实也无所谓，其实也可以忽略不计，毕竟是缓存，丢了就丢了，但是如果追求数据的完整性，那就的考虑使用AOF了。
AOF特点
- 以日志的形式来记录用户请求的写操作。读操作不会记录，因为写操作才会存存储。
- 文件以追加的形式而不是修改的形式。
- redis的aof恢复其实就是把追加的文件从开始到结尾读取执行写操作。
优势
- AOF更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性。所以AOF可
一次，使用fsync操作。 - 以log日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具
- 当数据太大的时候，redis可以在后台自动重写aof。当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端
作。 - AOF 日志包含的所有写操作，会更加便于redis的解析恢复。
劣势
- 相同的数据，同一份数据，AOF比RDB大
- 针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对与RDB来说就略低。 每秒备份fsync没毛病，但是
的每次写入就做一次备份fsync的话，那么redis的性能就会下降。 - AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单，但是呢为
的产生，AOF就不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去做重构，这样就更加健壮和可靠了。
AOF的配置
# AOF 默认关闭，yes可以开启
appendonly no
# AOF 的文件名
appendfilename "appendonly.aof"
# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec
# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no
# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
五、Redis 主从复制架构（一主二从）
主从复制架构：通过增加从节点服务器来增加性能，把主节点服务器Redis的数据复制给从节点的Redis。
Master节点中内存Redis的数据先写入本节点磁盘，然后发送给Slave节点写入磁盘，然后再从Slave的磁盘读入Slave的内存Redis。
一般使用一主二从模型，Slave一般用2台节点，如果Slave节点多的话，Master与Slave间的数据传输会大大占用内网资源。
1、搭建Redis主从复制（一主二从）
准备三台服务器（已经安装了Redis，克隆）
此时可以看到，三台服务器的Redis都是Master。
只需要修改2台作为Slave的节点的Redis配置即可。
- 修改Slave节点的redis.conf配置文件
- 填写Master节点的内网地址
- 填写Master节点的密码
- 配置Slave节点只作为“读”节点
所有Slave节点配置完毕之后，Master节点进入Redis后查看信息：
如果Master节点的Redis出现异常，则Slave节点显示：
2、Redis无磁盘化复制（实验性功能）
如果Redis所在的节点服务器的磁盘是机械硬盘，读写速度会很慢。可以开启无磁盘化复制模式。此模式默认是关闭的，需要开启。
3、Redis 缓存过期处理与内存淘汰机制
计算机内存有限，越大越贵，Redis的高并发高性能都是基于内存的，用硬盘的话GG。
设置了expire的key缓存过期了，但是服务器的内存还是会被占用，这是因为redis所基于的两种删除策略
redis有两种策略：
- （主动）定时删除
- 定时随机的检查过期的key，如果过期则清理删除。（每秒检查次数在redis.conf中的hz配置）
- （被动）惰性删除
- 当客户端请求一个已经过期的key的时候，那么redis会检查这个key是否过期，如果过期了，则删除，然后返回一个nil。这种策略
友好，不会有太多的损耗，但是内存占用会比较高
- 当客户端请求一个已经过期的key的时候，那么redis会检查这个key是否过期，如果过期了，则删除，然后返回一个nil。这种策略
所以，虽然key过期了，但是只要没有被redis清理，那么其实内存还是会被占用着的。
内存占满了，可以使用硬盘，来保存，但是没意义，因为硬盘没有内存快，会影响redis性能。所以，当内存占用满了以后，redis提供了一套缓存淘汰机制：MEMORY MANAGEMENT
maxmemory ：当内存已使用率到达，则开始清理缓存
* noeviction：旧缓存永不过期，新缓存设置不了，返回错误
* allkeys-lru：清除最少用的旧缓存，然后保存新的缓存（推荐使用）
* allkeys-random：在所有的缓存中随机删除（不推荐）
* volatile-lru：在那些设置了expire过期时间的缓存中，清除最少用的旧缓存，然后保存新的缓存
* volatile-random：在那些设置了expire过期时间的缓存中，随机删除缓存
* volatile-ttl：在那些设置了expire过期时间的缓存中，删除即将过期的
六、Redis 哨兵机制（实现高可用、高并发）【单Master多Slave集群模式】
Master挂了，如何保证可用性，实现继续读写？
Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，是 Redis 高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。
1、在Master节点上配置哨兵
创建并且配置sentinel.conf：将Redis安装包中的sentinel.conf配置文件拷贝至Master节点服务器的Redis的安装目录。
修改sentinel.conf配置文件：
-
普通配置
port 26379 pidfile "/usr/local/redis/sentinel/redis-sentinel.pid" dir "/usr/local/redis/sentinel" daemonize yes protected-mode no logfile "/usr/local/redis/sentinel/redis-sentinel.log" -
核心配置
# 配置哨兵 sentinel monitor mymaster 127.0.0.1 6379 2 # 密码 sentinel auth-pass <master-name> <password> # master被sentinel认定为失效的间隔时间 sentinel down-after-milliseconds mymaster 30000 # 剩余的slaves重新和新的master做同步的并行个数 sentinel parallel-syncs mymaster 1 # 主备切换的超时时间，哨兵要去做故障转移，这个时候哨兵也是一个进程，如果他没有去执行，超过这个时间后，会由其他 sentinel failover-timeout mymaster 180000
2、 将Master节点上哨兵配置文件拷贝至Slave节点
拷贝后，不需要修改。
3、开启哨兵
Master、Slave节点都要先创建一个文件夹用于存放日志文件，不创建该文件夹的话会报错。
开启Master节点上Redis的哨兵
开启Slave1、Slave2节点上Redis的哨兵后，Master节点上会添加Slave1、Slave2上的哨兵信息
4、测试哨兵功能
4.1 关闭Master节点的Redis
从Master节点的Redis的日志可以看到，Master节点（192.168.1.191）宕机，通过选举，选择原来的Slave节点（192.168.1.192）作为新的Master，
从节点 192.168.1.192 的Redis的 info里可以看到：
从节点 192.168.1.193 的Redis的 info里可以看到：
4.2 开启原来的Master节点的Redis【开启后成为Slave】
开启原来的Master节点的Redis之后，该节点不会重新变为Master，而是作为Slave。
5、解决原Master恢复后不同步问题
原来的Master（191）恢复成Slave后，他的同步状态不OK，状态为 master_link_status:down ，这是为什么呢？
这是因为我们只设置了192和193的 masterauth ，这是用于同步master的数据，但是191一开始是master是不受影响的，当master转变为slave后，由于他没有
auth ，所以他不能从新的master同步数据，随之导致 info replication 的时候，同步状态为 down ，所以只需要修改 redis.conf 中的 masterauth 为 im
一般master数据无法同步给slave的方案检查为如下：
- 网络通信问题，要保证互相ping通，内网互通。
- 关闭防火墙，对应的端口开发（虚拟机中建议永久关闭防火墙，云服务器的话需要保证内网互通）。
- 统一所有的密码，不要漏了某个节点没有设置
6、 哨兵信息检查
# 查看imooc-master下的master节点信息
sentinel master imooc-master
# 查看imooc-master下的slaves节点信息
sentinel slaves imooc-master
# 查看imooc-master下的哨兵节点信息
sentinel sentinels imooc-master
7、SpringBoot 集成Redis哨兵机制【单Master多Slave集群模式】
spring:
redis:
# Redis哨兵机制
database: 1
password: imooc
sentinel:
master: imooc-master
nodes: 192.168.1.191:26379,192.168.1.192:26379,192.168.1.193:26379
七、Redis-Cluster 集群（实现高可用、高并发）【多Master多Slave集群模式】【三主三从集群模式】
学习了“主从复制”以及“哨兵机制”，他们可以提高读的并发，但是单个master容量有限，数据达到一定程度会有瓶颈，这个时候可以通过水平扩展为多master集群。
redis-cluster：他可以支撑多个master-slave，支持海量数据，实现高可用与高并发。
哨兵模式其实也是一种集群，他能够提高读请求的并发，但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实是异步复制吧，这个时候了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失。master恢复并转换成slave后，新数据则丢失。
特点
- 每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在与一个集群环境中，他们彼此之间可以交互和通信。那么这些关系都会保存到某个配置文件中，每个节点都有此配置文件，这个我们在搭建的时候会做配置的。
- 客户端要和集群建立连接的话，只需要和其中一个建立关系就行。
- 某个节点挂了，也是通过超过半数的节点来进行的检测，“客观下线”后主从切换，和我们之前在哨兵模式中提到的是一个道理。
- Redis中存在很多的插槽，又可以称之为槽节点，用于存储数据。
构建Redis集群，需要至少3个节点作为master，以此组成一个高可用的集群，此外每个master都需要配备一个slave，所以整个集群需要6个节点，这也是最经典 群，也可以称之为三主三从，容错性更佳。
- 各个Master节点之间的数据不是复制关系，一份数据只会保存的所有Master节点中的一个Master节点上
- Master节点与其对应的Slave节点是主从复制关系。
所以在搭建的时候需要有6台虚拟机。请各自准备6台虚拟机，可以通过克隆去构建，使用单实例的Redis 去克隆即可
- 集群也可以在单服务器构建，称之为伪集群，但是生产环境肯定是真的，所以建议用6台。
- 克隆后务必关闭Redis。
1、配置redis配置文件（6台节点服务器都要配置）
# 开启集群模式
cluster-enabled yes
# 每一个节点需要有一个配置文件（不需要手动编辑），需要6份。每个节点处于集群的角色都需要告知其他所有节点，彼此知道，这个文件用于存储集
cluster-config-file nodes-201.conf
# 超时时间，超时则认为master宕机，随后主备切换
cluster-node-timeout 5000
# 开启AOF
appendonly yes
停止redis，然后重新启动redis
2、构建“三主三从”集群
- 启动6台
- 如果启动过程出错，把rdb等文件删除清空
- 创建集群：进入redis安装包/src文件夹，执行以下命令
##### # 注意1：如果你使用的是redis3.x版本，需要使用redis-trib.rb来构建集群，最新版使用C语言来构建了，这个要注意 # 注意2：以下为新版的redis构建方式 ##### # 创建集群，主节点和从节点比例为1，1-3为主，4-6为从，1和4，2和5，3和6分别对应为主从关系，这也是最经典用的最多的集 redis-cli --cluster create ip1:port1 ip2:port2 ip3:port3 ip4:port4 ip5:port5 ip6:port6 --cluster-replicas 1
slots：槽，用于装数据，主节点有，从节点没有
3、检查集群信息
查看某个节点信息：
redis-cli --cluster check 192.168.1.201:6379
4、槽（Slot）怎么分配
槽节点是用于存储数据。数据是保存在槽里的，而不是Redis。
遵从一致性hash原则
5、测试Redis集群
在随便一台节点上测试，比如在203节点上操作
- 查看集群上节点（192.168.1.202）的信息
- 查看节点信息
- 在节点202上使用
keys *看不到节点201上的信息，可以通过get keyname查看redis里保存的key-value信息。
6、Springboot集成Redis集群【多Master多Slave集群模式】
spring:
redis:
# Redis集群模式
password: imooc
cluster:
nodes: 192.168.1.201:6379,192.168.1.202:6379,192.168.1.203:6379,192.168.1.204:6379,192.168.1.205:6379,192.168.1.206:6379
八、Redis缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
解决方案：
- 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
- 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
九、Redis缓存雪崩
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是， 缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
解决方案：
- 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
- 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
- 设置热点数据永远不过期。
414
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
