redis数据库

redis数据库

musql 关系型数据库

非关系型数据库redis mongodb

nosql不仅仅是

redis-cli ping pong

NoSQL

学名(not only sql)
特点:
存储结构与mysql这一种关系型数据库完全不同,nosql存储的是KV形式
nosql有很多产品,都有自己的api和语法,以及业务场景
产品种类:
Mongodb
redis
Hbase hadoop

Nosql和sql的区别

应用场景不同,sql支持关系复杂的数据查询,nosql反之
sql支持事务性,nosql不支持

redis优势

性能高,读取速度10万次每秒
写入速度8万次每秒
所有操作支持原子性
​
用作缓存数据库,数据放在内存中
替代某些场景下的mysql,如社交类app
大型系统中,可以存储session信息,购物车订单

redis缺点

缺点是:断电释放内存数据,redis数据丢失,redis进程挂掉,数据丢失,redis提供了持久化机制
 

yum安装redis

1.yum安装

#前提得配置好阿里云yum源,epel源
#查看是否有redis包
yum list redis
#安装redis
yum install redis -y
#安装好,启动redis
systemctl start redis

2.检测redis是否工作

redis-cli    #redis 客户端工具
#进入交互式环境后,执行ping,返回pong表示安装成功
127.0.0.1:6379> ping
PONG
​
redis-cli -p 端口号 -h ip地址 -a   密码

源码安装redis,编译安装

1.下载redis源码
wget http://download.redis.io/releases/redis-4.0.10.tar.gz
2.解压缩
tar -zxf redis-4.0.10.tar.gz
3.切换redis源码目录
cd redis-4.0.10.tar.gz
4.编译源文件
make
5.编译好后,src/目录下有编译好的redis指令
6.make install 安装到指定目录,默认在/usr/local/bin
redis可执行文件
./redis-benchmark //用于进行redis性能测试的工具
./redis-check-dump //用于修复出问题的dump.rdb文件
./redis-cli //redis的客户端
./redis-server //redis的服务端
./redis-check-aof //用于修复出问题的AOF文件
./redis-sentinel //用于集群管理

redis配置文件

redis配置文件名为
redis.conf
这个文件可以自定义
redis配置文件
绑定ip,如需要远程访问,需要填写服务器ip
bind 127.0.0.1  
​
端口,redis启动端口
port              #加端口号    
​
守护进程方式在后台运行
daemonize yes
​
rdb数据文件
dbfilename dump.rdb
​
数据文件存放路径
dir /var/lib/redis/
​
日志文件
logfile /var/log/redis/redis-server.log
​
主从复制
slaveof               #加要从的ip和端口号
​
requirepass       #密码
​
​
​

redis的数据结构

redis是一种高级的key:value存储系统,其中value支持五种数据类型
字符串(strings)
散列(hashes)
列表(lists)
集合(sets)
有序集合(sorted sets)
基本命令
keys *         查看所有key
type key     查看key类型
expire key seconds   过期时间
ttl key     查看key过期剩余时间       -2表示key已经不存在了
persist     取消key的过期时间   -1表示key存在,没有过期时间
​
exists key     判断key存在   存在返回1   否则0
del keys     删除key   可以删除

数据结构类型

1.strings类型

应用场景:

string是最常用的一种数据类型,普通的key/value存储都可以归为此类,即可以完全实现目前Memcached的功能,并且效率更高,还可以享受redis的定时持久化,操作日志及replication等功能,除了提供与Memcached一样的get.set.incr,decr等操作外,还提供了下面一些操作:
​
获取字符串的长度
往字符串append内容
设置和获取字符串的某一段内容
设置及获取字符串的某一位
批量设置一系列字符串的内容
​
实现方式:
string是二进制安全的,意思是redis的string可以包含任何数据类型,比如jpg图片或者序列化的对象

  1. O(1)时间复杂度获取字符串长度,未用长度,已用长度

  2. 预分配机制,减少内存在分配次数

  3. 惰性删除机制,字符串缩减长度后的空间不释放,作为预分配保留

string在redis內部存储都默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值进行计算,此时redisObject的encoding字段为int

 

set   设置key
get   获取key
append 追加string
mset   设置多个键值对
mget   获取多个键值对
del 删除key
incr 递增+1
decr 递减-1

2.list类型

简介:

list是按照插入顺序排序的字符串链表,可以在头部和尾部插入新的元素(双向链表实现,两端添加元素的时间复杂度为O(1).插入元素时,如果key不存在,redis会为该key创建一个新的链表,如果链表找那个所有的元素都被移除,该key也会从redis中移除

数据类型:

常见操作时用lpush在list头部插入元素,用rpop在list尾部取出数据

应用场景:
  1. 消息队列

    • redis的list数据类型对于大部分使用者来说,是是实现队列服务的最经济最简单的方式

  2. 最新内容

    • 应为list结构的数据查询两端附近的数据性能非常好,所以适合一些需要获取最新数据的场景,比如新闻应用中的'最近新闻';

优化建议
list是链表结构,所有如果在头部和尾部插入数据,性能会非常高,不受链表长度的影响;单如果在链表中插入数据,性能就会越来越差
方法:
lpush         从列表左边插
rpush         从列表右边插
lrange         获取一定长度的元素 lrange key start stop
ltrim               截取一定长度列表
lpop                 删除最左边一个元素
rpop                     删除最右边一个元素
lpushx/rpushx               key存在则添加值,不存在不处理

3.sets集合类型

redis的集合,是一种无序的集合,集合中的元素没有先后顺序。

set集合不允许数据重复,如果添加的输在在set中已经存在,将只保留一份.

set类型提供了多个set之间的聚合运算,如求交集,并集,补集,这些操作在redis内部完成,效率很高.

数据模型

应用场景
set类型的特点是----不重复无序的一组数据,并且具有丰富的计算功能,在一些特定的场景中可以高效的解决一般关系型数据库不方便做的工作
  1. 共同好友列表

    • 社交类应用中,获取两个人或多个人的共同好友,两个人或多个人共同关注的微博这样类似的功能,用 MySQL 的话操作很复杂,可以把每个人的好友 id 存到集合中,获取共同好友的操作就可以简单到一个取交集的命令就搞定。

// 这里为了方便阅读,把 id 替换成姓名
sadd user:wade james melo paul kobe
sadd user:james wade melo paul kobe
sadd user:paul wade james melo kobe
sadd user:melo wade james paul kobe
​
// 获取 wade 和 james 的共同好友
sinter user:wade user:james
/* 输出:
*      1) "kobe"
*      2) "paul"
*      3) "melo"
*/

// 获取香蕉四兄弟的共同好友
sinter user:wade user:james user:paul user:melo
/* 输出:
*      1) "kobe"
*/

/*
    类似的需求还有很多 , 必须把每个标签下的文章 id 存到集合中,可以很容易的求出几个不同标签下的共同文章;
把每个人的爱好存到集合中,可以很容易的求出几个人的共同爱好。
*/
方法
sadd/srem   添加/删除 元素
sismember   判断是否为set的一个元素
smembers   返回集合所有的成员
sdiff             返回一个集合和其他集合的差异
sinter           返回几个集合的交集
sunion         返回几个集合的并集

4.有序集合

用来保存需要排序的数据,例如排行榜,成绩,工资等。

在set的基础上给结合中的每个元素关联了一个分数,往有序集合中插入数据时会自动根据这个分数排序

应用场景
在集合类型的场景上加入排序就是有序集合的应用场景了,比如根据好友亲密度排序显示好友列表
// 用元素的分数(score)表示与好友的亲密度
zadd user:kobe 80 james 90 wade 85 melo 90 paul
​
// 根据“亲密度”给好友排序
zrevrange user:kobe 0 -1
​
/**
* 输出:
*     1) "wade"
*     2) "paul"
*     3) "melo"
*     4) "james"
*/

// 增加好友的亲密度
zincrby user:kobe 15 james
​
// 再次根据“亲密度”给好友排序
zrevrange user:kobe 0 -1
​
/**
* 输出:
*     1) "james"
*     2) "wade"
*     3) "paul"
*     2) "melo"
*/

//类似的需求还出现在根据文章的阅读量或点赞量对文章列表排序

 

ZADD  向有序集合中添加
ZREVRANGE 倒叙显示集合
ZRAGE     正序显示
ZREM     移除
ZCARD     返回集合的基数

利用有序集合的排序,排序学生的成绩

127.0.0.1:6379> ZADD mid_test 70 "alex"
(integer) 1
127.0.0.1:6379> ZADD mid_test 80 "wusir"
(integer) 1
127.0.0.1:6379> ZADD mid_test 99 "yuyu"

排行榜,zreverange 倒叙 zrange正序

127.0.0.1:6379> ZREVRANGE mid_test 0 -1 withscores
1) "yuyu"
2) "99"
3) "wusir"
4) "80"
5) "xiaofneg"
6) "75"
7) "alex"
8) "70"

移除有序集合mid_test中的成员,xiaofeng给移除掉

127.0.0.1:6379> ZREM mid_test xiaofneg
(integer) 1
127.0.0.1:6379> ZRANGE mid_test 0 -1 withscores
1) "alex"
2) "70"
3) "wusir"
4) "80"
5) "yuyu"
6) "99"

返回有序集合mid_test的基数

127.0.0.1:6379> ZCARD mid_test
(integer) 3

返回成员的score值

127.0.0.1:6379> ZSCORE mid_test alex
"70"

zrank返回有序集合中,成员的排名。默认按score,从小到大排序。

127.0.0.1:6379> ZRANGE mid_test 0 -1 withscores
1) "alex"
2) "70"
3) "wusir"
4) "80"
5) "yuyu"

5.哈希数据结构

哈希结构就是 k1 -> k1 : v1 如同字典 套字典 { k1 : { k2: v2 } } ,取出v2 必须 k1,取出k2

hashes即哈希。哈希是从redis-2.0.0版本之后才有的数据结构。

hashes存的是字符串和字符串值之间的映射,比如一个用户要存储其全名、姓氏、年龄等等,就很适合使用哈希。

应用场景:
在Memcached中,我们经常将一些结构化的信息打包成HashMap,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。
我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:
​
用户ID为查找的key,存储的value用户对象包含姓名,年龄,生日等信息,如果用普通的key/value结构来存储,主要有以下2种存储方式:

第一种:

第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。

第二种:

第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口

key依然是用户的ID,value是一个Map,这个Map的key就是成员的属性名,value是属性值,这样对数据的修改和存储都可以直接通过其内部Map的key(Redis里称内部Map的key为field),也就是通过key(用户ID)+field(属性标签)就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题,
对比
hash数据类型在存储上述类型的数据时具有比string更灵活,更快的优势,具体的说,使用string类型存储,必然需要转换和解析json格式的字符串,即便不需要转换,在内存开销方面,还是hash占优势

 

hset 设置散列值
hget 获取散列值
hmset 设置多对散列值
hmget 获取多对散列值
hsetnx   如果散列已经存在,则不设置(防止覆盖key)
hkeys     返回所有keys
hvals     返回所有values
hlen     返回散列包含域(field)的数量
hdel     删除散列指定的域(field)
hexists   判断是否存在
edis hash是一个string类型的field和value的映射表
​
语法 hset key field value  
​
hset news1   title "first news title" #设置第一条新闻 news的id为1,添加数据title的值是"first news title"
​
hset news1 content "news content"   #添加一个conntent内容
​
hget news1 title   #获取news:1的标题
​
hget news1 content #获取news的内容
​
hmget news1 title content   #获取多对news:1的 值
​
hmset news2 title "second news title" content "second Contents2"   #设置第二条新闻news:2 多个field
​
hmget news2 title content #获取news:2的多个值
​
hkeys news1   #获取新闻news:1的所有key
​
hvals news1   #获取新闻news:1的所有值
​
hlen news1   #获取新闻news:1的长度
​
hdel news1 title   #删除新闻news:1的title
​
hlen news1     #看下新闻news:1的长度
​
hexists news1 title   #判断新闻1中是否有title,不存在返回0,存在返回1

redis的发布订阅

Redis 通过 PUBLISH 、 SUBSCRIBE 等命令实现了订阅与发布模式。

发布/订阅 实验

PUBLISH channel msg
  将信息 message 发送到指定的频道 channel
​
SUBSCRIBE channel [channel ...]
  订阅频道,可以同时订阅多个频道
​
UNSUBSCRIBE [channel ...]
  取消订阅指定的频道, 如果不指定频道,则会取消订阅所有频道
   
PSUBSCRIBE pattern [pattern ...]
  订阅一个或多个符合给定模式的频道,每个模式以 * 作为匹配符,比如 it* 匹配所   有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等), news.* 匹配所有   以 news. 开头的频道( news.it 、 news.global.today 等等),诸如此类
PUNSUBSCRIBE [pattern [pattern ...]]
  退订指定的规则, 如果没有参数则会退订所有规则
PUBSUB subcommand [argument [argument ...]]
  查看订阅与发布系统状态
   
注意:使用发布订阅模式实现的消息队列,当有客户端订阅channel后只能收到后续发布到该频道的消息,之前发送的不会缓存,必须Provider和Consumer同时在线。

发布订阅:

窗口1,启动两个redis-cli窗口,均订阅diantai 频道(channel)
[root@bogon redis-4.0.10]# redis-cli 
127.0.0.1:6379> SUBSCRIBE ghl
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ghl"
3) (integer) 1
窗口2,启动两个redis-cli窗口,均订阅diantai 频道(channel)
[root@bogon redis-4.0.10]# redis-cli 
127.0.0.1:6379> SUBSCRIBE ghl
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ghl"
3) (integer) 1
窗口3,启动发布者向频道 diantai发送消息**
[root@bogon redis-4.0.10]# redis-cli
127.0.0.1:6379> PUBLISH ghl 'woshibaba'
(integer) 2

最后窗口1和2查看发布消息

redis持久化RDB和AOF

redis持久化

Redis是一种内存型数据库,一旦服务器进程退出,数据库的数据就会丢失,为了解决这个问题,Redis提供了两种持久化的方案,将内存中的数据保存到磁盘中,避免数据的丢失。

RDB持久化

redis提供了RDB持久化的功能,这个功能可以将redis在内存中的的状态保存到硬盘中,它可以手动执行。

也可以再redis.conf中配置,定期执行。

RDB持久化产生的RDB文件是一个经过压缩的二进制文件,这个文件被保存在硬盘中,redis可以通过这个文件还原数据库当时的状态。

RDB(持久化)
内存数据保存到磁盘
在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)
优点:速度快,适合做备份,主从复制就是基于RDB持久化功能实现
rdb通过再redis中使用save命令触发 rdb
​
​
rdb配置参数:
​
dir /data/6379/
dbfilename dbmp.rdb
​
每过900秒 有1个操作就进行持久化
​
save 900秒 1个修改类的操作
save 300秒 10个操作
save 60秒 10000个操作
​
save 900 1
save 300 10
save 60 10000

redis持久化之RDB实践

1.启动redis服务端,准备配置文件

daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379             #定义持久化文件存储位置
dbfilename dbmp.rdb       #rdb持久化文件
bind 10.0.0.10 127.0.0.1   #redis绑定地址
requirepass redhat           #redis登录密码
save 900 1                   #rdb机制 每900秒 有1个修改记录
save 300 10                   #每300秒       10个修改记录
save 60 10000               #每60秒内       10000修改记录

2.启动redis服务端

3.登录redis设置一个key

redis-cli -a redhat

4.此时检查目录,/data/6379底下没有dbmp.rdb文件

5.通过save触发持久化,将数据写入RDB文件

127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> save
OK

redis持久化之AOF

AOF(append-only log file) 记录服务器执行的所有变更操作命令(例如set del等),并在服务器启动时,通过重新执行这些命令来还原数据集 AOF 文件中的命令全部以redis协议的格式保存,新命令追加到文件末尾。 优点:最大程序保证数据不丢 缺点:日志记录非常大

redis-client   写入数据  >  redis-server   同步命令   >  AOF文件

配置参数

AOF持久化配置,两条参数
​
appendonly yes
appendfsync always   总是修改类的操作
            everysec   每秒做一次持久化
            no     依赖于系统自带的缓存大小机制

1.准备aof配置文件 redis.conf

daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379
dbfilename dbmp.rdb
requirepass redhat
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

redis 持久化方式有哪些?有什么区别?

rdb:基于快照的持久化,速度更快,一般用作备份,主从复制也是依赖于rdb持久化功能

aof:以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全,类似于mysql的binlog

redis的主从同步

1.redis和mysql都是支持多实例功能,基于配置文件区分,就是一个数据库单独的实例

环境准备

6379.conf

port 6379
daemonize yes
pidfile /data/6379/redis.pid
loglevel notice
logfile "/data/6379/redis.log"
dbfilename dump.rdb
dir /data/6379
protected-mode no

6380.conf

port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
protected-mode no
slaveof   127.0.0.1 6379

2.分别启动2个redis实例

redis-server redis-6379.conf 
redis-server redis-6380.conf
3.登录数据库,查看两人之间的关系
登录6379数据库,输入如下命令
127.0.0.1:6379> info replication
​
6380数据库查看如下关系
[root@s20 smredis]# redis-cli -p 6380 info replication
​

4.数据读写查看

在6379中是可以读写的
redis-cli -p 6379 set name5 haoxiangxiake
​
在6380中只能读不能写
redis-cli -p 6380 get name5
5.主从复制故障恢复

作用:从库挂了无所谓,主库挂了得立即恢复主库,或者将从库切换为主库,继续工作

实验步骤:
1.分别启动 6379 6380 6381 三个数据库实例,建立好主从关系
2.杀死6379主库,此时6380 6381 群龙无首
3.选择让6381为新的主库,就要去除6381的从的身份
redis-cli -p 6381 slaveof no one
#查看此时6381的身份
redis-cli -p 6381 info replication
4.此时将6380的主人改为6381
redis-cli -p 6380 slaveof 127.0.0.1 6381
​

 

6.redis的哨兵,自动的主从故障切换

配置步骤

1.环境准备,准备3个redis数据库实例,分别是 6379 6380 6381

#redis-6379.conf 
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/6379"


#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/6380"
slaveof 127.0.0.1 6379    
​
#redis-6381.conf
port 6381
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/6381"
slaveof 127.0.0.1 6379  

2.分别启动三个redis数据库实例

 1106  redis-server redis-6379.conf 
1107 redis-server redis-6380.conf
1108 redis-server redis-6381.conf

3.准备三个redis-sentinel哨兵的配置文件

redis-sentinel-26379.conf
port 26379  
dir /var/redis/data/26379
logfile "26379.log"
​
// 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
// 2代表判断主节点失败至少需要2个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor s20master 127.0.0.1   6379 2
​
//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过30000毫秒30s且没有回复,则判定不可达
sentinel down-after-milliseconds s20master 30000
​
//当Sentinel节点集合对主节点故障判定达成一致时,Sentinel领导者节点会做故障转移操作,选出新的主节点,
原来的从节点会向新的主节点发起复制操作,限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs s20master 1
​
//故障转移超时时间为180000毫秒
sentinel failover-timeout s20master 180000
//让哨兵在后台运行
daemonize yes
​
​
#如下26380和26381的配置文件,仅仅是端口的不同,可以快速生成
redis-sentinel-26380.conf
redis-sentinel-26381.conf
​
#生成命令如下
1119 sed "s/26379/26380/g" redis-26379.conf > redis-26380.conf
1121 sed "s/26379/26381/g" redis-26379.conf > redis-26381.conf
​

4.分别运行三个哨兵进程

#(保证sentinel的配置正确,否则,你在启动报错后,配置文件的内容发发生变化,这是个坑!!!!)
#创建哨兵的数据文件夹
mkdir -p /var/redis/data/26380
mkdir -p /var/redis/data/26379
mkdir -p /var/redis/data/26381
   
#分别启动三个哨兵

redis-sentinel redis-26379.conf
redis-sentinel redis-26380.conf
redis-sentinel redis-26381.conf
​

5.检查redis的哨兵状态

redis-cli -p 26379 info sentinel
#查看到如下参数,哨兵就正确了
master0:name=s20master,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

6.杀死主库,检查从主状态发现,其中一个库以及称为主库。

redis-cluster集群

集群搭建

1.环境准备,6个redis数据库节点

也就是准备6个配置文件,6匹马
redis-7000.conf
redis-7001.conf
redis-7002.conf
redis-7003.conf
redis-7004.conf
redis-7005.conf
#每个配置文件的内容,仅仅是端口的不同7000~7005
#内容如下
port 7000   #端口号
daemonize yes  #后台运行
dir "/opt/redis/data/7000"
logfile "7000.log"
dbfilename "dump-7000.rdb"
cluster-enabled yes   #开启集群模式
cluster-config-file nodes-7000.conf  #集群内部的配置文件
cluster-require-full-coverage no 
 #redis cluster需要16384个slot都正常的时候才能对外提供服务,换句话说,只要任何一个slot异常那么整个cluster不对外提供服务。 因此生产环境一般为no
​

2.快速生成6个节点的配置文件

mkdir -p /opt/redis/data/{7000,7001,7002,7003,7004,7005}
sed "s/7000/7001/g" redis-7000.conf > redis-7001.conf
sed "s/7000/7002/g" redis-7000.conf > redis-7002.conf
sed "s/7000/7003/g" redis-7000.conf > redis-7003.conf
sed "s/7000/7004/g" redis-7000.conf > redis-7004.conf
sed "s/7000/7005/g" redis-7000.conf > redis-7005.conf

3.启动6个redis节点(准备好了6匹马)

redis-server redis-7000.conf 
redis-server redis-7001.conf
redis-server redis-7002.conf
redis-server redis-7003.conf
redis-server redis-7004.conf
redis-server redis-7005.conf

4.马儿准备好了,分配槽位,开始放入数据,查看数据流向

Redis集群中有16384个hash slots,为了计算给定的key应该在哪个hash slot上,我们简单地用这个key的CRC16值来对16384取模。(即:key的CRC16  %  16384)

 

开启redis-cluster的集群功能,以及分配redis的slot槽位,基于ruby语言的脚本工具自动分配
1.下载ruby的解释器
wget https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.gz
​
2.解压缩ruby的源码包
tar -zxvf ruby-2.3.1.tar.gz
3.进入ruby的源码包目录,编译三部曲
cd ruby-2.3.1
./configure --prefix=/opt/ruby231
make && make install

4.读取这个/etc/profile
source /etc/profile
​
5.下载ruby操作redis的模块
wget http://rubygems.org/downloads/redis-3.3.0.gem
#安装ruby操作redis的模块
gem install -l redis-3.3.0.gem
​
6.一键分配redis集群的槽位
#查找一下这个命令的绝对路径
find / -name redis-trib.rb
#这个数字 1 代表,每个redis主库,只有一个redis从库
/opt/redis-4.0.10/src/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
​
7.开启了集群状态功能后,登录数据库,查看数据写入流向
/opt/redis-4.0.10/src/redis-trib.rb add-node --slave 127.0.0.1:7003 127.0.0.1:7000
​
8.防止redis-cluster主节点故障,可以搭配 redis-cluster + redis-sentinel ,用哨兵检测主节点状态,当主节点宕机,自动切换从节点为新的主库
1.redis-sentinel配置方式如下,检测三个主节点7000 7001 7002
port 27379
dir "/var/redis/data"
logfile "26379.log"
sentinel monitor master1 127.0.0.1 7000 2  
sentinel monitor master2 127.0.0.1 7001 2  
sentinel monitor master3 127.0.0.1 7002 2  
​
sentinel down-after-milliseconds master1 30000  
sentinel down-after-milliseconds master2 30000  
sentinel down-after-milliseconds master3 30000  
​
sentinel parallel-syncs master1 1  
sentinel parallel-syncs master2 1  
sentinel parallel-syncs master3 1  
​
sentinel failover-timeout master1 180000  
sentinel failover-timeout master2 180000  
sentinel failover-timeout master3 180000  
​
2.启动哨兵,检测cluster的主节点
redis-sentinel redis-26379.conf

3.杀死redis-cluster的主节点,查看从节点状态(是否自动重启),可以运行多个从节点,保证数据安全

 

posted @ 2019-11-26 16:58  百鬼之主  阅读(244)  评论(0)    收藏  举报