《终章》后端分布式多级缓存架构，也许你一直考虑的太简单了

这篇想聊的话题是:分布式多级缓存架构的终章，如何解决大流量、高并发这样的业务场景，取决于你能不能成为这个领域金字塔上层的高手? 能不能把这个问题思考清楚决定了你的成长速度。

不少人在一个行业5年、10年，依然未达到这个行业的中层甚至还停留在底层，由于他们历来不关心这样的话题。做为砥砺前行的践行者，我以为有必要给你们来分享一下。

开篇

服务端缓存是整个缓存体系中的重头戏，从开始的网站架构演进中，想必你已看到服务端缓存在系统性能的重要性。

但数据库确是整个系统中的“半吊子|慢性子”，有时数据库调优却可以以小搏大，在不改变架构和代码逻辑的前提下，缓存参数的调整每每是条捷径。

在系统开发的过程当中，可直接在平台侧使用缓存框架，当缓存框架没法知足系统对性能的要求时，就须要在应用层自主开发应用级缓存。

缓存经常使用的就是Redis这东西，那到底什么是平台级、应用级缓存呢？

后面给你们揭晓。但有一点可代表，平台级就是你所选择什么开发语言来实现缓存，而应用级缓存，则是经过应用程序来达到目的。

01数据库缓存

为什么说数据库是“慢性子”呢？ 对如今喜欢 快的你来讲，慢是解决不了问题的。就好像总感受感受妹子回复慢

由于数据库属于IO密集型应用，主要负责数据的管理及存储。数据一多查询自己就有可能变慢， 这也是为啥数据上得了台面时，查询爱用索引提速的缘由。固然数据库自身也有“缓存”来解决这个问题。

数据多了查询不该该都慢吗？ 小白说吒吒辉你不懂额

。。。这个，你说的也不全是，还得分状况。例如：数据有上亿行

缘由：

1. 由于简单的SQL的结果不会特别多。你请求也不大，磁盘跟的上
2. 并发总量超过磁盘吞吐上限，是谁都没招

就算大家不喜欢吒吒辉，我也要奋笔疾书

数据库缓存是自身一类特殊的缓存机制。大多数数据库不须要配置就能够快速运行，但并无为特定的需求进行优化。在数据库调优的时候，缓存优化你能够考虑下。

以MySQL为例，MySQL中使用了查询缓冲机制，将SELECT语句和查询结果存放在缓冲区中，以键值对的形式存储。之后对于一样的SELECT语句，将直接从缓冲区中读取结果，以节省查询时间，提升了SQL查询的效率。

1.1.MySQL查询缓存

Query cache做用于整个MySQL实例，主要用于缓存MySQL中的ResultSet，也就是一条SQL语句执行的结果集，因此它只针对select语句。

当打开 Query Cache 功能，MySQL在接收到一条select语句的请求后，若是该语句知足Query Cache的条件，MySQL会直接根据预先设定好的HASH算法将接收到的select语句以字符串方式进行 hash，而后到Query Cache中直接查找是否已经缓存。

若是结果集已经在缓存中，该select请求就会直接将数据返回，从而省略后面全部的步骤（如SQL语句的解析，优化器优化以及向存储引擎请求数据等），从而极大地提升了性能。

固然，若数据变化很是频繁的状况下，使用Query Cache可能会得不偿失。

这是为啥，用它不是提速吗？咋还得不偿失

由于MySQL只要涉及到数据更改，就会从新维护缓存。

1. 若是SQL请求量比较大，你在维护的时候，就透过缓存走磁盘检索。这样数据库的压力确定大。
2. 重建缓存数据，它须要mysql后台线程来工做。也会增长数据库的负载。

因此在MySQL8已经取消了它。 故通常在读多写少，数据不怎么变化的场景可用它，例如：博客

Query Cache使用须要多个参数配合，其中最为关键的是query_cache_size和query_cache_type， 前者用于设置缓存ResultSet的内存大小，后者设置在何种场景下使用Query Cache。

这样能够经过计算Query Cache的命中率来进行调整缓存大小。

1.2.检验Query Cache的合理性

检查Query Cache设置的是否合理，能够经过在MySQL控制台执行如下命令观察：

• SHOW VARIABLES LIKE '%query_cache%';

• SHOW STATUS LIKE 'Qcache%'; 经过检查如下几个参数能够知道query_cache_size设置得是否合理：

  • Qcache_inserts：表示Cache多少次未命中而后插入到缓存
  • Qcache_hits: 表示命中多少次，它可反映出缓存的使用效果。

若是Qcache_hits的值很是大，则代表查询缓冲使用很是频繁，若是该值较小反而会影响效率，那么能够考虑不用查询缓存；

• Qcache_lowmem_prunes: 表示多少条Query由于内存不足而被清除出Query_Cache。

若是Qcache_lowmem_prunes的值很是大，则代表常常出现缓冲不够的状况，因增长缓存容量。

• Qcache_free_blocks： 表示缓存区的碎片

Qcache_free_blocks值很是大，则代表缓存区中的碎片不少，可能须要寻找合适的机会进行整理。

经过 Qcache_hits 和 Qcache_inserts 两个参数能够算出Query Cache的命中率：

经过 Qcache_lowmem_prunes 和 Qcache_free_memory 相互结合，能更清楚地了解到系统中Query Cache的内存大小是否真的足够，是否频繁的出现因内存不足而有Query被换出的状况。

1.3.InnoDB的缓存性能

当选择 InnoDB 时，innodb_buffer_pool_size 参数多是影响性能的最为关键的一个参数，它用来设置缓存InnoDB索引及数据块、自适应HASH、写缓冲等内存区域大小，更像是Oracle数据库的 db_cache_size。

简单来讲，当操做InnoDB表的时候，返回的全部数据或者查询过程当中用到的任何一个索引块，都会在这个内存区域中去查询一遍。

和MyISAM引擎中的 key_buffer_size 同样，innodb_buffer_pool_size设置了 InnoDB 引擎需求最大的一块内存区域，直接关系到InnoDB存储引擎的性能，因此若是有足够的内存，尽可将该参数设置到足够大，将尽量多的InnoDB的索引及数据都放入到该缓存区域中，直至所有。

说到缓存确定少不了，缓存命中率。那innodb该如何计算？

计算出缓存命中率后，在根据命中率来对
`
innodb_buffer_pool_size 参数大小进行优化`

除开查询缓存。数据库查询的性能也与MySQL的链接数有关

table_cache 用于设置 table 高速缓存的数量。

show global status like 'open%_tables'; # 查看参数

因为每一个客户端链接都会至少访问一个表，所以该参数与max_connections有关。当某一链接访问一个表时，MySQL会检查当前已缓存表的数量。

若是该表已经在缓存中打开，则会直接访问缓存中的表以加快查询速度；若是该表未被缓存，则会将当前的表添加进缓存在进行查询。

在执行缓存操做以前，table_cache参数用于限制缓存表的最大数目：

若是当前已经缓存的表未达到table_cache数目，则会将新表添加进来；若已经达到此值，MySQL将根据缓存表的最后查询时间、查询率等规则释放以前的缓存。

02平台级缓存

什么是平台级缓存，说的这个玄乎？

平台级缓存是指你所用什么开发语言，具体选择的是那个平台，毕竟缓存自己就是提供给上层调用。主要针对带有缓存特性的应用框架，或者可用于缓存功能的专用库。

如：

• PHP中的Smarty模板库
• Java中，缓存框架更多，如Ehcache，Cacheonix，Voldemort，JBoss Cache，OSCache等等。

Ehcache是如今最流行的纯Java开源缓存框架，配置简单、结构清晰、功能强大，是从hibernate的缓存开始被普遍使用起来的。EhCache有以下特色：

Ehcache的系统结构如图所示:

什么是分布式缓存呢？好像我还没搞明白，小吒哥

首先得看看恒古不变的“分布式”，即它是独立的部署到多个服务节点上或者独立的进程，彼此之间仅仅经过消息传递进行通讯和协调。

也就是说分布式缓存，它要么是在单机上有多个实例，要么就独立的部署到不一样服务器，从而把缓存分散到各处

最后经过客户端链接到对应的节点来进行缓存操做。

Voldemort是一款基于Java开发的分布式键-值缓存系统，像JBoss的缓存同样，Voldemort一样支持多台服务器之间的缓存同步，以加强系统的可靠性和读取性能。

Voldemort有以下特色：

Voldemort的逻辑架构图

Voldemort至关因而Amazon Dynamo的一个开源实现，LinkedIn用它解决了网站的高扩展性存储问题。

简单来讲，就平台级缓存而言，只须要在框架侧配置一下属性便可，而不须要调用特定的方法或函数。

系统中引入缓存技术每每就是从平台级缓存开始，平台级缓存也一般会做为一级缓存使用。

既然平台级缓存都使用框架配置来实现，这咋实现缓存的分布式呢？节点之间都没有互相的消息通信了

若是单看，框架缓存的调用，那确实没办法作到分布式缓存，由于自身没得像Redis那样分布式的部署方式，经过网络把各节点链接 。
但本地平台缓存可经过远程过程调用，来操做分布在各个节点上的平台缓存数据。

在 Ehcache 中：

03应用级缓存

当平台级缓存不能知足系统的性能时，就要考虑使用应用级缓存。 应用级缓存，须要开发者经过代码来实现缓存机制。

有些许 一方有难，八方支援 的感受。本身搞不定 ，请教别人

这是NoSQL的战场，不管是Redis仍是MongoDB，以及Memcached均可做为应用级缓存的技术支持。
一种典型的方式是每分钟或一段时间后统一辈子成某类页面存储在缓存中，或者能够在热数据变化时更新缓存。

为啥平台缓存还不能知足系统性能要求呢？它不是还能够减小应用缓存的网络开销吗
那你得看这几点：

3.1面向Redis的缓存应用

Redis是一款开源的、基于BSD许可的高级键值对缓存和存储系统，例如：新浪微博有着几乎世界上最大的Redis集群。

为什么新浪微博是世界上最大的Redis集群呢？

微博是一个社交平台，其中用户关注与被关注、微博热搜榜、点击量、高可用、缓存穿透等业务场景和技术问题。Redis都有对应的hash、ZSet、bitmap、cluster等技术方案来解决。

在这种数据关系复杂、易变化的场景上面用到它会显得很简单。好比：

用户关注与取消：用hash就能够很方便的维护用户列表，你能够直接找到key,而后更改value里面的关注用户便可。

若是你像 memcache ，那只能先序列化好用户关注列表存储，更改在反序列化。而后再缓存起来，像大V有几百万、上千万的用户，一旦关注/取消。
当前任务的操做就会有延迟。

Reddis主要功能特色

• 主从同步

Redis支持主从同步，数据能够从主服务器向任意数量的从服务器同步，从服务器可作为关联其余从服务器的主服务器。这使得Redis可执行单层树状复制。

• 发布/订阅

因为实现了发布/订阅机制，使得从服务器在任何地方同步树的时候，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操做的可扩展性和数据冗余颇有帮助。

• 集群

Redis 3.0版本加入cluster功能，解决了Redis单点没法横向扩展的问题。Redis集群采用无中心节点方式实现，无需proxy代理，客户端直接与Redis集群的每一个节点链接，根据一样的哈希算法计算出key对应的slot，而后直接在slot对应的Redis上执行命令。

从Redis视角来看，响应时间是最苛刻的条件，增长一层带来的开销是不能接受的。所以，Redis实现了客户端对节点的直接访问，为了去中心化，节点之间经过Gossip协议交换相互的状态，以及探测新加入的节点信息。Redis集群支持动态加入节点，动态迁移slot，以及自动故障转移。

Redis集群的架构示意如图所示。

那什么是 Gossip 协议呢？ 感受好高大上，各类协议频繁出现

Gossip 协议是一个多播协议，基本思想是：
一个节点想要分享一些信息给网络中的其余的一些节点。因而，它周期性的随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会作一样的事情，即把这些信息传递给其余一些随机选择的节点。直至所有的节点。

即，Redis集群中添加、剔除、选举主节点，都是基于这样的方式。

例如：当加入新节点时(meet)，集群中会随机选择一个节点来邀请新节点，此时只有邀请节点和被邀请节点知道这件事，其他节点要等待 ping 消息一层一层扩散。
除了 Fail 是当即全网通知的，其余诸如新节点、节点重上线、从节点选举成为主节点、槽变化等，都须要等待被通知到，因此Gossip协议也是最终一致性的协议。

这种多播的方式，是否是突然有种好事不出门，坏事传千里的感脚

然而，Gossip协议也有不完美的地方，例如，拜占庭问题（Byzantine）。即，若是有一个恶意传播消息的节点，Gossip协议的分布式系统就会出问题。

注：Redis集群节点通讯消息类型

全部的Redis节点经过PING-PONG机制彼此互联，内部使用二进制协议优化传输速度和带宽。

这个ping为啥能提升传输速度和带宽？ 感受不大清楚，小吒哥。那这里和OSI网络层级模式有关系了

在OSI网络层级模型下，ping协议隶属网络层，因此它会减小网络层级传输的开销，而二进制是用最小单位0,1表示的位。

带宽是固定的，若是你发送的数据包都很小，那传输就很快，并不会出现数据包很大还要拆包等复杂工做。
至关于别人出差1斤多MacPro。你出差带5斤的战神电脑。

Redis的瓶颈是什么呢? 吒吒辉给安排

Redis自己就是内存数据库，读写I/O是它的强项，瓶颈就在单线程I/O上与内存的容量上。 目前已经有多线程了，

例如：Redis6具有网络传输的多线程模式，keydb直接就是多线程。
啥？ 还没了解多Redis6多线程模式，后面单独搞篇来聊聊

集群节点故障如何发现？

节点故障是经过集群中超过半数的节点检测失效时才会生效。客户端与Redis节点直连，客户端不须要链接集群全部节点，链接集群中任何一个可用节点便可。

Redis Cluster把全部的物理节点映射到slot上，cluster负责维护node、slot和value的映射关系。当节点发生故障时，选举过程是集群中全部master参与的，若是半数以上master节点与当前master节点间的通讯超时，则认为当前master节点挂掉。

这为什么不没得Slave节点参与呢？

集群模式下，请求在集群模式下会自动作到读写分离，即读从写主。但如今是选择主节点。只能由主节点来进行身份参与。

毕竟集群模式下，主节点有多个，每一个从节点只对应一个主节点，那这样，你别个家的从节点可以参与选举整个集群模式下的主节点吗？

就好像小姐姐有了对象，那就是名花有主，你还能在有主的状况下，去选一个？ 当心遭到社会的毒打

若是集群中超过半数以上master节点挂掉，不管是否有slave集群，Redis的整个集群将处于不可用状态。

当集群不可用时，全部对集群的操做都不可用，都将收到错误信息:

［（error）CLUSTERDOWN The cluster is down］。

支持Redis的客户端编程语言众多，能够知足绝大多数的应用，如图所示。

3.2.多级缓存实例

一个使用了Redis集群和其余多种缓存技术的应用系统架构如图所示

负载均衡

首先，用户的请求被负载均衡服务分发到Nginx上，此处经常使用的负载均衡算法是轮询或者一致性哈希，轮询可使服务器的请求更加均衡，而一致性哈希能够提高Nginx应用的缓存命中率。

什么是一致性hash算法？

hash算法计算出的结果值自己就是惟一的，这样就可让每一个用户的请求都落到同一台服务器。
默认状况下，用户在那台在服务器登陆，就生成会话session文件到该服务器，但若是下次请求从新分发给其余服务器就又须要从新登陆。

而有了一致性hash算法就能够治愈它，它把请求都专心交给同一台服务器，铁打的专注，从而避免上述问题。 固然这里的一致性hash原理就没给你们讲了。后面安排

nginx本地缓存

请求进入到Nginx应用服务器，首先读取本地缓存，实现本地缓存的方式能够是Lua Shared Dict，或者面向磁盘或内存的 Nginx Proxy Cache，以及本地的Redis实现等，若是本地缓存命中则直接返回。

这本地缓存怎么感受那么特别呢？ 好像你家附近的小姐姐，离得这么近，惋惜吃不着。呸呸呸，跑题啦

• Lua Shard Dict是指在nginx上，经过lua开辟一块内存空间来存储缓存数据。至关于用的是nginx的进程资源
• nginx Cache指nginx获取上游服务的数据缓存到本地。
• 本地Redis指nginx和Redis部署在同一台服务上，由nginx直接操做Redis

啥！ nginx还可直接操做Redis呀，听我细细到来

这些方式各有千秋，Lua Shard Dict 是经过Lua脚本控制缓存数据的大小并能够灵活的经过逻辑处理来修改相关缓存数据。

而Nginx Proxy Cache开发相对简单，就是获取上游数据到本地缓存处理。 而本地Redis则须要经过lua脚本编写逻辑来设置，虽然操做繁琐了，但解决了本地内存局限的问题。
因此nginx操做Redis是须要借助于 Lua 哒

nginx本地缓存有什么优势？

Nginx应用服务器使用本地缓存能够提高总体的吞吐量，下降后端的压力，尤为应对热点数据的反复读取问题很是有效。

本地缓存未命中时如何解决？

若是Nginx应用服务器的本地缓存没有命中，就会进一步读取相应的分布式缓存——Redis分布式缓存的集群，能够考虑使用主从架构来提高性能和吞吐量，若是分布式缓存命中则直接返回相应数据，并回写到Nginx应用服务器的本地缓存中。

若是Redis分布式缓存也没有命中，则会回源到Tomcat集群，在回源到Tomcat集群时也可使用轮询和一致性哈希做为负载均衡算法。

那我是PHP技术栈咋办？都不会用到java的Tomcat呀
nginx经常使用于反向代理层。而这里的Tomcat更可能是属于应用服务器，若是换成PHP，那就由php-fpm或者swoole服务来接受请求。即无论什么语言，都应该找对应语言接受请求分发的东西。

固然，若是Redis分布式缓存没有命中的话，Nginx应用服务器还能够再尝试一次读主Redis集群操做，目的是防止当从Redis集群有问题时可能发生的流量冲击。

这样的设计方案我在下表示看不懂

若是你网站流量比较大，若是一次在Redis分布式缓存中未读取到的话，直接透过到数据库，那流量可能会把数据库冲垮。这里的一次读主也是考虑到Redis集群中的主从延迟问题，为的就是防止缓存击穿。

在Tomcat | PHP-FPM集群应用中，首先读取本地平台级缓存，若是平台级缓存命中则直接返回数据，并会同步写到主Redis集群，在由主从同步到从Redis集群。

此处可能存在多个Tomcat实例同时写主Redis集群的状况，可能会形成数据错乱，须要注意缓存的更新机制和原子化操做。

如何保证原子化操做执行呢？

当多个实例要同时要写Redis缓存时，为了保持原子化，起码得在涉及这块业务多个的 Key 上采用lua脚本进行封装，而后再经过分布式锁或去重相同请求并入到一个队列来获取，让获取到锁或从队列pop的请求去读取Redis集群中的数据。

若是全部缓存都没有命中，系统就只能查询数据库或其余相关服务获取相关数据并返回，固然，咱们已经知道数据库也是有缓存的。 是否是安排得明明白白。

这就是多级缓存的使用，才能保障系统具有优良的性能。

何时，小姐姐也能明白俺的良苦心。。。。 默默的独自流下了泪水

3.3.缓存算法

缓存通常都会采用内存来作存储介质，使用索引成本相对来讲仍是比较高的。因此在使用缓存时，须要了解缓存技术中的几个术语。

缓存淘汰算法

替代策略的具体实现就是缓存淘汰算法。

使用频率：

1. Least-Recently-Used（LRU） 替换掉最近被请求最少的对象。

在CPU缓存淘汰和虚拟内存系统中效果很好。然而在直接应用与代理缓存中效果欠佳，由于Web访问的时间局部性经常变化很大。
浏览器就通常使用了LRU做为缓存算法。新的对象会被放在缓存的顶部，当缓存达到了容量极限，底部的对象被去除，方法就是把最新被访问的缓存对象放到缓存池的顶部。

1. Least-Frequently-Used（LFU） 替换掉访问次数最少的缓存，这一策略意图是保留最经常使用的、最流行的对象，替换掉不多使用的那些数据。

然而，有的文档可能有很高的使用频率，但以后不再会用到。传统的LFU策略没有提供任何移除这类文件的机制，所以会致使“缓存污染”，即一个先前流行的缓存对象会在缓存中驻留很长时间，这样，就阻碍了新进来可能会流行的对象对它的替代。

1. Pitkow/Recker 替换最近最少使用的对象

除非全部对象都是今天访问过的。若是是这样，则替换掉最大的对象。这一策略试图符合每日访问Web网页的特定模式。这一策略也被建议在天天结束时运行，以释放被“旧的”、最近最少使用的对象占用的空间。

1. Adaptive Replacement Cache（ARC） ARC介于LRU和LFU之间，为了提升效果，由2个LRU组成。

第一个包含的条目是最近只被使用过一次的，而第二个LRU包含的是最近被使用过两次的条目，所以，获得了新的对象和经常使用的对象。ARC可以自我调节，而且是低负载的。

1. Most Recently Used（MRU） MRU与LRU是相对，移除最近最多被使用的对象。

当一次访问过来的时候，有些事情是没法预测的，而且在存系统中找出最少最近使用的对象是一项时间复杂度很是高的运算，这时会考虑MRU，在数据库内存缓存中比较常见。

访问计数

1. Least Recently Used2 (LRU2）

LRU的变种，把被两次访问过的对象放入缓存池，当缓存池满了以后，会把有两次最少使用的缓存对象去除。

由于须要跟踪对象2次，访问负载就会随着缓存池的增长而增长。

1. Two Queues（2Q） Two Queues是LRU的另外一个变种。

把被访问的数据放到LRU的缓存中，若是这个对象再一次被访问，就把他转移到第二个、更大的LRU缓存，使用了多级缓存的方式。去除缓存对象是为了保持第一个缓存池是第二个缓存池的1/3。

当缓存的访问负载是固定的时候，把LRU换成LRU2，就比增长缓存的容量更好。

缓存容量算法

1. SIZE 替换占用空间最大的对象，这一策略经过淘汰一个大对象而不是多个小对象来提升命中率。不过，可能有些进入缓存的小对象永远不会再被访问。SIZE策略没有提供淘汰这类对象的机制，也会致使“缓存污染”。
2. LRU-Threshold 不缓存超过某一size的对象，其余与LRU相同。
3. Log（Size）+LRU 替换size最大的对象，当size相同时，按LRU进行替换。

缓存时间

1. Hyper-G LFU的改进版，同时考虑上次访问时间和对象size。
2. Lowest-Latency-First 替换下载时间最少的文档。显然它的目标是最小化平均延迟。

缓存评估

1. Hybrid Hybrid 有一个目标是减小平均延迟。

对缓存中的每一个文档都会计算一个保留效用，保留效用最低的对象会被替换掉。位于服务器S的文档f的效用函数定义以下：

Cs是与服务器s的链接时间；
bs是服务器s的带宽；frf表明f的使用频率；sizef是文档f的大小，单位字节。K1和K2是常量，Cs和bs是根据最近从服务器s获取文档的时间进行估计的。

1. Lowest Relative Value（LRV） LRV也是基于计算缓存中文档的保留效用，而后替换保留效用最低的文档。

随机与队列算法

1. First in First out（FIFO）

FIFO经过一个队列去跟踪全部的缓存对象，最近最经常使用的缓存对象放在后面，而更早的缓存对象放在前面，当缓存容量满时，排在前面的缓存对象会被踢走，而后把新的缓存对象加进去。

1. Random Cache 随机缓存就是随意的替换缓存数据，比FIFO机制好，在某些状况下，甚至比LRU好，可是一般LRU都会比随机缓存更好些。

还有不少的缓存算法，例如Second Chance、Clock、Simple time-based、Extended time-based expiration、Sliding time-based expiration……各类缓存算法没有优劣之分，不一样的实际应用场景，会用到不一样的缓存算法。在实现缓存算法的时候，一般会考虑使用频率、获取成本、缓存容量和时间等因素。

04.使用公有云的缓存服务

国内的共有云服务提供商如阿里云、青云、百度云等都推出了基于Redis的云存储服务，这些服务的有以下特色：

• 动态扩容：

用户能够经过控制面板升级所需Redis的存储空间，扩容过程当中服务不须要中断或中止，整个扩容过程对用户是透明且无感知的，而自主使用集群解决Redis平滑扩容是个很烦琐的任务，如今须要用你的小手按几下鼠标就能搞定，大大减小了运维的负担。

• 数据多备：

数据保存在一主一备两台机器中，其中一台机器宕机了，数据还在另一台机器上有备份。

• 自动容灾：

主机宕机后系统能自动检测并切换到备机上，实现了服务的高可用性。

• 成本较低：

在不少状况下，为使Redis的性能更好，须要购买一台专门的服务器用于Redis的存储服务，但这样会致使某些资源的浪费，购买Redis云存储服务就能很好地解决这样的问题。

有了Redis云存储服务，能使后台开发人员从烦琐的运维中解放出来。应用后台服务中，若是自主搭建一个高可用、高性能的Redis集群服务，是须要投入至关的运维成本和精力。

若是使用云服务，就不必投入这些成本和精力，可让后台应用的开发人员更专一于业务。

我是吒吒辉，就爱分析进阶相关知识，下期在见。若是以为文章对你有帮助，欢迎分享+关注额。 同时这边我也整理了后端系统提高的电子书和技术问题的知识卡片，也一并分享给你们，后面将持续更新，大家的关注将是我继续写做下去的最大动力。 须要的小伙伴可微信搜索【莲花童子哪吒】