sanylove的博客

当 AOF 写回策略配置了 Always 策略，如果写入是一个大 Key，主线程在执行 fsync() 函数的时候，阻塞的时间会比较久，因为当写入的数据量很大的时候，数据同步到硬盘这个过程是很耗时的。AOF 重写机制和 RDB 快照（bgsave 命令）的过程，都会分别通过fork()函数创建一个子进程来处理任务。会有两个阶段会导致阻塞父进程（主线程）：创建子进程的途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长；

大 key 并不是指 key 的值很大，而是 key 对应的 value 很大。一般而言，下面这两种情况被称为大 key：String 类型的值大于 10 KB；Hash、List、Set、ZSet 类型的元素的个数超过 5000个；

今天跟大家聊聊两个问题：如何用 Redis 实现分布式锁？Redis 是如何解决集群情况下分布式锁的可靠性问题的？

今天跟大家聊聊，常见的 3 种缓存更新策略。Cache Aside（旁路缓存）策略；Read/Write Through（读穿 / 写穿）策略；Write Back（写回）策略；实际开发中，Redis 和 MySQL 的更新策略用的是 Cache Aside，另外两种策略主要应用在计算机系统里。

Redis 使用的过期删除策略是「惰性删除+定期删除」，删除的对象是已过期的 key。

当有个哨兵标记主节点为「客观下线」后，就会进行选举 Leader 的过程，因为此时哨兵集群还剩下 3 个哨兵，那么还是可以拿到半数以上（5/2+1=3）的票，而且也达到了 quorum 值，满足了选举 Leader 的两个条件， 所以就能选举成功，因此哨兵集群可以完成主从切换。这时如果要恢复服务的话，需要人工介入，选择一个「从节点」切换为「主节点」，然后让其他从节点指向新的主节点，同时还需要通知上游那些连接 Redis 主节点的客户端，将其配置中的主节点 IP 地址更新为「新主节点」的 IP 地址。

整数集合是 Set 对象的底层实现之一。当一个 Set 对象只包含整数值元素，并且元素数量不时，就会使用整数集这个数据结构作为底层实现。

redis是一种内存数据库，所有的操作都是在内存中进行的，还有一种重要原因是：它的数据结构的设计对数据进行增删查改操作很高效。redis的数据结构是什么redis数据结构是对redis键值对值的数据类型的底层的实现，注意不是。

今天聊聊redis 三种缓存更新策略分别是：Cache Aside（旁路缓存）策略；Read/Write Through（读穿 / 写穿）策略；Write Back（写回）策略；其中 Cache Aside策略是redis和Mysql使用的更新策略，另外两种策略主要使用在计算机系统上。

在文章中，我们知道如果redis宕机了，我们可以通过AOF 和 RDB 文件的方式恢复数据，从而保证数据的丢失（或少量损失）从而提高稳定性。但是，如果我们数据只存在一台redis服务器中，那么在恢复期间我们无法提供服务的，这不符合服务器的高可靠性。如果更加严重的话，这台服务器的硬盘出现了故障，那么数据是不是全部丢失了吗？这也是无法接受的。那么为了避免这种单点故障，我们有什么办法呢？有同学可以会想到的机制。那就恭喜你了，你想的答案是对的。在redis中也提供来解决这样的问题。

Redis读写速度快、性能优越是因为它将所有数据存在了内存中，然而，当Redis进程退出或重启后，所有数据就会丢失。所以我们希望Redis能保存数据到硬盘中，在Redis服务重启之后，原来的数据能够恢复，这个过程就叫持久化。

我们都知道，用户数据一般都是存储在数据库中，而数据库的数据是落地于磁盘的，如果我们读取数据库的数据那是很慢的。一旦，用户访问量上来，就很容易引起数据库崩溃。所以，我们一般会加入一层缓存避免直接访问数据库，而redis就是不错的缓存层。因为redis是内存数据库，所以存放redis中的数据跟存放在内存中的数据差不多。这也是我们今天要解决的问题，要知道它们怎么发生的，然后该怎么解决。

在文章中，仔细的学习了一些MYSQL数据库的知识。但是，随着我们的业务越来越好，那么我们不可能直接去操作MYSQL数据库。因为直接去操作MYSQL终究会有比较多的I/O操作，而使整个系统的性能最终受到数据库I/O的制约而无法承载。所以，我们一般会给服务器加入缓存，这样客户端的操作可以直接操作缓存，从而减轻数据库的压力。而NOSQL中的redis比较常用的场景就是作为缓存。当我们引入缓存之后，怎么样去更新缓存和数据库的数据呢？

今天跟大家聊聊两个问题：如何用 Redis 实现分布式锁？Redis 是如何解决集群情况下分布式锁的可靠性问题的？