redis大要

灰太狼 2023-01-06 15:53 105阅读 0赞

### 目录 ###

*  redis问题画像
 *  redis特点
 *  string
 *  hash
 *  list
 *  set
 *  zset
 *  bitmap
 *  skiplist
 *  ziplist
 *  hyperloglog
 *  geo
 *  bloom filter
 *  cuckoo filter
 *  pipeline
 *  慢查询
 *  发布订阅
 *  RDB
 *  AOF
 *  读写分离
 *  规避复制风暴
 *  Sentinel
 *  Cluster
 *  四种批量操作优化的方法
 *  Redis开发规范
 *  redis内存管理
 *  巨人的肩膀
 *  VChat

--------------------

# redis问题画像 #

![在这里插入图片描述][20210114223436368.png]

# redis特点 #

数据在计算机存储的位置的不同，性能及成本也是不同的，一般来说遵循速度越快，成本越高，容量越小的规律  
![在这里插入图片描述][20210118205814150.png]

在redis的`bin`目录下，一般会有这几个二进制文件  
![在这里插入图片描述][20210130214644815.png]

<table> 
 <thead> 
  <tr> 
   <th>Redis可执行文件</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>redis-server</td> 
   <td>Redis服务器</td> 
  </tr> 
  <tr> 
   <td>redis-cli</td> 
   <td>Redis命令行客户端</td> 
  </tr> 
  <tr> 
   <td>redis-benchmark</td> 
   <td>Redis性能测试工具</td> 
  </tr> 
  <tr> 
   <td>redis-check-aof</td> 
   <td>AOF文件修复工具（服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。可以使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复）</td> 
  </tr> 
  <tr> 
   <td>redis-check-dump</td> 
   <td>RDB持久化文件检测和修复工具</td> 
  </tr> 
  <tr> 
   <td>redis-sentinel</td> 
   <td>Sentinel服务器</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th>Redis常用配置</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>daemonize</td> 
   <td>是否开启守护进程</td> 
  </tr> 
  <tr> 
   <td>port</td> 
   <td>对外端口号</td> 
  </tr> 
  <tr> 
   <td>logfile</td> 
   <td>Redis系统日志</td> 
  </tr> 
  <tr> 
   <td>dir</td> 
   <td>Redis工作目录</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>keys</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>dbsize</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>del</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>exists</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>expire</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>type</td> 
   <td>O(1)</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][20210127211618983.png]

![在这里插入图片描述][20210118220600644.png]

![在这里插入图片描述][20210118222058671.png]

由于redis是单线程的，一次只运行一条命令，所以注意要拒绝长（慢）命令，比如：  
`keys`，`flushall`，`flushdb`，`slow lua script`，`mutil/exec`，`operate big value（collection）`

其实不是单线程，有的命令会开一个独立的线程去执行，比如：`fysnc file descriptor`，`close file descriptor`

# string #

由于redis单线程，无竞争，所以天然就适合做计数器

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>set key value</td> 
   <td>设置key-value</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>get key</td> 
   <td>获取key-value</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>del key</td> 
   <td>删除key-value</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>setnx key</td> 
   <td>根据key是否存在，设置key-value</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>Incr、decr</td> 
   <td>计数</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>mget、mset</td> 
   <td>批量操作key-value</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>getset key newvalue</td> 
   <td>set key newvalue并返回旧的value</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>append key value</td> 
   <td>将value追加到旧的value</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>strlen key</td> 
   <td>返回字符串的长度（注意中文）</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>getrange key start end</td> 
   <td>获取字符串指定下标所有的值</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>setrange key index value</td> 
   <td>设置指定下标所有对应的值</td> 
   <td>O(1)</td> 
  </tr> 
 </tbody> 
</table>

# hash #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>hget、 hset、 hdel</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>hexists</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>hincrby</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>hgetall、 hvals、 hkeys</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>hmget、 hmset</td> 
   <td>O(n)</td> 
  </tr> 
 </tbody> 
</table>

# list #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>rpush key valuel value2…valueN</td> 
   <td>从列表右端插入值（1-N个）</td> 
   <td>O(1~n)</td> 
  </tr> 
  <tr> 
   <td>lpush key valuel value2…valueN</td> 
   <td>从列表左端插入值（1-N个）</td> 
   <td>O(1~n)</td> 
  </tr> 
  <tr> 
   <td>linsert key beforelafter value newValue</td> 
   <td>在list指定的值前或后插入newValue</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>Itrim key start end</td> 
   <td>按照索引范围修剪列表</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>Irange key start end（包含end）</td> 
   <td>获取列表指定索引范围所有item</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>lindex key index</td> 
   <td>获取列表指定索引的item</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>lpop key</td> 
   <td>从列表左侧弹出一个item</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>rpop key</td> 
   <td>从列表右侧弹出一个item</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>llen key</td> 
   <td>获取列表长度</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>lrem key count value</td> 
   <td>根据count值，从列表中删除所有value相等的项<br>（1）count&gt;0，从左到右，删除最多count个value相等的项<br>（2）count&lt;0，从右到左，删除最多Math.abs（count）个value相等的项<br>（3）count=0，删除所有value相等的项</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>lset key index newValue</td> 
   <td>设置列表指定索引值为newValue</td> 
   <td>O(n)</td> 
  </tr> 
  <tr> 
   <td>blpop key timeout</td> 
   <td>Ipop阻塞版本，timeout是阻塞超时时间，timeout=0为永远不阻塞</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>brpop key timeout</td> 
   <td>rpop阻塞版本，timeout是阻塞超时时间，timeout=0为永远不阻塞</td> 
   <td>O(1)</td> 
  </tr> 
 </tbody> 
</table>

# set #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>sadd key element</td> 
   <td>向集合key添加element（如果element已经存在，添加失败）</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>srem key element</td> 
   <td>将集合key中的element移除掉</td> 
   <td>O(1)</td> 
  </tr> 
 </tbody> 
</table>

# zset #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>zadd key score element</td> 
   <td>添加score和element</td> 
   <td>O(logN)</td> 
  </tr> 
  <tr> 
   <td>zrem key element</td> 
   <td>删除元素</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>zscore key element</td> 
   <td>返回元素的分数</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>zincrby key increScore element</td> 
   <td>增加或减少元素的分数</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>zcard key</td> 
   <td>返回元素的总个数</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>zrange key start end[WITHSCORES]</td> 
   <td>返回指定索引范围内的升序元素[分值]</td> 
   <td>O（log（n）+m）</td> 
  </tr> 
  <tr> 
   <td>zrangebyscore key minScore maxScore[WITHSCORES]</td> 
   <td>返回指定分数范围内的升序元素[分值]</td> 
   <td>O（log（n）+m）</td> 
  </tr> 
  <tr> 
   <td>zcount key minScore maxScore</td> 
   <td>返回有序集合内在指定分数范围内的个数</td> 
   <td>O（log（n）+m）</td> 
  </tr> 
  <tr> 
   <td>zremrangebyrank key start end</td> 
   <td>删除指定排名内的升序元素</td> 
   <td>O（log（n）+m）</td> 
  </tr> 
  <tr> 
   <td>zremrangebyscore key minScore maxScore</td> 
   <td>删除指定分数内的升序元素</td> 
   <td>O（log（n）+m）</td> 
  </tr> 
 </tbody> 
</table>

# bitmap #

通过一个bit位来表示某个元素对应的值或者状态,其中的key就是对应元素本身  
![在这里插入图片描述][20210130234745280.png]

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>setbit key offset value</td> 
   <td>给位图指定索引设置值</td> 
  </tr> 
  <tr> 
   <td>getbit key offset</td> 
   <td>获取位图指定索引的值</td> 
  </tr> 
  <tr> 
   <td>bitcount key[start end]</td> 
   <td>获取位图指定范围（start到end，单位为字节，如果不指定就是获取全部）位值为1的个数</td> 
  </tr> 
  <tr> 
   <td>bitpos key targetBit [start] [end]</td> 
   <td>计算位图指定范围（start到end，单位为字节，如果不指定就是获取全部）第一个偏移量对应的值等于targetBit的位置</td> 
  </tr> 
 </tbody> 
</table>

> 应用场景
> 
>  *  计数统计  
>     比如用户上线次数统计、统计活跃用户、用户签到、用户在线状态

# skiplist #

跳跃表(skiplist)是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。在大部分情况下，跳跃表的效率可以和平衡树（关系型数据库的索引就是平衡树结构）相媲美，并且因为跳跃表的实现比平衡树要来得更为简单，所以有不少程序使用跳跃表来代替平衡树。

跳跃表支持评价O(logN)、最坏O(N)复杂度的节点查找，还可以通过顺序性操作来批量处理节点。

![在这里插入图片描述][20210131134855299.png]

# ziplist #

ziplist是用一个字符串来实现的双向链表结构，其实是通过把短结构压缩在一起来达到节省内存的做法，节省了前驱和后驱指针的空间，在 64 位机器上共节省了 8 个字节， 这让数据在内存中更为紧凑。

> ziplist的结构由以下几个部分构成：  
> ![在这里插入图片描述][20210131142349159.png]
> 
>  *  zlbytes：压缩列表的字节长度，占4个字节，因此压缩列表最长(2^32)-1字节；
>  *  zltail：压缩列表尾元素相对于压缩列表起始地址的偏移量，占4个字节；
>  *  zllen：压缩列表的元素数目，占两个字节；那么当压缩列表的元素数目超过(2^16)-1怎么处理呢？此时通过zllen字段无法获得压缩列表的元素数目，必须遍历整个压缩列表才能获取到元素数目；
>  *  entryX：压缩列表存储的若干个元素，可以为字节数组或者整数；entry的编码结构后面详述；
>  *  zlend：压缩列表的结尾，占一个字节，恒为0xFF。

![在这里插入图片描述][20210127212343611.png]

# hyperloglog #

基于HyperLogLog算法，即对集合去重元素的计数，极小空间完成独立数量统计，本质还是字符串。

在输入元素的数量不超过2^64个，计算基数所需的内存最多12KB，该结构使用一种近似值算法，标准误差0.81%。

![在这里插入图片描述][20210130235934607.png]

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>PFADD key element [element …]</td> 
   <td>将除了第一个参数以外的参数存储到以第一个参数为变量名的HyperLogLog结构中。这个命令的一个副作用是它可能会更改这个HyperLogLog的内部来反映在每添加一个唯一的对象时估计的基数(集合的基数)。如果一个HyperLogLog的估计的近似基数在执行命令过程中发了变化， PFADD返回1，否则返回0，如果指定的key不存在，这个命令会自动创建一个空的HyperLogLog结构（指定长度和编码的字符串）。如果在调用该命令时仅提供变量名而不指定元素也是可以的，如果这个变量名存在，则不会有任何操作，如果不存在，则会创建一个数据结构。如果 HyperLogLog 的内部被修改了,那么返回 1,否则返回 0 。</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>PFCOUNT key [key …]</td> 
   <td>当参数为一个key时,返回存储在HyperLogLog结构体的该变量的近似基数，如果该变量不存在,则返回0。当参数为多个key时，返回这些HyperLogLog并集的近似基数，这个值是将所给定的所有key的HyperLoglog结构合并到一个临时的HyperLogLog结构中计算而得到的。HyperLogLog可以使用固定且很少的内存（每个HyperLogLog结构需要12K字节再加上key本身的几个字节）来存储集合的唯一元素。返回的可见集合基数并不是精确值， 而是一个带有 0.81% 标准错误（standard error）的近似值。</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>PFMERGE destkey sourcekey [sourcekey …]</td> 
   <td>将多个 HyperLogLog 合并（merge）为一个 HyperLogLog ， 合并后的 HyperLogLog 的基数接近于所有输入 HyperLogLog 的可见集合（observed set）的并集。合并得出的 HyperLogLog 会被储存在目标变量（第一个参数）里面， 如果该键并不存在， 那么命令在执行之前， 会先为该键创建一个空的。</td> 
   <td>O（N）</td> 
  </tr> 
 </tbody> 
</table>

> 使用建议  
> 1.是否能容忍错误？（错误率：0.81%）  
> 2.是否需要单条数据？  
>   
>   
> 应用场景
> 
>  *  非精确统计，HyperLogLog是近似值算法，有0.81%标准误差
>  *  数据量巨大，不大就用不上，大材小用，浪费空间
>  *  只能统计集合基数（去重）数量，而没办法去知道具体的内容，自然也没办法返回集合元素
> 
> 比如统计 IP 数、统计 UV 数、统计用户每天搜索不同词条个数、统计在线用户数

# geo #

用于存储地理位置信息，并对存储的信息进行操作。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

![在这里插入图片描述][20210131002942496.png]

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>geoadd key longitude latitude member [longitude latitude member …]</td> 
   <td>将指定的地理空间位置（纬度、经度、名称）添加到指定的key中。</td> 
   <td>O(log(N))</td> 
  </tr> 
  <tr> 
   <td>geopos key member [member …]</td> 
   <td>可以获取集合中任意元素的经纬度坐标，可以一次获取多个</td> 
   <td>O(log(N))</td> 
  </tr> 
  <tr> 
   <td>geodist key member1 member2 [unit]</td> 
   <td>返回两个给定位置之间的距离。</td> 
   <td>O(log(N))</td> 
  </tr> 
  <tr> 
   <td>georadius key longitude latitude radius m/km/ft/mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC/DESC] [STORE key] [STOREDIST key]</td> 
   <td>基于经纬度坐标的范围查询</td> 
   <td>O(N+log(M))</td> 
  </tr> 
  <tr> 
   <td>georadiusbymember key member radius m/km/ft/mi [WITHCOORD] [WITHDIST] [WITHHASH] [ASC/DESC] [COUNT count]</td> 
   <td>基于成员位置范围查询</td> 
   <td>O(log(N)+M)</td> 
  </tr> 
  <tr> 
   <td>geohash key member [member …]</td> 
   <td>计算经纬度Hash</td> 
   <td>O(log(N))</td> 
  </tr> 
 </tbody> 
</table>

geo的实现是zset，所以可以用zset的命令去操作
    zrange geo:city 0 -1    //遍历
    zrem geo:city suzhou    //删除
    zunionstore geo:all 2 geo:city geo:user     //并集

# bloom filter #

> 问题  
> 现有50亿个电话号码，现有10万个电话号码，要快速准确判断这些电话码是否已经存在？  
> 1.通过数据库查询：实现快速有点难。  
> 2.数据预放在集合中：50亿\*8字节≈40GB（内存浪费或不够）  
> 3.hyperloglog：准确性难以保证

布隆过滤器：一种数据结构，可以用来判断一个元素是否在一个集合中。布隆过滤器原理是通过多个 hash 函数, 将结果对应的位设为1, 所以它能做到 100%的去重。 虽然会误判, 但是在合理的设计的前提下, 误判率是可以接受的。但布隆过滤器也不是完美无缺的，首先它的查询性能相对较弱, 它是用 hash 函数在位图上不同的点跳跃探测， 很难利用 cpu 缓存。

> 原理：一个很长的二进制向量和若干个哈希函数。
> 
> ![在这里插入图片描述][20210131131919709.png]
> 
>   
> 
> 
> 应用场景
> 
>  *  垃圾邮件过滤
>  *  文字处理软件（例如word）错误单词检测网络爬虫重复url检测。
>  *  Hbase行过滤。
>  *  检查用户名可用性
>  *  欺诈检测和缓解某些类型的网络攻击  
>       
>       
>     
> 
> 本地布隆过滤器  
> 现有库：guava  
> 本地布隆过滤器的问题：  
> （1）容量受限制。  
> （2）多个应用存在多个布隆过滤器，构建同步复杂。  
> ![在这里插入图片描述][20210127074016645.png]  
>   
>   
> 基于Redis布隆过滤器  
> ![在这里插入图片描述][20210127074248317.png]  
>   
>   
> 基于Redis单机实现布隆过滤器存在的问题
> 
> 1.  速度慢：比本地慢，输在网络  
>     解决：单独部署，与应用同机房甚至机架部署。
> 2.  容量受限：Redis最大字符串为512MB、Redis单机容量。  
>     解决：基于Redis Cluster实现。
> 
>   
>   
>   
> 基于Redis分布式布隆过滤器
> 
> 1.  多个布隆过滤器：二次路由。
> 2.  基于pipeline提高效率。

# cuckoo filter #

谷鸟过滤器并不是使用位图实现的, 而是一维数组. 它所存储的是数据的指纹(fingerprint)。布谷鸟过滤器使用两个 hash 算法将新来的元素映射到数组的两个位置. 如果两个位置中有一个位置位空, 那么就可以将元素直接放进去. 但是如果这两个位置都满了, 它就会随机踢走一个, 然后自己霸占了这个位置。正如布谷鸟那样, 把蛋下到其它鸟的窝里. 这也是得名的由来. 但它并不是像布谷鸟那样, 管杀不管埋, 还会为这个被踢走的数据, 找一个新家。

> 布谷鸟过滤器在下面情况比布隆过滤器更好：
> 
> 1.  删除项目
> 2.  更快的查找（因为更好的内存位置）
> 3.  空间效率（当目标错误率低于3％时）
> 4.  更快的插入（当过滤器的填充率低于80％时）
> 
>   
> 
> 
> 布谷鸟过滤器在下面情况比布隆过滤器更糟糕：
> 
> 1.  你的填充率超过80％;在这种情况下，布谷鸟过滤器的插入速度很快就会低于布隆。
> 2.  你有更宽松的目标错误率（大于3％），使布谷鸟过滤器的空间效率降低
> 3.  你需要高度可预测的行为（因为布谷鸟过滤器在插入过程中使用随机源来提供性能改进）

# pipeline #

使用建议  
1.注意每次pipeline携带数据量  
2.pipeline每次只能作用在一个Redis节点上  
3.M（批量）操作与pipeline区别

![在这里插入图片描述][20210130231711743.png]

![在这里插入图片描述][20210130231944198.png]

# 慢查询 #

redis是单线程操作,如果在redis中执行耗时较长的操作,就会阻塞其他请求了，指命令在执行阶段执行时间超过给定时长的慢操作

> 建议  
> 1.slowlog-max-len不要设置过大，默认10ms，通常设置1ms  
> 2.slowlog-log-slower-than不要设置过小，通常设置1000左右。  
> 3.定期持久化慢查询。

# 发布订阅 #

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

![在这里插入图片描述][2021013023292575.png]

# RDB #

redis创建RDB文件，以二进制文件落地硬盘，redis启动时从硬盘里载入RDB这个二进制文件到内存里

<table> 
 <thead> 
  <tr> 
   <th>触发机制</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>save（同步）</td> 
  </tr> 
  <tr> 
   <td>bgsave（异步）</td> 
  </tr> 
  <tr> 
   <td>自动触发</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][20210118235033452.png]  
![在这里插入图片描述][20210119000216832.png]

# AOF #

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，Aof保存的是appendonly.aof文件，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF持久化的三种策略  
![在这里插入图片描述][20210119000601764.png]

![在这里插入图片描述][20210119000635569.png]

![在这里插入图片描述][20210119000720644.png]

![在这里插入图片描述][20210119000754213.png]

<table> 
 <thead> 
  <tr> 
   <th>AOF重写作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>减少硬盘占用量</td> 
  </tr> 
  <tr> 
   <td>加速恢复速度</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th>AOF重写实现两种方式</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>bgrewriteaof</td> 
  </tr> 
  <tr> 
   <td>AOF重写配置</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][20210119001926470.png]  
![在这里插入图片描述][20210119002340910.png]

![在这里插入图片描述][20210119002654972.png]

![在这里插入图片描述][20210120211118793.png]

# 读写分离 #

对于读占比较高的场景，可以通过把一部分流量分摊导出从节点(salve) 来减轻主节点（master）压力，同时需要主要只对主节点执行写操作  
![在这里插入图片描述][20210120213805577.png]  
![在这里插入图片描述][20210120221208718.png]

# 规避复制风暴 #

复制风暴是指大量从节点对同一主节点或者同一台机器的多个主节点，在短时间内发起全量复制的过程。此时将导致被发起的主节点或机器产生大量开销，如 ：CPU、内存、硬盘、带宽等。我们可以通过分析这样的复制场景，然后采用合理的方式进行规避。

![在这里插入图片描述][20210120214324892.png]

# Sentinel #

sentinel是redis高可用的解决方案，可以在一个架构中运行多个 Sentinel 进程（progress）以监视一个或者多个redis master服务，以及这些master服务的所有从服务；这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

![在这里插入图片描述][20210131113827617.png]

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

*  监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
 *  提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
 *  自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

![在这里插入图片描述][2021012021560212.png]

![在这里插入图片描述][20210120220350812.png]

![在这里插入图片描述][20210120220716266.png]

![在这里插入图片描述][20210120220845679.png]

# Cluster #

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

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

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

![在这里插入图片描述][20210131120437518.png]

集群的容错功能是通过使用主节点（master）和从节点（slave）两种角色（role）的节点（node）来实现的：

1.  主节点和从节点使用完全相同的服务器实现， 它们的功能（functionally）也完全一样， 但从节点通常仅用于替换失效的主节点。
2.  不过， 如果不需要保证“先写入，后读取”操作的一致性（read-after-write consistency）， 那么可以使用从节点来执行只读查询。

> 集群总结
> 
>  *  Redis cluster数据分区规则采用虚拟槽方式（16384个槽），每个节点负责一部分槽和相关数据，实现数据和请求的负载均衡。
>  *  搭建集群划分四个步骤：准备节点、节点握手、分配槽、复制。  
>     redis-trib.rb工具用于快速搭建集群。
>  *  集群伸缩通过在节点之间移动槽和相关数据实现。  
>           1. 扩容时根据槽迁移计划把槽从源节点迁移到新节点。  
>           2. 收缩时如果下线的节点有负责的槽需要迁移到其它节点，再通过cluster forget命令让集群内所有节点忘记被下线节点。
>  *  使用smart客户端操作集群达到通信效率最大化，客户端内部负责计算维护键->槽->节点的映射，用于快速定位到目标节点。
>  *  集群自动故障转移过程分为故障发现和节点恢复。节点下线分为主观下线和客观下线，当超过半数主节点认为故障节点为主观下线时标记它为客观下线状态。从节点负责对客观下线的主节点触发故障恢复流程，保证集群的可用性。
>  *  开发运维常见问题包括：超大规模集群带宽消耗，pub/sub广播问题，集群倾斜问题，单机和集群对比等
> 
>   
>   
> 
> 
> 分布式Redis不一定好
> 
> 1.Redis Cluster：满足容量和性能的扩展性，很多业务”不需要”。
> 
>  *  大多数时客户端性能会”降低”。
>  *  命令无法跨节点使用：mget、keys、scan、flush、sinter等。
>  *  Lua和事务无法跨节点使用。
>  *  客户端维护更复杂：SDK和应用本身消耗（例如更多的连接池）。
> 
> 2.很多场景Redis Sentinel已经足够好。

# 四种批量操作优化的方法 #

1.  串行mget  
    ![在这里插入图片描述][20210123105033505.png]
2.  串行IO  
    ![在这里插入图片描述][20210123105208150.png]
3.  并行IO  
    ![在这里插入图片描述][20210123105337450.png]
4.  hash\_tag

![在这里插入图片描述][20210123105456233.png]

![在这里插入图片描述][20210123105542454.png]

# Redis开发规范 #

*  Key名设计

> 三大建议
> 
> 1.  可读性和可管理性  
>     以业务名（或数据库名）为前缀（防止key冲突），用冒号分割，比如业务名:表名:id，如`ugc:video:1`
> 2.  简洁性  
>     保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视（redis3:39字节embstr），如`user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}`  
>     ![在这里插入图片描述][20210127205819680.png]
> 3.  不要包含特殊字符  
>     反例：包含空格、换行、单双引号以及其他转义字符

*  Value设计

> 1.  拒绝bigkey  
>     ◆ string类型控制在10KB以内  
>     ◆ hash、list、set、zset元素个数不要超过5000
> 
> `bigkey的危害： ①网络阻塞、 ②Redis阻塞、 ③集群节点数据不均衡、 ④频繁序列化引起应用服务器CPU消耗`
> 
> 1.  选择合适的数据结构  
>     数据结构内存优化：例如ziplist，注意内存和性能的平衡
> 2.  过期设计  
>     ◆ 周期数据需要设置过期时间，object idle time可以找垃圾key-value  
>     ◆ 过期时间不宜集中：缓存穿透和雪崩等问题

*  命令使用技巧

> 1.  【推荐】O(N)以上命令关注N的数量例如：hgetall、Irange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。
> 2.  【推荐】禁用命令  
>     禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。
> 3.  【推荐】合理使用select  
>     ◆redis的多数据库较弱，使用数字进行区分  
>     ◆很多客户端支持较差  
>     ◆同时多业务用多数据库实际还是单线程处理，会有干扰
> 4.  【推荐】Redis事务功能较弱，不建议过多使用  
>     ◆Redis的事务功能较弱（不支持回滚）  
>     ◆而且集群版本（自研和官方）要求一次事务操作的key必须在一个slot上（可以使用hashtag功能解决）
> 5.  【推荐】Redis集群版本在使用Lua上有特殊要求  
>     ◆所有key，必须在1个slot上，否则直接返回error
> 6.  【建议】必要情况下使用monitor命令时，要注意不要长时间使用  
>     ![在这里插入图片描述][20210127214114803.png]

*  客户端优化

> 1.  【推荐】  
>     ◆避免多个应用使用一个Redis实例  
>     ◆正例：不相干的业务拆分，公共数据做服务化。
> 2.  【推荐】  
>     使用连接池

# redis内存管理 #

> 内存使用统计
> 
> ![在这里插入图片描述][20210127215122198.png]

redis使用的内存分为两大块：

1.  used\_memory: 又分为自身内存、对象内存、缓冲内存、lua内存

*  自身内存：很低，几百k，可以忽略
 *  对象内存：就是我们存储的string、hash、set、list等内容
 *  缓冲内存：包括复制缓冲区、aof缓冲区、客户端缓冲区等等
 *  lua内存：略

![在这里插入图片描述][20210127215311937.png]

1.  内存碎片：内存碎片率 + used\_memory（redis实际使用的内存量） = used\_memory\_rss(总的内存消耗量)

![在这里插入图片描述][20210127215219865.png]

> 缓冲区内存
> 
> 1.  输入缓冲区  
>     客户端发送命令给redis，redis在执行这些命令前，这些命令会被临时存放到一个输入缓冲区，也就是之前说的命令队列（由于redis是单线程的所以命令要放在队列中排队顺序执行）。  
>     命令存在于输入缓冲区的时间很短，因为redis处理命令很快，所以输入缓冲区占用的内存基本看到都是0  
>     但是如果redis很忙，或者key是一个bigkey，那么输入缓冲区就会较长时间的被占用。  
>     输入缓冲区不能占用超过1G（无法配置修改），否则就会断开和客户端的连接。![在这里插入图片描述][2021012721560799.png]  
>       
>       
>     
> 2.  客户端缓冲区  
>     分为①普通客户端（redis-cli,php或者python执行命令时的客户端等）、②slave客户端（从节点同步主节点时需要一个slave客户端接收主节点同步过来的命令）、③pubsub客户端（发布订阅时会生成客户端）  
>     这三个是输出缓冲区（redis服务返回命令所经过的缓冲区）  
>     如果客户端请求的是bigkey，那么普通客户端缓冲区就很容易占用大量内存。![在这里插入图片描述][20210127222032997.png]
> 
>   
>   
> 
> 
> 1.  复制缓冲区  
>     用于主从节点的部分复制而生的，master节点会将写命令写入到复制缓冲区，然后再从复制缓冲区发送给从节点以进行数据同步。为了防止网络抖动造成不必要的全量复制可以将这个缓冲区调大点。这个缓冲区大小默认是1Mb，可以调大到100M的样子。![在这里插入图片描述][20210127215726923.png]
> 
>   
>   
> 
> 
> 1.  AOF缓冲区  
>     分为aof缓冲区（用于aof日志的生成）和aof重写缓冲区（用于aof重写），这两个缓冲区是没有容量限制的。  
>     ![在这里插入图片描述][20210127215802109.png]
> 
>   
>   
> 
> 
> 1.  子进程内存消耗  
>     必然存在：fork（bgsave和bgrewriteaof）  
>     优化方式：  
>     ◆ 去掉THP特性：2.6.38增加的特性。  
>     ◆ 观察写入量：copy-on-write  
>     ◆ overcommit\_memory=1
> 
>   
>   
> 
> 
> 内存碎片  
>     优化方式：  
>     ◆ 避免频繁更新操作：append、setrange等  
>     ◆ 安全重启，例如redis sentinel和redis cluster等。
> 
>   
>   
> 
> 
> 对象内存
> 
> 1.  key：不要过长，量大不容忽视（redis3：embstr39字节）
> 2.  value:ziplist、intset等优化方式。

设置内存上限

Redis使用 maxmemory 参数限制最大可用内存，默认值为0，表示无限制。限制内存的目的主要 有：

1.  用于缓存场景，当超出内存上限 maxmemory 时使用 LRU 等删除策略释放空间。
2.  防止所用内存超过服务器物理内存。因为 Redis 默认情况下是会尽可能多使用服务器的内存，可能会出现服务器内存不足，导致 Redis 进程被杀死  
    ![在这里插入图片描述][20210127220531146.png]

maxmemory 限制的是Redis实际使用的内存量，也就是 used\_memory统计项对应的内存。由于内存碎片率的存在，实际消耗的内存 可能会比maxmemory设置的更大，实际使用时要小心这部分内存溢出。

Redis默认无限使用服务器内存，为防止极端情况下导致系统内存耗 尽，建议所有的Redis进程都要配置maxmemory。 在保证物理内存可用的情况下，系统中所有Redis实例可以调整 maxmemory参数来达到自由伸缩内存的目的。

内存回收策略

Redis 回收内存大致有两个机制：一是删除到达过期时间的键值对象；二是当内存达到 maxmemory 时触发内存移除控制策略，强制删除选择出来的键值对象。

1.  删除过期键值  
    ◆ 惰性删除  
    ◆ 定时删除  
    ![在这里插入图片描述][20210127221006733.png]
2.  内存溢出控制策略

超过maxmemory后触发相应策略，由maxmemory-policy控制。  
◆ Noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回端错误信息"（error）OOM command not allowed when used memory"此时Redis只响应读操作由maxmemory-policy控制。  
◆ Volatile-Iru：根据LRU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。  
◆ Allkeys-Iru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。  
◆ Alkeys-random：随机删除所有键，直到腾出足够空间为止。  
◆ volatile-random：随机删除过期键，直到腾出足够空间为止。  
◆ volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。

# 巨人的肩膀 #

> 从他人的工作中汲取经验来避免自己的错误重复，正如我们是站在巨人的肩膀上才能做出更好的成绩。

[https://coding.imooc.com/class/chapter/151.html\#Anchor][https_coding.imooc.com_class_chapter_151.html_Anchor]  
[https://www.kancloud.cn/lizhenjie1992/rediss/571576][https_www.kancloud.cn_lizhenjie1992_rediss_571576]  
[https://www.cnblogs.com/williamjie/p/9505075.html][https_www.cnblogs.com_williamjie_p_9505075.html]  
[http://redisdoc.com/][http_redisdoc.com]  
[https://www.cnblogs.com/hsdy][https_www.cnblogs.com_hsdy]  
[https://blog.csdn.net/u011277123/article/details/88757861][https_blog.csdn.net_u011277123_article_details_88757861]  
[https://www.cnblogs.com/Courage129/category/1890815.html][https_www.cnblogs.com_Courage129_category_1890815.html]  
[https://www.cnblogs.com/hunternet/p/11248192.html][https_www.cnblogs.com_hunternet_p_11248192.html]  
[https://wiki.jikexueyuan.com/project/redis/][https_wiki.jikexueyuan.com_project_redis]  
[http://xiaorui.cc/archives/6026][http_xiaorui.cc_archives_6026]  
[https://blog.csdn.net/yahuuqq1314/article/details/100566688][https_blog.csdn.net_yahuuqq1314_article_details_100566688]

# VChat #

一个没有哆啦A梦和静香的IT码农，不专业Gopher  
![在这里插入图片描述][20201206221123294.png]

[20210114223436368.png]: /images/20221119/739ae56be4d6485ebaeb4361d5f75204.png
[20210118205814150.png]: /images/20221119/8a354e3d06914563a4dbc9d12f988856.png
[20210130214644815.png]: /images/20221119/b08b3931f4854317b5790046e59a110c.png
[20210127211618983.png]: /images/20221119/ff18f43eca3944f7b39d348aaa4be33e.png
[20210118220600644.png]: /images/20221119/01272cfad472467bbb8663103045db92.png
[20210118222058671.png]: /images/20221119/2c06bdc48358427e81b9f985d27486a6.png
[20210130234745280.png]: /images/20221119/6a3cfd5ffc7f425e8d94c3ae3b5929d8.png
[20210131134855299.png]: /images/20221119/a09d7e993ec145508af117a104b40c1a.png
[20210131142349159.png]: /images/20221119/002910bdfdd44138b8ef4ab56ce3a3bb.png
[20210127212343611.png]: /images/20221119/a0258fa50091458b874013d4bfe8c863.png
[20210130235934607.png]: /images/20221119/cb2d2764b06a48c388532cf9597163ac.png
[20210131002942496.png]: /images/20221119/07bfddd9dcb44182a4b22cbfa5952f6e.png
[20210131131919709.png]: /images/20221119/a3aa21d4860243b98044d5197a012641.png
[20210127074016645.png]: /images/20221119/92066c8c568e43cdbea5020878c6dbfb.png
[20210127074248317.png]: /images/20221119/861d98d6da4a4dfa92f2138f43fadd1a.png
[20210130231711743.png]: /images/20221119/e2b7ca9c75f14a92af289344f9361ff9.png
[20210130231944198.png]: /images/20221119/03f6d64239df410fb8156ad9ce918684.png
[2021013023292575.png]: /images/20221119/36967f95204d4c6f82ff428de2127c36.png
[20210118235033452.png]: /images/20221119/3fe0dd16e8964f928767f6f4e77a5967.png
[20210119000216832.png]: /images/20221119/65f86915b3af4c97b335237a7c95c775.png
[20210119000601764.png]: /images/20221119/e371ccf44b784f45ba9226c471f0facf.png
[20210119000635569.png]: https://img-blog.csdnimg.cn/20210119000635569.png
[20210119000720644.png]: https://img-blog.csdnimg.cn/20210119000720644.png
[20210119000754213.png]: https://img-blog.csdnimg.cn/20210119000754213.png
[20210119001926470.png]: https://img-blog.csdnimg.cn/20210119001926470.png
[20210119002340910.png]: https://img-blog.csdnimg.cn/20210119002340910.png
[20210119002654972.png]: https://img-blog.csdnimg.cn/20210119002654972.png
[20210120211118793.png]: https://img-blog.csdnimg.cn/20210120211118793.png
[20210120213805577.png]: https://img-blog.csdnimg.cn/20210120213805577.png
[20210120221208718.png]: https://img-blog.csdnimg.cn/20210120221208718.png
[20210120214324892.png]: https://img-blog.csdnimg.cn/20210120214324892.png
[20210131113827617.png]: https://img-blog.csdnimg.cn/20210131113827617.png
[2021012021560212.png]: https://img-blog.csdnimg.cn/2021012021560212.png
[20210120220350812.png]: https://img-blog.csdnimg.cn/20210120220350812.png
[20210120220716266.png]: https://img-blog.csdnimg.cn/20210120220716266.png
[20210120220845679.png]: https://img-blog.csdnimg.cn/20210120220845679.png
[20210131120437518.png]: https://img-blog.csdnimg.cn/20210131120437518.png
[20210123105033505.png]: https://img-blog.csdnimg.cn/20210123105033505.png
[20210123105208150.png]: https://img-blog.csdnimg.cn/20210123105208150.png
[20210123105337450.png]: https://img-blog.csdnimg.cn/20210123105337450.png
[20210123105456233.png]: https://img-blog.csdnimg.cn/20210123105456233.png
[20210123105542454.png]: https://img-blog.csdnimg.cn/20210123105542454.png
[20210127205819680.png]: https://img-blog.csdnimg.cn/20210127205819680.png
[20210127214114803.png]: https://img-blog.csdnimg.cn/20210127214114803.png
[20210127215122198.png]: https://img-blog.csdnimg.cn/20210127215122198.png
[20210127215311937.png]: https://img-blog.csdnimg.cn/20210127215311937.png
[20210127215219865.png]: https://img-blog.csdnimg.cn/20210127215219865.png
[2021012721560799.png]: https://img-blog.csdnimg.cn/2021012721560799.png
[20210127222032997.png]: https://img-blog.csdnimg.cn/20210127222032997.png
[20210127215726923.png]: https://img-blog.csdnimg.cn/20210127215726923.png
[20210127215802109.png]: https://img-blog.csdnimg.cn/20210127215802109.png
[20210127220531146.png]: https://img-blog.csdnimg.cn/20210127220531146.png
[20210127221006733.png]: https://img-blog.csdnimg.cn/20210127221006733.png
[https_coding.imooc.com_class_chapter_151.html_Anchor]: https://coding.imooc.com/class/chapter/151.html#Anchor
[https_www.kancloud.cn_lizhenjie1992_rediss_571576]: https://www.kancloud.cn/lizhenjie1992/rediss/571576
[https_www.cnblogs.com_williamjie_p_9505075.html]: https://www.cnblogs.com/williamjie/p/9505075.html
[http_redisdoc.com]: http://redisdoc.com/
[https_www.cnblogs.com_hsdy]: https://www.cnblogs.com/hsdy
[https_blog.csdn.net_u011277123_article_details_88757861]: https://blog.csdn.net/u011277123/article/details/88757861
[https_www.cnblogs.com_Courage129_category_1890815.html]: https://www.cnblogs.com/Courage129/category/1890815.html
[https_www.cnblogs.com_hunternet_p_11248192.html]: https://www.cnblogs.com/hunternet/p/11248192.html
[https_wiki.jikexueyuan.com_project_redis]: https://wiki.jikexueyuan.com/project/redis/
[http_xiaorui.cc_archives_6026]: http://xiaorui.cc/archives/6026
[https_blog.csdn.net_yahuuqq1314_article_details_100566688]: https://blog.csdn.net/yahuuqq1314/article/details/100566688
[20201206221123294.png]: https://img-blog.csdnimg.cn/20201206221123294.png