当我们发送指令给服务器，服务器接收到指令并没有马上记录，而是将指令放到AOF写命令刷新缓存区，缓冲区满，将直接把命令同步到AOF文件中
至于一次写过去多少条，多久写一次，我们通过配置策略来解决
⭐️1.2.3 AOF写数据三种策略（appendfsync）
=============================================================================================
-
always（每次）
-
每次写入操作均同步到AOF文件中，数据零误差，性能较低
-
everysec（每秒）
-
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
-
在系统突然宕机的情况下丢失1秒内的数据
-
no（系统控制）
-
由操作系统控制每次同步到AOF文件的周期，整体过程不可控
========================================================================
-
配置
-
appendonly yes|no
-
作用
-
是否开启AOF持久化功能，默认为不开启状态
-
配置
-
appendfsync always|everysec|no
-
作用
-
AOF数据策略
-
配置
-
appendfilename filename
-
作用
-
AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
-
配置
-
dir
-
作用
-
AOF持久化文件保存路径，与RBD持久化文件保持一致
========================================================================
配置完成后重启redis服务
可以看到AOF持久化文件已经生成
我们尝试存储一些数据并观察文件的变化
进入持久化文件
我们发现我们每一步有效操作的步骤都被记录在文件中
=================================================================================
我们执行以上指令会发现，set name zs 和 set name ls 在写数据时实际上是不用执行的incr num也可以合并为1条指令，AOF提供这样的功能
===========================================================================
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积，AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。
简单说就是将对同一个数据的若干个命令执行结果转化成最终结果数据对应的指令进行记录
AOF重写的规则
-
进程内
已超时的数据不再写入文件 -
忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令 -
如del key1、hdel key2、srem key3、set key4 111、set key4 222等 -
对同一数据的多条写命令
合并为一条命令 -
如lpush list1 a、lpush list1 b、lpush list1 c可转化为：lpush list1 a b c -
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令对多写入64个元素
===============================================================================
-
手动重写
-
bgrewriteaof
-
自动重写
-
auto-aof-rewrite-min-size size
-
auto-aof-rewrite-percentage percentage
未指定重写之前
AOF将操作都记录了下来
手动重写：
查看aof文件
我们看到只有set name 456在其中，set name 123 set name 235等无效操作没有被记录
=============================================================================
| 持久化方式 | RDB | AOF |
| :-: | :-: | :-: |
| 占用存储空间 | 小（数据级：压缩） | 大（指令级：压缩） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 有可能丢失 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |
================================================================================
====================================================================
一般来说，事务是必须满足4个条件（ACID）：：
原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称
独立性）、持久性（Durability）。
-
**原子性：**一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
-
**一致性：**在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
-
**隔离性：**数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
-
**持久性：**事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
redis事务就是一个命令执行的队列，将一系列预定义命令包装秤一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或干扰
===========================================================================
-
开启事务
-
multi
-
作用
-
设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中
-
执行事务
-
exec
-
作用
-
设定事务的结束位置，同时执行事务。与multi成对出现，成对使用
-
取消事务
-
discard
-
作用
-
终止当前事务的定义，发生在multi之后，exec之前
加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行
===========================================================================
假定我们有一个set指令，服务器接收到之后会先做判断，判断set指令是否处于事务状态
-
不在事务状态：识别指令，如果是普通指令就直接执行并返回执行结果，如果是事务指令（MULTI），会直接创建事务队列，然后返回“OK”结果
-
在事务状态：识别指令，如果是普通指令，就将该指令加入队列，如果是事务指令（EXEC）则会直接执行事务，事务队列中的指令会挨个执行，执行完毕后返回执行结果并销毁事务队列，如果是事务指令（DISCARD），则会直接销毁事务队列，返回结果
事务执行流程图解
=============================================================================
1.如果定义事务的过程中，命令格式输入错误怎么办？
-
语法错误
-
指命令书写格式有误
-
处理结果
-
如果定义的事物中所包含的命令存在语法错误，整体事务中所有命令
均不会执行。包括那些语法正确的命令
2.如果定义事务的过程中，命令执行出现错误怎么办？
-
运行错误
-
指命令格式正确，但是无法正确的执行，例如对list进行incr操作
-
处理结果
-
能够正确运行的命令会执行，
运行错误的命令不会被执行
注意：已经执行完毕的命令对应的数据不会自动实现回滚，有些操作具有连贯性的，当我们其中一行指令执行错误,
后面指令的结果会受到影响，这就比较难受了，需要程序员自己在代码中实现回滚，因为这种原因，redis的事务在
企业级开发中用的较少一些
=====================================================================
业务场景1
天猫双11热卖过程中，对已经售空的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系列的操作，牵扯到多个连续操作，如何保障不会重复操作？
业务分析1
-
多个客户端有可能
同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作 -
在操作之前锁定要操作的数据，一旦发生变化，终止当前操作
解决方案1
-
对key添加监视锁，在执行exec前如果key发生了变化，终止事务进行
-
watch key1 [key2…]
-
取消对所有key的监视
-
unwatch
在执行exec之前，我们让另一个客户端修改name的值，发现执行exec之后结果为nil，事务队列中的所有指令都被取消，可以看出，watch指令监控的东西一旦发生改变，事务将不再执行，除非在开启事务之前unwatch，取消监控
业务场景2
天猫双11热卖过程中，对已经售空的货物追加补货，且补货完成。客户购买热情高涨，3秒内将所有商品购买完毕。本次补货已经将库存全部清空，如何避免最后一件商品不被多人同时购买？【超卖问题】
业务分析2
-
使用
watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据 -
虽然
redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改？
解决方案2
-
使用setnx设置一个公共锁
-
setnx lock-key value
-
作用
-
利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
-
对于返回设置成功的，拥有控制权，进行下一步的具体业务操作 -
对于返回设置失败的，不具有控制权，排队或等待 -
操作完毕通过del操作释放锁
上述解决方案是一种设计概念，依赖规范保障，具有风险性（锁必须一致，如果设置锁为lock-num那么之后是用的
锁都应该是lock-num）
操作演示：
我们对num加锁，对其进行操作，如果此时另一个用户也想获取锁就会失败
==========================================================================
业务场景1
依赖分布式锁的机制，某个用户操作时对应的客户端宕机，但是它已经获得了锁，其他客户端需要它释放锁才能继续工作，如何解决？
业务分析1
-
由于锁操作由用户控制加锁解锁，必定会存在加锁后未解锁的风险
-
需要解锁操作不能仅依赖用户控制，系统级别要给出对应的保底处理方案
我们采取的方案就是给锁加一个时效
解决方案1
-
使用expire为锁key添加时间限定，到时不释放，放弃锁
-
expire lock-key second （设置秒）
-
pexpire lock-key milliseconds （设置毫秒）
演示：
此时另一客户不断获取锁，终于在设定的20s之后获取到了锁
======================================================================
========================================================================
Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态
-
XX：具有时效性的数据
-
-1：永久有效的数据
-
-2：已经过期的数据或被删除的数据或为定义的数据
时效性数据的存储结构
redis会开放出一个空间名叫expires，它是哈希结构的，存放的数据左边是16进制的地址，而右边就是过期时间，一个地址和一个过期时间相对应
数据删除策略的目标：
在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或内存泄露
==========================================================================
==========================================================================
==========================================================================
-
数据
到达过期时间，不作处理，等下次访问该数据时再做处理（get name） -
如果未过期，返回数据
-
如果过期，删除数据，返回不存在，内部会触发expirelfNeeded()函数，在任何获取数据的操作之前内部都将执行这个操作，expirelfNeeded()便是检查数据是否过期的
-
优点、节约CPU性能，发现必须删除的时候才删除 -
缺点：内存压力很大，出现长期占用内存的数据
总结：以空间换时间
==========================================================================
通过对比我们发现，无论是定时删除还是惰性删除都显得太过极端，有没有一种折中方案呢？
在redis的16个数据库中每一个数据库中都会存在一个expires,里面存放所有的过期数据地址和过期时间
定期删除的策略是这样的：
当redis启动服务完成初始化的时候，它会去读取server.hz的值，这个值默认为10
- redis每秒执行server.hz次serverCron()进行定时轮询，serverCron会去调用databasesCron()方法，对
redis的每个库进行轮询，访问expires的信息，对他们执行activeExpireCycle()进行数据检查
-
activeExpireCycle()方法对每个expires[*]逐一进行检测，每次执行250ms/server.hz次
-
activeExpireCycle()的执行策略是对每个expires[*]检测时，随机挑选W个key检测，如果key超时，就直接
删除key，如果一轮中超时的key的数量>Wx25%，则循环该过程，如果<Wx25%,则检查下一个数据库的expires,16
个数据库循环进行
-
简单地说我们可以理解为抽奖，一直对16个数据库进行轮询，删除过期数据，对于某一个数据库如果过期数据>
-
抽出总量的1/4则继续抽奖，否则就去下一个数据库继续抽奖
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
最后
每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。
如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-5dxB24Vu-1712791603490)]
[外链图片转存中…(img-brfYkiV9-1712791603490)]
[外链图片转存中…(img-r4qMuAXu-1712791603490)]
[外链图片转存中…(img-XyaGvQPO-1712791603491)]
[外链图片转存中…(img-lPPcD9iK-1712791603491)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-8Q6S9Eq8-1712791603491)]
最后
每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。
如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。
[外链图片转存中…(img-xmS2rs5x-1712791603491)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-qx53lETO-1712791603492)]
扫一扫
495
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
