Redis札记

Redis介绍

什么是Reids

Redis 是一个基于内存的高性能key-value数据结构存储系统。

Redis应用

数据库、缓存和消息中间件

Redis与其他key-value产品相比

• Redis支持数据的持久化。可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
• Redis支持多种数据类型。Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份。即master-slave模式的数据备份。

优势

• 性能极高 – 因为Redis数据在内存中，所以性能极高。Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

缺点

• 数据库容量受到物理内存的限制。因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

数据类型

• string
• list
• set
• hash
• zset(sorted set：有序集合)

string类型是Redis中最为基础的数据存储类型，一般用来存字符串，整数和浮点数。
应用场景：很常见的场景用于统计网站访问数量，当前在线人数等。

list基于Linked Lists实现。好比Java的linkedList，插入元素快，查找速度慢。Redis Lists用linked list实现的原因是：对于数据库系统来说，至关重要的特性是：能非常快的在很大的列表上添加元素。如果快速访问集合元素很重要，建议使用可排序集合(sorted sets)。
应用场景：1.聊天系统；2.消息队列；3.评论列表。
有必要提下List上的阻塞操作：可以使用List来实现生产者和消费者模型，如使用LPUSH和RPOP来实现该功能。但会遇到这种情景：list是空，这时候消费者就需要轮询来获取数据，这样就会增加redis的访问压力、增加消费端的cpu时间，而很多访问都是无用的。为此redis提供了阻塞式访问 BRPOP 和 BLPOP 命令。 消费者可以在获取数据时指定如果数据不存在阻塞的时间，如果在时限内获得数据则立即返回，如果超时还没有数据则返回null, 0表示一直阻塞。同时redis还会为所有阻塞的消费者以先后顺序排队。如需了解详细信息请查看 RPOPLPUSH 和 BRPOPLPUSH。

set是String的无序列表，不允许重复值。set最大的优势在于可以进行交集并集差集操作。
应用场景：1.利用交集求共同好友。2.统计访问网站的所有独立IP。

hash可以看成键值对。
应用场景：表示对象

zset和set很像，都是String的集合，都不允许重复值。它们之间的差别在于zset是有序的。zset中每一个成员都会有一个分数(score)与之关联，Redis正是通过score来为集合中的成员进行从小到大的排序。尽管有序集合中的成员必须是唯一的，但是分数却可以重复。
应用场景：1.排行榜。

内置功能

• 主从复制（replication）
• LUA脚本（Lua scripting）
• 内存回收：LRU驱动事件（LRU eviction）
• 事务（transactions）
• 磁盘持久化（persistence）
• Sentinel 系统：Redis哨兵（Sentinel）
• 集群：自动分区（Cluster）
• 发布订阅（Pub/Sub）
• 过期自动删除key

一、主从复制

同步主Redis 服务器（下文称master）的内容到从Redis服务器（下文称slave）上。

1.主从复制策略分为三种情况

• 当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave 的更新，以便于将自身数据集的改变（包括客户端的写入、key 的过期或被逐出等等）复制给 slave。
• 当master和slave之间的连接断开之后，因为网络问题、或者是主从意识到连接超时， slave 重新连接上 master 并会尝试进行部分重同步：这意味着它会尝试只获取在断开连接期间内丢失的命令流。
• 当无法进行部分重同步时， slave 会请求进行全量重同步。这会涉及到一个更复杂的过程，例如 master 需要创建所有数据的快照，将之发送给 slave ，之后在数据集更改时持续发送命令流到 slave 。

2.特性

• Redis 使用异步复制。slave 和 master 之间异步地确认处理的数据量
• 一个 master 可以拥有多个 slave
• slave 可以接受其他 slave 的连接。除了多个 slave 可以连接到同一个 master 之外， slave 之间也可以像层叠状的结构（cascading-like structure）连接到其他 slave 。自 Redis 4.0 起，所有的 sub-slave 将会从 master 收到完全一样的复制流。
• 复制在 master 侧是非阻塞的。这意味着 master 在一个或多个 slave 进行初次同步或者是部分重同步时，可以继续处理查询请求。
• 复制在 slave 侧大部分也是非阻塞的。当 slave 进行初次同步时，它可以使用旧数据集处理查询请求，假设你在 redis.conf 中配置了让 Redis 这样做的话。否则，你可以配置如果复制流断开， Redis slave 会返回一个 error 给客户端。但是，在初次同步之后，旧数据集必须被删除，同时加载新的数据集。 slave 在这个短暂的时间窗口内（如果数据集很大，会持续较长时间），会阻塞到来的连接请求。自 Redis 4.0 开始，可以配置 Redis 使删除旧数据集的操作在另一个不同的线程中进行，但是，加载新数据集的操作依然需要在主线程中进行并且会阻塞 slave 。
• 复制既可以被用在可伸缩性，以便只读查询可以有多个 slave 进行（例如 O(N) 复杂度的慢操作可以被下放到 slave ），或者仅用于数据安全。
• 可以使用复制来避免 master 将全部数据集写入磁盘造成的开销：一种典型的技术是配置你的 master Redis.conf 以避免对磁盘进行持久化，然后连接一个 slave ，其配置为不定期保存或是启用 AOF。但是，这个设置必须小心处理，因为重新启动的 master 程序将从一个空数据集开始：如果一个 slave 试图与它同步，那么这个 slave 也会被清空。

3.当 master 关闭持久化时，复制的安全性

在使用 Redis 复制功能时的设置中，强烈建议在 master 和在 slave 中启用持久化。当不可能启用时，例如由于非常慢的磁盘性能而导致的延迟问题，应该配置实例来避免重置后自动重启。

4.主从复制工作原理

• 部分同步：每个 master 也持有一个偏移量，master 将自己产生的复制流发送给 slave 时，发送多少个字节的数据，自身的偏移量就会增加多少，目的是当有新的操作修改自己的数据集时，它可以以此更新 slave 的状态。当 slave 连接到 master 时，它们使用 PSYNC 命令来发送它们记录的旧的 master replication ID 和它们至今为止处理的偏移量。通过这种方式， master 能够仅发送 slave 所需的增量部分。但是如果 master 的缓冲区中没有足够的命令积压缓冲记录，或者如果 slave 引用了不再知道的历史记录（replication ID），则会转而进行一个全量重同步。
• 全量同步：master 开启一个后台保存进程，以便于生产一个 RDB 文件。同时它开始缓冲所有从客户端接收到的新的写入命令。当后台保存完成时， master 将数据集文件传输给 slave， slave将之保存在磁盘上，然后加载文件到内存。再然后 master 会发送所有缓冲的命令发给 slave。

5.无需磁盘参与的复制

正常情况下，一个全量重同步要求在磁盘上创建一个 RDB 文件，然后将它从磁盘加载进内存，然后 slave以此进行数据同步。如果磁盘性能很低的话，这对 master 是一个压力很大的操作。Redis 2.8.18 是第一个支持无磁盘复制的版本。在此设置中，子进程直接发送 RDB 文件给 slave，无需使用磁盘作为中间储存介质。

6.主从复制如何配置

方法1：将以下内容加进 slave 的配置文件：

slaveof masterIP masterPort

方法2：用 SLAVEOF 命令。

无磁盘复制可以使用 repl-diskless-sync 配置参数。

7.只读性质的slave

自从 Redis 2.6 之后， slave 支持只读模式且默认开启。

配置：1.redis.conf 文件中的 slave-read-only 变量控制这个行为；2.在运行时使用 CONFIG SET 来随时开启或者关闭。

8.复制如何处理 key 的过期

Redis slaves 能正确地复制具有过期时间的 key。

9.INFO 和 ROLE 命令

有两个 Redis 命令可以提供有关主从实例当前复制参数的很多信息。

• INFO。它提供与复制相关的信息。
• ROLE，它提供 master 和 slave 的复制状态以及它们的复制偏移量，连接的 slaves 列表等等。

10.重新启动和故障转移后的部分重同步

从 Redis 4.0 开始，当一个实例在故障转移后被提升为 master 时，它仍然能够与旧 master 的 slaves 进行部分重同步。为此，slave 会记住旧 master 的旧 replication ID 和复制偏移量，因此即使询问旧的 replication ID，其也可以将部分复制缓冲提供给连接的 slave 。

另外，slave 在关机并重新启动后，能够在 RDB 文件中存储所需信息，以便与 master 进行重同步。这在升级的情况下很有用。当需要时，最好使用 SHUTDOWN 命令来执行 slave 的保存和退出操作。

11.应用

分布式读写分离。可以利用master来插入数据，slave提供检索服务。这样可以有效减少单个机器的并发访问数量。

二、LUA脚本

待补充

三、LRU驱动事件

可以将Redis当做缓存来使用，当你新增数据时，让它自动地回收旧数据是件很方便的事情。LRU是Redis唯一支持的回收方法。

Maxmemory配置指令

maxmemory配置指令用于配置Redis存储数据时指定限制的内存大小。通过redis.conf可以设置该指令，或者之后使用CONFIG SET命令来进行运行时配置。

例如为了配置内存限制为100mb，以下的指令可以放在redis.conf文件中。
maxmemory 100mb
设置maxmemory为0代表没有内存限制。对于64位的系统这是个默认值，对于32位的系统默认内存限制为3GB。

当达到指定的内存限制大小时，需要选择策略来回收内存。

回收策略

Redis使用的回收策略由maxmemory-policy指令来进行配置。

可选策略

• noeviction：当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）返回错误
• allkeys-lru：尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。
• volatile-lru：尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。
• allkeys-random：回收随机的键使得新添加的数据有空间存放。
• volatile-random：回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。
• volatile-ttl： 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。

如果没有键满足回收的前提条件，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。
选择正确的回收策略是非常重要的，这取决于你的应用的访问模式，不过你可以在运行时进行相关的策略调整，并且监控缓存命中率和没命中的次数，通过RedisINFO命令输出以便调优。

一般的经验规则

• 使用allkeys-lru策略：当你希望你的请求符合一个幂定律分布，也就是说，你希望部分的子集元素将比其它其它元素被访问的更多。如果你不确定选择什么，这是个很好的选择。.
• 使用allkeys-random：如果你是循环访问，所有的键被连续的扫描，或者你希望请求分布正常（所有元素被访问的概率都差不多）。
• 使用volatile-ttl：如果你想要通过创建缓存对象时设置TTL值，来决定哪些对象应该被过期。

为了键设置过期时间也是需要消耗内存的，所以使用allkeys-lru这种策略更加高效，因为当内存有压力时没有必要为键取设置过期时间。

回收进程如何工作

1. 一个客户端运行了新的命令，添加了新的数据。
2. Redis检查内存使用情况，如果大于maxmemory的限制, 则根据设定好的策略进行回收。
3. 重复步骤1、2

如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到一个新的键），不用多久内存限制就会被这个内存使用量超越。

近似LRU算法

因为使用真实的LRU实现需要太多的内存，Redis的LRU算法并非完整的实现。Redis并没办法选择最久未被访问的键来进行回收。它会尝试运行一个近似LRU的算法，通过对少量keys进行取样，然后回收其中最久未被访问的键。

Redis 3.0将算法已经改进为回收键的候选池。这改善了算法的性能，使得更加近似真是的LRU算法的行为。

LRU有个很重要的点，通过调整每次回收时检查的采样数量，以实现调整算法的精度。可以通过配置指令maxmemory-samples 5，或者通过CONFIG SET maxmemory-samples命令来调整采样数量。

四、事务

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。事务可以一次执行多个命令， 并且带有以下两个重要的保证：

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

用法

MULTI 命令用于开启一个事务，它总是返回 OK 。 MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中。EXEC 命令负责触发并执行事务中的所有命令。当 EXEC命令被调用时， 所有队列中的命令才会被执行。通过调用 DISCARD ， 客户端可以清空事务队列， 并放弃执行事务。

以下是一个事务例子， 它原子地增加了 foo 和 bar 两个键的值：

> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1

为什么 Redis 不支持回滚

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

使用WATCH命令实现乐观锁

WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。

被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。

举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。

Redis 脚本和事务

从定义上来说， Redis 中的脚本本身就是一种事务， 所以任何在事务里可以完成的事， 在脚本里面也能完成。 并且一般来说， 使用脚本要来得更简单，并且速度更快。因为脚本功能是 Redis 2.6 才引入的， 而事务功能则更早之前就存在了， 所以 Redis 才会同时存在两种处理事务的方法。

五、磁盘持久化

持久化级别

• RDB持久化方式：能在指定的时间间隔对数据进行快照存储.
• AOF持久化方式：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份。比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

• 很难完全恢复数据。
• 保存数据时会降低系统性能。RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

AOF 优点

• 丢失数据少：你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

如何选择使用哪种持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

配置方法

• 通过命令打开RDB方式：SAVE或者 BGSAVE
• 在配置文件中打开AOF方式：appendonly yes

怎样从RDB方式切换为AOF方式

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

• 为最新的 dump.rdb 文件创建一个备份。
• 将备份放到一个安全的地方。
• redis-cli config set appendonly yes，开启了 AOF 功能
• redis-cli config set save “”，关闭 RDB 功能，可选， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。
• 确保写命令会被正确地追加到 AOF 文件的末尾。
• 别忘了在 redis.conf 中打开 AOF 功能！ 否则的话， 服务器重启之后， 之前通过 CONFIG SET 设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。

六、Sentinel 系统：Redis哨兵

待补充

七、自动分区（集群）

待补充

八、发布订阅

简介

发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。Redis 客户端可以订阅任意数量的频道。下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client1、 client1 和 client3 之间的关系：

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

实例

创建名为redisChat的订阅频道

127.0.0.1:6379> subscribe redisChat

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

重新开启个 redis 客户端，然后在同一个频道 redisChat 发布两次消息，订阅者就能接收到消息。

127.0.0.1:6379> publish redisChat "Redis is a great caching technique"

(integer) 1

127.0.0.1:6379> PUBLISH redisChat "Learn redis by w3cschool.cc"

(integer) 1

# 订阅者的客户端会显示如下消息
1) "message"
2) "redisChat"
3) "Redis is a great caching technique"
1) "message"
2) "redisChat"
3) "Learn redis by w3cschool.cc"

发布订阅常用命令

命令	描述
PSUBSCRIBE pattern [pattern …]	订阅一个或多个符合给定模式的频道。
PUBSUB subcommand [argument [argument …]]	查看订阅与发布系统状态。
PUBLISH channel message	将信息发送到指定的频道。
PUNSUBSCRIBE [pattern [pattern …]]	退订所有给定模式的频道。
SUBSCRIBE channel [channel …]	订阅给定的一个或多个频道的信息。
UNSUBSCRIBE [channel [channel …]]	指退订给定的频道。

九、过期自动删除key

Expire 命令用于设置 key 的过期时间。key 过期后将不再可用。

Redis如何淘汰过期的keys

Redis keys过期有两种方式：被动和主动方式。当一些客户端尝试访问它时，key会被发现并主动的过期。当然，这样是不够的，因为有些过期的keys，永远不会访问他们。 无论如何，这些keys应该过期，所以定时随机测试设置keys的过期时间。所有这些过期的keys将会从密钥空间删除。

被动过期：

• 测试随机的20个keys进行相关过期检测。
• 删除所有已经过期的keys。
• 如果有多于25%的keys过期，重复步奏1。

在复制AOF文件时如何处理过期

为了获得正确的行为而不牺牲一致性，当一个key过期，DEL将会随着AOF文字一起合成到所有附加的slaves。在master实例中，这种方法是集中的，并且不存在一致性错误的机会。

然而，当slaves连接到master时，不会独立过期keys（会等到master执行DEL命令），他们仍然会在数据集里面存在，所以当slave当选为master时淘汰keys会独立执行，然后成为master。

命令

命令	描述
EXPIRE key seconds	为给定 key 设置过期时间。
EXPIREAT key timestamp	EXPIREAT 的作用和 EXPIRE 类似，都用于为 key 设置过期时间。 不同在于 EXPIREAT 命令接受的时间参数是 UNIX 时间戳(unix timestamp)。
PEXPIRE key milliseconds	设置 key 的过期时间亿以毫秒计。
PEXPIREAT key milliseconds-timestamp	设置 key 过期时间的时间戳(unix timestamp) 以毫秒计

Redis面试题

Redis 常见的性能问题都有哪些？如何解决？

• 主线程（master）写内存快照问题。save命令会阻塞主线程的工作，当快照比较大的时候对性能影响非常严重，会出现间断性暂停服务
  
  • 解决方法：主线程不使用内存快照做持久化
• Master持久化问题。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
  
  • 解决方法：如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
• 主线程调用bgrewriteaof 重写AOF文件，AOF在重写的时候会栈大量的cpu和内存的资源，导致服务load过高，出现短暂服务暂停现象。
  
  • 解决方法；为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
• 尽量避免在压力很大的主库上增加从库
• 单点故障问题。由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题。
  
  • 解决方法：主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…。这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

maxmemory配置指令用于配置Redis存储数据时指定限制的内存大小。当达到指定的内存限制大小时，就会施行数据淘汰策略。Redis提供 6种数据淘汰策略。
设置maxmemory为0代表没有内存限制。对于64位的系统这是个默认值，对于32位的系统默认内存限制为3GB。

Memcache与Redis的区别都有哪些？

• 数据持久化
  
  • Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
  • Redis有部份存在硬盘上，这样能保证数据的持久性。
• 数据支持类型
  
  • Memcache对数据类型支持相对简单。
  • Redis有复杂的数据类型。
• value大小
  
  • redis最大可以达到1GB
  • memcache只有1MB

谈谈Redis的读写分离模型
可以利用master来插入数据，slave提供检索服务。通过增加Slave DB的数量，读的性能可以线性增长。为了避免Master DB的单点故障，集群一般都会采用两台Master DB做双机热备，所以整个集群的读和写的可用性都非常高。
读写分离架构的缺陷在于，不管是Master还是Slave，每个节点都必须保存完整的数据，如果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于Write-intensive类型的应用，读写分离架构并不适合。

谈谈Redis的数据分片模型
为了解决读写分离模型的缺陷，可以将数据分片模型应用进来。
可以将每个节点看成都是独立的master，然后通过业务实现数据分片。
结合上面两种模型，可以将每个master设计成由一个master和多个slave组成的模型。

请用Redis实现恶意登录保护，限制1小时内每用户Id最多只能登录5次。讲下思路
数据结构使用list。list中每个元素代表登陆时间，只要倒数第五次登陆的时间和现在时间差不超过1小时就禁止登陆，否则允许登录。登陆成功后，将此次登录时间存入list。

参考：REDIS介绍