获取Twitter好友列表庞大的用户群和管理限速设计 [英] Design for getting Twitter friends list for large user base and managing rate limiting

查看:199
本文介绍了获取Twitter好友列表庞大的用户群和管理限速设计的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设有一个移动应用程序和服务器。

Assume there's a mobile app and a server.

我对速率限制和希望有人能对设计给一些建议为我敲我的脑袋上如何围绕限速导航问题。一定有什么东西我米失踪,因为每IP每小时150未认证的速率限制是非常低的。

I have question about rate limiting and hoping someone can give some advice on a design as I'm banging my head on how to navigate around rate limit. There must be something I"m missing because the 150 unauthenticated rate limit per IP per hour is extremely low.

想象一下,我要建立的情况是以下(简化为一个简单的例子这discusion)。 假设用户登录到Twitter的整个讨论删除有关OAuth的讨论。

Imagine the scenario I want to build is the following (simplified into a trivial example for this discusion). Assume user is signed into Twitter for this entire discussion to remove discussion about oAuth.

我们的服务移动谈判,以向用户显示Twitter好友列表。每一个移动应用程序被加载时,它会显示整个好友列表,并强调在最后2天添加的新朋友。

就是这样。但关键是,我想,以确保朋友列表始终是最新的客户端,这意味着我们的服务器必须有最新的最新的好友列表中。

That's it. But the trick is that I want to ensure that the friends list is always up to date in the client, which means our server has to have the most recent up to date friends list.

每隔一段时间,我想我的服务器自动扫描我的应用程序的每个用户的Twitter好友列表,查看是否有新的朋友已经加入。

Periodically, I want my server to automatically scan the Twitter friends list for every user of my app to see if new friends have been added.

我们的最初的设计是越来越我们的服务器来完成所有与此流程的工作:

Our initial design was getting our server to do all the work with this flow:


  1. 在客户端新用户的迹象,可以访问令牌服务器

  2. 服务器使得调用Twitter的REST API来获取最初的好友名单

  3. 服务器存储的Twitter好友的ID,并显示响应与列表中的客户端。

定期(例如每48小时),服务器将检查Twitter的REST API的朋友列表中为每个用户,并将其与我们的缓存Twitter好友列表中,我们必须让他们看到谁是新的,在移动应用凸显。

Periodically (e.g. every 48 hours), server checks Twitter REST APIs for friends list for each user and compares it to our cached Twitter friends list we have for them to see who is new and to highlight in the mobile app.

这个的好处是,所有与Twitter的互动来获得好友列表,比较和peridiocally刷新是在服务器上。移动客户端只是使一个调用到我的服务器并获取好友列表。

The good thing about this is that all the interaction with twitter to get friends list, compare and peridiocally refresh is on the server. Mobile client just makes a single call to my server and gets friends list.

这一设计的问题是,它会为单个用户的工作,但由于限速为150每小时上没有认证的电话,我会尽快打我的极限,151用户的用户我的服务(其中有一个固定IP)。

The problem with this design is that it will work for a single user, but since the rate limit is 150 per hour on un-authenticated calls, I will hit my limit as soon as 151 users user my service (which has a fixed IP).

我能看到的唯一的解决办法是让客户端做的工作为每个用户,然后给我的朋友列表,其中我的服务器缓存。这需要照顾上面的步骤#2。但是,对于第4步,我不得不建立一些到客户端自动刷新的Twitter好友,并发送回服务器。

The only solution I can see is to have the client do the work for each user, then send me the friends list which my server caches. This takes care of Step #2 above. However, for Step #4, I'd have to build something into the client to auto refresh twitter friends and send back to the server.

这是超级笨拙有这Twitter好友列表操作在所有参与的客户端。

This is super clumsy to have the client involved at all in this Twitter friends list operation.

起初我还以为我疯了,喜欢把自己的朋友列表中的非授权的API将不会受到速率限制。然而,根据他们的文档,它是。

At first I thought I was crazy and the public unauthenticated APIs like getting friends lists wouldn't be subject to rate limiting. However, according to their docs, it is.

我失去了一些东西明显或者是解决这个问题的唯一办法是把沉重的逻辑放到客户端?

推荐答案

既然你正在代表你应该让这些请求被认证为这些用户的用户的请求。然后,请求将计入​​每个用户350请求自己的游泳池/小时。

Since you are making request on behalf of users you should make those requests be authenticated as those users. Then requests will count against each users own pool of 350 requests/hour.

这篇关于获取Twitter好友列表庞大的用户群和管理限速设计的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆