优秀文档:
https://www.cnblogs.com/bigben0123/p/9115597.html
1:redis的简介和特点
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。
(*)前身:Memcached
(*)区别:支持持久化,RDB、AOF
支持丰富的数据类型
2:安装部署redis
- 解压缩:
[root@hadoop01 softwares]# tar zxvf redis-3.2.11.tar.gz
- 如果报错:/bin/sh: cc: command not found
安装gcc:yum install gcc
- 如果报错:zmalloc.h:50:31: error: jemalloc/jemalloc.h: No such file or directory
原因是没有安装jemalloc内存分配器,可以安装jemalloc或直接输入
[root@hadoop01 redis-3.2.11]# make MALLOC=libc
安装redis:
[root@hadoop01 redis-3.2.11]# make PREFIX=/root/app/redis-3.2.11 install
命令脚本:
-rwxr-xr-x 1 root root 274188 Oct 10 22:53 redis-benchmark 压力测试工具(测试AOF日志重写的时候会用到)
-rwxr-xr-x 1 root root 22185 Oct 10 22:53 redis-check-aof 检查AOF日志文件
-rwxr-xr-x 1 root root 2526599 Oct 10 22:53 redis-check-rdb 检查RDB快照文件
-rwxr-xr-x 1 root root 404085 Oct 10 22:53 redis-cli 客户端
lrwxrwxrwx 1 root root 12 Oct 10 22:53 redis-sentinel -> redis-server 哨兵,实现主从复制的HA(版本2.4+)
-rwxr-xr-x 1 root root 2526599 Oct 10 22:53 redis-server 启动或者停止Redies Server
- 核心配置文件:需要在源码中拷贝
cp /opt/softwares/redis-3.2.11/redis.conf conf/
- 修改配置文件:
daemonize yes 是否以后台运行的方式启动redis,建议设置为yes(如果 设置no的话,在命令行窗口退出则会关掉)
port 6379
- 启动:
bin/redis-server conf/redis.conf
- 查看redis是否已经启动
ps -ef | grep redis
- 进入当前redis客户端:
bin/redis-cli
3:Redis的基本操作
参考官网:
http://www.redis.net.cn/order/
4:Redis的事务处理
- (*)什么是事务?transaction
事务是有一组原子操作, 不能再分,要么成功,要么失败
事务是有一组DML(数据操作语言:insert update delete)语句组成
举例:银行转账 Mysql数据库
start transaction; --->Mysql事务开启方式是手动开启
update useraccount set money = money - 100 where name = "zhangsan"
update useraccount set money = money + 100 where name = "lisi"
commit; 发生错误:rollback;
事务的特性:原子性、一致性、持久性、隔离性
- (*)Redis中的事务并不是真正的事务:本质:将一组操作放到一个队列中,统一的执行
- (*)对Mysql和Redis事务做对比
Mysql Redis
开启事务: 自动开启 multi命令
操作: DML操作 redis命令:set incr
set incrBy
递交: commit exec命令
回滚: rollback discard命令
- (*)Redis 事务举例1:从tom->100->mike账号
127.0.0.1:6379> set tom 1000
OK
127.0.0.1:6379> set mike 1000
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby tom 100
QUEUED
127.0.0.1:6379> incrby mike 100
QUEUED
127.0.0.1:6379> exec
1) (integer) 900
2) (integer) 1100
(*)Redis 事务举例2:买票
set tom 1000
set ticket 1
multi
decrby tom 100
decr ticket
exec -> 递交操作慢了一点,票被别人抢走了
5:Redis的消息机制(广播)
(*)什么是消息? 消息的类型?
(1)消息可以是一个字符串,也可以是一个对象
(2)类型:
类型一:点对点(队列)
类型二:群发广播(主题)Topic
(*)常见的消息系统:
(1)kafka、redis --》都只支持Topic
(2)JMS:Java message Service标准
既可以支持Queue,也支持Topic
专业的JMS Server:Weblogic
(*)redis中消息的命令
发送消息:publish 频道的名称 消息的内容
接收消息:subscribe 频道的名称
psubscribe 通配符,来接收多个频道的消息
6:持久化:redis将内存中的数据写到磁盘文件上
(1)RDB:默认的持久化方式
执行快照,每隔一段时间把内存中数据写到RDB文件(dump.rdb)
定义生成RDB的策略
秒 key的个数
save 900 1 :15分钟内,如果有1个key的value发生变化,就执行RDB
save 300 10 :5分钟内,如果有10个key的value发生变化,就执行RDB
save 60 10000 :1分钟内,如果有10000个key的value发生变化,就执行RDB
stop-writes-on-bgsave-error yes
如果执行RDB快照的时候,出现错误,就停止客户端继续写入数据
rdbcompression yes
生成的RDB文件是否压缩
如果压缩,节约存储的空间,但是恢复效率比较低
如果不压缩,浪费存储空间,但是恢复效率高
RDB的优点和缺点:
(*)优点:恢复快
(*)缺点:两次RDB之间,会造成数据的丢失
(2)AOF:append only file-》通过记录日志
(*)默认禁用 appendonly no
1)生成AOF的策略
# appendfsync always 每个操作都记录日志:最安全、性能最差
appendfsync everysec 每秒记录一次
# appendfsync no 由操作系统决定什么时候写日志
2)no-appendfsync-on-rewrite no 当执行日志重写的时候,停止日志的写入
什么是重写?
DEMO:使用压力测试工具模拟10w条数据操作
bin/redis-benchmark -n 100000
-rw-r--r-- 1 root root 65600127 Oct 11 03:58 appendonly.aof
-rw-r--r-- 1 root root 31320430 Oct 11 03:58 appendonly.aof
触发日志重写的时机:
auto-aof-rewrite-percentage 100 日志文件比上次重写的时候大小超过了1倍
auto-aof-rewrite-min-size 64mb 日志文件超过64M发生重写
AOF的优点和缺点:
(*)优点:保证数据的安全
(*)缺点:恢复效率低
(3)总结
RDB和AOF各自优缺点,以及现实生产环境中应该如何使用
结合RDB和AOF实现Redis的持久化,类似于关系型数据库(RDBMS)中的全量备份、增量备份
7:Redis的主从复制
(*)是主从结构,就存在单点故障的问题
(*)作用
1)实现读写分离,默认:主节点负责写,从节点(s)负责读
2)实现任务分离,主节点不在负责生产RDB和AOF文件,由从节点生成
(*)架构
1)星型模型
2)线性模型
(*)配置
主节点:端口6379
关闭RDB和AOF
#save 900 1
#save 300 10
#save 60 10000
appendonly no
从节点:开启RDB和AOF
参数:slaveof 配置主节点的地址
从节点1:
port 6380
dbfilename dump6380.rdb
appendfilename "appendonly6380.aof"
slaveof localhost 6379
从节点2:
port 6381
dbfilename dump6381.rdb
appendfilename "appendonly6381.aof"
slaveof localhost 6379
8:Redis的哨兵Sentinal(实现HA):解决单点故障
(*)redis 2.4+ 版本提出
(*)redis 2.4版本以前使用zookeeper实现redis HA
(*)以:星型模型 为例
(*)Demo:启动三个redis实例
哨兵的核心配置文件:sendtinal.conf
cp /opt/softwares/redis-3.2.11/sentinel.conf conf/
参数:
port 26379 端口号
sentinel monitor <master-name> <ip> <redis-port> <quorum> -》配置哨兵见识对象
主节点别名 主节点IP 主节点端口 几个哨兵
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel auth-pass <master-name> <password> 如果主节点配置了密码,哨兵连接主节点的密码
sentinel down-after-milliseconds mymaster 30000 如果30秒没有收到主节点的心跳,进行HA的切换
sentinel parallel-syncs mymaster 1 选举新的主节点后,允许同时连接的从节点个数,这个参数一定不能太大
sentinel failover-timeout mymaster 180000 默认三分钟,HA的切换没有完成,就失败
启动:
bin/redis-sentinel conf/sentinel.conf
输出日志:
1552:X 11 Oct 20:01:36.219 # +monitor master mymaster 127.0.0.1 6379 quorum 1
1552:X 11 Oct 20:01:36.221 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
1552:X 11 Oct 20:01:36.223 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
杀掉6379的主节点
注意:一台:使用IP地址,启动一个哨兵
输出的监控日志
1552:X 11 Oct 20:03:50.428 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
1552:X 11 Oct 20:03:50.428 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
1552:X 11 Oct 20:03:50.428 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
9:Redis的代理分片:针对是从节点
(*)部署规划
使用nutcracker-0.3.0
Demo:主节点 6379
从节点 6380 6381
(*)安装
解压缩
[root@hadoop01 softwares]# tar -zxvf nutcracker-0.3.0.tar.gz
执行脚本
[root@hadoop01 nutcracker-0.3.0]# ./configure --prefix=/root/app/proxy
[root@hadoop01 nutcracker-0.3.0]# make
[root@hadoop01 nutcracker-0.3.0]# make install
拷贝一个核心配置文件
[root@hadoop01 proxy]# cp /opt/softwares/nutcracker-0.3.0/conf/nutcracker.yml conf/
检查配置文件是否正确
[root@hadoop01 proxy]# sbin/nutcracker -t conf/nutcracker.yml
nutcracker: configuration file 'conf/nutcracker.yml' syntax is ok ->返回ok表示配置正确
启动代理服务器
[root@hadoop01 proxy]# sbin/nutcracker -d -c conf/nutcracker.yml
查看启动的代理服务器
[root@hadoop01 proxy]# ps -ef | grep nutcracker
10:Redis Clauster: 分布式存储机制(3.0以后的特性)--> HDFS
(*)什么是redis clauster?
是redis提供的分布式存储解决方案
1)单节点的redis存储瓶颈
问题1:容量问题
问题2:高并发问题
2)redis cluster:利用分布式
特点:去中心化(没有中心节点)
分布式存储
(*)redis cluster的体系结构
(*)安装部署