Een schaalbare Twitter-gegevensadapter ontwikkelen

We bouwen een Twitter-adapter voor ons productplatform om tweets te verzamelen met zowel Search API als Streaming API. We hebben een prototype ontwikkeld dat gebruik maakt van Java Executor Service en Twitter4j om tweets te verzamelen en in te dienen ze naar onze wachtrij voor tweets.

Hier zijn enkele ontwerpbeslissingen waarvoor we suggesties zouden willen doen over:

  1. Hoe kan de adapterclient schaalbaar en fouttolerant worden gemaakt?
  2. Hoe voorkom je het ophalen van dubbele tweets?
  3. Hoe het ophalen van tweets met meerdere gebruikers-ID te maximaliseren zonder de snelheidslimiet te raken?
0
toegevoegd
Bekeken: 1
de bron
ja ru fr pt de

1 antwoord

Some answers , but bare in mind it has been awhile since I used twitter API -

In order to make the adaptor scalable and fault tolerant you can consider the following techniques -

  1. Use several instances (i.e - clustering) of your client- it really depends what it does, but you may decide to use an Active-Active or Active-Passive clustering model
  2. If you go for clustering - Do you have clients connecting to the adapter? If so , you will need a load balancer that supports sticky session (so during a given session, a client addresses the same Adapter instance) - check [this][1] link for some info.
  3. I recommend you use caching for twitts - and if we look at a cache as map of key to value, and then your key can probably the URL that you use in order to get the information from Twitter API (If I recall, the API is some sort of a RESTful web service)
    You should set eviction policies on the cache (i.e - how long the data is considered relevant for you) - this may help you both in performance, and both to reduce the number of accesses to twitter (I'm referring you to the part of your question about the rate limit).
  4. Maybe you should see if you can share information between users - but this will have some logic involved.
    An example - if user A follows user B, and B follows A, they might have more common followers or users they follow, and you can share data.
  5. If you go for clustering as I suggested before, your cache should be distributed. You can use EHCache for this
  6. If you store information at database - try to minimize data base accesses, by building a thread local bases caching system (so within a thread, if you perform twice get on the same ID for the same entity, without a write, you will not access the database twice...)

Kortom, dit is slechts een tip van een ijsberg voor advies, u moet uw vereisten zorgvuldig kennen, cases en flows gebruiken en bekijken hoe u elk van deze kunt optimaliseren.

1
toegevoegd
de bron