sunnylg的博客

参考网站:http://blog.nosqlfan.com/html/4077.html本文来自温柔一刀的分享，介绍了他在实际工作中遇到的一些Redis问题以及对应的规避和解决方案，如果你也在用Redis，那么可能其中有一些经验可供参考。原文链接：http://zhupan.iteye.com/blog/15761081.Master写内存快照save命令调度rdbSave函数

这几年的线上业务表明，redis这个内存数据库，它的高性能、稳定性都是不用怀疑的，但我们塞进redis的数据过多，内存过大，那如果出问题，那它可能会带给我们的就是灾难性(我想很多公司都遇到过) 这里列举一下，我们遇到的一些问题：1 主库宕机先来看一下主库宕机容灾过程：如下图在主库宕机的时候，我们最常见的容灾策略为“切主”。具体为从该集群剩余从库中选出一个从库并将

一、背景: 选择合适的使用场景   很多时候Redis被误解并乱用了，造成的Redis印象：耗内存、价格成本很高：   1. 为了“赶时髦”或者对于Mysql的“误解”在一个并发量很低的系统使用Redis，将原来放在Mysql数据全部放在Redis中。     ----（Redis比较适用于高并发系统，如果是一些复杂Mis系统，用Redis反而麻烦，因为单从功能讲Mysql要更为强大，

一、背景1. AOF:    Redis的AOF机制有点类似于Mysql binlog，是Redis的提供的一种持久化方式（另一种是RDB），它会将所有的写命令按照一定频率(no, always, every seconds)写入到日志文件中，当Redis停机重启后恢复数据库。      2. AOF重写：     (1) 随着AOF文件越来越大，里

Redis 2.4版本做了很多功能改进，尤其是aof这块变动较大。增加了自动的bgrewriteaof，开启两个后台线程来避免主线程fsync、rename、close等阻塞操作，另外修复了出现重复命令进入aof文件的bug，下面是基于2.4.1的源码aof这块的改进分析。旧的版本问题主要有:1 主线程aof的每次fsync(everysecond模式)在高并发下时常出现100ms

背景    公司的redis有时background save db不成功，通过log发现下面的告警，很可能由它引起的：[13223] 17 Mar 13:18:02.207 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix thi

redis 配置 参数 详解张映 发表于 2015-04-30分类目录： nosql标签：nosql, redis, 参数, 配置redis配置参数，非常的多，下面罗列了一些redis 常用参数配置，以及中文注释。查看复制打印?/********************************* GENERAL

1.redis持久化 RDB 和 AOF对比 以及实现细节2.redis容灾备份具体参见 http://www.redis.cn/topics/persistence.html

全面剖析Redis Cluster原理和应用1.Redis Cluster总览1.1 设计原则和初衷在官方文档Cluster Spec中，作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个：性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲