制作一个网站数据库怎么做,指数基金,机械加工网入网,巨鹿县住房与城乡建设厅网站上篇博客我们说到了redis的基本概念和基本操作#xff0c;本篇我们就更深入去了解一些redis的操作和概念#xff0c;我们就从red的主从同步、redis哨兵模式和redis集群三个方面来了解redis数据库
一、主从同步
像MySQL一样#xff0c;redis是支持主从同步的#xff0c;而…上篇博客我们说到了redis的基本概念和基本操作本篇我们就更深入去了解一些redis的操作和概念我们就从red的主从同步、redis哨兵模式和redis集群三个方面来了解redis数据库
一、主从同步
像MySQL一样redis是支持主从同步的而且也支持一主多从以及多级从结构。 主从结构一是为了纯粹的冗余备份二是为了提升读性能比如很消耗性能的SORT就可以由从服务器来承担。 redis的主从同步是异步进行的。
1.主从同步原理
从服务器会向主服务器发出SYNC指令当主服务器接到此命令后就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作也就是将主服务器的数据写入RDB文件中。在数据持久化期间主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后主服务器会将持久化好的RDB文件发送给从服务器从服务器接到此文件后会将其存储到磁盘上然后再将其读取到内存中。这个动作完成后主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
另外要说的一点是即使有多个从服务器同时发来SYNC指令主服务器也只会执行一次BGSAVE然后把持久化好的RDB文件发给多个从服务器。
2.部署主从同步(一主两从)
部署环境
192.168.91.5 redis-master
192.168.91.149 redis-slave-1
192.168.91.150 redis-slave-2关闭防火墙和selinux
systemctl stop firewalld
systemctl disable firewalld #关闭防火墙
setenforce 0 #关闭selinux 修改master配置文件
# vim /usr/local/redis/redis.confbind 0.0.0.0
protected-mode no
修改slave配置文件
#vim /usr/local/redis/redis.confbind 0.0.0.0
protected-mode no
replicaof 192.168.91.5 重启redis服务再netstat -nlpt查看一下端口即可
二、哨兵模式
哨兵模式是用于监控redis主从复制中Master状态的工具所以我们的哨兵模式都是基于主从复制的基础去做的
1.作用
检测Master状态如果Master异常则会进行Master-Slave切换将其中一个Slave作为Master将之前的Master作为Slave Master-Slave切换后sentinel的监控目标会随之调换
2.工作模式
1)每个Sentinel以每秒钟一次的频率向它所知的MasterSlave以及其他 Sentinel 实例发送一个 PING 命令 2)如果一个实例instance距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值则这个实例会被 Sentinel 标记为主观下线。 3)如果一个Master被标记为主观下线则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 4)当有足够数量的 Sentinel大于等于配置文件指定的值在指定的时间范围内确认Master的确进入了主观下线状态 则Master会被标记为客观下线 ps:quorum 的值一般设置为哨兵个数的二分之一加1例如 3 个哨兵就设置 2。
3.主观下线和客观下线
主观下线Subjectively Down简称 SDOWN指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线Objectively Down 简称 ODOWN指的是多个 Sentinel(哨兵) 实例在对Master Server做出 SDOWN 判断并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后得出的Master Server下线判断然后开启failover(故障转移)
4.配置哨兵模式
vim /usr/local/redis/sentinel.confdaemonize yes #设置哨兵放后台运行
logfile /var/log/sentinel.log #设置哨兵日志
sentinel monitor mymaster 192.168.91.5 6379 2 #当集群中有2个sentinel认为master死了时才能真正认为该master已经不可用了。 (slave上面写的是master的ipmaster写自己ip)
protected-mode no #将加密保护关闭
sentinel down-after-milliseconds mymaster 3000 #单位毫秒
sentinel failover-timeout mymaster 10000 #若sentinel在该配置值内未能完成failover(故障转移)操作即故障时master/slave自动切换则认为本次failover失败。[rootredis-master redis]# ./src/redis-sentinel sentinel.conf #开启哨兵模式
三、redis集群
1.使用redis集群的原因
1.首先Redis单实例主要有单点容量有限流量压力上限的问题。
Redis单点故障可以通过主从复制replication和自动故障转移sentinel哨兵机制。但Redis单Master实例提供读写服务仍然有容量和压力问题。2.并发问题
redis官方声称可以达到 10万/每秒,每秒执行10万条命令
假如业务需要每秒100万的命令执行呢
解决方案如下
正确的应该是考虑分布式加机器把数据分到不同的位置分摊集中式的压力。那么一堆机器做一件事.还需要一定的机制保证数据分区并且数据在各个主Master节点间不能混乱。总结:
redis cluster:主要是针对海量数据高并发高可用的场景海量数据如果你的数据量很大那么建议就用redis cluster
2.redis集群特点
1.所有的redis节点彼此互联(PING-PONG机制)。
2.客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
3.节点的fail是通过集群中超过半数的节点检测失效时才生效。
4.Redis-Cluster采用无中心结构每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。
3.数据分布存储原理
Redis 集群使用数据分片来实现Redis 集群中内置了 16384 个哈希槽当需要在 Redis 集群中放置一个 key-value 时redis 先对 key 使用 crc16 算法算出一个结果然后把结果对 16384 求余数(集群使用公式 CRC16(key) % 16384)这样每个key 都会对应一个编号在 0-16384 之间的哈希槽那么redis就会把这个key 分配到对应范围的节点上了。同样当连接三个节点任何一个节点想获取这个key时也会这样的算法然后内部跳转到存放这个key节点上获取数据。
4.集群部署
准备环境
1.准备三机器关闭防火墙和selinux
2.制作解析并相互做解析。
注:规划架构两种方案一种是单机多实例这里我们采用多机器部署:
三台机器每台机器上面两个redis实例一个master一个slave第一列做主库第二列做备库
#记得选出控制节点redis-cluster1 192.168.91.5 7000、7001
redis-cluster2 192.168.91.149 7002、7003
redis-cluster3 192.168.91.150 7004、7005
安装redis(三台机器都需要操作)
yum -y install gcc automake autoconf libtool make #安装编译工具
wget https://download.redis.io/releases/redis-6.2.0.tar.gz #下载
tar xzvf redis-6.2.0.tar.gz -C /usr/local #解压
mv /usr/local/redis-6.2.0 /usr/local/redis #改名
cd /usr/local/redis
make #编译
mkdir /usr/local/redis/data #创建存放数据的目录
创建节点目录:按照规划在每台redis节点的安装目录中创建对应的目录以端口号命名
[rootredis-cluster1 redis]# pwd
/usr/local/redis[rootredis-cluster1 redis]# mkdir cluster #创建集群目录
[rootredis-cluster1 redis]# cd cluster/
[rootredis-cluster1 cluster]# mkdir 7000 7001 #创建节点目录[rootredis-cluster2 redis]# mkdir cluster
[rootredis-cluster2 redis]# cd cluster/
[rootredis-cluster2 cluster]# mkdir 7002 7003[rootredis-cluster3 redis]# mkdir cluster
[rootredis-cluster3 redis]# cd cluster/
[rootredis-cluster3 cluster]# mkdir 7004 7005
拷贝配置文件到节点目录中
[rootredis-cluster1 cluster]# cp /data/redis/redis.conf 7000/
[rootredis-cluster1 cluster]# cp /data/redis/redis.conf 7001/[rootredis-cluster2 cluster]# cp /data/redis/redis.conf 7002/
[rootredis-cluster2 cluster]# cp /data/redis/redis.conf 7003/[rootredis-cluster3 cluster]# cp /data/redis/redis.conf 7004/
[rootredis-cluster3 cluster]# cp /data/redis/redis.conf 7005/
修改集群redis配置文件。(主要是端口、ip、pid文件三台机器相同操作)
[rootredis-cluster1 7000]# vim redis.conf bind 192.168.116.172 #每个实例的配置文件修改为对应节点的ip地址
port 7000 #监听端口运行多个实例时需要指定规划的每个实例不同的端口号
daemonize yes #redis后台运行
pidfile /var/run/redis_7000.pid #pid文件运行多个实例时需要指定不同的pid文件
logfile /var/log/redis_7000.log #日志文件位置运行多实例时需要将文件修改的不同。
dir /data/redis/data #存放数据的目录
appendonly yes #开启AOF持久化redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中当redis重新启动时会从该文件恢复出之前的状态。
appendfilename appendonly.aof #AOF文件名称
appendfsync everysec #表示对写操作进行累积每秒同步一次以下为打开注释并修改
cluster-enabled yes #启用集群
cluster-config-file nodes-7000.conf #集群配置文件由redis自动更新不需要手动配置运行多实例时请注修改为对应端口
cluster-node-timeout 5000 #单位毫秒。集群节点超时时间即集群中主从节点断开连接时间阈值超过该值则认为主节点不可以从节点将有可能转为master
cluster-replica-validity-factor 10 #在进行故障转移的时候全部slave都会请求申请为master但是有些slave可能与master断开连接一段时间了导致数据过于陈旧不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。
cluster-migration-barrier 1 #一个主机将保持连接的最小数量的从机以便另一个从机迁移到不再被任何从机覆盖的主机
cluster-require-full-coverage yes #集群中的所有slot16384个全部覆盖才能提供服务
注:所有节点配置文件全部修改切记需要修改的ip、端口、pid文件...避免冲突。确保所有机器都修改。
启动三台机器上面的每个节点
[rootredis-cluster1 src]# ./redis-server ../cluster/7000/redis.conf
[rootredis-cluster1 src]# ./redis-server ../cluster/7001/redis.conf[rootredis-cluster2 7003]# cd /data/redis/src/
[rootredis-cluster2 src]# ./redis-server ../cluster/7002/redis.conf
[rootredis-cluster2 src]# ./redis-server ../cluster/7003/redis.conf[rootredis-cluster3 7005]# cd /data/redis/src/
[rootredis-cluster3 src]# ./redis-server ../cluster/7004/redis.conf
[rootredis-cluster3 src]# ./redis-server ../cluster/7005/redis.conf
查看端口
netsata -lnpt #查看端口 查看到这些信息之后就说明我们的redis集群搭建成功了
四、总结redis在运维方面的经典问题
一、如何解决Redismysql双写一致性
1.最经典的缓存数据库读写的模式:
读的时候先读缓存缓存没有的话就读数据库然后取出数据后放入缓存同时返回响应。
更新的时候先更新数据库然后再删除缓存。
2.给缓存设置过期时间这种方案下可以对存入缓存的数据设置过期时间所有的写操作以数据库为准也就是说如果数据库写成功缓存更新失败那么只要到达过期时间则后面的读请求自然会从数据库中读取新值然后回填缓存。二、缓存雪崩
数据未加载到缓存中或者缓存同一时间大面积的失效从而导致所有请求都去查数据库导致数据库CPU和内存负载过高甚至宕机。产生雪崩的简单过程
1、redis集群大面积故障
2、缓存失效但依然大量请求访问缓存服务redis
3、redis大量失效后大量请求转向到mysql数据库mysql的调用量暴增很快就扛不住了甚至直接宕机
4、由于大量的应用服务依赖mysql和redis的服务这个时候很快会演变成各服务器集群的雪崩最后网站彻底崩溃。解决问题
1.缓存的高可用性
缓存层设计成高可用防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉依然可以提供服务例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2.缓存降级
可以利用ehcache等本地缓存(暂时支持)主要还是对源服务访问进行限流、资源隔离熔断、降级等。
当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级也可以配置开关实现人工降级这里会涉及到运维的配合。
降级的最终目的是保证核心服务可用即使是有损的。
在进行降级之前要对系统进行梳理比如哪些业务是核心(必须保证)哪些业务可以容许暂时不提供服务(利用静态页面替换)等以及配合服务器核心指标来后设置整体。
3.Redis备份和快速预热
1)Redis数据备份和恢复
2)快速缓存预热
4.提前演练
最后建议还是在项目上线前演练缓存层宕掉后应用以及后端的负载情况以及可能出现的问题对高可用提前预演提前发现问题。三、缓存穿透
缓存穿透是指查询一个一不存在的数据。例如从缓存redis没有命中需要从mysql数据库查询查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到数据库去查询造成缓存穿透。解决问题
如果查询数据库也为空直接设置一个默认值存放到缓存这样第二次到缓冲中获取就有值了而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。四、redis有哪些好处
(1) 速度快因为数据存在内存中.
(2) 支持丰富数据类型支持stringlistsetsorted sethash
(3) 支持事务操作都是原子性所谓的原子性就是对数据的更改要么全部执行要么全部不执行
(4) 丰富的特性可用于缓存消息按key设置过期时间过期后将会自动删除
redis相比memcached有哪些优势
(1) memcached所有的值均是简单的字符串redis作为其替代者支持更为丰富的数据类型
(2) redis可以持久化其数据
redis常见性能问题和解决方案
(1) Master最好不要做任何持久化工作如RDB内存快照和AOF日志文件
(2) 如果数据比较重要某个Slave开启AOF备份数据策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
