XL来
学生
获得徽章 1
- #青训营笔记创作活动#
1月30日 打卡 Day54
缓存降级，其实都应该是指服务降级。在访问量剧增、服务响应出现问题（如响应延迟或不响应）或非核心服务影响到核心流程的性能的情况下，仍然需要保证核心服务可用，尽管可能一些非主要服务不可用，这时就可以采取服务降级策略。
服务降级的最终目的是保证核心服务可用，即使是有损的。服务降级应当事先确定好降级方案，确定哪些服务是可以降级的，哪些服务是不可降级的。根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心服务的正常运行。
降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。根据服务方式：可以拒接服务，可以延迟服务，也可以随机提供服务。根据服务范围：可以暂时禁用某些功能或禁用某些功能模块。总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。
展开评论点赞 - #青训营笔记创作活动#
1月29日 打卡 Day53
全量同步：
Slave 初始化时它会发送一个 psync 命令到主服务器，如果是第一次同步，主服务器会做一次bgsave，并同时将后续的修改操作记录到内存 buffer 中，待 bgsave 完成后再将 RDB 文件全量同步到从服务器，从服务器接收完成后会将 RDB 快照加载到内存然后写入到本地磁盘，处理完成后，再通知主服务器将期间修改的操作记录同步到复制节点进行重放就完成了整个全量同步过程
展开评论点赞 - #青训营笔记创作活动#
1月28日 打卡 Day52
增量同步：
Slave 初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。增量同步的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令。
展开评论点赞 - #青训营笔记创作活动#
1月27日 打卡 Day51
过期删除策略3
方式3：定期删除
每隔一段时间就会对数据库进行一次检查，删除里面的过期Key，而检查多少个数据库，则由算法决定
特点： 定期删除是对上面两种过期策略的折中，也就是对内存友好和CPU友好的折中方法。每隔一段时间执行一次删除过期键任务，并通过限制操作的时长和频率来减少对CPU时间的占用
展开评论点赞 - #青训营笔记创作活动#
1月26日 打卡 Day50
过期删除策略2
惰性删除
key 不使用时不管 key 过不过期，只会在每次使用的时候再检查 Key 是否过期，如果过期的话就会删除该 Key。
特点： 对 CPU 友好，对内存不友好。不会花费额外的CPU资源来检测Key是否过期，但如果存在较多未使用且过期的Key时，所占用的内存就不会得到释放
展开评论点赞 - #青训营笔记创作活动#
1月25日 打卡 Day49
过期删除策略
定时删除
在设置 Key 的过期时间的同时，会创建一个定时器 timer，定时器在 Key 过期时间来临时，会立即执行对 Key 的删除操作
特点： 对内存友好，对 CPU 不友好。存在较多过期键时，利用定时器删除过期键会占用相当一部分CPU展开评论点赞 - #青训营笔记创作活动#
1月24日 打卡 Day48
AOF 全称是 Append Only File（追加文件）。当 Redis 处理每一个写命令都会记录在 AOF 文件中，可以看做是命令日志文件。该方式需要设置 AOF 的同步选项，因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区中，同步选项有三种配置项选择：
always：同步刷盘，可靠性高，但性能影响较大
everysec：每秒刷盘，性能适中，最多丢失 1 秒的数据
no：操作系统控制，性能最好，可靠性最差
为了解决 AOF 文件体检不断增大的问题，用户可以向 Redis 发送 bgrewriteaof 命令，可以将 AOF 文件进行压缩，也可以选择自动触发，在配置文件中配置
auto-aof-rewrite-precentage 100 auto-aof-rewrite-min-zise 64mb
优点
实现持久化，数据安全，AOF持久化可以配置 appendfsync 属性为 always，每进行一次命令操作就记录到AOF文件中一次，数据最多丢失一次
通过 append 模式写文件，即使中途服务器宕机，可以通过 Redis-check-aof 工具解决数据一致性问题
AOF 机制的 rewrite 模式。AOF 文件的文件大小触碰到临界点时，rewrite 模式会被运行，重写内存中的所有数据，从而缩小文件体积
缺点
AOF 文件大，通常比 RDB 文件大很多
比 RDB 持久化启动效率低，数据集大的时候较为明显
AOF 文件体积可能迅速变大，需要定期执行重写操作来降低文件体积展开评论点赞 - #青训营笔记创作活动#
1月23日 打卡 Day47
、RDB（Redis DataBase）持久化
RDB 是 Redis 中默认的持久化机制，按照一定的时间将内存中的数据以快照的方式保存到磁盘中，它会产生一个特殊类型的文件 .rdb 文件，同时可以通过配置文件中的 save 参数来定义快照的周期
在 RDB 中有两个核心概念 fork 和 cow，在执行备份的流程如下：
在执行bgsave的时候，Redis 会 fork 主进程得到一个新的子进程，子进程是共享主进程内存数据的，会将数据写到磁盘上的一个临时的 .rdb 文件中，当子进程写完临时文件后，会将原来的 .rdb 文件替换掉，这个就是 fork 的概念。那 cow 全称是 copy-on-write ，当主进程执行读操作的时候是访问共享内存的，而主进程执行写操作的时候，则会拷贝一份数据，执行写操作。
优点
只有一个文件 dump.rdb ，方便持久化
容错性好，一个文件可以保存到安全的磁盘
实现了性能最大化，fork 单独子进程来完成持久化，让主进程继续处理命令，主进程不进行任何 I/O 操作，从而保证了Redis的高性能
RDB 是一个紧凑压缩的二进制文化，RDB重启时的加载效率比AOF持久化更高，在数据量大时更明显
缺点
可能出现数据丢失，在两次RDB持久化的时间间隔中，如果出现宕机，则会丢失这段时间中的数据
由于RDB是通过fork子进程来协助完成数据持久化，如果当数据集较大时，可能会导致整个服务器间歇性暂停服务
展开评论点赞 - #青训营笔记创作活动#
1月22日 打卡 Day46
完全基于内存
数据结构简单，操作方便，并且不同数据结构能够应对于不同场景
采用单线程（网络请求模块使用单线程，其他模块仍用了多线程），避免了不必要的上下文切换和竞争条件，也不存在多进程或多线程切换导致CPU消耗，不需要考虑各种锁的问题。
使用多路I/O复用模型，为非阻塞I/O
Redis 本身设定了 VM 机制，没有使用 OS 的Swap，可以实现冷热数据分离，避免因为内存不足而造成访问速度下降的问题
展开评论点赞 - #青训营笔记创作活动#
1月20日 打卡 Day45
Redis 能够用来实现分布式锁的命令有 INCR、SETNX、SET，并利用过期时间命令 expire 作为辅助
方式1：利用 INCR
如果 key 不存在，则初始化值为 0，然后再利用 INCR 进行加 1 操作。后续用户如果获取到的值大于等于 1，说明已经被其他线程加锁。当持有锁的用户在执行完任务后，利用 DECR 命令将 key 的值减 1，则表示释放锁。
方式2：利用 SETNX
先使用 setnx 来争抢锁，抢到之后利用 expire 设置一个过期时间防止未能释放锁。setnx 的意义是如果 key 不存在，则将key设置为 value，返回 1。如果已存在，则不做任何操作，返回 0。
方式3：利用 SET
set 指令有非常复杂的参数，相当于合成了 setnx 和 expire 两条命令的功能。其命令格式如：set($Key,$value, array('nx', 'ex'=>$ttl))。
展开评论点赞