RabbitMQ vs Kafka - ¿Cuál escoger?

[@MariaMartinez-xy8zd]

Quiero llorar, un vídeo en CASTELLANO suuper bién explicado, dinámico y entretenido donde lo entiendes TODO. GRACIASSS

[@CodelyTV]

Gracias por el comentario 😊😊😊

[@mullinslol]

Brutal la explicación, la parte de Kafka y los consumer groups tiene su miga

[@jesusmartinezmendez680]

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.

[@pubdigitalix]

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.

[@miguelpayran9509]

Tengo algo parecido, tengo deployado Rabbit en kubernetes usando un PVC y si se llega. a morir el rabbit, puedo usar los datos en disco, asi no pierdo información.

[@JhonasVe]

@@pubdigitalix En el minuto 25 lo comentan

[@IVANLUISLG]

muy buena explicacion, yo uso azure service bus y algunas cosas que han mencionado existen en ese servicio

[@miguelangelrodriguezgomez2138]

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.

[@alonsoruiz6315]

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.

[@gustavoangelsanchez5170]

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.

[@roboto0101]

Gracias por el vídeo. La explicación ha sido increíble. 4:33 - Procesamiento con RabbitMQ

[@__renesan]

Ayudaría mucho renovar el curso de Event Sourcing, estária de lujo con Typescript, PHP o Java, el actual no es muy claro :/

[@jesusarmandomaciasbenitez1517]

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

[@RamiroAsincrono]

Gracias por estos vídeos!

[@jhairagila3185]

Excelente explicación

[@carmelocotonable]

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.

[@CodelyTV]

Avro + Schema registry = ❤️

[@BackDoorMann]

Un vídeo muy bueno y bastante ameno de ver. A el muchacho Jack&Jones no se le entiende mucho. Parece que se come algunas sílabas cuando habla? O el vídeo tiene errores de edición. Buen trabajo.

[@joaquindiez]

deberiais considerar Pulsar, que cojio lo mejor de ambos mundos. y esta muy bien diseñada para sistemas mutltidominio.

[@Clovhis]

Consulta, si quiero instalar Kafka o RabbitMQ en un AKS Cluster (Kubernetes) existe algún tipo de UI para ellos?

[@Alberto_APC91]

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.

[@puduwatom]

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"

[@JorgeDev92]

@@puduwatom 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

[@kmiiloberrio-dev]

@@puduwatomcasi 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.

[@devjaime]

En mi trabajo actual ocupamos pubsub de gcp es parecido a rabbitmq

[@padaone777]

Hola, esto es backend? Gracias

[@yo-meeguen5822]

Si, en cierta manera ... son herramientas a parte, pero orientadas a gestión de procesos de backend. Seria mas de arquitectura de software ...

[@appsky7982]

Sería bueno que RabbitMQ soporte transacciones XA y manejo de estados

[@Jefferson4026]

Intente integrar kafka con laravel y fue imposible , no logré hacerlo En cambio rabbitmq es super fácil de configurar

[@JoseRolandoVillegasMendizabal]

Gracias por la información, muy buena y didactica.

[@CodelyTV]

Gracias por el comentario!!

[@JorgeZapata8]

Excele,te explicacion, nuchas gracias!

[@tbl6625]

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.

[@CodelyTV]

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. 🙌

[@oscarjoseantoniopintosalaz6600]

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

[@nixjavi7220]

Magnifica explication !

[@CodelyTV]

¡Gracias! Es un vídeo al que le hemos dedicado bastante cariño :)

[@aleman7]

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

[@CodelyTV]

Buenas! Aquí lo explicamos: Cómo gestionar Errores en un Sistema de Mensajería kzbin.info/www/bejne/fZe0eJqnmrCajLM

[@aleman7]

muchas gracias, lo veo!

[@djthdinsessions]

NATS tambien va bien segun para que

[@lmarts]

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!

[@CodelyTV]

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 🙌

[@barrenaedu]

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..

[@barrenaedu]

SNS = Publisher subscriber model, 0 subscribers, los mensajes se pierden. PUSH SQS = Publisher consumers model, 0 consumers, los mensajes NO se pierden. PULL

[@imarsuarez913]

Para cuando un curso de kafka

[@crayder03]

¿Algún videito para escalar horizontalmente Rabbit?

[@DesingFxTube]

Deberían hablar de NATS Jetstream en un momento, es bastante potente y simple...

[@VRedondoQ]

Recomiendo investigar de NATs, super mas potente y eficiente que kafka

[@joffreveloz2410]

Exelente video

[@armandojorgelopezespinoza476]

Y la programación y demo?

[@lucasgorordo5111]

Muy bueno 👏👏

[@Darknessrd666]

kafka hibino sin duda

[@cherrejim]

Grandes!

[@andresgiraldop.6825]

No entendí un carajo...pero muy interesante

[@carloss3028]

Normalmente veo más puestos de trabajo para RabbitMQ

[@kzelmer]

Donde? Cualquier gran empresa elige Kafka por escalado

[@CarlosReyesVDev]

@@kzelmer Exacto . en Linkedin la mayoria de ofertas que he visto son de Kafka

[@user-tz6nn8iw9m]

jetstream o apache pulsar

[@CodelyTV]

Pulsar es maravilla también! 👌

[@crisegam6285]

Al fin se puso serio el canal y se dejó de hablar de esa porqueria de PHP ... muy bien !!!

[@CodelyTV]

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 😊

[@nelsonscript]

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!

[@crisegam6285]

@@CodelyTV Esta bien. Voy a estar atento a los temas serios y con proyeccion.

[@ULISESGERMAN]

que usas como lenguaje para tu backend? por que tanto odio?

[@0nesX0]

Que es chicha ??

[@CodelyTV]

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”

[@BrunoVillasanti]

😂

[@nathanmartinez8843]

NATS

[@alvaromarin144]

Esto no es del todo cierto. Con las colas de tipo stream en rabbitmq no se eliminan los eventos.

[@TheCreativeHenry]

laravel tiene su propio sistema de colas, seria bueno que hablen que tan rentable es usar laravel queue?

[@kuja69]

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

[@Sapop3rro]

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.

[@__cpmarcelo]

Mucho hate a Laravel jaja, solo es un comentario 😅...

[@orioldelrio4789]

Rrrrrredemption.

[@CodelyTV]

Ese deeelrriiooo queeee rrricoooooo

[@LuiTrO-]

Buenas, quien haya trabajado con colas mq y Kafka sabe perfectamente que las colas jms son una 💩. Kafka es mucho mejor.

[@LuiTrO-]

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

[@ronindevninja]

Elixir hace esto solo

[@espartangod]

Cerrar el 0rt0 con tus lenguajes para gente con autoestima que depende de cuántos lenguaje de programación sepas