解决了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,因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

（编辑：云计算网_泰州站长网）

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