Опашките на Rabbit се намират в паметта и следователно ще бъдат много по-бързи от прилагането на това в база данни. Една (добра) специална опашка за съобщения трябва също така да предоставя основни функции, свързани с опашката, като регулиране/контрол на потока и възможност за избор на различни алгоритми за маршрутизиране, за да назовете двойка (заек предоставя тези и повече). В зависимост от размера на вашия проект, може също да искате компонентът за предаване на съобщения отделно от вашата база данни, така че ако единият компонент изпитва голямо натоварване, той да не пречи на работата на другия.
Що се отнася до проблемите, които споменахте:
-
анкета, поддържаща базата данни заета и ниска производителност :Използвайки Rabbitmq, производителите могат да натискат актуализации за потребителите, което е много по-ефективно от анкетата. Данните просто се изпращат на потребителя, когато е необходимо, елиминирайки нуждата от разточителни проверки.
-
заключване на масата -> отново ниска ефективност: Няма маса за заключване :P
-
милиони редове задачи -> отново анкетата е с ниска ефективност: Както бе споменато по-горе, Rabbitmq ще работи по-бързо, тъй като се намира в RAM и осигурява контрол на потока. Ако е необходимо, той може също да използва диска за временно съхраняване на съобщения, ако му свърши RAM. След 2.0, Rabbit значително подобри използването на RAM. Налични са и опции за групиране.
Що се отнася до AMQP, бих казал, че наистина страхотна функция е „борсата“ и възможността тя да се насочва към други борси. Това ви дава повече гъвкавост и ви позволява да създавате широк спектър от сложни типологии за маршрутизиране, които могат да бъдат много полезни при мащабиране. За добър пример вижте:
(източник:springsource.com)
и:http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
И накрая, по отношение на Redis, да, той може да се използва като посредник на съобщения и може да се справи добре. Въпреки това, Rabbitmq има повече функции за опашка за съобщения от Redis, тъй като rabbitmq е създаден от самото начало, за да бъде пълнофункционална специална опашка за съобщения на корпоративно ниво. Redis, от друга страна, е създаден предимно да бъде съхраняване на ключ-стойност в паметта (въпреки че сега прави много повече от това; дори се нарича швейцарско армейско ножче). Все пак съм чел/чувал много хора да постигат добри резултати с Redis за по-малки проекти, но не съм чувал много за това в по-големи приложения.
Ето пример за използване на Redis в изпълнение на чат с дълга анкета:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
