简述网站开发平台及常用开发工具,软文推广套餐,长沙建企聘企业管理有限公司,品牌化妆品排行榜前十名双写一致
双写一致性#xff1a; 当修改了数据库中的数据#xff0c;也要更新缓存的数据#xff0c;使缓存和数据库中的数据保持一致。 相关问题#xff1a;使用Redis作为缓存#xff0c;mysql的数据如何与Redis进行同步#xff1f;——双写一致性问题 回答时#xff0…双写一致
双写一致性 当修改了数据库中的数据也要更新缓存的数据使缓存和数据库中的数据保持一致。 相关问题使用Redis作为缓存mysql的数据如何与Redis进行同步——双写一致性问题 回答时根据不同的业务背景分为高要求一致场景和允许延迟一致场景。
高要求一致业务场景
策略一 在进行写操作时采用延迟双删策略 过程如图 在执行更新操作之前先进行一次删除缓存操作删除旧数据等数据库修改之后再进行一次删除缓存操作确保删除旧数据降低脏数据的出现。 延时删除由于数据库一般采取的是主从模式当主节点的数据发生改变时需要一定的时间等待其他的从结点完成数据同步因此需要延时删除缓存。因此延时的度也不好控制延时双删策略仍会存在脏数据的风险。
特点 有脏数据风险代码耦合性高
策略二 采用互斥锁如图所示 由上图可见无论是读、写操作都要进行加锁访问数据库这会大大降低服务器的性能。但在实际应用中存入缓存中的数据大都是读多写少型数据若需要经常修改数据不建议放入缓存直接访问数据库效率更高因此可以采用由Redisson提供的读写锁 进行控制。 共享锁读锁readLock加锁之后其他线程可以共享读操作 排他锁独占锁writeLock也叫加锁之后阻塞其他线程读写操作 如图 特点 保证了数据的强一致性但性能低适合高要求一致的业务场景。
允许延迟一致业务场景
策略一 异步通知保证数据的最终一致性 当我们将修改数据写入到MySQL后就会发送一条消息到MQ在缓存服务模块监听MQ最终更新缓存。该方式保证最终一致性的关键在于——保证MQ的可靠性。
策略二 基于Canal由阿里开源的数据库变更监听工具的异步通知 当有数据被写入数据库会把数据库发生的变化记录到BINLOG二进制日志文件中如DDL【数据定义语言】语句和DML【数据操纵语言】语句但不包括数据查询语句如SELECT、SHOW。当Canal监听到BINLOG发生变化则会通知缓存进行数据更新。
持久化
持久化是指将数据保存在非易失性存储介质如磁盘、固态硬盘等主要目的是保证数据的持久性即使在系统系统关闭或重启之后数据仍然能够被恢复访问。Redis采用了两种持久化方式——RDB和AOF这两种方式可以分别或同时使用以满足不同的需求。 RDBRedis Database Backup fileRedis数据备份文件也称为Redis数据快照持久化 RDB持久化是通过将Redis的数据集快照写入磁盘来实现的。它将当前内存中的数据状态保存到一个二进制文件称为RDB文件中以便在Redis重启时进行恢复。命令执行 ps对主进程进行数据快照时会阻塞其他进程执行所以一般使用bgsave命令对子进程进行RDB以上是主动备份的方式——即需要程序员手动备份。Redis提供了自动触发RDB的机制可以通过redis.conf进行设置如下 RDB持久化通常用于数据备份和恢复因为它可以在较短的时间内创建一个全量的数据快照。RDB持久化的缺点是可能会造成一定程度的数据丢失因为它是周期性地生成快照如果Redis服务器突然崩溃可能会丢失最后一次快照后的所有数据变更。 AOF持久化Append Only File AOF持久化记录了Redis服务器接收到的所有写操作命令以追加的方式写入一个日志文件称为AOF文件中。psAOF默认是关闭我们需要修改配置文件redis.conf来开启AOP。# 是否开启AOF功能默认是no
appendonly yes
# AOF文件的名称
appendfilename appendonly.aof设置AOF的命令记录的频率# 表示每执行一次写命令立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区然后表示每隔1秒将缓冲区数据写到AOF文件是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no一般在项目中采取everysec的方式。 Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb AOF持久化可以保证更高的数据完整性因为它记录了每个写操作命令可以通过重新执行这些命令来恢复数据。AOF持久化的缺点是日志文件可能会变得很大因此Redis提供了一些压缩和重写机制来减小AOF文件的体积。
RDB的执行原理
采用bgsave方式 快照生成 RDB持久化通过生成数据库的快照来保存数据。当满足一定条件时例如在一定的时间间隔内或者在达到一定的写入操作次数时Redis会fork一个子进程将当前内存中的数据集以及服务器状态保存到一个临时文件中。 写入临时文件 在生成快照期间Redis主进程会继续处理客户端的读写请求。而子进程则负责将数据库的快照写入到临时文件中这个过程不会阻塞主进程的运行。 替换原有文件 当子进程完成快照的生成后Redis会用新生成的临时文件替换掉旧的RDB文件从而完成持久化操作。在这个过程中Redis会使用原子操作来确保数据的完整性。 在上图中主进程通过页表与内存进行数据交互。当进行数据备份时主进程会创建一个新的子进程来完成该项任务创建一个子进程和复制页表的时间消耗很少因此对主进程的影响也小。在子进程中仍然是通过从主进程中复制的页表来读取内存中的数据。在子进程进行数据备份时主进程不会发生阻塞因此主进程可能会进行写操作为了避免出现脏数据因此对主/子进程共享的区域进行了操作限制在子进程备份期间该区域只允许读操作。当主进程执行写操作时则会拷贝一份数据执行写操作如数据B。当子进程完成数据快照猴替换掉磁盘上的旧RDB文件保存当前读取的数据为新的RDB文件
fork采用的是copy-on-write技术
当主进程执行读操作时访问共享内存当主进程执行写操作时则会拷贝一份数据执行写操作。
特点 定时对整个内存做数据备份。
优点 高效的备份和恢复RDB持久化通过生成数据库的快照来保存数据生成的快照文件通常比较紧凑恢复速度快适合用于数据备份和恢复。 适用于大规模数据RDB持久化在生成快照时会fork一个子进程生成快照的过程中主进程可以继续处理客户端的读写请求因此适用于大规模数据的场景。 易于理解和操作RDB持久化生成的快照文件是一个二进制文件相对于AOF持久化的操作日志文件来说更容易理解和操作。 适用于灾难恢复RDB持久化生成的快照文件可以存档在磁盘上以备份的形式存储可以用于灾难恢复和数据迁移。
缺点 可能造成数据丢失RDB持久化是周期性生成快照文件因此在两次快照之间的数据变更可能会丢失尤其是在Redis服务器突然崩溃时可能会丢失最后一次快照后的所有数据变更。 IO开销较大生成快照文件需要将整个数据集写入磁盘因此可能会造成一定的IO开销影响系统的性能。 不适合频繁写入场景由于生成快照需要将整个数据集写入磁盘因此对于频繁写入的场景RDB持久化可能会导致较大的性能开销。 不够实时RDB持久化是基于时间间隔或写入操作次数触发的因此无法做到实时保存数据可能会有一定的数据延迟。
AOF执行原理 写入操作记录 当Redis接收到写入操作如SET、DEL等时它将相应的写操作以追加Append的方式记录到AOF文件中即将操作命令追加到AOF文件的末尾。 数据恢复 在Redis重启时会读取AOF文件中的操作记录并按顺序重新执行这些写操作命令以重建数据集的状态。
因为是记录命令AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作但只有最后一次写操作才有意义。通过执行bgrewriteaof命令可以让AOF文件执行重写功能用最少的命令达到相同效果。 特点 记录每次执行的写入操作命令。
优点 数据完整性更好AOF持久化记录了每个写操作的命令因此可以更精确地恢复数据减少数据丢失的可能性。 易于恢复AOF文件中的操作记录是顺序写入的因此在恢复数据时只需要按顺序执行操作记录即可恢复速度比较快。 可读性强AOF文件中的写操作是以命令的形式记录的易于人类阅读和理解。
缺点 文件体积较大AOF文件中记录了大量的操作命令因此AOF文件的体积通常比较大可能会占用较多的磁盘空间。 写入性能较差由于AOF持久化需要将每个写操作追加到文件末尾因此可能会造成文件的频繁写入影响了写入性能。 数据恢复耗时由于AOF文件体积较大重启时需要读取并执行整个AOF文件中的操作记录因此在数据恢复时可能会花费较长的时间。
RDB与AOF对比 RDB和AOF各有自己的优缺点如果对数据安全性要求较高在实际开发中往往会结合两者来使用。
