庐山真面目之十三微服务架构中如何在Docker上使用Redis缓存

Linux52

一、介绍

1、开始说明
在微服务器架构中,有一个组件是不能少的,那就是缓存组件。其实来说,缓存组件,这个叫法不是完全正确,因为除了缓存功能,它还能完成其他很多功能。我就不隐瞒了,今天我们要探讨的就是Redis,作为RDBMS的一个有效的补充。现在的互联网和以前的互联网已经发生了翻天覆地的变化,这些变化的突出特征就是"三高"。当然,这"三高"不是我们人类身体的三高,而是最新系统的三种特性,它们分别适合:高并发,高性能和高可用。这三种特征是现在系统必须满足的要求。为了满足这三个要求,其实会有很多技术来支持,但是里面有一个功能是必不可少的,那就是具有缓存功能和分布特性的Redis,它可以为这三个特性增光添彩,今天我们就来看看它的真面目,让我们对它有一个更全面、更直接的认识,深度我不敢说,因为自己也是在学习的过程中,如果以后有了新的体验,再和大家分享吧。

2、基础环境

2.1、操作系统:CentOs7(64bit)

2.2、虚拟容器:Docker 19.03.13

2.3、客 户 端:SSH Secure Shell Client或者XShell

2.4、虚拟系统:VMware Workstation Pro 14.1.3

2.5、Redis版本:6.2.1(最新版本)

3、docker 环境安装

3.1、直接执行命令,安装 Docker 就好。

命令:#yum install docker

3.2、升级 docker 为最新的版本。

如果大家不熟悉,可以查看我写的文章《如何将Docker升级到最新版本 》【https://www.cnblogs.com/PatrickLiu/default.html?page=3】

3.3、设置 Docker 镜像地址,防止拉取镜像太慢。

3.3.1、编辑或者增加 daemon.json 文件。

命令:#vim /etc/docker/daemon.json

3.3.2、增加镜像地址

{"registry-mirrors": ["https://5f2jam6c.mirror.aliyuncs.com", "http://hub-mirror.c.163.com"]}

3.3.3、重新加载配置文件。

命令:#systemctl daemon-reload

3.3.4、启动 docker 服务。

命令:#systemctl enable docker

3.3.5、查看docker 的启动状态。

命令:#systemctl status docker

二、Redis 基础

1、Redis 入门

1.1、Redis 介绍

1.1.1、NoSQL

NoSQL:即Not-Only SQL(泛指非关系型数据库),作为关系型数据库的补充。

特征:
可扩容、可伸缩。
大数据量下高性能
灵活的数据类型
高可用。

1.1.2、NoSQL分类

1.1.2.1、键值(Key-Value)存储数据库

该类数据库主要会使用到一个哈希表,这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。如:Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB。

1.1.2.2、列存储数据库

该类数据库通常是用来应对分布式存储的海量数据。键仍然存在,但是它们的特点是指向了多个列。这些列是由列家族来安排的。如:Cassandra, HBase, Riak.

1.1.2.3、文档型数据库

该类型的数据模型是版本化的文档,半结构化的文档以特定的格式存储,比如JSON。文档型数据库可以看作是键值数据库的升级版,允许之间嵌套键值,在处理网页等复杂数据时,文档型数据库比传统键值数据库的查询效率更高。如:CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB,已经开源。

1.1.2.4、图形(Graph)数据库

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同,它是使用灵活的图形模型,并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL),因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如:Neo4J, InfoGrid, Infinite Graph。

1.1.3、应用场景(解决方案-电商场景)

1.1.3.1、基本信息(名称,价格,厂商。。)---MySQL

1.1.3.2、商品附加信息(描述、详情、评论。。。)---MongoDB

1.1.3.3、图片信息---分布式文件系统

1.1.3.4、搜索信息---ES,Lucene,solr

1.1.3.5、热点信息---(以上4中都可以成为热点信息)---Redis、memcache、tair

1.1.4、Redis 简介

1.1.4.1、概念:Redis(REmote Dictionary Server)是用C语言开发的一个开源的高性能的键值对(Key-Value)数据库。

1.1.4.2、特征

1、数据间没有必然的联系。

2、内部采用单线程机制进行工作。

3、高性能。50个并发执行100000个请求,读的速度是:110000次/s,写的速度是81000次/s。

4、多数据类型支持。

5、支持持久化,可以进行数据的灾难恢复。

1.1.4.3、Redis 应用

1、为热点数据加速查询(主要场景),如热点商品、热点新闻、热点资讯、推广类的等高访问量信息等。

2、任务队列,如秒杀,抢购,购票排队等。

3、即时信息查询,如各类排行榜,各类网站访问统计,公交到站信息,在线人数信息(聊天室,网站)、设备信号等。

4、时效性信息控制,如验证码控制,投票控制。

5、分布式数据共享,如分布式集群架构中的 Session 分离。

6、消息队列。

7、分布式锁。

1.1.4.4、Redis 命令行模式使用思考。

1、功能型命令。

set name patrickliu
get name

2、清楚屏幕命令。

clear

3、帮助信息命令。

help 命令
help @组名(tab)

4、退出命令。
exit
quit

1.2、在 Docker 环境中安装 Redis。

1.2.1、获取Redis的镜像。(我已经拉取了Redis的镜像)

1.2.2、查看本地的镜像。
命令:#docker images

1.2.3、创建本地的 Redis.conf 配置文件。

1.2.4、修改配合文件的内容。

1.2.5、创建并启动 Redis 容器。

1.2.6、查看 Redis 容器
命令:#docker container ls -a

命令:docker ps查看运行的容器

1.2.7、通过 redis-cli 连接测试使用 redis 服务
命令:docker exec -it redis(redis容器实例名称或者ID) /bin/bash 进入docker终端,在终端中输入:redis-cli

1.2.8、安装过程中,如果发现容器启动失败,使用docker logs查看容器日志。
本例中docker容器名为redis,查看日志命令为:docker logs -f -t --tail 100 redis

1.2.9、系统启动,Docker 容器自动启动,Redis 容器自动启动。

2、数据类型

2.1、数据存储类型介绍
作为缓存的组件有两个,我个人接触的比较多的就是Memcache和Redis,其实Memcache出来的要更久一些,但是到现在,使用的已经很少了,除非是以前就在使用这个技术。就算以前以前在使用Memcache,现在很多公司也选择了Redis了,那是为什么呢?有一个很重要的原因就是Redis拥有丰富的数据类型,接下来,我们就简单认识一下它和5中核心类型,当然也包含另外3中扩展类型。我们继续吧。

2.2、string

基本操作:有关 string 存储类型的基本操作。

2.2.1、set key value

2.2.2、get key

2.2.3、del key

2.2.4、mset key1 value1 key2 value2 ...

2.2.5、mget key1 key2 ...

2.2.6、strlen key

2.2.7、append key value

扩展操作:

Tips 1:Redis 用于控制数据库表主键的 ID 值,为数据库表主键提供生成策略,保证数据库表的主键唯一性。此方案适用于所有数据库,且支持数据库集群。

2.2.8、incr key

2.2.9、incrby key increment

2.2.10、incrbyfloat key increment

2.2.11、decr key

2.2.12、decrby key increment

Tips 2:Redis 控制数据的生命周期,通过数据是否失效控制业务行为,适用于所有具有时效性限定控制的操作。
如:多久投一次票等。

2.2.13、setex key seconds value

2.2.14、psetex key milliseconds value

注意事项:

数据操作不成功的反馈与数据正常操作之间的差异。

1、表示运行结果是否成功。
(integer)0---->false 失败。
(integer)1---->true 成功。

2、表示运行结果值。
(integer)3---->3 个。
(integer)1---->1 个。

3、数据未获取到
(nil)等同于null

4、数据量最大存储量
512MB

5、数值结算最大范围(java 中long 的最大值)
9223372036854775807

string 类型的应用场景:

1、在 Redis 中为大V用户设定用户信息,以用户主键和属性值作为 key,后台设定定时刷新策略即可。
eg: user(表名):ID(主键):605904930(主键值):fans(栏位) ------ 3292349。
eg: user(表名):ID(主键):605904930(主键值):blogs(栏位) ------ 654。
eg: user(表名):ID(主键):605904930(主键值):focuss(栏位) ------ 46。

2、在 Redis 中以json 格式存储大 V 的用户信息,定时刷新(可以使用 hash 类型)
eg: user:id:594030334---->{id:594030334,name:liulei,fans:44454,blogs:435,focuss:83}

3、Redis 应用于各种结构性和非结构性高人读数据访问加速。

4、在 Redis 中 key 的设置约定。
表名:主键名:主键值:字段名
user: id : 22132 : name
order: id : 59454 : titles

2.3、hash

2.3.1、string 类型的存储的问题,存储为json格式,方便取,但是如果要想修改其中的某个字段,就很难了,这个时候,如果我们使用 Redis 里面的 hash 类型,存和改都很方便了。

hash 类型:适合存储对象类型的信息。

hash 类型,底层使用的就是哈希表结构实现的数据存储。

hash 存储结构的优化:

如果 field 数量较少,存储结构优化为类数组结构。

如果 field 数量较多,存储结构使用 hashMap 结构。

基本操作

2.3.2、hset key field value

2.3.3、hget key field

2.3.4、hgetall key

2.3.5、hdel key field [field..]

2.3.6、hmset key field value [field value ...]

2.3.7、hmget key field [field ...]

2.3.8、hlen key

2.3.9、hexists key field

2.3.10、hsetnx key field value

扩展操作:

2.3.11、hkeys key

2.3.12、hvals key

2.3.13、hincrby key field increment

2.3.14、hincrbyfloat key field increment

注意事项:

2.3.15、hash 类型下的 value 只能存储字符串,不允许存储其他数据类型,不存在嵌套现象,如果数据未找到,对应的值为(nil)。

2.3.16、每个 hash 可以存储2^32-1个键值对。

2.3.17、hash 类型十分贴近对象的存储形式,并且可以灵活的添加和删除对象属性,但是 hash 设计初衷不是为了存储大量对象而设计的,切记不可滥用,更不可以将 hash 作为对象列表使用。

2.3.18、hgetall 操作可以获取全部属性,如果内部 field 过多,遍历整体数据效率就会很低,有可能成为数据访问瓶颈。

应用场景:

2.3.19、电商网站购物车设计与实现。

Tips 4: Redis 应用于购物车数据存储设计。

Tips 5:Redis 应用于抢购、限购、限量发放优惠券、激活码等业务的数据存储设计。

string 存对象还是 hash 存对象,如果数据需要变动,修改,这样操作频繁,就是用hash,如果数据不变动,只是用于展示,使用string 存对象,json 格式。

2.4、list

2.4.1、list 类型:

数据存储需求:存储多个数据,并对数据进入存储空间的顺序进行区分。

需要存储结构:一个存储空间保存多个数据,且通过数据可以体现进入顺序。

List 类型:保存多个数据,底层使用双向链表存储结构实现。

基本操作:

2.4.2、lpush key value1,value2...

2.4.3、rpush key value1,value2...

2.4.4、lrange key start stop

2.4.5、lindex key index

2.4.6、llen key

2.4.7、lpop key

2.4.8、rpop key

扩展操作:任务队列实现基础

2.4.9、blpop key1 [key2 ...] timeout b=block

2.4.10、brpop key1 [key2 ...] timeout

2.4.11、lrem key count value(可以中间操作)

Tips 6:Redis 应用于具有操作先后顺序的数据控制。

注意事项:

2.4.12、List中保存的数据都是 string 类型的,数据总容量是有限,最多存储2^32-1个元素。

2.4.13、list 具有索引的概念,但是操作数据时候,通常以队列的形式进行入队出队操作,或者以栈的形式进行入栈出栈操作。

2.4.14、获取全部数据操作实数索引设置-1.

2.4.15、list 可以对数据进行分页操作,通常第一页的信息来至于list,第二页及更多的信息通过数据库的形式加载。

应用场景:

2.4.16、业务场景:twitter,新浪微博,腾讯微博中个人用户的关注列表需要按用户的关注顺序进行展示,粉丝列表需要将最近关注的粉丝列在前面。

Tips 7:Redis 应用于最新消息展示

2.5、set

2.5.1、Set 类型:

新的存储需求:存储大量的数据,在查询方面提供更高的效率。
需要的存储结构:能够保存大量的数据,高校的内部存储机制,便于查询。
Set 类型:与 hash 存储结构完全相同,仅存储键,不存储值(nil),并且值是不允许重复的。

基本操作:

2.5.2、sadd key member1 [member2 ...]

2.5.3、smembers key

2.5.4、srem key member1 [member2 ...]

2.5.6、scard key

2.5.7、sismember key member

扩展操作:

2.5.8、srandmember key [count]

2.5.9、spop key [count]

Tip 8:Redis应用于随机推荐类信息检索,例如:热点歌单推荐,热点新闻推荐,热卖旅游线路,应用App 推荐,大V推荐等。

2.5.10、求两个集合的交集、并集和差集。

2.5.10.1、sinter key1 [key2]

2.5.10.2、sunion key1 [key2]

2.5.10.3、sdiff key1 [key2]

2.5.11、求两个集合的交集、并集和差集并保存。

2.5.11.1、sinterstore destination key1 [key2]

2.5.11.2、sunionstore destination key1 [key2]

2.5.11.3、sdiffstore destination key1 [key2]

2.5.12、将指定数据从原实际和中移动到目标集合中。

Tips 9:Redis应用于同类信息的关联搜索,二度关联搜索,深度关联搜索。

显示共同关注(一度)
显示共同好友(一度)

由用户A出发,获取到好友用户B的好友信息列表(一度)
由用户A出发,获取到好友用户B的购物信息列表(二度)
由用户A出发,获取到好友用户B的游戏充值列表(二度)

注意事项

1、Set 类型不允许数据重复,如果天剑的数据在 Set 中应存在,将只保留一份。
2、Set 虽然与Hash 的存储结构相同,但是无法启用 Hash 中的存储值的空间。

应用场景

1、Redis可以应用于同类型不重复数据的合并操作。在权限设计过程中,权限会有重复的情况,可以使用Set去掉重复权限。
2、 【Tips 11】Redis 应用于同类型数据的快速去重。网站数据统计,PV:网站访问量,刷新也算(string的计算器);UV:独立用户访问量(建立Set模型,记录不同Cookie数量);IP:独立IP访问量(建立Set模型,记录不同IP数量)
3、 【Ti ps 12】基于Redis可以制作黑名单和白名单功能。黑名单:过滤掉不想让他们进来的;白名单:只保留能访问的。

2.6、sorted_set

2.6.1、Sorted_Set 类型。

1、新的存储需求:数据排序有利于数据的有效展示,需要提供一种可以根据自身特征进行排序的方式。
2、需要的存储结构:新的存储模型,可以保存大量数据,又可以对数据进行排序。
3、Sorted_Set 类型:基于 Set 类型存储结构基础上增加了排序字段。

基本操作

2.6.2、zadd key score1 member1 [score2 member2]

2.6.3、zrange key start stop [WITHSCORES]

2.6.4、zrevrange key start stop [WITHSCORES]

2.6.5、zrem key member [member ...]

2.6.6、zrangebyscore key min max [WITHSCROES] [LIMIT]

2.6.7、zrevrangebyscroe key max min [WITHSCORES]

2.6.8、zremrangebyrank key start stop

2.6.9、zremrangebyscore key min max

2.6.10、注意:
。min与max用于限定搜索查询的条件。
。start与stop用于限定查询范围,作用于索引,表示开始和结束索引。
。offset与count用于限定查询范围,作用于查询结果,表示开始位置和数据总量。

2.6.11、zcard key

2.6.12、zcount key min max

2.6.13、zinterstore destination numkeys key [key ...]

2.6.14、zunionstore destination numkeys key [key ...]

扩展操作(适合榜单排行)

2.6.15、zrank key member

2.6.16、zrevrank key member

2.6.17、zscore key member

2.6.18、zincrby key increment member.

Tips 13:Redis应用于计数器组合排序对应的排名。

注意事项:
1、score保存的数据存储空间是64位,如果是整数,范围是:-9007199254740992~9007199254740992
2、score保存的数据也可以是一个双精度的double 值,基于双精度浮点数的特征,可能会丢失精度,使用时要谨慎。
3、sorted_set 底层存储还是基于 set 结构的,因此数据不能重复,如果重复添加相同的数据,score 值将被反复覆盖,保留最后一次修改的结果。

应用场景:
1、Tips 14 Redis应用于定时任务执行顺序管理或者任务过期管理。基础服务+增值服务,观影vip,游戏体验vip。
2、关于带有权重的任务/消息队列。当任务或者消息待处理,形成了任务队列或者消息队列时,对于高优先级的任务要保证对其优先处理,如何实现任务权重管理。对于带有权重的任务,优先处理权重高的任务,采用 score 记录权重即可。
3、Tips 15:Redis 应用于即时任务/消息队列执行管理

2.7、数据类型实践案例

2.7.1、Tips 16:Redis 应用于显示按次结算的服务控制。

1、应用场景:人工智能领域的语义识别和自动对话僵尸未来服务业机器人应答呼叫体系中重要的技术,百度自己研制的用户评价语义识别服务,免费开放给企业试用,同时训练百度自己的模型,现对试用用户的使用行为进行限速,限制每个用户每分钟最多发起的10次调用。

2、解决方案:控制用户的访问次数场景:可以使用计数器,时间限制可以为数据增加过期时间,到期就清空,就可以实现。

setex key second value,然后递增,incr key,每次检查次数。

为了避免每次检查次数,我们可以设置int最大值,使用次数n,用int.maxvalue-n 为初始值,每次增加,到最大值会抛出异常,通过异常来处理,不用每次判断次数。

2.7.2、Tips 17:Redis 应用于基于时间顺序的数据操作,而不关注具体时间。

1、应用场景:使用微信的过程中,当微信接收消息后,会默认将最近的接受消息置顶,当多个好友及其关注的订阅号同时发送消息时,该排序会不停的进行交替,同时还可以将重要的会话设置为置顶,一旦用户离线后,再次打开微信,消息该按什么顺秀显示?

2、解决方案:使用 list 数据结构,具有顺序,消息最后发送的,时间最近,所以最新显示,该特性是栈特性。

3、通用命令

3.1、key 的基本操作

3.1.1、del key

3.1.2、exists key

3.1.3、type key

3.2、key的扩展操作(时效性控制)

3.2.1、expire key seconds

3.2.2、pexpire key milliseconds

3.2.3、ttl key

3.2.4、pttl key

3.2.5、persist key

3.3、key 的扩展操作(查询模式,keys * ? []pattern)

3.3.1、keys *

3.3.2、keys ?

3.3.3、keys []

3.4、key 的其他操作

3.4.1、rename key newkey

3.4.2、renamenx key newkey

3.4.3、sort

3.4.4、help @generic

3.5、db 的基本操作

3.5.1、select index

3.5.2、quit

3.5.3、ping

3.5.4、echo

3.6、db 的相关操作

3.6.1、move key db

3.6.2、dbsize

3.6.3、flushdb

3.6.4、flushall

三、Redis高级

1、Redis安装

1.1、默认启动

1.1.1、服务器端:进入redis安装目录,直接执行 redis-server,端口默认:6379

1.1.2、客户端:进入redis安装目录,直接执行 redis-cli,端口默认:6379

1.2、带参数启动

1.2.1、服务器端:进入redis安装目录,直接执行 redis-server --port 6379 --host ip

1.2.2、客户端:进入redis安装目录,直接执行 redis-cli -p 6379 -h ip

1.3、配置文件

1.3.1、服务器端:进入redis安装目录,直接执行 redis-server redis.conf,如果想要启动多个redis实例,可以复制多个redis.conf配置文件,指定配置文件启动

命令:#redis-server redis.conf

命令:#redis-server redis6380.conf

命令:#redis-server redis6381.conf

1.3.2、客户端:进入redis安装目录,直接执行 redis-cli -p port -h ip,如果有多少个实例,启动客户端要链接指定端口和地址的redis实例。

命令:#redis-cli -p 6379

命令:#redis-cli -p 6380

命令:#redis-cli -p 6381

1.3.3、查看redis配置文件,过滤备注和空格

1.3.3.1、查看redis.conf文件,过滤"#"和"空格"。

命令:#cat redis.conf |grep -v "#" |grep -v "^$"

1.3.3.2、查看redis.conf文件,过滤"#""空格",生成新的文件。

命令:#cat redis.conf |grep -v "#" |grep -v "^$" > redis-default.conf

1.4、查看实例

2、持久化

2.1、持久化简介

2.1.1、利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制。

2.1.2、防止数据丢失,确保数据的安全性。

2.1.3、持久化方式:数据快照(RDB),操作日志(AOF)

2.2、持久化(RDB)

2.2.1、RDB启动方式--save命令,手动执行一次就保存一次数据。

2.2.2、dbfilename dump.rdb

说明:设置本地数据库文件名,默认值:dump.rdb

经验:通常设置为 dump-端口号.rdb

2.2.3、dir

说明:设置存储 rdb 文件的路径,不包含文件名。

经验:通常设置成存储空间较大的目录中,目录名:data

2.2.4、 rdbcompression yes

说明:设置存储至本地数据库时是否压缩数据,默认值:yes,采用lzf压缩。

经验:通常默认为开启状态,如果设置为no,可以节省 cpu 运行时间,但会使存储的文件变大。

2.2.5、 rdbchecksum yes

说明:设置是否进行RDB文件格式的校验,该校验过程在写文件和读文件均进行。

经验:通常默认开启状态,若果设置为 no,可以节约读写过程中约10%的时间消耗,但是存储一定数据损坏的风险。

2.2.6、bgsave,不是立刻执行,后台运行。

2.2.7、stop-writes-on-bgsave-error yes

说明:后台存储过程中如果出现错误现象,是否停止保存操作。

经验:通常默认开始状态。

2.2.8、自动执行

save second changes:满足限定时间范围内key的变化数量达到指定数量就进行持久化。

second:监控的时间范围。

changes:监控key的变化量。

2.2.9、RDB特殊启动形式

全量复制:在主从复制中执行。

服务器运行过程中重启:debug reload

关闭服务器时指定保存数据:shutdown save

2.2.10、RDB优缺点:

2.2.10.1、优点:

2.2.10.1.1、RDB是一个紧凑压缩的二进制文件,存储效率较高。

2.2.10.1.2、RDB内部存储的是Redis在某个时间点的数据库快照,非常适用于数据备份,全量复制等场景。

2.2.10.1.3、RDB恢复数据的速度比AOF 快很多。

2.2.10.1.4、服务器中每 X 小时执行bgsave 备份,并将RDB文件拷贝到远程服务器中,用于灾难恢复。

2.2.10.2、缺点

2.2.10.2.1、RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据。

2.2.10.2.2、bgsave指令每次运行都要 fork 操作创建子进程,都要牺牲掉一些性能。

2.2.10.2.3、Redis 的众多版本中未进行RDB文件格式的版本统一,有可能出现各个版本服务之间的数据格式无法兼容的现象。

2.3、持久化(AOF)

2.3.1、RDB存储的弊端

2.3.1.1、存储的数据量较大 ,效率比较低。基于快照思想,每次都是全部数据,当数据量巨大时,效率非常低。

2.3.1.2、大数据量下的IO性能较低。

2.3.1.3、基于 fork 创建的子进程,会产生额外的内存消耗。

2.3.1.4、宕机带来的数据丢失风险。

2.3.2、AOF 写数据的过程。

always(每次)每次写入操作均同步到AOF文件中,数据零误差,性能较低,不建议使用。

everysec(每秒)每秒将缓冲区中的指令同步到AOF 文件中,数据准确性较高,性能较高,建议使用。也是默认配置。

no(系统控制)由操作系统控制每次同步到AOF文件的周期,整体过程不可控。

2.3.3、AOF 启动过程。

appendonly yes|no 是否开启AOF持久化功能,默认不开启。

appendfsync always|everysec|no AOF写数据策略。

2.3.4、AOF相关配置

appendfilename filename AOF持久化文件名,默认文件名:appendonly.aof,建议配置:appendonly-端口号.aof

dir AOF持久化文件保存的路径,与RDB持久化文件保持一致即可。

2.3.5、AOF重写

2.3.5.1、定义:随着命令不断的写入AOF文件,文件会越来越大,文件里面可能包含一些无效的命令,或者是重复的命令,为了解决这个问题,Redis引入了AOF重写机制来压缩文件体积。AOF文件重写是将Redis进程内的数据转换为写命令同步到新AOF文件的过程。简单的说就是将对同一个数据的若干条命令执行结果转化成最终结果数据对应的指令进行记录。

2.3.5.2、AOF重写作用

降低磁盘占用量,提高磁盘利用率。

提高持久化效率,降低持久化写时间,提高IO性能。

降低数据恢复用时,提高数据恢复效率。

2.3.5.3、重写规则

进程内已经超时的数据不再写入文件。

忽略无效指令,重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令。del key1,hdel key2,srem key3 set key4 1111,set key 4 222 等。

对同一数据的多条写入命令合并为一条命令。如:lpush list1 a,lpush list1 b,lpush list1 c,lpush list1 d 合并为 lpush list1 a b c d。

2.3.6、AOF重写方式

2.3.6.1、手动重写

bgrewriteaof

2.3.6.2、自动重写

2.3.6.2.1、自动重写触发条件设置

2.3.6.2.2、自动重写触发对比参数

2.3.6.2.3、自动重写触发条件

2.3.7、AOF工作流程

2.3.7.1、always:执行指令Set--->主进程---->fork子进程---->把操作信息写入aof(非重写了)
|

2.3.7.3、everysec+rewrite:执行指令Set--->主进程--->fork启动子进程--->aof缓冲区----->非重写了aof
| | |

Original: https://www.cnblogs.com/PatrickLiu/p/14518160.html
Author: 可均可可
Title: 庐山真面目之十三微服务架构中如何在Docker上使用Redis缓存