Redis 总结汇总(精简版)

redis的优点

1. 丰富的数据类型 支持string，list，set，sorted set，hash
2. 支持持久化    -->开启持久化功能化后,重启redis,数据会自动通过持久化文件恢复
3. 支持事务
4. 支持主从
5. 速度快,因为数据存在内存中,类似于Hashmap,hashmap的优势就是查找和操作的时间复杂度都是o(1)
6. 丰富的特性: 可用于缓存,消息,按key设置过期时间,过期后自动删除

redis加密

redis客户端在向redis-server发送请求之前，先进行密码验证。

requirepass 1122334

这里我们通过requirepass将密码设置成“1122334”。

如果redis设置了密码，登陆的时候需要用-a 指定密码进行登录

redis相比memcached有哪些优势

(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis可以持久化其数据

redis常见性能问题和解决方案

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用树状结构，用单向链表结构更为稳定，即：Master（写） <- Slave1（读） <- Slave2（读） <- Slave3（读）...

这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

redis持久化的两种方式

1. RDB: 在不同的时间点,将redis的存储数据生成快照存储到磁盘等介质上

• 周期性
• 不影响数据写入
• 高效     -->一次性还原
• 完整性较差      -->故障前一次备份之间的数据,无法恢复

1. AOF: 将所有执行过的命令记录下来,相当于mysql的逻辑备份

• 实时性
• 完整性好
• 体积大     -->所有指令都记录下来了

1. 方式

缓存：不用开启任何持久方式,redis将变成一个纯内存数据库.

双开:因RDB数据不实时，但同时使用两者时服务器只会找AOF文件,所以RDB留作万一的手段。

AOF  写入速度快

RDB  写入速度慢

redis的命令

key *  查看所有key

del     删除key

expire   给key设置过期时间

ttl       查看key的剩余有效期

exists   查看key是否存在  0不存在  1 存在

info    查看redis的信息

flushdb  清空数据(慎用)

hset   添加hash类型key的field的值

hget   获取

hmset  批量添加

hmget  批量获取

redis的相关工具

./redis-benchmark     #用于进行redis性能测试的工具

./redis-check-dump    #用于修复出问题的dump.rdb文件    

./redis-cli           #redis的客户端

./redis-server        #redis的服务端

./redis-check-aof     #用于修复出问题的AOF文件

./redis-sentinel      #用于集群管理

redis主从

为了纯粹的冗余备份,提高性能

主从架构中,可以考虑关闭主服务器的数据持久化功能,从服务器保持持久化功能,提高主服务器性能降低压力

从服务器一般设为只读,防止错误修改,但是从服务器仍然可以接受CONFIG等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。

redis-sentinel  哨兵模式

Sentinel(哨兵)用来监控redis集群master状态的工具(高可用)

1. 工作模式

哨兵每秒ping一次 范围内的master 和Slave和其他哨兵,如果在规定时间没有回复,就被认为主观下线

当有足够数量(半数及以上)哨兵确认master主观下线,就会被标记为客观下线

如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave 

Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

主观下线: 当前哨兵对某个redis服务器做出的下线判断

客观下线: 多个哨兵(大于或配置文件的值)对服务器做出下线判断后,被称为客观判断

Redis Cluster 去中心化集群

单个master会有容量和压力问题,并发问题(10万/秒) 

搭建集群,内存会大很多倍,压力会被分担,容量变大,并发变大

redis cluster 特点

1. 所有redis节点彼此互联(ping - pong机制),内部使用二进制协议优化传输速度和带宽
2. 客户端与redis节点直连,不需要中间proxy层,客户端不需要连接集群所有节点,连接集群中任何一个可用节点
3. 节点的fail是通过集群中超过半数节点检测失效才生效

Redis 集群中内置了 16384 个哈希槽

如果集群任意一个主节点挂掉,且当前主节点没有从节点，则集群将无法继续

添加节点与删除节点

添加: 如果用户将1新节点D添加到集群中,那么集群只需要将节点 A,B,C中的某些节点移动到D节点就可以了

删除 : 如果用户要从集群中移除节点A,那么集群只需要将节点A中的所有哈希槽点移动到其余节点,然后在移除空白的节点A就可以了(节点中存在槽点不可被移除)

nuhop ./redis-cli 

启动机器

cd /data/redis/src/

nohup ./redis-server ../cluster/7000/redis.conf &

单机进入客户端  ./redis-cli

# 登录集群客户端，-c标识以集群方式登录

./redis-cli -h 192.168.116.172 -c -p 7000

客户端模式

cluster info  #查看集群信息

CLUSTER nodes #查看集群节点信息(随便登陆一个客户端即可)

缓存组件也层出不进，常见的有

JCache：Java缓存API。由JSR107定义，定义了5个核心接口，分别是CachingProvider，CacheManager，Cache，Entry和Expriy

EhCache：纯Java的进程内缓存框架，jvm虚拟机中缓存、速度快，效率高，是Hibernate中默认的CacheProvider，但是共享缓存与集群分布式应用整合不方便

Redis：生态完善，通过socket访问缓存服务，效率上是比EhCache低的，但是在集群模式、分布式应用上就比较成熟，是大型应用首先中间件

Caffeine：Caffeine是使用Java8对Guava缓存的重写版本,有人称它为缓存之王

缓存雪崩

缓存雪崩指的是缓存同一时间大面积失效,所以,后面的请求都回落到数据库上,造成数据库短时间内承受大量请求崩掉.

简单理解: 原有缓存到期失效,新的缓存未到,在这期间本该访问缓存的请求全部访问数据库,而对CPU和内存造成巨大压力,严重的会造成数据库宕机,从而形成一系列连锁反应,造成整个系统崩溃.

解决办法:

1. 事前 做缓存的高可用性 -->缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。  Redis备份和快速预热  提前演练
2. 事中 缓存降级  用ehcache等本地缓存(暂时支持)，主要还是对源服务访问进行限流、资源隔离（熔断）、降级等。

降级的最终目的是保证核心服务可用，即使是有损的。

1. 事后 利用 Redis 持久化机制保存的数据尽快恢复缓存

缓存穿透

​

查询一个不存在的数据,请求会落到数据库上面,造成数据库短时间承受大量请求崩掉.

简单的理解为：缓存穿透是指查询一个一定不存在的数据，由于缓存不命中，接着查询数据库也无法查询出结果，因此也不会写入到缓存中，这将会导致每个查询都会去请求数据库，造成缓存穿透。

解决办法:

1. 布隆过滤器  -->这是最常见的一种解决方法了，它是将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压 力。对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；
2. 缓存空对象  ->如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可

缓存预热

​ 缓存预热是指系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。用户会直接查询事先被预热的缓存数据。

1、直接写个缓存刷新页面，上线时手工操作下；

2、数据量不大，可以在项目启动的时候自动进行加载；

目的就是在系统上线前，将数据加载到缓存中

如何解决Redis，mysql双写一致性？

1.最经典的缓存+数据库读写的模式:

读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。

更新的时候，先更新数据库，然后再删除缓存。

2.给缓存设置过期时间，这种方案下，可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。