初步认识Redis

官方介绍：

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。

一：五大数据类型

• String（字符串类型）
• List（列表）
• Set（集合）
• Hash（哈希）
• Zset（有序集合）

二：三种特殊数据类型

• geospatial（地理位置）
  -实际场景：错用于存储位置，位置共享、附近的人
• hyperloglog（基数）
  • 实际场景： 多数用来做统计，结合bitmaps使用：统计页面实时 UV 数、统计注册 IP 数、统计每日访问 IP 数、统计页面实时 UV 数、统计在线用户数、统计用户每天搜索不同词条的个数
• bitmap
  • 实际场景：同上，bitmap标识哪些用户活跃，hyperloglog计数

三：事务

Redis事务本质：一组命令的集合！一个事务的所有命令都会被序列化，在事务的执行过程中，会按照顺序执行！
一次性、顺序性、排他性！执行一些列的命令！
Redis事务没有隔离级别的概念
所有的命令在事务中，并没有直接被执行，只有发起执行命令的时候才会执行!Exec
Redis单条命令式保证原子性，但是事务不保证原子性！

Redis的事务执行：

• 开启事务（multi）
• 命令入队（…）
• 执行事务（exec）

Redis事务相关命令：

• MULTI：开启事务
• EXEC：执行事务中的所有操作命令
• DISCARD：取消事务，放弃执行事务块中的所有命令。
• WATCH：监视一个或多个key，如果事务在执行前，这个key（或者多个key）被其他命令修改，则事务被中断，不会执行事务中的任何命令。
• UNWATCH：取消WATCH对所有key的监视

与MYsql 的对比

Redis的watch实现乐观锁，使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种方式。

四：Redis.conf 文件详解

帮助文档：https://www.cnblogs.com/wsxdev/p/11594678.html

五：Redis持久化

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器的数据状态也会消失，所以Redis提供了持久化功能！

RDB（Redis DataBase）

简述：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读取到内存里。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，在用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！
rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的

优点:

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高

缺点：

1. 需要一定的时间间隔进行进程操作！如果redis意外挂了，这个最后一次修改数据就没有了！
2. fork进程的时候，会占用一定的内容空间

AOF（Append Only File)

简述：将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部执行一遍！

以日志的形式来记录每个操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以修改文件，redis启动之初或读取文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将指令从前到后执行一次已完成数据的恢复工作
Aof保存的是APPendonly.aof文件

优点：

1. 每一次修改都同步，文件的完整会更好！
2. 每秒同步一次，可能会丢失一秒的数据
3. 从不同步，效率最高的！

缺点：

4. 相对于数据文件来说，aof远远大于rdb，修复的速度也比edb慢！
5. aof运行效率也要比rdb慢，所以我们redis默认配置就是rdb持久化！

六：Redis发布订阅

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。
Redis客户端可以订阅任意数量的频道。
订阅/发布消息图：

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

七：主从复制

简述： 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（maste/leader）,后者称为从节点（slave/follower）；数据的复制是单向的，只能由主节点到从节点。 Master以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点；
一个主节点有多个从节点（或者没有），但是一个从节点只能有一个主节点

主从复制的作用主要包括：

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
   读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

服务器配置：在丛机的配置里面配置主机的ip端口和密码（密码可选配）

复制的原理：

Slave启动成功连接到maaster后会发送一个sync同步命令
Master接收到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，
增量复制：Master继续将新的所有收集到的修改命令一次传给slave，完成同步。
只要重新连接master，一次完全同步（全量复制）将会被 自动执行

八：哨兵模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
简述： 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
  

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改

# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

# 启动Redis服务器进程
./redis-server ../redis.conf
# 启动哨兵进程
./redis-sentinel ../sentinel.conf

九：缓存穿透和雪崩

缓存穿透（查不到）

概念：
缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（秒杀！），于是都去请求了持久层数据。这会给持久层数据造成很大的压力，这时候就相当于出现了缓存穿透。
解决方案：

• 布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；
  
• 缓存空对象；当存储层不命中后，即使返回的空对象也将其缓存起来，同事会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；
  
  但是这种方法会存在两个问题：
• 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键；因为这当中可能会有很多的空值的键；
• 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（量太大）

概述 ：
指一个key非常热点，在不停的扛着大并发,大并发集中对着一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，直接请求数据库，就像在一个屏障上凿开一个洞。
当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力过大。
解决方案：

1. 设置热点数据永不过期；从缓存层面看,没有设置过期时间，所以不会出现热点key过期后产生的问题。
2. 加互斥锁；分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待锁即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

**概念 : **
缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis宕机！
解决方案：

1. redis高可用：多搭建几个（异地多活）
2. 先留降级：在缓存失效后，通过加锁或者队列来控制读数据写缓存的线程数量。比如对某一个key只允许一个线程查询数据和写缓存，其他线程等待。
3. 数据预热：提前吧数据缓存到内存里。设置不同的过key

以上内容都由网络学习而来，如有侵权，请及时联系！！！