大致为两种措施：
一、脚本同步：
1、自己写脚本将数据库数据写入到redis/memcached。
2、这就涉及到实时数据变更的问题（mysql row binlog的实时分析），binlog增量订阅Alibaba 的canal ，以及缓存层数据 丢失/失效 后的数据同步恢复问题。
二、业务层实现：
1、先读取nosql缓存层，没有数据再读取mysql层，并写入数据到nosql。
2、nosql层做好多节点分布式（一致性hash），以及节点失效后替代方案（多层hash寻找相邻替代节点），和数据震荡恢复了。
② redis缓存原理
1、Redis是一种内存高速cache，如果使用redis缓存，那经常被访问的内容会被缓存在内存中，需要使用的时候直接从内存调取，不知道比硬盘调取快了多少倍，并且支持复杂的数据结构，应用于许多高并发的场景中。
2、Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。zset是set的一个升级版本，他在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，zset会自动重新按新的值调整顺序。可以理解了有两列的mysql表，一列存value，一列存顺序。操作中key理解为zset的名字。
更多关于redis缓存原理，进入：https://www.abcgonglue.com/ask/66eab61616100681.html?zd查看更多内容
③ 如何在service层加入redis缓存
//放入缓存注解
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Inherited
public@interfaceCacheable{//放入
Stringkey();//缓存key
StringfieldKey();//field值
intexpireTime()default3600;
}
//从缓存中销毁注解
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public@interfaceCacheEvict{//销毁
Stringkey();
String[]fieldKey();
intexpireTime()default3600;
}
Aspect类
//环绕切入
@Around(value="@annotation(com.xx.cache.annotation.Cacheable)")
publicObjectcache(ProceedingJoinPointpjp){
Objectresult=null;
Methodmethod=getMethod(pjp);
Cacheablecacheable=method.getAnnotation(Cacheable.class);
StringfieldKey=cacheable.fieldKey();
if(cacheable.fieldKey().indexOf("#")==0){//动态变量存入方式
fieldKey=parseKey(cacheable.fieldKey(),method,pjp.getArgs());
}
if(useCache){//判断是否开启缓存开启缓存从缓存获取result
//获取方法的返回类型,让缓存可以返回正确的类型
ClassreturnType=((MethodSignature)pjp.getSignature()).getReturnType();
//使用redis的hash进行存取，易于管理
//result=JedisUtils.hget(cacheable.key(),fieldKey,method.getReturnType());
result=JedisUtils.hget(cacheable.key(),fieldKey,returnType);
if(result==null){
try{
result=pjp.proceed();
//Assert.notNull(fieldKey);
JedisUtils.hset(cacheable.key(),fieldKey,result);
logger.debug("The"+cacheable.key()+"addtoredis,thefieldKeyis"+fieldKey);
}catch(Throwablee){
e.printStackTrace();
}
}
returnresult;
}
try{
returnpjp.proceed();
}catch(Throwablethrowable){
throwable.printStackTrace();
returnnull;
}
}
//环绕切入
@Around(value="@annotation(com.xx.cache.annotation.CacheEvict)")
publicObjectevict(ProceedingJoinPointpjp){
//和cache类似，使用Jedis.hdel()删除缓存即可
if(useCache){//判断是否开启缓存
Methodmethod=getMethod(pjp);
CacheEvictcacheEvict=method.getAnnotation(CacheEvict.class);
String[]fieldKeys=cacheEvict.fieldKey();
intdeleteSuccessFlag=0;
for(StringfieldKey:fieldKeys){
if(fieldKey.indexOf("#")==0){//动态变量存入方式
Stringt=fieldKey;
fieldKey=parseKey(fieldKey,method,pjp.getArgs());
if(fieldKey==null){
logger.error("cacheevictfieldkey{}connotbenull,thatmaybecausedataconnotsync",t);
t=null;
}
}
deleteSuccessFlag+=JedisUtils.hdel(cacheEvict.key(),fieldKey==null?"":fieldKey);
logger.debug("Thereferencefieldkey:"+fieldKey+"for"+cacheEvict.key()+"hasbeendeletefromredis");
}
logger.debug("Delete"+deleteSuccessFlag+""+cacheEvict.key()+"fromredis");
}
try{
returnpjp.proceed();
}catch(Throwablee){
e.printStackTrace();
returnnull;
}
}
/**
*获取缓存的key
*key定义在注解上，支持SPEL表达式
*
*@paramkey
*@parammethod
*@paramargs
*@return
*/
privateStringparseKey(Stringkey,Methodmethod,Object[]args){
//获取被拦截方法参数名列表(使用Spring支持类库)
=();
String[]paraNameArr=u.getParameterNames(method);
//使用SPEL进行key的解析
ExpressionParserparser=newSpelExpressionParser();
//SPEL上下文
=newStandardEvaluationContext();
//把方法参数放入SPEL上下文中
for(inti=0;i<paraNameArr.length;i++){
context.setVariable(paraNameArr[i],args[i]);
}
returnparser.parseExpression(key).getValue(context,String.class);
}
使用，在service调用前使用：
@Cacheable(key="biz_member",fieldKey="#id")publicMemberget(Stringid){returnsuper.get(id);}@CacheEvict(key="member",fieldKey={"#member.id","#member.account"})publicSerializablesave(Membermember){return.insert(member);}@CacheEvict(key="member",fieldKey={"#member.id","#member.account"})publicvoiddelete(Membermember){.delete(member);}
④ web服务器怎么使用redis分步式缓存
Redis复制流程概述
Redis的复制功能是完全建立在之前我们讨论过的基于内存快照的持久化策略基础上的，也就是说无论你的持久化策略选择的是什么，只要用到了Redis的复制功能，就一定会有内存快照发生，那么首先要注意你的系统内存容量规划，原因可以参考我上一篇文章中提到的Redis磁盘IO问题。
Redis复制流程在Slave和Master端各自是一套状态机流转，涉及的状态信息是：
Slave 端：
REDIS_REPL_NONEREDIS_REPL_CONNECTREDIS_REPL_CONNECTED
Master端：
REDIS_REPL_WAIT_BGSAVE_STARTREDIS_REPL_WAIT_BGSAVE_ENDREDIS_REPL_SEND_BULKREDIS_REPL_ONLINE
整个状态机流程过程如下：
Slave端在配置文件中添加了slave of指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。
Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(最新版的Redis已经不需要让Slave阻塞)。
Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。
Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成。
Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。
整个复制过程完成，流程如下图所示：
Redis复制机制的缺陷
从上面的流程可以看出，Slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来非常多的问题。
比如一台线上正在运行的Master主库配置了一台从库进行简单读写分离，这时Slave由于网络或者其它原因与Master断开了连接，那么当Slave进行重新连接时，需要重新获取整个Master的内存快照，Slave所有数据跟着全部清除，然后重新建立整个内存表，一方面Slave恢复的时间会非常慢，另一方面也会给主库带来压力。
所以基于上述原因，如果你的Redis集群需要主从复制，那么最好事先配置好所有的从库，避免中途再去增加从库。
Cache还是Storage
在我们分析过了Redis的复制与持久化功能后，我们不难得出一个结论，实际上Redis目前发布的版本还都是一个单机版的思路，主要的问题集中在，持久化方式不够成熟，复制机制存在比较大的缺陷，这时我们又开始重新思考Redis的定位：Cache还是Storage？
如果作为Cache的话，似乎除了有些非常特殊的业务场景，必须要使用Redis的某种数据结构之外，我们使用Memcached可能更合适，毕竟Memcached无论客户端包和服务器本身更久经考验。
如果是作为存储Storage的话，我们面临的最大的问题是无论是持久化还是复制都没有办法解决Redis单点问题，即一台Redis挂掉了，没有太好的办法能够快速的恢复，通常几十G的持久化数据，Redis重启加载需要几个小时的时间，而复制又有缺陷，如何解决呢？
Redis可扩展集群搭建1. 主动复制避开Redis复制缺陷。
既然Redis的复制功能有缺陷，那么我们不妨放弃Redis本身提供的复制功能，我们可以采用主动复制的方式来搭建我们的集群环境。
所谓主动复制是指由业务端或者通过代理中间件对Redis存储的数据进行双写或多写，通过数据的多份存储来达到与复制相同的目的，主动复制不仅限于用在Redis集群上，目前很多公司采用主动复制的技术来解决MySQL主从之间复制的延迟问题，比如Twitter还专门开发了用于复制和分区的中间件gizzard(https://github.com/twitter/gizzard) 。
主动复制虽然解决了被动复制的延迟问题，但也带来了新的问题，就是数据的一致性问题，数据写2次或多次，如何保证多份数据的一致性呢？如果你的应用对数据一致性要求不高，允许最终一致性的话，那么通常简单的解决方案是可以通过时间戳或者vector clock等方式，让客户端同时取到多份数据并进行校验，如果你的应用对数据一致性要求非常高，那么就需要引入一些复杂的一致性算法比如Paxos来保证数据的一致性，但是写入性能也会相应下降很多。
通过主动复制，数据多份存储我们也就不再担心Redis单点故障的问题了，如果一组Redis集群挂掉，我们可以让业务快速切换到另一组Redis上，降低业务风险。
2. 通过presharding进行Redis在线扩容。
通过主动复制我们解决了Redis单点故障问题，那么还有一个重要的问题需要解决：容量规划与在线扩容问题。
我们前面分析过Redis的适用场景是全部数据存储在内存中，而内存容量有限，那么首先需要根据业务数据量进行初步的容量规划，比如你的业务数据需要100G存储空间，假设服务器内存是48G，那么根据上一篇我们讨论的Redis磁盘IO的问题，我们大约需要3~4台服务器来存储。这个实际是对现有业务情况所做的一个容量规划，假如业务增长很快，很快就会发现当前的容量已经不够了，Redis里面存储的数据很快就会超过物理内存大小，那么如何进行Redis的在线扩容呢？
Redis的作者提出了一种叫做presharding的方案来解决动态扩容和数据分区的问题，实际就是在同一台机器上部署多个Redis实例的方式，当容量不够时将多个实例拆分到不同的机器上，这样实际就达到了扩容的效果。
拆分过程如下：
在新机器上启动好对应端口的Redis实例。
配置新端口为待迁移端口的从库。
待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。
配置从库为新的主库。
移除老的端口实例。
重复上述过程迁移好所有的端口到指定服务器上。
以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。
Redis复制的改进思路
我们线上的系统使用了我们自己改进版的Redis,主要解决了Redis没有增量复制的缺陷，能够完成类似Mysql Binlog那样可以通过从库请求日志位置进行增量复制。
我们的持久化方案是首先写Redis的AOF文件，并对这个AOF文件按文件大小进行自动分割滚动，同时关闭Redis的Rewrite命令，然后会在业务低峰时间进行内存快照存储，并把当前的AOF文件位置一起写入到快照文件中，这样我们可以使快照文件与AOF文件的位置保持一致性，这样我们得到了系统某一时刻的内存快照，并且同时也能知道这一时刻对应的AOF文件的位置，那么当从库发送同步命令时，我们首先会把快照文件发送给从库，然后从库会取出该快照文件中存储的AOF文件位置，并将该位置发给主库，主库会随后发送该位置之后的所有命令，以后的复制就都是这个位置之后的增量信息了。
Redis与MySQL的结合
目前大部分互联网公司使用MySQL作为数据的主要持久化存储，那么如何让Redis与MySQL很好的结合在一起呢？我们主要使用了一种基于MySQL作为主库，Redis作为高速数据查询从库的异构读写分离的方案。
为此我们专门开发了自己的MySQL复制工具，可以方便的实时同步MySQL中的数据到Redis上。
（MySQL-Redis 异构读写分离）
总结：
Redis的复制功能没有增量复制，每次重连都会把主库整个内存快照发给从库，所以需要避免向在线服务的压力较大的主库上增加从库。
Redis的复制由于会使用快照持久化方式，所以如果你的Redis持久化方式选择的是日志追加方式(aof),那么系统有可能在同一时刻既做aof日志文件的同步刷写磁盘，又做快照写磁盘操作，这个时候Redis的响应能力会受到影响。所以如果选用aof持久化，则加从库需要更加谨慎。
可以使用主动复制和presharding方法进行Redis集群搭建与在线扩容。
⑤ Redis分布式缓存搭建
花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。
笔者安装中遇到的一些问题：
如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
这回编译通过了，提示让你最好make test一下/
执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升级tcl， yum install tcl
重新make test，如果还有error就删了目录，重新tar包解压重新make , make test
o/ All tests passed without errors! ，表示编译成功。
然后make install即可。
直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf &
redis.conf 配置文件里 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。
redis高可用方案有两种：
常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。
（1）sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
sentinel2.conf配置：
坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth
当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：
原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf
中配置：
坑2：哨兵配置文件要暴露客户端可以访问到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。
附springboot2.1 redis哨兵配置：
坑3：要注意配置文件.conf会被哨兵修改
redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。
曾经遇到过这样一个问题，大致的信息如下
slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !
最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。
（2）集群
当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 -> 中间件 -> Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。
Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。
每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。
reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。
搭建Redis cluster
redis.conf文件关键的几个配置：
启动6个集群节点
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
这时候这6个节点还是独立的，要把他们配置成集群：
说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。
上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。
最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。
查看集群状态：
坑1：暴露给客户端的节点地址不对
使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。
我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 mp.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：
然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！
解决办法，修改每个节点的redis.conf配置文件，找到如下说明：
所以增加配置：
然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）
重新使用Lettuce测试，这次终于连上了！
坑2：Lettuce客户端在master节点故障时没有自动切换到从节点
name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：
重新启动7002进程，
7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。
解决办法，修改Lettuce的配置：
笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。
重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）
Redis不保证数据的强一致性
Redis并不保证数据的强一致性，也就是取CAP定理中的AP
关于一致性Hash算法，可以参考 一致性Hash算法 - (jianshu.com)
Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。
比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。
关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。
与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。
所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。
这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。
Redis高可用方案 - (jianshu.com)
面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent.com)
深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs.com)
Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)
云服务器Redis集群部署及客户端通过公网IP连接问题
⑥ 缓存-redis 三种模式搭建和运行原理
标签： redis 缓存 主从 哨兵 集群
本文简单的介绍redis三种模式在linux的安装部署和数据存储的总结，希望可以相互交流相互提升。
对于Centos7在安装redis之前需要进行一些常用工具的安装：
关闭防火墙
正式安装redis
在redis进行maketest时候会出现一系列的异常，有如下解决方案：
用redis-server启动一下redis，做一些实验没什么意义。
要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动，操作不走如下：
RDB和AOF是redis的一种数据持久化的机制。 持久化 是为了避免系统在发生灾难性的系统故障时导致的系统数据丢失。我们一般会将数据存放在本地磁盘，还会定期的将数据上传到云服务器。
RDB 是redis的snapshotting，通过redis.conf中的save配置进行设置，如 save 60 1000:
AOF 是以appendonly方式进行数据的储存的，开启AOF模式后，所有存进redis内存的数据都会进入os cache中,然后默认1秒执行一次fsync写入追加到appendonly.aof文件中。一般我们配置redis.conf中的一下指令：
AOF和RDB模式我们一般在生产环境都会打开，一般而言，redis服务挂掉后进行重启会优先家在aof中的文件。
当启动一个slave node的时候，它会发送一个PSYNC命令给master node,如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据;否则如果是slave node第一次连接master node，那么会触发一次full resynchronization;
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。
master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,但是如果没有找到对应的offset，那么就会执行一次resynchronization。
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了，可以有如下配置：
slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。
在redis.conf配置文件中，上面的参数代表至少需要3个slaves节点与master节点进行连接，并且master和每个slave的数据同步延迟不能超过10秒。一旦上面的设定没有匹配上，则master不在提供相应的服务。
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为master宕机
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机
如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个slave来做切换，这个slave还得得到majority哨兵的授权，才能正式执行切换；
（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
4.3.2 slave的永久下线
让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行.
redis的集群模式为了解决系统的横向扩展以及海量数据的存储问题，如果你的数据量很大，那么就可以用redis cluster。
redis cluster可以支撑N个redis master,一个master上面可以挂载多个slave，一般情况我门挂载一个到两个slave，master在挂掉以后会主动切换到slave上面，或者当一个master上面的slave都挂掉后，集群会从其他master上面找到冗余的slave挂载到这个master上面，达到了系统的高可用性。
2.1 redis cluster的重要配置
2.2 在三台机器上启动6个redis实例
将上面的配置文件，在/etc/redis下放6个，分别为: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf
每个启动脚本内，都修改对应的端口号
2.3 创建集群
解决办法是 先安装rvm，再把ruby版本提升至2.3.3
使用redis-trib.rb命令创建集群
--replicas: 表示每个master有几个slave
redis-trib.rb check 192.168.31.187:7001 查看状体
3.1 加入新master
以上相同配置完成后，设置启动脚本进行启动；然后用如下命令进行node节点添加：
3.2 reshard一些数据过去
3.3 添加node作为slave
3.4 删除node
⑦ 接口添加redis缓存之后并发还是很低
把redis作为缓存使用已经是司空见惯，但是使用redis后也可能会碰到一系列的问题，尤其是数据量很大的时候，经典的几个问题如下：
(一)缓存和数据库间数据一致性问题
分布式环境下（单机就不用说了）非常容易出现缓存和数据库间孙旁的数据一致性问题，针对这一点的话，只能说，如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。我们只能郑昌采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括 合适的缓存更新策略，更新数据库后要及时更新缓存、缓存失败时增加重试机制，例如MQ模式的消息队列。
(二)缓存击则丛橡穿问题
⑧ redis千万数据放缓存合理么
Redis是一种高性能的内存数据库,它可以用来存储高速缓存数据。
将数据存储在缓存中可以提高系统的性能，因为从缓存中读取数据的速度比从数据库中读取数据的速度快得多。
但是，将所有数据都放入缓存中可能并不是最优解。缓存有一定的容量限制，如果缓存容量不足以容纳所有数据，那么缓存就会淘汰部分数据，这样就会导致缓存命中率降低，系统性能也会降低。因此，应该根据实际情况合理设置缓存容量，并将重要的、频繁使用的数据放入缓存中。
⑨ redis 缓存服务器 怎么给外部系统用
Redis介绍
Redis本质上一个Key/Value数据库，与Memcached类似的NoSQL型数据库，但是他的数据可以持久化的保存在磁盘上，解决了服务重启后数据不丢失的问题，他的值可以是string（字符串）、list（列表）、sets（集合）或者是ordered sets（被排序的集合），所有的数据类型都具有push/pop、add/remove、执行服务端的并集、交集、两个sets集中的差别等等操作，这些操作都是具有原子性的，Redis还支持各种不同的排序能力
Redis 2.0更是增加了很多新特性，如：提升了性能、增加了新的数据类型、更少的利用内存（AOF和VM）
Redis支持绝大部分主流的开发语言，如：C、Java、C＃、PHP、Perl、Python、Lua、Erlang、Ruby等等
官网：http://code.google.com/p/redis/
Redis性能
根据Redis官方的测试结果：在50个并发的情况下请求10w次，写的速度是110000次/s，读的速度是81000次/s
地址：http://code.google.com/p/redis/wiki/Benchmarks
一、安装过程：
最新稳定版，Redis 2.0.4 stable
wget http://redis.googlecode.com/files/redis-2.6.7.tar.gz （其他版本到官网下载即可）
tar zxf redis-2.6.7.tar.gz
cd redis-2.6.7
与其它软件不同的是，不需要configure。
make
装完了。
创建一个目录
mkdir /usr/local/redis2
cd src
cp redis-server redis-benchmark redis-cli ../redis.conf /usr/local/redis2
二、启动与停止：
cd /usr/local/redis2
启动 ./redis-server > /dev/null & 或者 ./redis-server redis.conf 或者 ./redis-server redis.conf 1>log.log 2>errlog.log （1为标准输出，2为错误输出）
停止 ./redis-cli shutdown
客户端连接 ./redis-cli
三、测试：
存值：
./redis-cli set hx value
取值：
./redis-cli get hx
> quit
退出连接
> dbsize
(integer) 12
当前数据库中key的数量
> info
服务器基本信息
monitor
实时转储收到的请求
config get
获取服务器的参数配置
flushdb
清空当前数据库
flushall
清除所有数据库
四、附注
redis.conf配置文件：
引用
#是否作为守护进程运行
daemonize yes
#配置pid的存放路径及文件名，默认为当前路径下
pidfile redis.pid
#Redis默认监听端口
port 6379
#客户端闲置多少秒后，断开连接
timeout 300
#日志显示级别
loglevel verbose
#指定日志输出的文件名，也可指定到标准输出端口
logfile stdout
#设置数据库的数量，默认连接的数据库是0，可以通过select N来连接不同的数据库
databases 16
#保存数据到disk的策略
#当有一条Keys数据被改变是，900秒刷新到disk一次
save 900 1
#当有10条Keys数据被改变时，300秒刷新到disk一次
save 300 10
#当有1w条keys数据被改变时，60秒刷新到disk一次
save 60 10000
#当mp .rdb数据库的时候是否压缩数据对象
rdbcompression yes
#mp数据库的数据保存的文件名
dbfilename mp.rdb
#Redis的工作目录
dir /home/falcon/redis-2.0.0/
########### Replication #####################
#Redis的复制配置
# slaveof <masterip> <masterport>
# masterauth <master-password>
############## SECURITY ###########
# requirepass foobared
############### LIMITS ##############
#最大客户端连接数
# maxclients 128
#最大内存使用率
# maxmemory <bytes>
########## APPEND ONLY MODE #########
#是否开启日志功能
appendonly no
# 刷新日志到disk的规则
# appendfsync always
appendfsync everysec
# appendfsync no
################ VIRTUAL MEMORY ###########
#是否开启VM功能
vm-enabled no
# vm-enabled yes
vm-swap-file logs/redis.swap
vm-max-memory 0
vm-page-size 32
vm-pages 134217728
vm-max-threads 4
############# ADVANCED CONFIG ###############
glueoutputbuf yes
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
#是否重置Hash表
activerehashing yes