Redis 常见的性能问题和解决方法

没有评论

2012 年 07 月 21 日 at 下午 10:22分类:NoSQL

1.Master写内存快照
save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。
2.Master AOF持久化
如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。
3.Master调用BGREWRITEAOF
Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。
下面是我的一个实际项目的情况,大概情况是这样的:一个Master,4个Slave,没有Sharding机制,仅是读写分离,Master负责写入操作和AOF日志备份,AOF文件大概5G,Slave负责读操作,当Master调用BGREWRITEAOF时,Master和Slave负载会突然陡增,Master的写入请求基本上都不响应了,持续了大概5分钟,Slave的读请求过也半无法及时响应,Master和Slave的服务器负载图如下:
Master Server load:

Slave server load:

上面的情况本来不会也不应该发生的,是因为以前Master的这个机器是Slave,在上面有一个shell定时任务在每天的上午10点调用BGREWRITEAOF重写AOF文件,后来由于Master机器down了,就把备份的这个Slave切成Master了,但是这个定时任务忘记删除了,就导致了上面悲剧情况的发生,原因还是找了几天才找到的。
将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题,设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入。最好是不开启Master的AOF备份功能。
4.Redis主从复制的性能问题
第一次Slave向Master同步的实现是:Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。第二次以及以后的同步实现是:Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上,只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞,但由于Redis使用单线程服务,如果Master快照文件比较大,那么第一次全量传输会耗费比较长时间,且文件传输过程中Master可能无法提供服务,也就是说服务会中断,对于关键服务,这个后果也是很可怕的。
以上1.2.3.4根本问题的原因都离不开系统io瓶颈问题,也就是硬盘读写速度不够快,主进程 fsync()/write() 操作被阻塞。
5.单点故障问题
由于目前Redis的主从复制还不够成熟,所以存在明显的单点故障问题,这个目前只能自己做方案解决,如:主动复制,Proxy实现Slave对Master的替换等,这个也是Redis作者目前比较优先的任务之一,作者的解决方案思路简单优雅,详情可见 Redis Sentinel design draft http://redis.io/topics/sentinel-spec。
总结
Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化。
如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。
为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内。
尽量避免在压力较大的主库上增加从库
为了Master的稳定性,主从复制不要用图状结构,用单向链表结构更稳定,即主从关系为:Master<–Slave1<–Slave2<–Slave3…….,这样的结构也方便解决单点故障问题,实现Slave对Master的替换,也即,如果Master挂了,可以立马启用Slave1做Master,其他不变。 本文转载自:http://blog.nosqlfan.com/html/4077.html

redis中使用multi和pipeline以及不使用这两名字的区别

没有评论

2012 年 07 月 21 日 at 下午 10:16分类:PHP

看了手册的都知道multi这个命令的作用就好比是mysql的事务的功能,但是大家都知道事务吗,就是在操作的过程中,把整个操作当作一个原子来处理,避免由于中途出错而导致最后产生的数据不一致,而产生BUG ,Mysql的事务功能可以做到这点,但是在redis中的multi,手册中说是把多个命令当作个事务来处理,但是在真正的测试之后发现并没有所说的事务的功能,个人经过测试发现,只有把他watch命令结合起来用,方可显现出其具有事务的功能,所以这点很是迷惑,关键是有一点很诧异,当启用了multi命令之后整个redis的读写会相对于没有使用multi的的读写要慢一点,我通过读写100W条数据发现,他们的速度相差600多毫秒,搞不清楚为什么相差这么多!个人觉得没有必要,还是不要使用这个multi的为好!
至于redis的pipeline命令,看手册都知道,它能够让(多条)执行命令简单的,更加快速的发送给服务器,但是没有任何原子性的保证,能不能保证原子性这个我没有测试,但是这个速度我测试了下,确实是吃了一惊啊!相比于没有使用pipeline的读写操作,使用了pipeline命令的操作要快12倍不止啊!这个效率高的。。。。
下面是我的测试代码:欢迎拍砖。

<?php

set_time_limit(0);

//计时函数
function G($start,$end='',$dec=4)
{
    static $_info = array();
	if (!empty($end))
    {
        if(!isset($_info[$end])) $_info[$end] = microtime(TRUE);
        $sconds = number_format(($_info[$end]-$_info[$start]), $dec) * 1000;
        echo "{$sconds}ms<br />";
    }
    else
    {
        $_info[$start] = microtime(TRUE);
    }
}

$redis = new Redis();
$redis->connect('127.0.0.1');

G('t');
$redis->pipeline();
for ($i=0; $i < 100000 ; $i++) { 
   $redis->set("test_{$i}", pow($i, 2));
   $redis->get('test_{$i}');
}
$redis->exec();
G('t','r');

G('m');
$redis->multi();
for ($i=0; $i < 100000 ; $i++) { 
   $redis->set("test_{$i}", pow($i, 2));
   $redis->get('test_{$i}');
}
$redis->exec();
G('m','i');

$redis->flushdb();

G('f');
for ($i=0; $i < 100000 ; $i++) { 
   $redis->set("test_{$i}", pow($i, 2));
   $redis->get('test_{$i}');
}
G('f','e');

?>

这是返回的结果:
//pipeline的执行时间
1926.5ms
//multi的执行时间
27725.7ms
//正常情况下
24832.1ms