[TOC]

1. Redis简介

redis全称 Remote Dictionary Service（近程字典服务）。Redis存储的都是K-V对，Redis里寄存的任何一条数据都有惟一的key作为名称。Redis中，所有的key都存储在一个很大的字典中。一个Redis实例有多个库（database），可用过配置文件里的“databases”配置，库索引从0到databases-1，能够应用指令SELECT <index>切换到不通的库。

留神：在Redis命令行，Redis的指令不辨别大小写，然而key辨别大小写。

2. Redis根底数据结构

Redis有五种根底的数据结构：string、list、hash、set、zset。其中list、hash、set、zset称为容器型数据结构，容器型数据结构有两条通用规定：

  • 如果容器不存在，就创立一个，再进行操作。
  • 如果容器里没有数据了，就立刻删除，回收内存。

2.1 string（字符串）

string是Redis最简略的数据结构，一个key对应一个value。Redis的string实际上是应用数组实现的。

string根本指令有：

  • SET：设置一个kv对，示例：SET name lily
  • GET：获取一个key对应的的value，示例：GET name
  • MSET：设置一个或多个kv对，示例：MSET name lily age 18
  • MGET：获取一个或多个key对应的value，示例：MGET name age
  • SETNX：设置一个kv对，如果该key不存在，设置胜利；如果改成存在，设置失败，示例：SETNX name lilei
  • INCR：如果 value 是整数，还能够进行原子加一操作，示例：INCR age
  • DECR：如果 value 是整数，还能够进行原子减一操作，示例：DECR age

2.2 list（列表）

Redis的list是链表实现的，所以其插入删除操作十分快，工夫复杂度都是O(1)，然而索引定位很慢，工夫复杂度是O(n)。当list中没有元素了，该数据结构会主动删除，内存被回收。

list的根本指令有：

  • LPUSH：从右边插入元素，能够插入多个。示例：LPUSH students lily lilei zhangsan
  • LPOP：从右边删除元素，默认删除一个元素。能够指定须要删除的个数，示例：LPOP students 5
  • RPUSH：从左边插入元素，用法同LPUSH
  • RPOP：从左边删除元素，用法同LPOP
  • LRANGE：列出指定范畴里的元素（不会删除元素），示例：LRANGE students 0 -1
  • LINDEX：（工夫复杂度O(n)）获取指定地位的元素，示例：LINDEX students 1
  • LTRIM：（工夫复杂度O(n)）删除指定范畴的元素，示例：LTRIM students 1 2

list罕用场景：

  1. 队列/音讯队列

    从list的一边push数据，从另一边pop数据，就能够作为队列或者音讯队列应用。如果list外面没有数据，LPOP和RPOP不会阻塞，都会立刻返回空。如果用作音讯队列，消费者须要解决LPOP或RPOP立刻返回空的状况，个别的做法是如果返回为空，期待一段时间，再次获取，然而等待时间不好确定，等待时间太短会拉高CPU，造成节约；等待时间太长会升高QPS，影响性能。Redis为list设计了阻塞读指令：BLPOP、BRPOP，指令用法是BLPOP key1 [key2 ...] timeout，这里BLPOP/BRPOP里的B是blocking的意思。阻塞读在list没有数据的时候，会立刻休眠，一旦有数据到了，则立即醒过来。

  2. 栈

    在list的同一边push和pop数据，就能够作为栈应用

  3. 音讯队列

    LPOP或者RPOP操作不会阻塞，如果list外面没有数据，LPOP和RPOP都会立刻返回空，如果

2.3 hash（字典）

Redis的hash的值只能是字符串。

hash的根本指令：

  • HMSET：写入数据，反对批量。示例： HMSET 001 name lily age 18，其中 001 是该条hash的key，name、age 是hash外面的field。
  • HMGET：获取指定hash的某个field的value。示例：HMGET 001 name
  • HGETALL：获取指定hash的所有数据。示例：HGETALL 001
  • HINCRBY ：如果hash外部的value是整型，能够应用HINCRBY进行原子加减操作（只需讲操作数设置为正数就是减法操作），示例：HINCRBY 001 age 1，HINCRBY 001 age -1

2.4 set（汇合）

Redis的set是无序的。

set的根本指令：

  • SADD：退出汇合。示例：SADD students lily lilei
  • SMEMBERS：列出汇合内成员。示例：SMEMBERS students
  • SISMEMBER：查问某个成员是否存在。示例：SISMEMBER students lily
  • SREM：删除某个成员。示例：SREM students lily
  • SCARD：获取汇合长度。示例：SCARD students
  • SPOP：弹出成员，能够指定须要弹出的个数（不晓得默认是1）。示例：SPOP students 5

2.5 zset（有序汇合）

Redis的zset是一个很有特色的数据结构，一方面它是一个set，保障了外部value的唯一性，另一方面它能够给每个value赋予一个score，代表这个value的排序权重。它的外部实现采纳的是”跳跃列表(skiplist)“。

zset根本指令：

  • ZADD：减少成员。示例：ZADD students 95 lily 85 lilei 70 zhangsan 55 lisi
  • ZRANGE：正序获取指定个数的成员。示例：ZRANGE students 0 -1
  • ZREVRANGE：倒序获取指定个数的成员。示例：ZREVRANGE statuents 0 -1
  • ZRANGEBYSCORE：依据score范畴获取成员，正序排列。示例：ZRANGEBYSCORE students 0 60
  • ZREVRANGEBYSCORE：依据score范畴获取成员，顺叙排列。示例：ZREVRANGEBYSCORE students 100 0
  • ZREM：删除指定成员。示例：ZREM students zhangsan
  • ZREMRANGEBYSCORE ：按score范畴删除成员。示例：ZREMRANGEBYSCORE students 0 60
  • ZSCORE：获取成员score。示例：ZSCORE students lilei
  • ZCARD：获取zset长度。示例：ZCARD students

3. Redis通用指令

3.1 EXPIRE

EXPIRE指令用于设置超时，某个key超时后会主动删除。示例：EXPIRE students 10，10秒后students将被主动删除。

超时相干指令有：

  • TTL：查看残余过期工夫，单位是秒。示例：TTL students
  • PTTL：查看残余过期工夫，单位是豪秒。示例：PTTL students

3.2 KEYS

KEYS获取以后库所有的或者特定的key列表，反对通配符”*“。示例：KEYS *查问全副key。

3.3 SCAN

KEYS能够获取key列表，然而有两个显著的毛病：

  1. 没有 offset、limit 参数，一次性返回所有满足条件的key。

  2. KEYS算法是遍历算法，复杂度是O(n)，如果以后库中key很多，应用KEYS会导致Redis卡顿。

    Redis提供了SCAN指令，SCAN相比KEYS有一下特点：

    1. 复杂度尽管也是O(n)，然而它是通过游标分步进行的，不会阻塞线程。
    2. 提供limit参数，能够管制每次返回后果的最大条数。
    3. 提供模式匹配性能。
    4. 服务器不须要为游标保留状态，游标的惟一状态就是SCAN返回给客户端的游标整数。
    5. 返回的后果可能会有反复，须要客户端去重。
    6. 遍历的过程中如果有数据批改，改变后的数据能不能遍历到是不确定的。
    7. 单词返回的后果是空的并不意味着遍历完结，而要看返回的游标值是否为零。

SCAN用法： SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]，示例：scan 0 match s* count 5 type string。SCAN有四个参数，第一个是cursor整数值（相当于offset），第二个是key的正则模式，第三个是count（相当于limit），第四个是key的类型。第一次遍历时cursor值为0，而后将返回后果中的第一个整数值作为下一次遍历的cursor，始终遍历到返回的cursor值为0时完结。须要留神的是，每次SCAN返回的个数不肯定是count，因为这个count不是限定返回后果的数量，而是限定服务器单次遍历的字典槽位数量，只有返回的cursor不是0，就示意遍历还没完结。

3.4 INFO

通过INFO指令，能够清晰地看到Redis外部一系列运行参数，如下：

127.0.0.1:6379> info# Serverredis_version:6.2.1redis_git_sha1:00000000redis_git_dirty:0redis_build_id:fa5dfffb0053744e...# Clientsconnected_clients:2cluster_connections:0maxclients:10000...# Memoryused_memory:895736used_memory_human:874.74Kused_memory_rss:8294400used_memory_rss_human:7.91M...# Persistenceloading:0current_cow_size:0current_fork_perc:0.00%...# Statstotal_connections_received:16total_commands_processed:140instantaneous_ops_per_sec:0...# Replicationrole:masterconnected_slaves:0master_failover_state:no-failovermaster_replid:b81735795edbd0987a13af0b42d5896e0c87e10c...# CPUused_cpu_sys:178.131199used_cpu_user:250.434150used_cpu_sys_children:0.009278...# Modules# Errorstatserrorstat_ERR:count=15# Clustercluster_enabled:0# Keyspacedb0:keys=1,expires=0,avg_ttl=0db1:keys=2,expires=0,avg_ttl=0

INFO指令能够查看某一方面地数据，如下：

127.0.0.1:6379> info clients# Clientsconnected_clients:2cluster_connections:0maxclients:10000...127.0.0.1:6379> info cpu# CPUused_cpu_sys:178.614214used_cpu_user:251.278258used_cpu_sys_children:0.009278...

3.5 其余指令

  • TYPE，查看数据类型。实例：TYPE students
  • SAVE：长久化。
  • BGSAVE：后盾长久化。

4. Redis高级性能

4.1 分布式锁

锁的通用应用办法：“获取锁--业务逻辑--开释锁”。应用Redis实现分布式锁的实质就是”占位“，具体实现是应用SETNX操作同一个key。哪个过程可能SETNX胜利，就示意失去了锁（因为一旦key存在了，其余过程SETNX就会失败）。为了避免过程获取锁后在开释锁之前解体，会应用EXPIRE给锁设置个超时。为了避免过程在SETNX之后，EXPIRE之前解体，须要保障SETNX和EXPIRE的执行是原子化的。SET指令能够实现，示例：SET lock true ex 10 nx。

应用Redis做分布式锁须要留神的问题：

  1. 如果过程在加锁和锁超时之间逻辑执行的工夫太长，过程自身可能会呈现问题，这个须要依据业务解决。而且锁超时之后，其余过程就能够获取到锁，然而如果这时前一个过程开释锁，就可能把第二个过程获取到的锁开释掉。解决这个问题，就须要在SET设置锁的时候把value设置成一个随机数，开释锁的时候先匹配随机数是否统一，而后再删除key。

4.2 延时队列

能够应用Redis的zset实现简略的延时队列，思维很简略，就是把score设置成以后工夫戳加上延时时长，而后有一个轮循，应用ZRANGEBYSCORE获取小于以后工夫戳的元素。如果没有到期，是获取不到放入的元素的。

用法示例：

client = redis.Redis(host="10.53.3.62")now = int(time.time())print("start ", now)client.zadd("tasks", {"task1": now + 5})while 1:    a = client.zrangebyscore("tasks", 0, int(time.time()))    print(int(time.time()), a)    time.sleep(1)# 输入：（能够看到，5s之后能力获取到数据，达到了延时成果）start  16182955671618295567 [b'+']1618295568 [b'+']1618295569 [b'+']1618295570 [b'+']1618295571 [b'+']1618295572 [b'+', b'task1']1618295573 [b'+', b'task1']1618295574 [b'+', b'task1']

4.3 位图

Redis提供了位图数据结构，实际上就是string。Redis提供了以下指令操作位图：

  • SETBIT：设置某位的值。示例：SETBIT w 1 1，示意给w的第1位设置为1。
  • GETBIT：获取某位的值。示例：GETBIT w 1，示意获取w的第1地位。
  • BITCOUNT：统计制订范畴内1的个数。示例：BITCOUNT w 0 1
  • BITPOS：查找指定范畴内呈现的第一个0或1。用法：BITPOS key bit [start] [end]，示例：BITPOS w 1 0 1
  • BITFIELD：反对一次操作多个位。BITFIELD有三个子指令，别离是GET/SET/INCRBY，它们都能够对指定位片段进行读写，然而最多只能解决64个间断的位，如果超过64位，就得应用多个子指令，BITFIELD能够一次执行多个子指令。

4.4 HyperLogLog

HyperLogLog数据结构是Redis的高级数据结构。HyperLogLog提供不准确的去重计数计划，用于不须要准确统计的统计场景。HyperLogLog不保留源数据，只去重并统计个数。HyperLogLog没有提供相似查找的办法，不能应用HyperLogLog判断某个元素是否存在。

HyperLogLog用法示例：

  • PFADD：退出元素（会去重）。示例：PFADD students lily
  • PFCOUNT：统计个数。示例：PFCOUNT students

4.5 布隆过滤器

布隆过滤器用于判断某个元素是否存在。当布隆过滤器说这个元素存在时，这个元素可能存在；当它说这个元素不存在时，那就必定不存在。Redis提供了反对布隆过滤器的插件，须要装置该插件，能力应用。

用法示例：

  • BF.ADD：退出元素。示例：BF.ADD students lily
  • BF.EXISTS：判断元素是否存在。示例：BF.EXISTS students lilei
  • BF.MADD：批量退出元素。示例：BF.MADD students zhangsan lisi wangwu
  • BF.MEXISTS：判断多个元素是否存在。示例：BF.MEXISTS students zhangsan lisi wangwu

布隆过滤器的原理

每个布隆过滤器对应到Redis的数据结构外面就是一个大型的位数组和几个不一样的无偏hash函数。向布隆过滤器种增加key时，会应用多个hash函数对key进行hash算得一个整数索引值而后对数组长度取模失去一个地位，每个hash函数都会算得一个不同得地位，再把位数组得这几个地位都置为1就实现了add操作。所以查问key是否存在时，即便hash后的所有位都为1，也不肯定存在，可能有的地位的1是其余key的hash后果，然而如果hash后的地位中有某个地位的后果不是0，那就示意该key肯定不存在。

4.6 zset简略限流

能够应用Redis的zset限度某个用户在规定的工夫内容许拜访的次数。根本思维也不简单：就是能获取到一个时间段范畴的次数统计。应用zset的ZRANGEBYSCORE指令就能够做到。用户没拜访一次，就往zset外面退出一个元素，score应用工夫戳（要准确的话能够应用毫秒级的），value只有惟一就行，简略起见，能够和score一起应用毫秒级工夫戳。通常只须要保留规定工夫范畴内的拜访次数，如果规定工夫以前的次数不须要存储，能够应用ZREMRANGEBYSCORE删掉规定工夫之前的数据。

用法示例：

client = redis.Redis(host="10.53.3.62")def is_action_allowed(user_id, action_key, period, max_count):    """    指定用户 user_id 的某个行为 action_key 在特定的工夫内 period 只容许产生肯定的次数 max_count    """    key = 'hist:%s:%s' % (user_id, action_key)    now_ts = int(time.time() * 1000)  # 毫秒工夫戳    with client.pipeline() as pipe:        pipe.zadd(key, {now_ts: now_ts})  # 记录拜访次数        pipe.zremrangebyscore(key, 0, now_ts - period * 1000)  # 移除老旧数据        pipe.zcard(key)  # 获取规定工夫内的次数        _, _, current_count = pipe.execute()    return current_count <= max_countfor i in range(20):    can_reply = is_action_allowed("lily", "request", 60, 10)    print(i, can_reply)    # ======= 输入：0 True1 True2 True3 True4 True5 True6 True7 True8 True9 True10 True11 True12 True13 True14 False15 False16 False17 False18 False19 False

4.7 GeoHash

Redis提供了地理位置模块GeoHash，理论是应用zset存储的。

GeoHash用法：

  • GEOADD：减少地位。
  • GEODIST：计算间隔。
  • GEOPOS：查问经纬度，可批量。
  • GEOHASH：获取元素geohash值，能够应用该geohash值到网站http://geohash.org/${hash}直...
  • GEORADIUSBYMEMBER：获取元素左近的其余元素。
  • GEORADIUS：依据坐标值查问左近的元素。

示例：

127.0.0.1:6379> GEOADD sz 114.035529 22.615108 beizhan(integer) 1127.0.0.1:6379> GEOADD sz 113.821705 22.638172 jichang(integer) 1127.0.0.1:6379> GEODIST sz beizhan jichang km"22.1019"127.0.0.1:6379> GEOPOS sz beizhan1) 1) "114.03552979230880737"   2) "22.61510789529109644"127.0.0.1:6379> GEOHASH sz beizhan1) "ws10duyns30"127.0.0.1:6379> GEORADIUSBYMEMBER sz beizhan 30 km count 3 asc1) "beizhan"2) "jichang"127.0.0.1:6379> GEORADIUSBYMEMBER sz beizhan 20 km count 3 asc1) "beizhan"127.0.0.1:6379> GEORADIUS sz 113.821705 22.638172 23 km withdist count 3 asc1) 1) "jichang"   2) "0.0001"2) 1) "beizhan"   2) "22.1018"

4.8 PubSub

Redis的list能够做为简略的音讯队列应用，然而它不反对多播。Redis提供了PubSub，一个简略的音讯队列，反对多播。它的用法比较简单，就是订阅和公布。PubSub指令：

  • SUBSCRIBE： 订阅，反对模式匹配，反对批量订阅。
  • PUBLISH：公布。

PubSub毛病：

PubSub的音讯不会长久化，如果没有消费者，生产者公布的音讯会丢掉。

5. Redis进阶篇

5.1 长久化

Redis提供了两种长久化机制：一种是RBD（Redis Database），即快照；另一种是AOF（Append Only File）日志追加。RBD是一次全量备份，AOF日志是间断的增量备份。RBD是内存数据的二进制序列化模式，在存储上十分紧凑，而AOF日志记录的是内存数据批改的指令记录文本。AOF日志会缓缓变大，所以须要定期进行AOF重写，给AOF日志进行瘦身。

5.1.1 RBD

Redis应用操作系统的多过程COW（Copy On Write，写时复制）机制来实现快照长久化。Redis在长久化时fork一个子过程，快照长久化齐全交给子过程来解决，父过程持续解决客户端申请。子过程刚刚产生时，和父过程共享内存外面的代码段和数据段，当父过程接管到客户端申请须要批改数据时，会利用COW机制将须要批改的页复制一份进行批改，不会扭转原来的页，所以子过程看到的还是它本人产生的那一瞬间的数据（这就是叫这种长久化机制为”快照“的起因），能够安心的遍历数据进行长久化。

5.1.2 AOF

AOF日志存储的是Redis服务器的程序指令序列，AOF日志只记录对内存进行批改的指令记录。Redis复原的时候，只须要依据AOF日志”重放“就行了。

Redis在长期运行过程中，AOF日志会越变越大，所以须要对AOF日志进行瘦身。Redis提供了bgrewirteaof指令用于对AOF日志进行瘦身。其原理就是开拓一个子过程对内存进行遍历转换成一系列Redis的操作指令，序列化到一个新的AOF日志文件中。序列化结束后再将操作期间产生的增量AOF日志追加到这个新的AOF日志文件中，追加结束后就立刻代替旧的AOF日志文件，瘦身工作就实现了。

当Redis对AOF日志文件进行写操作时，实际上是将内容写到了内核为文件描述符调配的一个内存缓存中，而后内核会异步将脏数据刷回到磁盘。Redis提供了不同的刷盘策略：

  • 定时刷盘，工夫距离可配。（如果须要开启长久化，个别采纳这种形式。）
  • 来一个指令就刷盘一次。（会影响性能）
  • 永不被动刷盘，让操作系统决定何时刷盘。（很不平安）

5.1.3 混合长久化

将RDB文件的内容和增量的AOF日志文件存在一起，这里的AOF日志不是全量的日志，而是自快照长久化开始到长久化完结的这段时间产生的增量AOF日志。Redis重启的时候，先加载RBD的内容，再重放增量AOF日志。

5.2 管道

Redis的管道并不是Redis服务器提供的一个技术，而是客户端提供的。原理就是客户端将多个申请并行发送，节俭期待每个申请返回响应的工夫。服务端还是按失常程序解决每个申请。

5.3 事务

Redis也反对事务，相干指令有：

  • MULTI：批示事务的开始，相当于关系型数据库里的begin。
  • EXEC：执行事务，相当于关系型数据库里的commit。
  • DISCARD：抛弃事务，相当于关系型数据库里的rollback。

简略事务应用示例：

# === EXEC 应用示例127.0.0.1:6379> MULTIOK127.0.0.1:6379(TX)> INCR studentsQUEUED127.0.0.1:6379(TX)> INCR studentsQUEUED127.0.0.1:6379(TX)> EXEC1) (integer) 12) (integer) 2127.0.0.1:6379> get students"2"127.0.0.1:6379> # ==== DISCARD 应用示例127.0.0.1:6379> MULTIOK127.0.0.1:6379(TX)> INCR students1QUEUED127.0.0.1:6379(TX)> INCR students1QUEUED127.0.0.1:6379(TX)> DISCARDOK127.0.0.1:6379> get students1(nil)

Redis在开始一个事务时，所有的指令在EXEC之前不执行，而是缓存在服务器的一个事务队列中。如果服务器收到EXEC指令，就开始执行整个事务队列，并在执行结束后一次性返回所有指令的运行后果；如果服务器收到DISCARD指令，则抛弃事务缓存队列中的所有指令。

Redis的事务是不反对原子性的，即便事务执行两头遇到了失败，后续指令也还是会继续执行。如下：

127.0.0.1:6379> MULTIOK127.0.0.1:6379(TX)> SET name lilyQUEUED127.0.0.1:6379(TX)> INCR nameQUEUED127.0.0.1:6379(TX)> set after helloQUEUED127.0.0.1:6379(TX)> EXEC1) OK2) (error) ERR value is not an integer or out of range3) OK127.0.0.1:6379> GET after  # 即便第二个指令出错了，第三个指令依然失常执行"hello"

Redis能够应用WATCH指令配合事务来解决并发批改的问题（WATCH机制是一种乐观锁）。WATCH会在事务开始之前监督一个或多个变量，当事务开始执行时（发送了EXEC），Redis会查看被WATCH监督的变量是否被以后事务之外的申请批改过，如果有批改过，EXEC指令会返回nil，Redis事务执行返回失败。

127.0.0.1:6379> WATCH monitorOK127.0.0.1:6379> INCR monitor  # 在事务之前批改了 monitor(integer) 1127.0.0.1:6379> MULTIOK127.0.0.1:6379(TX)> INCR monitorQUEUED127.0.0.1:6379(TX)> EXEC  # 事务执行失败(nil)# =====127.0.0.1:6379> WATCH monitor1OK127.0.0.1:6379> MULTIOK127.0.0.1:6379(TX)> incr monitor1QUEUED127.0.0.1:6379(TX)> incr monitor1QUEUED127.0.0.1:6379(TX)> EXEC1) (integer) 12) (integer) 2

留神：Redis禁止在MULTI和EXEC之间执行WATCH指令，而必须在MULTI之前检视变量。

5.4 淘汰策略

当Redis内存应用超出配置参数“maxmemory”限度的内存后，Redis提供了几种可选策略（配置里的“maxmemory-policy”）来让用户决定如果解决。Redis配置文件外面能够看到这些策略：

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory# is reached. You can select among five behaviors:## volatile-lru -> Evict using approximated LRU among the keys with an expire set.# allkeys-lru -> Evict any key using approximated LRU.# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.# allkeys-lfu -> Evict any key using approximated LFU.# volatile-random -> Remove a random key among the ones with an expire set.# allkeys-random -> Remove a random key, any key.# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)# noeviction -> Don't evict anything, just return an error on write operations.
  • volatile-lru：从设置了过期工夫的key的汇合中应用近似LRU算法进行淘汰。没有设置过期工夫的key不会被淘汰。
  • allkeys-lru：从所有的key的汇合中应用近似LRU算法进行淘。
  • volatile-lfu：从设置了过期工夫的key的汇合中应用近似LFU算法进行淘汰。
  • allkeys-lfu：从所有的key的汇合中应用近似LFU算法进行淘。
  • volatile-random：从设置了过期工夫的key的汇合中随机淘汰key。
  • allkeys-random：从所有的key的汇合中随机淘汰key。
  • volatile-ttl：从设置了过期工夫的key的汇合中依据剩余时间ttl的值进行淘汰，ttl越小的越先被淘汰。
  • noeviction：不做任何操作，只对写申请返回谬误，读申请能够持续进行。

5.4.1 LRU

LRU，Least Recentlly Used，最近起码应用。LRU算法应用一个链表，保护被拜访的key的程序，每个key被拜访的时候，就把key移到表头，所以链表的程序就是key最近被拜访的工夫程序。如果空间满了，就从表尾删除数据。

应用python的OrderedDict（字典+双向链表）实现简略的LRU算法：

from collections import OrderedDictclass LRUDict(OrderedDict):    def __init__(self, capacity):        super().__init__()        self.capacity = capacity        self.items = OrderedDict()    def __setitem__(self, key, value):        old_value = self.items.get(key)        if old_value is not None:  # 如果key存在，挪动到表头            self.items.pop(key)            self.items[key] = value        elif len(self.items) < self.capacity:  # 如果key不存在，且空间够用，直接插入到表头            self.items[key] = value        else:            self.items.popitem(last=False)  # 如果空间满了，删除最初一个元素，而后将key插入到表头            self.items[key] = value    def __getitem__(self, key):        value = self.items.get(key)        if value is not None:  # 每次拜访key，都把key挪动到表头            self.items.pop(key)            self.items[key] = value        return value    def __repr__(self):        return repr(self.items)d = LRUDict(10)for i in range(15):    d[i] = i    print(d)

5.4.2 LFU

LFU，Least Frequently User，最近不常常应用。LFU算法是在给每个key统计拜访次数。在每个key被拜访的时候，计数加一，如果多个计数雷同，则按拜访工夫排序。空间满的时候，从计数最小的开始删除。

6. Redis集群篇

6.1 主从同步

6.1.1 增量同步

Redis增量同步同步的是指令流，主节点将会批改数据的指令记录在内存buffer中，而后异步将buffer中的指令同步到从节点，从节点一边执行同步的指令流，一边向主节点反馈同步偏移地位。

Redis的复制内存buffer是一个定长的环形数组，如果数组内容满了，就会从头开始笼罩后面的内容。如果网络不好，从节点同步太滞后，可能会造成从节点数据失落。

6.1.2 全量同步（快照同步）

快照同步首先在主库上进行一次bgsave将数据长久化到磁盘，而后再将快照文件的内容全副传送到从节点。从节点将快照文件全副接管结束后，清空内存占用的数据，对快照文件执行一次全量加载，加载实现后再告诉主节点持续进行增量同步。

6.1.3 无盘复制

无盘复制是指服务器间接通过套接字将快照内容发送到从节点，主节点一边遍历内存，一边将内容发送到从节点。从节点先将收到的内容存入磁盘，而后进行一次性加载。

6.2 Sentinel（哨兵）模式

Redis Sentinel是Redis官网提供的一种高可用计划。Redis Sentinel自身能够单点部署，也能够集群部署。

Redis Sentinel负责继续监控主从节点的衰弱，当主节点挂掉时，主动抉择一个最优的从节点切换为主节点。客户端连贯Redis集群时，会首先连贯Sentinel，通过Sentinel查问主节点的地址，而后客户端间接去连贯主节点进行数据交互。主节点故障时，客户端再向Sentinel获取新的主节点地址。

6.3 Cluster

Redis Cluster是Redis作者本人提供的去中心化的Redis集群化计划。Redis Cluster中每个节点负责存储一部分数据，节点之间通过非凡的二进制协定交互集群信息。Redis Cluster起码须要三个主节点，个别会为每个主节点配置一个（或多个）从节点，某个主节点故障时，集群会主动将该主节点的某个从节点晋升为主节点。如果产生故障的主节点没有从节点，那么实践上整个集群将不可用，不过Redis提供了参数“cluster-require-full-coverage”能够容许局部节点故障，其它节点还能够持续提供对外拜访。

Redis Cluster将所有的数据划分为16384个槽（solt），每个节点负责其中一部分槽位，槽位的信息存储在每个节点中。当Redis Cluster的客户端连贯集群时，它会失去一份集群的槽位配置信息，这样当客户端须要查找某个key时，能够间接定位到指标节点。

6.3.1 槽定位算法

Cluster默认应用crc16算法进行hash再对16384取模来失去具体槽位。Cluster提供有hash tag容许用户应用指定的tag来定位槽。如果key蕴含{...}模式，则只应用“{”和“}”之间的字符串进行哈希以定位槽，例如key是"xxxxxsdfdf{hello}"，或“fff222222{hello}”的，都只会应用“hello”来定位槽。

6.3.2 跳转

当客户端向一个谬误的节点发送指令，该节点发现key所在的槽位不归本人治理，这时它会向客户端发送一个非凡的跳转指令MOVED携带指标操作的节点地址，通知客户端去连贯这个节点。

6.3.3 迁徙

Redis Cluster迁徙的单位是槽，Redis一个槽一个槽进行迁徙，当一个槽正在迁徙时，这个槽就处于两头过渡状态。这个槽的源节点的状态为migrating，在指标节点的状态为importing，示意数据正在从源流向指标。

迁徙工具redis-trib首先会在源和指标节点设置好两头过渡状态，而后一次性获取源节点槽位的所有key，再挨个key进行迁徙。每个key迁徙过程是：从源节点获取内容，发送到指标节点，指标节点存入内存，源节点删除内容。留神，这里的迁徙过程是同步的，在指标节点存入内存到源节点删除key之间，节点的主线程会处于阻塞状态，晓得key被胜利删除。所以集群环境下要防止大key的产生。

6.3.4 节点下线

因为Redis Cluster是去中心化的，一个节点认为某个节点失联了并不代表所有节点都认为它失联了。只有当大多数节点都认定某个节点失联了，集群才认为该节点须要进行主从切换来容错。

7. 参考文献

  1. 《Redis深度历险：外围原理和利用实际》