简介：风雨不动安如山

背景

近几年互联网的疾速倒退中，互联网业务倒退越来越简单，业务也被拆分得越来越细，阿里外部业务也产生着天翻地覆的变动，从最后的单体利用，到前面的分布式集群，再到最近几年大中台小前台的业务状态，作为后端开发，依赖的服务方越来越多，同时依赖服务方的故障因素也会越来越多的会影响到闲鱼的下层业务的稳固。例如在闲鱼主推商品流的业务场景中，商品中台数据库的抖动会造成主推商品流的卡顿或者页面显示空窗景象，个性化算法中台向量集群的扩容也会造成举荐内容延时被拖到十分长，前面还有可能依赖其余的业务中台，作为下层业务如何保障依赖的中台越来越多的状况下，还能保障服务的稳定性运行呢？

业界支流溜一遍

依据日常解决问题的教训，不能间接解决业务问题自身，能够折中解决业务问题也是一个不错的方法。上述业务问题中，当业务呈现问题的时候，能够折中提前置备好所需的业务数据返回给业务，也是一个不错的方法。在闲鱼主推商品流的业务场景中，对可靠性要求十分高，因为举荐商品失败，用户看到举荐页呈现空窗，业务所需的数据量大略是 5 页的举荐商品数据流，大略为 3M 左右。在理论解决问题中，笔者从业务所需的数据量级、可靠性要求级别等角度调研了业界一些通用解决办法。

为了给用户良好的业务体验，笔者次要应用服务端数据冗余、客户端数据冗余、熔断机制等办法，来确保用户对闲鱼 App 晦涩的业务体验。笔者次要服务端数据冗余聊聊本地缓存，依据笔者在阿里断网演练的教训，断网演练时，某个区域的所有服务不可用，所以笔者在技术选型的时候没有思考分布式缓存 Redis，Memcache 之类等。目前就业界本地缓存库有 Guava、Caffeine、Ehcache、Cache2K、ConcurrentHashMap、Varnish、JackRabbit 等，笔者选取了几个性能比拟优越的缓存库比拟，上面笔者从性能上、性能上、易用性、集群能力、可视化报表上等别离比拟。

笔者对照目前业务需要比照了上述四个组件，在定时生效策略能力上，除了 ConcurrentHashMap 都是应用定时生效能力，并且三个组件工夫复杂度都是 O(n)。在集群能力上，Ehcache 依赖本身网络协议保障集群数据一致性，不能应用现有团体外部组件保证数据一致性。在本地缓存能力上，Caffeine 的写能力 [1] 优与 Guava。在组件通用性上，Guava 组件更加通用。最终笔者选用了 Guava 组件作为本地缓存组件，因为 Guava 组件更加通用，并且很不便与阿里外部中间件集成配合应用。在集群数据同步能力，通过配置核心中间件实现数据同步，在可视化报表能力，通过定时工作打印日志，日志采集零碎采集展现数据报表。接下来笔者介绍如何增加上述三种能力和优化 Guava 本地缓存能力。

我的集群 Cache 组件

Guava Caching 提供了定时生效、最初拜访生效、最初写入生效策略等能力，笔者次要应用了定时生效能力，在首次写入 Key 后，指定工夫过后，该 Key 会生效，业务获取该 Key 时，会调用 reload 办法从新同步加载该 Key。如果应用 invalid 办法使该 Key 有效，业务并发再次获取该 Key，多线程加载该 Key 时，只有一个业务线程调用 load 办法加载该 Key，其余线程期待该 Key，加载实现后从新进入指定工夫后流程。笔者在原来 Guava Cache 本地缓存能力上联合 Spring 主动注入能力，进行工程化，增加了业务所需的如下三种能力

• 当 key 生效，本地缓存 reload 异步加载
• 生效本地缓存 key，整个集群机器上 key 生效能力
• 定时上报本机 Cache 内各个 Key 在本地缓存大小

根据上述业务能力，整体流程图如下所示

集群本机 Cache 组件的整体构造类图如下:

• AbstractCacheLoader 重写父类 CacheLoader 的 reload 办法，增加异步加载能力
• LocalCacheManager 治理所有实现 AbstractCacheConfig 的子类，并上报各自本地缓存大小。
• 实现 AbstractCacheConfig 的业务配置子类，例如 CurrentCacheConfig 等，调用 invalidate 办法时，会告诉集群本机 Cache 中 Key 音讯。

业务同学在应用集群本机 Cache 组件时，只须要继承 AbstractCacheConfig 抽象类，申明为 Bean，即用集群本机 Cache 组件，业务同学无需关怀集群环境问题等。相比 Guava cache 组件，提供了集群本机 Cache Key 生效能力，以及对 Key 集中管理和监控，缩小了独自应用 Guava cache 带来内存无奈治理的问题。
接下来笔者介绍应用集群本机 Cache 组件能力的典型案例：主动置备兜底组件。

典型栗子

主动置备兜底组件

兜底是在服务遇到内部依赖异样（超时、不可用、数据异样等），可能导致服务无能够返回的失常数据时，服务通过应用兜底数据提供服务的一种降级行为。主动置备兜底组件应用集群本机 cache 的本机缓存能力和集群生效能力，很不便实现兜底数据置备。在闲鱼的业务场景中应用兜底置备组件的场景十分多，例如闲鱼主推商品流等。
兜底主动置备组件原理如下:

• 应用定时工作 scheduleX2 定时触发服务集群中的一台服务器，执行兜底置备，更新 tair 缓存内容，生效本地缓存，即生效集群 server 的本地缓存。
• 当业务申请获取 key 时，会获取 tair 中最新内容，并缓存到本地，再次申请，间接本地获取。

具体业务申请流程图如下所示

主动兜底组件曾经在闲鱼的多个业务场景失去应用，在断网演练状况下，服务端 RT 延时和成功率有了显著的晋升，闲鱼次要业务场景的晋升成果如下：

瞻望

在集群本机 cache 组件应用过程中也发现一些问题，例如有时候集群本机 cache 缓存谬误的配置，须要重启集群或者期待 key 生效，所以须要集群本机 cache 组件 web 治理性能。在集群本机 cache 组件推广中，发现有些业务场景的缓存 key 对应的缓存对象比拟大，或者缓存 key 的数量比拟多，前期依照 key 应用频率等级，思考对于长期不应用的 key 存储到本机磁盘上，让业务方不关怀缓存 Key 过大可能造成的问题。

作者：闲鱼技术——习武
原文链接
本文为阿里云原创内容，未经容许不得转载