Redis 管理平台 Repoll 功能解读.docx

《Redis 管理平台 Repoll 功能解读.docx》由会员分享，可在线阅读，更多相关《Redis 管理平台 Repoll 功能解读.docx（9页珍藏版）》请在优知文库上搜索。

1、Repoll是仿照cachecloud的django版本Redis集中管理平台，目前刚开源起步。RediS标准申请流程标准化公司内部的redis资源申请流程，审批流中涉及提交和审批，工作流交给repoll平台和DBA处理或者所有了解redis的运维也可以。repoll平台也标准化了redis的配置、redis资源池的统一管理以及配置上线的过程。流程如图：8udbgv*,0Wto。AedktSn(WCIS。Regtil”D*三WftDAMIte餐例OlDRogEjttTItM0dtM三rtMPm*wbiRod*fiMfdk*u三ff0申请提交人可以是项目经理、开发人员、运维甚至是产品经理，看公司

2、组织设置。WWXQRoMOKM9RediS实例的申审批审批简单，选中申请中的实例点击，批准选择的Redis实例，即可同意审批,反之拒绝申请配置Redis资源池机器只有已经在redis资源池中的机器才能被配置使用。如后续DBA在批准redis实例在哪些机器上运行。配置实例上线在Redis上线配置中由DBA或者运维角色进行配置已批准的redis实例进行上线服务。按照既定的审批文本格式进行配置实例上线具体规则如下：1、StandaIOne类型：masterIp:masterPort:memSize(M)(例如：10.10.xx.xx2048)2、Sentinel类型:masterIp:masterP

3、ort:memSize(M):masterName:slaveIp:slavePortSentinelIplsentinellp2sentinellp3KirtaKMMnao三m已运行实例监控目前repoll的版本的只支持实例的QPS监控、启动和停止功能08MMg.B*K*MMMtBOKMMQfkSXRttMBS1*SA*RWteStaKdMmImaMVNfIX/0ISamMHl/，R/M已运行实例的展示172.20.10.9:8989O富BAPPl比OBtJ口读懂Redis缓存系统本文介绍了RediS缓存原理、详细解析了缓存模型、缓存一致性和缓存异常场景。尽管（关系型）数据库系统（SQ1.）

4、带来了许多出色的属性，例如ACID,但为了保持这些属性，数据库的性能在“3高”条件环境下下往往显得捉襟见肘、苍白无力。为了解决这个问题，我们往往需要在应用层（即处理业务逻辑的后端代码）和存储层（即SQ1.数据库）之间增加一个缓存层。该缓存层通常使用内存缓存来实现，毕竟，传统SQ1.数据库的性能瓶颈通常发生在二级存储（即硬盘）的I/O层面。随着主内存（RAM）的价格在过去十年中下降，故将（至少部分）数据存储在主内存中以提高性能便是一种性价比较高的解决方案。基于当前的技术发展现状，RediS便成为当下一种较为流行的选择。当然，大多数系统只将所谓的“热数据”存储在缓存层（即主内存）中。基于帕累托原理

5、（也称为80/20法则），对于大多数事件，大约80%的影响来自20%的原因。为了节省成本，我们只需要将这20%存储在缓存层中。为了识别“热数据”，我们可以指定驱逐策略（例如1.FU或1.RU）来确定哪些数据将过期。缓存概述缓存是一种“预热”技术，用于将经常访问的数据存储在临时存储器（称为缓存）中，以减少硬盘驱动器的读/写。缓存无处不在，基于此技术可以大大地提高Web应用程序的性能。通常，在最初的单体架构模型，当用户向我们的服务发送一个消息请求时，Web服务器首先会读取或写入数据库再返回响应。在缓存的情况下，服务器首先检查缓存副本是否存在，如果存在则从缓存返回数据而不是询问数据库。它节省了时间和

6、数据库的计算工作量。下面简要介绍一下应用程序如何请求Redis,此处主要基于Master-Slave-Sentinel模式的集群,App通过调用RediSClien3例如，Jedis1.ettuce及Redisson等来与RedisSentinel通信，当RediSMaSter切换至Slave时，Application依旧能够正常工作，如下为详细的时序图：缓存模型在分布式系统中，基于CAP定理指导，根据业务需求和上下文选择这些策略，通常可将其划分为常规模式和CaChe-Aside模式。在开始之前，让我们通过刷新缓存的方式来了解常用的缓存模式，具体如下所示：写模型1、WriteThrough:即

7、“直写”。此模型为同步写入数据库后再缓存。这是安全的，因为它首先写入数据库，但比后写慢。与写无效相比，它为先写后读场景提供了更好的性能。在这种写入策略中，数据首先写入缓存，然后写入数据库。缓存与数据库串联，写入总是通过缓存到主数据库。直写模式的算法是：1）对于不可变操作（读取）：此策略不处理不可变操作。它应该与通读模式相结合。2）对于可变操作（创建、更新、删除）：客户端只需要在RediS中创建、更新或删除条目。缓存层必须以原子方式将此更改同步到MySQ1.o直写模式的缺点也很明显。首先，许多缓存层本身并不支持这一点。其次，Redis是缓存而不是RDBMSo它的设计并非具有弹性。因此，更改在复制

8、到MySQ1.之前可能会丢失。即使Redis现在已经支持RDB和AOF等持久化技术,但仍然不推荐这种方式。就其本身而言，直写缓存似乎没有太大作用，实际上，它们会引入额外的写入延迟，因为数据先写入缓存，然后再写入主数据库。但是当与通读缓存配对时,我们可以获得通读的所有好处，并且我们还可以获得数据一致性保证，使我们免于使用缓存失效技术。DynamoDBAccelerator（DAX）是读取/写入缓存的一个很好的例子。它与DynamoDB和应用程序内联。可以通过DAX对DynamoDB进行读取和写入。2、WriteBehind:即“后写或回写”。基于此策略，应用程序将数据写入缓存,缓存会立即确认，并

9、在延迟一段时间后将数据写回数据库。这对于写入速度非常快，如果将同一键上的多个写入合并为一次对数据库的写入，则速度会更快。但是数据库长时间与缓存不一致，如果在数据刷新到数据库之前进程崩溃，可能会丢失数据。RAlD卡是这种模式的一个很好的例子，为了避免数据丢失，通常需要RAID卡上的电池备份单元将数据保存在缓存中，但尚未登陆到磁盘。AppUcadonQchcDacaRmcWriteBehind模式的算法是：1）对于不可变操作（读取）：此策略不处理不可变操作。它应该与通读模式相结合。2）对于可变操作（创建、更新、删除）：客户端只需要在RediS中创建、更新或删除条目。缓存层将更改保存到消息队列中并向

10、客户端返回成功。更改会异步复制到MySQ1.,并且可能在Redis向客户端发送成功响应后发生。后写模式与直写不同，因为它异步地将更改复制到MySQ1.。它提高了吞吐量，因为客户端不必等待复制发生。具有高持久性的消息队列可能是一种可能的实现。RediS流（自RediS5.0起受支持）可能是一个不错的选择。为了进一步提高性能，可以结合更改并批量更新MySQ1.（以节省查询次数）。WriteBehind模式的缺点是相似的。首先，许多缓存层本身并不支持这一点。其次，使用的消息队列必须是FIFO（先进先出）。否则，对MySQ1.的更新可能会乱序，因此最终结果可能不正确。回写缓存提高了写入性能,适用于写入

11、繁重的工作负载。与通读结合使用时它适用于混合工作负载，其中最近更新和访问的数据始终在缓存中可用。它对数据库故障具有弹性，并且可以容忍一些数据库停机时间。如果支持批处理或合并，它可以减少对数据库的总体写入，从而减少负载并降低成本，如果数据库提供程序按请求数量收费，例如动态数据库。请记住，DAX是直写的，因此如果应用程序写入繁重，则不会看到任何成本降低。一些开发人员将RediS用于缓存和回写，以更好地吸收峰值负载期间的峰值。主要缺点是如果缓存失败，数据可能会永久丢失。大多数关系数据库存储引擎（即InnoDB）在其内部默认启用回写缓存。查询首先写入内存并最终刷新到磁盘。3、Writeinvalida

12、te:类似于直写，先写入数据库，然后使缓存无效。在并发更新的情况下，这简化了缓存和数据库之间的一致性处理。我们不需要复杂的同步,权衡是命中率较低，因为我们总是使缓存无效并且下一次读取将始终未命中。读模型ReadThrough:即“通读1.当读取未命中时，需要从数据库中加载并保存到缓存中。这种模式的主要问题是基于某些特定的场景有时需要预热缓存。通读缓存与数据库保持一致。当缓存未命中时，它会从数据库中加载丢失的数据，填充缓存并将其返回给应用程序。通读模式的算法是：1、对于不可变操作（读取）：客户端将始终简单地从缓存中读取。缓存命中或缓存未命中对客户端是透明的。如果是缓存未命中，缓存应该具有自动从数

13、据库中获取的能力。2、对于可变操作（创建、更新、删除）：此策略不处理可变操作。它应该与直写（或后写）模式结合使用。通读模式的一个主要缺点是许多缓存层可能不支持它。例如，RediS将无法自动从MySQ1.获取（除非为RediS编写插件）。CaChe-ASide和Read-Through策略都是延迟加载数据，即仅在第一次读取时加载。其适用用例场景如下所示：虽然Read-Through和Cache-Aside非常相似，但至少有两个关键区别：在缓存侧，应用程序负责从数据库中获取数据并填充缓存。在通读中，此逻辑通常由库或独立缓存提供程序支持。与Cache-Aside不同，Read-ThroughCach

14、e中的数据模型不能与数据库的数据模型不同。当多次请求相同的数据时，通读缓存最适合读取繁重的工作负载。例如，一个新闻故事。缺点是当第一次请求数据时，总是会导致缓存未命中，并招致将数据加载到缓存中的额外惩罚。开发人员通过手动发出查询来“加热”或预热”缓存来处理这个问题。就像cache-aside一样，缓存和数据库之间的数据也有可能不一致，解决方法在于写入策略，我们将在下面看到。不读或不写模型Refreshahead:预测热点数据并自动刷新数据库中的缓存，永不阻塞读取，最适合小型只读数据集，例如邮政编码列表缓存，我们可以定期刷新整个缓存，因为它很小并且是只读的。如果能够可以准确地预测最常读取哪些键，

15、那么，还可以在此模式中预热这些键。最后，如果数据在系统之外更新而系统无法收到通知，可能必须使用此模式。在大多数场景下，我们通常使用通读和直写/后写/写无效等模型。针对RefreSh-ahead模型，其可以单独使用，也可以作为一种优化来预测和预热读取以进行通读。由谁负责缓存维护，调用者或专用层有两种实现模式。1、Cache-Facade：缓存层是一个库或服务委托写入数据库，我们只与缓存层交谈。然后数据库对我们的应用程序是透明的。缓存层可以处理一致性和故障转移。例如，许多数据库都有自己的缓存，这是缓存外观的一个很好的例子。我们还可以编写一些进程内DAO层来读取/写入具有嵌入式缓存层的实体，从调用者的角度来看，这个小层也是一个缓存门面。2、Cache-Aside:我们的应用程序保持缓存一致性，这意味着应用程序代码更复杂，但这提供了更大的灵活性。例如，像数据库查询缓存这样的缓存外观模式只能缓存行，如果想缓存带有行的JaVaPOJo或Kotlin数据类，则将缓存放在一边要容易得多。但是它仍然可以使用缓存门面，例如，将Spring缓存作为门面库来缓存PoJ0，并在后台自动处理数据库中的POJ0。当缓存不支持原生的读通和写通操作，并且资源需求不可预测时，我们使用这种缓存侧模