进入redis的目录
src/redis-server /usr/local/redis/etc/redis.conf 指定配置文件启动
ps -ef |grep redis 查询启动状态
linux 连接redis客户端命令：
redis -cli -h 10.25.85.16 -p 6379 -a root
选择相关的库空间：select 1
展示密码与修改密码，连接到客户端后
config set requirepass 查询密码
config set requirepass test1234 重新设置密码、
reids 线程模型：单线程（内部一个线程处理，维护排队处理）、NIO、异步事件处理
reids 常用数据类型及操作： 1.String :应用场景：很常见的场景用于统计网站访问数量，当前在线人数等。incr命令(++操作)
2.list应用场景：1.最新消息排行榜。2.消息队列，以完成多程序之间的消息交换。可以用push操作将任务存在list中（生产者），然后线程在用pop操作将任务取出进行执行。（消费者）
3.hash应用场景：例如存储、读取、修改用户属性（name，age，pwd等）
4.set应用场景：1.利用交集求共同好友。2.利用唯一性，可以统计访问网站的所有独立IP。3.好友推荐的时候根据tag求交集，大于某个threshold（临界值的）就可以推荐
5.有序集合sorted set 6.key的通用操作，所有的数据类型都可以使用的和set很像，都是字符串的集合，都不允许重复的成员出现在一个set中。他们之间差别在于有序集合中每一个成员都会有一个分数(score)与之关联，Redis正是通过分数来为集合中的成员进行从小到大的排序。尽管有序集合中的成员必须是卫衣的，但是分数(score)却可以重复。应用场景：可以用于一个大型在线游戏的积分排行榜，每当玩家的分数发生变化时，可以执行zadd更新玩家分数(score)，此后在通过zrange获取几分top ten的用户信息
如何保证缓存中的数据与db中的一致最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。
读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。更新的时候，先更新数据库，然后再删除缓存。
为什么是删除缓存，而不是更新缓存？
原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。
问题：先更新数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。
解决思路：先删除缓存，再更新数据库。如果数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，所以去读了数据库中的旧数据，然后更新到缓存中。
比较复杂的数据不一致问题分析 数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改。完了，数据库和缓存中的数据不一样了...
redis的过期策略以及内存淘汰机制 redis采用的是定期删除+惰性删除策略。
定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。
内存淘汰机制在redis.conf中有一行配置：
maxmemory-policy volatile-lru
该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错
ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。
Redis 集群方案应该怎么做？都有哪些方案？1.twemproxy，大概概念是，它类似于一个代理方式， 使用时在本需要连接 redis 的地方改为连接 twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 redis，将结果再返回 twemproxy。
缺点： twemproxy 自身单端口实例的压力，使用一致性 hash 后，对 redis 节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。
2.codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新 hash 节点
3.redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash 槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。
取数十万次。再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次。
**数据更新前至少读取两次，**缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。
那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力。
redis提供了两种持久化方式RDB和AOFRDB是通过快照方式完成的，当满足一定条件时，redis会自动将内存中的数据持久化到磁盘。
在redis.conf中配置
快照设置规则 save {多少秒内} {数据变化了多少}
例如:save 100 1:在100秒内，至少有一个键被修改就进行快照;save 200 4:在200秒内，至少4个键被修改就进行快照。
RDB的优缺点 缺点:使用RDB进行持久化，在redis突然异常退出的时候，会丢失最后一次快照之后的数据。但是，可以根据组合设置自动快照的方式，降低数据损失，确保在接受范围内。如果数据较为重要，可以使用AOF方式 优点:使用RDB方式可以最大化redis性能，在快照过程中，我们可以看到主进程只需要fork出一个子进程即可，剩下的工作全部由子进程完成，父进程无需进行任何的磁盘I/O操作。但是，如果数据集较大，在fork子进程的时候比较耗时，会导致redis在一段时间内停止处理请求。
AOF（append only file）
redis通过将所有的写入命令记录到AOF文件中，来持久化数据。而将命令记录到AOF文件的过程，可以分成三个阶段:
命令传播缓存追加文件写入和保存(WRITE:将AOF缓存中的内容写入到AOF文件SAVE:调用fsync或者fdatasync函数，将AOF文件保存到磁盘中)缓存穿透
缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层。缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。
造成缓存穿透的基本原因有两个：
第一，自身业务代码或者数据出现问题。
第二，一些恶意攻击、爬虫等造成大量空命中。
缓存穿透问题解决方案：
1、缓存空对象 key,null
2、布隆过滤器 bit 数组，经过多次hash运算标记数据位置为1为存在，多个值hash运算可能会覆盖前值，所以有误判断
对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不
存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可
能不存在；当它说不存在时，那就肯定不存在。
在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截，当收到一个对key请求时先用布隆过滤器验证是key否存在，如果存在在进入缓存层、存储层。可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景，代码维护较为复杂，但是缓存空间占用少
缓存失效(击穿)由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。
解决方案
1、分布式互斥锁
只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。set(key,value,timeout)
2、设置热点缓存不过期，或分散key的过期时间
缓存雪崩由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不可用（宕机）或者大量缓存由于超时时间相同在同一时间段失效（大批key失效/热点数据失效），大量请求直接到达存储层，存储层压力过大导致系统雪崩。
解决方案
1、可以把缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务。利用sentinel或cluster实现
2、采用多级缓存，本地进程作为一级缓存，redis作为二级缓存，不同级别的缓存设置的超时时间不同，即使某级缓存过期了，也有其他级别缓存兜底
3、缓存的过期时间用随机值，尽量让不同的key的过期时间不同
redis 主从复制主从复制工作机制
当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。
复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。
主从配置
redis默认是主数据，所以master无需配置，我们只需要修改slave的配置即可。