企业级分布式集群实战----------------Redis的基本介绍和主从复制以及高可用
企业级分布式集群----------------Redis的基本介绍和主从复制以及高可用
一、Redis的基本介绍
1.为什么要学习Redis呢？
传统的关系型数据库如Mysql已经不能适用所有应用场景，例如算双十一秒杀的库存扣减，APP首页的访问流量高峰等等，都很容易把数据库打崩，所以引入了缓存中间件，目前市面上比较常用的缓存中间件有 Redis 和 Memcached 。不过综合考虑他们的优缺点后，Redis也成了各大公司的专宠，面试中也是常客，那我们来简单认识一下redis。
2.什么是Redis？
Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。
另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
3.Redis相比memcached有哪些优势？
- memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
- redis的速度比memcached快很多
- redis可以持久化其数据
- Redis支持数据的备份，即master-slave模式的数据备份。
- 使用底层模型不同：它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
- value大小：redis最大可以达到1GB，而memcache只有1MB
4.Redis有哪些数据结构？
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet、
HyperLogLog、Geo、Pub/Sub、Redis Module（BloomFilter，RedisSearch，Redis-ML）
5.为什么Redis是单线程的？
-
官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）。
-
性能指标
关于redis的性能，官方网站也有，普通笔记本可以轻松处理每秒几十万的请求。 -
详细原因
1.不需要各种锁的性能消耗
Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。
总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
2.单线程多进程集群方案
单线程的威力实际上非常强大，每核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。
所以单线程、多进程的集群不失为一个时髦的解决方案。
3.CPU消耗
采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。
但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？
可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。
6.使用Redis有哪些好处？
- 速度快：因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
- 支持丰富数据类型：支持string，list，set，sorted set，hash
- 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
- 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
7.Redis有哪些适合的场景？
1. 会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
2. 全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
3. 队列Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。
4. 排行榜/计数器Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：ZRANGE user_scores 0 10 WITHSCORESAgora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。
5. 发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！
二、Redis的主从复制
1.部署redis
1. redis安装：
tar zxf redis-5.0.3.tar.gz
cd redis-5.0.3
yum install gcc -y
make
make install
2.执行redis安装脚本：
cd utils/
./install_server.sh #一路回车
netstat -antlp
3. 修改端口使其他主机可访问：
vim /etc/redis/6379.conf
70 bind 0.0.0.0
/etc/init.d/redis_6379 restart #重启redis
netstat -antlp
测试redis
在server1添加key-value值：
redis-cli
127.0.0.1:6379> set name junjun
OK
127.0.0.1:6379> get name
"junjun"
2.实现redis的主从复制
实验环境：server1—master，server2—slave
在server2中：
1. 在server2中安装redis：
scp redis-5.0.3 server2:/root #在server1中把解压好的目录发给server2
make install
2. 执行redis安装脚本：
cd utils/
./install_server.sh
netstat -antlp
3. 修改配置文件：
vim /etc/redis/6379.conf
70 bind 0.0.0.0
1379 slaveof 192.168.43.71 6379
/etc/init.d/redis_6379 restart #重启redis
netstat -antlp
配置完成！！！
测试：
在server2查看：
[root@server2 utils]# redis-cli
127.0.0.1:6379> get name #可以看到刚在server1中添加的信息
"junjun"
127.0.0.1:6379> set name xiaoxu #无法添加信息
(error) READONLY You can't write against a read only replica.
127.0.0.1:6379>
三、redis高可用
首先配置好server1和server3之间的主从复制：（和server2相同）
server1—master
server3—slave
在server3中：
1. 在server3中安装redis：
scp redis-5.0.3 server3:/root #在server1中把解压好的目录发给server3
make install
2. 执行redis安装脚本：
cd utils/
./install_server.sh
netstat -antlp
3 修改配置文件：
vim /etc/redis/6379.conf
70 bind 0.0.0.0
1379 slaveof 192.168.43.71 6379
/etc/init.d/redis_6379 restart #重启redis
netstat -antlp
测试：
这样三台redis的主从复制就实现了！！！！！！！！！！
哨兵模式的相关介绍
1. sentinel哨兵模式介绍
（1）Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，
以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，
自动将下线主服务器属下的某个从服务器升级为新的主服务器。
（2）Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，
sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，
sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；
当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。
（3）sentinel可让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，
集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。
2. sentinel哨兵模式的结构
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案
假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换
而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换
Sentinel由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器
并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器
在server1掉线后
升级server2为新的主服务器
3.哨兵模式的其他知识
（1）Sentinel状态持久化
snetinel的状态会被持久化地写入sentinel的配置文件中。
每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。
这意味着，可以安全的停止和重启sentinel进程。
（2）Sentinel作用
Master状态检测
如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。
Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，
即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
（3）Sentinel工作方式（每个Sentinel实例都执行的定时任务）
1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
2）如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值，
则这个实例会被Sentinel标记为主观下线。
3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4）当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，
则Master会被标记为客观下线。
5）在一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
6）当Master被Sentinel标记为客观下线时，Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
7）若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。
若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。
（4）三个定时任务
sentinel在内部有3个定时任务
1）每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：
a）发现slave节点
b）确认主从关系
2）每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。
sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。
3）每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。
（5）主观下线
所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，
即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。
主观下线就是说如果服务器在down-after-milliseconds给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复，
或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（SDOWN ）。
sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，
通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，
如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。
（6）客观下线
客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，
并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启failover。
客观下线就是说只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（ODOWN）。
只有当master被认定为客观下线时，才会发生故障迁移。
当sentinel监视的某个服务主观下线后，sentinel会询问其它监视该服务的sentinel，看它们是否也认为该服务主观下线，
接收到足够数量（这个值可以配置）的sentinel判断为主观下线，既任务该服务客观下线，并对其做故障转移操作。
sentinel通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务id，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。
一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该服务时候在该sentinel主观下线，
并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。
sentinel接收到回复后，根据配置设置的下线最小数量，达到这个值，既认为该服务客观下线。
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。
（7）在redis-sentinel的conf文件里有这么两个配置
1）sentinel monitor
四个参数含义：
masterName这个是对某个master+slave组合的一个区分标识（一套sentinel是可以监听多套master+slave这样的组合的）。
ip 和 port 就是master节点的 ip 和 端口号。
quorum这个参数是进行客观下线的一个依据，意思是至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
2）sentinel down-after-milliseconds
这个配置其实就是进行主观下线的一个依据，masterName这个参数不用说了，timeout是一个毫秒值，
表示：如果这台sentinel超过timeout这个时间都无法连通master包括slave（slave不需要客观下线，因为不需要故障转移）的话，
就会主观认为该master已经下线（实际下线需要客观下线的判断通过才会下线）
那么，多个sentinel之间是如何达到共识的呢？
这就是依赖于前面说的第二个定时任务，某个sentinel先将master节点进行一个主观下线，然后会将这个判定通过sentinel is-master-down-by-addr这个命令问对应的节点是否也同样认为该addr的master节点要做客观下线。最后当达成这一共识的sentinel个数达到前面说的quorum设置的这个值时，就会对该master节点下线进行故障转移。quorum的值一般设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。
（8）主观下线（SDOWN）和客观下线（ODOWN）的更多细节
sentinel对于不可用有两种不同的看法，一个叫主观不可用(SDOWN),另外一个叫客观不可用(ODOWN)。
SDOWN是sentinel自己主观上检测到的关于master的状态，
ODOWN需要一定数量的sentinel达成一致意见才能认为一个master客观上已经宕掉，
各个sentinel之间通过命令SENTINEL is_master_down_by_addr来获得其它sentinel对master的检测结果。
从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
这个时间在配置中通过is-master-down-after-milliseconds参数配置。
4.Redis Sentinel的主从切换方案
Redis 2.8版开始正式提供名为Sentinel的主从切换方案，通俗的来讲，
Sentinel可以用来管理多个Redis服务器实例，可以实现一个功能上实现HA的集群，Sentinel主要负责三个方面的任务：
1）监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2）提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3）自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
哨兵模式具体的实现过程如下：
上面我们已经实现了三台redis的主从复制了
第一步：在master（server1中）中写入切换策略：
cd redis-5.0.3
ls
cp sentinel.conf /etc/redis
cd /etc/redis/
编辑哨兵模式的配置文件sentinel.conf
vim sentinel.conf
修改如下内容：
17 protected-mode no #打开17行，表示关闭保护模式
84 sentinel monitor mymaster 192.168.43.71 6379 2
#指定要监控的master，mymaster是定义的master名字，quorum为法定票数2，此处指的是sentinel的数， 只有指定的sentinel同意时才认为sentinel做的决策是有效的，一般大于sentinel数量的半数。可以有多个master，一组sentinel集群可以监控N个主从复制架构
113 sentinel down-after-milliseconds mymaster 10000
#至少多长时间连不上才认为master离线了。单位为ms，即连接超时时长（这里我设置为10秒）
第二步：在修改完成后，发送给两个slave节点：
scp sentinel.conf server2:/etc/redis
scp sentinel.conf server3:/etc/redis
在server1上开启sentinel进程
在server2上开启sentinel进程
在server3上开启sentinel进程
可以看到，此时的master节点是正常工作的，三个节点都很正常！！！！！
接下来模拟哨兵模式
用真机再开启一台shell连接server1
使用命令查看此时的master节点和slave节点的信息
down掉server1的redis服务
查看进程，可以看到server1的redis-server进程已经关闭
但是server1的redis-sentinel进程依然正常运行，可以参加选举
在server2和server3上都可以看到将master由server1切换为server2
在server1上使用命令远程登陆redis集群中的server2，可以看到server2是master，server3是slave
此时server2为master节点，所以可以添加信息
在server1中编辑redis的配置文件，发现配置文件已经恢复为原来默认的样子
然后我们再次设置server1作为slave节点，它的master节点是server2
重启server1上的redis服务，查看进程，已经恢复好了
注意：
这里为什么要我们手动去把server1变为slave，而不是选举完之后直接将master置为slave？
因为server1原来是master，上面会有重要的数据，而且它的slave节点server2和server3上的数据有可能不完全和server1同步
如果这个时候直接将server1置为slave的话，它会以新的master节点作为参考，丢弃原来的所有数据
这时候就有可能造成严重的数据丢失
总结来说，故障转移分为三个步骤：
1）从下线的主服务的所有从服务里面挑选一个从服务，将其转成主服务
sentinel状态数据结构中保存了主服务的所有从服务信息，领头sentinel按照如下的规则从从服务列表中挑选出新的主服务；
删除列表中处于下线状态的从服务；删除最近5秒没有回复过领头sentinel info信息的从服务；
删除与已下线的主服务断开连接时间超过 down-after-milliseconds*10毫秒的从服务，
这样就能保留从的数据比较新（没有过早的与主断开连接）；
领头sentinel从剩下的从列表中选择优先级高的，如果优先级一样，选择偏移量最大的（偏移量大说明复制的数据比较新），
如果偏移量一样，选择运行id最小的从服务。
2）已下线主服务的所有从服务改为复制新的主服务
挑选出新的主服务之后，领头sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新master。
3）将已下线的主服务设置成新的主服务的从服务，当其回复正常时，复制新的主服务，变成新的主服务的从服务
同理，当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从。
温馨提示：还可以向任意sentinel发生sentinel failover 进行手动故障转移，这样就不需要经过上述主客观和选举的过程。