redis（一）redis详解以及redis的三种集群方式

目录

 

一、redis是什么？

二、redis应用的场景有哪些？

三、为什么要使用redis

四、redis和mysql的区别

五、redis的单线程和高性能

六、redis的三种集群方式

---

一、redis是什么？

Redis是一个速度非常快的基于内存的支持Key-Value非关系数据库

二、redis应用的场景有哪些？

缓存

缓存可以说是Redis最常用的功能之一了，合理的缓存不仅可以加快速度的访问速度，以及可以减少后端的压力(通常就是MySQL的压力)。可以说，一个合理的缓存可以极大地提高网站的性能。

排行榜系统

利用Redis的列表和有序集合的特点，可以制作排行榜系统，而排行榜系统目前在商城类、新闻类、博客类等等，都是比不可缺的。

计数器应用

计数器的应用基本和排行榜系统一样，都是多数网站的普遍需求，如视频网站的播放计数，电商网站的浏览数等等，但这些数量一般比较庞大，如果存到关系型数据库，对MySQL或者其他关系型数据库的挑战还是很大的，而Redis基本可以说是天然支持计数器应用。

消息队列系统

Redis支持发布订阅系统和阻塞队列的功能，可以充当一般的消息队列功能，虽然和专业的消息队列MQ比如RebbitMQ比起来还优点差距，但也基本够用了，比如celery的异步模型，Redis也是celery官方指定的2种队列的一种。
社交网络

对于社交网络来说，一般用户量是及其庞大的，此时的关系型数据库就捉襟见肘了，比如好有点赞、关注、推送等等功能，用Redis就能比较轻松地实现这些功能。

三、为什么要使用redis

1、速度快

说到Redis的速度快，大家的第一反应一定是内存读取，那是肯定的，但如果面试的时候仅仅说到这点，那还是远远不够的，至少还有以下三点要补充：

    Redis是用C语言实现的，而众所周知，C语言是“距离”操作系统最近的的编程语言，执行速度快
    Redis采用了单线程的架构(这点很容易遗忘，但是是Redis的最重要特性)，避免了多线程的资源竞争问题
    Redis的源码非常精简，可以说是集性能和优雅于一身的代码

2、基于键值对的服务器

Redis的全称是Remote Dictionary Server，是集合了五种数据结构：字符串、列表、哈希、集合、有序集合，可以说五种数据结构都是围绕于key-value的形式，而value不仅仅可以是值，还能是具体的数据结构，这给予了Redis强大的变化性和灵活能力。
丰富的功能

除了数据结构的强大，另外就是Redis所提供的丰富的功能了：

    提供了key过期的功能，这能运用于实现缓存
    提供了发布订阅的功能，可运用于消息队列，如celery
    支持lua脚本功能，当觉得Redis的命令实现功能不够时，就能利用lua来创建新的功能
    提供了简单的事务功能，不过不能支持回滚，但也能一定程度上保持事务的特性
    提供了pipeling功能，这样客户端可以将多条命令一次io，减少了网络的开销

3、简单稳定

Redis的简单表现在两方面，一方面是在3.0版本之前源代码仅3万行，后面3.0加入了集群后代码加到了5万行，而5万行的源代码对于开发人员来说，要理解掌握它也显得并不是那么难；另一方面就是Redis是单线程的结构，这使得Redis的服务端处理模型变得简单，客户端开发也显得简单。
Redis虽然代码少，并且是单线程的，但是它又非常的稳定，很少会出现因为自身bug而down掉的情况。

4、客户端语言多

Redis目前基本可以说和MySQL的知名度一样高了，太多的运用场景，太多的支持语言，常见的比如：java的jedis，Python的redis、PHP、C、C++等等。

5、持久化

Redis还支持两种方式的持久化，即将数据写入磁盘的方法，RDB和AOF，两种方法各有利弊，这里就不详细介绍了。

6、主从复制

那数据库的主从复制、集群功能是非常重要的，可以在Redis异常挂了后不影响客户端的使用，而Redis也是支持主从复制功能。

7、高可用和分布式

Redis从2.8版本后提供了高可用实现的Redis Sentinel，即Redis的“哨兵机制”，可以保证Redis节点的故障发现和自动转移，这实现了Redis强大的分布式功能。

深入了解的话，可以看《Redis的开发于运维》

另外因为源码也不多，喜欢源码的可以看《Redis的设计与实现》，是基于源码地角度来介绍Redis。
 

四、redis和mysql的区别

       mysql是持久化存储，存放在磁盘里，检索的话，会涉及到一定的IO(涉及到IO，速度肯定慢)，为了解决这个瓶颈，于是出现了缓存，比如现在用的最多的 memcached(简称mc)。首先，用户访问mc，如果未命中，就去访问mysql，之后像内存和硬盘一样，把数据复制到mc一部分。

　　redis和mc都是缓存，并且都是驻留在内存中运行的，这大大提升了高数据量web访问的访问速度。然而mc只是提供了简单的数据结构，比如 string存储；redis却提供了大量的数据结构，比如string、list、set、hashset、sorted set这些，这使得用户方便了好多，毕竟封装了一层实用的功能，同时实现了同样的效果，当然用redis而慢慢舍弃mc。

　　内存和硬盘的关系，硬盘放置主体数据用于持久化存储，而内存则是当前运行的那部分数据，CPU访问内存而不是磁盘，这大大提升了运行的速度，当然这是基于程序的局部化访问原理。

　　推理到redis+mysql，它是内存+磁盘关系的一个映射，mysql放在磁盘，redis放在内存，这样的话，web应用每次只访问redis，如果没有找到的数据，才去访问Mysql。

　　然而redis+mysql和内存+磁盘的用法最好是不同的。

前者是内存数据库，数据保存在内存中，当然速度快。

后者是关系型数据库，功能强大，数据访问也就慢。

像memcache，mongoDB，Redis，都属于No sql系列。

不是一个类型的东西，应用场景也不太一样，还是要看你的需求来决定。

五、redis的单线程和高性能

1、Redis的单线程和高性能

Redis 单线程为什么还能这么快？
因为它所有的数据都在内存中，所有的运算都是内存级别的运算（纳秒），而且单线程避免了多线程的切换（上下文切换）性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。

Redis 单线程如何处理那么多的并发客户端连接？
Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，
依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

2.持久化

RDB快照（snapshot）
在默认情况下， Redis 将内存数据库快照保存在名字为dump.rdb的二进制文件中。
你可以对 Redis 进行设置， 让它在N秒内数据集至少有M个改动这一条件被满足时， 自动保存一次数据集。
比如说， 以下设置会让 Redis 在满足60秒内有至少有1000个键被改动”这一条件时， 自动保存一次数据集：
redis.conf文件里面有默认的3种情况，3种是或的关系。

AOF（append-only file）
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件
你可以通过修改配置文件来打开 AOF 功能：
开启后，每当 Redis 执行一个改变数据集的命令时（比如SET）， 这个命令就会被追加到 AOF 文件的末尾。
这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
你可以配置 Redis 多久才将数据fsync到磁盘一次。
有三个选项：
每次有新命令追加到 AOF 文件时就执行一次fsync：非常慢，也非常安全。
每秒fsync一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
从不fsync：将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒fsync一次， 这种fsync策略可以兼顾速度和安全性。
3.RDB 和 AOF ，我应该用哪一个？

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，
并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。
4.缓存淘汰策略(解决数据热点问题)

当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)。
交换会让 Redis 的性能急剧下降，对于访问量比较频繁的 Redis 来说，这样龟速的存取效率基本上等于不可用。
在生产环境中我们是不允许 Redis 出现交换行为的，为了限制最大使用内存，
Redis 提供了配置参数 maxmemory 来限制内存超出期望大小。
当实际内存超出 maxmemory 时，
Redis 提供了几种可选策略 (maxmemory-policy) 来让用户自己决定该如何腾出新的空间以继续提供读写服务。

（1）noeviction
不会继续服务写请求 (DEL 请求可以继续服务)，读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。这是默认的淘汰策略。

（2）volatile-lru
尝试淘汰设置了过期时间的 key，最少使用的 key 优先被淘汰。
没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。

（3）volatile-ttl
跟上面一样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。

（4）volatile-random
跟上面一样，不过淘汰的 key 是过期 key 集合中随机的 key。

（5）allkeys-lru
区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不只是过期的 key 集合。
这意味着没有设置过期时间的 key 也会被淘汰。
allkeys-random跟上面一样，不过淘汰的策略是随机的 key。

==（6）volatile-xxx ==
策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的 key 进行淘汰。如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。

六、redis的三种集群方式

redis有三种集群方式：主从复制，哨兵模式和集群。

1.主从复制

主从复制原理：

• 从服务器连接主服务器，发送SYNC命令； 
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）
• 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

主从复制优缺点：

优点：

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
• 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
• Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
• Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

• Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

2.哨兵模式

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

    （1）监控主服务器和从服务器是否正常运行。 
    （2）主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式：

• 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
• 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
• 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
• 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
• 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
• 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
• 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

 哨兵模式的优缺点

优点：

• 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
• 主从可以自动切换，系统更健壮，可用性更高。

缺点：

• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

3.Redis-Cluster集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

 Redis-Cluster采用无中心结构,它的特点如下：

• 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

• 节点的fail是通过集群中超过半数的节点检测失效时才生效。

• 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式：

在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。