Redis总结一波

Redis是用c语言写的,数据存储在内存中,支持事务,持久化,LUA脚本,多种集群方案;
Redis读写分离,保证了数据的一致性
主表写,保证数据准确性,从表读;
redis-benchmark官方自带性能测试工具,正常一台redis的并发量为5.2万QPS;

RT:响应时间,一般指系统所有功能平均时间或者所有功能的最大响应时间;
TPS:吞吐量, 系统单位时间内处理请求的数量,当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加,两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致,与qps的区别是针对多个服务器;

QPS:每秒查询率,衡量服务器的性能(针对特定的服务器);

同步原理:
持久化有两种:RDB全量持久化和AOF增量持久化
**2.8版本之前,**使用旧版复制功能SYNC,非常耗时,执行BGSAVE命令生成RDB文件,将这个文件发送给从服务器;
2.8之后,使用PSYNC,具有完整重同步和部分重同步两种模式;
第一种用于 初次复制;
第二种 用于断线后复制; 将短线后的写命令放入缓存区进行增量同步,连上后,发送给从服务器;
功能由以下三个部分构成：
1） 主服务的复制偏移量（replication offset）和从服务器的复制偏移量量。
2） 主服务器的复制积压缓冲区（replication backlog）,默认大小为1M。 3） 服务器的运行ID，用于存储服务器标识：

高可用

手动主从切换
升级为主服务，执行命令：

slaveof no one

修改从服务器对应的主服务器,执行命令:

slave of  ip+port

人工,费事费力

sentinel哨兵模式
ping pong 机制

redis 常见数据结构以及使用场景分析

1. String
   常用命令: set,get,decr,incr,mget
   String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。 常规key-value缓存应用；
   常规计数：微博数，粉丝数等。
   2.Hash
   常用命令： hget,hset,hgetall 等。
   Hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，你可以直接仅
   仅修改这个对象中的某个字段的值。 比如我们可以Hash数据结构来存储用户信息，商品信息等;
   3.List
   常用命令: lpush,rpush,lpop,rpop,lrange等
   list 就是链表，Redis list 的应用场景非常多，也是Redis最重要的数据结构之一，比如微博的关注列表，粉丝列表，
   消息列表等功能都可以用Redis的 list 结构来实现;
   Redis list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。
   另外可以通过 lrange 命令，就是从某个元素开始读取多少个元素，可以基于 list 实现分页查询，这个很棒的一个功
   能，基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西（一页一页的往下走），性能高。
   4.Set
   常用命令： sadd,spop,smembers,sunion 等
   set 对外提供的功能与list类似是一个列表的功能，特殊之处在于 set 是可以自动排重的。
   当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在
   一个set集合内的重要接口，这个也是list所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。
   比如：在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis可以非常
   方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程，具体命令如下：

sinterstore key1 key2 key3 将交集存在key1内

5.Sorted Set
常用命令： zadd,zrange,zrem,zcard等
和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列。
举例： 在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维
度的消息排行榜）等信息，适合使用 Redis 中的 SortedSet 结构进行存储。

redis 设置过期时间

定期删除+惰性删除。

缓存雪崩和缓存穿透问题

缓存雪崩:同一时间大面积的失效,请求落到数据库,短时间承受大量请求而崩掉;
解决办法:
事前:尽量保证整个redis集群的高可用,发现机器宕机尽快补上,选择合适的内存淘汰策略;
事中:hystrix限流降级,有5000个请求,限制2000个请求,其它3000个请求,走降级方法,返回友好的提示;
事后:利用redis持久化机制保存的数据尽快恢复缓存;

缓存穿透: 请求缓存中不存在的数据,导致落在数据库上;
采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被bitmap拦截掉,还有一个更简单粗暴的方法(我们采用的就是这种),如果一个数据返回的数据为空(不管是数据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间很短,最长不超过五分钟;