RabbitMQ vs Kafka - ¿Cuál escoger?
Vložit
- čas přidán 17. 01. 2024
- RabbitMQ y Kafka son dos de los sistemas de mensajería más famosos que existen. En este vídeo los comparamos como message brokers, vemos todo su potencia y, sobretodo, veremos cuál escoger para una arquitectura basada en eventos.
→ Curso RabbitMQ: bit.ly/curso-rabbitmq
﹤🍍﹥ Codely
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🔖 Cursos: bit.ly/cursos-codely
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv - Věda a technologie
No me he enterado de nada pero os felicito por el video. Por cierto, vaya pelazo que se ha dejado Rafita, está en su prime.
Buen vídeo
Aclarar que RabbitMQ también tiene la opción de persistir los mensajes en disco, se especifica con una propiedad (Delivery mode) cuando se va a publicar el mensaje en la cola.
Muy buena aclaración. Además el concepto topic tambien existe en RabbitMQ y es distino a del exchange tradicional. Aquí se ve la clásica configuración con AQMP pero ahora que RabbitMQ se utiliza mucho para IoT con MQTT el uso de topics es muy importante.
excelente video, si bien no estoy trabajando en la rama informática todavía, cada vez que veo sus videos me dan mas ganas de aprender en sus cursos.
Realmente cada cosa que hacen se ve muy didáctico, profesional y estéticamente perfecto, saludos desde Argentina.
Ayudaría mucho renovar el curso de Event Sourcing, estária de lujo con Typescript, PHP o Java, el actual no es muy claro :/
muy buena explicacion, yo uso azure service bus y algunas cosas que han mencionado existen en ese servicio
Gracias por el vídeo.
La explicación ha sido increíble.
4:33 - Procesamiento con RabbitMQ
Gracias por estos vídeos!
Brutal la explicación, la parte de Kafka y los consumer groups tiene su miga
muchas gracias compas , me ayudo mucho , he manejado rabbit pero kafka no , la verdad muy way como dicen ustedes , la verdad estaria bueno un curso de kafka como el que tienen de rabbit
Kafka está a otro nivel. Una maravilla usarlo. Súper tuneable y alto rendimiento.
Trabajaba en un lado donde era el backbone de toda la plataforma (un SaaS XDR CyberSec). Todo se hacia dentro de un pipeline gigante (manejado por eventos). En cuanto carga, la plataforma tiene operaciones en todo el mundo (LATAM, APAC, EU, NA) y Los servicios eran casi todos Go.
Excele,te explicacion, nuchas gracias!
Gracias por la información, muy buena y didactica.
Gracias por el comentario!!
Magnifica explication !
¡Gracias! Es un vídeo al que le hemos dedicado bastante cariño :)
Grandes!
Exelente video
Muy bueno 👏👏
Buena comparativa, felicidades y gran trabajo. La magia en Kafka no solo está en los consumidores y la persistencia. Añadiría y/o revisaría los productores, los distintos sistemas de ingesta, serialización (Avro, Protobuff, etc), compresión y componentes como el schema registry, creo que serían interesantes que se comentasen. Mis dos centimos y felicidades de nuevo.
Por otra parte... usar topics como sistemas de persistencia, lo hacen muy atractivo y su replicación es bastante sencillo. Creo que el New York Times, tiene un histórico de artículos guardados en topics de kafka.
Avro + Schema registry = ❤️
Consulta, si quiero instalar Kafka o RabbitMQ en un AKS Cluster (Kubernetes) existe algún tipo de UI para ellos?
NATS tambien va bien segun para que
En mi trabajo actual ocupamos pubsub de gcp es parecido a rabbitmq
¿Algún videito para escalar horizontalmente Rabbit?
Sería bueno que RabbitMQ soporte transacciones XA y manejo de estados
Deberían hablar de NATS Jetstream en un momento, es bastante potente y simple...
Para cuando un curso de kafka
Y la programación y demo?
deberiais considerar Pulsar, que cojio lo mejor de ambos mundos. y esta muy bien diseñada para sistemas mutltidominio.
No entendí un carajo...pero muy interesante
Hola, esto es backend? Gracias
Si, en cierta manera ... son herramientas a parte, pero orientadas a gestión de procesos de backend. Seria mas de arquitectura de software ...
Me ocurrio con Nestjs y Kafka que tenia 2 consumer tratando de optener un mismo topic, y uno de ellos no recibia nada... Aun Estoy tratando de aprender un poco más del tema para tener mas particiones. Excelente video.
Si son del mismo grupo, se "pelearán" por obtener primero el mensaje, tienen que pertenecer a un distinto group_id para que no ocurra este tipo de "race condition"
@@eliseohenriquezhenriquez8589 Nadie se pelea por obtener primero ningun mensaje, hay un arbitro en el lado del cluster de Kafka y ese arbitro decide quien va a ser uno de los consumidores que puede asignar (determinado por el numero de particiones), en el momento en el que es asignado ya lo será hasta que pase algo que fuerce la reeleccion, como que se caiga el consumidor, si levantas 5 consumidores y hay 1 partición, no es que vayan a estar peleandose siempre por leer el siguiente mensaje, habra 1 que los recibirá siempre y los otros 4 estarán mirando la pared hasta que el primer consumidor no pueda continuar y toque la reelección. También puede pasar la reelección por algo que le ocurra al cluster de kafka, por ejemplo, cuando se actualiza el servidor, ocurre la reelección
@@eliseohenriquezhenriquez8589casi que siempre toca cubrirse de la race condición, porque si tienes varias instancias quiere decir que tienes varios consumidores que apuntan a un mismo group. Toca meterle algún lock.
Tenemos pensado migrar nuestro viejo código legacy monolítico a algo con arquitectura hex y ddd, y cómo no, usar colas, pero teníamos en mente usar SQS, aprovechando que toda nuestra infraestructura está en AWS. ¿Desaconsejais SQS en favor de RabbitMQ? Saludos y gracias por estos vídeos!
SNS + SQS es muy top también! Y desde el punto de vista de mantener el servicio es más sencillo. Seguramente dentro de unos meses hagamos contenido de ello 🙌
Desde el punto de vista de la availability y scalability siempre que puedan les va a convenir usar SNS y SQS, a Amazon MQ (sea rabbit o activemq) porque en el segundo caso van a tener que crear los servidores uds así como el tipo de maquina de cu, crear cluster si es mas de uno, etc.. y siempre alguien puede borrar sin querer un server o apagarlo por error. En cambio usando sns y sqs eso no pasa, aws se encarga de todo. Pero amazon mq se comporta diferente a sns y sqs, y sns y sqs tiene tambien sus tipos de colas y cu con sus limites (fifo y no fifo), asi que mi recomendacion seria leer bien todo directo de la documentacion de AWS que es el mejor lugar para aprender, evaluen costos, etc..
SNS = Publisher subscriber model, 0 subscribers, los mensajes se pierden. PUSH
SQS = Publisher consumers model, 0 consumers, los mensajes NO se pierden. PULL
hola, consulto lo siguiente. Si envio un mensaje que es atendido por 5 microservicios y 2 de ellos no pueden realizar la operación, ¿cómo y que se se informa al productor? , ¿existe alguna estrategia alternativa para controlar situacion?. gracias y saludos
Buenas!
Aquí lo explicamos: Cómo gestionar Errores en un Sistema de Mensajería
czcams.com/video/GfQGgqeKgVQ/video.html
muchas gracias, lo veo!
Recomiendo investigar de NATs, super mas potente y eficiente que kafka
perdonad, el ack en kafka si existe pero se sitúa en el productor:
- acks=0 (sin acknowledgment): El productor no espera ninguna confirmación después de enviar el mensaje. Esto implica un menor nivel de garantía y puede resultar en la pérdida de mensajes en caso de que el líder (leader) del tema no haya confirmado la recepción del mensaje antes de que ocurra un fallo.
- acks=1 (acknowledgment del líder): El productor recibe una confirmación después de que el líder del tema ha recibido el mensaje. Esto proporciona un nivel medio de garantía, ya que el líder debería haber replicado el mensaje antes de confirmar su recepción.
- acks=all (acknowledgment de todos los replicas): El productor recibe una confirmación después de que todos los replicas en el conjunto de inscritos hayan recibido el mensaje. Este nivel de garantía es el más alto pero también puede tener un impacto en la latencia debido a la espera de la sincronización entre replicas.
Totalmente, gracias por la aclaración y el aporte!
En el vídeo nos referimos a que no existe del mismo modo que RabbitMQ, que un ack hace que se borre el mensaje ya procesado. 🙌
Excelente, a mi tambien me llamo la atencion al momento de aseverar que no existe el ack en kafka, en conclusion, se debe escuchar pero no se debe dar por cierto todo lo que diga
jetstream o apache pulsar
Pulsar es maravilla también! 👌
NATS
Normalmente veo más puestos de trabajo para RabbitMQ
Donde? Cualquier gran empresa elige Kafka por escalado
@@kzelmer Exacto . en Linkedin la mayoria de ofertas que he visto son de Kafka
Al fin se puso serio el canal y se dejó de hablar de esa porqueria de PHP ... muy bien !!!
Sentimos decepcionarte, pero seguiremos hablando de PHP. Y de Java, de TypeScript, y en resumen de todo donde apliquen buenas prácticas y arquitectura de software. En la variedad está la gracia. Así te puedes quedar con lo bueno de cada mundo y valorar con mayor criterio 😊
Si es cierto lo importante es las buenas prácticas y la arquitectura de software por encima del código, plataforma etc... Pero también de alguna manera estoy de acuerdo que PHP tiene un tufillo de caducado. Sería interesante ya que hablan de diversidad entonces muestren o comprueben estos principios y prácticas en Golang, Rust y Flutter con Dart. Son desafios interesantes, por demás igual agradecer por el espacio y por compartir sus conocimientos.
PD: Me gustaría que se hablara también de Cloud Pub/Sub de Google Cloud que también es un servicio de mensajeria!
@@CodelyTV Esta bien. Voy a estar atento a los temas serios y con proyeccion.
que usas como lenguaje para tu backend? por que tanto odio?
Que es chicha ??
Chicha se suele usar en España para referirse a “carne”. Usado por ejemplo como “vamos a ver dónde está la chicha del ejemplo” querría decir algo como “vamos a ver dónde está lo interesante/complejo/jugoso del ejemplo”
😂
Rrrrrredemption.
Ese deeelrriiooo queeee rrricoooooo
Buenas, quien haya trabajado con colas mq y Kafka sabe perfectamente que las colas jms son una 💩. Kafka es mucho mejor.
Una cosa que decís mal es que Kafka no exactly_once y si la gente no sabe manejar Kafka no es problema Kafka. Kafka es exacly_once. Y las colas jms no lo son. Y os lo puedo explicar con miles de ejemplos. Llevo años trabajando con aplicaciones streaming
Esto no es del todo cierto. Con las colas de tipo stream en rabbitmq no se eliminan los eventos.
laravel tiene su propio sistema de colas, seria bueno que hablen que tan rentable es usar laravel queue?
Que tiene que ver Laravel Queue con esto? En el vídeo se habla de dos de los brokers de mensajes más famosos. Laravel Queue es una simple librería, para gestionar cosas en segundo plano y que además te permite trabajar con los brokers más comunes o.0
Laravel queue no tiene comparación porque es susceptible a fallos, si se cae la instancia se pierde la cola, no puede manejar un gran volumen de información, la gestión de colas que tiene es muy básica. En cambio Kafka y RabitMQ son los brokers que pueden manejarse como clusters para aumentar su alta disponibilidad y paralelismo. La diferencia es que en la utilidad estos sirven para publicar mensajes en series de tiempo como por ejemplo sincronizar el consumo eléctrico por hora de contadores de luz o eventos create, update y delete de una tabla. Cómo podrás ver estos casos son de volúmenes muy grande. Kafka es más usado para streaming, RabitMQ para flujos de trabajo pendientes y publicaciones de eventos o control de API ( una API que límite por ejemplo max 100 requests por min, entonces es mejor usar colas y eventos). También he visto que varios proveedores de servicios de software publican su RSS de cambios de schema a través de RabitMQ, es muy útil cuando se requiere replicar para evitar que un ETL falle. En fin, laravel queue para proyectos en dónde no estén relacionados con finanzas, ventas, salud o blockchain. Si el problema es pequeño y no requieres escalabilidad o confiabilidad puedes usar laravel queue sin problemas.
Mucho hate a Laravel jaja, solo es un comentario 😅...
Elixir hace esto solo
Cerrar el 0rt0 con tus lenguajes para gente con autoestima que depende de cuántos lenguaje de programación sepas
Dentro de aws estan sns y sqs que comparaciones se puede tener.
SNS = Publisher subscriber model, 0 subscribers, los mensajes se pierden. PUSH
SQS = Publisher consumers model, 0 consumers, los mensajes NO se pierden. PULL