简介： 风雨不动安如山
背景
近几年互联网的疾速倒退中，互联网业务倒退越来越简单，业务也被拆分得越来越细，阿里外部业务也产生着天翻地覆的变动，从最后的单体利用，到前面的分布式集群，再到最近几年大中台小前台的业务状态，作为后端开发，依赖的服务方越来越多，同时依赖服务方的故障因素也会越来越多的会影响到闲鱼的下层业务的稳固。例如在闲鱼主推商品流的业务场景中，商品中台数据库的抖动会造成主推商品流的卡顿或者页面显示空窗景象，个性化算法中台向量集群的扩容也会造成举荐内容延时被拖到十分长，前面还有可能依赖其余的业务中台，作为下层业务如何保障依赖的中台越来越多的状况下，还能保障服务的稳定性运行呢？
业界支流溜一遍
依据日常解决问题的教训，不能间接解决业务问题自身，能够折中解决业务问题也是一个不错的方法。上述业务问题中，当业务呈现问题的时候，能够折中提前置备好所需的业务数据返回给业务，也是一个不错的方法。在闲鱼主推商品流的业务场景中，对可靠性要求十分高，因为举荐商品失败，用户看到举荐页呈现空窗，业务所需的数据量大略是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过大可能造成的问题。
作者：闲鱼技术——习武
原文链接
本文为阿里云原创内容，未经容许不得转载