Répartition de charge avec une architecture asynchrone
Avec ce titre pompeux je voulais depuis longtemps écrire un article sur ce thème. Je l’avais un peu abordé avec ce billet sur beanstalkd, cependant je désirais en parler de manière plus généraliste.
Finalement le Grand Ternet a encore une fois encouragé ma feignantise car j’ai trouvé cette suite de 3 petits excellents articles sur haute-disponibilite.net qui expliquent très bien ce domaine :
- Communiquer via une file d’attente de message, 1
- Communiquer via une file d’attente de message, 2
- Communiquer via une file d’attente de message, 3
A compléter avec cet article très riche d’un co-fondateur de last.fm : Anti-RDBMS: A list of distributed key-value stores. Il faut ajouter à cette liste déjà imposante l’étonnant Tokyo cabinet ainsi que nanite basé sur RabbitMQ et cela démontrera aux plus incrédules l’importance d’un bon backend asynchrone et les énormes avantages que cela apporte en terme de réactivité pour l’utilisateur.
Cependant la tentation sera certainement de plus en plus grande d’utiliser les technologies clés en main de cloud computing offertes par Google et Amazon… A quand un service de cloud computing opensource à disposition uniquement, bien sûr, des sites opensource ? 
Pour finir, à lire également l’excellent article de Greg, {key, value} qui comporte des détails techniques et des exemples (attention par contre sur la partie memcached, car memcachedb ou memcacheq seront plus pertinent pour cet usage).
