英语原文共 22 页，剩余内容已隐藏，支付完成后下载完整资料
了解Redis最重要的5个性能指标
一、介绍
以往的网站主要是用关系型的内容填充静态页面数据库。当今的网站是几乎都是实时交互和低延迟。对实时性的需求和计算机体系结构的限制决定了需要把内存中的数据存储在现代应用程序的中心。
当你需要低延迟、持久、跨平台的存储时，没有比Redis更好的选择。Redis的流行源于它丰富的API，以及拥有在提供低延迟的同时提供持久性的优势，通常使用于传统的关系数据库。Redis有很多杰出的用户，包括Yahoo！,Twitter、Craigslist、Stack Overflow和Flickr。
本指南的目的是解释以下五个最重要的指标，以便你更有效地使用Redis。了解这些指标将有助于常见问题的疑难解答。在本指南中，您将了解这些指标是什么，如何访问它们，如何解释它们的输出，以及如何使用它们来改进你的Redis表现。
前几页描述了什么是Redis，为什么开发人员使用它，以及共同的选择。你可以从第七页开始直接阅读Redis最重要的5个性能指标。
二、Redis：一个快速、易用的键值（Key-Value）存储
Redis是一个开源的，用于内存的高级分布式存储系统，具有对磁盘的持久性。Redis的两种常见用法是caching2和publish-shy;subscribe队列(Pub /Sub)3。当用户登录到web应用程序时， Redis允许开发人员将用户属性存储在内存中，而不是必须每次需要用户信息时查询数据库，实现更快的数据检索。对于Pub/Sub，Redis提供了一些原语以便轻松实现发布-订阅消息模型。
键值存储：更快，更小的NoSQL数据库
键值数据由两个对象组成：1）代表键的字符串和2）与该键关联的实际数据。 例如，您可以将键值“lastname_2078”改为键值“ Miller”或键值“ boroughs_of_new_york”
其值应为“bronx, brooklyn, manhattan, queens, staten_island”。键值存储已在短时间内成为快速获得应用程序的关键，消除了对精心设计的结构化数据的先期需求表。
Redis：具有传统数据库持久性的快速缓存
Redis的流行源于它的速度，丰富的语义和稳定性。Redis比其他无架构NoSQL数据库（例如MongoDB）要快，并且被设计用作记录系统，而不是简单易失的缓存。尽管作为内存中的数据存储，Redis可以将其数据持久存储到磁盘上以实现持久性。
持久性是进程在关闭后恢复其状态的能力。存储在内存中的数据在服务器关闭后无法保存。Redis体系结构的真正意义在于，它能够提供可预测、低延迟和与传统的以磁盘为中心的数据库一样丰富的API。由于内存访问比磁盘访问快（0.1mu;s vs. 10 ms），因此与以磁盘为中心的数据库相比，Redis的性能非常好。
除了高性能之外，Redis还为您提供了两种选择来持久地存储其数据：（1）是否使用快照（2）使用只追加文件。
Redis快照是内存中数据的即时点图像。Redis不会先将所有更改写入磁盘，而是会在内存中创建自己的副本（使用fork），以便可以将副本尽快保存到磁盘。从上次到现在成功快照之间修改的数据始终会受到威胁，因此，如果磁盘足够快，建议运行频繁的快照。 最佳频率取决于您的应用；设置该参数时首先要问自己的问题是，如果应用程序丢失了那条高风险数据，将遭受多少损失。
Redis还提供了仅附加文件（AOF）作为更可靠的持久性模式。使用AOF，对内存中的数据集所做的所有更改也会写入磁盘。通过详细的磁盘配置，此机制可确保将所有过去的写入都保存到磁盘上。但是，较高频率的磁盘写入将对性能造成重大负面影响。在AOF，快照和在没有持久性的情况下使用Redis三者间，需要在发生崩溃的情况下100％的数据完整性与系统运行时的运行速度两者间进行权衡。
Redis不仅仅存储字符串
Redis不同于许多基本的键值存储，因为它可以存储多种数据类型。支持的数据类型包括：
bull;字符串：字符序列
bull;字符串列表：按插入时间排序的字符串的有序集合
bull;集合：非hellip;重复的无序字符串集合
bull;排序集：按用户定义的值排序的字符串的非重复排序集合
bull;散列：映射字符串字段和字符串值的关联数组
Redis散列特别有用，因为小散列（少于100个字段）是以非常节省内存的方式编码的。因此，散列字段是在一个键中表示对象的多个数据字段的有效方法。例如，如果你使用Redis作为web缓存来存储有关站点访问者的信息，则使用一个键将给定用户的所有属性存储在散列中会更有效。各种属性（用户名、电子邮件、帐户类型）将存储在同一散列的不同字段中。
Redis扩展简单
由于其键值数据模型，Redis数据库很适合分区，你可以在多个Redis实例上拆分键控数据，每个实例都包含一个子集。通过分区，在内存方面，使用Redis可以存储比你最大的服务器容纳的数据更多的数据。
最后，Redis协议简单且一致。几乎每种编程语言都有一个使用Redis的库。这意味着Redis可以用作整个基础设施中的通用数据存储，而不用担心将自己锁定在特定的堆栈中。
三、Redis备选方案
对于Redis解决的问题，有其他解决方案，但是在Redis提供的独特功能组合中，没有一个完全重叠。 诸如Memcached之类的多线程缓存系统替代方案不会持久保存到磁盘，并且通常仅支持将字符串数据类型作为值。 更多功能丰富的数据库替代方案（例如MongoDB）通常会占用更多资源。 下面提供了有关这些差异的其他详细信息。
Memcached
Memcached是一种开源的内存中多线程键值存储，通常用作高速缓存来加速动态Web应用程序。 如果不需要持久性，而您只存储字符串，则Memcached是一种简单而强大的缓存工具。 如果您的数据受益于更丰富的数据结构，则使用Redis将使您受益。 在性能方面，根据特定的用例，Memcached的性能可能比Redis更好或更差。
MongoDB
MongoDB是一个开源的NoSQL数据库，它支持更丰富的数据类型。它是最流行的NoSQL数据库。从关系数据库中，它借用了运行相对复杂的查询的能力，而不必担心（太多）数据库将采用哪种路径来访问数据。
四、如何查询Redis指标
要分析以下描述的Redis指标，您将需要访问实际数据。可通过Redis命令行界面（redis-cli）访问Redis指标。使用info命令可打印有关Redis服务器的信息和指标。
info命令的输出分为10个部分：
bull; server
bull; clients
bull; memory
bull; persistence
bull; stats
bull; replication
bull; cpu
bull; commandstats
bull; cluster
bull; keyspace
本指南将涵盖“内存和统计信息”部分中的重要指标。
请注意，info不提供任何延迟度量。 我们还将讨论如何获取这些特定指标。
如果您只想查看与特定部分相关的信息，只需将相关部分的标题作为参数添加到info命令中。例如，命令info memory将仅返回与内存有关的统计信息。
五、了解Redis最重要的5个性能指标
为了帮助您快速发现并解决问题，我们选择了五个指标来报告我们遇到的最常见的Redis性能问题。具体如下。
- 内存使用：used_memory
used_memory指标报告Redis分配的字节总数。 used_memory_human指标以更易读的格式提供相同的值。
这些指标反映了Redis请求存储您的数据的内存量以及需要运行的支持元数据。由于内存分配器与操作系统进行交互的方式，因此这些指标无法解决内存碎片导致的浪费。 换句话说，在此报告的内存量指标几乎总是与操作系统已分配的Redis内存总量不同。
解释内存使用情况：检测由于内存交换而导致的性能问题
内存使用率是Redis性能的关键组成部分。 如果实例超出可用内存（used_memorygt;总可用内存），则操作系统将开始交换，并且内存的旧/未使用部分（称为页面）将被写入磁盘，以便为更新/活动页面腾出空间。 从磁盘写入或读取比从内存写入或读取最多慢5个数量级（内存为0.1mu;s，磁盘为10 ms）。 如果Redis进程发生交换，它将严重影响其性能以及所有依赖Redis数据的应用程序的性能。 通过显示Redis使用了多少内存，used_memory指标将有助于确定实例是否有开始交换的风险或是否已经在交换数据。
跟踪内存使用情况以解决性能问题
如果您使用的是没有定期快照的Redis，则您的实例不仅有在关闭时丢失其数据的风险，而且还存在内存使用量超过可用内存总量的95％时被部分换入和换出的风险。
启用快照需要Redis在将当前数据集复制到磁盘之前在内存中创建一个副本。 因此，启用快照时，如果您使用的可用内存超过45％，则内存交换会变得很有风险。 如果对您的Redis实例进行更频繁的更新，这可能会进一步加剧。 您可以使用以下技巧来减少Redis的内存占用量，从而降低交换风险：
- 如果您的数据小于4GB，请使用32位Redis实例
- 尽可能使用哈希
- 设置密钥的到期时间
- 驱逐键：您可以在Redis配置文件（通常称为redis.conf）中进行设置，通过设置“maxmemory”选项并重新启动实例，可以限制Redis的内存使用。
您还必须选择在达到最大内存限制时如何选择退出键。 该设置redis.conf文件中称为“maxmemory-policy”。 如果您有效地使用了密钥，那么“volatile-ttl”策略将是一个不错的选择。 如果密钥没有足够快地或根本没有过期，则“allkeys-lru”将允许您删除最近未使用过的密钥，而不管其过期状态如何。 其他模式如下所述。
通过将“最大内存”设置为可用内存的45％或95％（取决于您的持久性策略），并为驱逐策略选择“ volatile-ttl”或“ allkeys-lru”（取决于您的到期过程），可以严格限制 Redis内存使用情况，在大多数情况下，以类似于缓存的方式使用Redis，以确保不进行内存交换。 仅当您无法承担丢失内存限制的键时，非逐出模式才有意义。
- 处理的命令数：total_commands_processed
total_commands_processed指标提供了Redis服务器处理的命令数。 命令来自连接到Redis服务器的一个或多个客户端。 每次Redis服务器完成来自客户端的140多种可能命令中的任何命令时，total_commands_processed都会增加。 例如，如果Redis服务器完成来自client_x的两个命令和来自client_y的三个命令，则总命令度量将增加五倍。
解释已处理的命令数：诊断延迟增加
跟踪已处理命令的数量对于诊断Redis实例中的延迟问题至关重要。 由于Redis是单线程的，因此命令请求将按顺序处理。 1Gb / s网络的典型延迟约为200mu;s，如果您看到命令的响应时间很慢并且延迟显着高于200mu;s，则可能是因为命令队列中有大量请求。
在这种情况下，您会看到响应速度慢，并且处理的命令总数激增。 相反，如果慢速和增加的延迟是由一个或多个慢速命令引起的，则随着Redis性能下降，您将看到总命令指标下降或完全停止。 诊断这些问题要求您跟踪命令的数量和时延。
例如，您可以设置一个脚本，该脚本定期记录total_commands_processed指标并测量延迟。 然后，您可以使用此历史命令量日志来确定在观察到响应时间变慢时处理的命令总数是增加还是减少。
使用处理的命令数量来解决延迟增加
如果您发现与历史规范相比，已处理的命令总数有所增加或减少，则可能是命令数量过多（队列中有更多命令）或一些缓慢的命令阻塞了系统的迹象。 以下是三种方法来解决由命令量大和命令慢引起的延迟问题：
1.使用多参数命令：如果Redis客户端在短时间内向Redis服务器发送大量命令，您可能会看到响应时间很慢，这仅仅是因为后面的命令在队列中等待大量的前面的命令完成。 改善延迟的一种方法是通过使用接受多个参数的Redis命令来减少总体命令量。 例如，您无需使用循环和Redis命令LSET的
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[236345]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
