redis集群怎么搭建

介绍安装环境与版本

用两台虚拟机模拟6个节点，一台机器3个节点，创建出3 master、3 salve 环境。

redis 采用 redis-324 版本。

两台虚拟机都是 CentOS ，一台 CentOS65 （IP:19216831245），一台 CentOS7（IP:19216831210） 。

安装过程

1 下载并解压

cd /root/softwarewget http://downloadredisio/releases/redis-324targztar -zxvf redis-324targz

2 编译安装

cd redis-324make && make install3 将 redis-tribrb 复制到 /usr/local/bin 目录下

cd src

cp redis-tribrb /usr/local/bin/4 创建 Redis 节点

首先在 19216831245 机器上 /root/software/redis-324 目录下创建 redis_cluster 目录；

mkdir redis_cluster在 redis_cluster 目录下，创建名为7000、7001、7002的目录，并将 redisconf 拷贝到这三个目录中

mkdir 7000 7001 7002<br>cp redisconf redis_cluster/7000cp redisconf redis_cluster/7001cp redisconf redis_cluster/7002分别修改这三个配置文件，修改如下内容

port 7000 //端口7000,7002,7003

bind 本机ip //默认ip为127001 需要改为其他节点机器可访问的ip 否则创建集群时无法访问对应的端口，无法创建集群

daemonize yes //redis后台运行

pidfile /var/run/redis_7000pid //pidfile文件对应7000,7001,7002

cluster-enabled yes //开启集群 把注释#去掉

cluster-config-file nodes_7000conf //集群的配置 配置文件首次启动自动生成 7000,7001,7002

cluster-node-timeout 15000 //请求超时 默认15秒，可自行设置

appendonly yes //aof日志开启 有需要就开启，它会每次写操作都记录一条日志接着在另外一台机器上（19216831210），的操作重复以上三步，只是把目录改为7003、7004、7005，对应的配置文件也按照这个规则修改即可

5 启动各个节点

第一台机器上执行

redis-server redis_cluster/7000/redisconf

redis-server redis_cluster/7001/redisconf

redis-server redis_cluster/7002/redisconf

另外一台机器上执行

redis-server redis_cluster/7003/redisconf

redis-server redis_cluster/7004/redisconf

redis-server redis_cluster/7005/redisconf6 检查 redis 启动情况

##一台机器<br>ps -ef | grep redis

root 61020 1 0 02:14 00:00:01 redis-server 127001:7000 [cluster]

root 61024 1 0 02:14 00:00:01 redis-server 127001:7001 [cluster]

root 61029 1 0 02:14 00:00:01 redis-server 127001:7002 [cluster]

netstat -tnlp | grep redis

tcp 0 0 127001:17000 0000: LISTEN 61020/redis-server

tcp 0 0 127001:17001 0000: LISTEN 61024/redis-server

tcp 0 0 127001:17002 0000: LISTEN 61029/redis-server

tcp 0 0 127001:7000 0000: LISTEN 61020/redis-server

tcp 0 0 127001:7001 0000: LISTEN 61024/redis-server

tcp 0 0 127001:7002 0000: LISTEN 61029/redis-server12345678910111213

##另外一台机器

ps -ef | grep redis

root 9957 1 0 02:32 00:00:01 redis-server 127001:7003 [cluster]

root 9964 1 0 02:32 00:00:01 redis-server 127001:7004 [cluster]

root 9971 1 0 02:32 00:00:01 redis-server 127001:7005 [cluster]

root 10065 4744 0 02:38 pts/0 00:00:00 grep --color=auto redis

netstat -tlnp | grep redis

tcp 0 0 127001:17003 0000: LISTEN 9957/redis-server 1tcp 0 0 127001:17004 0000: LISTEN 9964/redis-server 1tcp 0 0 127001:17005 0000: LISTEN 9971/redis-server 1tcp 0 0 127001:7003 0000: LISTEN 9957/redis-server 1tcp 0 0 127001:7004 0000: LISTEN 9964/redis-server 1tcp 0 0 127001:7005 0000: LISTEN 9971/redis-server 17创建集群

Redis 官方提供了 redis-tribrb 这个工具，就在解压目录的 src 目录中，第三步中已将它复制到 /usr/local/bin 目录中，可以直接在命令行中使用了。使用下面这个命令即可完成安装。

redis-tribrb create --replicas 1 19216831245:7000 19216831245:7001 19216831245:7002 19216831210:7003 19216831210:7004 19216831210:7005其中，前三个 ip:port 为第一台机器的节点，剩下三个为第二台机器。

等等，出错了。这个工具是用 ruby 实现的，所以需要安装 ruby。安装命令如下：

yum -y install ruby ruby-devel rubygems rpm-buildgem install redis

之后再运行 redis-tribrb 命令，会出现如下提示：

输入 yes 即可，然后出现如下内容，说明安装成功。

8 集群验证

在第一台机器上连接集群的7002端口的节点，在另外一台连接7005节点，连接方式为 redis-cli -h 19216831245 -c -p 7002 ,加参数 -C 可连接到集群，因为上面 redisconf 将 bind 改为了ip地址，所以 -h 参数不可以省略。

在7005节点执行命令 set hello world ，执行结果如下：

然后在另外一台7002端口，查看 key 为 hello 的内容， get hello ，执行结果如下：

说明集群运作正常。

简单说一下原理

redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。所以我们在测试的时候看到set 和 get 的时候，直接跳转到了7000端口的节点。

Redis 集群会把数据存在一个 master 节点，然后在这个 master 和其对应的salve 之间进行数据同步。当读取数据时，也根据一致性哈希算法到对应的 master 节点获取数据。只有当一个master 挂掉之后，才会启动一个对应的 salve 节点，充当 master 。

需要注意的是：必须要3个或以上的主节点，否则在创建集群时会失败，并且当存活的主节点数小于总节点数的一半时，整个集群就无法提供服务了。

更多Redis相关技术文章，请访问Redis教程栏目进行学习！

转至： https://wwwcnblogscom/ITtangtang/p/7967386html

每个Spark executor作为一个YARN容器(container)运行。Spark可以使得多个Tasks在同一个容器(container)里面运行

1 Spark支持资源动态共享，运行于Yarn的框架都共享一个集中配置好的资源池

2 可以很方便的利用Yarn的资源调度特性来做分类、隔离以及优先级控制负载，拥有更灵活的调度策略

3 Yarn可以自由地选择executor数量

4 Yarn是唯一支持Spark安全的集群管理器，使用Yarn，Spark可以运行于Kerberized Hadoop之上，在它们进程之间进行安全认证

我们知道Spark on yarn有两种模式：yarn-cluster和yarn-client。这两种模式作业虽然都是在yarn上面运行，但是其中的运行方式很不一样，今天就来谈谈Spark on YARN yarn-client模式作业从提交到运行的过程剖析

Spark运行模式：

在Yarn-client中，Driver运行在Client上，通过ApplicationMaster向RM获取资源。本地Driver负责与所有的executor container进行交互，并将最后的结果汇总。结束掉终端，相当于kill掉这个spark应用。

因为Driver在客户端，所以可以通过webUI访问Driver的状态，默认是 http://hadoop1:4040 访问，而YARN通过http:// hadoop1:8088访问

因为是与Client端通信，所以Client不能关闭。

客户端的Driver将应用提交给Yarn后，Yarn会先后启动ApplicationMaster和executor，另外ApplicationMaster和executor都 是装载在container里运行，container默认的内存是1G，ApplicationMaster分配的内存是driver- memory，executor分配的内存是executor-memory。同时，因为Driver在客户端，所以程序的运行结果可以在客户端显 示，Driver以进程名为SparkSubmit的形式存在。

应用的运行结果不能在客户端显示（可以在history server中查看），所以最好将结果保存在HDFS而非stdout输出，客户端的终端显示的是作为YARN的job的简单运行状况，下图是yarn-cluster模式

[上传失败(image-107978-1592274191581)]

执行过程：

比以前的更多的理解：

（1）Application Master所在的NodeManager是Yarn随机分配的，不是在主节点上，下图是实验室集群上跑得一个Spark程序，tseg0是主节点，tseg1~tseg4是workers，IP1010324029指的是tseg3:

（2）在上图还可以看出，executor的容器和AM容器是可以共存的，它们的封装都是容器；

（3）AM是Yarn启动的第一个容器；

（4）AM所在的NodeManager就是平常说的Driver端，因为这个AM启动了SparkContext，之前实验室说的“谁初始化的SparkContext谁就是Driver端”一直理解错了，以为这句话是相对于机器说的，但其实是相对于Cluster和Client的集群模式来说的（不知道其他模式Mesos、standalone是不是也是这样）。

（5）在Application提交到RM上之后，Client就可以关闭了，集群会继续运行提交的程序，在实际使用时，有时候会看到这样一种现象，关闭Client会导致程序终止，其实这个Application还没有提交上去，关闭Client打断了提交的过程，Application当然不会运行。

（1）YarnCluster的Driver是在集群的某一台NM上，但是Yarn-Client就是在RM的机器上；

（2）而Driver会和Executors进行通信，所以Yarn_cluster在提交App之后可以关闭Client，而Yarn-Client不可以；

（3）Yarn-Cluster适合生产环境，Yarn-Client适合交互和调试。

下表是Spark Standalone与Spark On Yarn模式下的比较

IBGP水平分割，从IBGP邻居学到的路由不会再通告给其他的IBGP邻居；

在一个大型的AS当中收到IBGP水平分割的影响，出现了BGP路由无法通过IBGP邻居接收的问题，解决办法有三种：

1、全互连的IBGP邻居

2、路由反射器RR

3、BGP联盟

一、全互连的IBGP邻居

建立全互连的IBGP邻居将会需要更多的资源，每建立一个BGP邻居就需要一个TCP连接，这样会极大地消耗CPU资源，TCP连接数计算公式：n(n-1)/2;

在大型的BGP网络中，一般不采用全连接方式，通常会采用路由反射器RR和联盟来解决

二、路由反射器RR

多台路由器只与一台中心路由器建立邻居关系，不需要全互连的邻居，这台中心路由器允许从IBGP邻居学来的路由被反射出去，打破了IBGP水平分割限制的中心路由器就是路由反射器RR；

1、路由反射器RR的几种角色：

（1）路由反射器route reflector

允许把从IBGP邻居学到的路由反射给其他IBGP邻居的BGP设备；

（2）客户机client

与RR形成反射邻居关系的IBGP设备，由RR决定哪台设备作为客户机；

（3）非客户机non-client

既不是RR也不是客户机的IBGP设备；

在AS内部所有的非客户机与RR必须建立全互连的IBGP邻居；

（4）始发者Originator

在AS内部始发路由的设备，Originator-ID属性用于防止集群内产生路由环路；

（5）集群Cluster

路由反射器及其客户机集合，Cluster-List属性用于防止集群间产生路由环路；

2、路由反射原理

同一集群内的客户机只需要与该集群的RR交换路由信息，所以客户机只需要与RR之间建立IBGP连接，不需要与其他客户机建立IBGP连接，从而减少IBGP连接数量；

RR打破了IBGP水平分割的限制，并采用Originator-ID属性和Cluster-List属性防止路由环路；

RR向IBGP邻居发布路由规则：

（1）从非客户机学来的路由，反射给所有的客户机；

（2）从客户机学来的路由，反射给其他所有的客户机和非客户机；

（3）从EBGP学来的路由，反射给所有的客户机和非客户机；

3、Originator-ID属性和Cluster-List属性

当网络中只部署一台RR时，如果该RR设备发生故障，将会导致其他所有的路由器无法收到路由，因此部署多台RR可以提供更好的冗余；

在一个AS内部署了两台RR设备，都能够用于路由的反射，其他设备同时与两台RR建立IBGP邻居关系，及时一台出现故障，另外一台也可以工作；

但是部署过多的RR以及复杂的拓扑也可能带来环路的隐患，AS-Path无法检测到AS内的环路，因此在部署路由反射器时，BGP提供了两种属性，用于检测AS内的环路问题，分别是Originator-ID和Cluster-List属性，这两个属性仅存在当RR将从IBGP邻居收到的路由向另一个IBGP邻居通告时，用于防止环路而添加的仅在AS内起作用的属性，这两个属性不会出现在AS外；

（1）Originator-ID：可选非过渡属性，RR反射路由时，为该路由添加Originator-ID属性（内容是路由始发者客户机的RouterID），用于防止集群内路由环路；

集群内环路现象：

一个集群中部署两个RR（两个RR使用相同的Cluster-ID），每个RR和集群中每个客户机建立IBGP邻居关系，两个RR之间建立IBGP邻居关系（如果存在EBGP邻居的话需要建立IBGP邻居关系）；

客户机Client1通告一条路由给RR1，RR1将该路由反射给RR2，RR2继续反射该路由给客户机Clent1，路由回到始发路由器，Client1如果使用该路由则环路产生；

在反射集群内使用Originator-ID属性解决环路过程如下：

客户机Client1通告一条路由给RR1;

RR1反射该路由时为该路由添加Originator-ID属性，内容是路由始发者客户机Client1的RouterID,然后反射给RR2；

RR2反射该路由时，发现路由已经携带Originator-ID属性，继续反射给客户机Client1；

客户机Client1收到该路由后，发现路由携带OriginatorID属性且与自身RouterID一致，丢弃该路由；

说明：此场景仅用于阐述Originator-ID原理，实际上RR1反射路由给RR2时，除了添加Originator-ID属性外，还添加了Cluster-List属性，RR2发现路由携带Cluster-List属性且包含自身Cluster-ID（两个RR属于同一集群，Cluster-ID相同），就会丢弃该路由；

（2）Cluster-List：可选非过渡属性，RR使用该属性记录路由经过每个集群的Cluster-ID，用来在集群间避免环路；

AS内的每个集群都由唯一的Cluster-ID来标识，默认为BGP的RouterID，可以使用命令Cluster-ID来修改；

当一条路由被RR反射的时候，RR会把本地Cluster-ID添加到Cluster-List的前面；

当RR接收到一条路由时，会检查Cluster-List，如果Cluster-List中已经有本地Cluster-ID，丢弃该路由，否则把本地Cluster-ID添加到Cluster-List的前面，然后反射出去；

集群间环路现象：

RR1、RR2、RR3是三个反射集群中的路由反射器，假设任意两个RR都是另一个RR的客户机，并部署全互连的IBGP邻居关系；

客户机Client1通告一条路由给RR1，RR1反射给RR2，RR2反射给RR3，RR3重新将该路由反射给RR1，一旦RR1接收并使用该路由则产生环路；

在反射集群之间使用Cluster-List属性解决花露过程如下：

客户机Client1将一条路由通告给RR1；

RR1收到该路由发现没携带Cluster-List属性，为路由添加Cluster-List属性并把自身集群Cluster-ID添加进去，然后反射出去；

RR2收到该路由发现携带Cluster-List属性，不包含自身集群Cluster-ID，把自身集群Cluster-ID添加进去，然后反射出去；

RR3收到该路由发现携带Cluster-List属性，不包含自身集群Cluster-ID，把自身集群Cluster-ID添加进去，然后反射出去；

RR1收到该路由发现携带Cluster-List属性，包含自身集群Cluster-ID，丢弃该路由；

4、路由反射器的设计部署

（1）备份路由反射器方案

为增加网络的可靠性，避免单点故障，需要在一个集群中配置一个以上的RR，同一集群中的所有RR必须使用相同的Cluster-ID；

路由反射器RR1和RR2在同一个集群内，配置了相同的Cluster-ID；

客户机Client和相同Cluster-ID的RR都建立IBGP邻居关系，RR之间建立IBGP邻居关系；

客户机Client学到EBGP路由后，同时向RR1和RR2通告这条路由；

RR1和RR2收到该路由后，将本地Cluster-ID添加到Cluster-List前面，然后向其他客户机反射，同时相互反射；

RR1和RR2收到该反射路由后，检查Cluster-List发现包含自身的Cluster-ID，丢弃该路由，能避免同集群内路由反射器间互相学习源自同一客户机的路由，节省内存空间；

由于集群内RR之间不互相学习Client的路由，所以如果RR上没有EBGP邻居关系，则RR间可以没有IBGP邻居关系；

（2）同级路由反射器方案

一个骨干网被分成多个集群，各集群的RR之间互为非客户机关系，建立IBGP全连接；

每个客户机只与所在集群的RR建立IBGP连接，所有RR和客户机都能收到全部路由信息；

（3）分层路由反射器方案

一个AS内可以存在多个集群，各个集群的RR之间建立IBGP邻居；

当RR所处的网络层不同时，可以将较低网络层次的RR配成客户机，形成分级RR；

每个路由反射器既可以作为该集群的反射器角色，也可作为其他集群的客户机角色；

三、BGP联盟

1、联盟概念

在一个AS中，受IBGP水平分割的影响，如果IBGP会话数量较多，管理起来将会显得麻烦，为了解决该问题，除了使用路由反射器外，还可以使用BGP联盟Confederation；

联盟的概念就是将一个AS划分为若干个子AS，每个子AS内部建立IBGP全连接关系（联盟IBGP邻居），子AS之间建立EBGP连接关系（联盟EBGP邻居），但联盟外部AS仍认为联盟是一个AS；

AS100被分成三个子AS（65001、65002、65003），使用AS100作为联盟ID，此时不需要采用IBGP全互连，连接数从10条减少到4条，如果没有配置联盟，AS100内部都是IBGP邻居，配置联盟以后形成了联盟EBGP邻居和联盟IBGP邻居，在联盟子AS内部可以使用全互连或RR，而在联盟子AS之间使用联盟AS-Path来避免环路；

2、联盟的特点

配置联盟后，原AS号将作为每个路由器的联盟ID；

通告给联盟内的路由，MED属性在整个联盟范围内保留；

Local Preference属性在整个联盟范围内保留，而不只是在通告的成员AS内；

在联盟内保留联盟外部的next-hop属性；

在联盟内将子AS号加入AS-Path中，但不会将联盟内子AS号通告到联盟之外；

联盟内的子AS号在AS-Path属性中用单独的两种类型AS-CONFED-SEQUENCE和AS-CONFED-SET表示，默认联盟将子AS号以AS-CONFED-SEQUENCE的形式在AS-Path中列出，如果在联盟内配置了聚合，AS号将以AS-CONFED-SET形式列出；

AS-Path中的联盟子AS号用于避免环路，不计算在AS-Path长度中；

联盟EBGP邻居和联盟IBGP邻居都被看作IBGP类型邻居，不存在联盟EBGP路由优于联盟IBGP路由，即在其他条件相同的情况下，同时从EBGP邻居学到、联盟EBGP或联盟IBGP学到同一条路由，从EBGP邻居学到的路由更优；

联盟内相关属性传出联盟时将会自动删除，不用配置策略过滤子AS号等信息；

3、联盟配置举例

R1为AS100，R2/R3/R4拥有联盟ID为200，R2和R3在联盟子AS65001中，R4属于联盟子AS65002，R5属于AS300；

通过命令confederation id配置BGP联盟，指定联盟ID；

通过命令confederation peer-as指定联盟内子AS号；

R2配置：

bgp 65001

confederation id 200

peer 12111 as-number 100

peer 23113 as-number 65001

R3配置：

bgp 65001

confederation id 200

peer 23112 as-number 65001

confederation peer-as 65002

peer 34114 as-number 65002