一： 缓存概念：
缓存是为了调节速度不一致的两个或多个不同的物质的速度，在中间对速度较快的一方起到一个加
速访问速度较慢的一方的作用，比如 CPU 的一级、二级缓存是保存了 CPU 最近经常访问的数据，内存是保存 CPU 经常访问硬盘的数据，而且硬盘也有大小不一的缓存，甚至是物理服务器的 raid 卡有也缓存，都是为了起到加速 CPU 访问硬盘数据的目的，因为 CPU 的速度太快了， CPU 需要的数据硬盘往往不能在短时间内满足 CPU 的需求，因此 PCU 缓存、内存、 Raid 卡以及硬盘缓存就在一定程度上满足了 CPU 的数据需求，即 CPU 从缓存读取数据可以大幅提高 CPU 的工作效率。
系统缓存
1、buffer 与 cache
buffer：缓冲也叫写缓冲，一般用于写操作，可以将数据先写入内存在写入磁盘 buffer 一般用于写缓冲，用于解决不同介质的速度不一致的缓冲，先将数据临时写入到里自己最近的地方，以提高写入速度， CPU 会把数据线写到内存的磁盘缓冲区，然后就认为数据已经写入完成看，然后内核的线程在后面的时间在写入磁盘，所以服务器突然断电会丢失内存中的部分数据。
cache：缓存也叫读缓存，一般用于读操作 CPU 读文件从内存读，如果内存没有就先从硬盘读到内存再读到 CPU 将需要频繁读取的数据放在里自己最近的缓存区域，下次读取的时候即可快速读取。
2、cache 的保存位置：
客户端：浏览器
内存：本地服务器、远程服务器
硬盘：本机硬盘、远程服务器硬盘
3、cache 的特性：
自动过期：给缓存的数据加上有效时间 ，超出时间后自动过期删除
过期时间：强制过期，源网站更新图片后 CDN 是不会更新的，需要强制是图片缓存过期
命中率：即缓存的读取命中率
4、用户层缓存：
5、DNS 缓存
默认为60 秒，即 60 秒之内在访问同一个域名就不在进行 DNS 解析：
查看 chrome 浏览器的 DNS 缓存：chrome://netinternals/#dns
火狐 浏览器缓存：about:cache
浏览器缓存过期机制：
最后修改时间：
系统调用会获取文件的最后修改时间，如果没有发生变化就返回给浏览器 304 的状态码，表示没有
发生变化，然后浏览器就使用的本地的缓存展示资源，
Etag 标记：
基于 Etag 标记是否一致做判断页面是否发生过变化，比如基于 Nginx 的 etag on 来实现
过期时间：
以上两种都需要发送请求，即不管资源是否过期都要发送请求进行协商，这样会消耗不必要的时间，
因此有了缓存的过期时间，即第一次请求资源的时候带一个资源的过期时间，默认为 30 天，当前这
种方式使用的比表较多，但是无法保证客户的时间都是准确并且一致的，因此假如一个最大生存周期，
使用用户本地的时间计算缓存数据是否超过多少天，下面的过期时间为 2027 年，但是缓存的最大生
存周期计算为天等于 3650 天即 10 年，过期时间如下：
CDN 缓存：
什么是 CND：
内容分发网络（ Content Delivery Network），通过将服务内容分发至全网加速节点，利用全球调度系
统使用户能够就近获取，有效降低访问延迟，提升服务可用性， CDN 第一降低机房的使用带宽，因为很多资源通过 CDN 就直接返回用户了，第二解决不同运营商之间的互联，因为可以让联通的网络访问联通让电信的网络访问电信，起到加速用户访问的目的， 第三：解决用户访问的地域问题，就近返回用户资源。
百度 CDN： https://cloud.baidu.com/product/cdn.html
阿里 CDN： https://www.aliyun.com/product/cdn?spm=5176.8269123.416540.50.728y8n
腾讯 CDN： https://www.qcloud.com/product/cdn
1.3.2： 用户请求 CDN 流程：
提前对静态内容进行预缓存，避免大量的请求回源，导致主站网络带宽被打满而导致数据无法更新，
另外 CDN 可以将数据根据访问的热度不同而进行不同级别的缓存，例如访问量最高的资源访问 CDN
边缘节点的内存，其次的放在 SSD 或者 SATA，再其次的放在云存储，这样兼顾了速度与成本。
CDN 主要优势：
提前对静态内容进行预缓存，避免大量的请求回源，导致主站网络带宽被打满而导致数据无法更新，
另外 CDN 可以将数据根据访问的热度不同而进行不同级别的缓存，例如访问量最高的资源访问 CDN边缘节点的内存，其次的放在 SSD 或者 SATA，再其次的放在云存储，这样兼顾了速度与成本。
缓存到最快的地方如内存，缓存的数据准确命中率高，访问速度就快
调度准确-将用户调度到最近的边缘节点
性能优化-CDN 专门用于缓存响应速度快
安全相关-抵御攻击
节省带宽：由于用户请求由边缘节点响应，因此大幅降低到源站带宽
应用层缓存：
Nginx、 PHP 等 web 服务可以设置应用缓存以加速响应用户请求， 另外有些解释性语言比如 PHP/Python
不能直接运行，需要先编译成字节码，但字节码需要解释器解释为机器码之后才能执行，因此字节码
也是一种缓存，有时候会出现程序代码上线后字节码没有更新的现象。
其他层面缓存：
CPU 缓存(L1 的数据缓存和 L1 的指令缓存)、二级缓存、三级缓存
磁盘缓存
RAID 卡
分布式缓存： redis、 memcache
# MegaCli64 -LDinfo -Lall –aAll
二： redis 部署与使用：
2.1： redis 基础：
官网地址： https://redis.io/
Redis 和 Memcached 是非关系型数据库也称为 NoSQL 数据库， MySQL、 Mariadb、 SQL Server、PostgreSQL、Oracle 数据库属于关系型数据(RDBMS, Relational Database Management System)
redis 简介：
Redis(Remote Dictionary Server)在 2009 年发布， 开发者 Salvatore Sanfilippo 是意大利开发者， 他本想为自己的公司开发一个用于替换 MySQL 的产品 Redis， 但是没有想到他把 Redis 开源后大受欢迎，短短几年， Redis 就有了很大的用户群体，目前国内外使用的公司有知乎网、新浪微博、 GitHub 等redis 是一个开源的、 遵循 BSD 协议的、 基于内存的而且目前比较流行的键值数据库(key-value database)，是一个非关系型数据库， redis 提供将内存通过网络远程共享的一种服务，提供类似功能的还有memcache，但相比 memcache， redis 还提供了易扩展、高性能、 具备数据持久性等功能。
Redis 在高并发、低延迟环境要求比较高的环境使用量非常广泛， 目前 redis 在 DB-Engine 月排行榜https://db-engines.com/en/ranking 中一直比较靠前，而且一直是键值型存储类的首位。
redis 对比 memcached：
支持数据的持久化：可以将内存中的数据保持在磁盘中，重启 redis 服务或者服务器之后可以从备份
文件中恢复数据到内存继续使用。
支持更多的数据类型：支持 string(字符串)、 hash(哈希数据)、 list(列表)、 set(集合)、 zet(有序集合)
支持数据的备份：可以实现类似于数据的 master-slave 模式的数据备份，另外也支持使用快照+AOF。
支持更大的 value 数据： memcache 单个 key value 最大只支持 1MB，而 redis 最大支持 512MB。
Redis 是单线程， 而 memcache 是多线程， 所以单机情况下没有 memcache 并发高， 但 redis 支持分布式集群以实现更高的并发， 单 Redis 实例可以实现数万并发。
支持集群横向扩展：基于 redis cluster 的横向扩展，可以实现分布式集群，大幅提升性能和数据安全
性，而memcached不支持集群。
都是基于 C 语言开发。
redis 典型应用场景：
Session 共享：常见于 web 集群中的 Tomcat 或者 PHP 中多 web 服务器 session 共享
消息队列： ELK 的日志缓存、 部分业务的订阅发布系统
计数器： 访问排行榜、商品浏览数等和次数相关的数值统计场景
缓存： 数据查询、 电商网站商品信息、 新闻内容
微博/微信社交场合： 共同好友、 点赞评论等
Redis 安装及使用：
官方下载地址： http://download.redis.io/releases/
yum 安装 redis：
在 centos 系统上需要安装 epel 源。
查看 yum 仓库 redis 版本
[root@centos7 ~]#rpm -qi redis
[root@centos7 ~]#yum info redis
安装 redis：
[root@centos7 ~]#yum install redis
[root@centos7 ~]#systemctl start redis && systemctl enable redis
[root@centos7 ~]#redis-cli
127.0.0.1:6379> set test 123
OK
127.0.0.1:6379> get test
"123"
127.0.0.1:6379> ping
PONG
编译安装 redis：
下载当前最新 release 版本 redis 源码包：
官方的安装命令：https://redis.io/download
[root@centos7 ~]#tar xf redis-5.0.3.tar.gz
[root@centos7 ~]#cd redis-5.0.3
[root@centos7 ~]#make PREFIX=/usr/local/redis install
[root@centos7 ~]#ll /usr/local/redis
total 0
drwxr-xr-x 2 root root 134 Dec 13 09:21 bin
[root@centos7 ~]#mkdir /usr/local/redis/etc
[root@centos7 ~]#cp redis.conf /usr/local/redis/etc/
前台启动 redis：
[root@centos7 ~]#/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf
8894:C 11 Jun 19:38:05.867 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8894:C 11 Jun 19:38:05.867 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=8894, just started
8894:C 11 Jun 19:38:05.867 # Configuration loaded
8894:S 11 Jun 19:38:05.868 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 4.0.11 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 8894
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
8894:S 11 Jun 19:38:05.870 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
8894:S 11 Jun 19:38:05.870 # Server initialized
8894:S 11 Jun 19:38:05.870 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
8894:S 11 Jun 19:38:05.871 * DB loaded from disk: 0.000 seconds
解决当前的警告提示：
tcp-backlog：
The backlog argument defines the maximum length to which the queue of pending connections
for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error
with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may
be ignored so that a later reattempt at connection succeeds.
backlog 参数控制的是三次握手的时候 server 端收到 client ack 确认号之后的队列值。
net.core.somaxconn = 512
vm.overcommit_memory：
0、表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；
否则，内存申请失败，并把错误返回给应用进程。
1、表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2、表示内核允许分配超过所有物理内存和交换空间总和的内存
vm.overcommit_memory = 1
transparent hugepage：
开启大页内存动态分配，需要关闭让 redis 负责内存管理。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
[root@centos7 ~]#vim /etc/sysctl.conf
[root@centos7 ~]#sysctl -p
net.core.somaxconn = 512
vm.overcommit_memory = 1
[root@centos7 ~]#echo never > /sys/kernel/mm/transparent_hugepage/enabled
再次启动 redis：
将以上配置同步到其他 redis 服务器。
编辑 redis 服务启动脚本:
[root@s1 ~]# cat /usr/lib/systemd/system/redis.service
[Unit]
Description=Redis persistent key-value database
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
#ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd
ExecStart=/apps/redis/bin/redis-server /apps/redis/etc/redis.conf --supervised systemd
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
Type=notify
User=root
Group=root
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
创建 redis 用户和数据目录：
[root@centos7 ~]# groupadd -g 1000 redis && useradd -u 1000 -g 1000 redis -s /sbin/nologin
[root@centos7 ~]# mkdir -pv /usr/local/redis/{etc,logs,data,run}
[root@centos7 ~]# chown redis.redis -R /usr/local/redis/
[root@centos7 ~]# systemctl start redis
使用客户端连接 redis：
[root@centos7 ~]# /usr/local/redis/bin/redis-cli -h IP/HOSTNAME -p PORT -a PASSWORD
创建命令软连接：
[root@centos7 ~]# ln -sv /usr/local/redis/bin/redis-* /usr/bin/
redis 持久化：
redis 虽然是一个内存级别的缓存程序，即 redis 是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的， redis 支持两种不同方式的数据持久化保存机制，分别是 RDB 和 AOF
RDB 模式：
只保存一份快照，下一次会覆盖上一次的备份，在保存快照的时间内如果有用户写入，是没有备份的，只记录快照瞬间前的数据，如果备份时机器down机了，会造成数据丢失
RDB： 基于时间的快照， 只保留当前最新的一次快照， 特点是执行速度比较快，缺点是可能会丢失从上次快照到当前快照未完成之间的数据。
RDB 实现的具体过程 Redis 从主进程先 fork 出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，比如 dump.rdb.temp，当数据保存完成之后再将上一次保存的 RDB 文件替换掉，然后关闭子进程，这样可以保存每一次做 RDB 快照的时候保存的数据都是完整的，因为直接替换 RDB文件的时候可能会出现突然断电等问题而导致 RDB 文件还没有保存完整就突然关机停止保存而导致数据丢失的情况，可以手动将每次生成的 RDB 文件进程备份，这样可以最大化保存历史数据。RDB 模式的优缺点：
优点：
-RDB 快照保存了某个时间点的数据，可以通过脚本执行 bgsave(非阻塞)或者 save(阻塞)命令自定义时间点北备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本。
-可以最大化 o 的性能，因为父进程在保存 RDB 文件的时候唯一要做的是 fork 出一个子进程，然后的操作都会有这个子进程操作，父进程无需任何的 IO 操作
-RDB 在大量数据比如几个 G 的数据，恢复的速度比 AOF 的快
缺点：
-不能时时的保存数据，会丢失自上一次执行 RDB 备份到当前的内存数据
-数据量非常大的时候，从父进程 fork 的时候需要一点时间，可能是毫秒或者秒
AOF 模式：
AOF:按照操作顺序依次将操作添加到指定的日志文件当中，特点是数据安全性相对较高， 缺点是即使有些操作是重复的也会全部记录。AOF 和 RDB 一样使用了写时复制机制， AOF 默认为每秒钟 fsync 一次，即将执行的命令保存到 AOF 文件当中，这样即使 redis 服务器发生故障的话顶多也就丢失 1 秒钟之内的数据，也可以设置不同的 fsync策略，或者设置每次执行命令的时候执行 fsync， fsync 会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入 AOF 文件的 IO 影响2.3.2.4： AOF 模式优缺点：AOF 的文件大小要大于 RDB 格式的文件根据所使用的 fsync 策略(fsync 是同步内存中 redis 所有已经修改的文件到存储设备)，默认是appendfsync everysec 即每秒执行一次 fsync
redis 配置文件：
redis 主要配置项：
bind 0.0.0.0 #监听地址， 可以用空格隔开后多个监听 IP
protected-mode yes #redis3.2之后加入的新特性，在没有设置bind IP和密码的时候只允许访问127.0.0.1:6379
port 6379 #监听端口
tcp-backlog 511 #三次握手的时候 server 端收到 client ack 确认号之后的队列值。
timeout 0 #客户端和 Redis 服务端的连接超时时间，默认是 0，表示永不超时。
tcp-keepalive 300 #tcp 会话保持时间
daemonize no #认情况下 redis 不是作为守护进程运行的，如果你想让它在后台运行，你就把它改成yes,当 redis 作为守护进程运行的时候，它会写一个 pid 到 /var/run/redis.pid 文件里面
supervised no #和操作系统相关参数， 可以设置通过 upstart 和 systemd 管理 Redis 守护进程， centos 7以后都使用 systemd
pidfile /var/run/redis_6379.pid #pid 文件路径
loglevel notice #日志级别
logfile "" #日志路径
databases 16 #设置 db 库数量，默认 16 个库
always-show-logo yes #在启动 redis 时是否显示 log
save 900 1 #在 900 秒内有一个键内容发生更改就出就快照机制
save 300 10
save 60 10000
stop-writes-on-bgsave-error no #快照出错时是否禁止 redis 写入操作
rdbcompression yes #持久化到 RDB 文件时，是否压缩， "yes"为压缩， "no"则反之
rdbchecksum yes #是否开启 RC64 校验，默认是开启
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路径
replica-serve-stale-data yes #当从库同主库失去连接或者复制正在进行，从机库有两种运行方式： 1) 如果 replica-serve-stale-data 设置为 yes(默认设置)，从库会继续响应客户端的读请求。 2) 如果 replicaserve-stale-data 设置为 no，除去指定的命令之外的任何请求都会返回一个错误"SYNC with master inprogress"。
replica-read-only yes #是否设置从库只读
repl-diskless-sync no #是否使用 socket 方式复制数据， 目前 redis 复制提供两种方式， disk 和 socket， 如果新的 slave 连上来或者重连的 slave 无法部分同步，就会执行全量同步， master 会生成 rdb 文件， 有2 种方式： disk 方式是 master 创建一个新的进程把 rdb 文件保存到磁盘，再把磁盘上的 rdb 文件传递给 slave， socket 是 master 创建一个新的进程，直接把 rdb 文件以 socket 的方式发给 slave， disk 方式的时候，当一个 rdb 保存的过程中，多个 slave 都能共享这个 rdb 文件， socket 的方式就是一个个 slave顺序复制， 只有在磁盘速度缓慢但是网络相对较快的情况下才使用 socket 方式， 否则使用默认的 disk方式repl-diskless-sync-delay 30 #diskless 复制的延迟时间， 设置 0 为关闭， 一旦复制开始还没有结束之前，master 节点不会再接收新 slave 的复制请求， 直到下一次开始
repl-ping-slave-period 10 #slave 根据 master 指定的时间进行周期性的 PING 监测
repl-timeout 60 #复制链接超时时间，需要大于 repl-ping-slave-period， 否则会经常报超时
repl-disable-tcp-nodelay no #在 socket 模式下是否在 slave 套接字发送 SYNC 之后禁用 TCP_NODELAY，
如果你选择“yes”Redis 将使用更少的 TCP 包和带宽来向 slaves 发送数据。但是这将使数据传输到 slave上有延迟， Linux 内核的默认配置会达到 40 毫秒， 如果你选择了 "no" 数据传输到 salve 的延迟将会减少但要使用更多的带宽
repl-backlog-size 1mb #复制缓冲区大小， 只有在 slave 连接之后才分配内存。
repl-backlog-ttl 3600 #多次时间 master 没有 slave 连接，就清空 backlog 缓冲区。
replica-priority 100 #当 master 不可用， Sentinel 会根据 slave 的优先级选举一个 master。最低的优先级的 slave，当选 master。而配置成 0，永远不会被选举。
requirepass foobared #设置 redis 连接密码
rename-command #重命名一些高危命令
maxclients 10000 #最大连接客户端
maxmemory #最大内存， 单位为 bytes 字节， 8G 内存的计算方式 8(G)*1024(MB)*1024(KB)*1024(Kbyte)，需要注意的是 slave 的输出缓冲区是不计算在 maxmemory 内。appendonly no #是否开启 AOF 日志记录， 默认 redis 使用的是 rdb 方式持久化，这种方式在许多应用中已经足够用了。但是 redis 如果中途宕机，会导致可能有几分钟的数据丢失，根据 save 来策略进行持久化，Append Only File 是另一种持久化方式，可以提供更好的持久化特性。 Redis 会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时 Redis 都会先把这个文件的数据读入内存里，先忽略 RDB 文件。
appendfilename "appendonly.aof" #AOF 文件名
appendfsync everysec #aof 持久化策略的配置,no 表示不执行 fsync,由操作系统保证数据同步到磁盘,always 表示每次写入都执行 fsync，以保证数据同步到磁盘,everysec 表示每秒执行一次 fsync，可能会导致丢失这 1s 数据。
no-appendfsync-on-rewrite no 在 aof rewrite 期间,是否对 aof 新记录的 append 暂缓使用文件同步策略,主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no,表示"不暂缓",新的 aof 记录仍然会被立即同步，Linux 的默认 fsync 策略是 30 秒，如果为 yes 可能丢失 30 秒数据， 但由于 yes 性能较好而且会避免出现阻塞因此比较推荐。
auto-aof-rewrite-percentage 100 # 当 Aof log 增长超过指定百分比例时，重写 log file， 设置为 0 表示不自动重写 Aof 日志，重写是为了使 aof 体积保持最小，而确保保存最完整的数据。
auto-aof-rewrite-min-size 64mb #触发 aof rewrite 的最小文件大小
aof-load-truncated yes #是否加载由于其他原因导致的末尾异常的 AOF 文件(主进程被 kill/断电等)
aof-use-rdb-preamble yes #redis4.0 新增 RDB-AOF 混合持久化格式，在开启了这个功能之后， AOF 重写产生的文件将同时包含 RDB 格式的内容和 AOF 格式的内容，其中 RDB 格式的内容用于记录已有的数据，而 AOF 格式的内存则用于记录最近发生了变化的数据，这样 Redis 就可以同时兼有 RDB 持久化和AOF 持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
lua-time-limit 5000 #lua 脚本的最大执行时间， 单位为毫秒
cluster-enabled yes #是否开启集群模式，默认是单机模式
cluster-config-file nodes-6379.conf #由 node 节点自动生成的集群配置文件
cluster-node-timeout 15000 #集群中 node 节点连接超时时间
cluster-replica-validity-factor 10 #在执行故障转移的时候可能有些节点和 master 断开一段时间数据比较旧， 这些节点就不适用于选举为 master， 超过这个时间的就不会被进行故障转移
cluster-migration-barrier 1 #一个主节点拥有的至少正常工作的从节点， 即如果主节点的 slave 节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。
cluster-require-full-coverage no #集群槽位覆盖， 如果一个主库宕机且没有备库就会出现集群槽位不全， 那么 yes 情况下 redis 集群槽位验证不全就不再对外提供服务，而 no 则可以继续使用但是会出现查询数据查不到的情况(因为有数据丢失)。
#Slow log 是 Redis 用来记录查询执行时间的日志系统， slow log 保存在内存里面，读写速度非常快，因此你可以放心地使用它，不必担心因为开启 slow log 而损害 Redis 的速度。
slowlog-log-slower-than 10000 #以微秒为单位的慢日志记录， 为负数会禁用慢日志， 为 0 会记录每个命令操作。
slowlog-max-len 128 #记录多少条慢日志保存在队列，超出后会删除最早的， 以此滚动删除
127.0.0.1:6379> slowlog len
(integer) 14
127.0.0.1:6379> slowlog get
1) 1) (integer) 14
2) (integer) 1544690617
3) (integer) 4
4) 1) "slowlog"
127.0.0.1:6379> SLOWLOG reset
OK
添加一个 key：
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> get key1
"value1"
127.0.0.1:6379> TYPE key1
获取一个 key 的内容：
127.0.0.1:6379> get key1
删除一个 key：
127.0.0.1:6379> DEL key1
(integer) 1
批量设置多个 key：
127.0.0.1:6379> MSET key1 value1 key2 value2
OK
批量获取多个 key：
127.0.0.1:6379> MSET key1 value1 key2 value2
OK
追加数据：
127.0.0.1:6379> APPEND key1 append
(integer) 12
127.0.0.1:6379> get key1
"value1append"
数值递增：
127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> INCR num
(integer) 11
127.0.0.1:6379> get num
"11"
数值递减：
127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> DECR num
(integer) 9
127.0.0.1:6379> get num
"9"
返回字符串 key 长度：
127.0.0.1:6379> STRLEN key1
(integer) 12
列表(list)：
列表是一个双向可读写的管道， 其头部是左侧尾部是右侧，一个列表最多可以包含 2^32-1 个元素即
4294967295 个元素。
生成列表并插入数据：
127.0.0.1:6379> LPUSH list1 jack
(integer) 1
127.0.0.1:6379> TYPE list1
list
向列表追加数据：
127.0.0.1:6379> LPUSH list1 tom
(integer) 2
127.0.0.1:6379> RPUSH list1 jack
(integer) 3
获取列表长度：
127.0.0.1:6379> LLEN list1
(integer) 3
移除列表数据：
127.0.0.1:6379> RPOP list1 #最后一个
"jack"
127.0.0.1:6379> LPOP list1 #第一个
"tom"
集合(set)：
Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。
2.4.3.1：生成集合 key:
127.0.0.1:6379> SADD set1 v1
(integer) 1
127.0.0.1:6379> SADD set2 v2 v4
(integer) 2
127.0.0.1:6379> TYPE set1
set
127.0.0.1:6379> TYPE set2
set
追加数值：
追加的时候不能追加已经存在的数值
127.0.0.1:6379> SADD set1 v2 v3 v4
(integer) 3
127.0.0.1:6379> SADD set1 v2 #没有追加成功
(integer) 0
127.0.0.1:6379> TYPE set1
set
127.0.0.1:6379> TYPE set2
set
查看集合的所有数据：
127.0.0.1:6379> SMEMBERS set1
1) "v4"
2) "v1"
3) "v3"
4) "v2"
127.0.0.1:6379> SMEMBERS set2
1) "v4"
2) "v2"
获取集合的差集：
差集： 已属于 A 而不属于 B 的元素称为 A 与 B 的差（集）
127.0.0.1:6379> SDIFF set1 set2
1) "v1"
2) "v3"
获取集合的交集：
交集： 已属于 A 且属于 B 的元素称为 A 与 B 的交（集）
127.0.0.1:6379> SINTER set1 set2
1) "v4"
2) "v2"
获取集合的并集：
并集：已属于 A 或属于 B 的元素为称为 A 与 B 的并（集）
127.0.0.1:6379> SUNION set1 set2
1) "v2"
2) "v4"
3) "v1"
4) "v3"
sorted set(有序集合):
Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员，不同的是每个元素都会
关联一个 double(双精度浮点型)类型的分数， redis 正是通过分数来为集合中的成员进行从小到大的排
序，序集合的成员是唯一的,但分数(score)却可以重复，集合是通过哈希表实现的，所以添加，删除，
查找的复杂度都是 O(1)， 集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储 40 多亿个成
员)。
生成有序集合：
127.0.0.1:6379> ZADD zset1 1 v1
(integer) 1
127.0.0.1:6379> ZADD zset1 2 v2
(integer) 1
127.0.0.1:6379> ZADD zset1 2 v3
(integer) 1
127.0.0.1:6379> ZADD zset1 3 v4
(integer) 1
127.0.0.1:6379> TYPE zset1
zset
127.0.0.1:6379> TYPE zset2
zset
排行案例：
192.168.7.104:6379> ZADD paihangbang 10 key1 20 key2 30 key3
(integer) 3
192.168.7.104:6379> ZREVRANGE paihangbang 0 -1 withscores
1) "key3"
2) "30"
3) "key2"
4) "20"
5) "key1"
6) "10"
批量添加多个数值：
127.0.0.1:6379> ZADD zset2 1 v1 2 v2 4 v3 5 v5
(integer) 4
获取集合的长度数：
127.0.0.1:6379> ZCARD zset1
(integer) 4
127.0.0.1:6379> ZCARD zset2
(integer) 4
基于索引返回数值：
127.0.0.1:6379> ZRANGE zset1 1 3
1) "v2"
2) "v3"
3) "v4"
127.0.0.1:6379> ZRANGE zset1 0 2
1) "v1"
2) "v2"
3) "v3"
返回某个数值的索引：
127.0.0.1:6379> ZRANK zset1 v2
(integer) 1
127.0.0.1:6379> ZRANK zset1 v3
(integer) 2
哈希(hash)：
hash 是一个 string 类型的 field 和 value 的映射表， hash 特别适合用于存储对象,Redis 中每个 hash 可
以存储 232 - 1 键值对（ 40 多亿）。
生成 hash key：
127.0.0.1:6379> HSET hset1 name tom age 18
(integer) 1
127.0.0.1:6379> TYPE hset1
hash
获取 hash key 字段值：
127.0.0.1:6379> HGET hset1 name
"tom"
127.0.0.1:6379> HGET hset1 age
"18"
删除一个 hash key 的字段：
127.0.0.1:6379> HDEL hset1 age
(integer) 1
获取所有 hash 表中的字段：
127.0.0.1:6379> HSET hset1 name tom age 19
(integer) 1
127.0.0.1:6379> HKEYS hset1
1) "name"
2) "age"
消息队列：
消息队列主要分为两种，分别是生产者消费者模式和发布者订阅者模式，这两种模式 Redis 都支持，生产者消费者模式：
在生产者消费者(Producer/Consumer)模式下， 上层应用接收到的外部请求后开始处理其当前步骤的
操作，在执行完成后将已经完成的操作发送至指定的频道(channel)当中，并由其下层的应用监听该频
道并继续下一步的操作， 如果其处理完成后没有下一步的操作就直接返回数据给外部请求，如果还有下一步的操作就再将任务发布到另外一个频道， 由另外一个消费者继续监听和处理。
模式介绍：
生产者消费者模式下， 多个消费者同时监听一个队里，但是一个消息只能被最先抢到消息的消费者
消费， 即消息任务是一次性读取和处理， 此模式在分布式业务架构中非常常用， 比较常用的软件还有RabbitMQ、 Kafka、 RocketMQ、 ActiveMQ 等
队列介绍：
队列当中的 消息由不同的生产者写入也会有不同的消费者取出进行消费处理，但是一个消息一定是
只能被取出一次也就是被消费一次。
生产者发布消息：
[root@redis-s4 ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK
127.0.0.1:6379> LPUSH channel1 msg1 #从管道的左侧写入
(integer) 1
127.0.0.1:6379> LPUSH channel1 msg2
(integer) 2
127.0.0.1:6379> LPUSH channel1 msg3
(integer) 3
127.0.0.1:6379> LPUSH channel1 msg4
(integer) 4
127.0.0.1:6379> LPUSH channel1 msg5
(integer) 5
查看队列所有消息：
127.0.0.1:6379> LRANGE channel1 0 -1
1) "msg5"
2) "msg4"
3) "msg3"
4) "msg2"
5) "msg1"
消费者消费消息：
127.0.0.1:6379> RPOP channel1 #从管道的右侧消费
"msg1"
127.0.0.1:6379> RPOP channel1
"msg2"
127.0.0.1:6379> RPOP channel1
"msg3"
127.0.0.1:6379> RPOP channel1
"msg4"
127.0.0.1:6379> RPOP channel1
"msg5"
127.0.0.1:6379> RPOP channel1
(nil)
再次验证队列消息：
127.0.0.1:6379> LRANGE channel1 0 -1
(empty list or set) #队列中的消息已经被已全部消费完毕
发布者订阅模式：
模式简介：
在发布者订阅者模式下，发布者将消息发布到指定的 channel 里面， 凡是监听该 channel 的消费者
都会收到同样的一份消息，这种模式类似于是收音机模式，即凡是收听某个频道的听众都会收到主持
人发布的相同的消息内容。
此模式常用语群聊天、 群通知、群公告等场景。
Subscriber：订阅者
Publisher： 发布者
Channel： 频道
订阅者监听频道：
[root@redis-s4 ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK
127.0.0.1:6379> SUBSCRIBE channel1 #订阅者订阅指定的频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1
发布者发布消息：
127.0.0.1:6379> PUBLISH channel1 test1 #发布者发布消息
(integer) 2
127.0.0.1:6379> PUBLISH channel1 test2
(integer) 2
127.0.0.1:6379>
各订阅者验证消息：
订阅多个频道：
> SUBSCRIBE channel1 channel2
订阅指定的多个频道
> SUBSCRIBE channel1 channel2
订阅所有频道：
127.0.0.1:6379> PSUBSCRIBE *
订阅匹配的频道：
> PSUBSCRIBE chann* #匹配订阅多个频道
redis 其他命令：
CONFIG：
config 命令用于查看当前 redis 配置、以及不重启更改 redis 配置等
更改最大内存：
127.0.0.1:6379> CONFIG set maxmemory 8589934592
127.0.0.1:6379> CONFIG get maxmemory
1) "maxmemory"
2) "8589934592"
设置连接密码：
127.0.0.1:6379> CONFIG SET requirepass 123456
永久保存：写入配置文件中redis.conf：
requirepass 123
查看当前配置：
127.0.0.1:6379> CONFIG GET *
info：
显示当前节点 redis 运行状态信息
127.0.0.1:6379> info
SELECT：
切换数据库
127.0.0.1:6379> SELECT 1
127.0.0.1:6379[1]>
keys:
查看当前库下的所有 key：
127.0.0.1:6379>KEYS *
BGSAVE：
手动在后台执行 RDB 持久化操作
127.0.0.1:6379>BGSAVE
DBSIZE：
返回当前库下的所有 key 数量
127.0.0.1:6379>DBSIZE
FLUSHDB：
强制清空当前库中的所有 key
FLUSHALL：
强制清空当前 redis 服务器所有数据库中的所有 key， 即删除所有数据
redis 高可用与集群：
虽然 Redis 可以实现单机的数据持久化， 但无论是 RDB 也好或者 AOF 也好， 都解决不了单点宕机问题，即一旦 redis 服务器本身出现系统故障、硬件故障等问题后， 就会直接造成数据的丢失， 因此需要使用另外的技术来解决单点问题。
配置 reids 主从：
主备模式， 可以实现 Redis 数据的跨主机备份。程序端连接到高可用负载的 VIP， 然后连接到负载服务器设置的 Redis 后端 real server， 此模式不需要在程序里面配置 Redis 服务器的真实 IP 地址， 当后期 Redis 服务器 IP 地址发生变更只需要更改 redis相应的后端 real server 即可， 可避免更改程序中的 IP 地址设置。
Slave 主要配置：
Redis Slave 也要开启持久化并设置和 master 同样的连接密码， 因为后期 slave 会有提升为 master 的可能,Slave 端切换 master 同步后会丢失之前的所有数据。一旦某个 Slave 成为一个 master 的 slave， Redis Slave 服务会清空当前 redis 服务器上的所有数据并将master 的数据导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据。
1、Slave节点配置：
当前状态为 master，需要转换为 slave 角色并指向 master 服务器的 IP+PORT+Password
192.168.7.104:6379> SLAVEOF 192.168.7.103 6379 #指向主节点
192.168.7.104:6379> CONFIG SET masterauth 123456 #配置主节点密码
永久保存：写入配置文件中redis.conf：
slaveof 172.18.0.70 6379
masterauth 123
2、重启Slave即可开始同步
3、查看Slave节点状态：
192.168.7.104:6379> INFO Replication
4、slave 状态只读无法写入数据
5、查看Master日志与Slave
主从复制过程：
Redis 支持主从复制分为全量同步和增量同步， 首次同步是全量同步，主从同步可以让从服务器从
主服务器备份数据，而且从服务器还可与有从服务器，即另外一台 redis 服务器可以从一台从服务器
进行数据同步， redis 的主从同步是非阻塞的，其收到从服务器的 sync(2.8 版本之前是 PSYNC)命令会fork 一个子进程在后台执行 bgsave 命令，并将新写入的数据写入到一个缓冲区里面， bgsave 执行完成之后并生成的将 RDB 文件发送给客户端，客户端将收到后的 RDB 文件载入自己的内存，然后主 redis将缓冲区的内容在全部发送给从 redis，之后的同步从服务器会发送一个 offset 的位置(等同于 MySQL的 binlog 的位置)给主服务器，主服务器检查后位置没有错误将此位置之后的数据包括写在缓冲区的积压数据发送给 redis 从服务器，从服务器将主服务器发送的挤压数据写入内存，这样一次完整的数据同步，再之后再同步的时候从服务器只要发送当前的 offset 位 置给主服务器，然后主服务器根据响应的位置将之后的数据发送给从服务器保存到其内存即可。
Redis 全量复制一般发生在 Slave 初始化阶段，这时 Slave 需要将 Master 上的所有数据都复制一份。具体步骤如下：
1）从服务器连接主服务器，发送 SYNC 命令；
2）主服务器接收到 SYNC 命名后，开始执行 BGSAVE 命令生成 RDB 快照文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器 BGSAVE 执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
7） 后期同步会先发送自己 slave_repl_offset 位置， 只同步新增加的数据， 不再全量同步。
主从同步优化：
Redis 在 2.8 版本之前没有提供增量部分复制的功能， 当网络闪断或者 slave Redis 重启之后会导致主从之间的全量同步，即从 2.8 版本开始增加了部分复制的功能。
repl-diskless-sync yes#yes 为支持 disk， master 将 RDB 文件先保存到磁盘在发送给 slave， no 为 maste直接将 RDB 文件发送给 slave，默认即为使用 no， Master RDB 文件不需要与磁盘交互。
repl-diskless-sync-delay 5 #Master 准备好 RDB 文件后等等待传输时间
repl-ping-slave-period 10 #slave 端向 server 端发送 ping 的时间区间设置，默认为 10 秒
repl-timeout 60 #设置超时时间
repl-disable-tcp-nodelay no #是否启用 TCP_NODELAY， 如设置成 yes，则 redis 会合并小的 TCP 包从而节省带宽，但会增加同步延迟（40ms），造成 master 与 slave 数据不一致，假如设置成 no，则 redis master会立即发送同步数据，没有延迟，前者关注性能，后者关注一致性
repl-backlog-size 1mb #master 的写入数据缓冲区， 用于记录自上一次同步后到下一次同步过程中间的写入命令，计算公式： b repl-backlog-size = 允许从节点最大中断时长 * 主实例 offset 每秒写入量， 比如 master 每秒最大写入 64mb， 最大允许 60 秒，那么就要设置为 64mb*60 秒=3840mb(3.8G)=repl-backlog-ttl 3600 #如果一段时间后没有 slave 连接到 master，则 backlog size 的内存将会被释放。如果值为 0 则表示永远不释放这部份内存。
slave-priority 100 #slave 端的优先级设置，值是一个整数，数字越小表示优先级越高。当 master 故障时将会按照优先级来选择 slave 端进行恢复，如果值设置为 0，则表示该 slave 永远不会被选择。
#min-slaves-to-write 0 #
#min-slaves-max-lag 10 #设置当一个 master 端的可用 slave 少于 N 个，延迟时间大于 M 秒时，不接收写操作。
Master 的重启会导致 master_replid 发生变化， slave 之前的 master_replid 就和 master 不一致从而会引发所有 slave 的全量同步。
slave 切换 master：
停止 slave 同步并查看当前状态：
192.168.7.101:6379> SLAVEOF no one
192.168.7.101:6379> info Replication
测试能否写入数据：
192.168.7.101:6379> set key1 value1
Slave 节点再有 Slave：
常见问题汇总：
master 密码不对：
即配置的 master 密码不对，导致验证不通过而无法建立主从同步关系
Redis 版本不一致：
不同的 redis 版本之间存在兼容性问题， 因此各 master 和 slave 之间必须保持版本一致。
无法远程连接：
在开启了安全模式情况下，没有设置 bind 地址和密码
[root@centos7 ~]# redis-cli -h 192.168.0.1
192.168.0.1:6379>KEYS *
(error) DENIED Redis is running in protected mode because protected mode is enabled, no
bind address was specified, no authentication password
is requested to clients. In this mode connections are only accepted from the loopback
interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:
1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so.Use CONFIG REWRITE to make this change permanent.
2) Alternatively you can just disable the protected mode by editing the Redis configuration
file, and setting the protected mode option to 'no', and then restarting the server.
3) If you started the server manually just for testing, restart it with the '--protected-mode no' option.
4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
redis 集群：
上一个步骤的主从架构无法实现 master 和 slave 角色的自动切换， 即当 master 出现 redis 服务异常、主机断电、磁盘损坏等问题导致 master 无法使用，而 redis 高可用无法实现自故障转移(将 slave 提升为 master)，需要手动改环境配置才能切换到 slave redis 服务器，另外也无法横向扩展 Redis 服务的并行写入性能， 当单台 Redis 服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题， 即： 1.master 和 slave 角色的无缝切换，让业务无感知从而不影响业务使用 2.可以横向动态扩展 Redis 服务器，从而实现多台服务器并行写入以实现更高并发的目的。
Redis 集群实现方式： 客户端分片 代理分片 Redis Cluster
Sentinel(哨兵)：
Sentinel 进程是用于监控 redis 集群中 Master 主服务器工作的状态，在 Master 主服务器发生故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用，其已经被集成在 redis2.6+的版本中， Redis 的哨兵模式到了 2.8 版本之后就稳定了下来。一般在生产环境也建议使用 Redis 的 2.8 版本的以后版本。哨兵(Sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于 Master 主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、 Master、 Slave 定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称： Subjective Down，简称 SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-masterdown-by-addr 命令互相交流之后，得出的 Master Server 下线判断，这种方式就是“客观宕机”，英文名称是： Objectively Down， 简称 ODOWN。通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（ failover）。
Sentinel 机制可以解决 master 和 slave 角色的切换问题
主服务器手动配置 master：
需要手动先指定某一台 Redis 服务器为 master，然后将其他 slave 服务器使用命令配置为 master 服务器的 slave
从服务器 A 配置 slave：
192.168.7.102:6379> REPLICAOF 192.168.7.101 6379 #PEPLICAOF命令不成功则用SLAVEOF替代
192.168.7.102:6379> CONFIG SET masterauth "123456"
从服务器 B 配置 slave：
192.168.7.102:6379> REPLICAOF 192.168.7.101 6379 #PEPLICAOF命令不成功则用SLAVEOF替代
192.168.7.102:6379> CONFIG SET masterauth "123456"
查看各配置状态
192.168.7.102:6379> info
192.168.7.102:6379> info Replication
应用程序如何连接 redis？ ：
java 客户端连接 redis 是通过 jedis 来实现的， java 代码用的时候只要创建 jedis 对象就可以建多个 jedis 连接池来连接 redis， 应用程序再直接调用连接池即可连接 Redis。而 Redis 为了保障高可用,服务一般都是 Sentinel 部署方式， 当 Redis 服务中的主服务挂掉之后,会仲裁出另外一台 Slaves 服务充当 Master。这个时候,我们的应用即使使用了 Jedis 连接池,Master服务挂了,我们的应用奖还是无法连接新的 Master 服务， 为了解决这个问题,Jedis 也提供了相应的Sentinel 实现,能够在 Redis Sentinel 主从切换时候,通知我们的应用,把我们的应用连接到新的Master 服务。Jedis Sentinel 的使用也是十分简单的,只是在 JedisPool 中添加了 Sentinel 和 MasterName 参数， Jedis Sentinel 底层基于 Redis 订阅实现 Redis 主从服务的切换通知， 当 Reids 发生主从切换时， Sentinel 会发送通知主动通知 Jedis 进行连接的切换， JedisSentinelPool 在每次从连接池中获取链接对象的时候,都要对连接对象进行检测,如果此链接和 Sentinel 的 Master 服务连接参数不一致,则会关闭此连接,重新获取新的 Jedis 连接对象。
编辑配置文件 sentinel.conf：
Server1 配置：
哨兵可以不和 Redis 服务器部署在一起
[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 0.0.0.0
port 26379
daemonize yes
pidfile "/usr/local/redis/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel_26379.log"
dir "/usr/local/redis"
sentinel monitor mymaster 192.168.7.101 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000 #(SDOWN)主观下线的时间
sentinel parallel-syncs mymaster 1 #发生故障转移时候同时向新 master 同步数据的 slave 数量， 数字越小总同步时间越长
sentinel failover-timeout mymaster 180000 #所有 slaves 指向新的 master 所需的超时时间
sentinel deny-scripts-reconfig yes
Server2 配置：
[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 192.168.7.102
port 26379
daemonize yes
pidfile "/usr/local/redis/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel_26379.log"
dir "/usr/local/redis"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.7.101 6379 2
sentinel auth-pass mymaster 123456
Server3 配置：
[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 192.168.7.103
port 26379
daemonize yes
pidfile "/usr/local/redis/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel_26379.log"
dir "/usr/local/redis"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.7.101 6379 2
sentinel auth-pass mymaster 123456
启动哨兵：
三台哨兵都要启动
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
当前 sentinel 状态：
尤其是最后一行， 涉及到 master IP 是多少，有几个 slave，有几个 sentinels， 必须是符合全部服务器数量的。
[root@redis-s1 etc]# redis-cli -h 192.168.7.101 -p 26379
192.168.7.101:26379> info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.7.101:6379,slaves=2,sentinels=3
故障转移后的 redis 配置文件：
故障转移后 redis.conf 中的 replicaof 行的 master IP 会被修改， sentinel.conf 中的 sentinel monitor IP 会被修改。
Redis Cluster：
Redis 分布式部署方案：
1) 客户端分区： 由客户端程序决定 key 写分配和写入的 redis node， 但是需要客户端自己处理写入分配、高可用管理和故障转移等
2)代理方案： 基于三方软件实现 redis proxy，客户端先连接之代理层，由代理层实现 key 的写入分
配，对客户端来说是有比较简单，但是对于集群管节点增减相对比较麻烦，而且代理本身也是单点和
性能瓶颈。在哨兵 sentinel 机制中，可以解决 redis 高可用的问题， 即当 master 故障后可以自动将 slave 提升为master 从而可以保证 redis 服务的正常使用，但是无法解决 redis 单机写入的瓶颈问题， 即单机的 redis写入性能受限于单机的内存大小、 并发数量、 网卡速率等因素，因此 redis 官方在 redis 3.0 版本之后推出了无中心架构的 redis cluster 机制， 在无中心的 redis 集群汇中，其每个节点保存当前节点数据和整个集群状态,每个节点都和其他所有节点连接， 特点如下：
1： 所有 Redis 节点使用(PING 机制)互联
2：集群中某个节点的失效， 是整个集群中超过半数的节点监测都失效才算真正的失效
3： 客户端不需要 proxy 即可直接连接 redis， 应用程序需要写全部的 redis 服务器 IP。
4： redis cluster 把所有的 redis node 映射到 0-16383 个槽位(slot)上， 读写需要到指定的 redis node 上进行操作，因此有多少个 reids node 相当于 redis 并发扩展了多少倍。
5： Redis cluster 预先分配 16384 个(slot)槽位，当需要在 redis 集群中写入一个 key -value 的时候，会使用 CRC16(key) mod 16384 之后的值，决定将 key 写入值哪一个槽位从而决定写入哪一个 Redis 节点上， 从而有效解决单机瓶颈。
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
