En tant qu'auteur de spymemcached , je suis un peu biaisé, mais je dirais que c'est le mien pour les raisons suivantes:
Conçu à partir de zéro pour être non bloquant partout possible.
Lorsque vous demandez des données, émettez un ensemble, etc ... il y a une petite insertion de file d'attente simultanée et vous obtenez un Future pour bloquer les résultats (avec certaines méthodes pratiques pour les cas courants comme get).
Optimisé de manière agressive
Vous pouvez en savoir plus sur ma page optimisations , mais je fais l'optimisation de l'application entière.
Je fais toujours assez bien dans les micro-benchmarks, mais pour comparer équitablement avec l'autre client, vous devez créer des modèles d'utilisation irréalistes (par exemple, attendre la réponse à chaque opération définie ou créer des verrous pour les empêcher de faire l'optimisation des paquets ).
Testé de manière obsessionnelle
Je maintiens une suite de tests assez rigoureuse avec rapports de couverture sur chaque version.
Les bogues se glissent toujours, mais ils sont généralement assez mineurs et le client ne cesse de s'améliorer. :)
Bien documenté
La page exemples fournit une introduction rapide, mais la page javadoc est extrêmement détaillée.
Fournit des abstractions de haut niveau
J'ai une interface Map vers le cache ainsi qu'une abstraction CAS fonctionnelle. Le binaire et le texte prennent en charge un mécanisme incr-with-default (fourni par le protocole binaire, mais plutôt délicat dans le texte).
Reste avec les spécifications
Je fais un beaucoup de travail sur le serveur lui-même, donc je continue avec les changements de protocole.
J'ai fait les premières implémentations de serveur de protocole binaire (à la fois un serveur de test et memcached lui-même), et ce fut le premier client prêt pour la production à le prendre en charge, et le fait de première classe.
J'ai également pris en charge plusieurs algorithmes de hachage et algorithmes de distribution de nœuds, qui sont tous bien testés pour chaque génération. Vous pouvez faire un hachage cohérent ketama ou un dérivé en utilisant FNV-1 (ou même le hachage de chaîne natif de Java) si vous voulez de meilleures performances.
Je crois que memcached Java client est le meilleur client.
Caractéristiques
- Prise en charge du protocole binaire . moyen le plus rapide d'accéder à la clé/valeur stockée dans le serveur memcached.
- Prise en charge du protocole UDP . Vous pouvez définir la clé avec le protocole tcp et obtenir avec le protocole udp. En fait, certaines grandes sociétés font comme ça.
- Prend en charge la sérialisation et la désérialisation personnalisées.
- Pool de connexions avec NIO et tampon direct. Augmentez dynamiquement les connexions lorsque vous n'êtes pas utilisé pour le pool de connexions.
Performance
- Reportez-vous à performance pour un test de référence des clients memcached populaires existants Java clients.
- Désérialisation lors de la réception de la réponse
- Optimisation des performances dans chaque ligne du code source.
Si ce sont des nombres toujours valides, alors ... http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html
Il y a environ un an, lorsque j'ai dû utiliser un client memcached Java, le connecteur spymemcached a été décrit comme une API optimisée avec plus de fonctionnalités. Depuis, il y a eu un certain nombre de nouvelles versions du client memcached, il peut donc être utile de vérifier.
FWIW, le client espion a parfaitement fonctionné pour moi.
J'utilise SpyMemcached et je dois admettre que c'est le meilleur disponible sur le marché, avec de nombreuses améliorations plus récentes.
Il y a client memcached pour Java et spymemcached . Mais pas beaucoup d'expérience avec.
Veuillez essayer xmemcached , il est également basé sur nio et possède des fonctionnalités puissantes.