目录
5.2.1、数据备份目录:/usr/local/redis/copy
7、redis如何通过读写分离承载读请求qps超过10万+?
7.3、如果redis要支撑超过10万+的并发,那应该怎么做?
写在前面:
redis的技术,包括4块
- redis各种数据结构和命令的使用,包括java api的使用
- redis一些特殊的解决方案的使用,pub/sub消息系统,分布式锁,输入的自动完成等等
- redis日常的管理相关的命令
- redis企业级的集群部署和架构
集群架构的底层原理,哨兵的底层原理,redis的大规模的架构师如何去支撑海量数据、高并发、高可用的。
1、安装单机版redis
wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd /usr/local/tcl8.6.1/unix/
./configure
make && make install
使用redis-3.2.8.tar.gz(截止2017年4月的最新稳定版)
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test && make install
2、redis的生产环境启动方案
要把redis作为一个系统的daemon进程去运行的,每次系统启动,redis进程一起启动
(1)redis utils目录下,有个redis_init_script脚本
(2)将redis_init_script脚本拷贝到linux的/etc/init.d目录中,将redis_init_script重命名为redis_6379,6379是我们希望这个redis实例监听的端口号
(3)修改redis_6379脚本的第6行的REDISPORT,设置为相同的端口号(默认就是6379)
(4)创建两个目录:/etc/redis(存放redis的配置文件(我的在/home/hadoop)),/var/redis/6379(存放redis的持久化文件)
(5)修改redis配置文件(默认在根目录下,redis.conf),拷贝到/etc/redis目录中,修改名称为6379.conf
(6)修改redis.conf中的部分配置为生产环境
- daemonize yes 让redis以daemon进程运行
- pidfile /var/run/redis_6379.pid 设置redis的pid文件位置
- port 6379 设置redis的监听端口号
- dir /var/redis/6379 设置持久化文件的存储位置
(7)启动redis,执行cd /etc/init.d, chmod 777 redis_6379,./redis_6379 start
(8)确认redis进程是否启动,ps -ef | grep redis
(9)让redis跟随系统启动自动启动
在redis_6379脚本中,最上面,加入两行注释
# chkconfig: 2345 90 10
# description: Redis is a persistent key-value database
chkconfig redis_6379 on
3、redis cli的使用
redis-cli SHUTDOWN,连接本机的6379端口停止redis进程
redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN,制定要连接的ip和端口号
redis-cli PING,ping redis的端口,看是否正常
redis-cli,进入交互式命令行
SET k1 v1
GET k1
4、企业级的持久化的配置策略
企业级的数据备份和各种灾难下的数据恢复,是怎么做得呢?
- 在企业中,RDB的生成策略,用默认的也差不多。
- save 60 10000:如果你希望尽可能确保说,RDB最多丢1分钟的数据,那么尽量就是每隔1分钟都生成一个快照,低峰期,数据量很少,也没必要。
- 是10000条生成RDB还是1000条生成RDB,这个根据你自己的应用和业务的数据量,你自己去决定。
- AOF一定要打开,fsync选择everysec。
- auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%,上次的两倍。
- auto-aof-rewrite-min-size 64mb: 根据你的数据量来定,16mb,32mb。
5、企业级的数据备份方案
RDB非常适合做冷备,每次生成之后,就不会再有修改了
5.1、数据备份方案
(1)写crontab定时调度脚本去做数据备份。
(2)每小时都copy一份rdb的备份,到一个目录中去,仅仅保留最近48小时的备份。保证数据出错时细粒度恢复。
(3)每天都保留一份当日的rdb的备份,到一个目录中去,仅仅保留最近1个月的备份。
(4)每次copy备份的时候,都把太旧的备份给删了。
(5)每天晚上将当前服务器上所有的数据备份,发送一份到远程的云服务S3上去。
5.2、数据备份实操
5.2.1、数据备份目录:/usr/local/redis/copy
cd /etc/local
mkdir redis
cd redis
mkdir copy
cd copy
vim redis_rdb_copy_hourly.sh
1.1、每小时copy一次备份,删除48小时前的数据的脚本文件:redis_rdb_copy_hourly.sh
#!/bin/sh
cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date
增加权限:chmod 777 redis/copy/redis_rdb_copy_hourly.sh
1.2、定时任务目录:/usr/local/redis/snapshotting
crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
1.3、执行定时任务
cd /usr/local/redis/copy
./redis_rdb_copy_hourly.sh
2.1、每天copy一次备份,删除1个月前的数据的脚本文件:redis_rdb_copy_daily.sh
#!/bin/sh
cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date
2.2、每天一次将所有数据上传一次到远程的云服务器上去。
crontab -e
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
效果:在目录/usr/local/redis/snapshotting下有近48小时和近1个月的数据,用于出现大面积数据错误时的数据恢复。对于数据丢失等故障的恢复时使用最新的dump即可。
6、数据恢复方案
- 如果是redis进程挂掉,那么重启redis进程即可,直接基于AOF日志文件恢复数据。不演示了,在AOF数据恢复那一块,演示了。如果使用fsync everysec,最多就丢一秒的数据。
- 如果是redis进程所在机器挂掉,那么重启机器后,尝试重启redis进程,尝试直接基于AOF日志文件进行数据恢复。若AOF没有破损,也是可以直接基于AOF恢复的,因为AOF是 append-only,顺序写入,如果AOF文件破损,那么用redis-check-aof fix即可。
- 如果redis当前最新的AOF和RDB文件出现了丢失/损坏,那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复。当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复,一般不是机器的故障,是人为的造成的。比如:大数据系统hadoop,有人不小心就把hadoop中存储的大量的数据文件对应的目录,rm -rf一下,我朋友的一个小公司,运维不太靠谱,权限也弄的不太好。
举例:/var/redis/6379下的dump和aof文件给删除了。
办法:找到RDB最新的一份备份,小时级的备份可以了,小时级的肯定是最新的,copy到redis里面去,就可以恢复到某一个小时的数据。
appendonly.aof + dump.rdb,优先用appendonly.aof去恢复数据,但是我们发现redis自动生成的appendonly.aof是没有数据的。然后我们自己的dump.rdb是有数据的,但是明显没用我们的数据。
redis启动的时候,自动重新基于内存的数据,生成了一份最新的rdb快照,直接用空的数据,覆盖掉了我们有数据的,拷贝过去的那份dump.rdb。
你停止redis之后,其实应该先删除appendonly.aof,然后将我们的dump.rdb拷贝过去,然后再重启redis。很简单,就是虽然你删除了appendonly.aof,但是因为打开了aof持久化,redis就一定会优先基于aof去恢复,即使文件不在,那就创建一个新的空的aof文件。
方法:停止redis,暂时在配置中关闭aof,然后拷贝一份rdb过来,再重启redis,数据能不能恢复过来,可以恢复过来。脑子一热,再关掉redis,手动修改配置文件,打开aof,再重启redis,数据又没了,空的aof文件,所有数据又没了。
在数据安全丢失的情况下,基于rdb冷备,如何完美的恢复数据,同时还保持aof和rdb的双开?
正确做法:首先停止redis,然后打开配置文件关闭aof,然后拷贝rdb备份到redis中,然后重启redis,确认数据恢复,最后直接在命令行热修改redis配置,打开aof,这个redis就会将内存中的数据对应的日志,写入aof文件中。并且此时aof和rdb两份数据文件的数据就同步了。
问题是:redis config set热修改配置参数,可能配置文件中的实际的参数没有被持久化的修改,再次停止redis,手动修改配置文件打开aof的命令,再次重启redis。
- 如果当前机器上的所有RDB文件全部损坏,那么从远程的云服务上拉取最新的RDB快照回来恢复数据
- 如果是发现有重大的数据错误,比如某个小时上线的程序一下子将数据全部污染了,数据全错了,那么可以选择某个更早的时间点,对数据进行恢复。举例,12点上线了代码发现代码有bug,导致代码生成的所有的缓存数据,写入redis,全部错了?找到一份11点的rdb的冷备,然后按照上面的步骤,去恢复到11点的数据,就可以。
7、redis如何通过读写分离承载读请求qps超过10万+?
7.1、redis高并发跟整个系统的高并发之间的关系
redis,你要搞高并发的话,不可避免,要把底层的缓存搞得很好。
mysql,高并发,做到了,那么也是通过一系列复杂的分库分表,订单系统,事务要求的,QPS到几万,比较高了。
要做一些电商的商品详情页,真正的超高并发,QPS上十万,甚至是百万,一秒钟百万的请求量
光是redis是不够的,但是redis是整个大型的缓存架构中,支撑高并发的架构里面重要环节。
首先,你的底层的缓存中间件,缓存系统,必须能够支撑的起我们说的那种高并发,其次,良好的整体的缓存架构的设计(多级缓存架构、热点缓存),支撑真正的上十万,甚至上百万的高并发。
7.2、redis不能支撑高并发的瓶颈在哪里?
单机
7.3、如果redis要支撑超过10万+的并发,那应该怎么做?
单机的redis几乎不太可能说QPS超过10万+,除非一些特殊情况,比如你的机器性能特别好,配置特别高,物理机,维护做的特别好,而且你的整体的操作不是太复杂,一般情况单机就在几万。
方案:使用读写分离,一般来说,对缓存一般都是用来支撑读高并发的,写的请求是比较少的。可能写请求也就一秒钟几千,一两千。大量的请求都是读,一秒钟二十万次读。
读写分离:一主多从,主节点负责写,从节点负责读。从节点可以水平扩容。
主从架构 -> 读写分离 -> 支撑10万+读QPS的架构
7.4、接下来要讲解的一个topic
redis replication
redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构