缓存服务器部署

㈠ Redis分布式缓存搭建

花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。

笔者安装中遇到的一些问题：

如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：

在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable

scl enable devtoolset-9 bash

重新make clean, make

这回编译通过了，提示让你最好make test一下/

执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test

那就升级tcl， yum install tcl

重新make test，如果还有error就删了目录，重新tar包解压重新make , make test

o/ All tests passed without errors! ，表示编译成功。

然后make install即可。

直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf &

redis.conf 配置文件里 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。

redis高可用方案有两种：

常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。

（1）sentinel哨兵

/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &

sentinel2.conf配置：

坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth

当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：

原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf
中配置：

坑2：哨兵配置文件要暴露客户端可以访问到的master地址

在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。

附springboot2.1 redis哨兵配置：

坑3：要注意配置文件.conf会被哨兵修改

redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。

曾经遇到过这样一个问题，大致的信息如下

slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !
最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。

（2）集群

当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 -> 中间件 -> Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。

Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。

每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。

reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。

搭建Redis cluster

redis.conf文件关键的几个配置：

启动6个集群节点

[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]

这时候这6个节点还是独立的，要把他们配置成集群：

说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。

上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。

最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。

查看集群状态：

坑1：暴露给客户端的节点地址不对

使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。

我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 mp.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：

然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！

解决办法，修改每个节点的redis.conf配置文件，找到如下说明：

所以增加配置：

然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）

重新使用Lettuce测试，这次终于连上了！

坑2：Lettuce客户端在master节点故障时没有自动切换到从节点

name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：

重新启动7002进程，

7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。
解决办法，修改Lettuce的配置：

笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。

重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）

Redis不保证数据的强一致性

Redis并不保证数据的强一致性，也就是取CAP定理中的AP

关于一致性Hash算法，可以参考 一致性Hash算法 - (jianshu.com)

Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。

比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。

关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。

与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。

所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。

这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。

Redis高可用方案 - (jianshu.com)

面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent.com)

深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs.com)

Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)

云服务器Redis集群部署及客户端通过公网IP连接问题

㈡ 缓存-redis 三种模式搭建和运行原理

标签： redis 缓存 主从 哨兵 集群

本文简单的介绍redis三种模式在linux的安装部署和数据存储的总结，希望可以相互交流相互提升。

对于Centos7在安装redis之前需要进行一些常用工具的安装：

关闭防火墙

正式安装redis

在redis进行maketest时候会出现一系列的异常，有如下解决方案：

用redis-server启动一下redis，做一些实验没什么意义。

要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动，操作不走如下：

RDB和AOF是redis的一种数据持久化的机制。 持久化 是为了避免系统在发生灾难性的系统故障时导致的系统数据丢失。我们一般会将数据存放在本地磁盘，还会定期的将数据上传到云服务器。
RDB 是redis的snapshotting，通过redis.conf中的save配置进行设置，如 save 60 1000:

AOF 是以appendonly方式进行数据的储存的，开启AOF模式后，所有存进redis内存的数据都会进入os cache中,然后默认1秒执行一次fsync写入追加到appendonly.aof文件中。一般我们配置redis.conf中的一下指令：

AOF和RDB模式我们一般在生产环境都会打开，一般而言，redis服务挂掉后进行重启会优先家在aof中的文件。

当启动一个slave node的时候，它会发送一个PSYNC命令给master node,如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据;否则如果是slave node第一次连接master node，那么会触发一次full resynchronization;
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,但是如果没有找到对应的offset，那么就会执行一次resynchronization。

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了，可以有如下配置：

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

在redis.conf配置文件中，上面的参数代表至少需要3个slaves节点与master节点进行连接，并且master和每个slave的数据同步延迟不能超过10秒。一旦上面的设定没有匹配上，则master不在提供相应的服务。

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为master宕机
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个slave来做切换，这个slave还得得到majority哨兵的授权，才能正式执行切换；

（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致

4.3.2 slave的永久下线

让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行.

redis的集群模式为了解决系统的横向扩展以及海量数据的存储问题，如果你的数据量很大，那么就可以用redis cluster。
redis cluster可以支撑N个redis master,一个master上面可以挂载多个slave，一般情况我门挂载一个到两个slave，master在挂掉以后会主动切换到slave上面，或者当一个master上面的slave都挂掉后，集群会从其他master上面找到冗余的slave挂载到这个master上面，达到了系统的高可用性。

2.1 redis cluster的重要配置

2.2 在三台机器上启动6个redis实例

将上面的配置文件，在/etc/redis下放6个，分别为: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf

每个启动脚本内，都修改对应的端口号

2.3 创建集群

解决办法是 先安装rvm，再把ruby版本提升至2.3.3

使用redis-trib.rb命令创建集群

--replicas: 表示每个master有几个slave

redis-trib.rb check 192.168.31.187:7001 查看状体

3.1 加入新master

以上相同配置完成后，设置启动脚本进行启动；然后用如下命令进行node节点添加：

3.2 reshard一些数据过去

3.3 添加node作为slave

3.4 删除node

㈢ 你了解CDN吗CDN工作原理帮你了解它

网站卡顿，访问量大?站长对于CDN加速肯定已经不陌生了，目前CDN加速的使用率也是越来越高，那么大家在使用CDN加速的同时知道CDN加速的工作原理到底是什么吗?CDN加速究竟是怎么应用于你的网站的呢?

首先来了解一下什么是 CDN?



CDN的全称是(Content Delivery Network)，即内容分发网络。其目的是通过在现有的Internet中增加一层新的CACHE(缓存)层，将网站的内容发布到最接近用户的网络”边缘“的节点，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因，提高用户访问网站的响应速度。

简单的说，CDN的工作原理就是将您源站的资源缓存到位于全球各地的CDN节点上，用户请求资源时，就近返回节点上缓存的资源，而不需要每个用户的请求都回您的源站获取，避免网络拥塞、缓解源站压力，保证用户访问资源的速度和体验.

使用了CDN缓存后的网站的访问过程

1.用户输入访问的域名,操作系统向 LocalDns 查询域名的ip地址.

2.LocalDns向 ROOT DNS 查询域名的授权服务器(这里假设LocalDns缓存过期)

3.ROOT DNS将域名授权dns记录回应给 LocalDns

4.LocalDns得到域名的授权dns记录后,继续向域名授权dns查询域名的ip地址

5.域名授权dns 查询域名记录后(一般是CNAME)，回应给 LocalDns

6.LocalDns 得到域名记录后,向智能调度DNS查询域名的ip地址

7.智能调度DNS 根据一定的算法和策略(比如静态拓扑，容量等),将最适合的CDN节点ip地址回应给 LocalDns

8.LocalDns 将得到的域名ip地址，回应给 用户端

9.用户得到域名ip地址后，访问站点服务器

10.CDN节点服务器应答请求，将内容返回给客户端.(缓存服务器一方面在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成数据服务过程)

为了实现对普通用户透明(使用缓存后用户客户端无需进行任何设置)访问，需要使用DNS(域名解析)来引导用户来访问Cache服务器，以实现透明的加速服务。由于用户访问网站的第一步就是域名解析,所以通过修改dns来引导用户访问是最简单有效的方式。

腾正 科技 15CDN通过多地域分布式部署，全面智能的监控系统及多盾联动混合节点防御技术，毫秒级的防御响应时间，高效彻底解决CC攻击带来的安全和响应速度问题。现在腾正 科技 为了助力大家畅享新年，推出CDN春节特惠活动，20TB流量，10个域名，可使用三个月，价格仅售￥999。

活动详情

CDN畅享新年活动来袭

20TB流量仅￥999 助力更“快”乐!

流量总数：20TB

域名个数：10个

使用时间：3个月

适用场景：适用于门户网站、有官网的电商网站、中小型图片站客户。

活动时间：2020年1月8日-2020年1月31日

㈣ 存根DNS服务器作用是什么，是缓存DNS服务器吗其工作原理的又是如何。

管理存根区域的DNS服务器称为存根DNS服务器。一般情况下，不需要单独部署存根DNS服务器，而是和其他DNS服务器类型合用。在存根DNS服务器和主服务器之间同样存在着区域复制

缓存DNS服务器
缓存DNS服务器即没有管理任何区域的DNS服务器，也不会产生区域复制，它只能缓存DNS名字并且使用缓存的信息来答复DNS客户端的解析请求。当刚安装好DNS服务器时，它就是一个缓存DNS服务器。缓存DNS服务器可以通过缓存减少DNS客户端访问外部DNS服务器的网络流量，并且可以降低DNS客户端解析域名的时间，因此在网络的广泛的使用。例如一个常见的中小型企业网络接入到Internet的环境，并没有在内部网络中使用域名，所以没有架设DNS服务器，客户通过配置使用ISP的DNS服务器来解析Internet域名。此时就可以部署一台缓存DNS服务器，配置将所有其他DNS域转发到ISP的DNS服务器，然后配置客户使用此缓存DNS服务器，从而减少解析客户端请求所需要的时间和客户访问外部DNS服务的网络流量

㈤ 如何部署服务器级别的存储虚拟化

主机级别的方案中通常只是虚拟化直连主机的存储，当然也有一些可以部署在一个SAN环境中的多台存储子系统上。
早先的存储虚拟化产品常用于简化内部磁盘驱动器和服务器外部直连存储的空间分配，以及支持应用集群。Veritas Volume Manager和Foundation Suite就是首批这类解决方案，这类方案使得存储扩展，以及为应用程序和文件服务器提供空间更为简单快速。
随着存储需求的增长远远超过直连存储所能提供的范围，存储虚拟化逐渐成为存储阵列中的一种容量提供方式。而容量持续增长以及诸如iSCSI等小型IT组织负担得起的共享存储技术的出现又使得存储虚拟化技术也融合进基于网络的设备和运行在通用硬件的软件里。
不过现今的服务器和桌面虚拟化技术兴起给存储虚拟化技术带来了新的生机，而基于主机的存储虚拟化技术正在逐渐回归。服务器虚拟化平台必需要基于共享存储体系架构来实现一些关键特性，比如VMware的vMotion和Distributed Resource Schele (DRS)。通过传统的SAN架构自然可以实现这种共享存储体系架构，不过越来越多的IT组织开始寻求更简单的方式来实现共享存储。基于主机的虚拟化技术就是方式之一。
诸如VMware之类的服务器虚拟化供应商认为存储是妨碍虚拟化技术大规模普及的瓶颈之一。这些Hypervisor供应商已经实现了处理器和内存资源的抽象，实现更好的控制并提高资源利用率，他们自然而然也会希望这样控制存储。不过将存储控制功能整合到主机服务器端，称之为“存储Hypervisor”时会带来一些潜在的问题。处理一些在虚拟服务器和虚拟桌面环境中至关重要的存储服务，诸如快照、克隆和自动精简配置时，会严重影响主机服务器的性能。
Virsto的解决方案
Virsto开发出了一款软件解决方案，安装在每台主机服务器上(无论是一台虚拟机或Hypervisor上的过滤驱动器)并在主存储上创建一个虚拟化层，称为Virsto存储池。其同时创建一个高性能磁盘或者固态存储区域，成为“vLog”。读操作会直接指向主存储，不过写操作会通过vLog进行，这会给请求的虚拟机或应用程序发回一个确认。然后vLog将这些写操作异步地分布写入主存储，从而减少对写性能的影响。该存储池可以容纳多至4层的存储方式，包括固态存储和各类型的磁盘驱动器。
和缓存的工作方式类似，vLog通过在存储前端降低耦合度改善了存储性能，降低了后端存储的延迟。其同时将前端主机的随机写操作变为顺序方式，实现后端存储的最佳性能。基于Virsto主机的存储虚拟化软件实现了以上这些功能。
虚拟存储设备
基于主机的存储虚拟化的另一项应用实例是虚拟存储设备(VSA)
VSA是运行在虚拟机上的存储控制器，其虚拟化统一集群中的主机所直接连接的存储。VSA提供一个主机使用的简易的存储共享体系架构，并支持高可用性、虚拟机迁移，并改善存储提供方式。对于很多企业，这种方式可以替代原本需要建立并管理传统SAN或NAS来支持虚拟服务器和桌面的体系架构。
vSphere Storage Appliance。VMware的vSphere Storage Appliance以一个虚拟机的方式运行，从在2个或3个节点集群中，每个ESX/ESXi主机所直连的DAS存储中，创建一个共享存储池。VMware VSA提供每个节点的RAID保护，并在同一集群的各个节点之间提供镜像保护。虽然从技术角度上看，VMware VSA是一个基于文件的体系架构，不过其亦为集群中每台主机提供数据块级别的存储虚拟化，并用户可以从这种部署方式中获取和基于数据块的共享存储一样的收益。
HP的LeftHand Virtual SAN Appliance。虽然和VMware VSA的功能类似，P4000 VSA软件可以支持每台主机直连DAS以外的方式。其还允许使用iSCSI或FC SAN等外部存储来创建共享存储池。这就意味着可以将如何可用的存储，本地存储或用于容灾的异地存储，转变为LeftHand存储节点。P4000t提供快照和自动精简配置，并且支持Hyper-V和VMware。
DataCore的SANsymphony-V。DataCore的解决方案是通过在一个虚拟机中部署其SANsymphony软件来整合其它各个VMware，Hyper-V或XEN主机的直连存储，形成共享存储池。SANsymphony-V可以和HP的解决方案那样虚拟化外部的网络存储，并且该软件可以在迁移到传统的共享存储体系架构时部署在外部服务器上。SANsymphony-V同时提供各类存储服务，譬如快照、自动精简配置、自动化分层和远程复制。
FalconStor的NSS Virtual Appliance。FalconStor的Network Storage Server Virtual Appliance(NSSVA)是该公司NASS硬件产品中唯一支持的VMware版本，用网络上其它主机的直连存储创建一个虚拟存储池。和DataCore和LeftHand的解决方案类似，该存储池可以扩展到网络上任何可用的iSCSI存储上。该NSS Virtual Appliance包括快照、自动精简配置、读/写缓存、远程复制和卷分层等存储功能。
基于主机的存储虚拟化解决方案是目前大多使用在虚拟化服务器和虚拟化桌面环境中，用以实现环境的高可用性特性，以及改善存储性能、利用率和管理效率。

㈥ 秒开缓存服务器4.0版本有几种部署方式

一共三种

1〉旁路(DNS)网络结构如下：