Redis主从模型

主从架构：

角色设置，有身份的

Master

Master：大师，主节点

Slave：奴隶,从节点

主节点可以和客户端联系

从节点只有读和写，从节点的数据是由主节点分配过去的。从节点越多，主节点功能越强大，但是增删改只能由主节点去完成。

无主模型，脑裂，过半确认。

Redis在底层采用，异步分发。坏处是不一致，是不同版本的。

Sentinel:哨兵，监督

在这里是监督主节点的运行状态。

Sentinel：监督，一个集群中，一个master，两个slave，

当master挂了的时候，哨兵会将其中一个slave提升级别成master。

一个哨兵可能监控多套节点的工作和多个集群。

哨兵带来的最大好处是可以自定完成主从节点的替换。

如果没有哨兵，也可以完成切换，只是需要人工手动去完成。

Slaveof:是谁的从节点，从属于谁

是通过哨兵来维护的。

在redis的主从是可以通过手动切换。

 

进入redis,创建三个目录，

6380

6381

6382

进入其中一个

redis-server  --help查看

Synchronization：同步

 

 

 

链接主节点的客户端

 

 

设置值

Get k1:获取值

奴隶只能代表master存数据，但是不可以进行增删改的操作。

Down机

Ctr+C

或者shutdown

主挂了的时候，从不能取自己的值，也不能取主的值

手动切换启动另一个主节点时，必须从新以从节点的身份重新启动从节点。

Quie退出

Exit:退出

在客户端执行server-shuldown

 

 

 

 

 

高可用哨兵：

2.X：仅仅以旁观者身份运行哨兵

3.X：

哨兵也是以集群的方式监控

 

哨兵配置文件信息

在src下拷贝文件到lib下

 

Monitor:监控

Sentinel monitor  sxt   127.0.0.1 6380  2

 

 

zai

在把哨兵跑起来之前先把集群跑起来。

 

启动哨兵

 

 

把主挂掉之后，其余的会有短暂的挂掉，

 

 

 

原主再一次启动，则只能作为从节点。

从节点的启动：

redis-server --port 6381 --slaveof 192.168.198.21 6380

主节点的启动：

redis-server --port 6380

Redis做不了集群的汇聚工作

集群不稳定，很容易挂掉。

Data-s

Redis不好处理数据迁移

 

 

 

Redis twemproxy

Twemproxy

Twitter开发，代理用户的读写请求

 

数据迁移

Redis对于数据迁移，不好做。

大数据：效率优于准确性。

大数据是宏观上解决问题

槽位：

 

 

认领4000—10000

槽位是一个虚表

Slot

0—5000，5000—10000,10000—15000

服务器1，服务器2，服务器3

放置

先算槽位

3.0版本，当集群搭建起来，会不断的出现redirect，多个节点可以进行横向扩展。

单个节点容易挂掉，还需要做高可用，2.x是哨兵，3.0也需要哨兵。2.x中，哨兵是监控，3.0自带哨兵，每个节点都有双重身份，高可用和哨兵。

真正做到完美的是zookeeper。

首先将2.X下的bin文件删除，然后上传3.0版本（redie-cluster）到root根目录下

解压，确定有gcc和tcl,安装

编译

 make && make PREFIX=/opt/sxt/redis/

Make:编译

Make install:安装

安装：

gem install --local redis-3.3.0.gem

Redis：

单机

伪分布式

主从

进行槽位的分发：

./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

横向扩

展