共计 10552 个字符，预计需要花费 27 分钟才能阅读完成。
这篇想聊的话题是:分布式多级缓存架构的终章，如何解决大流量、高并发这样的业务场景，取决于你能不能成为这个畛域金字塔下层的高手? 能不能把这个问题思考分明决定了你的成长速度。
很多人在一个行业 5 年、10 年，仍然未达到这个行业的中层甚至还停留在底层，因为他们从来不关怀这样的话题。作为砥砺前行的践行者，我感觉有必要给大家来分享一下。
开篇
服务端缓存是整个缓存体系中的重头戏，从开始的网站架构演进中，想必你已看到服务端缓存在零碎性能的重要性。
但数据库确是整个零碎中的“半吊子 | 慢性子”，有时数据库调优却可能以小搏大，在不扭转架构和代码逻辑的前提下，缓存参数的调整往往是条捷径。
在零碎开发的过程中，可间接在平台侧应用缓存框架，当缓存框架无奈满足系统对性能的要求时，就须要在应用层自主开发利用级缓存。
缓存罕用的就是 Redis 这货色，那到底什么是平台级、利用级缓存呢？
前面给大家揭晓。但有一点可表明，平台级就是你所抉择什么开发语言来实现缓存，而利用级缓存，则是通过应用程序来达到目标。
01 数据库缓存
为何说数据库是“慢性子”呢？对当初喜爱 快的你来说，慢是解决不了问题的。就如同总感觉感觉妹子回复慢
因为数据库属于 IO 密集型应 用，次要负责数据的治理及存储。数据一多查问自身就有可能变慢，这也是为啥数据上得了台面时，查问爱用索引提速的起因。当然数据库本身也有“缓存”来解决这个问题。
数据多了查问不应该都慢吗？小白说吒吒辉你不懂额
。。。这个，你说的也不全是，还得分状况。例如：数据有上亿行
起因：
- 因为简略的 SQL 的后果不会特地多。你申请也不大，磁盘跟的上
- 并发总量超过磁盘吞吐下限，是谁都没招
就算你们不喜爱吒吒辉，我也要奋笔疾书
数据库缓存是本身一类非凡的缓存机制。大多数数据库不须要配置就能够疾速运行，但并没有为特定的需要进行优化。在数据库调优的时候，缓存优化你能够思考下。
以 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 只有波及到数据更改，就会从新保护缓存。
- 如果 SQL 申请量比拟大，你在保护的时候，就透过缓存走磁盘检索。这样数据库的压力必定大。
- 重建缓存数据，它须要 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. 缓存算法
缓存个别都会采纳内存来做存储介质，应用索引老本相对来说还是比拟高的。所以在应用缓存时，须要理解缓存技术中的几个术语。
缓存淘汰算法
代替策略的具体实现就是缓存淘汰算法。
应用频率：
- Least-Recently-Used（LRU）替换掉最近被申请起码的对象。
在 CPU 缓存淘汰和虚拟内存零碎中成果很好。然而在间接利用与代理缓存中成果欠佳，因为 Web 拜访的工夫局部性经常变化很大。
浏览器就个别应用了 LRU 作为缓存算法。新的对象会被放在缓存的顶部，当缓存达到了容量极限，底部的对象被去除，办法就是把最新被拜访的缓存对象放到缓存池的顶部。
- Least-Frequently-Used（LFU）替换掉拜访次数起码的缓存，这一策略用意是保留最罕用的、最风行的对象，替换掉很少应用的那些数据。
然而，有的文档可能有很高的应用频率，但之后再也不会用到。传统的 LFU 策略没有提供任何移除这类文件的机制，因而会导致“缓存净化”，即一个先前风行的缓存对象会在缓存中驻留很长时间，这样，就妨碍了新进来可能会风行的对象对它的代替。
- Pitkow/Recker 替换最近起码应用的对象
除非所有对象都是明天拜访过的。如果是这样，则替换掉最大的对象。这一策略试图合乎每日拜访 Web 网页的特定模式。这一策略也被倡议在每天完结时运行，以开释被“旧的”、最近起码应用的对象占用的空间。
- Adaptive Replacement Cache（ARC）ARC 介于 LRU 和 LFU 之间，为了进步成果，由 2 个 LRU 组成。
第一个蕴含的条目是最近只被应用过一次的，而第二个 LRU 蕴含的是最近被应用过两次的条目，因而，失去了新的对象和罕用的对象。ARC 可能自我调节，并且是低负载的。
- Most Recently Used（MRU）MRU 与 LRU 是绝对，移除最近最多被应用的对象。
当一次拜访过去的时候，有些事件是无奈预测的，并且在存零碎中找出起码最近应用的对象是一项工夫复杂度十分高的运算，这时会思考 MRU，在数据库内存缓存中比拟常见。
拜访计数
- Least Recently Used2 (LRU2）
LRU 的变种，把被两次拜访过的对象放入缓存池，当缓存池满了之后，会把有两次起码应用的缓存对象去除。
因为须要跟踪对象 2 次，拜访负载就会随着缓存池的减少而减少。
- Two Queues（2Q）Two Queues 是 LRU 的另一个变种。
把被拜访的数据放到 LRU 的缓存中，如果这个对象再一次被拜访，就把他转移到第二个、更大的 LRU 缓存，应用了多级缓存的形式。去除缓存对象是为了放弃第一个缓存池是第二个缓存池的 1 /3。
当缓存的拜访负载是固定的时候，把 LRU 换成 LRU2，就比减少缓存的容量更好。
缓存容量算法
- SIZE 替换占用空间最大的对象，这一策略通过淘汰一个大对象而不是多个小对象来进步命中率。不过，可能有些进入缓存的小对象永远不会再被拜访。SIZE 策略没有提供淘汰这类对象的机制，也会导致“缓存净化”。
- LRU-Threshold 不缓存超过某一 size 的对象，其余与 LRU 雷同。
- Log（Size）+LRU 替换 size 最大的对象，当 size 雷同时，按 LRU 进行替换。
缓存工夫
- Hyper-G LFU 的改进版，同时思考上次访问工夫和对象 size。
- Lowest-Latency-First 替换下载工夫起码的文档。显然它的指标是最小化均匀提早。
缓存评估
- Hybrid Hybrid 有一个指标是缩小均匀提早。
对缓存中的每个文档都会计算一个保留效用，保留效用最低的对象会被替换掉。位于服务器 S 的文档 f 的效用函数定义如下：
Cs 是与服务器 s 的连接时间；
bs 是服务器 s 的带宽；frf 代表 f 的应用频率；sizef 是文档 f 的大小，单位字节。K1 和 K2 是常量，Cs 和 bs 是依据最近从服务器 s 获取文档的工夫进行预计的。
- Lowest Relative Value（LRV）LRV 也是基于计算缓存中文档的保留效用，而后替换保留效用最低的文档。
随机与队列算法
- First in First out（FIFO）
FIFO 通过一个队列去跟踪所有的缓存对象，最近最罕用的缓存对象放在前面，而更早的缓存对象放在后面，当缓存容量满时，排在后面的缓存对象会被踢走，而后把新的缓存对象加进去。
- 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 集群服务，是须要投入相当的运维老本和精力。
如果应用云服务，就没必要投入这些老本和精力，能够让后盾利用的开发人员更专一于业务。
我是吒吒辉，就爱剖析进阶相干常识，下期在见。如果感觉文章对你有帮忙，欢送分享 + 关注额。
同时这边我也整顿了后端系统晋升的电子书和技术问题的常识卡片，也一并分享给大家，前面将继续更新，你们的关注将是我持续写作上来的最大能源。须要的小伙伴可微信搜寻【莲花童子哪吒】