Preguntas frecuentes

Oracle Cloud Infrastructure (OCI) Streaming ofrece una solución de mensajería totalmente gestionada, escalable y duradera que permite asimilar flujos de datos continuos y de alto volumen que puede consumir y procesar en tiempo real. Streaming está disponible en todas las regiones de Oracle Cloud Infrastructure compatibles. Para obtener una lista, visite la página Regiones y dominios de disponibilidad.

Streaming es un servicio sin servidor que descarga la gestión de la infraestructura que va desde la red hasta el almacenamiento y la configuración necesaria para transmitir sus datos. No tiene que preocuparse por el aprovisionamiento de la infraestructura, el mantenimiento continuo ni la aplicación de parches de seguridad. El servicio Streaming replica datos de forma sincrónica en tres dominios de disponibilidad, lo que proporciona alta disponibilidad y durabilidad de los datos. En regiones con un solo dominio de disponibilidad, los datos se replican en tres dominios de fallo.

Streaming facilita la recopilación, el almacenamiento y el procesamiento de datos generados en tiempo real a partir de cientos de fuentes. La cantidad de casos de uso es casi ilimitada, desde la mensajería hasta el procesamiento de flujos de datos complejos. A continuación, se muestran algunos de los numerosos usos posibles de Streaming:

• Mensajería: utilice Streaming para desacoplar los componentes de sistemas grandes. Los productores y consumidores pueden utilizar Streaming como un bus de mensajes asincrónico y actuar de forma independiente y a su propio ritmo.
• Entrada de métricas y registros: utilice Streaming como alternativa a los enfoques tradicionales de extracción de archivos para conseguir que los datos operativos esenciales estén disponibles rápidamente para la indexación, el análisis y la visualización.
• Entrada de datos de actividad web o móvil: utilice Streaming para capturar la actividad de sitios web o aplicaciones móviles, como visitas a páginas, búsquedas u otras acciones del usuario. Puede utilizar esta información para supervisar y analizar en tiempo real, así como en sistemas de almacenamiento de datos para procesar y crear informes sin conexión.
• Procesamiento de eventos de infraestructura y aplicaciones: utilice Streaming como un punto de entrada unificado. Los componentes de la nube lo usarán para notificar sus eventos de ciclo de vida para auditoría, contabilidad y actividades relacionadas.

Puede comenzar a usar Streaming de la siguiente manera:

1. Cree un flujo utilizando la consola de Oracle Cloud Infrastructure o la operación API CreateStream.
2. Configure productores para publicar mensajes en el flujo. Consulte Publicar mensajes.
3. Cree consumidores para leer y procesar datos del flujo. Consulte Consumir mensajes.

También puede usar las API de Kafka para producir y consumir desde un flujo. Para obtener más información, consulte Uso de Streaming con Apache Kafka.

El rendimiento de Streaming está diseñado para escalar sin límites mediante la adición de particiones a un flujo. Sin embargo, debe tener en cuenta ciertos límites cuando utiliza Streaming:

• El período máximo de retención de mensajes en un flujo es de siete días.
• El tamaño máximo de un mensaje único que se puede generar en un flujo es de 1 megabyte (MB).
• Cada partición puede manejar hasta 1 MB por segundo de rendimiento con cualquier número de solicitudes de escritura.
• Cada partición admite una velocidad máxima total de escritura de datos de 1 MB por segundo y una velocidad de lectura de 2 MB por segundo.

Streaming proporciona semántica basada en flujos. La semántica de flujos proporciona garantías estrictas de ordenación por partición, capacidad de reproducción de mensajes, cursores en el lado del cliente y escala horizontal masiva de rendimiento. Las colas no ofrecen estas características. Las colas se pueden diseñar para proporcionar garantías de pedidos si se utilizan colas FIFO, pero solo a expensas de agregar una sobrecarga significativa en el rendimiento.

Un flujo es un registro de mensajes con particiones, que solo se puede anexar, en el que las aplicaciones del productor escriben datos y desde el cual las aplicaciones del consumidor leen datos.

Un grupo de flujos es una agrupación que se puede utilizar para organizar y administrar flujos. Los grupos de flujos ofrecen facilidad operativa, ya que facilitan la capacidad de compartir ajustes de configuración en múltiples flujos. Por ejemplo, los usuarios pueden compartir configuraciones de seguridad como claves de cifrado personalizadas en el grupo de flujos para cifrar los datos de todos los flujos dentro del grupo. Un grupo de flujos también permite crear un punto final privado para los flujos, ya que restringe el acceso a Internet a todos los flujos dentro de un grupo de flujos. Para los clientes que utilizan la función de compatibilidad de Streaming con Kafka, el grupo de flujos sirve como raíz de un clúster virtual de Kafka, lo que permite que cada acción de dicho clúster virtual tenga el alcance del grupo de flujos.

Una partición es una unidad de rendimiento base en un flujo que permite la escala horizontal y el paralelismo de producción y consumo de un flujo. Una partición proporciona una capacidad de entrada de datos de 1 MB/s y salida de datos de 2 MB/s. Cuando crea un flujo, especifica el número de particiones que necesita en función de los requisitos de rendimiento de su aplicación. Por ejemplo, puede crear un flujo con diez particiones, en cuyo caso puede lograr un rendimiento de entrada de 10 MB/s y un rendimiento de salida de 20 MB/s a partir de un flujo.

Un mensaje es una unidad de datos codificada en Base64 que se almacena en un flujo. El tamaño máximo de un mensaje que puede producir en una partición en un flujo es 1 MB.

Una clave es un identificador que se utiliza para agrupar mensajes relacionados. Los mensajes con la misma clave se escriben en la misma partición. Streaming se asegura de que todo consumidor de una partición determinada lea siempre los mensajes de dicha partición exactamente en el mismo orden en que fueron escritos.

Un productor es una aplicación cliente que puede escribir mensajes en un flujo.

Un consumidor es una aplicación cliente que puede leer mensajes de uno o más flujos. Un grupo de consumidores es un conjunto de instancias que coordina los mensajes de todas las particiones en un flujo. En un momento dado, los mensajes de una partición específica solo pueden ser consumidos por un único consumidor del grupo.

Un cursor es un puntero a una ubicación en un flujo. Esta ubicación puede ser un puntero a un desplazamiento o momento específico en una partición, o bien, a la ubicación actual de un grupo.

Cada mensaje de una partición tiene un identificador llamado desplazamiento. Los consumidores pueden leer mensajes a partir de un desplazamiento específico y se les permite leer desde cualquier punto de desplazamiento que elijan. Los consumidores también pueden confirmar el último desplazamiento procesado a fin de poder reanudar su trabajo sin reproducir o perder un mensaje si detienen la tarea y luego la reinician.

Streaming proporciona cifrado de datos de forma predeterminada, tanto en reposo como en tránsito. Streaming está completamente integrado con Oracle Cloud Infrastructure Identity and Access Management (IAM), que le permite utilizar políticas de acceso para otorgar permisos de forma selectiva a usuarios y grupos de usuarios. Cuando utiliza las API de REST, también puede ejecutar PUT y GET de forma segura con sus datos de Streaming a través de puntos finales SSL con el protocolo HTTPS. Además, Streaming proporciona un aislamiento completo de datos a nivel de inquilino sin ningún problema del tipo "vecino ruidoso".

Los datos de Streaming se cifran tanto en reposo como en tránsito; además, la integridad del mensaje está garantizada. Puede dejar que Oracle gestione el cifrado o utilizar Oracle Cloud Infrastructure Vault para almacenar y administrar de forma segura sus propias claves de cifrado si necesita cumplir con estándares específicos de cumplimiento o seguridad.

Puede editar la configuración de cifrado de datos del grupo de flujos en cualquier momento si desea cambiar entre el uso de "Cifrado proporcionado por claves de Oracle" y "Cifrado gestionado por claves administradas por el cliente". Streaming no impone ninguna restricción sobre la cantidad de veces que se puede realizar esta actividad.

Streaming está completamente integrado con Oracle Cloud Infrastructure IAM. Cada flujo tiene un compartimento asignado. Los usuarios pueden especificar políticas de control de acceso basadas en roles que se pueden usar para describir reglas detalladas a nivel de inquilino, de compartimiento o de flujo único.

La política de acceso se especifica en forma de “Allow <subject> to <verb> <resource-type> in <location> where <conditions>”.

La autenticación con el protocolo Kafka utiliza tokens de autenticación y el mecanismo SASL/PLAIN. Puede generar tokens en la página de detalles del usuario de la consola. Consulte Trabajar con tokens de autenticación para obtener más información. Le recomendamos que cree un grupo/usuario específico y otorgue a ese grupo el permiso para administrar flujos en el compartimiento o inquilino apropiado. Luego puede generar un token de autenticación para el usuario que haya creado y usarlo en la configuración de su cliente de Kafka.

Los puntos finales privados restringen el acceso a una red virtual en la nube (VCN, virtual cloud network) específica dentro de su inquilino para que no se pueda acceder a sus flujos a través de Internet. Los puntos finales privados asocian una dirección IP privada dentro de una VCN al grupo de flujos, lo que permite que el tráfico de Streaming evite atravesar Internet. Para crear un punto final privado para Streaming, necesita acceso a una VCN con una subred privada en el momento de crear el grupo de flujos. Consulte Información sobre puntos finales privados y VCN y subredes para obtener más información.

Puede escribir el contenido de un flujo directamente en un depósito de Object Storage, normalmente para conservar los datos en el flujo para su almacenamiento a largo plazo. Para este fin, puede utilizar Kafka Connect for S3 con Streaming. Para obtener más información, consulte la publicación del blog Publicar en Object Store desde Oracle Streaming Service.

Puede asimilar datos desde una tabla en una instancia de Oracle Autonomous Transaction Processing. Para obtener más información, consulte la publicación del blog Uso de Kafka Connect con Oracle Streaming Service y Autonomous Database.

Puede utilizar los SDK de Kafka para producir y consumir mensajes de Streaming. También puede utilizar el soporte integrado de Micronaut para Kafka. Para obtener más información, consulte la publicación del blog Mensajería sencilla con Kafka Support de Micronaut y Oracle Streaming Service.

Para obtener información, consulte la publicación del blog Asimilar datos de IoT de brokers MQTT en OCI-Oracle Streaming Service, OCI-Kafka Connect Harness y Oracle Kubernetes Engine.

Oracle GoldenGate for Big Data ya cuenta con la certificación necesaria para integrarse con Streaming. Para más información, consulte Conexión a Oracle Streaming Service en la documentación de Oracle GoldenGate for Big Data.

Debe utilizar Kafka JDBC Sink Connect para transportar directamente datos de Streaming a Oracle Autonomous Data Warehouse.

• En la publicación del blog Uso de Kafka Connect con Oracle Streaming Service y Autonomous Database, se explica cómo usar un conector de fuente Kafka Connect, que envía datos de Oracle Autonomous Data Warehouse a los flujos. Necesita lo contrario, un conector receptor.
• En la publicación del blog Datos OSS a ADW casi en tiempo real, se explica cómo utilizar una tabla externa con una ruta de almacenamiento de objetos para obtener datos en Oracle Autonomous Data Warehouse.

Streaming utiliza un esquema de precios Pay-as-you-go (pago por consumo), de modo que solo pagará por los recursos que use sin ningún costo por adelantado. Las dimensiones de precios son las siguientes:

• Precio de solicitud GET/PUT: gigabytes de datos transferidos
• Precio del almacenamiento, determinado por la cantidad de horas de período de retención utilizadas para retener sus datos: gigabytes de almacenamiento por hora

Consulte la página de producto Streaming para obtener la información más reciente sobre precios.

Gracias a los precios líderes en la industria de Streaming, se garantiza que usted paga solo cuando utiliza el servicio. Esto significa que no pagará un precio adicional por los recursos que no utilice.

Streaming no cobra un precio adicional por cargas y descargar datos en el servicio. Además, los usuarios pueden aprovechar el poder de Service Connector Hub para cargas y descargar datos en Streaming sin servidor ni precio adicional.

Streaming no cuenta actualmente con ninguna opción gratuita.

Oracle Cloud Infrastructure Streaming garantiza un porcentaje de tiempo de actividad mensual de al menos el 99,9 %. El porcentaje de tiempo de actividad mensual se calcula restando el porcentaje no disponible en el mes calendario al 100 % del servicio de Oracle Cloud Infrastructure Streaming correspondiente.

Consulte la sección 2.7.1.6.32 Oracle Cloud Infrastructure Streaming, en Servicios de nube públicos Oracle PaaS e IaaS: documento básico (PDF) para obtener información detallada sobre todos los términos y las condiciones del acuerdo de nivel de servicio y la elegibilidad para los créditos de servicio.

Identity and Access Management le permite controlar quién tiene acceso a sus recursos en la nube. Para usar los recursos de Oracle Cloud Infrastructure, debe tener el tipo de acceso requerido en una política escrita por un administrador, tanto si usa la consola o la API de REST con un SDK, CLI u otras herramientas. La política de acceso se especifica en la siguiente forma:

Allow <subject> to <verb> <resource-type> in <location> where <conditions>

Los administradores de una tenencia pueden usar la política:

Allow group StreamAdmins to manage streams in tenancy

que permite a un grupo específico StreamAdmins hacer de todo con Streaming, desde crear, actualizar y enumerar hasta eliminar flujos y sus recursos asociados. Sin embargo, siempre puede especificar políticas más detalladas para que solo determinados usuarios de un grupo puedan acceder a un solo subconjunto de actividades que pueden realizar en un flujo dado. Si es nuevo en materia de políticas, consulte Introducción a las políticas y Políticas comunes. Si desea profundizar en la redacción de políticas para Streaming, consulte Detalles del servicio Streaming en la referencia de políticas de IAM.

Puede aprovisionar un flujo y todos sus componentes asociados, como políticas de IAM, particiones y configuraciones de cifrado, entre otros, utilizando Oracle Cloud Infrastructure Resource Manager o el proveedor de Terraform para Oracle Cloud Infrastructure. Para obtener información sobre el proveedor de Terraform, consulte Tema sobre Terraform para el servicio Streaming.

Cuando crea un flujo, debe especificar cuántas particiones contendrá. Como ayuda para determinar la cantidad de particiones para su flujo, piense en el rendimiento esperado de su aplicación. Multiplique el tamaño promedio de los mensajes por el número máximo de mensajes escritos por segundo para calcular el rendimiento esperado. Dado que una sola partición está limitada a una velocidad de escritura de 1 MB por segundo, un mayor rendimiento requiere particiones adicionales para evitar la limitación. Como ayuda para administrar los picos de aplicación, le recomendamos que asigne particiones un poco más altas que su rendimiento máximo.

Las particiones se crean cada vez que se genera un flujo, ya sea en la consola o mediante programación.

Interfaz de usuario de la consola:

Mediante programación:

Crear un flujo

CreateStreamDetails streamDetails =

        CreateStreamDetails.builder()

                .compartmentId(compartmentId)

                .name(streamName)

                .partitions(partitions)

                .build();

Se proporciona un ejemplo más detallado con el SDK.

Streaming gestiona las particiones de forma interna para que usted no tenga que hacerlo. Un usuario no puede eliminar directamente una partición. Cuando se elimina un flujo, se eliminan todas las particiones asociadas con ese flujo.

El rendimiento de un flujo de Oracle Cloud Infrastructure está definido por una partición. Una partición proporciona 1 MB de entrada de datos por segundo y 2 MB de salida de datos por segundo.

El rendimiento de un flujo de Oracle Cloud Infrastructure se puede escalar agregando más particiones. No hay límites superiores teóricos en el número de particiones que puede contener un flujo. Sin embargo, cada tenencia de Oracle Cloud Infrastructure viene con un límite de particiones predeterminado de 5 para cuentas de tipo Universal Credits. Si necesita más particiones, siempre puede solicitar que se aumenten sus límites de servicio.

Siga estos pasos para solicitar un aumento de los límites del servicio:

1. En la esquina superior derecha de la consola, abra el menú Usuario y haga clic en Tenencia: <tenancy_name> .
   
   
2. Hacer clic en Límites del servicio y, a continuación, haga clic en Solicitar un aumento del límite del servicio.
   
   
3. Llene el formulario y seleccione Otros en Categoría de servicio y Otros límites en Recurso. En Razón de la solicitud, solicite aumentar el número de particiones para el servicio Streaming en su tenencia.

A continuación, se muestran algunas prácticas recomendadas para tener en cuenta a la hora de crear un flujo:

• Los nombres de los flujos deben ser únicos dentro de un grupo de flujos. Esto significa que puede crear dos flujos con el mismo nombre en el mismo compartimento solo si se encuentran en diferentes grupos de flujos.
• Una vez creado el flujo, no puede cambiar el número de particiones que contiene. Recomendamos asignar un número de particiones ligeramente más alto que su rendimiento máximo. Esta práctica ayuda a administrar los picos de aplicaciones.
• No se puede cambiar el período de retención de un flujo después de su creación. Por defecto, los datos se almacenan en un flujo durante 24 horas. Sin embargo, se puede configurar para retener los datos entre 24 y 168 horas. La cantidad de datos almacenados en un flujo no tiene ningún impacto en el rendimiento del flujo.

Una vez creado el flujo y con el estado "Activo", puede comenzar a generar mensajes. Puede producir mensajes a un flujo mediante la consola o la API.

Para la consola: Vaya a la sección del servicio Streaming en la consola, ubicada debajo de la pestaña Soluciones y plataforma > Analítica. Si ya ha creado flujos, seleccione un flujo en un compartimento y vaya a la página "Detalles del flujo". Haga clic en el botón "Producir mensaje de prueba" en la consola. Con esta acción, asignará una clave de partición al mensaje y escribirá a una partición en el flujo. Para ver este mensaje en la sección Mensajes recientes, haga clic en el botón Cargar mensajes.

Para las API: puede utilizar las API de Oracle Cloud Infrastructure Streaming o las API de Kafka para producir mensajes a un flujo. El mensaje se publicará en una partición del flujo. Si hay más de una partición, especifique una clave para elegir a qué partición enviar el mensaje. De lo contrario, si no especifica ninguna clave, Streaming le asignará una cuando genera un UUID y enviará el mensaje a una partición aleatoria. De este modo, se asegura de que los mensajes sin clave se distribuyen de manera uniforme en todas las particiones. Sin embargo, le recomendamos que especifique siempre una clave de mensaje para que pueda controlar explícitamente la estrategia de partición de sus datos.

Los ejemplos de cómo producir mensajes en un flujo mediante los SDK de Streaming están disponibles en la documentación.

Cuando utiliza las API de Oracle Cloud Infrastructure para producir un mensaje, la lógica de la creación de particiones está controlada por Streaming. Este proceso se denomina creación de particiones en el lado del servidor. Como usuario, usted elige la partición de envío en función de la clave. La clave se codifica y el valor resultante se usa para determinar el número de particiones al que enviar el mensaje. Los mensajes con la misma clave se envían a la misma partición. Los mensajes con claves diferentes pueden ir a particiones diferentes o a la misma partición.

Sin embargo, si usa las API de Kafka para producir mensajes a un flujo, el cliente de Kafka controla la partición y el patrocinador en el cliente de Kafka se responsabiliza de la lógica de creación de particiones, lo que se conoce como creación de particiones en el lado del cliente.

Para garantizar una distribución uniforme de los mensajes, necesita un valor eficaz para las claves de sus mensajes. Para crear uno, tenga en cuenta la selectividad y la cardinalidad de los datos del flujo.

• Cardinalidad: tenga en cuenta el número total de claves únicas que podrían generarse para el caso de uso correcto. Una cardinalidad de claves más alta suele significar que la distribución es mejor.
• Selectividad: tenga en cuenta la cantidad de mensajes con cada clave. Cuanto más alta sea la selectividad, más mensajes habrá por clave, lo que puede generar puntos calientes.

El objetivo siempre es lograr una alta cardinalidad y una baja selectividad.

Streaming garantiza lecturas y escrituras linealizables dentro de una partición. Si desea asegurarse de que los mensajes con el mismo valor vayan a la misma partición, debe usar la misma clave para esos mensajes.

Una partición proporciona una velocidad de entrada de datos de 1 MB/s y admite hasta 1000 mensajes PUT por segundo. Por lo tanto, si el tamaño del registro es inferior a 1 KB, la velocidad de entrada de datos real de una partición será inferior a 1 MB/s, limitada por el número máximo de mensajes PUT por segundo. Le recomendamos que genere mensajes en lotes por las siguientes razones:

• Reduce el número de solicitudes PUT enviadas al servicio, lo que evita la aceleración.
• Ofrece un mejor rendimiento.

El tamaño de un lote de mensajes no debe exceder 1 MB. Si se supera este límite, se activa el mecanismo de aceleración.

Puede usar la fragmentación o enviar el mensaje mediante Oracle Cloud Infrastructure Object Storage.

• Fragmentación: puede dividir grandes cargas útiles en varios fragmentos más pequeños que Streaming puede aceptar. Los fragmentos se almacenan en el servicio de la misma manera que se almacenan los mensajes ordinarios no fragmentados. La única diferencia es que el consumidor debe conservar los fragmentos y combinarlos en el mensaje cuando se hayan recopilado todos los fragmentos. Los fragmentos de la partición se pueden entrelazar con mensajes ordinarios.
• Object Storage: se coloca una carga útil grande en Object Storage y solo se transfiere el puntero a esos datos. El receptor reconoce este tipo de carga útil de puntero, lee de forma transparente los datos de Object Storage y se los proporciona al usuario final.

Cuando un productor produce a una velocidad superior a 1 MB por segundo, la solicitud se acelera y se envía el error 429, demasiadas solicitudes al cliente para avisarle que se están recibiendo demasiadas solicitudes por segundo por partición.

Un consumidor es una entidad que lee mensajes de uno o más flujos. Esta entidad puede existir individualmente o formar parte de un grupo de consumidores. Para consumir mensajes, debe crear un cursor y usarlo para leer los mensajes. Un cursor señala una ubicación en un flujo. Esta ubicación puede ser un desplazamiento o momento específicos en una partición, o bien, la ubicación actual de un grupo. Dispone de múltiples tipos de cursores en función de la ubicación desde la que le gustaría leer: TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME y LATEST.

Para obtener más información, consulte la documentación sobre Consumir mensajes.

El método getLimit ( ) de la clase GetMessagesRequest devuelve el número máximo de mensajes. Puede especificar cualquier valor hasta 10.000. De forma predeterminada, el servicio devuelve todos los mensajes posibles. Tenga en cuenta el tamaño promedio de sus mensajes para evitar superar el rendimiento en el flujo. Los tamaños de lote de GetMessages de Streaming se basan en el tamaño promedio de los mensajes producidos en el flujo específico.

Streaming proporciona semántica de entrega "al menos una vez" a los consumidores. Recomendamos que las aplicaciones de consumidor se encarguen de los duplicados. Por ejemplo, cuando una instancia previamente inactiva del grupo de consumidores se vuelve a unir al grupo y comienza a consumir mensajes que no han sido confirmados por la instancia previamente asignada, es posible que se produzcan duplicados.

Se dice que un consumidor se está retrasando cuando se produce más rápido de lo que se puede consumir. Para determinar si su consumidor se está retrasando, puede utilizar la marca de tiempo del mensaje. Si el consumidor se está retrasando, considere la posibilidad de generar un nuevo consumidor para que se haga cargo de algunas de las particiones del primer consumidor. Si se está retrasando en una sola partición, la recuperación no es posible.

Considere las siguientes opciones:

• Aumentar el número de particiones en el flujo.
• Si el problema se debe a un punto caliente, cambie la estrategia de clave de mensaje.
• Reducir el tiempo de procesamiento de mensajes o gestionar solicitudes en paralelo.

Si desea saber cuántos mensajes quedan para consumir en una partición determinada, use un cursor de tipo LATEST, obtenga el desplazamiento del siguiente mensaje publicado y calcule el delta con el desplazamiento que está consumiendo actualmente. Dado que no tenemos densidad de desplazamiento, solo puede obtener una estimación aproximada. Sin embargo, si su productor dejó de producir, no podrá obtener dicha información porque nunca obtendrá el desplazamiento del siguiente mensaje publicado.

Se pueden configurar consumidores de forma que consuman los mensajes como parte de un grupo. Las particiones de flujo se distribuyen entre los miembros de un grupo para que los mensajes de cualquier partición individual se envíen solamente a un único consumidor. Las asignaciones de particiones se reequilibran a medida que los consumidores se unen al grupo o lo abandonan. Para obtener más información, consulte la documentación sobre Grupos de consumidores.

Los grupos de consumidores ofrecen las siguientes ventajas:

• Cada instancia de un grupo de consumidores recibe mensajes de una o más particiones que se le asignan "automáticamente" y el resto de las instancias (que están asignadas a diferentes particiones) no recibe los mismos mensajes. De esta manera, podemos ampliar o reducir el número de instancias hasta el número de particiones de forma que una instancia lea una sola partición. En este caso, una nueva instancia que se una al grupo estará en estado inactivo, sin asignar a ninguna partición.
• Disponer de instancias que forman parte de  diferentes grupos de consumidores  significa que se proporciona un  patrón de publicación-suscripción en el que los mensajes de particiones se envían a todas las instancias de los distintos grupos.
  Dentro del mismo grupo de consumidores, las reglas son las que se muestran en la siguiente imagen:
  
  
  En diferentes grupos, las instancias reciben los mismos mensajes, como se muestra en la siguiente imagen:
  
  Esto es útil cuando los mensajes dentro de una partición son de interés para distintas aplicaciones que los procesarán de diferentes formas. Queremos que todas las aplicaciones interesadas reciban los mismos mensajes de la partición.
• Cuando una instancia se une a un grupo, si el número de particiones disponibles es suficiente (es decir, no se ha alcanzado el límite de una instancia por partición), se inicia un reequilibrado. Las particiones se reasignan a las instancias actuales y a la nueva. De la misma manera, si una instancia sale de un grupo, las particiones se reasignan a las instancias restantes.
• Las confirmaciones de desplazamiento se gestionan automáticamente.

Hay un límite de 50 grupos de consumidores por flujo. Los grupos de consumidores son efímeros, es decir, desaparecen cuando no se utilizan durante el período de retención del flujo.

Los siguientes componentes de Streaming tienen tiempos de espera:

• Cursor: mientras siga consumiendo mensajes, no es necesario crear un cursor. Si se detiene el consumo de mensajes durante más de 5 minutos, debe volver a crear el cursor.
• Instancia: si una instancia deja de consumir mensajes durante más de 30 segundos, se elimina del grupo de consumidores y su partición se reasigna a otra instancia. Esto se conoce como reequilibrado.

El reequilibrado es el proceso en el que un grupo de instancias, que pertenecen al mismo grupo de consumidores, se coordina para poseer un conjunto de particiones mutuamente excluyentes que pertenecen a un flujo específico. Cuando una operación de reequilibrado se completa correctamente para un grupo de consumidores, cada partición del flujo es propiedad de una o más instancias de consumidores dentro del grupo.

Cuando una instancia de un grupo de consumidores se vuelve inactiva porque no envía ningún latido durante más de 30 segundos o el proceso finaliza, se activa una actividad de reequilibrado dentro del grupo de consumidores. Esto se hace para manejar las particiones previamente consumidas por la instancia inactiva y reasignarlas a una instancia activa. De manera similar, cuando una instancia de un grupo de consumidores que anteriormente estaba inactivo se une al grupo, se activa un reequilibrado para asignar una partición desde la que comenzar a consumir. El servicio Streaming no ofrece ninguna garantía para reasignar la instancia a la misma partición cuando se vuelve a unir al grupo.

Para recuperarse de un error, debe almacenar el desplazamiento del último mensaje procesado para cada partición de forma que pueda comenzar a consumir desde ese mensaje si necesita reiniciar el consumidor.

Nota: No almacene el cursor; los cursores caducan cada 5 minutos.

No proporcionamos ninguna guía para almacenar el desplazamiento del último mensaje que procesó, por lo que puede usar el método que desee. Por ejemplo, puede almacenar el cursor en otro flujo, un archivo en una máquina virtual o un depósito de Object Storage. Cuando se reinicia el consumidor, lea el desplazamiento del último mensaje procesado, cree un cursor de tipo AFTER_OFFSET y especifique el desplazamiento que acaba de recibir.

El servicio Streaming proporciona un punto final Kafka que pueden utilizar sus aplicaciones existentes basadas en Apache Kafka. Solo se necesita un cambio de configuración para tener una experiencia Kafka completamente administrada. La compatibilidad de Kafka con Streaming ofrece una alternativa a la ejecución de su propio clúster Kafka. Streaming es compatible con Apache Kafka 1.0 y las versiones de cliente más recientes y funciona con sus aplicaciones, herramientas y marcos existentes de Kafka.

Los clientes con aplicaciones Kafka existentes podrán migrar a Streaming simplemente cambiando los siguientes parámetros de su archivo de configuración de Kafka.

security.protocol: SASL_SSL

sasl.mechanism: PLAIN

sasl.jaas.config: org.apache.kafka.common.security.plain.PlainLoginModule required username="{username}" password="{pwd}";

bootstrap.servers: kafka.streaming.{region}.com:9092

# Application settings

topicName: [streamOcid]

Para utilizar sus conectores Kafka con Streaming, cree una configuración de Kafka Connect mediante la consola o la interfaz de línea de comandos (CLI, command-line interface). En la API de Streaming estas configuraciones se denominan arneses. Las configuraciones de Kafka Connect creadas en un compartimento determinado funcionan solo para los flujos del mismo compartimento. Puede utilizar varios conectores Kafka con la misma configuración de Kafka Connect. En los casos en los que sea necesario producir o consumir flujos en compartimentos separados o cuando se requiera más capacidad para evitar alcanzar los límites del acelerador en la configuración de Kafka Connect (por ejemplo, demasiados conectores o conectores con demasiados trabajadores), puede crear más configuraciones de Kafka Connector.

Gracias a la compatibilidad de Kafka Connect con Streaming, puede aprovechar los muchos conectores existentes propios y de terceros para mover datos de sus fuentes a sus destinos. Conectores Kafka para productos Oracle:

• Oracle Cloud Infrastructure Object Storage (mediante el uso de Kafka Connect for S3)
• Conector de fuente Kafka Connect Amazon S3, para productores
• Conector receptor Kafka Connect Amazon S3, para consumidores
• Oracle Integration Cloud
• Oracle Database (mediante el uso de Kafka Connect JDBC)
• Oracle GoldenGate

Para obtener una lista completa de conectores de fuente y conectores receptores Kafka de terceros, consulte el centro oficial de Confluent Kafka.

Streaming está completamente integrado con Oracle Cloud Infrastructure Monitoring. En la consola, seleccione el flujo que desea supervisar. En la página Detalles del flujo, vaya a la sección Recursos y haga clic en Producir gráficos de seguimiento para supervisar las solicitudes de los productores, o bien, haga clic en Consumir gráficos de seguimiento para supervisar las métricas del lado del consumidor. Las métricas están disponibles a nivel de flujo y no a nivel de partición. Para obtener una descripción de las métricas de Streaming compatibles, consulte la documentación.

Cada métrica disponible en la consola proporciona las siguientes estadísticas:

• Rate (relación), Sum (Suma) y Mean (media)
• Min (mínimo), Max (máximo) y Count (recuento)
• P50, P90, P95, P99 y P99.9

Estas estadísticas se ofrecen para los siguientes intervalos de tiempo:

• Auto
• 1 minuto
• 5 minutos
• 1 hora

Para los productores, considere configurar alarmas en las siguientes métricas:

• Latencia de Put Messages: un aumento de latencia significa que los mensajes están tardando más en publicarse, lo que podría indicar problemas de red.
• Rendimiento total de Put Messages:
  • Un aumento importante en el rendimiento total podría indicar que se alcanzará el límite de 1 MB por segundo por partición y ese evento activará el mecanismo de aceleración.
  • Una disminución importante podría significar que el productor del cliente tiene un problema o está a punto de detenerse.
• Registros de Put Messages acelerados: es importante recibir notificaciones cuando se aceleran los mensajes.
• Error de Put Messages: es importante recibir notificaciones si los Put Messages comienzan a fallar, para que el equipo de operaciones pueda comenzar a investigar las razones.

Para los consumidores, considere configurar las mismas alarmas con base en las siguientes métricas:

• Latencia de Get Messages
• Rendimiento total de Get Messages
• Solicitudes aceleradas de Get Messages
• Error de Get Messages

Un flujo está en buen estado cuando está en estado Activo. Si puede producir en su flujo y la respuesta obtenida es correcta, significa que el flujo está en buen estado. Una vez producidos los datos en el flujo, los consumidores pueden acceder a ellos durante el período de retención configurado. Si las llamadas a la API de GetMessages devuelven niveles elevados de errores internos del servidor, significa que el servicio no está en buen estado.

Un flujo en buen estado también contiene métricas en buen estado:

• La latencia de Put Messages es baja.
• El rendimiento total de Put Messages es cercano a 1 MB por segundo por partición.
• El número de registros acelerados de Put Messages se aproxima a 0.
• El número de errores de Put Messages se aproxima a 0.

• La latencia de Get Messages es baja.
• El rendimiento total de Get Messages se aproxima a 2 MB por segundo por partición.
• El número de solicitudes aceleradas de Get Messages se aproxima a 0.
• El número de errores de Get Messages se aproxima a 0.

La aceleración indica que el flujo es incapaz de manejar nuevas lecturas o escrituras. El mecanismo de aceleración se activa cuando se superan los siguientes umbrales:

• GetMessages: cinco llamadas por segundo o 2 MB por segundo por partición
• PutMessages: 1 MB por segundo por partición
• Operaciones del plano de gestión y control, como CreateCursor, ListStream, etc.: cinco llamadas por segundo para cada flujo

Los detalles sobre los errores de API se encuentran en la documentación.