《Redis官方教程》-FAQ

原文链接   译者:Alexandar Mahone  校对:方腾飞(红体标记重点)

为什么Redis不同于其他的键值存储数据库?

有两个主要原因:

  • Redis发展方向不同与其他键值数据库,它能包含很多复杂数据类型,对这些数据类型操作都是原子的。Redis数据类型与基本数据结构强相关,直接暴露给程序员,没有增加抽象层。
  • Redis是一个内存数据库,而不是持久化在硬盘数据库中,因此为了实现高速读写,数据集大小不能超过内存。内存数据库另一个优点是,内存数据库相对于硬盘数据库非常容易操作复杂数据结构,因此Redis的可以做很多事情,很少有内部的复杂性。与此同时两款磁盘存储格式(RDB和AOF)不需要支持随机访问,因此他们是紧凑的,而且总是以追加形式生成(甚至AOF日志轮换也是一个追加操作,因为新版本是由内存中的副本生成)。


Redis内存使用情况?

举几个例子(所有数据基于64位实例)

  • 一个空实例大约占用1M内存
  • 1百万简单字符串键值对大约占用100M内存
  • 1百万哈希表键值对,每个对象有5个属性,大约占用200M内存

为了测试你的用例,使用redis-benchmark工具生成随机数据集,使用INFO memory命令检查使用内存空间。

存储相同的键,64位系统比32位系统使用更多的内存,键值很小情况下更明显。这是因为64位系统指针占用8字节。但是64位系统优点是可以配置更多内存(校对注:32位操作系统支持的内存最多为2的32次方,就是4G),因此为了运行大型Redis服务器,64位系统或多或少都是需要的。另一种方案是使用分片。



我喜欢Redis的高性能操作和特性,但是不喜欢所有内容都在内存中,我不能创建一个比内存更大数据集。有计划改变吗?

过去为了允许数据集超过RAM大小,Redis开发人员尝试使用虚拟内存和其他系统,但是我们非常高兴可以把一件事情做好:数据服务由内存提供,磁盘用于存储数据。所以现在没有计划为Redis创建磁盘后端,毕竟Redis大部分特性都是基于其当前架构设计的。

你的真正问题并不是所需的总内存,而是你需要划分你的数据集到多个Redis实例上,为了获取更多信息请阅读本文档中的分区页面



同时使用Redis和磁盘数据库,是不是一个好想法?

是的,一个通用的设计方案是,在非常频繁的写小的数据时采用Redis(并且你需要使用Redis数据结构给你的问题建立高效模型),以及将大数据存储到SQL数据库或者最终一致性磁盘数据库中。



有没有方法降低Redis内存使用率?

如果可以的话使用Redis 32位实例。另外,还要善于使用哈希表,列表,有序集合和整数集,因为在特殊情况下Redis使用这些数据类型可以更紧凑存储一些元素。可以在内存优化页面获取更多信息。



Redis内存不足时会发生什么?

Redis要么被Linux内核OOM杀掉,抛出错误崩溃,要么开始变得卡顿。随着现代操作系统malloc方法通常都不返回NULL,而是服务器开始交换,因此Redis性能降低,因此你可能会观察到一些错误现象。

INFO命令返回Redis使用内存总量,因此你可以编写脚本监控Redis服务器内存临界值。

Redis内置保护措施允许用户在配置文件中使用maxmemory选项,设置Redis最大占用内存。如果达到此限制,Redis将开始返回错误给写命令(但是将继续接受只读命令),或者当最大内存限制达到时也可以配置为驱逐键,在这种情况下Redis作为缓存使用。

我们有文档描述Redis作为LRU缓存使用



在Linux系统中,即使我有很多空闲内存,后台保存失败报fork错误!

精辟答案:echo 1 > /proc/sys/vm/overcommit_memory

详细回答:

Redis后台保存模式依赖现代操作系统的写时拷贝技术。Redis fork(创建一个子进程)是父进程精确拷贝。子进程存储数据到磁盘并且最终退出。从理论上讲,子进程应该和父进程使用同样多内存,作为父进程副本,但是得益于多数现代操作系统实现的写时复制技术,父进程和子进程共享内存页。内存页在父进程或子进程改变时将被复制。当子进程保存时,理论上所有页面都可能改变,Linux无法提前告知子进程需要多少内存,因此如果overcommit_memory设置为0,fork将会失败除非有足够的空闲RAM真正复制父进程内存页.结果是,如果你有3G Redis数据集,只有2G可用内存将会失败。

overcommit_memory设置为1,意味着Linux 使用更乐观方式fork,这确实是你所期望的Redis。

理解虚拟机内存 (校对注:有兴趣可以翻译此文在并发网发表)”是红帽经典文章,可以了解Linux虚拟内存怎么工作,overcommit_memory和overcommit_ratio的替代品。这篇文章校正了proc(5)用户手册对overcommit_memory1和2配置正确含义。



Redis磁盘快照是不是原子操作?

是的,当服务器不在执行命令时,Redis后台保存进程总是被创建,因此每个命令在RAM中是原子的,并且在磁盘快照过程也是原子的。



Redis是单线程的,我怎么利用多CPU/核?

CPU基本不可能成为的Redis的瓶颈,因为通常Redis受限于内存或网络。例如使用Pipelining,Redis运行在普通的Linux系统上,每秒可以处理50万请求,所以如果你的应用程序主要使用O(N) 或者 O(log(N))命令,几乎不会使用太多的CPU。

然而为了最大限度利用CPU,你可以在一台机器上启动多个Redis实例,并把它们设置为不同服务器。某些时候单个机器是不够的,所以如果你想使用多个CPU,你可以提前考虑使用分片。

关于使用多Redis实例,你可以在Partitioning page找到更多的信息



单个Redis实例最多可以存储多少键?哈希表、列表、集合和有序集合最大可以包含多少元素?

Redis最大可以处理2^32键,实践测试每个实例最少可以处理2.5亿键。

每个哈希表、列表、集合和有序集合可以容纳2^32元素。

换句话说,Redis极限容量就是系统可用内存。



为什么我的从实例与主实例拥有不同数量键?

如果你使用有生存周期的键,这就是正常现象。这就导致主从实例键的数量不一致原因。

  • 主实例在第一次与从实例同步时生成RDB文件。
  • RDB文件不包含已经过期的键,但是已经过期的键仍然在内存中。
  • 尽管这些键从逻辑上说已经过期失效,但是还在Redis主实例内存中,他们并不被识别为存在的,当增量或访问这些键时这些键会被回收。尽管从逻辑上说这些键不是数据集一部分,但是INFO和DBSIZE命令结果包含这些信息。
  • 当从实例读取主实例生成的RDB文件时,过期键不会被载入。

为很多键设置过期属性,通常为用户提供了在从实例上存储更少键,但是实际上实例内容没有逻辑区别。



Redis实际含义是什么?

Redis是远程数据字典服务器(REmote DIctionary Server)。



你为什么启动Redis项目?

最初启动Redis,是为了扩大LLOOGG。但是当我完成了基本服务端工作后,我喜欢把这个想法分享给其他人,然后Redis转变成开源项目。 

时间: 2024-11-03 06:13:20

《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