解决了Redis的这些问题，你就是Redis高手

内存分配：由于c不记录字符串长度，对于包含了n个字符的字符串，底层总是一个长度n+1的数组，每一次长度变化，总是要对这个数组进行一次内存重新分配的操作。因为内存分配涉及复杂算法并且可能需要执行系统调用，所以它通常是比较耗时的操作。

双端、无环、带长度记录、

多态：使用 void* 指针来保存节点值， 可以通过 dup 、 free 、 match 为节点值设置类型特定函数， 可以保存不同类型的值。

其实字典这种数据结构也内置在很多高级语言中，但是c语言没有，所以redis自己实现了。

应用也比较广泛，比如redis的数据库就是字典实现的。不仅如此，当一个哈希键包含的键值对比较多，或者都是很长的字符串，redis就会用字典作为哈希键的底层实现。

LRU全称是Least Recently Used，即最近最久未使用的意思。

LRU算法的设计原则是：如果一个数据在最近一段时间没有被访问到，那么在将来它被访问的可能性也很小。也就是说，当限定的空间已存满数据时，应当把最久没有被访问到的数据淘汰。

redis原始的淘汰算法简单实现：当需要淘汰一个key时，随机选择3个key，淘汰其中间隔时间最长的key。**基本上，我们随机选择key，淘汰key效果很好。后来随机3个key改成一个配置项"N随机key"。但把默认值提高改成5个后效果大大提高。考虑到它的效果，你根本不用修改他。

1. RDB持久化可以手动执行，也可以配置定期执行，可以把某个时间的数据状态保存到RDB文件中，反之，我们可以用RDB文件还原数据库状态。
2. AOF持久化是通过保存服务器执行的命令来记录状态的。还原的时候再执行一遍即可。

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久

化功能。 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以

只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照

（snapshot） 非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复

的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。

1.twemproxy， 大概概念是， 它类似于一个代理方式， 使用方法和普通 Redis 无任何区别，

设 置 好它 下 属 的多 个 Redis 实 例 后， 使 用 时在 本 需 要 连接 Redis 的 地 方改 为 连接

twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法， 将请求转接到具

体 Redis， 将结果再返回 twemproxy。 使用方式简便(相对 Redis 只需修改连接端口)， 对

旧项目扩展的首选。 问题： twemproxy 自身单端口实例的压力， 使用一致性 hash 后， 对

Redis 节点数量改变时候的计算值的改变， 数据无法自动移动到新的节点。

2. codis， 目前用的最多的集群方案， 基本和 twemproxy 一致的效果， 但它支持在 节点

数量改变情况下， 旧节点数据可恢复到新 hash 节点。

3. Redis cluster3.0 自带的集群， 特点在于他的分布式算法不是一致性 hash， 而是 hash

槽的概念， 以及自身支持节点设置从节点。 具体看官方文档介绍。

4.在业务代码层实现， 起几个毫无关联的 Redis 实例， 在代码层， 对 key 进行 hash 计算，

然后去对应的 Redis 实例操作数据。 这种方式对 hash 层代码要求比较高， 考虑部分包括，

节点失效后的替代算法方案， 数据震荡后的自动脚本恢复， 实例的监控， 等等

MySQL 里有 2000w 数据， Redis 中只存 20w 的数据，

如何保证 Redis 中的数据都是热点数据？

Redis 内存数据集大小上升到一定大小的时候， 就会施行数据淘汰策略

（1）、 会话缓存（Session Cache）

最常用的一种使用 Redis 的情景是会话缓存（session cache）。 用 Redis 缓存会话比其他

存储（如 Memcached） 的优势在于： Redis 提供持久化。 当维护一个不是严格要求一致性

的缓存时， 如果用户的购物车信息全部丢失， 大部分人都会不高兴的， 现在， 他们还会这样

吗？

幸运的是， 随着 Redis 这些年的改进， 很容易找到怎么恰当的使用 Redis 来缓存会话的文

档。 甚至广为人知的商业平台 Magento 也提供 Redis 的插件。

（2）、 全页缓存（FPC）

除基本的会话 token 之外， Redis 还提供很简便的 FPC 平台。 回到一致性问题， 即使重启

了 Redis 实例， 因为有磁盘的持久化， 用户也不会看到页面加载速度的下降， 这是一个极

大改进， 类似 PHP 本地 FPC。

再次以 Magento 为例， Magento 提供一个插件来使用 Redis 作为全页缓存后端。

此外， 对 WordPress 的用户来说， Pantheon 有一个非常好的插件 wp-Redis， 这个插件

能帮助你以最快速度加载你曾浏览过的页面。

（3）、 队列

Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得 Redis 能作为一个

很好的消息队列平台来使用。 Redis 作为队列使用的操作， 就类似于本地程序语言（如

Python） 对 list 的 push/pop 操作。

如果你快速的在 Google 中搜索“Redis queues”， 你马上就能找到大量的开源项目， 这些

项目的目的就是利用 Redis 创建非常好的后端工具， 以满足各种队列需求。 例如， Celery

有一个后台就是使用 Redis 作为 broker， 你可以从这里去查看。

（4）、 排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted

Set） 也使得我们在执行这些操作的时候变的非常简单， Redis 只是正好提供了这两种数据

结构。 所以， 我们要从排序集合中获取到排名最靠前的 10 个用户–我们称之为

“user_scores”， 我们只需要像下面一样执行即可：

当然， 这是假定你是根据你用户的分数做递增的排序。 如果你想返回用户及用户的分数， 你

需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games 就是一个很好的例子， 用 Ruby 实现的， 它的排行榜就是使用 Redis 来存储

数据的， 你可以在这里看到。

（5）、 发布/订阅

最后 是 Redis 的发布/订阅功能。 发布/订阅的使用场景确实非

常多。 我已看见人们在社交网络连接中使用， 还可作为基于发布/订阅的脚本触发器， 甚至

用 Redis 的发布/订阅功能来建立聊天系统。

说说 Redis 哈希槽的概念？

Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念， Redis 集群有 16384 个哈希槽，

每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽， 集群的每个节点负责一部分

hash 槽

(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。

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

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