闲鱼如何一招保证推荐流稳如泰山？

时间：2021-02-23 09:37:15

关键字：闲鱼架构互联网算法数据库

手机看文章

扫描二维码
随时随地手机看文章

[导读]在闲鱼主推商品流的业务场景中，商品中台数据库的抖动会造成主推商品流的卡顿或者页面显示空窗现象，个性化算法中台向量集群的扩容也会造成推荐内容延时被拖到非常长，后面还有可能依赖其他的业务中台，作为上层业务如何保证依赖的中台越来越多的情况下，还能保证服务的稳定性运行呢？

背景

近几年互联网的快速发展中，互联网业务发展越来越复杂，业务也被拆分得越来越细，阿里内部业务也发生着翻天覆地的变化，从最初的单体应用，到后面的分布式集群，再到最近几年大中台小前台的业务形态，作为后端开发，依赖的服务方越来越多，同时依赖服务方的故障因素也会越来越多的会影响到闲鱼的上层业务的稳定。

例如在闲鱼主推商品流的业务场景中，商品中台数据库的抖动会造成主推商品流的卡顿或者页面显示空窗现象，个性化算法中台向量集群的扩容也会造成推荐内容延时被拖到非常长，后面还有可能依赖其他的业务中台，作为上层业务如何保证依赖的中台越来越多的情况下，还能保证服务的稳定性运行呢？

业界主流溜一遍

根据日常解决问题的经验，不能直接解决业务问题本身，可以折中解决业务问题也是一个不错的办法。上述业务问题中，当业务出现问题的时候，可以折中提前置备好所需的业务数据返回给业务，也是一个不错的办法。在闲鱼主推商品流的业务场景中，对可靠性要求非常高，因为推荐商品失败，用户看到推荐页出现空窗，业务所需的数据量大概是5页的推荐商品数据流，大概为3M左右。在实际解决问题中，笔者从业务所需的数据量级、可靠性要求级别等角度调研了业界一些通用解决办法。
闲鱼如何一招保证推荐流稳如泰山？

为了给用户良好的业务体验，笔者主要使用服务端数据冗余、客户端数据冗余、熔断机制等方法，来确保用户对闲鱼App流畅的业务体验。笔者主要服务端数据冗余聊聊本地缓存，根据笔者在阿里断网演练的经验，断网演练时，某个区域的所有服务不可用，所以笔者在技术选型的时候没有考虑分布式缓存Redis，Memcache之类等。目前就业界本地缓存库有Guava、Caffeine、Ehcache、Cache2K、ConcurrentHashMap、Varnish、JackRabbit等，笔者选取了几个性能比较优越的缓存库比较，下面笔者从功能上、性能上、易用性、集群能力、可视化报表上等分别比较。闲鱼如何一招保证推荐流稳如泰山？

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

我的集群Cache组件

Guava Caching提供了定时失效、最后访问失效、最后写入失效策略等能力，笔者主要使用了定时失效能力，在首次写入Key后，指定时间过后，该Key会失效，业务获取该Key时，会调用reload方法重新同步加载该Key。如果使用invalid方法使该Key无效，业务并发再次获取该Key，多线程加载该Key时，只有一个业务线程调用load方法加载该Key，其他线程等待该Key，加载完成后重新进入指定时间后流程。笔者在原来Guava Cache本地缓存能力上结合Spring自动注入能力，进行工程化，添加了业务所需的如下三种能力