【redis篇】redis的单节点/集群方式搭建及说明

第一部分:安装

1.单节点搭建

1.安装版本 redis-2.8.18.tar.gz

2.解压

tar xf xxx

3.下载gcc，tcl 命令编译器 yum -y install gcc tcl (命令名字别写错)

4.编译、创建目录、拷贝make && make PREFIX=/opt/jw/redis install

5.配置环变： EXPORT REDIS_PREFIX=/opt/jw/redis

6.重新加载配置文件: . /etc/profile

7.测试 re+tab

8.utils 目录，服务脚本安装：./install_server.sh

9.端口、实例、配置文件、日志、持久化数据目录、执行路径配置（安装过程的选择项，直接enter到底就行）

10.enter执行 、ctrl+c退出（9中已说明，勿退出！）

11.启动客户端：redis -cli （6379） // 默认6379 不用输入

帮助： 直接输入 help

12.使用帮助：

utils目录下： redis-cli -h

redis-server -h

2.伪分布式搭建

1.创建redis目录： mkdir redis

2.在redis目录下分别创建3个端口目录： 6380,6381,6382

（不在配置文件中写他的目录指定关系，直接在当前目录下执行，持久化目录）

3.当前目录下分别启动３个实例：

redis-server --port 6380

redis-server --port 6381 --slaveof 127.0.0.1 6380

redis-server --port 6382 --slaveof 127.0.0.1 6380

4.主从演示 crud权限，高可用

演示如下：

启动6380端口主服务：

redis-server --port 6380

启动6381端口从节点服务：

redis-server --port 6381 --slaveof 127.0.0.1 6380

启动6382从节点服务：

redis-server --port 6382 --slaveof 127.0.0.1 6380

在6380、6381和6382节点分别启动客户端。

redis-cli -p 638?

。

6380主节点才有CRUD的操作。其他从节点的客户端只有查询的权限。

如果把6380主节点的服务挂点，则6381和6382的从节点就会六神无主，一直在尝试连接。此时只需要在6381或者6382的客户端上执行：

slaveof no one

让6381/6382由从变成主。如果让6381变成主，再通知6382。

slaveof 127.0.0.1 6381

通知6382，作为6381的从。

伪分布哨兵集群搭建：

1 拷贝src下的redis-sentinel至bin目录下：

2 启动三个主从redis实例

3 创建哨兵配置文件目录： mkdir sent

4 目录下创建启动配置文件病拷贝：

vi s1.conf cp s2.conf s3.conf

配置文件内容：

port 26380,1,2

sentinel monitor jw 127.0.0.1 6380 2

5 启动sentinel读取配置文件：

redis-sentinel s1.conf s2.conf s3.conf

6 测试：演示自动提备

说明：通过启动6380/6381/6382分别为主、从、从。以及启动s1.cong s2.conf s3.conf 哨兵监控主。

通过主动杀死6380主节点，查看6381 6382从节点的情况。发现，先连接异常，后来选出新的主节点。通过哨兵就可以看到选出的主是谁。以及在客户端测试是否可以set操作。

<
4000
strong>3.全分布式搭建[/b]

备：全分布式只在node02上搭建。所有的操作都在一个节点的不同的客户端窗口中进行。

1.删redis2.8下的bin目录和文件

rm -fr /opt/jw/reids

2.ftp上传reids-cluster

解压里面的redis 3.0

3.make命令编译拷贝到/opt/jw/redis下

make && make PREFIX=/opt/jw/redis install

成功后会有哨兵的提示。

4.测试是否成功

re+tab

5.安装ruby编译环境

yum -y install ruby rubygems

6.redis-cluster目录下安装 redis gem 模块

gem  install --local redis-3.3.0.gem

8.创建文件目录、主从节点并匹配端口

指定3个主节点端口为7000 7001 7002 对应3个从节点端口为7003 7004 7005

mkdir 7000 7001 7002 7003 7004 7005

9.创建配置文件redis.conf

上述的目录下新建redis.conf 里面写入：

1 cluster-enabled yes

2 port 7000

10.分别启动6个节点：

redis-server redis.conf redis.conf

ss -tanl | grep 700

11.创建集群，槽位认领

在安装目录下的src中， 找到redis-trib.rb 这是rubby脚本执行程序，完成redis3.0集群创建

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

12.客户端测试

redis-cli -p 7000 -c

127.0.0.1:7000> set k1 a

-> Redirected to slot [12706] located at 127.0.0.1:7002 // a模值在槽位在7002上会跳转到7002上。

OK

127.0.0.1:7002>

[root@node02 ~]# redis-cli -p 7001 -c

127.0.0.1:7001> get k1

-> Redirected to slot [12706] located at 127.0.0.1:7002

"a"

127.0.0.1:7002>

如果查看需要在7002的客户端上去拿。

测试，如果把7000挂掉，则7003会由备变成主。测试从7003的客户端可以查看7000上的数据。

第二部分:带哨兵的集群架构细节分析

集群的分析：

由于单点故障/瓶颈，因此需多个节点负载

一变多（一致性<弱一致，最终一致性>）->可用性

最终一致性：一部分角色确认 -> 网络分区（脑裂）->过半机制

镜像：数据容量不变

切片：横向扩展

Cap原则

集群分类

主从复制 Replication：镜像：增删改（主<退化到单节点>）查询负载到从节点

高可用 Sentinel

分布式 twemproxy：切片

集群 Cluster

主从复制 Replication

1.一个Redis服务可以有多个该服务的复制品，这个Redis服务称为Master，其他复制品称为Slaves

2.只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步

3.只有Master可以执行写命令，Slaves只能执行读命令

4.从服务器执行客户端发送的读命令，比如GET、LRANGE、SMEMMBERS、HGET、ZRANGE等等

5.客户端可以连接Slaves执行读请求，来降低Master的读压力。

6.相对于无主模型，更加简单. 主单点返回确认即可。Redis采用异步主从同步数据，有瑕疵。另外主单点，使用哨兵解决单点故障。

主从复制创建

每个redis实例默认自己是主，需要手动变更

redis-server --slaveof <master-ip> <master-port>

，配置当前服务称为某Redis服务的Slave

redis-server --port 6380 --slaveof 127.0.0.1 6379

SLAVEOF host port命令，将当前服务器状态从Master修改为别的服务器的Slave

redis > SLAVEOF 192.168.1.1 6379，将服务器转换为Slave

redis > SLAVEOF NO ONE ，将服务器重新恢复到Master，不会丢弃已同步数据

配置方式：启动时，服务器读取配置文件，并自动成为指定服务器的从服务器

主从复制问题

一个Master可以有多个Slaves

Slave下线，只是读请求的处理性能下降

Master下线，写请求无法执行

其中一台Slave使用SLAVEOF no one命令成为Master，其它Slaves执行SLAVEOF命令指向这个新的Master，从它这里同步数据

以上过程是手动的，能够实现自动，这就需要Sentinel哨兵，实现故障转移Failover操作

监控 Monitoring

Sentinel会不断检查Master和Slaves是否正常

每一个Sentinel可以监控任意多个Master和该Master下的Slaves

Sentinel网络

监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器的信息

右图中3个Sentinel监控着S1和它的2个Slave



服务器下线

当一个sentinel认为被监视的服务器已经下线时，它会向网络中的其他Sentinel进行确认，判断该服务器是否真的已经下线

如果下线的服务器为主服务器，那么sentinel网络将对下线主服务器进行自动故障转移，通过将下线主服务器的某个从服务器提升为新的主服务器，并让其从服务器转为复制新的主服务器，以此来让系统重新回到上线的状态

Sentinel 配置文件

至少包含一个监控配置选项，用于指定被监控Master的相关信息

指定sentinel端口号：

port 26380（Sentinel默认端口号为26379)

Sentinel monitor<name><ip><port><quorum>

，

例如:sentinel monitor mymaster 127.0.0.1 63802

监视mymaster的主服务器，服务器ip和端口，将这个主服务器判断为下线失效至少需要2个Sentinel同意，如果多数Sentinel同意才会执行故障转移

Sentinel会根据Master的配置自动发现Master的Slaves

Sentinel 配置举例

执行以下两条命令，将创建两个监视主服务器s1的sentinel实例：

$redis-sentinel sentinel1.conf

$redis-sentinel sentinel2.conf

其中sentinel1.conf的内容为：

port 26379

Sentinel monitor s1 127.0.0.1 6380 1

sentinel2.conf的内容为：

Port 26380

Sentinel monitor s1 127.0.0.1 6379 2

Sentinel 总结

主从复制，解决了读请求的分担，从节点下线，会使得读请求能力有所下降

Master只有一个，写请求单点问题

Sentinel会在Master下线后自动执行Failover操作，提升一台Slave为Master，并让其他Slaves重新成为新Master的Slaves

主从复制+哨兵Sentinel只解决了读性能和高可用问题，但是没有解决写性能问题

第三部分:全分布式集群架构细节分析

在redis3.0版本之前推特公司自己研发了集群版redis。主要的是利用代理服务。



分析：

Twitter开发的代理服务器，他兼容Redis和Memcached，允许用户将多个redis服务器添加到一个服务器池（pool）里面，并通过用户选择的散列函数和分布函数，将来自客户端的命令请求分发给服务器池中的各个服务器

通过使用twemproxy我们可以将数据库分片到多台redis服务器上面，并使用这些服务器来分担系统压力以及数据库容量：在服务器硬件条件相同的情况下，对于一个包含N台redis服务器的池来说，池中每台平均1/N的客户端命令请求

向池里添加更多服务器可以线性的扩展系统处理命令请求的能力，以及系统能够保存的数据量

代理存在单点故障问题，将key采用hash取模方式分发到不同节点。但是如果加节点还需要重新对取模算法调整。而且如果数据特殊，同一个key过多，会造成数据倾斜。造成负载不均衡。但是数据迁移不好做。

redis3.0版本正式版

简介：采用取模方式但是优化的地方在于，采用槽位的思想

一共有16384个槽位（slot），然后这些槽位被几个几点分割。比如节点1从0-1000。节点2从1001-1600，节点3从16001-16383.这样，如果增加了节点，只需要把操作再分配以下就可以了。不想推特的做法，还需要重新计算取模的方式。在数据迁移、倾斜的时候都会因为之前知道key和槽位的关系。就会好办些。

Redis集群分片

集群将整个数据库分为16384个槽位slot，所有key都属于这些slot（槽位）中的一个，key的槽位计算公式为slot_number=crc16(key)%16384，其中crc16为16位的循环冗余校验和函数

集群中的每个主节点都可以处理0个至16383个槽，当16384个槽都有某个节点在负责处理时，集群进入上线状态，并开始处理客户端发送的数据命令请求

举例

三个主节点7000、7001、7002平均分片16384个slot槽位

节点7000指派的槽位为0到5060

节点7001指派的槽位为5461到10022

节点7002指派的槽位为10923到16383

节点7003指派的槽位为5061到5460,10023-10922

Redis集群节点复制

Redis集群的每个节点都有两种角色可选：主节点master node、从节点slave node。其中主节点用于存储数据，而从节点则是某个主节点的复制品

当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能，因为Redis集群重用了单机Redis复制特性的代码，所以集群的复制行为和我们之前介绍的单机复制特性的行为是完全一样的

Redis集群故障转移

Redis集群的主节点内置了类似Redis Sentinel的节点故障检测和自动故障转移功能，当集群中的某个主节点下线时，集群中的其他在线主节点会注意到这一点，并对已下线的主节点进行故障转移

集群进行故障转移的方法和Redis Sentinel进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以集群不必另外使用Redis Sentinel

Redis集群Redirect转向

由于Redis集群无中心节点(无主模型)，请求会发给任意主节点

主节点只会处理自己负责槽位的命令请求，其它槽位的命令请求，该主节点会返回客户端一个转向错误

客户端根据错误中包含的地址和端口重新向正确的负责的主节点发起命令请求

redis集群的缺点：

不支持类似MR的suffle的过程。比如不同节点都有相同set集合。redis让2者不可以汇聚，既不可以交并差操作。群杜绝了它们之间对的沟通。防止影响其负载均衡的能力。

第四部分:原理及简介

1.redis的引入

介绍在数据没出来前都是通过文件系统的存储数据的。但是存在如果文件中的数据过多，读取过慢情况，因此产生了数据库的概念。有2大知识点支持数据的发展。第一是：DP（datapage），有很多的DP，通过切片的方式存储大文件的数据。每个DP是4k。（4K,是因为磁盘的最小单位是扇区，每个扇区最大是512个字节）。比如导入数据库的文件，都是被切割成很多4k的小块存储的。

2.redis简单介绍

2.1.开源的（BSD协议），（genu）使用ANSI C 编写，基于内存的且支持持久化，高性能的Key-Value的NoSQL数据库

2.2.redis把数据分为冷数据和热数据。 热数据放在内存里，冷数据放在磁盘中。客户端访问服务器，如果第一次第一，内存中没有此数据。服务器读取磁盘上表结构的数据。把数据放入内存中，下次访问直接走内存。redis机制中，会对数据设置过期时间。然后定期查询，时间轮循的方式。（类似的内存数据库， NameNode,DataNode,memcache）。其中redis比memcache火的原因，mencache只支持String类型，而redis支持海量类型。

2.3.支持数据结构类型丰富，有如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。

丰富的支持主流语言的客户端，C、C++、Python、Erlang、R、C#、Java、PHP、Objective-C、Perl、Ruby、Scala、Go、JavaScript

2.4.用途：缓存（StackOverFlow）、数据库（微博）、消息中间件（微博）

2.5. 世界上任何数据类型都可以由以下几种(组合)方式表达

a=1 a=k

a=(1,3,98)

a={x=11,w=88}

2.6.可视化客户端

RedisDesktopManager

3.Nosql分类：