代码拉取完成，页面将自动刷新
同步操作将从 turnon/db-tutorial 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。
键的类型只能为字符串，值支持的五种类型数据类型为：字符串、列表、集合、有序集合、散列表。
Redis 与 Memcached 因为都可以用于缓存，所以常常被拿来做比较，二者主要有以下区别：
数据类型
数据持久化
分布式
内存管理机制
Redis 单机 QPS 能达到 100000。
Redis 是单线程模型（Redis 6.0 已经支持多线程模型），为什么还能有这么高的并发？
I/O 多路复用
I/O 多路复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
Redis 基本数据类型：STRING、HASH、LIST、SET、ZSET
Redis 高级数据类型：BitMap、HyperLogLog、GEO
更详细的特性及原理说明请参考：Redis 数据类型和应用
最大缓存 - Redis 允许通过 maxmemory 参数来设置内存最大值。
失效时间 - 作为一种定期清理无效数据的重要机制，在 Redis 提供的诸多命令中，EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT 以及 SETEX 和 PSETEX 均可以用来设置一条键值对的失效时间。而一条键值对一旦被关联了失效时间就会在到期后自动删除（或者说变得无法访问更为准确）。
淘汰策略 - 随着不断的向 Redis 中保存数据，当内存剩余空间无法满足添加的数据时，Redis 内就会施行数据淘汰策略，清除一部分内容然后保证新的数据可以保存到内存中。内存淘汰机制是为了更好的使用内存，用一定得 miss 来换取内存的利用率，保证 Redis 缓存中保存的都是热点数据。
非精准的 LRU - 实际上 Redis 实现的 LRU 并不是可靠的 LRU，也就是名义上我们使用 LRU 算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。
Redis 可以为每个键设置过期时间，当键过期时，会自动删除该键。
对于散列表这种容器，只能为整个键设置过期时间（整个散列表），而不能为键里面的单个元素设置过期时间。
可以使用 EXPIRE 或 EXPIREAT 来为 key 设置过期时间。
🔔 注意：当
EXPIRE的时间如果设置的是负数，EXPIREAT设置的时间戳是过期时间，将直接删除 key。
示例：
redis> SET mykey "Hello"
"OK"
redis> EXPIRE mykey 10
(integer) 1
redis> TTL mykey
(integer) 10
redis> SET mykey "Hello World"
"OK"
redis> TTL mykey
(integer) -1
redis>
内存淘汰只是 Redis 提供的一个功能，为了更好地实现这个功能，必须为不同的应用场景提供不同的策略，内存淘汰策略讲的是为实现内存淘汰我们具体怎么做，要解决的问题包括淘汰键空间如何选择？在键空间中淘汰键如何选择？
Redis 提供了下面几种内存淘汰策略供用户选：
noeviction - 当内存使用达到阈值的时候，所有引起申请内存的命令会报错。这是 Redis 默认的策略。allkeys-lru - 在主键空间中，优先移除最近未使用的 key。allkeys-random - 在主键空间中，随机移除某个 key。volatile-lru - 在设置了过期时间的键空间中，优先移除最近未使用的 key。volatile-random - 在设置了过期时间的键空间中，随机移除某个 key。volatile-ttl - 在设置了过期时间的键空间中，具有更早过期时间的 key 优先移除。allkeys-lru。allkeys-random。volatile-ttl。volatile-lru 和 volatile-random 适合既应用于缓存和又应用于持久化存储的场景，然而我们也可以通过使用两个 Redis 实例来达到相同的效果。allkeys-lru 策略从而更有效率的使用内存。Redis 删除失效主键的方法主要有两种：
maxmemory 限定时，触发主动清理策略，该策略由启动参数的配置决定主键具体的失效时间全部都维护在 expires 这个字典表中。Redis 是内存型数据库，为了保证数据在宕机后不会丢失，需要将内存中的数据持久化到硬盘上。
Redis 支持两种持久化方式：RDB 和 AOF。
AOF(Append Only File) 是以文本日志形式将所有写命令追加到 AOF 文件的末尾，以此来记录数据的变化。当服务器重启的时候会重新载入和执行这些命令来恢复原始的数据。AOF 适合作为 热备。
Redis 服务器是一个事件驱动程序，服务器需要处理两类事件：
文件事件（file event） - Redis 服务器通过套接字（Socket）与客户端或者其它服务器进行通信，文件事件就是对套接字操作的抽象。服务器与客户端（或其他的服务器）的通信会产生文件事件，而服务器通过监听并处理这些事件来完成一系列网络通信操作。时间事件（time event） - Redis 服务器有一些操作需要在给定的时间点执行，时间事件是对这类定时操作的抽象。Redis 基于 Reactor 模式开发了自己的网络时间处理器。
虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器实现了高性能的网络通信模型。
文件事件处理器有四个组成部分：套接字、I/O 多路复用程序、文件事件分派器、事件处理器。
时间事件又分为：
Redis 将所有时间事件都放在一个无序链表中，每当时间事件执行器运行时，通过遍历整个链表查找出已到达的时间事件，并调用响应的事件处理器。
服务器需要不断监听文件事件的套接字才能得到待处理的文件事件，但是不能一直监听，否则时间事件无法在规定的时间内执行，因此监听时间应该根据距离现在最近的时间事件来决定。
事件调度与执行由 aeProcessEvents 函数负责，伪代码如下：
def aeProcessEvents():
## 获取到达时间离当前时间最接近的时间事件
time_event = aeSearchNearestTimer()
## 计算最接近的时间事件距离到达还有多少毫秒
remaind_ms = time_event.when - unix_ts_now()
## 如果事件已到达，那么 remaind_ms 的值可能为负数，将它设为 0
if remaind_ms < 0:
remaind_ms = 0
## 根据 remaind_ms 的值，创建 timeval
timeval = create_timeval_with_ms(remaind_ms)
## 阻塞并等待文件事件产生，最大阻塞时间由传入的 timeval 决定
aeApiPoll(timeval)
## 处理所有已产生的文件事件
procesFileEvents()
## 处理所有已到达的时间事件
processTimeEvents()
将 aeProcessEvents 函数置于一个循环里面，加上初始化和清理函数，就构成了 Redis 服务器的主函数，伪代码如下：
def main():
## 初始化服务器
init_server()
## 一直处理事件，直到服务器关闭为止
while server_is_not_shutdown():
aeProcessEvents()
## 服务器关闭，执行清理操作
clean_server()
从事件处理的角度来看，服务器运行流程如下：
Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。
MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。
事务可以一次执行多个命令， 并且有以下两个重要的保证：
MULTI 命令用于开启一个事务，它总是返回 OK 。
MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。
以下是一个事务例子， 它原子地增加了 foo 和 bar 两个键的值：
> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1
EXEC 命令负责触发并执行事务中的所有命令。
MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。EXEC ，那么事务中的所有命令都会被执行。当执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出。
示例：
> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"
WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。
被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回 nil-reply 来表示事务已经失败。
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。
这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。
WATCH 使得 EXEC 命令需要有条件地执行：事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。
WATCH 命令可以被调用多次。对键的监视从 WATCH 执行之后开始生效，直到调用 EXEC 为止。
用户还可以在单个 WATCH 命令中监视任意多个键，例如：
redis> WATCH key1 key2 key3
OK
当 EXEC 被调用时， 不管事务是否成功执行， 对所有键的监视都会被取消。
另外， 当客户端断开连接时， 该客户端对键的监视也会被取消。
使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务， 有时候程序需要同时对多个键进行加锁， 然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时， 就可以使用 UNWATCH 命令来取消目前对键的监视， 中途放弃这个事务， 并等待事务的下次尝试。
WATCH 可以用于创建 Redis 没有内置的原子操作。
举个例子，以下代码实现了原创的 ZPOP 命令，它可以原子地弹出有序集合中分值（score）最小的元素：
WATCH zset
element = ZRANGE zset 0 0
MULTI
ZREM zset element
EXEC
Redis 不支持回滚。Redis 不支持回滚的理由：
Redis 是一种基于 C/S 模型以及请求/响应协议的 TCP 服务。Redis 支持管道技术。管道技术允许请求以异步方式发送，即旧请求的应答还未返回的情况下，允许发送新请求。这种方式可以大大提高传输效率。
在需要批量执行 Redis 命令时，如果一条一条执行，显然很低效。为了减少通信次数并降低延迟，可以使用 Redis 管道功能。Redis 的管道（pipeline）功能没有提供命令行支持，但是在各种语言版本的客户端中都有相应的实现。
以 Jedis 为例：
Pipeline pipe = conn.pipelined();
pipe.multi();
pipe.hset("login:", token, user);
pipe.zadd("recent:", timestamp, token);
if (item != null) {
pipe.zadd("viewed:" + token, timestamp, item);
pipe.zremrangeByRank("viewed:" + token, 0, -26);
pipe.zincrby("viewed:", -1, item);
}
pipe.exec();
注意：使用管道发送命令时，Redis Server 会将部分请求放到缓存队列中（占用内存），执行完毕后一次性发送结果。如果需要发送大量的命令，会占用大量的内存，因此应该按照合理数量分批次的处理。
Redis 提供了 5 个发布与订阅命令：
| 命令 | 描述 |
|---|---|
SUBSCRIBE |
SUBSCRIBE channel [channel ...]—订阅指定频道。 |
UNSUBSCRIBE |
UNSUBSCRIBE [channel [channel ...]]—取消订阅指定频道。 |
PUBLISH |
PUBLISH channel message—发送信息到指定的频道。 |
PSUBSCRIBE |
PSUBSCRIBE pattern [pattern ...]—订阅符合指定模式的频道。 |
PUNSUBSCRIBE |
PUNSUBSCRIBE [pattern [pattern ...]]—取消订阅符合指定模式的频道。 |
订阅者订阅了频道之后，发布者向频道发送字符串消息会被所有订阅者接收到。
某个客户端使用 SUBSCRIBE 订阅一个频道，其它客户端可以使用 PUBLISH 向这个频道发送消息。
发布与订阅模式和观察者模式有以下不同：
分割线以下为 Redis 集群功能特性
关系型数据库通常会使用一个主服务器向多个从服务器发送更新，并使用从服务器来处理所有读请求，Redis 也采用了同样的方式来实现复制特性。
Redis 2.8 版本以前的复制功能基于 SYNC 命令实现。
Redis 的复制功能分为同步（sync）和命令传播（command propagate）两个操作：
同步（sync） - 用于将从服务器的数据库状态更新至主服务器当前的数据库状态。命令传播（command propagate） - 当主服务器的数据库状态被修改，导致主从数据库状态不一致时，让主从服务器的数据库重新回到一致状态。这种方式存在缺陷：不能高效处理断线重连后的复制情况。
Redis 2.8 版本以后的复制功能基于 PSYNC 命令实现。PSYNC 命令具有完整重同步和部分重同步两种模式。
完整重同步（full resychronization） - 用于初次复制。执行步骤与 SYNC 命令基本一致。部分重同步（partial resychronization） - 用于断线后重复制。如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只需接收并执行这些写命令，即可将主从服务器的数据库状态保持一致。部分重同步有三个组成部分：
从服务器向要复制的主服务器发送 PSYNC <runid> <offset> 命令
主服务器通过向从服务传播命令来更新从服务器状态，保持主从数据一致。
从服务器通过向主服务器发送命令 REPLCONF ACK <replication_offset> 来进行心跳检测，以及命令丢失检测。
Sentinel（哨兵）可以监听主服务器，并在主服务器进入下线状态时，自动从从服务器中选举出新的主服务器。
💡 更详细的特性及原理说明请参考：Redis 哨兵
分片是将数据划分为多个部分的方法，可以将数据存储到多台机器里面，也可以从多台机器里面获取数据，这种方法在解决某些问题时可以获得线性级别的性能提升。
假设有 4 个 Reids 实例 R0，R1，R2，R3，还有很多表示用户的键 user:1，user:2，... 等等，有不同的方式来选择一个指定的键存储在哪个实例中。最简单的方式是范围分片，例如用户 id 从 0~1000 的存储到实例 R0 中，用户 id 从 1001~2000 的存储到实例 R1 中，等等。但是这样需要维护一张映射范围表，维护操作代价很高。还有一种方式是哈希分片，使用 CRC32 哈希函数将键转换为一个数字，再对实例数量求模就能知道应该存储的实例。
主要有三种分片方式：
Redis 社区中有多种编程语言的客户端，可以在这里查找合适的客户端：Redis 官方罗列的客户端清单
redis 官方推荐的 Java Redis Client：
💡 Redis 常用于分布式缓存，有关缓存的特性和原理请参考：缓存基本原理
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。