Choisir une solution de mémoire partagée distribuée
J'ai une tâche pour construire un prototype pour une application de mémoire partagée distribuée (DSM) massivement évolutive. Le prototype ne servirait que de preuve de concept, mais je veux passer mon temps le plus efficacement possible en choisissant les composants qui seraient utilisés dans la vraie solution plus tard.
Le but de cette solution est de prendre des données en entrée à partir d'une source externe, de les désabonner et de rendre le résultat disponible pour un certain nombre de frontend. Ces "interfaces" prendraient simplement les données du cache et serviraient sans traitement supplémentaire. La quantité de visites frontend sur ces données peut littéralement être des millions par seconde.
Les données elles-mêmes sont très volatiles; elles peuvent (et changent) assez rapidement. Cependant, les interfaces devraient voir les" anciennes " données jusqu'à ce que les plus récentes aient été traitées et mises en cache. Le traitement et l'écriture sont effectués par un seul nœud (redondant) tandis que les autres nœuds ne lisent que les données. En d'autres termes: pas de comportement de lecture.
Je cherchais des solutions comme memcached cependant, celui-ci ne remplit pas toutes les nos exigences qui sont énumérées ci-dessous:
- La solution doit au moins avoir Java client API qui est raisonnablement bien entretenu car le reste de l'application est écrit en Java et nous sommes des développeurs Java chevronnés;
- , La solution doit être totalement élastique: il devrait être possible d'ajouter de nouveaux nœuds sans redémarrer les autres nœuds du cluster;
- , La solution doit être capable de gérer basculement. Oui, je me rends compte que cela signifie des frais généraux, mais la taille globale des données servies n'est pas grande (1G max), donc cela ne devrait pas être un problème. Par" basculement", j'entends une exécution transparente sans codage en dur/modification de l'adresse IP du serveur comme dans les clients memcached lorsqu'un nœud tombe en panne;
- Idéalement, il devrait être possible de spécifier le degré de chevauchement des données (par exemple, combien de copies des mêmes données doivent être stockées dans le cluster DSM);
- Il n'est pas nécessaire de stocker en permanence toutes les données mais il peut y avoir un besoin de post-traitement de certaines données (par exemple, la sérialisation de la DB).
- Prix. Évidemment, nous préférons le free / open source mais nous sommes heureux de payer un montant raisonnable si une solution en vaut la peine. De toute façon, payé 24h / jour contrat de soutien est un must.
- Le tout doit être hébergé dans nos centres de données donc les offres SaaS comme Amazon SimpleDB sont hors de portée. Nous ne considérerions cela que si aucune autre option ne le serait disponible.
- , Idéalement, la solution serait strictement conforme (comme dans PAC); toutefois, éventuelle consistance peut être considéré comme une option.
Merci d'avance pour toutes les idées.
8 answers
Jetez un oeil àHazelcast . Il est pur Java, open source (licence Apache) produit de grille de données en mémoire hautement évolutive. Il offre un support 7X24. Et cela résout tous vos problèmes, j'ai essayé d'expliquer chacun d'eux ci-dessous:
- Il a un client Java natif.
- Il est 100% dynamique. Ajouter et supprimer des nœuds dynamiquement. Pas besoin de changer quoi que ce soit.
- Encore une fois tout est dynamique.
- Vous pouvez configurer le nombre de nœuds de sauvegarde.
- Hazelcast soutenez la persistance.
- Tout ce que Hazelcast offre est gratuit(open source) et il offre un support au niveau de l'entreprise.
- Hazelcast est un fichier jar unique. super facile à utiliser. Ajoutez simplement jar à votre chemin de classe. Jetez un oeil à screen cast dans la page principale.
- Hazelcast est strictement cohérent. Vous ne pouvez jamais lire des données périmées.
Je vous suggère d'utiliser Redisson - Grille de données en mémoire basée sur Redis pour Java. Met en œuvre (BitSet, BloomFilter, Set, SortedSet, Map, ConcurrentMap, List, Queue, Deque, BlockingQueue, BlockingDeque, ReadWriteLock, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, RemoteService, ExecutorService, LiveObjectService, SchedulerService) sur le dessus de Redis serveur! Il prend en charge les modes maître/esclave, sentinelle et serveur de cluster. Détection automatique de la topologie des serveurs cluster/sentinel prise en charge également. Cette lib est gratuite et open-source.
Fonctionne Parfaitement dans cloud grâce au support AWS Elasticache
Selon ce que vous préférez, je suivrais sûrement les autres en suggérant Hazelcast si vous êtes vers AP du théorème CAP mais si vous avez besoin de CP, je choisirais Redis
Vous voudrez peut-être extraire des solutions spécifiques à Java comme Coherence: http://www.oracle.com/global/ru/products/middleware/coherence/index.html
Cependant, je considère que de telles solutions sont trop complexes et je préfère utiliser des solutions comme memcached. Le gros inconvénient de memcached pour votre but est le manque de verrouillage d'enregistrement, il semble et il n'y a pas de moyen intégré de répliquer les données pour le basculement. C'est pourquoi je voudrais regarder dans les magasins de données clé-valeur. Beaucoup d'entre eux répondraient à vos besoins complètement.
Voici une liste de magasins de données clé-valeur qui peuvent vous aider dans votre tâche: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores Il suffit de choisir un que vous remplissez à l'aise avec.
Jetez un oeil au clustering JVM de Terracotta, c'est OpenSource ;) Il n'a pas d'API alors qu'il fonctionne efficacement au niveau de la JVM, lorsque vous stockez la valeur dans un objet répliqué, elle est envoyée à tous les autres nœuds. Même le verrouillage et toutes ces choses fonctionnent de manière transparente et sans ajouter de nouveau code.
Je fais un projet similaire, mais je cible plutôt la plate-forme.NET. En dehors des solutions déjà mentionnées, je pense que vous devriez jeter un oeil à ScaleOut StateServer et Alachisoft NCache. Je crains qu'aucune de ces alternatives ne soit bon marché, mais elles sont un pari plus sûr que l'open source pour les solutions commerciales selon mon jugement.
- Les deux fournissent des API client Java, même si je n'ai joué qu'avec les API.NET.
- StateServer caractéristiques auto-découverte de nouveaux nœuds de cache, et NCache a une console de gestion où de nouveaux nœuds de cache peuvent être ajoutés.
- Les deux devraient pouvoir gérer les basculements de manière transparente.
- StateServer peut avoir 1 ou 2 copies passives des données. NCache propose plus de topologies de mise en cache entre lesquelles choisir.
- Si vous voulez dire write-through/write-behind dans une base de données disponible dans les deux.
- Je n'ai aucune idée du nombre de serveurs de cache que vous prévoyez d'utiliser, mais voici le prix complet cifications: ScaleOut StateServer Alachisoft NCache
- Les deux sont installés et configurés localement sur votre serveur et ils ont tous deux la gestion de l'interface graphique.
- Je ne sais pas exactement ce que strictement cohérent implique, donc je vais laisser cela pour vous d'enquêter..
Dans l'ensemble, StateServer est la meilleure option si vous souhaitez ignorer la configuration de chaque petit détail dans le cluster de cache, tandis que NCache propose de très nombreuses fonctionnalités et topologies de mise en cache à choisir de.
Selon le comportement des données envers les clients (si les données sont lues plusieurs fois à partir du même client), il peut être judicieux de mélanger la mise en cache locale sur les clients avec la mise en cache distribuée dans le cluster (disponible pour NCache et StateServer), juste une pensée.
Le cas d'utilisation spécifié semble correspondre au Hollow de Netflix. Il s'agit d'un cache répliqué en lecture seule avec un seul producteur et plusieurs consommateurs.
Avez-vous pensé à utiliser une solution de messagerie standard commerabbitmq ? RabbitMQ est une implémentation open source du protocoleAMQP .
Votre application ressemble plus ou moins à un système de publication/abonnement. Le nœud Publisher est celui qui effectue le traitement et place les messages (données traitées) dans une file d'attente dans les serveurs. Les abonnés peuvent recevoir des messages du serveur de différentes manières. AMQP dissocie le producteur et le consommateur de messages et est très souple dans la façon dont vous pouvez combiner les deux côtés.