Va a mejor la cosa, tengo que hacer tests si o tambien porque no estoy
nada seguro si es que todo funciona como espero ya que toda llamada a la
api corresponde a una llamada a cache y descubrir si es que esta todo en
cache como se espera
Voy a terminar del modo que lo estoy haciendo y tal vez cambio esto a un
modulo de cache el cual se encargara de o obtener datos desde cache o
llamar a music brainz para suplir los datos que no puede responder
Resulta que django-redis es muy bonito pero esta pensado para usarse
como el cache por default de django, remplazando a memcached y por eso
no permite casi ninguna de las funcionalidades que redis permite, como
usar listas y sets.
Djang-redis permite usar el cliente directamente pero el codigo se
estaba haciendo largo y creando mas problemas de los que necesito
Asi que voy a usar el cliente regular, asi me evito dramas
Ya que no tengo limite de request por segundo a coverart archive solo
hago mas lento el worker default con las request hacia alla sumando a
que tengo que esperar a que termine el resto
En un worker separado no tengo esas limitaciones
Necesitaba un ratelimit que estuviera disponible en todos los workers,
cosa que aparentemente la libreria que estaba usando no tomaba en cuenta
asi que la mejor idea que tuve es aprovechar el cache y usarlo para
generar el ratelimit :3 asi que como todos los workers se comunican con
el mismo cache, todos van a compartir el mismo lock
Esto esta en proceso, se va a mover el cache a medium, donde se puede
controlar lo que se esta haciendo, ya que se planea que musicbrainz.py
sea simplemente una capa de conexion
Daniel Cortes