Windows10如何架设局域网DNS服务器？

1、 安装DNS服务

开始—〉设置—〉控制面板—〉添加/删除程序—〉添加/删除Windows组件—〉“网络服务”—〉选择“域名服务系统（DNS）”—〉按确定进行安装

2、 创建DNS正相解析区域

开始—〉程序—〉管理工具—〉选择DNS，打开DNS控制台—〉右击“正相搜索区域”—〉选择“新建区域”—〉选择“标准主要区域”（或“Active Directory 集成区域”或“标准辅助区域”）--〉输入域名“abc.com” —〉输入要保存的区域的文件名“abc.com.dns”— 〉按完成，完成创建

创建主机记录等：

右击“abc.com”—〉“新建主机” —〉在名称处输入“www”，在“IP地址”处输入“192.168.0.3”，—〉按“添加主机”完成

3、 创建DNS反向解析区域

开始—〉程序—〉管理工具—〉选择DNS，打开DNS控制台—〉右击“反向搜索区域”—〉选择“新建区域”—〉选择“标准主要区域”—〉输入用来标示区域的“网络ID”—〉输入要保存的区域的文件名“0.168.192.in-addr.arpa.dns”—〉按完成，完成创建

创建指针PTR：

右击“192.168.1.x.subnet”—〉选择“新建指针”—〉在“主机IP号”中输入2—〉在“主机名”中输入ftp—按 “确定”完成添加

4、 启用DNS循环复用功能

如www.abc.com对应于多个IP地址时DNS每次解析的顺序都不同

右击选择“DNS服务器”—〉属性—〉高级—〉选择“启用循环”（round robin）--〉选择“启用netmask 排序”—〉按“ 确定”返回

注：如所有的IP和域名服务器在同一子网时需要取消“启用netmask排序”，才能实现循环复用功能。即启用循环时 ，当主机的IP和dns在同一个子网时将始终排在最前面，当都在一个子网时就不进行循环，只有去除了“启用netmask排序” 时才能实现循环复用。

DNS服务器会优先把与自己的网络ID相同的记录返回给客户端

5、 创建标准辅助区域，实现DNS区域复制

在另一台DNS服务器上，右击“正向搜索区域”—〉选择“新建区域”—〉选择“标准辅助区域”—〉输入“abc.com”—〉输入主域名服务器的IP地址—〉选择“完成”

可手工要求同步：

在辅域名服务器上右击“abc.com”的域—〉选择“从主服务器传输”

并且可以设置允许传输的域名服务器：

在主域名服务器上右击“abc.com”的域—〉选择“属性”—〉选择“区域复制”—〉在“允许复制”前打勾，并选择允许复制的主机（到所有服务器、只有在“名称服务器”选项卡中列出的服务器、只允许到下列服务器）

完成服务器类型的转换：

右击区域—〉选择 “属性”—〉选择“类型”的“更改”按钮—〉选择要更改的区域类 型—〉按“确定”

6、 实现DNS唯高速缓存服务器

创建一个没有任何区域的DNS服务器—〉右击DNS服务器—〉选择“属性”—〉选择“转 发器”中的“启用转发器”—〉输入转发器的IP地址—〉按“确定”完成

清除“唯高速缓存”中的cache内容：

右击“DNS服务器”—〉选择“清除缓存”

或者选择“DNS服务器”—〉在菜单中选择“查看”，高级—〉右击“缓存的查找”—〉选择“清除缓存”

（客户端清空DNS缓存—）ipconfig /flushdns）

7、 DNS的委派（子域的转向）

在原域名服务器上建立“subdomain.abc.com”的主机—〉右击abc.com的域，选择“新建委派”—〉将subdomain.abc.com的域代理给subdomain.abc.com的主机—〉在subdomain.abc.com上建立“正向标准区域”subdomain.abc.com—〉添加相关主机记录

8、 设置 DNS区域的动态更新

右击选择DNS上区域—〉选择“属性”—〉选择“常规”中的“允许动态更新”，选是— 〉然后按 “确定”—〉在本机的DHCP服务器中—〉右击选择DHCP服务器—〉选择“属性”—〉选择“DNS”—〉选择“为不支持动态更新的DNS客户启用更新”—〉在客户端使用ipconfig /registerdns来更新域名的注册信息

注意客户端需要将完整的计算机名改成myhost.abc.com

9、 配置DNS客户端

在客户端计算机上打开tcp/ip属性对话框，在dns服务器地址栏输入dns服务器的ip地址

手工配置最多可配置12个 DNS服务器 .

CDN的全称是Content Delivery Network，即分发网络。基本原理是采用各种缓存服务器，内将这些缓存服务器分布容到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

办理CDN许可证的材料：

1、营业执照副本；

2、法人及股东身份证；

3、公司章程；

4、公司主要管理人员及技术人员身份证；

5、社保证明。

哪些业务需要办CDN许可证？

根据规定：企业从事为为视频网站、门户网站、个人网站、购物网站、企事业单位网站或数据提供网络加速服务的，均需要办理内容分发网络（CDN）许可证。

具体办理事宜可以向有经验的代理公司像是阿里云等详细咨询了解，也可以委托其代理。

CDN的功能特点：

(1)节省骨干网带宽，减少带宽需求量；

(2)提供服务器端加速，解决由于用户访问量大造成的服务器过载问题；

(3)服务商能使用Web Cache技术在本地缓存用户访问过的Web页面和对象，实现相同对象的访问无须占用主干的出口带宽，并提高用户访问因特网页面的相应时间的需求；

(4)能克服网站分布不均的问题，并且能降低网站自身建设和维护成本；

(5)降低“通信风暴”的影响，提高网络访问的稳定性

花了两天时间整理了之前记录的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 这些节点配置文件，删除持久化文件 dump.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连接问题

---