***Redis的三个问题: 高并发(分布 集群), 高可用(集群), 海量数据
分别解决办法: 读写分离 , Senti自动故障转移, ***
一. Redis分布式缓存
- redis-benchmark是官方自带的Redis性能测试工具，用来测试Redis在当前环境下的读写性能。我们在 使用Redis的时候，服务器的硬件配置、网络状况、测试环境都会对Redis的性能有所影响，我们需要对 Redis实时测试以确定Redis的实际性能。
使用语法: redis-benchmark [参数][参数值]
参数说明：
-h 指定服务器主机名 127.0.0.1
-p 指定服务器端口 6379
-s 指定服务器 socket
-c 指定并发连接数 50
-n 指定请求数 10000
-d 以字节的形式指定 SET/GET 值的数据大小 2
-k 1=keep alive 0=reconnect 1
-r SET/GET/INCR 使用随机 key, SADD 使用随机值
-P 通过管道传输 请求 1
-q 强制退出 redis。仅显示 query/sec 值
–csv 以 CSV 格式输出
-l 生成循环，永久执行测试
-t 仅运行以逗号分隔的测试命令列表。
-I Idle 模式。仅打开 N 个 idle 连接并等待。
-
安装redis
1.)在虚拟机中安装c++环境：
yum install gcc-c++2.)安装Redis，依次执行以下命令： #解压 tar -zxf redis-4.0.14.tar.gz # 进入解压目录 cd redis-4.0.14 # 编译 make # 安装 make install PREFIX=/usr/local/redis #进入安装好的redis目录 cd /usr/local/redis/bin #复制配置文件 cp /root/redis-4.0.14/redis.conf ./ #修改配置文件 vi redis.conf # Redis后台启动 修改 daemonize 为 yes # Redis服务器可以跨网络访问 修改 bind 为 0.0.0.0 # 开启bind 为 0.0.0.0 appendonly yes # 启动redis ./redis-server redis.conf 3.)执行以下命令，测试性能： # 执行测试性能命令 ./redis-benchmark -t set,get -n 100000 -
TPS、QPS、RT
QPS:每秒查询次数,针对单机(硬件性能)
RT:响应时间
TPS:吞吐量,针对整个项目 保持平衡状态,既没有等待,也没有闲置 -
并发, 数据量与安全 (高并发,高可用,海量数据 )
并发 – 单位时间内请求的次数
数据量 – 数据量太大,存储空间太小
安全 – 如果服务挂机, 用户就找不到主机
VIP – 虚拟IP -
Redis的读写分离
redis自身集成了读写分离供用户使用。我们只需在redis的配置文件里面加上一条，slaveof host port语句配置即可，我们现在开始配置主从环境。
执行命令:
#复制redis
cd /usr/local/redis/bin
cp -R bin redis01
#修改配置
vi redis.conf
修改 port 为 6380
添加 slaveof 192.168.200.129 6379
#清空持久化文件
rm -rf dump.rdb
rm -rf appendonly.aof
#启动
./redis-server redis.conf
分别连接主库（6379）和从库（6380），测试发现主库的写操作，从库立刻就能看到相同的数据。但是在从库进行写操作，提示 READONLY You can't write against a read only slave 不能写数据到从库。
现在我们就可以通过这种方式配置多个从库读操作，主库进行写操作，实现读写分离，以提高redis的QPS。
-
Redis的同步原理
我们知道redis的主从复制，主服务器执行写操作命令，从服务器会通过 主服务器的数据的变化，同步数据到从服务器。但是如果主服务器下线，从服务器无法连接主服务器，那么数据同步该如何拿到不能连接主服务器这段时间的命令呢？主从复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称作数据库状态一致。 Redis数据库持久化有两种方式：RDB全量持久化(默认,内存快照 ,快,数据不安全 )和AOF增量持久化(日志记录,慢,数据安全)。 数据同步步骤：1.) redis2.8版本之前使用旧版复制功能SYNC，这是一个非常耗费资源的操作
- 主服务器需要执行BGSAVE命令来生成RDB文件，这个生成操作会耗费主服务器大量量的的CPU、内存和磁盘读写资源。
- 主服务器将RDB文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络带宽和流量，并对主服务器响应命令
- 请求的时间产生影响：接收到RDB文件的从服务器在载入文件的过程是阻塞的，无法处理命令请求
2.) redis2.8之后使用PSYNC，具有完整重同步和部分重同步两种模式部分重同步两种模式。
第一种完整重同步：
第二种部分重同步：
功能由以下三个部分构成：
1） 主服务的复制偏移量（replication offset）和从服务器的复制偏移量量。
2） 主服务器的复制积压缓冲区（replication backlog）,默认大小为1M。
3） 服务器的运行ID，用于存储服务器标识：
如果从服务器断线重新连接，获取主服务器的运行ID与重接后的主服务器运行ID进行对比，判断是不是原来的主服务器，从而决定是执行部分重同步，还是执行完整重同步。
二. Redis高可用Sentinel
-
高可用介绍
高可用是分布式系统架构设计中必须考虑的因素之一，它是通过架构设 计减少系统不能提供服务的时间。保证高可用通常遵循下面几点：-
)单点是系统高可用的大敌，应该尽量在系统设计的过程中避免单点。
-
)通过架构设计而保证系统高可用的，其核心准则是：冗余。
-
)每次出现故障需要人工介入恢复，会增加系统不可用的时间，实现自动故障转移(重点)。
我们现在已经给Redis实现了主从复制，可将主节点数据同步给从节点，从节点此时有两个作用：
-
)从节点扩展主节点的读能力，分担主节点读压力。
-
) 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。（高可用）
-
-
手动主从切换
- )环境准备
cd /usr/local/redis/
cp redis01/ redis02 -R
vi redis.conf
修改 port 为 6381
./redis-server redis.conf
分别进入一主两从服务，执行info命令，看到服务的状态： - )主从切换
- )环境准备
-
Sentinel(哨兵)实现高可用 – 自动故障转移
在前面的例子中，主节点宕机，需要把从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点。
这整个过程都是人工，费事费力，还会造成一段时间内服务不可用，而且需要人一直都在。这不是一种好的方式，更多时候，我们优先考虑Sentinel（哨兵）。在读写分离的时候,如果主机出现了挂机的事情,sentinel就负责把一个从机升级为主机,继续运行.
1 安装
1.) Sentinel在redis的安装包中有，我们直接使用就可以了，但是先需要修改配置文件，执行命令：
cd /usr/local/redis/
#复制sentinel配置文件
cp /root/redis-4.0.14/sentinel.conf sentinel01.conf
#修改配置文件：
vi sentinel01.conf
2.) 在sentinel01.conf配置文件中添加：
# 外部可以访问
bind 0.0.0.0
sentinel monitor mymaster 192.168.200.128 6379 1
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
注意：如果有sentinel monitor mymaster 192.168.200.129 6379 2配置，则注释掉。
参数说明：
- sentinel monitor mymaster 192.168.200.129 6379 1
mymaster 主节点名,可以任意起名，但必须和后面的配置保持一致。
192.168.200.129 6379 主节点连接地址。
1 将主服务器判断为失效需要投票，这里设置至少需要 1个 Sentinel 同意。
- sentinel down-after-milliseconds mymaster 10000
设置Sentinel认为服务器已经断线所需的毫秒数。
- sentinel failover-timeout mymaster 60000
设置failover（故障转移）的过期时间。当failover开始后，在此时间内仍然没有触发任何failoer操作，当前
sentinel 会认为此次failoer失败。
- sentinel parallel-syncs mymaster 1
设置在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小，表示同时进行同步的从服务器越少，那么完成故障转移所需的时间就越长。
如果从服务器允许使用过期数据集， 那么我们可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为从服务器在载入主服务器发来的RDB文件时， 会造成从服务器在一段时间内不能处理命令请求。如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。3.) 配置文件修改后，执行以下命令，启动sentinel： /root/redis-4.0.14/src/redis-sentinel sentinel01.conf 4.) 进行测试 在6379执行shutdown，关闭主服务2 原理
Sentinel主要是监控服务器的状态，并决定是否进行故障转移。如何进行故障转移在前面的部分已经给大家演示过人工的操作，那么Sentinel是如何判断服务是否下线呢，主要分为主观下线和客观下线：
-
主观下线：
- 概念：
主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断 - 特点：
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复， 那么 Sentinel 就会将这个服务器标记为主观下线
- 概念：
-
客观下线
-
概念：
多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断ODOWN。 （一个Sentinel 可以通过向另一个 Sentinel 发送命令来询问对方是否认为给定的服务器已下线） -
特点：
从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum algorithm），而是使用了流言传播（Gossip）： 如果Sentinel在给定的时间范围内， 从其他Sentinel那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 -
注意点：
客观下线条件只适用于主服务器，对于其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不不需要进行协商， 所以从服务器或者其他 Sentinel 不会达到客观下线条件。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个Sentinel就可能会被其他 Sentinel 推选出，并对失效的主服务器执行自动故障迁移操作。3 小结
Sentinel三大工作任务
- 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过API向管理员或者其他应用程序发送通知。
- 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时，Sentinel会开始一次自动故障转移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器。
当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。**互联网冷备和热备**
-
-
冷备
概念：冷备发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完整的数据库
优点：非常快速的备份方法（只需拷文件), 低度维护，高度安全
缺点：a,单独使用时，只能提供“某一时间点上”的恢复
b.在实施备份的全过程中，数据库必须要作备份而不能作其他工作。也就是说，在冷备份过程中，数据库必须是关闭状态
2) 热备
概念：热备份是在数据库运行的情况下，采用归档模式(archivelog mode)方式备份数据库的方法
优点：备份的时间短, 备份时数据库仍可使用, 可达到秒级恢复
缺点：若热备份不成功，所得结果不可用于时间点的恢复。难于维护，要非常仔细小心
三. Redis内置集群
1.
1741
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
