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

很多人在一个行业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集群服务，是须要投入相当的运维老本和精力。

如果应用云服务，就没必要投入这些老本和精力，能够让后盾利用的开发人员更专一于业务。

我是吒吒辉，就爱剖析进阶相干常识，下期在见。如果感觉文章对你有帮忙，欢送分享+关注额。
同时这边我也整顿了后端系统晋升的电子书和技术问题的常识卡片，也一并分享给大家，前面将继续更新，你们的关注将是我持续写作上来的最大能源。 须要的小伙伴可微信搜寻【莲花童子哪吒】