说淑人的所思所想

（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习过程/多有漏误/仅作参考/不再更新）（学习总结/最新最准/持续更新）（学习总结/最新最准/持续更新）

主从同步的本质是数据复制机制。主从同步机制无法避免在主机宕机时丢失数据。Redis存在“一主多从/级联”两种主从同步架构。

此外主从同步还间接具备提升数据读/写性能的效果，因为只要将读/写指令分别引导至从/主机执行以实现读/写分离，那么原本该由主机一力承担的指令便可以分摊至多台Redis实例上并发执行，从而大幅提升读/写效率。在开启主从同步的情况下，主机更推荐同时开启RDB/AOF机制以保证数据尽可能的完整，毕竟其是数据的实际来源，而从机的持久化方案则需要根据实际情况来定。随后通过从机偏移量在复制积压缓冲区中定位最后同步指令的位置，并向从机发送尚未同步的复制加压缓冲指令以实现持续性的指令同步；开启主从同步后还需要开启持久化吗？

Redisson基于Redis提供了多项适用于分布式环境的线程控制功能。Redisson锁支持自动释放。

红锁特性的具体表现是：当线程试图加/解锁任意类型的锁时，如果其操作的目标Redis实例存在任意形式（主从/集群）的从机，那么其只有在主机将锁信息同步至从机后才会返回成功。可以很快发现的是红锁在单机/主从部署的Redis中是没有多少使用意义的，因为在这种情况下无论使用了多少锁去组成红锁，其锁信息也都会被统一保存在单个实例/主机中，因为信息一旦丢失也往往是全局性的。我们通常所说的红锁是指由Redisson在早期版本中提供的一种在Redis集群环境中使用的锁，相比普通的锁而言其具备更高的容错性。

淘汰策略用于在内存不足时控制Redis对数据的删除。Redis会执行淘汰策略前先执行过期策略。

最近/长期使用频率的模拟：Redis并不会对数据的最近/长期使用频率进行精确计算，而是会使用最近访问时间/概率访问总数来进行模拟。局部比较代替全量比较：为了最大程度的提升性能/降低开销，Redis不会去比较全量数据的最近/长期使用频率，而只会随机抽取{maxmemory-samples}配置项数量的数据来进行局部比较，并将最近/长期使用频率最小的数据淘汰。Redis对LRU/LFU类型的淘汰策略采用的是近似实现，因此统计/对比所有目标数据的最近/完全使用次数/频率是非常耗费性能的行为…

所谓缓存雪崩是缓存击穿的并发情况，即短时间内有大量缓存失效而导致更大数量的请求直接访问数据库…避免缓存雪崩的常用解决方案如下：设置热点数据永不过期；为热点数据设置不同的存活时间；使用惰性缓存方案，确保热点数据只在使用时才被缓存，从而分散热点数据的缓存时间；对向数据库请求的过程加互斥锁；将热点数据的缓存更新交由专属的后台线程处理，而后台线程则需频繁检查缓存是否失效，并在失效时及时加载缓存（不推荐）。什么是缓存穿透？怎么避免？

Redis事务并不严格具备ACID属性。在我们对数据库的常规理解中，事务必然会严格遵守原子性/一致性/隔离性/持久性。但由于Redis基于内存设计/实现的原因，其对事务ACID属性的实现并不存在/彻底。因此与其称之为事务，将之称为批处理其实更加贴切...该知识点会在下文讲解ACID时详述。Redis事务的意义是为了防止插队。Redis事务中的指令会被打包一次执行，因此可以避免多客户端指令交互执行的情况发生。

Redis事务有组队/执行两个阶段，在组队阶段中任意指令的语法错误都将导致整个事务拒绝被执行，因此事务在组队阶段是具备原子性的。但在执行阶段中指令的错误执行并不会对事务造成影响，事务依然会继续向后执行至彻底结束为止，因此事务在执行阶段时并不具备原子性，故而才说Redis事务只具备伪原子性，并且其也不支持回滚。此外为了避免事务的目标数据在执行过程中被其它事务/指令修改，还可以在开启事务前先通过{WATCH}指令监控指定键集，在键集中任意键的值被改动的情况下事务都将无法被执行。事务有组队/执行两个阶段。

哨兵机制实现了对主从同步机制故障转移的自动化。哨兵会对外提供Redis的连接地址。哨兵推荐以奇数集群的形式进行工作。监测相同主机的多个哨兵默认同属一个集群。

这是因为在判断主节点已宕机的情况下哨兵集群协同投票选举出监测数据最新的哨兵成为领导哨兵，目的是由其根据从节点的优先级/主机数据的同步进度/运行ID的大小等因素选择出可用性最高的从节点以作为新的主节点。直接通讯是在间接通讯的基础上后天建立起来的，因为哨兵会根据其它哨兵共享的地址信息而与之建立TCP连接。在通知完其它哨兵这个消息后，领导哨兵会根据从机的优先级/主机数据的同步进度/运行ID的大小等因素挑选出可用性最高的从机作为新主机，并修改其它从机的配置以令之向新主机同步，最后再将新主机告知其它哨兵；

Redis集群通过数据分片来分摊单台Redis的读/写压力。Redis集群是去中心化的。Redis集群支持高效扩/缩容Redis集群支持自动主从同步/故障转移。

内存开销小/通讯影响少/增加集群体量：Redis集群的节点数量是很难超过1000个的，其“主要”原因是集群中的节点两两之间都会进行通讯，因此节点数量的增加就意味着“单个节点需要通讯的其它节点数量/通讯心跳包中包含的各节点数据（主要指各节点的运行状态，用于综合反应集群状态）”也同步增加，从而在节点数量接近1000时因为出现网络拥堵现象而难以继续扩容。而由于这两者的映射关系是受开发者主观控制的，因此迁移那（几）个节点的数据，迁移多少数据都可以自由决定，从而为最佳迁移方案的指定/执行提供了实现基础。

本地缓存的优点是轻量/快速，但缺点是生命周期与服务绑定，并且由于在多实例（分布式/集群）情况下每个实例都拥有各自的缓存，因此很容易在开发/使用时出现缓存不一致问题，Map/Guava就属于该类型的缓存。采用非阻塞的多路I/O复用模型，使得单线程能够并发/高效地处理多客户端连接，减少了Redis在网络I/O上的等待，并且在Redis 6.0版本中引入了多线程机制进一步提升了网络I/O的处理性能。列表类型的底层实现是双向链表，因此支持首/尾两端的插入/移除/获取，并且时间复杂度都为O(1)。

定期删除：Redis会每隔一段时间抽取一定量的期限数据并删除其中的到期数据。该过期策略的特点是期限数据的抽取频率可以动态调整，因此可以根据实际场景在删除的性能/开销上自由平衡/侧重。定期删除一个值得讲述的点是其只抽取一定数量的期限数据而不全量遍历的原因，这表面上是因为全量遍历会造成CPU/内存负载的急剧上升而对性能造成影响。Redis如此设计的真正原因是定期删除必须被高频执行以保证较好的清理效果，但如此一来其对性能的影响就是持久习惯的。（学习过程/多有漏误/仅作参考/不再更新）（学习解答/持续更新）

过期策略用于控制过期数据的删除时机。Redis同时通过“惰性删除/定期删除”过期策略来删除过期数据。惰性删除策略会令过期数据在被首次访问时被删除。惰性删除策略不支持开/关。定期删除策略会周期抽取/删除过期数据。定期删除策略不支持开/关。定期删除策略不一次性检查全量数据是出于性能方面的考量。定期删除策略不支持配置抽取数量。

Redis的发布/订阅机制是一种消息传递机制。Redis发布/订阅机制不会持久化消息。Redis发布/订阅机制无需显式创建频道。

而对于数据完整性较高的程序而言通常会同时开启RDB&AOF机制，这其中RDB机制是作为AOF机制失效是的备用手段存在的，因为AOF日志文件在持续写入的过程中有较大的概率出现损坏。此外如果对数据完整性的要求极高，那么还推荐将AOF机制的写回机制设置为always，这样Redis在宕机时丢失的数据可以达到最少，甚至有较大概率不丢失数据。RDB机制的本质是将Redis某时刻的数据保存为快照文件，从而得以在Redis重启时将数据恢复至快照文件所记录的时刻…在RDB/AOF都开启的情况下Redis会如何恢复数据？

Redis持久化机制用于避免/减少内存数据的丢失。Redis存在RDB/AOF两种持久化机制。