技术范儿|应用数据缓存:Glispa的最佳实践

技术

glispa全球 · 2016-12-21 13:42

技术范儿|应用数据缓存:Glispa的最佳实践

在Glispa,高度复杂的技术需要依托连续并可靠的大数据处理能力。例如我们在全球分布的需求方平台(DSP)服务器就需要每秒处理上千次请求,并对每一个请求在10毫秒内进行回应(这是我们为自己设立的标准)。

我们的需求方平台(DSP)服务器使用的是HTTP协议并且需要得到包括广告活动和广告创意在内的数据来处理所有的请求。对于每一个广告请求,系统需要查看数千个广告活动。这组数据集的实际可存储空间其实并不大 – 只有仅仅几个G并且通常不会有什么变化。这就意味着,当考虑性能表现的要求时,缓存无疑是一个有效的解决途径 – 一旦数据得到暂时的存储,我们便能更快地处理对数据的请求。由于在不同的使用情况下缓存有多种不同的方法,我们需要根据我们的要求决定哪一种方法能够更好地建立一个这样的系统。以下就是我们在Glispa曾考虑的三种方式。

延迟加载

一种最直接的应用数据缓存的方法(也是最为普遍的方法)就是将原存储中的数据提取一次并放入缓存中,这样就不用耗费时间再去提取一次。这些数据通常被存储在内存中(最快的选项)或者硬盘上 – 通常在特殊的缓存系统例如Memcached与Redis。

 

这种解决方式虽然比较容易实施,但在某些具体使用情况下会存在一些缺陷。首先,数据的访问时间具有不确定性,并且会有比较大的差异。对于尚未缓存数据的请求也会比较慢,清除旧数据也会比较困难。另外,用以衡量缓存数据有效期的生存时间(TTL值)同样比较难以确立。如果选择的TTL值太短,过早地将数据从缓存中移除将会使得性能表现受到影响。如果选择的TTL值过长,则缓存不能及时刷新,导致滞后的广告活动。而“失效”的方法(一旦数据被更改则在缓存中失效)意味着数据需要从存储中重新抓取,同样也会影响性能表现。如果将部分数据失效则会在数据存储上引发查找高峰,使响应时间增加。当然,在同时存储和读取数据的时候,缓存也必须能够应对并发性的问题。

单缓冲的预加载

另一种方式则是使用单缓冲的预加载,尤其当服务器需要确定性的访问时间。其中一种办法就是通过背景的预先同步。


如果使用这种方法,所有的数据都被加载到缓存中。随后,背景同步将保持更新数据。由于数据一直在内存中,访问时间就可以是固定的,唯一的延迟仅发生在同步周期中。随着同步的增加,同步周期将会缩短至几秒钟。然而,并发性问题仍会时常发生。每一个数据类都必须能够具备处理写入和同时读取的机制 。这就意味着适配的收集及锁定机制需要被使用。

双缓冲的预加载

这种解决方案与之前的解决方案非常类似,数据同样是被加载入内存中。而不同的是使用了两个不同的内存缓存,一个用于读取,另一个用于写入。处理请求时只需用到读取缓冲。由于在创建之后不可更改,它能够确保连贯性问题不会发生并且不再需要同步并发性的访问。数据通过写入缓冲与存储空间进行同步。一旦更新写入缓存,它便与读取缓存互换。在这一种解决方案中,数据能够被持续和快速地访问,也不存在并发性与连贯性的问题。而然另一方面,需要的存储空间也翻了一番。


缓存有着不同的方式。若要选择正确的策略,需要考虑数据的具体情况(例如总大小,要求更新的频率以及运行中的使用情况)。我们也是通过不断的尝试来选择最终采取哪种策略,所以不妨尝试不同的方法并监测响应时间(平均值与百分位数),这样就能找到最符合需求的解决方案。


同样,我们也无需拘泥于单一的策略,一个应用可以针对不同的数据使用不同的方法。在Glispa,延迟加载与双缓冲的预加载都被大量的使用。在例如需求方平台(DSP)服务器的多个项目中我们应用了双缓冲,同时我们也使用Guava对不同的数据集进行延迟加载。


每个公司对数据的要求都各不相同。当我们发现我们需要一个缓存的解决方案的时候,我们进行了一些尝试与大量的研究,直到我们发现对于我们来说最好的解决方式是两种不同方法的结合。关键就是深入地了解公司想要达成的目标并对不同选项进行评估。


glispa全球(glispa)

 查看原文  分享到微信  文章为作者独立观点,不代表大不六文章网立场
glispa
glispa是无线、互娱的世界营销领袖;为您全球的用户/玩家获取提供一站式服务。 这里不仅有全球移动营销最新行业干货,还有Glispa为您打造的贴心服务。
最新文章