实践出真知，看我们如何化解DynamoDB的挑战

DynamoDB 是 Amazon 基于《 Dynamo: Amazon’s Highly Available Key-value Store 》实现的 NoSQL 数据库服务。它可以满足数据库无缝的扩展，可以保证数据的持久性以及高可用性。开发人员不必费心关注 DynamoDB 的维护、扩展、性能等一系列问题，它由 Amazon 完全托管，开发人员可以将更多的精力放到架构和业务层面上。

本文主要介绍作者所在团队在具体业务中所遇到的挑战，基于这些挑战为何最终选型使用 Amazon DynamoDB，在实践中遇到了哪些问题以及又是如何解决的。文中不会详细讨论 Amazon DynamoDB 的技术细节，也不会涵盖 Amazon DynamoDB 的全部特性。

背景与挑战

TalkingData 移动广告效果监测产品(TalkingData Ad Tracking)作为广告主与媒体之间的一个广告投放监测平台，每天需要接收大量的推广样本信息和实际效果信息，并最终将实际的效果归因到推广样本上。

举个例子，我们通过手机某新闻类 APP 浏览信息，会在信息流中看到穿插的广告，广告可能是文字形式、图片形式、视频形式的，而不管是哪种形式的广告它们都是可以和用户交互的。

如果广告推送比较精准，刚好是用户感兴趣的内容，用户可能会去点击这个广告来了解更多的信息。一旦点击了广告，监测平台会收到这一次用户触发的点击事件，我们将这个点击事件携带的所有信息称为样本信息，其中可能包含点击的广告来源、点击广告的时间等等。通常，点击了广告后会引导用户进行相关操作，比如下载广告推荐的 APP，当用户下载并打开 APP 后，移动广告监测平台会收到这个 APP 发来的效果信息。到此为止，对于广告投放来说就算做一次成功转化。

DynamoDB实践：当数据量巨大而不可预知，如何保证高可用与实时性?

移动广告监测平台需要接收源源不断的样本信息和效果信息，并反复、不停的实时处理一次又一次转化。对于监测平台来讲，它的责任重大，不能多记录，也不能少记录，如果转化数据记多了广告主需要多付广告费给媒体，记少了媒体会有亏损。这样就为平台带来了几大挑战：

• 数据量大：有的媒体为了利益最大化可能会采取非正常手段制造假的样本，产生“虚假流量”，所以广告监测平台除了会收到真实用户样本外，也会收到大量造假的样本，影响正常的监测和归因。在最“疯狂”的时候，我们的平台会在一天内收到 40 亿 + 的点击样本事件请求。要知道，这些点击样本事件是要保留下来作为后续效果归因用的，而且样本有效期大不相同，从最短 12 小时到最长 90 天不等。
• 数据量不可预知：对于广告主的大推、应用商店竞价排名等一系列的推广，会导致突发大量样本数据流入。面对这些流量不可预知的情况，我们仍要保证系统的正确、稳定、实时。
• 实时处理：广告主依赖广告监测平台实时处理的结果来调整广告推广策略。因此广告监测平台需要支持数据实时处理，才能为广告主更快的优化推广策略提供有力支撑。与此同时，广告监测平台的处理结果也要实时回传给媒体方以及广告主。可以看到，准确性和实时性是系统必须要满足的基本条件。
• 样本存储：我们的业务最核心的功能就是归因，我们要明确例如用户下载打开 APP 的这个转化效果是由哪一个推广活动样本带来的——也就是上图中的第 7 步，当用户安装 APP 后，监测平台要对应找到第 1 步中样本所在推广活动，这个是一个查询匹配的过程。对于庞大的归因样本数据，有效期又各不相同，我们应该怎样存储样本才能让系统快速归因，不影响实时结果，这也是一个很大的挑战。

最初形态

在 2017 年 6 月前我们的业务处理服务部署在机房，使用 Redis Version 2.8 存储所有样本数据。Redis 使用多节点分区，每个分区以主从方式部署。在最开始我们 Redis 部署了多个节点，分成多个分区，每个分区一主一从。刚开始这种方式还没有出现什么问题，但随着用户设置的样本有效期加长、监测样本增多，当时的节点数量逐渐已经不够支撑业务存储量级了。如果用户监测推广量一旦暴增，我们系统存储将面临崩溃，业务也会瘫痪。于是我们进行了第一次扩容。

由于之前的部署方式我们只能将 Redis 的多个节点翻倍扩容，这一切都需要人为手动操作，并且在此期间我们想尽各种办法来保护用户的样本数据。

DynamoDB实践：当数据量巨大而不可预知，如何保证高可用与实时性?

这种部署方式随着监测量的增长以及用户设定有效期变长会越来越不堪重负，当出现不可预知的突发量时就会产生严重的后果。而且，手动扩容的方式容易出错，及时性低，成本也是翻倍的增长。在当时由于机器资源有限，不仅 Redis 需要扩容，广告监测平台的一系列服务和集群也需要进行扩容。

化解挑战

经过讨论和评估，我们决定将样本处理等服务迁移到云端处理，同时对存储方式重新选型为 Amazon DynamoDB，它能够满足我们的绝大部分业务需求。经过结构调整后系统大概是下图的样子：

DynamoDB实践：当数据量巨大而不可预知，如何保证高可用与实时性?

• 应对数据量大且不可预知：我们的平台需要接受推广监测连接请求，并进行持久化用于后续的数据归因处理。理论上来说系统进来多少广告监测数据请求，DynamoDB 就能存多少数据，只需要一张表就可以存储任意数量级的数据。不用关心 DynamoDB 扩容问题，在系统运行时我们感知不到存储正在扩容。这也是 Amazon 官方宣称的完全托管、无缝扩展。
• 高可用：Amazon DynamoDB 作为存储服务提供了极高的可用性，对于写入 DynamoDB 的全部数据都会存储到固态硬盘中，并且自动同步到 AWS 多个可用区，以达到数据的高可用。这些工作同样完全由 Amazon DynamoDB 服务托管，使用者可以将精力放到业务架构及编码上。
• 实时处理：Amazon DynamoDB 提供了极高的吞吐性能，并且支持按秒维度配置任意级别的吞吐量。对于写多读少的应用可以将每秒写入数据的数量调整成 1000 甚至更高，将每秒读取的数量降低到 10 甚至更少。吞吐量支持使用者任意设定，在设定吞吐量时除了可以随时在 Web 管理后台调整外，还可以通过 DynamoDB 提供的客户端动态调整。比如系统在运行时写入能力不足了，我们可以选择到 Web 管理后台手动上调或在代码中通过调用客户端 API 的方式实现自动上调。使用客户端动态调整的方式会让系统具备较高的收缩能力，同时还可以保证数据的实时处理，系统数据流量变高了就动态调整上去，数据流量变低了再动态调整下来。相比手动调整来看，动态调整的方式更为灵活。基于以上几点，我们认为 Amazon DynamoDB 可以很轻松的支撑系统的核心业务能力。对于业务侧需要做的就是，整理好业务逻辑把数据写到 DynamoDB 就可以了，剩下的就交给 DynamoDB 去做。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!