❶ redis master宕机和脑裂
两个配置可以减少异步复制和脑裂导致的数据丢失：
min-slaves-to-write 1
min-slaves-max-lag 10
解释：要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了
（卖竖1）减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
（2）减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送弊塌数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求，这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失
上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有中卜大slave给自己ack，那么就拒绝新的写请求。
因此在脑裂场景下，最多就丢失10秒的数据
client可以采取的措施，第一做服务降级。第二 将数据灌入消息队列，过段时间再写
❷ redis宕机自动重启
Redis服务器可以配置宕机后自动重启的功能，这样可以避免因为宕机造成的影响。可以在 Redis 配置姿桥文件中添加相应迟册汪的配码仔置内容，来实现 redis 宕机自动重启的功能。
❸ redis 宕机数据怎么办
用redis保存的*.rdb文件恢复即喊孝滚可。
另外redis还有AOF功慎槐能，启动时可以自动恢复到前一条查询。郑余
❹ redis内存满了,会宕机吗
接下来一起探讨下，Redis的内存淘汰策略。
redis的配置文件不一定使用的是安装目录下面的redis.conf文件，启动redis服务的时候是可以传一个轿贺参数指定redis的配置文件的
既然可以设置Redis最大占用内存大小，那么配置的内存就有用完的时候。那在内存用完的时候，还继续往Redis里面添加数据不就没内存可用了吗？
实际上Redis定义了几种策略用来处理这种情况：
noeviction(默认策略) ：对于写请求不再提供服务，直接返回错误（DEL请求和部分特殊请求除外）
allkeys-lru ：从所有key中使用LRU算法进行淘汰
volatile-lru ：从设置了过期时间的key中使用LRU算法进行淘汰
allkeys-random ：从所有key中随机淘汰数据
volatile-random ：从设置了过期时间的key中随机淘汰
volatile-ttl ：在设置了过期时间的key中，根据key的过期时间进行淘汰，越早过期的越优先被淘汰
上面说到了Redis可使用最做帆滑大内存使用完了，是可以使用LRU算法进行内存淘汰纯腊的，那么什么是LRU算法呢？
❺ redis怎么会崩溃
由于redis存储在内存中且提供一般编程语言常用的数据结构存储类型，所以经常被用于做服务器崩溃宕机的数据恢复处理。
服务器可以在某些指定过程中将需要保存的数据以json对象等方式存储到redis中，也就是我们常说的快照，当服务器运行时读取redis来判断是否有待需要恢复数据继续处理的业务。
当一次业务处理结束后再删除redis的数据即可。
redis提供两种将内存数据导出到硬盘实现数据备份的方法：
RDB方式(默认)
RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。RDB是redis默认采用的持久化方式，在配置文件中已经预置了3个条件：
save 900 1 # 900秒内有至少1个键被更改则进行快照
save 300 10 # 300秒内有至少10个键被更改则进行快照
save 60 10000 # 60秒内有至少10000个键被更改则进行快照
可以存在多个条件，条件之间是“或”的关系，只要满足其中一个条件，就会进行快照。 如果想要禁用自动快照，只需要将所有的save参数删除即可。
Redis默认会将快照文件存储在当前目录(可CONFIG GET dir来查看)的mp.rdb文件中，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。
Redis实现快照的过程
Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。
在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。
Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩（可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。
除了自动快照，还可以手动发送SAVE或BGSAVE命令让Redis执行快照，两个命令的区别在于，前者是由主进程进行快照操作，会阻塞住其他请求，后者会通过fork子进程进行快照操作。 Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20～30秒钟。 通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。
AOF方式
默认情况下Redis没有开启AOF(append only file)方式的持久化，可以在redis.conf中通过appendonly参数开启：
appendonly yes
在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些
开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：
appendfilename appendonly.aof
配置redis自动重写AOF文件的条件
auto-aof-rewrite-percentage 100 # 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据
auto-aof-rewrite-min-size 64mb # 允许重写的最小AOF文件大小
配置写入AOF文件后，要求系统刷新硬盘缓存的机制
# appendfsync always # 每次执行写入都会执行同步，最安全也最慢
appendfsync everysec # 每秒执行一次同步操作
# appendfsync no # 不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），最快也最不安全
Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少
我们简单做一个定时计数器的小程序
[javascript]view plain
redis=require('redis'),//导入js模块
RDS_PORT=1379,//端口号
RDS_HOST='47.93.112.119',//服务器IP
RDS_OPTS={},//设置项
redisdb=redis.createClient(RDS_PORT,RDS_HOST,RDS_OPTS);//创建连接
redisdb.select(20);//指定分区库
redisdb.on('ready',function(res){
console.log('ready');
});
redisdb.on('connect',function(){
console.log('connect');
});
exports.redisdb=redisdb;
functionredis_opt(opt,key,value,callback){
if(opt=='get'){
redisdb.get(key,function(err,data){
if(err==null){
callback(data);
}
else{
callback(err);
}
});
}
elseif(opt=='set')
{
redisdb.set(key,value,function(err,result){
if(err==null){
callback(result);
}
else{
callback(err);
}
});
}
elseif(opt=='del')
{
redisdb.del(key,function(err,result){
if(err==null){
callback(result);
}
else{
callback(err);
}
});
}
else
{
callback("erroropt!");
}
}
functionupdate(key)
{
redis_opt("get",key,null,function(data){
console.log("theredisdatais"+data);
if(data){
count=parseInt(data);
redis_opt("set",key,++count,function(data){
console.log("set"+count+""+data);
});
}
else{
redis_opt("set",key,10000,function(data){
console.log("set"+10000+""+data);
});
}
});
}
functionclear(key)
{
redis_opt("del",key,null,function(ret){
console.log("del"+key+""+ret);
});
}
functionmain()
{
varkey="count_test";
setInterval(function(){clear(key)},5000);
setInterval(function(){update(key)},1000);
}
//testmain();
main();
以上代码为简单的计时器函数，即服务器启动后定时读取redis的数据，如果存在则累加修改，不存在则初始化，同时为了方便说明，又设置了一个定时删除数据的定时器。
❻ 如何解决redis高并发客户端频繁time out
redis为什么会有高并发问题
redis的出身决定
Redis是一种单线程机制的nosql数据库，基于key-value，数橘汪据可持久化落盘。由于单线程所以redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对redis进行并发访问时会出现问题。发生连接超笑指时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混圆升仔乱造成。
同时，单线程的天性决定，高并发对同一个键的操作会排队处理，如果并发量很大，可能造成后来的请求超时。
在远程访问redis的时候，因为网络等原因造成高并发访问延迟返回的问题。
解决办法
在客户端将连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。
服务器角度，利用setnx变向实现锁机制。
❼ 每天一个知识点：宕机情况下，Redis 如何实现快速恢复
上一篇文章，我们讲到了宕机情况下，Redis 如何进行数据备份，那么，数据备份之后如何快速恢复呢？我的建议是使用内存快照（Redis Database）。
AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢核没复得很缓慢，影响到正常使用。RDB 既可以保证可靠性，还能在宕机时实现快速恢复。
Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，这就类似于给 100 个人拍合影，把每一个人都拍进照片里。这样做的好处是，一次性记录了所有数据，一个都不少。
Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。
bgsave 可以避免阻塞，但避免阻塞和正常处理写操作并不是一回事。此时，主线程的确没有阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线链竖程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。
Redis 4.0 中提出了一个棚氏大混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。
关于 AOF 和 RDB 的选择问题，有三点建议：