Redis笔记

Redis作为一款高效的键值型内存数据库,值得学习。本文梳理学习过程中的笔记。

Redis笔记

钱文品. Redis深度历险:核心原理与应用实践[M]. 北京: 电子工业出版社, 2019.

1 概述

1.1 了解

Redis主要可以用作:

  • 缓存:记录点赞数、缓存热帖、用户行为、榜单……;
  • 分布式锁

1.2 安装

1
2
3
4
5
# ubuntu
sudo apt install redis

# centos
sudo yum install redis

1.3 运行

1
2
# redis command-line interface
redis-cli

2 数据结构

Redis提供5种基础数据结构,分别为:字符串string、列表list、字典hash、集合set、有序集合zset。

2.1 字符串string

Redis所有数据结构都以唯一的key字符串作为名称,以此获得相应的value数据。

Redis string内部数据结构类似Java的ArrayList,预分配冗余空间以免频繁分配内存。当字符串小于1MB时,扩容方法为加倍当前容量;当超过1MB时,每次扩充1MB空间。字符串最大长度为512MB。

2.2 列表list

Redis list类似Java中的LinkedList链表(实际上不完全是),双向链表,插入和删除时间复杂度O(1),查询时间复杂度O(N)。

当list删除最后一个元素时,该数据结构被自动删除,内存回收。

双向链表可以被用来实现队列、栈。

2.2.1 底层实现——ziplist与quicklist

Redis list底层实现是quicklist数据结构。

当list元素较少时,采用ziplist(压缩列表)。ziplist用连续内存将所有的元素连续存储。

当list元素较多时,采用quicklist(快速链表)。quicklist是将链表与ziplist结合的产物,每一个ziplist包含多个元素,却仅需两个前后指针,因此,quicklist避免了为每个元素配备prev/next双指针的空间消耗。quicklist既满足了快速的插入和删除,又避免了产生较大的空间冗余。

2.3 字典hash

Redis hash类似Java中的HashMap,无序字典,存储键值对。

hash采用数组+链表的数据结构,但hash的值只能是字符串。

当hash删除最后一个元素时,该数据结构被自动删除,内存回收。

2.3.1 渐进式rehash

Java的HashMap每次rehash需要一次性全部rehash,而Redis的hash在rehash时,为了避免阻塞服务,采用渐进式rehash。

渐进式rehash在rehash时,保留新旧两个hash结构。旧的hashtable仍可用作查询,同时将旧的hashtable持续rehash到新的hashtable上。等rehash全部完成后,才以新的hashtable取代旧的hashtable。

2.4 集合set

Redis set相当于Java中的HashSet,内部的键值对时无序的、唯一的。

set的底层实现相当于是hash,只不过hash的value村的都是NULL。

当set删除最后一个元素时,该数据结构被自动删除,内存回收。

2.5 有序集合zset

Redis zset类似Java的SortedSet和HashMap的结合体。

zset一方面是set,value元素是唯一的,另一方面其有序性是依靠为value赋予score作为排序权重实现的。

当zset删除最后一个元素时,该数据结构被自动删除,内存回收。

2.5.1 跳跃列表skiplist

zset内部的排序功能采用skiplist实现。

skiplist中,高层(level)链表跨度大,连接比较大的跨度范围。越往底层跨度越小,表示比较小的跨度范围。通过skiplist,可以从大范围缩小到小范围,快速定位插入与查询的位置。

2.6 小结

2.6.1 通用性质

list, set, hash, zset这四种容器数据结构具有两个通用性质:

  1. create if not exists:操作时,如容器不存在,则新建;
  2. drop if not elements:操作时,如容器为空,则删除。

2.6.2 过期时间

所有数据结构都可设置过期时间,过期则删除。

字符串设置过期时间后,如果字符串被修改,则过期时间失效。

3 应用

3.1 分布式锁

setnx (set if not exists)指令做锁标记,del删除锁标记。

1
2
3
> setnx lock:resource_a true
> expire lock:resource_a 5
> del lock:resource_a
  • 事务需要判单自己能够设置对争用资源的分布式锁,才能修改资源。
  • expire设置5秒过期时间,防止死锁。

3.2 延时队列

list可以作为异步消息队列。

rpush/lpush操作入队列,lpop/rpop操作出队列。

blpop/brpop可以阻塞式(blocking)地读取数据。

3.3 位图

get/set处理整个位图的内容。

getbit/setbit处理各个位。

bitcount统计范围内1的位数。

bitpos查询第一个0或1的位置。

bitfield,包含get/set/incrby子指令,可以读取、设置和自增指定范围的位。bitfield可以混合多个子指令执行。

3.4 HyperLogLog

统计PV量无需去重,incrby自增就可以。统计UV则需要去重,不是简单的自增,去重常用的set集合在数据量很大时会消耗巨大的内存空间。

HyperLogLog可以实现去重计数问题。

pfadd添加元素(增加对该元素的计数);

pfcount统计元素的计数。

pfmerge用于合并多个pf计数元素为同一个元素,合并pf计数值。

pf指的是HyperLogLog的发明人Philippe Flajolet教授。

HyperLogLog数据结构在计数较小时采用 稀疏矩阵存储,在计数超过阈值时,转变为稠密矩阵。

HyperLogLog占据12KB存储空间,在数据量很大时,比set小了太多。

HyperLogLog的原理是调整低位连续零位的最大长度K,若K越大,概率越低,则说明计数N越大,由此通过有限的连续零位K来估算计数N,K与N存在线性相关性。占用12KB则是因为Redis的HyperLogLog实现采用个桶,每个桶maxbit为6 bit,因此

3.5 布隆过滤器(Bloom Filter)

RedisBloom

RedisBloom: Probabilistic Data Structures for Redis

The RedisBloom module provides four data structures: a scalable Bloom filter, a cuckoo filter, a count-min sketch, and a top-k. These data structures trade perfect accuracy for extreme memory efficiency, so they’re especially useful for big data and streaming applications.

bf.add添加元素;

bf.exists检查元素是否存在。

bf.madd添加多个元素;

bf.mexists检查多个元素是否存在。(返回分别表示每个元素存在性的0/1)

bf.reverse在添加元素之前预设布隆过滤器的key, error_rate和initial_size。

布隆过滤器:

  • 添加时计算元素k个哈希,将对应的k个bit置为1;
  • 检查存在时计算元素k个哈希,检查对应的k个bits是否都为1,如果是,则元素存在,否则不存在。

对hash函数数量k,布隆过滤器bit数量m,预计元素数量n,错误率f,有公式:

  • 此时错误率最低。

3.6 简单限流

以zset的score范围来划定滑动窗口。score存储timestamp,这样就可以计算得出时间窗口内的元素数量,判断访问计数是否超限。

zset不适合数量很大的限流,例如:60秒内限流100万次,100万个元素的zset会占用过大的空间。

3.7 漏斗限流

redis-cell

A Redis module that provides rate limiting in Redis as a single command. Implements the fairly sophisticated generic cell rate algorithm (GCRA) which provides a rolling time window and doesn’t depend on a background drip process.

漏斗(funnel)容量有限,不满时可以装入液体,漏斗满时无法装入液体,需要等漏斗内的液体慢慢流走一部分,才能继续装入。

1
2
3
4
5
6
CL.THROTTLE user123 15 30 60 1
▲ ▲ ▲ ▲ ▲
| | | | └───── apply 1 token (default if omitted)
| | └──┴─────── 30 tokens / 60 seconds
| └───────────── 15 max_burst
└─────────────────── key "user123"

3.8 GeoHash

通过GeoHash功能,可以快速找出指定经纬度周围的元素。

GeoHash将二维平面处理成网格,然后不断地行、列二分,对二维坐标进行编码,映射为一维整数。

Redis中,GeoHash将经纬度编码为52位整数,存入zset中,score是经纬度编码整数(zset的浮点数score可以无损存储52位整数),value是元素值。在zset中,借助skiplist来找出元素附近范围的其他元素是很容易的事情。使用坐标时,将编码整数解码还原为坐标即可。

geoadd添加经纬度坐标;

geodist计算元素之间的距离;

geopos读取元素的坐标;

geohash读取元素的经纬度编码字符串(base32编码的坐标值)。

georadiusbymember查询指定元素附近的其他元素。

注意:集群中,单个key下存储的坐标数量不宜过多(超过1MB),避免集群迁移出现卡顿。或者干脆采用独立实例,不做集群。

3.9 scan

keys列出符合pattern的key,采用遍历算法,时间复杂度O(N)。

scan从指定cursor开始,匹配pattern,扫描count个槽位。相较于keys,scan可以避免每次遍历整个redis内存槽。

Redis本身就相当于是一个很大的HashMap。scan的遍历顺序采用高位进位加法,以此避免字典扩容和缩容时重复或遗漏遍历槽位。

zscan遍历zset元素;

sscan遍历set元素;

hscan遍历hash元素。

3.10 避免bigkey

在业务开发中,避免大key的产生。

大key数据不论是在集群迁移时,还是在容器需要扩容时,哪怕是在回收时(因较大内存空间的分配和回收),都容易造成卡顿。

可以采用--bigkeys选项来检索大key。

1
redis-cli --bigkeys

4 原理

4.1 I/O模型

Redis是单线程程序。

Redis通过非阻塞I/O多路复用技术来提高单线程I/O处理效率。

对于每一个客户端socket连接,Redis为其关联:

  1. 一个指令队列,用于从客户端socket连接中读取指令。指令队列中的指令遵循FCFS;
  2. 一个响应队列,用于向客户端socket连接中写入指令。如果响应队列为空,说明暂无响应数据,则将该响应队列移出多路复用的write_fds以节省select代价。

对于定时任务,Redis采用最小堆进行管理:

  • 最临近的任务放在堆顶;
  • 取堆顶任务的距离时间作为select操作的timeout,这样在这段时间内就可以放心地select,不必担心错过定时任务。

4.2 通信协议

RESP (Redis Serialization Protocol)是Redis采用地通信协议,这是一种文本协议,实现简单,解析性能好。

RESP把数据分为5种最小单元类型,制定规则:

  1. 单行字符串,以+开头;
  2. 多行字符串,以$<len>开头;
  3. 整数,以:开头;
  4. 错误消息,以-开头;
  5. 数组,以*<len>开头。

4.3 持久化

4.3.1 快照

Redis采用fork机制创建子进程来导出快照。

内存空间采用COW机制,因此,父进程照常处理事务,修改的数据会记录在新的空间中,而子进程看到的仍然是fork时的内存数据,不用担心导出时数据又被更新的情况。

4.3.2 AOF日志

AOF日志记录Redis实例创建以来所有的修改性指令序列。

Redis收到客户端修改指令后,进行检查和处理,如果指令执行成功,则立即将该指令文本存储到AOF日志中。

AOF重写:长时间修改会积累大量的AOF日志,Redis可以开辟一个子进程遍历生成新的AOF指令日志,替代旧的AOF日志,起到日志瘦身的效果。(对同一个key频繁修改,会产生大量AOF日志,但实际上存一项就可以了。)

fsync:Redis定期调用fsync确保AOF日志实实在在写入磁盘,避免突然断电造成内存缓冲数据丢失。

混合持久化:快照 + AOF日志(增量)。提高重启效率,避免重做全部的AOF日志操作。

4.4 管道

Redis客户端重排指令。将读指令连续归在一起,写指令连续归在一起。这样客户端只需要向操作系统网络写缓冲区写一次,读缓冲区读一次即可,服务器端同理。节省了网络读写的次数。

4.5 事务

Redis可以实现begin, commit和rollback的事务功能。

4.6 PubSub

PubSub, Publisher Subscriber.

消息多播,一个Publisher可以向多个Subscriber提供消息。

Subscriber需要先订阅若干个channel,随后,Publisher向channel中发布数据,Redis会将数据提供给订阅该channel的所有Subscriber。

但是,如果subscriber掉线了,过后再上线,就不会再收到掉线时错过的消息了。Redis宕机时,就相当于时没有任何subscriber的情况,会造成所有的消息都被直接丢失的情况。

Redis在5.0版本开始提供新的Stream数据结构,实现了持久化的消息队列。

4.7 节省空间

4.7.1 32bit vs 64bit

32bit编译的Redis比64bit编译的版本节省一半的指针内存消耗。如使用内存不超过4GB,采用32bit即可。

4.7.2 基于ziplist的小对象压缩存储

相较于传统的链表,每个entry作为一个节点,都需要配备prev/next两个指针,ziplist则将多个entry以数组的形式存为一个节点,减少所需的指针空间。

每个ziplits节点存储:

  1. zlbytes,4字节,ziplist占用的字节数;
  2. zltail,4字节,最后一个entry的偏移地址;
  3. zllen,2字节,ziplist的entry数量;
  4. entry数组,存储若干entry;
  5. zlend,1字节,幻数255标记结尾。

4.7.3 基于intset的紧凑整数数组

inset数据结构包含:

  1. encoding,表示value的位宽;
  2. length,表示元素的个数;
  3. value数组,存储若干value。

若整数用uint16表示即可,intset就用uint16;需要升级到uint32或uint64时再动态升级。

4.7.4 内存回收机制

删除key时,内存不会立即全部回收释放交给操作系统,而是会预留部分内存给未来的使用需求。

4.7.5 内存分配算法

Redis有多种内存分配算法:

  1. jemalloc,facebook;
  2. tcmalloc,google。

Redis默认使用jemalloc,该库性能稍好。

通过info memory可以查到当前使用的内存分配库。

5 集群

多个Redis节点组成Redis集群。

5.1 Redis集群与CAP定理

5.1.1 CAP定理

CAP定理指的是分布式系统的一致性(Consistency)、可用性(Availability)和分区容忍性(Partition tolerance)不能三者兼得,最多只能满足两项。

当网络异常时,分布式节点之间无法连接,形成网络分区现象,如果要容忍分区情况,此时有两种选择:

  1. 保证可用性:即允许对每个节点的读和写,这样一来,节点之间就会因为无法立即同步而出现数据不一致的问题,放弃了强一致性,即AP;
  2. 放弃可用性:只允许对每个节点的读,禁止写,这样一来,能保证节点之间的数据一致性,但用户无法更新数据,损失了可用性,即CP[;

也就是说,网络分区发生时,一致性和可用性无法两全。

5.1.2 最终一致性

Redis的主从节点之间异步同步,不能保证严格的强一致性,因此Redis的选择是放弃一致性,转而满足可用性和分区容忍性。

Redis提供的是最终一致性(Eventually consistent),网络断开时,主从节点之间会出现不一致,但网络恢复后,会多策略地尽快同步,最终主从节点保持一致。

5.2 集群同步技术

5.2.1 主从同步与从从同步

主从同步(master-slave sync):主节点与从节点之间同步,主节点把数据复制(replicate)到从节点。

从从同步(slave-slave sync):从节点把数据复制到另一个从节点。

通过引入从从同步,可以降低主节点的同步负担。

5.2.2 增量同步

Redis同步指令流。

Redis主节点把写指令记录在本地的指令缓存(buffer)中,异步地将缓存中地指令同步到从节点,即增量同步。

指令缓存采用的是定长环形数组,因此,如果数组写满了,就会重新从头写入,也就覆盖掉了原有内容。如果网络分区发生时,有节点上产生大量写指令,为了避免指令缓存被覆盖导致写入记录丢失,不能只依赖指令缓存来保存未同步的指令。

5.2.3 快照同步

快照同步:执行bgsave操作,把内存中的数据全部快照存储到硬盘文件中。

增加从节点:增加新的从节点时,通过快照同步为从节点全量加载数据,随后再做增量同步。

快照同步死循环问题:当快照同步太慢,或者指令缓存太小时,就会出现快照同步还没结束,指令缓存就写满的情况。这样一来,指令就不得不直接写入,那快照就过期了,又得重新做一遍快照,而重新做快照可能又太慢,指令缓存又写满了……。为避免死循环,需要设置一个合适的指令缓存大小。

5.2.4 无盘复制

快照同步需要写入磁盘,有不小的文件IO代价。而且Redis执行AOF时需要做fsync,如果此时快照同步,就不得不延后fsync,这样AOF就延后了,指令执行就延后了。

为此,Redis 2.8.18开始支持无盘复制,主节点可以通过socket通信直接把快照发给从节点,避免磁盘上的文件IO代价。

5.2.5 wait指令实现同步复制

Redis的复制本身时异步执行的,因此不具备强一致性。

通过wait指令,可以实现Redis的同步复制,保证系统的(在没有网络分区情况下的)强一致性。

wait可以有限等待,也可以无限等待N个从节点同步完成,再执行后续指令。

如果无限等待时,Redis出现网络分区,那么同步无法完成,就会一直阻塞,导致Redis失去可用性。

5.3 Sentinel:自动主从切换技术

Redis Sentinel集群通常包含3~5个Sentinel节点,保证Sentinel的可用性。

Sentinel集群持续监控主节点和从节点的状态,一旦出现问题,就自动提升一个可用的从节点为主节点,取代故障的不可用的主节点。

Sentinel的具体工作流程:

  1. Client首先向Sentinel请求主节点的地址;
  2. Sentinel将最新的主节点地址返回给Client;
  3. Client访问主节点。

5.4 Codis:中心化集群方案

Codis是Redis集群方案之一,在Codis基础之上,开发出了TiDB。

单个Redis节点如果存储太多数据,会使得快照文件rdb特别大,导致同步起来很耗时,而且全量恢复也变得很慢。

Codis通过把数据分散到众多Redis节点上,来避免每个节点的数据量过大。

Codis对key做哈希,映射到1024个槽位(slots),以此求模,取得数据应该映射到的节点序号。分配完成后,Codis节点会存储槽位与Redis节点的映射关系。

Codis的扩容:可以通过增加Redis节点来扩容集群的容量。

Codis通过mget指令可以从分散的节点上取数据并汇总给用户。

5.5 Cluster:去中心化集群方案

Redis Cluster是去中心化的集群方案,每个节点都是对等的。

Redis Cluster把数据分为16384个槽位(),每个节点负责一部分的槽位。客户端根据key来确定槽位,进而确定目标节点。如果客户端向错误的节点发送请求,该节点会计算key对应的槽位,向客户端发送重定向的响应,告知客户端目标节点。

节点迁移:迁移的最小单位是槽位,流程是从源节点获取内容,然后存到目标节点,最后从源节点中删除内容。

容错:Redis Cluster可以为每个主节点设置若干从节点,自动实现故障时从节点提升为主节点。

可能下线与确定下线:集群节点采用Gossip协议来广播自己的状态。一个节点发现某个节点失联,则进入可能下线(PFail, Possibly Fail)状态。集群中大多数节点都收到该节点失联的消息,则标记该节点为确定下线(Fail)状态。

6 扩展

6.1 Stream:Redis5.0的消息队列

Redis Stream是Redis 5.0中退出的一款新的支持多播的可持久化消息队列,极大地借鉴了Kafka的设计。

Redis Stream通过消息链表将所有加入的消息串起来,每个消息包含唯一ID(timestampInMillis-sequence)和消息内容(形如hash结构的键值对)。

消费组:每个Stream可以挂载多个消费组(Consumer Group),不同消费组互相独立,互不影响,每个消费组都有一个游标last_delivered_id在Stream数组上向前移动,表示当前已经消费到哪条消息了。

消费者:每个消费组中可以包含多个消费者(Consumer),消费者之间为竞争关系,任意一个消费者读取消息都会使消费组的游标last_delivered_id向前移动。

PEL:每个消费者有一个的PEL(Pending Entries List),PEL是一个状态列表pending_ids,记录已经被客户端读取,但尚未收到ACK的消息ID。通过PEL可以确保客户端至少消费了消息1次,而不会在网络传输中途丢失了消息。 客户端重连时,可以根据PEL重新获取一遍接收失败的消息。

分区:Redis没有原生支持分区,分区Stream可以通过在客户端设计哈希策略来实现。Kafka原生支持Partition也是通过客户端的HashStrategy来决定将不同的消息加入不同的分区的。

xgroup create:创建消费组,创建时需要指定从哪个消息ID开始消费。

xadd:加入消息;

xdel:删除消息,只设置标志位,不实际删除消息;

xrange:获取消息列表,自动过滤标记为删除的消息;

xlen:获取消息长度;

del:删除整个消息列表的所有消息。

6.2 info:状态诊断

info指令可查询:

  1. server:服务器信息;
  2. clients:客户端信息;
  3. memory:运行内存统计数据;
  4. persistence:持久化信息;
  5. stats:通用统计数据;
  6. replication:主从复制;
  7. cpu:cpu使用情况;
  8. cluster:集群信息;
  9. keyspace:键值对统计信息。

查询方式如:

Redis内:

1
> info memory

Redis外:

1
redis-cli info memory

6.3 Redlock分布式锁

Sentinel集群中,主节点挂掉后,从节点取而代之,但主节点的分布式锁没有同步到从节点,新升任主节点的从节点中没有这个分布式锁,就会造成不安全性。

对多个对等的Redis实例,Redlock基于“大多数机制”,加锁时,向过半的节点发送set指令,过半的节点加锁成功,则本次加锁成功;解锁时,向所有节点发送del指令。因为Redlock需要向多个节点进行读写,考虑出错重试、时钟漂移等问题,相对单实例Redis的性能会下降一点。

6.4 过期策略

设置了expire时间的key放在一个独立的字典里。

Redis的过期策略既有定期扫描,也有惰性策略。

定期扫描,Redis默认每秒10次过期扫描,扫描算法为:

  1. 从过期字典中随机选出20个key;
  2. 删除这20个key中已经过期的key;
  3. 如果过期key的比例超过1/4,则重复步骤1.。

为避免循环过度造成线程卡死,默认设置扫描时间上限为25ms。这个25ms的依据是,1秒10次,每次25ms,总共最多占用250ms,即1/4的CPU时间。Redis实际上限制的是CPU时间,避免过期扫描耗费超过1/4的CPU时间。

如果大量key同时过期,Redis就会循环扫描字典,删除key,直到过期字典中的过期key比例变低。当过期的key数量很多的时候,扫描时间是完全可能撞到25ms的上限的。再加上内存回收的代价,就会产生比较多的CPU消耗。如果此时新来的请求设置的超时时间很短,例如10ms,就会导致刚设置数据,就开始扫描,等25ms扫描完,才来得及处理客户端的读取操作时,key早就过期了。客户端就发现自己刚设置的值,立即去修改就会超时过期,实际上是因为Redis的过期策略在间隔中消耗了时间。

为了避免以上问题,一方面,考虑到过期策略扫描耗时,过期时间不宜设置的过短;另一方面,避免大量key同时过期,哪怕对统一的过期时间加上一个随机量也好。

惰性策略:访问key时对key的过期时间进行检查,如果过期了就删除。

从节点不会主动执行过期策略,主节点删除节点并同步del给从节点,从节点收到后写入AOF,跟着主节点照做就是。不过因为同步是异步的,所以主从节点之间强一致性无法保证。

6.5 内存淘汰算法

Redis不允许发生swap,因为会造成性能急剧下降。

当Redis实际内存超过maxmemory时,有几种maxmemory-policy:

  1. noeviction:可读不可写;
  2. volatile-lru:淘汰过期集合中最少使用的(LRU);
  3. volatile-ttl:淘汰过期集合中剩余寿命TTL最小的key;
  4. volatile-random:淘汰过期集合中随机key;
  5. allkeys-lru:全体key中淘汰LRU;
  6. allkeys-random:全体key中淘汰随机的key。

6.6 懒惰删除

del直接删除,通常非常快,但对象非常大时,删除操作会造成单线程卡顿。

Redis 4.0引入的unlink可以解决卡顿问题,unlink卸下待删除对象,然后交给后台线程去异步地回收内存。

Redis 4.0为flushdb和flushall都引入了异步化,加上async选项即可,如:flushall async

异步删除借助异步队列实现,MainThread通过submitTask将待删除对象放入ConcurrentQueue,懒惰删除线程LazyFreeThread从中fetchTask并执行异步删除。

Redis的AOF Sync需要将AOF日志同步到磁盘,需要调用sync函数,因为sync比较耗时,因此采用异步线程去调用,该异步线程也有自己的任务队列,存放AOF Sync任务。

Redis在del和flush以外,也会在key过期、LRU淘汰、rename指令执行时回收内存。节点接受全量同步rdb文件后也会清空内存以载入数据。这些删除场景涉及额外的选项:

  1. slave-lazy-flush:从节点接受rdb文件后的flush操作;
  2. lazyfree-lazy-eviction:内存达到maxmemory时进行淘汰;
  3. lazyfree-lazy-expire-key:过期删除;
  4. lazyfree-lazy-server-del rename:指令删除destKey。

6.7 Jedis

Jedis是Java的Redis开源客户端。

因为Jedis对象不是线程安全的,所以使用Jedis是从Jedis连接池JedisPool中取出一个Jedis对象归该线程独占,用完了再还给连接池。

Jedis默认没有重试机制,网络抖动造成连接断开,再发送指令就会报错。需要手动捕获JedisConnectionException进行重连处理。

6.8 Redis安全

6.8.1 指令安全

rename-command既可以将已有命令更名,也可以更名为空字符串,从而屏蔽该命令被调用。

6.8.2 端口安全

bind指令规定监听的IP地址。

requirepass设置密码访问限制,从节点masterauth设置于主节点同步连接密码。

6.8.3 脚本安全

避免UGC的Lua脚本。

避免以root权限启动Redis。

6.8.4 SSL代理

使用SSH保护Redis连接。

使用官方推荐的spiped工具对SSH通道进行二次加密。spiped是一款加密代理软件。

支持我的写作!(Support my writing!)

欢迎关注我的其它发布渠道