办理了Redis的这些题目，你就是Redis好手

如上所述，在动静头中，最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时，这块的巨细是: 65536÷8÷1024=8kb 由于每秒钟，redis节点必要发送必然数目的ping动静作为心跳包，假如槽位为65536，这个ping动静的动静头太大了，挥霍带宽。

(2)redis的集群主节点数目根基不行能高出1000个。

如上所述，集群节点越多，心跳包的动静体内携带的数据越多。假如节点过1000个，也会导致收集拥堵。因此redis作者，不提议redis cluster节点数目高出1000个。 那么，对付节点数在1000以内的redis cluster集群，16384个槽位够用了。没有须要拓展到65536个。

(3)槽位越小，节点少的环境下，压缩比高

Redis主节点的设置信息中，它所认真的哈希槽是通过一张bitmap的情势来生涯的，在传输进程中，会对bitmap举办压缩，可是假如bitmap的添补率slots / N很高的话(N暗示节点数)，bitmap的压缩率就很低。 假如节点数很少，而哈希槽数目许多的话，bitmap的压缩率就很低。

Redis 并不能担保数据的强同等性， 这意味这在现实中集群在特定的前提下也许会丢失写操

作。

1.twemproxy，或许观念是，它相同于一个署理方法， 行使时在本必要毗连 redis 的处所改为毗连 twemproxy， 它会以一个署理的身份吸取哀求并行使同等性 hash 算法，将哀求转接到详细 redis，将功效再返回 twemproxy。

弱点： twemproxy 自身单端话柄例的压力，行使同等性 hash 后，对 redis 节点数目改变时辰的计较值的改变，数据无法自动移动到新的节点。

2.codis，今朝用的最多的集群方案，根基和 twemproxy 同等的结果，但它支持在 节点数目改变环境下，旧节点数据可规复到新 hash 节点

3.redis cluster3.0 自带的集群，特点在于他的漫衍式算法不是同等性 hash，而是 hash 槽的观念，以及自身支持节点配置从节点。详细看官方文档先容。

分区可以让 Redis 打点更大的内存， Redis 将可以行使全部呆板的内存。 假如没有分区， 你

最多只能行使一台呆板的内存。 分区使 Redis 的计较手段通过简朴地增进计较机获得成倍提

升,Redis 的收集带宽也会跟着计较机和网卡的增进而成倍增添。

涉及多个 key 的操纵凡是不会被支持。 譬喻你不能对两个荟萃求交集， 由于他们也许被存

储到差异的 Redis 实例（现实上这种环境也有步伐， 可是不能直接行使交集指令）。

同时操纵多个 key,则不能行使 Redis 事宜.

分区行使的粒度是key，不能行使一个很是长的排序key存储一个数据集（The partitioning

granularity is the key, so it is not possible to shard a dataset with a single huge

key like a very big sorted set） .

当行使分区的时辰， 数据处理赏罚会很是伟大， 譬喻为了备份你必需从差异的 Redis 实例和主

机同时网络 RDB / AOF 文件。

分区时动态扩容或缩容也许很是伟大。 Redis 集群在运行时增进可能删除 Redis 节点， 能

做到最洪流平对用户透明地数据再均衡，但其他一些客户端分区可能署理分区要领例不支持

这种特征。 然而， 有一种预分片的技能也可以较好的办理这个题目。

Redis 有着更为伟大的数据布局而且提供对他们的原子性操纵，这是一个差异于其他数据库

的进化路径。 Redis 的数据范例都是基于根基数据布局的同时对措施员透明， 无需举办特殊

的抽象。

Redis 运行在内存中可是可以耐久化到磁盘，以是在对差异数据集举办高速读写时必要衡量

内存， 应为数据量不能大于硬件内存。 在内存数据库方面的另一个利益是， 对比在磁盘上

沟通的伟大的数据布局， 在内存中操纵起来很是简朴， 这样 Redis 可以做许多内部伟大性

很强的工作。 同时， 在磁盘名目方面他们是紧凑的以追加的方法发生的， 由于他们并不需

要举办随机遇见

假如到达配置的上限， Redis 的写呼吁会返回错误信息（可是读呼吁还可以正常返回。） 或

者你可以将 Redis 当缓存来行使设置裁减机制，当 Redis 到达内存上限时会冲刷掉旧的内容。

可以在统一个处事器陈设多个 Redis 的实例， 并把他们看成差异的处事器来行使， 在某些时

候， 无论怎样一个处事器是不足的，

以是， 假如你想行使多个 CPU， 你可以思量一下分片（shard）。

一个 Redis 实例最多能存放几多的 keys？ List、 Set、Sorted Set 他们最多能存放几多元素？

理论上 Redis 可以处理赏罚多达 232 的 keys， 而且在现实中举办了测试， 每个实例至少存放了 2亿 5 万万的 keys。 我们正在测试一些较大的值。

任何 list、 set、 和 sorted set 都可以放 232 个元素。

换句话说， Redis 的存储极限是体系中的可用内存值

针对运行实例， 有很多设置选项可以通过 CONFIG SET 呼吁举办修改， 而无需执行任何

情势的重启。 从 Redis 2.2 开始， 可以从 AOF 切换到 RDB 的快照耐久性或其他方法

而不必要重启 Redis。 检索 ‘CONFIG GET *’ 呼吁获取更多信息。

但无意从头启动是必需的， 如为进级 Redis 措施到新的版本， 可能当你必要修改某些今朝

CONFIG 呼吁还不支持的设置参数的时辰

Redis sentinel 是一个漫衍式体系中监控 redis 主从处事器，并在主处事器下线时自动举办妨碍转移。个中三个特征：

监控（Monitoring）： Sentinel 会不绝地搜查你的主处事器和从处事器是否运作正常。

提示（Notification）： 被监控的某个 Redis 处事器呈现题目时， Sentinel 可以通过 API 向打点员可能其他应用措施发送关照。

自动妨碍迁徙（Automatic failover）： 当一个主处事器不能正常事变时， Sentinel 会开始一次自动妨碍迁徙操纵。

特点：

1、担保高可用

2、监控各个节点

3、自动妨碍迁徙

弱点：主从模式，切换必要时刻丢数据

没有办理 master 写的压力

一样平常的缓存体系，都是凭证key去缓存查询，假如不存在对应的value，就去后端体系查找（好比DB）。

一些恶意的哀求会存心查询不存在的key,哀求量很大，就会对后端体系造成很大的压力。这就叫做缓存穿透。

怎样停止？

1：对查询功效为空的环境也举办缓存，这样，再次会见时，缓存层会直接返回空值。缓存时刻配置短一点，可能该key对应的数据insert了之后整理缓存。

2：对必然不存在的key举办过滤。详细请看布隆过滤器

是针对缓存中没有但数据库有的数据。

场景是，当Key失效后，若是刹时溘然涌入大量的哀求，来哀求统一个Key，这些哀求不会掷中Redis，城市哀求到DB，导致数据库压力过大，乃至扛不住，挂掉。

办理步伐

1、配置热门Key，自动检测热门Key，将热门Key的逾期时刻加大可能配置为永不外期，可能配置为逻辑上永不外期

2、加互斥锁。当发明没有掷中Redis，去查数据库的时辰，在执行更新缓存的操纵上加锁，当一个线程会见时，其余线程守候，这个线程会见事后，缓存中的数据会被重建，这样其他线程就可以从缓存中取值。

是指大量Key同时失效，对这些Key的哀求又会打到DB上，同样会导致数据库压力过大乃至挂掉。

办理步伐

1）让Key的失效时刻分手开，可以在同一的失效时刻上再加一个随机值，可能行使更高级的算法分手失效时刻。

2）构建多个redis实例，个体节点挂了尚有此外可以用。

3）多级缓存：好比增进当地缓存，减小redis压力。

4）对存储层增进限流法子，当哀求超出限定，提供降级处事（一样平常就是返回错误即可）

单线程的redis为什么这么快

(一)纯内存操纵

(二)单线程操纵，停止了频仍的上下文切换

(三)回收了非阻塞I/O多路复用机制

（着实就是汗青遗留题目，非要吹的这么好。。。）

redis回收的是按期删除+惰性删除计策。

为什么不消按时删除计策?

按时删除,用一个按时器来认真监督key,逾期则自动删除。固然内存实时开释，可黑白常耗损CPU资源。在大并发哀求下，CPU要将时刻应用在处理赏罚哀求，而不是删除key,因此没有回收这一计策.

按期删除+惰性删除是怎样事变的呢?

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!