分布式缓存Redis使用方法

分布式缓存Redis使用方法

作者：张小博，新炬网络技术专家。

缓存在系统中的作用：

1、少量数据存储，高速读写访问。通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。

2、海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。Redis3.0以后开始支持集群，实现了半自动化的数据分片，不过需要smart-client的支持。

Redis全角度介绍:

网络模型：Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。

内存管理：Redis使用现场申请内存的方式来存储数据，并且很少使用free-list 等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据（但会尝试剔除部分临时数据），这点上Redis更适合作为存储而不是cache。

数据一致性问题：在一致性问题上，个人感觉redis没有memcached实现的好，Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串命令的原子性，中间不会被任何操作打断。

支持的KEY类型：Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供

了持久化和复制等功能。

客户端支持：redis官方提供了丰富的客户端支持，包括了绝大多数编程语言的客户端，比如我此次测试就选择了官方推荐了Java客户端Jedis.里面提供了丰富的接口、方法使得开发人员无需关系内部的数据分片、读取数据的路由等，只需简单的调用即可，非常方便。

数据复制：从2.8开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度， Redis复制工作原理详细过程如下：

1. 如果设置了一个Slave，无论是第一次连接还是重连到Master，它都会发出一个SYNC命令；

2. 当Master收到SYNC命令之后，会做两件事：

a) Master执行BGSAVE：后台写数据到磁盘（rdb快照）；

b) Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）；

3. 当Master在后台把数据保存到快照文件完成之后，Master会把这个快照文件传送给Slave，而Slave则把内存清空后，加载该文件到内存中；

4. 而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步；

5. Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致；

6. 需要注意的是Master和Slave之间一旦发生重连都会引发全量同步操作。但在2.8之后，也可能是部分同步操作。

2.8开始，当Master和Slave之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。

Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Master run id）。当网络断开，Slave尝试重连时：

a. 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时

刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了；

b. 否则，依然需要全量复制操作。

读写分离：redis支持读写分离，而且使用简单，只需在配置文件中把redis读服务器和写服务器进行配置，多个服务器使用逗号分开如下：

WriteServerList="192.168.2.71:6379"

ReadServerList="192.168.2.71:6379,192.168.2.71:6380"

MaxWritePoolSize="60"

MaxReadPoolSize="60"

AutoStart="true"

LocalCacheTime="180"

RecordeLog="false">

水平动态扩展：历时三年之久，终于等来了期待已由的Redis 3.0。新版本主要是实现了Cluster的功能，增删集群节点后会自动的进行数据迁移。实现 Redis 集群在线重配置的核心就是将槽从一个节点移动到另一个节点的能力。因为一个哈希槽实际上就是一些键的集合，所以 Redis 集群在重哈希（rehash）时真正要做的，就是将一些键从一个节点移动到另一个节点。

数据淘汰策略：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

集群（分布式）

下面详细介绍一下redis的集群功能，从3.0以后的版本开始支持集群功能，也就是正真意义上实现了分布式。

Redis 集群是一个分布式（distributed）、容错（fault-tolerant）的 Redis 实现，集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集（subset）。

Redis 集群中不存在中心（central）节点或者代理（proxy）节点，集群的其中一个主要设计目标是达到线性可扩展性（linear scalability）。

Redis 集群为了保证一致性（consistency）而牺牲了一部分容错性：系统会在保证对网络断线（net split）和节点失效（node failure）具有有限（limited）抵抗力的前提下，尽可能地保持数据的一致性。

集群特性：

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

(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.

(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

Redis 集群实现的功能子集：

Redis 集群实现了单机 Redis 中，所有处理单个数据库键的命令。针对多个数据库键的复杂计算操作，比如集合的并集操作、合集操作没有被实现，那些理论上需要使用多个节点的多个数据库键才能完成的命令也没有被实现。在将来，用户也许可以通过 MIGRATE COPY 命令，在集群的计算节点（computation node）中执行针对多个数据库键的只读操作，但集群本身不会去实现那些需要将多个数据库键在多个节点中移来移去的复杂多键命令。

Redis 集群不像单机 Redis 那样支持多数据库功能，集群只使用默认的 0 号数据库，并且不能使用 SELECT 命令。

Redis 集群协议中的客户端和服务器：

Redis 集群中的节点有以下责任：

1、持有键值对数据。

2、记录集群的状态，包括键到正确节点的映射（mapping keys to right nodes）。

3、自动发现其他节点，识别工作不正常的节点，并在有需要时，在从节点中选举出新的主节点。

为了执行以上列出的任务，集群中的每个节点都与其他节点建立起了“集群连接（cluster bus）”，该连接是一个 TCP 连接，使用二进制协议进行通讯。

节点之间使用 Gossip 协议来进行以下工作：

1、传播（propagate）关于集群的信息，以此来发现新的节点。

2、向其他节点发送 PING 数据包，以此来检查目标节点是否正常运作。

3、在特定事件发生时，发送集群信息。

4、除此之外，集群连接还用于在集群中发布或订阅信息。

因为集群节点不能代理（proxy）命令请求，所以客户端应该在节点返回-MOVED 或者 -ASK 转向（redirection）错误时，自行将命令请求转发至其他节点。因为客户端可以自由地向集群中的任何一个节点发送命令请求，并可以在有需要时，根据转向错误所提供的信息，将命令转发至正确的节点，所以在理论上来说，客户端是无须保存集群状态信息的。不过，如果客户端可以将键和节点之间的映射信息保存起来，

可以有效地减少可能出现的转向次数，籍此提升命令执行的效率。

键分布模型：

Redis 集群的键空间被分割为16384 个槽（slot），集群的最大节点数量也是16384 个。

推荐的最大节点数量为 1000 个左右。每个主节点都负责处理 16384 个哈希槽的其中一部分。

当我们说一个集群处于“稳定”（stable）状态时，指的是集群没有在执行重配（reconfiguration）操作，每个哈希槽都只由一个节点进行处理。重配置指的是将某个/某些槽从一个节点移动到另一个节点。一个主节点可以有任意多个从节点，这些从节点用于在主节点发生网络断线或者节点失效时，对主节点进行替换。

集群节点属性：

每个节点在集群中都有一个独一无二的 ID ，该 ID 是一个十六进制表示的 160 位随机数，在节点第一次启动时由 /dev/urandom 生成。

节点会将它的 ID 保存到配置文件，只要这个配置文件不被删除，节点就会一直沿用这个 ID 。节点 ID 用于标识集群中的每个节点。一个节点可以改变它的 IP 和端口号，而不改变节点 ID 。集群可以自动识别出 IP/端口号的变化，并将这一信息通过 Gossip 协议广播给其他节点知道。

以下是每个节点都有的关联信息，并且节点会将这些信息发送给其他节点：

1、节点所使用的 IP 地址和 TCP 端口号。

2、节点的标志（flags）。

3、节点负责处理的哈希槽。

4、节点最近一次使用集群连接发送 PING 数据包（packet）的时间。

5、节点最近一次在回复中接收到 PONG 数据包的时间。

6、集群将该节点标记为下线的时间。

7、该节点的从节点数量。

8、如果该节点是从节点的话，那么它会记录主节点的节点 ID 。如果这是一个主节点的话，那么主节点 ID 这一栏的值为 0000000 。

以上信息的其中一部分可以通过向集群中的任意节点（主节点或者从节点都可以）发送 CLUSTER NODES 命令来获得。

节点握手：

节点总是应答（accept）来自集群连接端口的连接请求，并对接收到的 PING 数据包进行回复，即使这个 PING 数据包来自不可信的节点。然而，除了 PING 之外，节点会拒绝其他所有并非来自集群节点的数据包。要让一个节点承认另一个节点同属于一个集群，只有以下两种方法：

1、一个节点可以通过向另一个节点发送 MEET 信息，来强制让接收信息的节点承认发送信息的节点为集群中的一份子。一个节点仅在管理员显式地向它发送CLUSTER MEET ip port 命令时，才会向另一个节点发送 MEET 信息。

2、如果一个可信节点向另一个节点传播第三者节点的信息，那么接收信息的那个节点也会将第三者节点识别为集群中的一份子。也即是说，如果 A 认识 B ， B 认识 C ，并且 B 向 A 传播关于 C 的信息，那么 A 也会将 C 识别为集群中的一份子，并尝试连接 C 。

这意味着如果我们将一个/一些新节点添加到一个集群中，那么这个/这些新节点最终会和集群中已有的其他所有节点连接起来。

这说明只要管理员使用 CLUSTER MEET 命令显式地指定了可信关系，集群就可以自动发现其他节点。这种节点识别机制通过防止不同的 Redis 集群因为 IP 地址变更或者其他网络事件的发生而产生意料之外的联合（mix），从而使得集群更具健壮性。当节点的网络连接断开时，它会主动连接其他已知的节点。

MOVED 转向：

一个 Redis 客户端可以向集群中的任意节点（包括从节点）发送命令请求。节点会对命令请求进行分析，如果该命令是集群可以执行的命令，那么节点会查找这个命令所要处理的键所在的槽。如果要查找的哈希槽正好就由接收到命令的节点负责处理，那么节点就直接执行这个命令。另一方面，如果所查找的槽不是由该节点处理的话，节点将查看自身内部所保存的哈希槽到节点ID 的映射记录，并向客户端回复一个

MOVED 错误。

即使客户端在重新发送 GET 命令之前，等待了非常久的时间，以至于集群又再次更改了配置，使得节点 127.0.0.1:6381 已经不再处理槽 3999 ，那么当客户端向节点 127.0.0.1:6381 发送 GET 命令的时候，节点将再次向客户端返回 MOVED 错误，指示现在负责处理槽 3999 的节点。

虽然我们用 ID 来标识集群中的节点，但是为了让客户端的转向操作尽可能地简单，节点在MOVED 错误中直接返回目标节点的IP 和端口号，而不是目标节点的ID 。但一个客户端应该记录（memorize）下“槽 3999 由节点 127.0.0.1:6381 负责处理“这一信息，这样当再次有命令需要对槽 3999 执行时，客户端就可以加快寻找正确节点的速度。

注意，当集群处于稳定状态时，所有客户端最终都会保存有一个哈希槽至节点的映射记录（map of hash slots to nodes），使得集群非常高效：客户端可以直接向正确的节点发送命令请求，无须转向、代理或者其他任何可能发生单点故障（single point failure）的实体（entiy）。

除了 MOVED 转向错误之外，一个客户端还应该可以处理稍后介绍的 ASK 转向错误。

集群在线重配置：

Redis 集群支持在集群运行的过程中添加或者移除节点。

实际上，节点的添加操作和节点的删除操作可以抽象成同一个操作，那就是，将哈希槽从一个节点移动到另一个节点：

添加一个新节点到集群，等于将其他已存在节点的槽移动到一个空白的新节点里面。

从集群中移除一个节点，等于将被移除节点的所有槽移动到集群的其他节点上面去。

因此，实现 Redis 集群在线重配置的核心就是将槽从一个节点移动到另一个节点的能力。因为一个哈希槽实际上就是一些键的集合，所以Redis 集群在重哈希（rehash）时真正要做的，就是将一些键从一个节点移动到另一个节点。

要理解 Redis 集群如何将槽从一个节点移动到另一个节点，我们需要对 CLUSTER 命令的各个子命令进行介绍，这些命理负责管理集群节点的槽转换表（slots translation table）。

以下是 CLUSTER 命令可用的子命令：

CLUSTER ADDSLOTS slot1 [slot2] ... [slotN]

CLUSTER DELSLOTS slot1 [slot2] ... [slotN]

CLUSTER SETSLOT slot NODE node

CLUSTER SETSLOT slot MIGRATING node

CLUSTER SETSLOT slot IMPORTING node

最开头的两条命令 ADDSLOTS 和 DELSLOTS 分别用于向节点指派（assign）或者移除节点，当槽被指派或者移除之后，节点会将这一信息通过 Gossip 协议传播到整个集群。 ADDSLOTS 命令通常在新创建集群时，作为一种快速地将各个槽指派给各个节点的手段来使用。

CLUSTER SETSLOT slot NODE node 子命令可以将指定的槽slot 指派给节点node 。

至于CLUSTER SETSLOT slot MIGRATING node 命令和CLUSTER SETSLOT slot IMPORTING node 命令，前者用于将给定节点 node 中的槽 slot 迁移出节点，而后者用于将给定槽 slot导入到节点 node ：

当一个槽被设置为 MIGRATING 状态时，原来持有这个槽的节点仍然会继续接受关于这个槽的命令请求，但只有命令所处理的键仍然存在于节点时，节点才会处理这个命令请求。

如果命令所使用的键不存在与该节点，那么节点将向客户端返回一个 -ASK 转向（redirection）错误，告知客户端，要将命令请求发送到槽的迁移目标节点。

当一个槽被设置为 IMPORTING 状态时，节点仅在接收到 ASKING 命令之后，才会接受关于这个槽的命令请求。

如果客户端没有向节点发送 ASKING 命令，那么节点会使用 -MOVED 转向错误将

命令请求转向至真正负责处理这个槽的节点。

上面关于 MIGRATING 和 IMPORTING 的说明有些难懂，让我们用一个实际的实例来说明一下。

假设现在，我们有 A 和 B 两个节点，并且我们想将槽 8 从节点 A 移动到节点B ，于是我们：

向节点 B 发送命令 CLUSTER SETSLOT 8 IMPORTING A

向节点 A 发送命令 CLUSTER SETSLOT 8 MIGRATING B

每当客户端向其他节点发送关于哈希槽 8 的命令请求时，这些节点都会向客户端返回指向节点 A 的转向信息：

如果命令要处理的键已经存在于槽 8 里面，那么这个命令将由节点 A 处理。

如果命令要处理的键未存在于槽 8 里面（比如说，要向槽添加一个新的键），那么这个命令由节点 B 处理。

这种机制将使得节点 A 不再创建关于槽 8 的任何新键。

与此同时，一个特殊的客户端redis-trib 以及Redis 集群配置程序（configuration utility）会将节点 A 中槽 8 里面的键移动到节点 B 。

键的移动操作由以下两个命令执行：

CLUSTER GETKEYSINSLOT slot count

上面的命令会让节点返回 count 个 slot 槽中的键，对于命令所返回的每个键，redis-trib 都会向节点 A 发送一条MIGRATE 命令，该命令会将所指定的键原子地（atomic）从节点 A 移动到节点 B （在移动键期间，两个节点都会处于阻塞状态，以免出现竞争条件）。

以下为 MIGRATE 命令的运作原理：

MIGRATE target_host target_port key target_database id timeout

执行 MIGRATE 命令的节点会连接到 target 节点，并将序列化后的 key 数据发送给 target ，一旦 target 返回 OK ，节点就将自己的 key 从数据库中删除。

从一个外部客户端的视角来看，在某个时间点上，键 key 要么存在于节点 A ，要么存在于节点 B ，但不会同时存在于节点 A 和节点 B 。

因为 Redis 集群只使用 0 号数据库，所以当 MIGRATE 命令被用于执行集群操作时， target_database 的值总是 0 。

target_database 参数的存在是为了让 MIGRATE 命令成为一个通用命令，从而可以作用于集群以外的其他功能。

我们对 MIGRATE 命令做了优化，使得它即使在传输包含多个元素的列表键这样的复杂数据时，也可以保持高效。

不过，尽管 MIGRATE 非常高效，对一个键非常多、并且键的数据量非常大的集群来说，集群重配置还是会占用大量的时间，可能会导致集群没办法适应那些对于响应时间有严格要求的应用程序。

ASK 转向：

在之前介绍 MOVED 转向的时候，我们说除了 MOVED 转向之外，还有另一种 ASK 转向。

当节点需要让一个客户端长期地（permanently）将针对某个槽的命令请求发送至另一个节点时，节点向客户端返回 MOVED 转向。另一方面，当节点需要让客户端仅仅在下一个命令请求中转向至另一个节点时，节点向客户端返回 ASK 转向。

比如说，在我们上一节列举的槽 8 的例子中，因为槽 8 所包含的各个键分散在节点 A 和节点 B 中，所以当客户端在节点 A 中没找到某个键时，它应该转向到节点 B 中去寻找，但是这种转向应该仅仅影响一次命令查询，而不是让客户端每次都直接去查找节点 B ：在节点 A 所持有的属于槽 8 的键没有全部被迁移到节点 B 之前，客户端应该先访问节点 A ，然后再访问节点 B 。因为这种转向只针对16384 个槽中的其中一个槽，所以转向对集群造成的性能损耗属于可接受的范围。

因为上述原因，如果我们要在查找节点 A 之后，继续查找节点 B ，那么客户端在向节点 B 发送命令请求之前，应该先发送一个 ASKING 命令，否则这个针对带有IMPORTING 状态的槽的命令请求将被节点 B 拒绝执行。接收到客户端 ASKING 命令的节点将为客户端设置一个一次性的标志（flag），使得客户端可以执行一次针对IMPORTING 状态的槽的命令请求。从客户端的角度来看，ASK 转向的完整语义

（semantics）如下：

1、如果客户端接收到 ASK 转向，那么将命令请求的发送对象调整为转向所指定的节点。

2、先发送一个 ASKING 命令，然后再发送真正的命令请求。

3、不必更新客户端所记录的槽 8 至节点的映射：槽 8 应该仍然映射到节点 A ，而不是节点 B 。

一旦节点 A 针对槽 8 的迁移工作完成，节点 A 在再次收到针对槽 8 的命令请求时，就会向客户端返回MOVED 转向，将关于槽8 的命令请求长期地转向到节点B 。

注意，即使客户端出现 Bug ，过早地将槽 8 映射到了节点 B 上面，但只要这个客户端不发送ASKING 命令，客户端发送命令请求的时候就会遇上MOVED 错误，并将它转向回节点 A 。

容错：

节点失效检测，以下是节点失效检查的实现方法：

1、当一个节点向另一个节点发送 PING 命令，但是目标节点未能在给定的时限内返回 PING 命令的回复时，那么发送命令的节点会将目标节点标记为 PFAIL（possible failure，可能已失效）。等待PING 命令回复的时限称为“节点超时时限（node timeout）”，是一个节点选项（node-wise setting）。

2、每次当节点对其他节点发送 PING 命令的时候，它都会随机地广播三个它所知道的节点的信息，这些信息里面的其中一项就是说明节点是否已经被标记为 PFAIL或者 FAIL 。

当节点接收到其他节点发来的信息时，它会记下那些被其他节点标记为失效的节点。这称为失效报告（failure report）。

3、如果节点已经将某个节点标记为 PFAIL ，并且根据节点所收到的失效报告显式，集群中的大部分其他主节点也认为那个节点进入了失效状态，那么节点会将那个失效节点的状态标记为 FAIL 。

4、一旦某个节点被标记为 FAIL ，关于这个节点已失效的信息就会被广播到整个

集群，所有接收到这条信息的节点都会将失效节点标记为 FAIL 。

简单来说，一个节点要将另一个节点标记为失效，必须先询问其他节点的意见，并且得到大部分主节点的同意才行。因为过期的失效报告会被移除，所以主节点要将某个节点标记为 FAIL 的话，必须以最近接收到的失效报告作为根据。

从节点选举：一旦某个主节点进入 FAIL 状态，如果这个主节点有一个或多个从节点存在，那么其中一个从节点会被升级为新的主节点，而其他从节点则会开始对这个新的主节点进行复制。

新的主节点由已下线主节点属下的所有从节点中自行选举产生，以下是选举的条件：

1、这个节点是已下线主节点的从节点。

2、已下线主节点负责处理的槽数量非空。

3、从节点的数据被认为是可靠的，也即是，主从节点之间的复制连接（replication link）的断线时长不能超过节点超时时限（node timeout）乘以REDIS_CLUSTER_SLAVE_VALIDITY_MULT 常量得出的积。

如果一个从节点满足了以上的所有条件，那么这个从节点将向集群中的其他主节点发送授权请求，询问它们，是否允许自己（从节点）升级为新的主节点。

如果发送授权请求的从节点满足以下属性，那么主节点将向从节点返FAILOVER_AUTH_GRANTED 授权，同意从节点的升级要求：

1、发送授权请求的是一个从节点，并且它所属的主节点处于 FAIL 状态。

2、在已下线主节点的所有从节点中，这个从节点的节点 ID 在排序中是最小的。

3、这个从节点处于正常的运行状态：它没有被标记为 FAIL 状态，也没有被标记为 PFAIL 状态。

一旦某个从节点在给定的时限内得到大部分主节点的授权，它就会开始执行以下故障转移操作：

1、通过 PONG 数据包（packet）告知其他节点，这个节点现在是主节点了。

2、通过 PONG 数据包告知其他节点，这个节点是一个已升级的从节点（promoted

slave）。

3、接管（claiming）所有由已下线主节点负责处理的哈希槽。

4、显式地向所有节点广播一个 PONG 数据包，加速其他节点识别这个节点的进度，而不是等待定时的 PING / PONG 数据包。

所有其他节点都会根据新的主节点对配置进行相应的更新：

1、所有被新的主节点接管的槽会被更新。

2、已下线主节点的所有从节点会察觉到 PROMOTED 标志，并开始对新的主节点进行复制。

3、如果已下线的主节点重新回到上线状态，那么它会察觉到 PROMOTED 标志，并将自身调整为现任主节点的从节点。

在集群的生命周期中，如果一个带有 PROMOTED 标识的主节点因为某些原因转变成了从节点，那么该节点将丢失它所带有的 PROMOTED 标识。

Redis面试专题及答案

redis和memcached什么区别？为什么高并发下有时单线程的redis比多线程的memcached效率要高？ 区别： 1.mc可缓存图片和视频。rd支持除k/v更多的数据结构; 2.rd可以使用虚拟内存，rd可持久化和aof灾难恢复，rd通过主从支持数据备份; 3.rd可以做消息队列。 原因：mc多线程模型引入了缓存一致性和锁，加锁带来了性能损耗。 redis主从复制如何实现的？redis的集群模式如何实现？redis的key是如何寻址的？ 主从复制实现：主节点将自己内存中的数据做一份快照，将快照发给从节点，从节点将数据恢复到内存中。之后再每次增加新数据的时候，主节点以类似于mysql的二进制日志方式将语句发送给从节点，从节点拿到主节点发送过来的语句进行重放。 分片方式： -客户端分片 -基于代理的分片 ●Twemproxy ●codis -路由查询分片 ●Redis-cluster（本身提供了自动将数据分散到Redis Cluster不同节点的能力，整个数据集合的某个数据子集存储在哪个节点对于用户来说是透明的） redis-cluster分片原理：Cluster中有一个16384长度的槽(虚拟槽)，编号分别为0-16383。每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，可以由用户指定，也可以在初始化的时候自动生成，只有Master才拥有槽的所有权。Master节点维护着一个16384/8字节的位序列，Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽，Master只要判断序列的第二位（索引从0开始）是不是为1即可。这种结构很容易添加或者删除节点。比如如果我想新添加个节点D, 我需要从节点A、B、C中得部分槽到D上。 使用redis如何设计分布式锁？说一下实现思路？使用zk可以吗？如何实现？这两种有什么区别？ redis: 1.线程A setnx(上锁的对象,超时时的时间戳t1)，如果返回true，获得锁。 2.线程B 用get获取t1,与当前时间戳比较,判断是是否超时,没超时false,若超时执行第3步; 3.计算新的超时时间t2,使用getset命令返回t3(该值可能其他线程已经修改过),如果 t1==t3，获得锁，如果t1!=t3说明锁被其他线程获取了。 4.获取锁后，处理完业务逻辑，再去判断锁是否超时，如果没超时删除锁，如果已超时，不用处理（防止删除其他线程的锁）。 zk: 1.客户端对某个方法加锁时，在zk上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点node1; 2.客户端获取该路径下所有已经创建的子节点，如果发现自己创建的node1的序号是最小的，就认为这个客户端获得了锁。 3.如果发现node1不是最小的，则监听比自己创建节点序号小的最大的节点，进入等待。

memcached&redis性能测试

一、Memcached 1.1、memcached简介 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web 应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器S停止运行或崩溃了，所有存放在S上的键/值对都将丢失。 Memcached由Danga Interactive开发，其最新版本发布于2010年，作者为Anatoly Vorobey和Brad Fitzpatrick。用于提升LiveJournal . com访问速度的。LJ每秒动态页面访问量几千次，用户700万。Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。 1.2、Memcached是如何工作的 Memcached的神奇来自两阶段哈希（two-stage hash）。Memcached就像一个巨大的、存储了很多对的哈希表。通过key，可以存储或查询任意的数据。客户端可以把数据存储在多台memcached上。当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点；客户端将请求发送给选中的节点，然后memcached节点通过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）。举个列子，假设有3个客户端1, 2, 3，3台memcached A, B, C：Client 1想把数 据”tuletech”以key “foo”存储。Client 1首先参考节点列表（A, B, C），计算key “foo”的哈希值，假设memcached B被选中。接着，Client 1直接connect 到memcached B，通过key “foo”把数据”tuletech”存储进去。Client 2使用与Client 1相同的客户端库（意味着阶段一的哈希算法相同），也拥有同样的

Redis的5个常见使用场景

Redis的5个常见使用场景概括 大家平时在使用Redis的时候有没有总结过Redis常用于哪些场景呢。下面科多老师带着大家一起来总结一下，希望能够帮助到各位同学。 1、会话缓存（Session Cache） 最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis 缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？ 幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis 来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。 2、全页缓存（FPC） 除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性 问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。 再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。 此外，对WordPress的用户来说，Pantheon有一个非常好的插件wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。 3、队列 Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis 能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。 如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这 里去查看。 4、排行榜/计数器 Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set） 和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可： 当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行： ZRANGE user_scores 0 10 WITHSCORES

memcache、redis、tair性能对比测试报告材料

memcache、redis、tair性能对比测试报告 第1章限制条件 前一周所做的分布缓存技术预言中有包括ehcache、memcache、redis、tair，还包括了基于MongoDB的分布式技术。测试中，考虑到各自功能的差异化特点，其中选择了memcache、redis、tair功能特性相近的缓存服务器进行性能对比，所以ehcache、MongoDB将不做为本次测试的规范，其原因如下： 1）Ehcache是组件级别的缓存，要搭建一个独立的缓存服务器，需要用到ehcache server 模块，这是个war包，能运行在web 容器中，决定整个缓存服务器性能的好坏因素太多，比如web服务器，集群方式等。跟memcache、redis、tair没有对比性。 2）MongoDB是面向文档的数据库，跟缓存没有可比性。 第2章测试场景概述 性能测试包括单机环境和分布式环境，主要针对memcache、redis、tair各缓存服务器在缓存了不同级别的数据下,多个线程并发操作向缓存set/get缓存数据，考虑到网络方面的负载，又将每次set/get操作的缓存数据的大小分为三个不同的级别：1KB,10KB,100KB,通过对上述的条件进行排列，取得以下的测试场景。 第3章单机环境测试 3.1.测试场景： 1.当各缓存的数据库空时，以单线程通过各缓存客户端set调用向服务端推送数据，比较 10000操作所消耗的时间，以上动作通过使用不同大小的单个缓存对象重复三次。2.在场景一完成的情况下，以单线程通过各缓存客户端get调用向服务端获取数据，比较 10000操作所消耗的时间，以上动作通过使用不同大小的单个缓存对象重复三次。3.并发200个线程通过缓存软件的客户set调用向服务端推送数据，每个线程完成10000 次的操作，比较服务器的tps大小，以上动作通过使用不同大小的单个缓存对象重复三

Redis面试题及答案

Redis 是一个基于内存的高性能key-value数据库。(有空再补充，有理解错误或不足欢迎指正) Reids的特点 Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。 因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是已知性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。 另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 Redis支持的数据类型 Redis通过Key-Value的单值不同类型来区分, 以下是支持的类型: Strings Lists Sets 求交集、并集 Sorted Set hashes

为什么redis需要把所有数据放到内存中？ Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。 如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。 如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。 Redis是单进程单线程的 redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销 虚拟内存 当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大. 当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value. vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的. 可能会造成比较长时间的延迟,但是对数据完整性有很好的保证. 自己测试的时候发现用虚拟内存性能也不错。如果数据量很大，可以考虑分布式或者其他数据库 分布式 redis支持主从的模式。原则：Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。 这是一个典型的分布式读写分离模型。我们可以利用master来插入数据，slave提供检索服务。这样可以有效减少单个机器的并发访问数量。

redis-jedis笔记整理

启动Redis服务器 启动客户端 Redis命令目录key(建) 保存键值对set key value 查询指定键对象get key 删除给定键的对象del key1key2…

设置键过期时间EXPIRE key exptime 剩余时间ttl key 查看搜索有键值keys键 migrate指令（移动将数据移动另外一个数据） 将key原子性地从当前实例传送到目标实例的指定数据库上，一旦传送成功，key保证会出现在目标实例上，而当前实例上的key会被删除。 MOVE key db 将数据库的key移动到指定的数据库db当中。如果当前数据库(源数据库)和给定数据库(目标数据库)有相同的名字的给定key,或者key不存在于当前数据库,那么MOVE没有任何效果。因此，也可以利用这一特性，将MOVE当作锁(locking)原语(primitive)。

Obejct{refcount|encoding|idletime} 通常用在debug或者了解为了节省空间使用特殊的编码情况,当redis用作缓存时候,也可以通过OBJECT命令中的信息,决定key的驱逐策略. object refcount key:返回给定key引用所存储的值的次数. object encoding key:返回给定key所存储的值编码可以有 raw(一般字符串)或int(用字符串表示64位数字是为了节约空间)。 ziplist或linkedlist。ziplist是为节约大小较小的列表空间而作的特殊表示。 intset或者hashtable。intset是只储存数字的小集合的特殊表示。 zipmap或者hashtable。zipmap是小哈希表的特殊表示。 ziplist或者skiplist格式。ziplist用于表示小的有序集合，而skiplist则用于表 示任何大小的有序集合。 object idletime key:返回给定key自存储的空闲时间 persist key 将key从带生存时间转换为持久的不带生存时间.

redis系列三-springboot如何使用redis做缓存及缓存注解的用法总结

redis系列三-springboot如何使用redis做缓存及缓存注解的 用法总结 1. 概述 本文介绍spring boot 如何使用Redis做缓存，如何对redis 缓存进行定制化配置(如key的有效期)以及spring boot 如何初始化redis做缓存。使用具体的代码介绍了@Cacheable，@CacheEvict，@CachePut，@CacheConfig等注解及其属性的用法。 2. spring boot集成redis 2.1. application.properties 配置application.properties，包含如下信息： 指定缓存的类型 配置redis的服务器信息 请不要配置spring.cache.cache-names值，原因后面再说 ## 缓存 # spring.cache.cache-names=book1,book2 spring.cache.type=REDIS # REDIS (RedisProperties)

spring.redis.database=0 spring.redis.host=192.168.188.7 spring.redis.password= spring.redis.port=6379 spring.redis.pool.max-idle=8 spring.redis.pool.min-idle=0 spring.redis.pool.max-active=100 spring.redis.pool.max-wait=-1123456789101112131234567891 0111213 2.2. 配置启动类 @EnableCaching: 启动缓存 重新配置RedisCacheManager，使用新的配置的值 @SpringBootApplication @EnableCaching // 启动缓存 public class CacheApplication { private static final Logger log = LoggerFactory.getLogger(CacheApplication.class); public static void main(String[] args) { https://www.wendangku.net/doc/db13744064.html,("Start CacheApplication.. ");

【IT专家】Redis缓存Mysql模拟用户登录Java实现实例

本文由我司收集整编，推荐下载，如有疑问，请与我司联系Redis缓存Mysql模拟用户登录Java实现实例2016/03/18 1 这段时间在研究Redis，作为缓存界的新宠，现在使用它的公司越来越多。本文使用的是最新稳定版Redis3.0.实现的具体逻辑是： 1. 用户登录首先判断是否在redis缓存中，如果在redis缓存中，直接登录成功； 2. 若用户未在redis缓存，则访问Mysql，判断用户是否存在，如果不存在，则提示用户注册；如果存在，则登录成功； 3. 在mysql存在并登录成功的同时，将改条数据用Redis Hash类型进行缓存，并设置过期时间为30分钟； 4. 设置redis最大内存，若超出内存范围，则使用FIFO方式进行清除。 ?本文实现方式为最简单的模拟方式，有的代码有进一步封装得必要。 ?一、首先创建两个类，一个类连接Mysql，一个类连接Redis，并复写相关方法：?public class Mysql {public Connection conn;{try {Class.forName( com.mysql.jdbc.Driver conn=DriverManager.getConnection( jdbc:mysql://localhost/spring , root , root } catch (ClassNotFoundException e) {e.printStackTrace();} catch (SQLException e) {e.printStackTrace();}}} ?public class Redis extends Jedis {public Jedis redis;{redis = new Jedis( 192.168.217.128 , 6379);redis.auth( root }// public static void main(String[] args) {// System.out.println(redis.get( name ));// System.out.println(redis.keys( * ));// // redis.sinter(keys);// }public String get(String key) {return redis.get( name }public String set(String key, String value) {return redis.set(key, value);}public Long del(String... keys) {return redis.del(keys);}// 键值增加字符public Long append(String key, String str) {return redis.append(key, str);}public Boolean exists(String key) {return redis.exists(key);}// Need researchpublic Long setnx(String key, String value) {return redis.setnx(key, value);}public String setex(String key, String value, int seconds) {return redis.setex(key, seconds, value);}public Long setrange(String key, String str, int offset)

Ehcache-Redis-Tair缓存性能对比

Ehcache/Redis/Tair缓存性能对比 后面介绍的不同方式都有测试数据，这些测试数据都是在同一的测试环境下得出的测试结果： 测试机器的配置如下： 64位5核CPU, E5620 @ 2.40GHz，内存8G CDN端缓存 由于计数器的价值并不在，具体的值是多少，尤其是对一些大访问量的商品来说个位或者十位的数据并没有什么意义，所以对这些热门商品的计数器访问可以采用定时更新的办法，可以将计数器的值直接缓存在CDN上或者后端Nginx的缓存中，定时再到数据库服务器上获取最新的计数器的值，这样能够大量减少对后端服务器的访问请求，而且计数器的数据量很小对缓存服务器的空间需求也不大。 改进的结构图如下： 直接在Nginx中利用Cache策略缓存住热门计数器的值，利用http协议的cache+max age来失效缓存的方式更新计数器的值。

优点： 实现方式简单，改动小，能够挡住热门商品的计数器访问请求，采用这种方式对查询请求来说，能达到类似于静态服务器的性能，如Nginx能达到2w的QPS 缺点：没有解决同一商品的计数器合并请求的问题，数据量会增大一倍对更新请求没有办法缓存，只能减少查询请求的压力 基于Java的存储方式 由于目前采用Nginx模块的方法开发，每次修改要重新编译Nginx服务器，所以想采用基于Java的方式，使得维护要容易一些。 选用Ehcache作为数据存储服务器，Ehcache也是基于内存存储，支持定时持久化功能，非常适合存储像计数器这种小数据类型。处理Http请求使用Tomcat容器，结构图如下： 处理逻辑采用一个servlet实现，并且在这个servlet中通过一致性Hash从Ehcache中获取计数器值。 在实际的部署结构中，可以将Tomcat和Ehcache部署在同一台机器上。 基于这种模式的测试结果如下：

基于Spark的机器学习资料66、后台服务代码架构：项目实际应用中redis缓存与数据库一致性问题解决

后台服务代码架构：项目实际应用中redis缓存与数据库一致性问题解决 一、需求起因 假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致【如下图：db中是新数据，cache中是旧数据】。 假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败【如下图：cache 中无数据，db中是旧数据】。 结论：先淘汰缓存，再写数据库。 二、数据不一致原因 先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致。 写流程： （1）先淘汰cache （2）再写db

（1）先读cache，如果数据命中hit则返回 （2）如果数据未命中miss则读db （3）将db中读取出来的数据入缓存 什么情况下可能出现缓存和数据库中数据不一致呢？ 在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署（为了保证可用性，一定是部署多份的），对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）： （a）发生了写请求A，A的第一步淘汰了cache（如上图中的1） （b）A的第二步写数据库，发出修改请求（如上图中的2） （c）发生了读请求B，B的第一步读取cache，发现cache中是空的（如上图中的步骤3） （d）B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了一个脏数据放入cache（如上图中的步骤4） 即在数据库层面，后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，缓存与数据库中的数据不一致出现了 三、问题解决思路 能否做到先发出的请求一定先执行完成呢？常见的思路是“串行化”

Redis备份容灾及高可用方案

Redis 备份、容灾及高可用方案

一，Redis简单介绍 Redis是一个高性能的key-value非关系型数据库，由于其具有高性能的特性，支持高可用、持久化、多种数据结构、集群等，使其脱颖而出，成为常用的非关系型数据库。 此外，Redis的使用场景也比较多。 我们常通过Reids的队列功能做购买限制。比如到节假日或者推广期间，进行一些活动，对用户购买行为进行限制，限制今天只能购买几次商品或者一段时间内只能购买一次。也比较适合适用。 4.排名 Redis在内存中对数字进行递增或递减的操作实现得非常好。所以我们在很多排名的场景中会应用Redis来进行，比如小说网站对小说进行排名，根据排名，将排名靠前的小说推荐给用户。

5.发布/订阅 Redis提供发布和订阅功能，发布和订阅的场景很多，比如我们可以基于发布和订阅的脚本触发器，实现用Redis的发布和订阅功能建立起来的聊天系统。 此外还有很多其它场景，Redis都表现的不错。 二，Redis使用中单点故障问题 正是由于Redis具备多种优良特新，且应用场景非常丰富，以至于Redis在各个公司都有它存在的身影。那么随之而来的问题和风险也就来了。Redis虽然应用场景丰富，但部分公司在实践Redis应用的时候还是相对保守使用单节点部署，那为日后的维护带来了安全风险。 在2015年的时候，曾处理过一个因为单点故障原因导致的业务中断问题。当时的Redis都未采用分布式部署，采用单实例部署，并未考虑容灾方面的问题。 当时我们通过Redis服务器做用户购买优惠商品的行为控制，但后来由于未知原因Redis节点的服务器宕机了，导致我们无法对用户购买行为进行控制，造成了用户能够在一段时间内多次购买优惠商品的行为。 这种宕机事故可以说已经对公司造成了不可挽回的损失了，安全风险问题非常严重，作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。

redis缓存技术学习

1 什么是redis redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。 2 性能怎么样 Redis是一个高性能的key-value内存数据库。官方性能测试结果： set操作每秒110000次，get操作每秒81000次。 3 可不可以存对象 和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。 4 Redis与memcache的最大区别 Replication（树形） data types（String、Lists、Sorted Sets、Hashes） persistence (snapshot、aof) 很多开发者都认为Redis不可能比Memcached快，Memcached完全基于内存，而Redis 具有持久化保存特性，即使是异步的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。 Libevent。和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis 用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis

REDIS缓存穿透,缓存击穿,缓存雪崩原因+解决方案

REDIS缓存穿透，缓存击穿，缓存雪崩原因+解决方案

文档修订摘要

目录 REDIS缓存穿透，缓存击穿，缓存雪崩原因+解决方案 (1) 1. 概述 (4) 2. 初认识 (4) 3. 缓存穿透解决方案 (4) 4. 缓存击穿解决方案 (5) 5. 缓存雪崩的解决方案 (6) 6. 小结 (8)

1.概述 在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。 为了克服上述的问题，项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。 redis技术就是NoSQL技术中的一种，但是引入redis又有可能出现缓存穿透，缓存击穿，缓存雪崩等问题。本文就对这三种问题进行较深入剖析。 2.初认识 ?缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。 ?缓存击穿：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。 ?缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。 3.缓存穿透解决方案 一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不 到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个 足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外 也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系 统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 粗暴方式伪代码： //伪代码public object GetProductListNew() { int cacheTime = 30; String cacheKey = "product_list"; String cacheValue = CacheHelper.Get(cacheKey);

Windows下Redis集群搭建

Windows下搭建Redis集群 Redis 集群简介 Redis 是一个开源的 key-value 存储系统，由于出众的性能，大部分互联网企业都用来做服务器端缓存。Redis 在3.0版本前只支持单实例模式，虽然支持主从模式、哨兵模式部署来解决单点故障，但是现在互联网企业动辄大几百G的数据，可完全是没法满足业务的需求，所以，Redis 在 3.0 版本以后就推出了集群模式。 Redis 集群采用了P2P的模式，完全去中心化。Redis 把所有的 Key 分成了16384 个 slot，每个 Redis 实例负责其中一部分 slot 。集群中的所有信息（节点、端口、slot等），都通过节点之间定期的数据交换而更新。 Redis 客户端可以在任意一个 Redis 实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。 集群搭建 要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时，强烈建议使用六个节点：其中三个为主节点，而其余三个则是各个主节点的从节点。 主节点崩溃，从节点的Redis就会提升为主节点，代替原来的主节点工作，崩溃的主Redis回复工作后，会成为从节点 1). 创建Redis集群目录 在redis安装的根目录下通过命令行创建6个以端口命名的文件夹 mkdir 7000 7001 7002 7003 7004 7005

将安装的redis文件夹中的redis.windows.conf以及redis-server,分别拷贝到新建的六个文件夹中 2). 更改配置 将六个文件夹下的redis.windows.conf文件中以下属性进行修改： port 7001（对应文件夹的端口号） cluster-enabled yes(开启实例的集群模式)去掉注释

Redis开发常用规范

Redis开发常用规范 1.冷热数据分离，不要将所有数据全部都放到Redis中 虽然Redis支持持久化，但是Redis的数据存储全部都是在内存中的，成本昂贵。建议根据业务只将高频热数据存储到Redis中【QPS大于5000】，对于低频冷数据可以使用 MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时速度更快、效率更高！ 2.不同的业务数据要分开存储 不要将不相关的业务数据都放到一个Redis实例中，建议新业务申请新的单独实例。因为Redis为单线程处理，独立存储会减少不同业务相互操作的影响，提高请求响应速度；同时也避免单个实例内存数据量膨胀过大，在出现异常情况时可以更快恢复服务！ 3.规范Key的格式 合适的key，便于查看，统计，排错。 “平台缩写“+“:”+“项目名”+“:”+“业务含义” 例如：GW:TRADE:USERID GW是新网关，TRADE是交易项目，USERID为业务ID。 ":"-作为key分隔符，方便客户端工具作为目录分级 4.存储的Key一定要设置超时时间 如果应用将Redis定位为缓存Cache使用，对于存放的Key一定要设置超时时间！因为若不设置，这些Key会一直占用内存不释放，造成极大的浪费，而且随着时间的推移会导致内存占用越来越大，直到达到服务器内存上限！另外Key的超时长短要根据业务综合评估，而不是越长越好！(某些业务要求key长期有效。可以在每次写入时，都设置超时时间，让超时时间顺延。) public Boolean set(final byte[] key, final byte[] value, final long liveTime) { return redisTemplate.execute(new RedisCallback() {

金蝶云星空K3 Cloud V7.2 分布式缓存使用说明书

金蝶云星空 分布式缓存使用说明书 修改记录 Ver. No 发版日期编制人批准人修改的章节号V1.02017/12/08 刘兵赖碧云初始版本 V1.22018/01/03 刘兵赖碧云 6.1.2 V1.3 2018/02/24 刘兵赖碧云 6.1

目录 1.概述 (3) 1.1.目的 (3) 1.2.范围 (3) 1.3.适用对象 (3) 1.4.参考资料 (3) 2.问题与解决策略 (3) 3.目标和约束 (3) 4.部署Redis服务 (4) 4.1.安装服务--service-install(安装必须的步骤) (4) 4.2.卸载服务--service-uninstall (4) 4.3.启动服务--service-start(安装必须的步骤) (4) 4.4.停止服务--service-stop (5) 4.5.服务配置修改（服务名和端口） (5) 4.6.Redis-cli配置(如果4.1按照2，3小点进行了修改，此节配置可以忽略) (5) 5.Redis配置文件修改 (5) 6.Redis缓存代码示例 (6) 6.1.1.写缓存和读缓存 (6) 6.1.2.错误的读写缓存 (7) 7.附录 (8)

1. 概述 1.1. 目的 为系统集群及分布式应用提供基础缓存服务。 1.2. 范围 适用版本：V6.2和后续版本 1.3. 适用对象 本文档适用于： 开发工程师：部署和开发指导。 实施人员：部署指导。 1.4. 参考资料 Redis相关资料 2. 问题与解决策略 愿景关注点描述与示例 3. 目标和约束 目标： 提供单据和基础数据的分布式缓存支持；

Django使用redis缓存服务器 光环大数据Python培训

https://www.wendangku.net/doc/db13744064.html, Django使用redis缓存服务器光环大数据Python培训 光环大数据Python培训了解到，redis相信大家都很熟悉了，和memcached 一样是一个高性能的key-value数据库，至于什么是缓存服务器，度娘都有很明 白的介绍了，我在这里就不一一介绍了。 那我们一般什么情况下才会使用缓存服务器呢？可不是什么情况都需要的 哦，一般来说是在需要频繁对一个字段读取的时候才会需要将这个字段放入到缓 存服务器上，而且由于key-value数据库一般只是放很简单的数据，所以在选择 保存的对象的时候要注意选择好。 下面我就来介绍如何在Django中配置使用redis数据库，首先是先安装 redis了，在Ubuntu中执行下面这句命令： #安装Redis服务器端 sudo apt-get install redis-server 然后为了能在Django中使用redis，还需要安装redis for Django的插件： pip install django-redis 那么现在就是在Django的settings中配置了。 CACHES = { 'default': { 'BACKEND': 'redis_cache.cache.RedisCache', 'LOCATION': '127.0.0.1:6379', "OPTIONS": { "CLIENT_CLASS":

https://www.wendangku.net/doc/db13744064.html, "redis_cache.client.DefaultClient", }, },}REDIS_TIMEOUT=7*2 4*60*60CUBES_REDIS_TIMEOUT=60*60NEVER_REDIS_TIMEOUT=365*24*60*60 其实只是需要CACHES中的那几条就可以了，后面这三句可以不需要的，只 是我后面的例子里需要用到，我就在这里配置了。 好了，现在连接和配置都已经完成了，那么在项目中该如何使用呢？接下来 看下面这段例子吧。 from django.conf import settingsfrom django.core.cache import cache#read cache user iddef read_from_cache(self, user_name): key = 'user_id_of_'+user_name value = cache.get(key) if value == None: data = None else: data = json.loads(value) return data#write cache user iddef write_to_cache(self, user_name): key = 'user_id_of_'+user_name cache.set(key, json.dumps(user_name), settings.NEVER_REDIS_TIMEOUT) 通过上面的这两个方法就可以实现对redis的读取操作了，只需要将需要的 字段当参数传入到方法中就好了。 那么之前提到的memcached呢？其实也是一样的配置： CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': '127.0.0.1:11211', }} 当然用法也是和我上面的例子是一样的了。其实对于redis这样的缓存服务 器来说，配置都是很简单的，而具体的使用也不难，官网上面也有很多简单明了

黑马程序员：为什么更要用redis,应该如何使用redis

为什么缓存数据库更要首选redis?如何使用redis? 一、使用缓存数据库为什么首选用redis? 我们都知道，把一些热数据存到缓存中可以极大的提高速度，那么问题来了，是用Redis 好还是Memcached好呢，以下是它们两者之间一些简单的区别与比较： 1. Redis不仅支持简单的k/v类型的数据，同时还支持list、set、zset(sorted set)、hash等数据结构的存储，使得它拥有更广阔的应用场景。 2. Redis最大的亮点是支持数据持久化，它在运行的时候可以将数据备份在磁盘中，断电或重启后，缓存数据可以再次加载到内存中，只要Redis配置的合理，基本上不会丢失数据。 3. Redis支持主从模式的应用。 4. Redis单个value的最大限制是1GB，而Memcached则只能保存1MB内的数据。 5. Memcache在并发场景下，能用cas保证一致性，而Redis事务支持比较弱，只能保证事务中的每个操作连续执行。 6. 性能方面，根据网友提供的测试，Redis在读操作和写操作上是略领先Memcached的。 从上面这些看出，Redis的优势比Memcached大，不过Memcached也还是有它用武之地的。要是只选择装其中一种的话，还是要首选Redis。 二、如何使用redis? 你一定要知道的是：redis的key名要区分大小写，在redis中除了和空格外，其他的字符都可以做为key名，且长度不做限制，不过为了性能考虑，一般key名不要设置的太长。redis 功能强大，支持数据类型丰富，以下是redis操作命令大全，基本上涵盖了redis所有的命令！ 1、redis命令基本篇 1)、【set key value 】存入一个key和值。如：set myname reson 2)、【get key 】读取一个key的值。 3)、【del key 】删除一个key。 4)、【del key1 key2 ... keyN 】删除多个key。如：del myname1 myname2 5)、【exists key 】判断一个key是否存在。 6)、【type key 】查看key的类型。 7)、【rename key keyNew 】重命名key名。如：rename myname myname2 8)、【dbsize 】查看当前库中的key的条数。