怎么使用测量数据建立加载一反馈机制？

发布：2018-06-19 12:03:15 浏览：3066

采集时序数据的另一个好处，就是能够通过编程使你的应用生成测量数据，从而可以建立安全、精密的反馈循环，这方面有很多有用的例子。

在云计算中，启用新的实例只需要给提供者发一条简单的API调用即可，但要想知道什么时候应该启动更多的实例或撤销正在运行的实例，就会很麻烦。如果基于采集的资源使用情况来判断启用撤销的话，就会容易得多，这是测量数据用做反馈机制的一种通例。

我在Flickr，有一个大型项目，使用了这种反馈机制，事实证明，非常有用。

2007年，Yahoo!决定关掉Yahoo!!Photos计划很简单:通知Yahoo!Photos的用户，这个服务将被关闭，用户可以自己选择，将自己的照片连同元数据一起转移到其他的服务，包括非Yahoo!!的服务，像Shutterfly和KodakGallery，Flickr也是选项之一。

为这个项目做出容量评估将是一件苦差事。尽管有一些测量数器据，用上载频度、片大小及其他因素指述了Yahoo!Photos的典型用户，但有多少用户会选择Flickr，即使选择了Flickr，用户的使用模式又会如何变化，我们心里仍然没底。我们谈论的是一项已经超过10年的照片存储服务，将会有巨量的数括，而且这么大的空同会在很短的时间内消耗掉。不用讲得太精确，我告诉你，2009年后期，Fick每天用掉大约12TB的存储客量。从Yahoo!Photos到Flickr的迁移，在2007年持续了一段不长的时间，每天消耗的存空间是这个数的两倍还多。

在在备迁移的过程中，基于对迁移的评估以及现有的Yahoo!Photos数器，我们对存需求做了最好的估计，并给出了一个宽松的安全系统，确保迁移结束之前，不会出现存空间不够的情况。我们能想到的每件事情，都有测量数据:

●迁移的账户

●迁移的照片

●处理的照片

●迁移队列大小

●磁盘空间消耗量

对选择迁移到Flickr的用户，开始迁移过程，并进行观察

我直接联到有意思的部分来说吧:即使微了如此谨慎的估计，我们还是错了，错大了。虽然做了研究，对存猪容量做了精心的评估，想迁近移到Fick来的人还是超出了我们的预期。要把想迁移到Flickr来的人的Yhoo!Photos数据都近移过来的话，我们部看的存猪空间都会用完。要么增加存猪，要么Flickr停止上载片。

調天地，由于测量数据能够追踪磁を请耗，我们很快意识到了这点，但却受限于采购时间表。重要的是尽快购买、安装、配置、部署更多存造，以免用完现有存。部著更多空间与迁移进程之间展开了一场竞赛，

为了解释我们是如何通过测量数据反转危为安的，要先介绍一下迁移过程是如何进行的:

1.告知用户，将关闭Yahoo!Photos服务，用户可以从列表中选择迁移到哪里。假如选择Flickr的话，该用户账号就进人迁移队列。

2.一旦用户的迁移任务进入队列，则则锁定该用户的Yahoo!Photos账号，防止用户进行修改。现在Yahoo!Photos和Flickr之间进行API对API的通信，以获取要迁移的照片数据。

3.Flickr获取并处理Yahoo!Photos账号的照片及其元数据。

4.将Yahoo!Photos账号写人Flickr存储和数据库。

迁移完成后，开放Flickr这边的账号，通知用户可以使用迁移过来的Flickr新账号了。单个用户的迁移并不需要很长时间，但用户量很大，所以还是花了不少时间。迁移过程基本上就是一个大规模的异步过程，每个异步过程包括创建Flickr新账号和批量上载照片。

由于知道迁移要消耗多少存储、“有机”(非迁移)增长要消耗多少存储，即使估计不足的话，也可以预测出还能够支持的天数。我们下了一个庞大的订单，来购买存储，并开始计时。确认了发货和安装日期，这样我们就知道这些存储什么时候能够在数据中心上架以及需要多久才能投入使用。

因为使用Ganglia采集数据，3行脚本代码就可以计算出存储的消耗率，然后将这个数字传给负责迁移的API进程。照片是存储在分布于美国各地的若干个数据中心的，要确保API进程能够远程获得这个值，并检查正在迁移数据的所有数据中心。我们修改了API的处理过程，以便观察存储消耗的速率。如果在过去的一小时存储的消耗率大于维持到新存储上线那天的消耗率，则降低对排队等待迁移的账号的处理速度，反之，则加快处理速度。前面列出的步骤中，我们在步骤2和步骤3之间插入了一个检查当前存储消耗率的步骤。

因为我们会根据存储的消耗率调整迁移的速度，进入队列的账号可能会等待更长的时间。减慢处理过程也是一个不得已的折中，既要保证迁移的顺利进行，又要不影响Flickr的当前业务。

最终，迁移顺利完成，没有发生存储空间用光的情况。事后看来，我们的估计是有偏差的，但并没有当初想的那么大。迁移开始时的高峰使我们担心存储会用光，所以马上部署了更多的存储。但随着渐渐接近原来的存储极限，进入迁移队列的用户也慢慢减少了

这个故事说明，将分布在全国多个地点的网站建设测量数据采集系统纳入反馈循环，能够将PB级照片数据从Yahoo!Photos安全地迁移到Flickr，同日时基本不影响两者的正常使用。