Imperativo vs reactivo

Para comprender mejor el contraste entre los 2 mundos, necesitamos explicar la diferencia entre los modelos de ejecución reactiva e imperativa. 

En el enfoque tradicional e imperativo, los frameworks asignan un hilo para manejar una solicitud. Entonces, todo el procesamiento de la solicitud se ejecuta en este hilo de trabajo. Este modelo no escala muy bien. De hecho, para manejar múltiples solicitudes simultáneas, necesita múltiples subprocesos; por lo que la simultaneidad de su aplicación está limitada por el número de subprocesos. Además, estos subprocesos se bloquean tan pronto como su código interactúe con servicios remotos. Por lo tanto, conduce a un uso ineficiente de los recursos, ya que es posible que necesite más subprocesos, y cada subproceso, ya que están asignados a subprocesos del sistema operativo, tiene un costo en términos de memoria y CPU.

Por otro lado, el modelo reactivo se basa en E/S sin bloqueo y en un modelo de ejecución diferente. La E/S sin bloqueo proporciona una forma eficaz de tratar las E/S simultáneas. Una cantidad mínima de subprocesos denominados subprocesos de E/S puede manejar muchas E/S simultáneas. Con un modelo de este tipo, el procesamiento de solicitudes no se delega a un subproceso de trabajo, sino que utiliza estos subprocesos de E/S directamente. Ahorra memoria y CPU, ya que no es necesario crear subprocesos de trabajo para manejar las solicitudes. También mejora la simultaneidad ya que elimina la restricción sobre el número de subprocesos. Finalmente, también mejora el tiempo de respuesta ya que reduce el número de cambios de hilo.

Entonces, con el modelo de ejecución reactiva, las solicitudes se procesan mediante subprocesos de E/S. Pero eso no es todo. Un subproceso de E/S puede manejar varias solicitudes simultáneas. ¿Cómo? Aquí está el truco y una de las diferencias más significativas entre reactivo e imperativo.

Cuando el procesamiento de una solicitud requiere interactuar con un servicio remoto, como una API HTTP o una base de datos, no bloquea la ejecución mientras espera la respuesta. En cambio, programa la operación de E/S y adjunta una continuación, es decir, el código restante de procesamiento de la solicitud. Esta continuación se puede pasar como una devolución de llamada (una función invocada con el resultado de E/S) o utilizar construcciones más avanzadas como programación reactiva o co-rutinas. 

Independientemente de cómo se exprese la programación no bloqueante, lo esencial es la liberación del subproceso de E/S y, en consecuencia, el hecho de que este subproceso pueda utilizarse para procesar otra solicitud. Cuando se completa la E/S, el subproceso de E/S continúa el procesamiento de la solicitud pendiente.

Entonces, a diferencia del modelo imperativo, donde la E/S bloquea la ejecución, los conmutadores reactivos a un diseño basado en la continuación, donde se liberan los subprocesos de E/S y se invoca la continuación cuando se completan las E/S. Como resultado, el subproceso de E/S puede manejar múltiples solicitudes concurrentes, mejorando la concurrencia general de la aplicación.

Pero hay una trampa. Necesitamos una forma de escribir código continuation-passing o no bloqueante. Hay muchas maneras de hacer esto. Por ejemplo en Quarkus propone:

• Mutiny: una biblioteca de programación reactiva intuitiva e impulsada por eventos
• Co-rutinas de Kotlin: una forma de escribir código asincrónico de manera secuencial

Dejo link: https://quarkus.io/guides/getting-started-reactive

Libros gratuitos

 

Download IT Guides!   Android UI Design Android’s user interface is based on direct manipulation, using touch inputs that loosely correspond to real-world actions, like swiping, tapping, pinching and reverse pinching to...     JPA Minibook The basic Java framework to access the database is JDBC. Unfortunately, with JDBC, a lot of hand work is needed to convert a database query result into Java classes. Other disadvantages...     Microservices for Java Developers Microservices are a software development technique – a variant of the service-oriented architecture (SOA) structural style – that arranges an application as a collection of loosely...     JMeter Tutorial JMeter is an application that offers several possibilities to configure and execute load, performance and stress tests using different technologies and protocols. It allows simulating...

The Best Web Programming Languages to Learn A more comprehensive list of tasks to which web development commonly refers, may include web engineering, web design, web content development, client liaison, client-side/server-side...     Web Developer Interview Questions A more comprehensive list of tasks to which web development commonly refers, may include web engineering, web design, web content development, client liaison, client-side/server-side...     Amazon AWS Lambda Tutorial AWS Lambda is an event-driven, serverless computing platform provided by Amazon as a part of the Amazon Web Services. It is a computing service that runs code in response to events and...     Jetty Server Cookbook The web server is used in products such as Apache ActiveMQ, Alfresco, Apache Geronimo, Apache Maven, Apache Spark, Google App Engine, Eclipse, FUSE, iDempiere, Twitter’s Streaming API and...

Primeros pasos con Apache Kafka parte 9

Seguimos con Kafka. 

Supongamos que el tiempo de ida y vuelta de la red entre nuestra aplicación y el clúster de Kafka es de 10 ms. Si esperamos una respuesta después de enviar cada mensaje, enviar 100 mensajes tardará alrededor de 1 segundo. Por otro lado, si solo enviamos todos nuestros mensajes y no esperamos ninguna respuesta, enviar 100 mensajes apenas nos llevará tiempo. En la mayoría de los casos, realmente no necesitamos una respuesta: Kafka devuelve el tema, la partición y el desplazamiento del registro después de que se escribió, lo que generalmente no es requerido por la aplicación de envío. Por otro lado, necesitamos saber cuándo fallamos en enviar un mensaje por completo para poder lanzar una excepción, registrar un error o quizás escribir el mensaje en un archivo de “errores” para un análisis posterior.

Para enviar mensajes de forma asincrónica y manejar escenarios de error, el productor admite agregar un callback al enviar un registro. Veamos un ejemplo:

private class DemoProducerCallback implements Callback {

    @Override

    public void onCompletion(RecordMetadata recordMetadata, Exception e) {

        if (e != null) {

            e.printStackTrace();

        }

    }

}

ProducerRecord<String, String> record = new ProducerRecord<>("CustomerCountry", "Biomedical Materials", "USA");

producer.send(record, new DemoProducerCallback());

Para usar callbaks, necesitamos una clase que implemente la interfaz org.apache.kafka.clients.producer.Callback, que tiene una única función onCompletion().

Si Kafka devolvió un error, onCompletion() tendrá una excepción no nula. Aquí lo “manejamos” imprimiendo, pero el código de producción probablemente tendrá funciones de manejo de errores más robustas. Los registros son los mismos que antes. Y pasamos un objeto de devolución de llamada cuando enviamos el registro.

Primeros pasos con Apache Kafka parte 8

Seguimos con Kafka. 

La forma más sencilla de enviar un mensaje es la siguiente:

ProducerRecord<String, String> record = new ProducerRecord<>("CustomerCountry", "Precision Products", "France");

try {

producer.send(record);

} catch (Exception e) {

e.printStackTrace();

}

El productor acepta objetos ProducerRecord, por lo que comenzamos creando uno. ProducerRecord tiene varios constructores. Aquí usamos uno que requiere el nombre del tema al que estamos enviando datos, que siempre es una cadena, y la clave y el valor que estamos enviando a Kafka, que en este caso también son cadenas. Los tipos de clave y valor deben coincidir con nuestros objetos de serializador y productor.

Usamos el método send() del objeto productor para enviar el ProducerRecord. El mensaje se colocará en un búfer y se enviará al broker en un hilo separado. El método send () devuelve un objeto Java Future con RecordMetadata, pero como simplemente ignoramos el valor devuelto, no tenemos forma de saber si el mensaje se envió correctamente o no. Este método de envío de mensajes se puede utilizar cuando es aceptable que algun mensaje no llegue

Si bien ignoramos los errores que pueden ocurrir al enviar mensajes a los brokers de Kafka, es posible que obtengamos una excepción si el productor encontró errores antes de enviar el mensaje a Kafka. Pueden ser una SerializationException cuando no se serializa el mensaje, una BufferExhaustedException o TimeoutException si el búfer está lleno, o una InterruptException si se interrumpió el hilo de envío.

Primeros pasos con Apache Kafka parte 7

Seguimos con Kafka. 

El primer paso para escribir mensajes a Kafka es crear un objeto productor. Un productor de Kafka tiene tres propiedades obligatorias:

bootstrap.servers

Lista de hosts: Como nos tenemos que conectar al cluster necesitamos, la ip de almenos una maquina pero se recomienda incluir al menos dos, por lo que en caso de que una se caiga, el productor aún podrá conectarse al clúster. Luego de conectarse, se le enviaran todas las ips del cluster. 

key.serializer

Nombre de una clase que se utilizará para serializar las claves de los registros que produciremos en Kafka. Los brokers de Kafka esperan matrices de bytes como claves y valores de mensajes.

Sin embargo, la interfaz de productor permite, utilizando tipos parametrizados, enviar cualquier objeto Java como clave y valor. Esto hace que el código sea muy legible, pero también significa que el productor debe saber cómo convertir estos objetos en matrices de bytes.

key.serializer debe configurarse con el nombre de una clase que implemente la interfaz org.apache.kafka.common.serialization.Serializer. El productor utilizará esta clase para serializar el objeto clave en una matriz de bytes. El paquete de cliente de Kafka incluye ByteArraySerializer. Es necesario configurar key.serializer incluso si tiene la intención de enviar solo valores.

value.serializer Nombre de una clase que se utilizará para serializar los valores de los registros que produciremos en Kafka. De la misma manera que establece key.serializer en un nombre de una clase que serializará el objeto de clave de mensaje en una matriz de bytes, establece value.serializer en una clase que serializará el objeto de valor de mensaje.

El siguiente fragmento de código muestra cómo crear un nuevo productor estableciendo solo los parámetros obligatorios y usando valores predeterminados para todo lo demás:

private Properties kafkaProps = new Properties();

kafkaProps.put("bootstrap.servers", "broker1:9092,broker2:9092");

kafkaProps.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");

kafkaProps.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

producer = new KafkaProducer<String, String>(kafkaProps);

Con una interfaz tan simple, está claro que la mayor parte del control sobre el comportamiento del productor se realiza estableciendo las propiedades de configuración correctas. La documentación de Apache Kafka cubre todas las opciones de configuración, y repasaremos las importantes más adelante.

Una vez que creamos una instancia de un productor, es hora de comenzar a enviar mensajes. Hay tres métodos principales para enviar mensajes:

Dispara y olvida

Enviamos un mensaje al servidor y realmente no nos importa si llega con éxito o no. La mayoría de las veces, llegará correctamente, ya que Kafka tiene una alta disponibilidad y el productor volverá a intentar enviar mensajes automáticamente. Sin embargo, algunos mensajes se pueden perder con este método, hay casos de uso que no nos importa estar seguros si llegan los mensajes para esos casos es este método. 

Envío sincrónico

Enviamos un mensaje, el método send () devuelve un objeto Future y usamos get () para esperar y ver si el envío fue exitoso o no.

Envío asincrónico

Llamamos al método send() con una función de devolución de llamada, que se activa cuando recibe una respuesta del corredor de Kafka. 

En los ejemplos que siguen, veremos cómo enviar mensajes usando estos métodos y cómo manejar los diferentes tipos de errores que pueden ocurrir pero eso es una historia para otro post...

Se encuentran abiertas las inscripciones para los cursos Gugler!!!

 

Consumiendo mensajes desde Apache Kafka con Spring Boot

Vamos a hacer un ejemplo de spring boot que consuma un mensaje desde Kafka. Primero tenemos que bajar nuestro proyecto de spring initializr en esta pagina podemos agregar spring-kafka o agregarlo luego  : 

implementation 'org.springframework.kafka:spring-kafka'

Usando Gradle o Maven. 

Antes vamos a hacer un mensaje de ejemplo, que va ser el mensaje a escribir : 

public class Message {

    private long id;

    private String message;

    private LocalDateTime time;

    public Message() {}

    public Message(long id, String message, LocalDateTime time) {

        this.id = id;

        this.message = message;

        this.time = time;

    }

    public Message(String message, LocalDateTime time) {

        this(new Random().nextLong(), message, time);

    }

    public Message(String message) {

        this(message,LocalDateTime.now());

    }

    public long getId() {

        return id;

    }

    public void setId(long id) {

        this.id = id;

    }

    public String getMessage() {

        return message;

    }

    public void setMessage(String message) {

        this.message = message;

    }

    public LocalDateTime getTime() {

        return time;

    }

    public void setTime(LocalDateTime time) {

        this.time = time;

    }

    @Override

    public boolean equals(Object o) {

        if (this == o) return true;

        if (o == null || getClass() != o.getClass()) return false;

        Message message1 = (Message) o;

        return Objects.equals(message, message1.message) &&

                Objects.equals(time, message1.time);

    }

    @Override

    public int hashCode() {

        return Objects.hash(message, time);

    }

    @Override

    public String toString() {

        return "Message{" +

                "message='" + message + '\'' +

                ", time=" + time +

                '}';

    }

}

Tenemos que escribir 2 clases de configuración, una para indicar como nos conectar a Kafka y como esta serializado el objeto. 

@EnableKafka

@Configuration

public class KafkaConsumerConfig {

    @Value(value = "${kafka.bootstrapAddress}")

    private String bootstrapAddress;

    @Bean

    public ConsumerFactory<String, Message> consumerFactory() {

        var props = new HashMap<String, Object>();

        props.put(

                ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,

                bootstrapAddress);

        props.put(

                ConsumerConfig.GROUP_ID_CONFIG,

                "demo");

        props.put(

                ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG,

                StringDeserializer.class);

        props.put(

                ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,

                JsonDeserializer.class);

        props.put(JsonDeserializer.TRUSTED_PACKAGES,

                "com.assembly.demo.model");

        return new DefaultKafkaConsumerFactory<>(props);

    }

    @Bean

    public ConcurrentKafkaListenerContainerFactory<String, Message>

    kafkaListenerContainerFactory() {

        var factory = new ConcurrentKafkaListenerContainerFactory<String, Message>();

        factory.setConsumerFactory(this.consumerFactory());

        return factory;

    }

}

Y Otra para confugurar el topic : 

@Configuration

public class KafkaTopicConfig {

    @Value(value = "${kafka.bootstrapAddress}")

    private String bootstrapAddress;

    @Bean

    public KafkaAdmin kafkaAdmin() {

        var configs = new HashMap<String, Object>();

        configs.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress);

        return new KafkaAdmin(configs);

    }

    @Bean

    public NewTopic topicDemo() {

        return new NewTopic("demo", 1, (short) 1);

    }

}

Y ahora vamos a hacer un servicio que consuma el mensaje y lo escriba en pantalla : 

@Service

public class ConsumerService {

    @KafkaListener(topics = "${kafka.topicName}", groupId = "demo")

    public void listenGroupDemo(Message message) {

        System.out.println("Received Message in group demo : " + message);

    }

}

Y Listo!!

Dejo link del repo : https://github.com/emanuelpeg/springBoot-Kafka-example

Escribiendo mensajes en Apanche Kafka con Spring Boot

Vamos a hacer un ejemplo de spring boot que escriba un mensaje con Kafka. Primero tenemos que bajar nuestro proyecto de spring initializr en esta pagina podemos agregar spring-kafka o agregarlo luego  : 

implementation 'org.springframework.kafka:spring-kafka'

Usando Gradle o Maven. 

Antes vamos a hacer un mensaje de ejemplo, que va ser el mensaje a escribir : 

public class Message {

    private long id;

    private String message;

    private LocalDateTime time;

    public Message(long id, String message, LocalDateTime time) {

        this.id = id;

        this.message = message;

        this.time = time;

    }

    public Message(String message, LocalDateTime time) {

        this(new Random().nextLong(), message, time);

    }

    public Message(String message) {

        this(message,LocalDateTime.now());

    }

    public long getId() {

        return id;

    }

    public void setId(long id) {

        this.id = id;

    }

    public String getMessage() {

        return message;

    }

    public void setMessage(String message) {

        this.message = message;

    }

    public LocalDateTime getTime() {

        return time;

    }

    public void setTime(LocalDateTime time) {

        this.time = time;

    }

    @Override

    public boolean equals(Object o) {

        if (this == o) return true;

        if (o == null || getClass() != o.getClass()) return false;

        Message message1 = (Message) o;

        return Objects.equals(message, message1.message) &&

                Objects.equals(time, message1.time);

    }

    @Override

    public int hashCode() {

        return Objects.hash(message, time);

    }

    @Override

    public String toString() {

        return "Message{" +

                "message='" + message + '\'' +

                ", time=" + time +

                '}';

    }

}

Luego tenemos que hacer 2 objetos de configuración, uno para configurar el acceso a kafka y sus parámetros : 

@Configuration

public class KafkaProducerConfig {

    @Value(value = "${kafka.bootstrapAddress}")

    private String bootstrapAddress;

    @Bean

    public ProducerFactory<String, Message> producerFactory() {

        var configProps = new HashMap<String, Object>();

        configProps.put(

                ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,

                bootstrapAddress);

        configProps.put(

                ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,

                StringSerializer.class);

        configProps.put(

                ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,

                JsonSerializer.class);

        return new DefaultKafkaProducerFactory<>(configProps);

    }

//Y creamos un template que nos ayuda a escribir mensaje con la configuración realizada. 

    @Bean

    public KafkaTemplate<String, Message> kafkaTemplate() {

        return new KafkaTemplate<>(producerFactory());

    }

}

Y luego configuramos el acceso al topic : 

@Configuration

public class KafkaTopicConfig {

    @Value(value = "${kafka.bootstrapAddress}")

    private String bootstrapAddress;

    @Bean

    public KafkaAdmin kafkaAdmin() {

        var configs = new HashMap<String, Object>();

        configs.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress);

        return new KafkaAdmin(configs);

    }

    @Bean

    public NewTopic topicDemo() {

        return new NewTopic("demo", 1, (short) 1);

    }

}

Ahora hacemos un servicio que escriba el mensaje: 

@Service

public class ProducerService {

    @Autowired

    private KafkaTemplate<String, Message> kafkaTemplate;

    @Value(value = "${kafka.topicName}")

    private String topicName;

    public void sendMessage(Message message) {

        ListenableFuture<SendResult<String, Message>> future =

                kafkaTemplate.send(topicName, message);

        future.addCallback(new ListenableFutureCallback<SendResult<String, Message>>() {

            @Override

            public void onSuccess(SendResult<String, Message> result) {

                System.out.println("Sent message=[" + message.getTime() + message.getMessage() +

                        "] with offset=[" + result.getRecordMetadata().offset() + "]");

            }

            @Override

            public void onFailure(Throwable ex) {

                System.out.println("Unable to send message=["

                        + message + "] due to : " + ex.getMessage());

            }

        });

    }

}

Y ya que estamos hacemos un controller que exponga un servicio Rest que escriba mensajes: 

@RestController

@RequestMapping("demo")

public class DemoController {

    @Autowired

    private ProducerService service;

    @GetMapping("/{msg}")

    public void sendMessage(@PathVariable String msg) {

        var message = new Message(msg);

        service.sendMessage(message);

    }

}

Y listo!! 

Dejo link del repo : https://github.com/emanuelpeg/springBoot-Kafka-example

Red Hat Developer eBooks

Medio tarde encontré este link el cual tiene unos buenos libros para desarrolladores y que quiero compartir con ustedes : 

https://developers.redhat.com/ebooks

Aprende Vim jugando con vim-adventures

Vim es un excelente editor pero pero no es tan fácil de aprender, por lo menos para mi. En fin si existiera un juegito en el cual podamos aprender jugando a utilizar Vim. Bueno este juego existe y se llama:  

https://vim-adventures.com/

:x

Primeros pasos con Apache Kafka parte 6

Ya sea que usemos Kafka como cola, bus de mensajes o plataforma de almacenamiento de datos, siempre un productor escribe datos en Kafka, un consumidor lee datos de Kafka o una aplicación cumple ambos roles.

Por ejemplo, en un sistema de procesamiento de transacciones de tarjetas de crédito, habrá una aplicación de cliente, tal vez una tienda en línea, responsable de enviar cada transacción a Kafka inmediatamente cuando se realiza un pago. Otra aplicación es responsable de verificar inmediatamente esta transacción con un motor de reglas y determinar si la transacción se aprueba o se niega. La respuesta de aprobación / denegación se puede volver a escribir a Kafka y la respuesta se puede propagar a la tienda en línea donde se inició la transacción. Una tercera aplicación puede leer tanto las transacciones como el estado de aprobación de Kafka y almacenarlos en una base de datos donde los analistas pueden luego revisar las decisiones y quizás mejorar el motor de reglas.

Apache Kafka se envía con API de cliente integradas que los desarrolladores pueden usar cuando desarrollan aplicaciones que interactúan con Kafka.

Hay muchas razones por las que una aplicación puede necesitar escribir mensajes en Kafka: registrar las actividades del usuario para auditoría o análisis, registrar métricas, almacenar mensajes de registro, registrar información de dispositivos inteligentes, comunicarse de forma asíncrona con otras aplicaciones, almacenar información en búfer antes de escribir en una base de datos y mucho más.

Esos diversos casos de uso también implican diversos requisitos: ¿cada mensaje es crítico o podemos tolerar la pérdida de mensajes? ¿Estamos de acuerdo con la duplicación accidental de mensajes? ¿Existe algún requisito estricto de latencia o rendimiento que debamos cumplir?

En el ejemplo de procesamiento de transacciones con tarjeta de crédito que presentamos anteriormente, podemos ver que es fundamental no perder un solo mensaje ni duplicar ningún mensaje. La latencia debe ser baja, pero se pueden tolerar latencias de hasta 500 ms y el rendimiento debe ser muy alto: esperamos procesar hasta un millón de mensajes por segundo.

Un caso de uso diferente podría ser almacenar información de clics de un sitio web. En ese caso, se puede tolerar la pérdida de algunos mensajes o algunos duplicados; La latencia puede ser alta siempre que no afecte a la experiencia del usuario. En otras palabras, no nos importa si el mensaje tarda unos segundos en llegar a Kafka, siempre que la página siguiente se cargue inmediatamente después de que el usuario haga clic en un enlace. El rendimiento dependerá del nivel de actividad que preveamos en nuestro sitio web.

Los diferentes requisitos influirán en la forma en que utilice la API del productor para escribir mensajes en Kafka y la configuración que utilice.

Si bien las API del productor son muy simples, hay un poco más que sucede bajo el capó del productor cuando enviamos datos. 

Comenzamos a producir mensajes a Kafka creando un ProducerRecord, que debe incluir el tema al que queremos enviar el registro y un valor. Opcionalmente, también podemos especificar una clave y / o una partición. Una vez que enviamos el ProducerRecord, lo primero que hará el productor es serializar la clave y los objetos de valor en ByteArrays para que puedan enviarse a través de la red.

A continuación, los datos se envían a un particionador. Si especificamos una partición en ProducerRecord, el particionador no hace nada y simplemente devuelve la partición que especificamos. Si no lo hicimos, el particionador elegirá una partición por nosotros, generalmente basada en la clave ProducerRecord. Una vez que se selecciona una partición, el productor sabe a qué tema y partición irá el registro. Luego agrega el registro a un lote de registros que también se enviarán al mismo tema y partición. Un hilo independiente es responsable de enviar esos lotes de registros a los brokers de Kafka correspondientes.

Cuando el broker recibe los mensajes, envía una respuesta. Si los mensajes se escribieron correctamente en Kafka, devolverá un objeto RecordMetadata con el tema, la partición y el desplazamiento del registro dentro de la partición. Si el corredor no pudo escribir los mensajes, devolverá un error. Cuando el productor recibe un error, puede volver a intentar enviar el mensaje unas cuantas veces más antes de darse por vencido y devolver un error.

Resultados de la encuesta de stack overflow para 2021

Como todos los años tenemos los resultados de la encuesta que hace stack overflow a miles de desarrolladores. Es te año sin muchas sorpresas. 

Como dato que podria observar Rust es el lenguaje más amado y Javascript el más utilizado.  

Otra cosa que me llamo mucho la atención es que Svelte, este como framework front más amado, ya me tengo que poner a estudiar Svelte.

Dejo link : https://insights.stackoverflow.com/survey/2021

Primeros pasos con Apache Kafka parte 5

 

Seguimos con Kafka.

A medida que crecen las implementaciones de Kafka, a menudo resulta ventajoso tener varios clústeres. Hay varias razones por las que esto puede resultar útil:

• Segregación de tipos de datos
• Aislamiento por requisitos de seguridad
• Varios centros de datos (recuperación ante desastres)

Cuando se trabaja con varios centros de datos en particular, a menudo se requiere que los mensajes se copien entre ellos. De esta manera, las aplicaciones en línea pueden tener acceso a la actividad del usuario en ambos sitios. Por ejemplo, si un usuario cambia información pública en su perfil, ese cambio deberá ser visible independientemente del centro de datos en el que se muestren los resultados de la búsqueda. O bien, los datos de monitoreo se pueden recopilar de muchos sitios en una sola ubicación central donde se alojan los sistemas de análisis y alerta. Los mecanismos de replicación dentro de los clústeres de Kafka están diseñados solo para funcionar dentro de un único clúster, no entre varios clústeres.

El proyecto Kafka incluye una herramienta llamada MirrorMaker, utilizada para este propósito. En esencia, MirrorMaker es simplemente un consumidor y un productor de Kafka, vinculado con una cola. Los mensajes se consumen de un clúster de Kafka y se generan para otro.

Ebook gratuito : Diseño e implementación de microservicios

 Me llego este mail y quiero compartirlo con ustedes : 

August 2021

Sent on behalf of NGINX to InfoQ Industry Email Notices Subscribers

Learn the pros and cons of different microservices patterns for design and deployment Download now

Use the guidance in this eBook about building microservices to learn what a microservice is, and why you might need a microservices architecture to make your applications faster, more flexible, and more stable. In this eBook, you will learn: What a microservice is, when and why it makes sense to adopt microservices How to implement an API gateway to route traffic to microservices Pros and cons of different microservices patterns for design and deployment Different strategies for refactoring a monolith to microservices Download now

Primeros pasos con Apache Kafka parte 4

Seguimos con Kafka.

Un único servidor de Kafka se denomina intermediario. El intermediario recibe mensajes de los productores, les asigna compensaciones y confirma los mensajes para almacenarlos en el disco. También atiende a los consumidores, respondiendo a las solicitudes de recuperación de particiones y respondiendo con los mensajes que se han enviado al disco. Dependiendo del hardware específico y sus características de rendimiento, un solo agente puede manejar fácilmente miles de particiones y millones de mensajes por segundo.

Los corredores de Kafka están diseñados para operar como parte de un clúster. Dentro de un grupo de agentes, un agente también funcionará como controlador del grupo (elegido automáticamente entre los miembros activos del grupo). El controlador es responsable de las operaciones administrativas, incluida la asignación de particiones a los intermediarios y la supervisión de las fallas de los intermediarios. La partición es propiedad de un único intermediario en el clúster, y ese intermediario se denomina líder de la partición. Se puede asignar una partición a varios intermediarios, lo que dará como resultado la replicación de la partición. Esto proporciona redundancia de mensajes en la partición, de modo que otro corredor puede asumir el liderazgo si falla el corredor. Sin embargo, todos los consumidores y productores que operan en esa partición deben conectarse con el líder. 

Una característica clave de Apache Kafka es la retención, que es el almacenamiento duradero de mensajes durante un período de tiempo. Los corredores de Kafka están configurados con una configuración de retención predeterminada para los temas, ya sea reteniendo mensajes durante un período de tiempo (por ejemplo, 7 días) o hasta que el tema alcance un cierto tamaño en bytes (por ejemplo, 1 GB). Una vez que se alcanzan estos límites, los mensajes caducan y se eliminan para que la configuración de retención sea una cantidad mínima de datos disponibles en cualquier momento. Los temas individuales también se pueden configurar con su propia configuración de retención para que los mensajes se almacenen solo mientras sean útiles. Los temas también se pueden configurar como registro compactado, lo que significa que Kafka retendrá solo el último mensaje producido con una clave específica. Esto puede ser útil para datos de tipo registro de cambios, donde solo la última actualización es interesante.

Primeros pasos con Apache Kafka parte 3

Seguimos con Kafka.

Existen dos tipos de clientes básicos: productores y consumidores. También hay API de cliente avanzadas Kafka Connect API para la integración de datos y Kafka Streams para el procesamiento de transmisiones. Los clientes avanzados utilizan productores y consumidores como bloques de construcción y proporcionan una funcionalidad de nivel superior.

Los productores crean nuevos mensajes. En otros sistemas de publicación / suscripción, estos pueden denominarse editores o escritores. En general, se producirá un mensaje sobre un tema específico.

De forma predeterminada, al productor no le importa en qué partición se escribe un mensaje específico y equilibrará los mensajes en todas las particiones de un tema de manera uniforme. En algunos casos, el productor enviará mensajes a particiones específicas. Esto generalmente se hace usando la clave del mensaje y un particionador que generará un hash de la clave y lo asignará a una partición específica. Esto asegura que todos los mensajes producidos con una clave determinada se escribirán en la misma partición. El productor también podría usar un particionador personalizado que siga otras reglas comerciales para mapear mensajes a particiones. 

Los consumidores leen mensajes. En otros sistemas de publicación / suscripción, estos clientes pueden denominarse suscriptores o lectores. El consumidor se suscribe a uno o más temas y lee los mensajes en el orden en que fueron producidos. El consumidor realiza un seguimiento de los mensajes que ya ha consumido al realizar un seguimiento del desplazamiento de los mensajes. El desplazamiento es otro bit de metadatos, un valor entero que aumenta continuamente, que Kafka agrega a cada mensaje a medida que se produce. Cada mensaje de una partición determinada tiene un desplazamiento único. Al almacenar el desplazamiento del último mensaje consumido para cada partición, ya sea en Zookeeper o en el propio Kafka, un consumidor puede detenerse y reiniciarse sin perder su lugar.

Los consumidores trabajan como parte de un grupo de consumidores, que es uno o más consumidores que trabajan juntos para consumir un tema. El grupo asegura que cada partición solo sea consumida por un miembro. El mapeo de un consumidor a una partición a menudo se denomina propiedad de la partición por parte del consumidor.

De esta manera, los consumidores pueden escalar horizontalmente para consumir temas con una gran cantidad de mensajes. Además, si un solo consumidor falla, los miembros restantes del grupo reequilibrarán las particiones que se consumen para reemplazar al miembro faltante.