所有程序员对那个缓存都不陌生，仿佛那个风流女子只为你一个人跳舞。看着那个回眸一笑的白梅生，让人怜惜又亲切。但随着项目规模的不断壮大和强大，单靠单一的缓存是难以招架的，优化起来似乎无能为力。此时，随着多级缓存化蝶，平台级缓存和分布式缓存在应用上相得益彰。但一山难容二虎，往往存在三大问题——①概念难辨②该选谁？③分别适用于哪些场景。如果你不明白这一点，恐怕你没有很多钱。在这篇文章中，我将老式的态度一一介绍给大家，同时掌握方案和场景，以及设计技术选择的原则。包括一线厂商本章可能涉及到的常见测试点。什么是平台级缓存和分布式缓存？平台级缓存是指您选择的编程语言中的缓存技术类型。它采用了语言前提下的缓存技术，即无论你使用什么语言，你都使用它存在的缓存技术。缓存是一种工具，被编程语言调用。前者为后者服务，必然有主次关系。所以有的时候你要控制好自己，不要给自己车的速度，不然车翻了你就不知道了淘宝在这个平台上提供装修功能。比如上传商品图片、店铺布局风格等。换句话说，平台级缓存是由平台的特性决定的。上一篇文章也提到了不同编程语言下的平台级缓存是不同的，比如PHP中Smarty模板库Java中的Ehcache、Cacheonix、Voldemort、JBossCache、OSCache等。并且根据应用层的定义，平台级缓存按照进程执行的方式可以分为进程内缓存和进程外缓存。那么什么是进程内缓存和进程外缓存呢？进程内缓存是指缓存的数据存在于应用进程内部，与??应用业务代码、变量、栈等类型共享应用进程的内存资源。缓存是定位数据段的过程。或者你以前一个人住一个房间，但现在你和其他人住在一起。进程外缓存是指存放缓存数据的地方在应用程序中没有使用，而是存放在其他外部进程中。比如：Redis、memcache之类的。那么如果缓存以文件的形式保存呢？也算进程外？放心，我是渣渣辉，不是渣渣辉。呸，因为大部分缓存都是在内存中操作的，所以没心没肺的人往往会忽略以文件形式保存的数据文件。在这种情况下，它仍然是平台级缓存下的进程内缓存，而不是进程外缓存。因为这个文件的缓存是为应用进程服务的，而你有一个像Redis这样的角色，它是一个独立的进程，进程和进程本身是隔离的，还是不同软件的进程，所以无所谓。而且，文件缓存中的内容是预先存储经过逻辑处理的数据。使用时，可以减少重复读取和计算数据的动作，达到缓存的效果。那如果我把Redis独立部署到其他服务器上，是不是也是进程外缓存呢？是这样的。上面提到的进程外缓存是相对于应用进程而言的，现在它们存在于不同的服务器中。如果部署在同一台服务器上。那也算是进程外缓存，因为进程是隔离的，但是一般Redis都是部署到其他服务器上的，我们不这么叫，那叫什么呢？这种情况称为分布式缓存，常说的分布式缓存就是以这种形式存在的。分布式缓存也很容易理解。首先看分布式，就是说不同的软件部署在不同的服务器上或者不同的软件服务部署在同一台服务器上。注意：这里的【分布式缓存】是一个相对的概念。按照分布式的理念，PHP|JAVA和Redis部署在一台服务器上。它们之间的关系也被认为是分布式的。但是我们现在是从进程内和进程外来划分缓存的概念。这样就不属于分布式缓存了。谁都知道，统一声明就够了。唉，累死我了，查南怎么能这样，遮遮掩掩呢？有点迷惑，你总是慢下来，细细品味为什么要用平台级和分布式缓存？不管是什么类型的缓存，使用它们的根本目的都是为了减少数据的逻辑操作，加快请求响应速度，进而提高网站的QPS。只是表达的地方不同而已。平台级和分布式缓存有什么好处？平台级优势：延迟更低，可以节省内网带宽平台级缓存，由于数据不需要跨网络传输，直接在本地内存中操作。因此性能好，延迟低，占用带宽少。无需引入第三方类库。开箱即用的通用平台级缓存都会有官方相关的操作类库。无需引入第三方类库，降低业务开发的相关性。缺点：存储容量有限，无法存储大数据。由于内存占用的是应用进程的内存空间，比如Java进程的JVM内存空间，无法存储大量数据。微服务架构中，集群部署数据的更新问题。平台缓存数据保存在应用进程中，其他应用进程无法访问。在集群部署中，需要部署同一份缓存数据的多份副本。如果数据库中的数据有对应的更新动作，需要同步更新到不同部署节点的本地缓存中，以保证数据的一致性。这更复杂，更容易出错。基于Redis的发布-订阅机制，可以同步更新各个部署节点或中间件，实现异步数据更新。当应用程序进程重新启动或崩溃时，数据会丢失。平台缓存数据保存在应用进程的内存空间中，所以当应用进程重启时，缓存数据也会丢失。所以，对于需要持久化的数据，一定要及时保存，否则可能会造成数据丢失。分布式缓存的优点：性能和存储容量没有上限，理论上可以无限扩展。本地缓存虽然快，但毕竟在单机上，资源性能是有上限的。分布式缓存是一个独立部署的进程。拥有自己独立的内存空间，不会受到应用进程重启的影响。同时，硬件资源也是独享的。如果一台机器的性能不够，可以通过集群的形式进行扩展，实现线性扩展。借助docker容器，将漂亮的数据瞬间集中存储，保证数据在业务上的一致性和解耦。虽然缓存是分布式存储的，但是部署方式会使用集群来保证高可用。这样，所有的缓存数据都维护在缓存集群中，不存在更新本地缓存数据的问题，同时也保证了不同节点上应用进程的数据一致性。以前缓存和业务是一起使用的，现在业务和缓存是分开的，互不影响，这样就把业务拆分了。数据与业务读写分离，保证网站的高性能。高可用分布式缓存一般都支持数据拷贝机制，从业务类上实现读写分离，可以解决高并发场景下的并发读写性能问题。由于数据在多个缓存节点中也是冗余的，提高了缓存数据的可用性，避免了缓存节点宕机导致数据不可用的问题。那么什么是读写分离呢？读写分离是指将网站中的用户请求按照读写请求进行划分。经常需要和MySQL主从配合，主库用于用户写请求，从库用于用户读请求。如果不做读写分离，那么请求会去到一台机器上。所以读写分离也可以在一定程度上实现负载均衡，也可以实现对单一类型请求的独裁。比如主库是写请求，可以不创建索引，而对于读请求，从库需要索引来处理。这允许您根据请求的类型选择是否使用索引。毕竟索引维护也是消耗资源的。谁让你这么小心的？无意中看到，读写分离是这样的。然后我就知道了。其实小扎就是随便乱扔的，不过大意是一样的。基本上就是把读写请求分开，然后独裁。又如：对于网站架构，也可以采用读写分离机制部署网站子系统，而对于搜索业务，search_product.com完全可以独立部署。它服务于搜索页面。再比如：为了提高业务的处理能力，我们缓存的主从架构还是可以配合读写分离来加快网站的处理速度。再举个例子：针对大流量，可以使用读写队列消耗流量，异步批量写入机制，提高网站的处理能力，避免写入负载过大。还有其他的，但是读写分离的作用大家一定要明白，有时候会根据业务进行调整。你TM炸炸灰吃不完，你一口气吃不完，你习惯了我的暴脾气。缺点：运维部署成本高由于采用分布式部署方式，部署和运维在技术上还是有难度的，因为必须知道每台服务器的运行状态，再加上线上环境的不确定因素。直接头大，但方案能承受大流量，方案还是可取的。同时，基于Docker的部署也会减轻很多压力。反正你们是一样的份额，不然怎么办？技术结构复杂，需要考虑缓存雪崩、击穿等问题。分布式缓存中肯定有很多数据。对于业务端来说，需要考虑缓存击穿、雪崩、穿透等问题，防止非预期的请求直接命中数据库导致数据库崩溃。数据通过网络传输，性能低于本地缓存。分布式缓存部署一般与应用进程位于不同的机器上，因此需要通过外网进行网络数据传输。与平台缓存进程的内部数据读取操作相比，性能会低一些。降低。平台级和分布式缓存的技术选择？每项技术都会有自己的定位，在什么情况下使用什么样的技术内容。还是得根据自己项目的需要来选择，看速度？选择平台级缓存平台缓存的好处是在应用进程内部，离程序最近。如果某部分数据不大，但是流量很大，直接拿去处理。省心省力，再加上AOP切面编程，真是舒服又没必要。例如：如果你想在首页和活动页面展示一些统计或推荐的信息。有了它，你不需要每次都调用相同的API来执行操作，只需要记得定期更新平台缓存即可。看数据量？分布式缓存平台缓存的选择受限于应用进程和有限存储。在大流量、海量数据规模的情况下，必须选择分布式缓存，基于水平扩展和读写分离，满足业务场景、数据存储、性能等需求。整体来说，规模选择分布式缓存，规模一般选择进程外缓存。你在小范围内守旧吗？当网站规模扩大到一定规模时，你就摆脱不了分布式。为了满足高可用和高可靠机制，一般采用分布式集群方式部署。对于这样的业务，会有多台机器提供服务。即使一个主机挂了，其他主机也会??顶上去。那么选择平台级缓存有什么问题呢？如果多台机器使用平台缓存，则有多个缓存。一旦数据发生变化，需要通知多个上游服务器更新数据。在微服务模式下，一个页面模块的展示数据在调用一个服务时，可能需要聚合多个服务的数据，再返回给客户端展示。如果这样一个服务的数据发生变化，需要通知刚刚启动的服务去更新缓存，而且业务是耦合的，增加了很多额外的工作，严重影响性能。数据一致性的问题，一个服务的更新，如果网络出现延迟或者意外，导致更新请求失败，那么就会出现数据库和缓存数据不一致的情况。总结网站的规模，推荐使用分布式缓存，因为业务端和缓存在业务上不需要耦合，后期的结构调整和维护也比较容易。场景选择什么还是要根据业务需求和架构设计综合考虑。我个人不推荐平台缓存。如果业务职责更明确一些可能会更好。思考题什么是分布式缓存？你用它做什么？在什么条件下使用？您使用哪个平台级缓存？平台级和分布式缓存的优缺点是什么？平台级和分布式分别适用于哪些场景？什么是读写分离？你有那些应用程序吗？如果觉得文章对您有帮助，请再看一遍，关注、分享、留言。您的好评和支持是我创作最大的动力。其实还有很多优化、架构等东西没有分享出来。同时，为了更好的帮助大家，我还整理了以下内容：需要的朋友可以微信搜索【哪吒】。这些其实都需要大家和我一起不断完善。毕竟我个人有限，期待大家的反馈。留言补充
