基础面试题
<ul>
<li><a href="https://www.topgoer.cn/docs/data-structures-questions/data-structures-questions-1d94t2g18u1v9">https://www.topgoer.cn/docs/data-structures-questions/data-structures-questions-1d94t2g18u1v9</a></li>
</ul>
<h2>为什么需要持久化</h2>
<ul>
<li>内存型数据库，服务器挂了，或者突然宕机，数据会丢失</li>
<li>让服务器在突然关机也能保存数据，通过持久化方式将数据从内存保存到磁盘中</li>
</ul>
<h2>持久化的作用</h2>
<ul>
<li>redis所有数据保存在内存中，对数据的更新将异步地保存到磁盘上。</li>
<li>主流数据库持久化实现方式
<ul>
<li>快照（MySQL Dump/Redis RDB），写日志(MySQL Binlog/Redis AOF)</li>
</ul></li>
</ul>
<h2>持久化方案</h2>
<ul>
<li>
<p><a href="https://blog.csdn.net/liupeifeng3514/article/details/79048767">https://blog.csdn.net/liupeifeng3514/article/details/79048767</a></p>
</li>
<li>RDB(快照/内存快照)
<ul>
<li>按照一定的时间周期将目前服务中的所有数据全部写入到磁盘中</li>
<li>持久化的触发分为：手动触发和自动触发</li>
<li>默认开启</li>
<li>创建RDB文件（二进制文件）到硬盘中，启动后载入RDB文件到内存</li>
</ul></li>
<li>AOF(写日志)
<ul>
<li>Append Only File 只进行增加的文件</li>
<li>周期性的同步</li>
</ul></li>
</ul>
<h2>RDB和AOF优缺点</h2>
<ul>
<li><strong>RDB持久化</strong></li>
<li>优点
<ul>
<li>RDB文件紧凑，体积小，网络传输快，适合全量复制</li>
<li>恢复速度比AOF快很多，对性能的影响相对较小</li>
</ul></li>
<li>缺点
<ul>
<li>RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化</li>
<li>RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）</li>
</ul></li>
<li><strong>AOF持久化</strong></li>
<li>优点
<ul>
<li>支持秒级持久化、兼容性好</li>
</ul></li>
<li>缺点
<ul>
<li>文件大、恢复速度慢、对性能影响大</li>
</ul></li>
</ul>
<h2>RDB & AOF最佳策略</h2>
<ul>
<li>
<p>RDB优先于AOF先启用</p>
</li>
<li>RDB：建议关掉，集中管理，在从节点开RDB</li>
<li>AOF：建议开启，每秒刷盘</li>
<li>最佳策略：小分片（log文件分片）</li>
</ul>
<h3>持久化策略选择</h3>
<ul>
<li>如果Redis中的数据完全丢弃也没有关系（如Redis完全用作DB层数据的cache）
<ul>
<li>那么无论是单机，还是主从架构，都可以不进行任何持久化。</li>
</ul></li>
<li>在单机环境下（对于个人开发者，这种情况可能比较常见）
<ul>
<li>如果可以接受十几分钟或更多的数据丢失，选择RDB对Redis的性能更加有利；</li>
</ul></li>
<li>如果只能接受秒级别的数据丢失，应该选择AOF。
<ul>
<li>在多数情况下，都会配置主从环境，从的存在既可以实现数据的热备，也可以进行读写分离分担Redis读请求，以及在主宕掉后继续提供服务。</li>
</ul></li>
</ul>
<h2>持久化触发机制</h2>
<ul>
<li>save(同步)
<ul>
<li>会产生阻塞</li>
</ul></li>
<li>文件策略
<ul>
<li>如存在老的RDB文件，新的替换老的，新的会先生成到一个临时文件</li>
</ul></li>
<li>bgsave(异步)
<ul>
<li>不会阻塞</li>
</ul></li>
</ul>
<h2>常见性能问题和解决方案</h2>
<ul>
<li>主最好不要做任何持久化工作
<ul>
<li>如RDB内存快照和AOF日志文件</li>
</ul></li>
<li>如果数据比较重要，某个从开启AOF备份数据，策略设置为每秒同步一次</li>
<li>为了主从复制的速度和连接的稳定性，主和从最好在同一个局域网内</li>
<li>尽量避免在压力很大的主库上增加从库</li>
</ul>
<h2>常用命令</h2>
<ul>
<li>slowlog get [n]:获取慢查询队列</li>
<li>slowlog len： 获取慢查询队列的长度</li>
<li>slowlog reset: 清空慢查询队列</li>
</ul>
<h2>运维经验</h2>
<ul>
<li>slowlog-max-len
<ul>
<li>不要设置过大，默认10ms,通常设置1ms，根据QPS来设置</li>
</ul></li>
<li>slowlog-log-slower-than
<ul>
<li>不要设置过小，通常设置1000左右</li>
</ul></li>
<li>定期持久化慢查询</li>
</ul>
<h2>运维和开发</h2>
<ul>
<li>节点运维
<ul>
<li>上下和下线</li>
</ul></li>
<li>机器下线
<ul>
<li>机器因为不能用了或者过保等什么原因要换机器</li>
</ul></li>
<li>机器性能不足
<ul>
<li>例如CPU、内存、硬盘、网络等</li>
</ul></li>
<li>节点自生保障
<ul>
<li>例如服务不稳定等</li>
</ul></li>
<li>哨兵故障切换
<ul>
<li>主节点主动故障转移，已经选举哨兵领导者，上述过程可以省略</li>
</ul></li>
<li>从节点下线
<ul>
<li>临时下线还是永久下线。</li>
<li>永久下线可能要清理掉一些配置文件，从节点下线的时候也要考虑读写分离的情况，因为这时候有可能正在读。</li>
</ul></li>
<li>节点上线
<ul>
<li>主节点执行哨兵故障切换进行替换，从节点slaveof即可，哨兵节点可以感知</li>
</ul></li>
</ul>
<h2>哨兵机制</h2>
<ul>
<li>在复制的基础上，哨兵实现了自动化的故障恢复</li>
<li>缺陷
<ul>
<li>写操作无法负载均衡</li>
<li>存储能力受到单机的限制</li>
</ul></li>
</ul>
<h2>分区</h2>
<ul>
<li>分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集</li>
</ul>
<h2>分区优势</h2>
<ul>
<li>通过利用多台计算机内存的和值，允许我们构造更大的数据库。</li>
<li>通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。</li>
</ul>
<h2>分区不足</h2>
<ul>
<li>涉及多个key的操作通常是不被支持的。
<ul>
<li>如：当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。</li>
</ul></li>
<li>涉及多个key的redis事务不能使用。</li>
<li>当使用分区时，数据处理较为复杂，比如你需要处理多个rdb/aof文件，并且从多个实例和主机备份持久化文件。</li>
<li>增加或删除容量也比较复杂。
<ul>
<li>redis集群大多数支持在运行时增加、删除节点的透明数据平衡的能力，但是类似于客户端分区、代理等其他系统则不支持这项特性。然而，一种叫做presharding的技术对此是有帮助的。</li>
</ul></li>
<li>分区类型
<ul>
<li>Redis 有两种类型分区。 </li>
<li>假设有4个Redis实例 R0，R1，R2，R3，和类似user:1，user:2这样的表示用户的多个key，对既定的key有多种不同方式来选择这个key存放在哪个实例中。也就是说，有不同的系统来映射某个key到某个Redis服务，关注+转发后，私信【Redis】获取300多页的Redis实战学习笔记。</li>
</ul></li>
</ul>
<h2>范围分区</h2>
<ul>
<li>最简单的分区方式是按范围分区，就是映射一定范围的对象到特定的Redis实例。
<ul>
<li>如，ID从0到10000的用户会保存到实例R0，ID从10001到 20000的用户会保存到R1，以此类推。</li>
</ul></li>
<li>缺点
<ul>
<li>要有一个区间范围到实例的映射表。这个表要被管理，同时还需要各种对象的映射表，通常对Redis来说并非是好的方法。</li>
</ul></li>
</ul>
<h2>哈希分区</h2>
<ul>
<li>对任何key都适用，无需是object_name:这种形式，
<ul>
<li>用一个hash函数将key转换为一个数字，比如使用crc32 hash函数。对key foobar执行crc32(foobar)会输出类似93024922的整数。</li>
<li>对这个整数取模，将其转化为0-3之间的数字，就可以将这个整数映射到4个Redis实例中的一个了。93024922 % 4 = 2，就是说key foobar应该被存到R2实例中。</li>
</ul></li>
<li>注意
<ul>
<li>取模操作是取除的余数，通常在多种编程语言中用%操作符实现。</li>
<li>当分区较多或发生变化的时候需要处理一些额外的情况</li>
</ul></li>
</ul>