闲鱼如何一招保证推荐流量稳如泰山？业务也发生了翻天覆地的变化，从最初的单体应用到后来的分布式集群，再到近几年大中小前台的业务形态。作为后端开发，依赖的服务商越来越多。同时，依赖服务商的故障因素越来越多，影响闲鱼上层业务的稳定性。例如在闲鱼主推产品流量的业务场景中，产品中心平台数据库抖动会导致主产品流量卡顿或页面显示空窗，扩展平台向量集群在产品中心个性化算法也会造成推荐内容的延迟。如果拖的时间很长，后面可能就要依赖其他业务中台了。作为上层业务，在越来越多的中台依赖的情况下，如何保证服务的稳定运行？根据日常解决问题的经验，业界主流并不能直接解决业务问题本身，折中解决业务问题也是一种很好的方式。在以上业务问题中，当业务出现问题时，妥协，提前准备好需要的业务数据，返回给业务，也是一种很好的方式。在闲鱼主推产品流的业务场景中，可靠性要求非常高。由于商品推荐失败，用户在推荐页面看到的是一个空窗。业务需要的数据量大概是5页的推荐商品数据流，大概是3M左右。在实际解决问题的过程中，笔者从业务需要的数据量和可靠性要求高低的角度，调研了一些业界常见的解决方案。为了给用户提供良好的业务体验，笔者主要通过服务端数据冗余、客户端数据冗余、熔断机制等方式来保障用户在闲鱼App上流畅的业务体验。笔者主要讲的是服务端和本地缓存的数据冗余。根据笔者在阿里断网演练的经验，在断网演练中，一定区域的所有服务都不可用，所以笔者在选择技术时没有考虑分布式缓存Redis。、内存缓存等。目前业界本地缓存库有Guava、Caffeine、Ehcache、Cache2K、ConcurrentHashMap、Varnish、JackRabbit等，笔者挑选了几个性能比较优越的缓存库进行对比。下面笔者就功能、性能、易用性和集群能力进行探讨。、可视化报告等进行比较。作者将以上四个组件与当前的业务需求进行了比较。在时序失效策略能力方面，除了ConcurrentHashMap，都使用了时序失效能力，三个组件的时间复杂度都是O(n)。在集群能力方面，Ehcache依靠自身的网络协议来保证集群数据的一致性，不能使用现有的组内部组件来保证数据的一致性。在本地缓存能力方面，Caffeine的写入能力[1]优于Guava。在组件通用性方面，Guava组件的通用性更强。最终笔者选择了Guava组件作为本地缓存组件，因为Guava组件的通用性更强，也更容易与阿里内部的中间件集成。在集群数据同步能力中，通过配置中心中间件实现数据同步。在可视化报表能力中，通过定时任务打印日志，日志采集系统采集并展示数据报表。接下来笔者介绍如何添加以上三种能力，以及优化Guava的本地缓存能力。我的集群Cache组件GuavaCaching提供了定时失败、最后访问失败、最后写入失败策略等能力。选择Key后，会调用reload方法同步重新加载Key。如果使用invalid方法使Key失效，业务会并发重新获取Key。多线程加载Key时，只有一个业务线程调用load方法加载Key，其他线程等待Key。加载完成后，在指定时间后重新进入流程。作者结合原有的GuavaCache本地缓存能力和Spring自动注入能力进行工程化，增加了业务需要的以下三个能力。当key失效时，本地缓存reload异步加载失效的本地缓存key，整个集群机器上的key失效能力定时上报本地Cache中每个Key的本地缓存大小根据以上业务能力，整体流程图表如下管理所有实现了AbstractCacheConfig的子类，并报告它们各自的本地缓存大小。实现了AbstractCacheConfig的业务配置子类，比如CurrentCacheConfig等，在调用invalidate方法时，会通知集群本地Cache中的Key消息。业务同学在使用集群原生Cache组件时只需要继承AbstractCacheConfig抽象类并声明为Bean即可，即使用集群原生Cache组件，业务同学不需要关心集群环境问题。与Guava缓存组件相比，它提供了使集群本地CacheKey失效的能力，以及对Key的集中管理和监控，减少单独使用Guava缓存带来的内存难以管理的问题。接下来笔者介绍一个使用集群原生Cache组件能力的典型案例：bottom-up组件的自动配置。典型的栗子会自动提供pocket组件。口袋是服务在遇到外部依赖异常（超时、不可用、数据异常等）时，使用口袋数据提供服务的一种降级行为，可能导致服务没有可以正常使用的数据回。自动开通组件利用集群本地缓存的本地缓存能力和集群故障能力，非常方便的完成底层数据的开通。在闲鱼的业务场景中，使用Provisioning组件的场景有很多。比如闲鱼，主推产品流量。自动开通组件原理如下：使用定时任务scheduleX2周期性触发服务集群中的一台服务器，进行开通，更新tai??r缓存内容，并使本地缓存失效，即本地缓存集群服务器。当业务请求获取key时，会获取Tair中最新的内容缓存到本地，再次请求直接在本地获取。详细的业务请求流程图如下所示。自动自下而上组件已经在闲鱼的多个业务场景中使用。在断网演练的情况下，服务器的RT延迟和成功率都有了明显的提升。闲鱼主要业务场景改进效果如下：在使用集群本地缓存组件的过程中，也发现了一些问题。比如有时候集群的本地缓存配置错误，需要重启集群或者等待key过期。因此需要集群本地缓存组件的web管理功能。在集群本地缓存组件的推广中，发现在某些业务场景下，缓存key对应的缓存对象比较多，或者缓存key的个数比较多。后期根据密钥使用频率高低，考虑将长期不用的密钥存放到本地磁盘。最重要的是让业务方不用关心cachekey过大可能带来的问题。作者：闲鱼科技—习武原文链接本文为阿里云原创内容，未经允许不得转载
