《Redis官方文档》 FAQ

原文地址 译者:zivyu

为什么Redis与其他的k-v存储相比不一样

有两个主要的原因

  • redis在键-值数据库中是一个不同的发展方向,值可以包含更复杂的数据类型,同时许多原子操作定义在这些数据类型上。redis的数据类型和基本数据结构密切相关,没有额外的抽象层,同样对于程序员也是直接可见的。
  • redis是一个在内存中但是可以持久化到磁盘上的数据库,所以它代表了一个不同的权衡,高速读写被实现,但是对数据集有限制,那就是不能大于内存的大小。在内存中的数据库还有另外的优点,内存中表示的复杂数据结构比一些在磁盘中的数据结构更容易操作,所以redis可以做很多操作而内部并不复杂。同时,两种磁盘存储格式(RDB和AOF)也不需要适合于随机存储。所以,数据是紧凑的,而且总是在末尾添加生成。

Redis的内存占用

下面给出一些例子:

  • 一个空的实例~1MB
  • 一百万个小的字符串key->value ~100MB
  • 一百万个哈希key->value,表示一个有五个字段的对象 ~ 200MB

测试你的用例是很简单的。使用redis-benchmark工具生成随机数据,然后使用Info memory检查空间使用。

当存储一些相同的key的时候,64位系统将比32位系统使用更多的内存,除非key和value很小。这是因为在64位系统使用8个字节的指针。当然,64位系统的优点是你可以拥有更多的内存,所以为了运行大型的redis服务,一个64位系统或多或少是需要的。还有一种选择是分片。

我喜欢redis的高级操作和特性,但是我不喜欢它在内存中做了所有的事情,并且我不能拥有比内存更大的数据集。怎么计划改变这点?

在过去,redis开发者尝试用虚拟内存和别的系统,为了允许比内存更大的数据集的使用。但是最终我们很乐意只做好一件事:内存用来数据服务,磁盘用来数据存储。所以现在还没有计划来创建一个对于redis的磁盘上的后端。毕竟,redis是它当前设计的直接结果。

你真正的问题不是总共的内存需要,事实上你需要把你的数据切分到多个redis实例中。,请阅读Partitioning page获取更多信息。

Redis和一个磁盘上的数据库一起使用是个好主意吗?

是的,一个通常的设计模式是把写非常密集的小数据放在redis中,大的二进制数据块放在SQL数据库或在磁盘数据库中保持最终一致。

我是否可以做些事情来降低Redis的内存使用?

如果可以的话,使用32位的Redis 实例。同样,使用小的哈希、列表、有序集和整数集也是很好的,因为Redis能够在一些元素的特殊情况下表示那些数据类型,以一种更加紧凑的方式。更多的信息请参考Memory Optimization page

如果Redis运行时内存不足会发生什么?

Redis要么被Linux kill,一个错误导致崩溃,要么就开始慢下来。现代操作系统的malloc()函数返回null是不常见的,通常服务开始调换,redis的性能开始降级,所以你可能会注意到有一些错误的事情。

INFO指令可以 报告redis正在使用的内存大小,所以你可以写个脚本通过检查一些临界条件来监视你的redis服务。

Redis有一个保护措施允许使用者设置一个内存使用的最大限度,在配置文件里使用maxmemory选项来设置一个Redis可以使用的内存限制。如果限制达到,redis将回复写命令一个错误(但是仍然可以继续接受只读命令),或者当你使用redis作为缓存的情况下,当最大内存限制达到的时候,你可以配置redis来丢弃某些key值。

可以参考Redis as an LRU cache

在Linux下后台存储失败且有一个fork()错误,虽然我有许多空闲内存

简短的回答:echo 1 > /proc/sys/vm/overcommit_memory

下面开始更长的答案:

Redis在后台的存储机制依赖于操作系统中fork的copy-on-write:也就是redis fork(创建一个子进程)是父进程的一个完整精确拷贝。子进程转储到磁盘上的数据库然后退出。理论上来说,子进程作为一个副本应该使用和父亲一样多的内存,但是实际上由于大部分现代操作系统的copy-on-write的实现,父进程和子进程将共享内存页。当他被父进程或者子进程改变的时候,一个内存页将被复制。因此,从理论上讲,当子进程存储的时候,所有内存页可能被改变,Linux不能提前告诉子进程多少内存被使用,所以如果overcommit_memory设置被设置为0,创建将会失败,除非有同样多的空闲内存。结果是,如果你有3GB的redis数据并且只有2GB的空闲内存,它将会失败。

把overcommit_memory设置为1来告诉Linux以更加乐观的方式来执行fork操作,并且这确实是你想要的。

Redis的磁盘快照是原子的吗?

是的,redis的后台存储进程总是被fork当服务没有执行执行的时候,所以内存中每个成为一个原子的指令从查看磁盘快照来说也是原子的。

Redis是单进程的,我怎么利用多CPU?

Redis中CPU成为你的瓶颈是非常不可能的,通常redis要么是内存要么就是网络绑定。例如,在一台普通的Linux系统上使用流水线redis每秒可以传输500k的请求,所以如果你的应用主要使用O(N) 或 O(log(N))的指令,很难使用太多的 CPU。

然而,为了CPU使用率最大化,你可以在同一个机器上启动多个redis实例,并把它们当作不同的服务对待。在有些时刻,单个机器可能还不够,所以如果你想使用多个CPU你可以开始思考一些方式去更早的碎片化。

使用多个redis实例请参考Partitioning page

单个redis能持有的key的最大数量是多少?一个哈希表、列表、集合 、有序集合中元素的最大数量呢?

Redis可以处理2^32个key,在实际的测试中,单个实例至少处理2.5亿 个key。

每个哈希表、列表、集合、有序集合能持有 2^32个元素。

换句话说,你的限制可能就是你系统的可用内存。

我的从节点与主节点相比,有不同数量的key。为什么?

如果你使用有限制时间的key,这是正常的情况。下面是发生了什么:

  • 在从节点第一次同步的时候,主节点生成一个RDB文件。
  • 这个RDB文件不包括在主节点中已经过期的key。但是这些key仍然在内存中。
  • 然而这些key仍然在主节点Redis的内存中,即使已经过期了。它们被考虑为不存在,但是内存不久之后将被回收。然而这些key不是数据集的一部分,在INFO中和使用DBSIZE指令被广告。
  • 当从节点读取主节点生成的RDB文件,这些key将不会被load。

作为结果,使用者有许多设置了有效期的key在从节点中看着少很多是很常见的,但是在实例中并没有什么实际的影响。

Redis的真正意思?

它的意思是REmote DIctionary Server。

为什么要开始Redis项目?

最初,redis为了衡量LLOOGG。但是当我完成基本的服务工作,我有了一个把它分享给其他人的想法,然后redis就变成了一个开源的项目。 

时间: 2024-12-30 14:22:31

《Redis官方文档》 FAQ的相关文章

mysql 5 mysql 5 技术内幕

mysql 5 mysql 5 技术内幕: http://www.kitebird.com/mysql-book/4ed.php

Flash鼠绘技术内幕完全接触

1.鼠绘技术内幕完全接触-概述篇 [2005-02-27]     2.鼠绘技术内幕完全接触-动物篇 [2005-02-27]     3.鼠绘技术内幕完全接触-环境背景篇 [2005-02-27]     4.鼠绘技术内幕完全接触--效果篇 [2005-02-27]     5.鼠绘技术内幕完全接触-植物篇 [2005-02-27]

鼠绘技术内幕完全接触-动物篇

动物是生态世界中重要的组成部分,在卡通绘画中,动物也是重要的组成部分,动物的千姿百态被设计师们充分的发挥利用,并注入了人类的思想感情,使得动物也变得和人一样感情丰富,幽默风趣.而且,在卡通的世界里,动物过着人一样的生活,和人一样也有忠奸善恶.喜怒哀乐,让原本有趣的卡通世界更加丰富多彩. 在讲述鼠绘动物技术内幕之前,先教大家几个学习动物鼠绘的方法: 集思广益:在动画世界里,动物占有相当大的比例,所以这方面成功的例子很多,大家可以收集并分析;了角同一种动物的不同种表现方法,以便更好的掌握它的形象特征

.NET编译技术内幕(2)

编译 .NET编译技术内幕(2)作者: builder.comTuesday, April 16 2002 12:23 PM 作为一种代码指令平台,Microsoft .NET比微软公司先前推出的其他技术平台要来得更为复杂.由于.NET提供了对多种编程语言以及(在理论上说)多重平台的支持,这就需要在传统的两个代码层添加一个中间代码层.在这里,传统的两层分别是源代码层和编译后的本机代码层.新加的代码层给.NET平台带来了额外的灵活性,不过,反过来却又增加了系统的复杂性.此外,由于这一新代码层的出现

WCF技术内幕

<WCF技术内幕>39:第2部分_第7章_通道管理器:通道工厂和本章 <WCF技术内幕>38:第2部分_第7章_通道管理器:通道侦听器 <WCF技术内幕>37:第2部分_第7章_通道管理器:概述和通道管理 <WCF技术内幕>36:第2部分_第6章_通道:创建自定义通道和本章 <WCF技术内幕>35:第2部分_第6章_通道:通道功能 <WCF技术内幕>34:第2部分_第6章_通道:通道接口和基本类型 <WCF技术内幕>33:

《WCF技术内幕》26

<WCF技术内幕>26:第2部分_第5章_消息:Buffered vs Streamed.序列化和反序列化消息 Buffered vs. Streamed消息 当我们在终结点之间流动的消息时,我们会本能地想到缓存.换个方式来说 ,我们假设程序接收到一个Message时,它已经知道整个Message.这种方式称作 缓存模式(buffering).与之相对的就是流处理模式(streaming),并且有2种 流处理模式(streaming).第一种是推模型(push model),发送者按照自己 的

《WCF技术内幕》23

<WCF技术内幕>23:第2部分_第5章_消息:XmlDictionaryReader和回到Message XmlDictionaryReader类型 XmlDictionaryReader抽象类型继承自System.Xml.XmlReader,因此继承了很 多XmlReader的特性.和XmlReader 一样,XmlDictionaryReader定义了几个工厂 方法,他们返回的是XmlDictionaryReader的子类型的实例.更确切地说, XmlDictionaryReader包装

《WCF技术内幕》翻译15:第1部分_第3章_消息交换模式、拓扑与编排:消息拓扑

<WCF技术内幕>翻译15:第1部分_第3章_消息交换模式.拓扑与编排:消息拓扑.消息编排和本章小结 消息拓扑 消息拓扑描述的是在一个或多个发送者和接受者之间消息如何发送的.消息拓扑可以描述简单的应用-应用的连接关系,但是它同样可以描述复杂的应用-企业的连接.在后续文章里,面向服务的应用的作用会显现出来.概括地说,这些可能存在的拓扑结构比面向组件的应用系统能够涉及到的情况会更加多.更加复杂. 某种层次上,一个消息拓扑是一个或者多个消息交换模式(MEP)的组合.实际上可能存在有无数种拓扑结构,但

《WCF技术内幕》翻译14:第1部分_第3章_消息交换模式、拓扑与编排…

<WCF技术内幕>翻译14:第1部分_第3章_消息交换模式.拓扑与编排:消息交换模式(MEP) 第3章:消息交换模式.拓扑和编排 当设计消息应用系统的时候,有必要考虑一下消息是怎样在发送者.中介者 和接受者(前面章节介绍了这些消息参与者)流转的.系统中消息交换可能性的 波动的值可以被不同程度地详细描述.这些不同级别的细节就是总所周知的消息 交换模式(MEPS).消息拓扑和消息编排[老徐备注1].当从总体来看时,这 三个级别的细节让我们抽象地描述任何消息场景.本章会详细剖析消息交换模式 (MEP

《WCF技术内幕》翻译6:第1部分_第2章_面向服务:概述、快速定义…

<WCF技术内幕>翻译6:第1部分_第2章_面向服务:概述.快速定义面向服务.理解消息 概述 互联网上充斥着面向服务(SO)的对话,大部分会话都是抽象地描述为面向 服务.这一章我们会一些不同的方法.下面一些章页,我们会站在需求的角度看 一下面向服务.更具体地说,我们将看一下一般的消息应用和需要什么才能使他 们运转.通过这个过程,我们将发掘几个理解面向服务必需的几个概念.本章的 最后几段会给出面向服务的比较正式的定义,并且会讨论一下为什么当今世界里 面向服务对于分布式计算意义重大. 如果你问10