Práctica de optimización de la tasa de repetición del nivel de registro del SDK de UBC

Desde datos hasta aplicaciones de modelos grandes, el 25 de noviembre se celebró la Conferencia Hangzhou Yuanchuang para compartir consejos de desarrollo.

Autor | wunan

Introducción 

El nivel de registro PV transmitido diariamente por el centro de registro puede alcanzar cientos de miles de millones. Los datos de registro redundantes se pueden reducir durante el proceso de generación de informes, lo que puede reducir la dificultad y el costo del procesamiento de datos posteriores, mejorar la precisión y la calidad de los datos y brindar un mejor soporte. Operación y optimización de sistemas empresariales. Este artículo presenta la práctica de optimización del SDK de UBC para el empaquetado de duplicación de registros. Al optimizar la base de datos, el proceso y el mecanismo de gestión, reduce efectivamente la tasa de duplicación a nivel de registro de tres milésimas a diez milésimas.

El texto completo tiene 8525 palabras y el tiempo estimado de lectura es de 22 minutos.

01 Introducción

El artículo primero presenta los antecedentes de deduplicación de la plataforma de registros y el mecanismo de gestión de UBC SDK, luego explica las dificultades y métodos para localizar problemas duplicados y, finalmente, se centra en el análisis y la práctica de solución de problemas duplicados.

1.1 Antecedentes de la deduplicación de registros

El centro de registros se centra en el desarrollo de capacidades del ciclo de vida completo de los registros finales, incluidas funciones como la recopilación, transmisión, gestión, consulta y análisis de datos de registros, etc., para realizar la gestión del ciclo de vida completo de los datos y resolver problemas como estandarización de registros y unificación de productos nuevos y antiguos, y mejora la utilización de recursos de la plataforma para maximizar el valor de aplicación de los registros.

Para garantizar que los datos posteriores reciban datos de manera eficiente y precisa, el centro de registro ha optimizado a largo plazo la puntualidad y confiabilidad de la transmisión de datos de un extremo a otro y ha logrado resultados notables, pero estas optimizaciones también han resaltado gradualmente el problema. de duplicación de datos.

Los problemas duplicados significan que el SDK informa el mismo registro al servidor más de una vez. Para reducir el QPS del servidor, el SDK empaquetará e informará varios registros, por lo que los problemas repetidos se pueden dividir en dos categorías:

1. Duplicación del paquete: el SDK envió los datos pero no recibió el resultado. El servidor se colocó en el disco, pero el paquete al final no se eliminó. El registro completo del paquete se informa repetidamente.

2. Duplicación de registros: se ingresa un único registro en varios paquetes y se informa al servidor con cada paquete.

El servidor del centro de registro ha lanzado una solución de deduplicación de transmisión para garantizar que no haya duplicación granular de paquetes en los datos descendentes. El servidor realiza la deduplicación a través del paquete md5, pero el mismo registro ingresado en diferentes paquetes dará como resultado diferentes md5. En este caso, el servidor no puede identificarlo. Por lo tanto, el requisito previo para la deduplicación del lado del servidor es que el SDK garantice que los registros informados no se empaqueten repetidamente.

1.2 Introducción al SDK de UBC

El SDK UBC (User Behavior Collection), es decir, el SDK de recopilación del comportamiento del usuario, es responsable de la recopilación, empaquetado, generación de informes y otras funciones de los registros de administración del terminal. Registra los datos del comportamiento del usuario y los carga en el servidor del centro de registro. Es el fuente del enlace de transmisión de datos del centro de registro.

1.2.1 Tipo de punto

Según el contenido expresado por la dirección, se puede dividir en gestión de eventos y gestión de flujo, que registran el comportamiento único y el comportamiento de estancia, respectivamente.

Las diferentes partes comerciales tienen diferentes requisitos en cuanto a la puntualidad de los informes puntuales. De lento a rápido, se pueden dividir en: informes en tiempo no real, informes en tiempo real, informes directos e informes de registro. Existen diferencias en los procesos de ejecución de diferentes tipos de informes.

1.2.2 Mecanismo de gestión

UBC SDK lleva el registro y transmisión de la mayoría de los datos en la fábrica. Ambos extremos pueden informar cientos de miles de millones de registros en un solo día. Deben informarse de manera rápida y precisa sin afectar la ejecución del hilo principal. Para lograr este objetivo, la UBC ha tomado las siguientes medidas:

1. Procesamiento asincrónico por fases : para garantizar la eficiencia y estabilidad de los informes, el SDK divide internamente todo el proceso en múltiples etapas y las entrega a subprocesos de tareas y subprocesos de envío para programación y ejecución asincrónicas.

2. Almacenamiento persistente de registros y paquetes : para garantizar que los registros no se pierdan, el SDK conservará los registros en SQLite, los guardará en archivos al enviarlos e intentará enviarlos repetidamente hasta que tenga éxito.

3. Múltiples tiempos de activación de informes : para tener en cuenta el rendimiento y la puntualidad de los informes, el SDK activará los informes de registros en diferentes momentos, como por ejemplo, inmediatamente cuando se produce la gestión en tiempo real, y cuando la gestión no en tiempo real llega a los informes. período, cambiar entre front-end y backend, o informar datos acumulados cuando la red se recupera, etc.

La arquitectura del módulo principal del SDK de UBC se muestra en la siguiente figura:

El proceso básico de gestión, almacenamiento y envío de registros UBC se muestra en la siguiente figura:

02 Medios de posicionamiento

2.1 Dificultades de posicionamiento y metodología

Existen las siguientes dificultades para solucionar problemas de duplicación de registros finales:

1. Hay muchas partes comerciales que utilizan UBC. Los diferentes escenarios de activación son diferentes en diferentes puntos y los problemas que surgen también son diferentes. Es imposible comprender los métodos de llamada de todos los servicios.

2. La duplicación de registros se debe principalmente a eventos anormales subyacentes de baja probabilidad, que están estrechamente relacionados con el entorno local del usuario, la versión del sistema y el fabricante, y el problema es difícil de reproducir.

3. UBC SDK es la entrada a los datos y afecta a todo el sistema. Cualquier modificación en el proceso de presentación de informes puede provocar fluctuaciones en los datos existentes y afectar las estadísticas comerciales.

Por lo tanto, este tipo de problema es difícil de solucionar y optimizar a través de medios comunes. UBC ha formado gradualmente un conjunto de metodologías en el proceso de manejo:

2.2 Herramientas de posicionamiento

2.2.1 Identificación de registros en línea

Los registros en línea son la forma más directa de monitorear indicadores, incluidas las tasas de duplicación, pero encontrar registros empaquetados duplicados entre cientos de miles de millones de datos es como encontrar una aguja en un pajar.

Por lo tanto, al localizar problemas duplicados, son cruciales varios tipos de indicadores, que se pueden utilizar para identificar y correlacionar diferentes entradas de registro para ayudar a determinar qué problemas están duplicados. A través de estadísticas de datos y alarmas de monitoreo, se pueden descubrir problemas dentro del límite de tiempo T+1 y los problemas se pueden analizar directamente a través de los datos sin procesar que participan en las estadísticas.

Para encontrar registros duplicados, primero debe identificar un registro de forma única.

Log uuid : UUID (Identificador único universal) ​​es una cadena de 128 bits que puede garantizar que un objeto o evento se identifique de forma única a nivel mundial, es decir, un registro se puede identificar de forma única en el mismo dispositivo para su registro y seguimiento. Los cambios pueden causar fluctuaciones en los datos existentes y afectar las estadísticas comerciales.

Los registros reportados repetidamente a TC-Box se pueden encontrar a través del uuid de registro. Sin embargo, para determinar si se trata de un paquete duplicado o un registro duplicado, es necesario juzgarlo en función de la información del paquete. Hay dos información de identificación principal del paquete. :

1. Paquete md5 : MD5 (Algoritmo de resumen de mensajes 5) es una función hash criptográfica ampliamente utilizada que puede recibir datos de cualquier longitud y generar un valor hash de longitud fija. UBC calcula el valor md5 a través del contenido del paquete como identificador del paquete.

2. Tiempo de creación del paquete : marca de tiempo del empaquetado a nivel de milisegundos. Dado que el valor de md5 es el mismo cuando el contenido del paquete es el mismo, si el mismo lote de datos se empaqueta varias veces, md5 no puede identificarlo, por lo que se debe usar md5 + createtime como identificador de identificación para empaquetamientos repetidos.

Además de la información de identificación, también se necesita otra información para ayudar a tomar decisiones, como por ejemplo:

1. marca de tiempo : la marca de tiempo en el momento de la administración, que se puede combinar con registros repetidos antes y después de la administración para inferir las operaciones del usuario.

2.appv : El número de versión de la aplicación durante la administración. Al evaluar el efecto de optimización, es necesario reducir la interferencia de los informes retrasados ​​de versiones antiguas.

3.proceso : Ejecute el ID del proceso empaquetado y el nombre del proceso. Cuando existen varios procesos en la instancia de UBC al mismo tiempo, puede ocurrir duplicación debido a la inseguridad del proceso.

4.disparador : Tiempo de activación del paquete. En circunstancias normales, diferentes tiempos de informes tienen diferentes frecuencias. La frecuencia anormal de los tiempos de informes también puede ayudar a localizar problemas.

5.db_sync : modo de sincronización SQLite, que se puede utilizar para ayudar a verificar las excepciones causadas por los métodos de reescritura de la base de datos del usuario.

2.2.2 Monitoreo anormal

Pueden ocurrir varias anomalías durante la ejecución de UBC. Para detectar estas anomalías de manera oportuna, UBC debe ser monitoreada a través de informes y gestión.

Los diferentes tipos de monitoreo y gestión de anomalías llevarán el estado de ejecución de enlaces especiales, pilas de excepciones y otros contenidos para ayudar en la resolución de problemas repetidos, estadísticas de magnitud de excepciones y análisis del efecto de reparación.

Para evitar situaciones anormales que provoquen que el proceso normal de UBC no se pueda ejecutar, el monitoreo omitirá el almacenamiento de UBC y almacenará e informará mediante omisión.

2.2.3 Gestión empresarial

Como SDK en la capa de servicio, UBC está desacoplado del negocio, por lo que solo puede monitorear el comportamiento del SDK en sí y no puede obtener directamente la ruta de operación del usuario ni la información del dispositivo.

La gestión del lado empresarial ocurre en varios escenarios de operaciones de los usuarios y puede ayudar a restaurar el comportamiento del usuario. Por ejemplo, podemos determinar el comportamiento de conmutación y arranque en frío del front-end y back-end del usuario mediante la activación manual de puntos relevantes; mostrar los puntos a través de la pantalla de presentación y obtener la energía del usuario para determinar si el dispositivo del usuario se ha apagado. y reiniciado, registra varios estados de la red, disco, etc. a través de otros puntos y otra información.

03 Atribución y resolución de problemas repetidos

3.1 Problemas relacionados con la base de datos

Según el proceso de ejecución de la administración, para solucionar el problema del empaquetado repetido de registros individuales, lo primero que me viene a la mente es solucionar el problema de la etapa de empaquetado de registros por lotes.

Hay muchas ramas lógicas en este enlace y las estrategias de ejecución de gestión en tiempo real y no real son diferentes:

• Después de que se activa el RBI no en tiempo real, primero se escribe en el caché y luego en la base de datos. Después de alcanzar el tiempo de informe, se consulta la base de datos en lotes y se activa el informe;

• La administración en tiempo real se escribe primero en el archivo para activar los informes. Si la escritura del archivo falla, se escribe en la base de datos. Al escribir el archivo, se consultará a la base de datos para agregar un lote de administración no en tiempo real.

En el análisis inicial de los datos repetidos, hubo pocos puntos de gestión en tiempo real, y la mayoría de ellos eran gestión no en tiempo real y gestión de transmisión que debían almacenarse en la base de datos. Por lo tanto, en la primera etapa de solución de problemas duplicados, nos centramos en solucionar problemas relacionados con la base de datos.

El proceso de empaquetado es el proceso de "transferir registros de la base de datos a archivos en lotes" Los detalles de los pasos que se muestran en el cuadro azul se muestran en la siguiente figura.

En circunstancias normales, si falla la eliminación del registro empaquetado en la base de datos después de escribir el archivo, el SDK finalizará el proceso de informes y eliminará el archivo generado, interrumpiendo el proceso de envío para evitar el empaquetado repetido.

La intención original de este enlace es resolver el problema del envío repetido causado por la lectura directa de la base de datos al informar, sin embargo, si hay excepciones que el SDK no conoce durante el proceso, hará que se envíe directamente el archivo actual. con éxito, pero el registro no se elimina. Este lote de registros es el siguiente Cuando se informa por primera vez, se consultará y empaquetará nuevamente, lo que resultará en una duplicación.

3.1.1 Corrupción de la base de datos

De acuerdo con la metodología de localización de problemas mencionada en la Sección 2.1, los usuarios duplicados se clasifican según las características de los datos, las causas de la duplicación se atribuyen una por una y los problemas duplicados con una gran proporción se localizan como corrupción de la base de datos.

(1) Atribución de problemas

Características de los datos

• El PV reportado por los usuarios en un solo día es enorme, y los casos graves alcanzan millones (el número promedio de PV reportado por un solo usuario en un solo día es de aproximadamente 2000).

• La mayoría de los registros informados por los usuarios son registros duplicados y el mismo registro se empaquetará varias veces.

• El intervalo entre embalajes múltiples es muy corto y no se experimenta ningún arranque en frío.

• La mayoría de los paquetes duplicados tienen el mismo md5, pero diferentes tiempos de creación, y la condición desencadenante es que la cantidad de elementos exceda el límite.

especulación de la razón

La eliminación de la transacción de registro empaquetada devuelve un resultado exitoso y lo informa, pero el resultado de la eliminación real es un error.

análisis mas extenso

Revisamos el código para eliminar datos reportados e inicialmente descartamos algunos factores que influyen:

• Toda la lógica se agrega con un bloqueo de sincronización para eliminar la influencia de otros subprocesos.

• Se detectarán excepciones de ejecución de SQL y se devolverá un error. El archivo actual se eliminará y no se informará.

• Supervisamos la situación en la que la cantidad de elementos eliminados mediante el método de eliminación no era la esperada, pero la magnitud del problema era pequeña y tenía poco impacto en la tasa de repetición.

Un análisis más detallado de las dos capas de try-catch en el código reveló el problema:

• Try-catch de capa interna: ejecute múltiples SQL, establezca el indicador de éxito de la transacción después del éxito y establezca el indicador de resultado en verdadero.

• Try-catch de capa exterior: envíe la transacción y cuente los resultados de la eliminación.

Al ingresar a la capa externa, el bit de bandera se estableció en verdadero, pero el resultado de la transacción enviada no se procesó, se infiere que ocurrió una excepción no controlada en este enlace y provocó que la transacción se revirtiera.

atribución de apoyo

• Para determinar la causa de la excepción, se refina el monitoreo de excepciones de SQL y se registran todas las pilas de excepciones capturadas en la clase DatabaseHelper.

• Obtuve datos de monitoreo anormales de usuarios duplicados y descubrí que había una gran cantidad de excepciones de SQL. La pila es la siguiente: Se produjo una excepción de corrupción de base de datos SQLiteDatabaseCorruptException durante db.endTransaction, lo que corrobora los resultados del análisis del código.

  

pila de choque

• El sitio web oficial de SQLite también explica el problema del daño de la base de datos: la falla de sincronización del archivo, el daño del disco, la escritura anormal de datos y otros problemas durante el proceso de lectura y escritura de la base de datos pueden causar daños a la base de datos.

  

atribución final

• La corrupción de la base de datos puede provocar que partes del registro sean legibles pero no escribibles.

• El resultado de la ejecución de la eliminación de datos se actualizó antes de que se confirmara la transacción y el informe se procesó de acuerdo con el resultado exitoso, pero la transacción se revirtió debido a daños en la base de datos y los datos no se eliminaron correctamente.

• Después de que cada carga sea exitosa, se verificará la cantidad de entradas de la base de datos. Si se excede el umbral, la carga se activará nuevamente. La escritura se detendrá después de que un solo paquete exceda el límite, lo que resultará en una gran cantidad de informes en un período corto. de tiempo con el mismo md5 de los paquetes.

(2)Plan de optimización

Para solucionar este problema, se requiere una optimización de dos pasos en ambos extremos:

1. Corrija los resultados de la ejecución de la transacción de la base de datos y restablezca los resultados si ocurre una excepción durante el envío de la transacción;

2. Reconstruya la base de datos cuando esté dañada. Elimine el archivo de la base de datos y sus archivos adjuntos -journal, -shm, -wal. El archivo de la base de datos se volverá a crear cuando la base de datos se abra nuevamente.

Evaluación de riesgos

1. UBC tiene una alta puntualidad en la presentación de informes. La mayoría de los datos se pueden informar y borrar de la base de datos en 1 minuto. Por lo tanto, generalmente solo se retienen unos pocos datos en la base de datos. La eliminación directa de los datos perdidos está dentro de un rango aceptable.

2. Las operaciones de eliminación y reconstrucción de archivos no deben realizarse con frecuencia, la frecuencia de reparación de la base de datos debe ser limitada y se deben recopilar estadísticas para cada operación de reparación y resultado.

3. El riesgo de reconstrucción de la base de datos es relativamente alto, por lo que se utiliza el método experimental de distribución dirigida AB para confirmar que es efectivo y que no tiene otros efectos antes de aumentar gradualmente el volumen.

Efecto de optimización

1. En la etapa inicial del experimento, el cambio experimental se dirigió a usuarios con una gran cantidad de informes repetidos, y todos se repararon con éxito y la tasa de repetición volvió a 0 después de la reparación.

2. Una vez que el experimento se haya implementado por completo, según las estadísticas de monitoreo, se pueden reparar con éxito más de 40 daños en la base de datos por día y ya no habrá una gran cantidad de problemas repetidos.

3. Después de optimizar el problema de corrupción de la base de datos, la tasa de duplicación del mercado cayó a menos de dos milésimas, una disminución de aproximadamente 0,07 puntos porcentuales, lo que representa aproximadamente el 35% del nivel antes de la optimización.

3.1.2 Error al escribir el archivo WAL

(1) Atribución de problemas

Características de los datos

• Si hay usuarios duplicados, un lote de paquetes se empaquetará dos veces.

• Hay un arranque en frío en los dos paquetes y el intervalo es largo.

• El último paquete es el primer paquete después del inicio en frío y la condición desencadenante para el empaquetado son los informes en tiempo real o los informes de recuperación de la red.

especulación de la razón

Una falla a nivel del sistema en el dispositivo del usuario provocó que la operación de la base de datos fuera exitosa, pero falló la reescritura.

análisis mas extenso

• A partir de Android 9.0, el modo WAL (registro de escritura anticipada) de SQLite está habilitado de forma predeterminada. En el modo WAL, SQLite registrará las operaciones de modificación en el archivo WAL. Cuando el sistema esté inactivo o cuando se confirme la transacción, se realizará una operación de punto de control y luego el archivo WAL se volverá a escribir en el archivo de base de datos en el disco. . SQLite utiliza este mecanismo para evitar operaciones frecuentes de escritura en disco y mejorar el rendimiento de escritura y la concurrencia de la base de datos.

• Cuando la operación de modificación se escribe en el archivo WAL y el archivo WAL se vuelve a escribir en el archivo de la base de datos, pasará por el proceso de escribir primero en el búfer del disco y luego realizar la operación fsync para vaciarlo en el disco. La clave para saber si las transacciones se pueden recuperar después de una excepción del sistema radica en si el archivo WAL ejecuta fsync con éxito.

• Hay dos modos principales de sincronización WAL comúnmente utilizados: PRAGMA esquema.synchronous = NORMAL | COMPLETO. La diferencia entre los dos es que NORMAL devolverá el resultado de la confirmación antes de que se ejecute fsync al escribir el archivo WAL, mientras que el modo COMPLETO en realidad escribirá el Archivo WAL al disco. El resultado se devuelve más tarde.

• La documentación oficial de SQLite menciona: En el modo NORMAL, el envío de transacciones puede revertirse cuando se corta la energía o el sistema falla.

atribución de apoyo

1. Inicie la gestión relacionada para registrar la energía del usuario. Para algunos usuarios, la energía fue inferior al 10% durante el paquete anterior. Sin embargo, la energía se recuperó durante el segundo paquete, lo que indica que hubo un problema de corte de energía durante el período.

2. Traiga y reporte la información del modo de sincronización de la base de datos. Se ha verificado que los modos de la base de datos de los usuarios con problemas tan repetidos son todos NORMALES.

atribución final

1. El SQLite del dispositivo del usuario utiliza el modo NORMAL de WAL. Después de que la transacción de eliminación se escribe en el búfer del disco WAL y antes de que el búfer se sincronice con el disco, se produce un corte de energía o una falla del sistema.

2. La transacción se consideró exitosa y se informó, pero el archivo WAL no se escribió. Por lo tanto, los datos en el archivo del disco no se eliminaron y la eliminación no se puede realizar nuevamente después de restaurar el sistema. Los datos informados aún existen.

(2)Plan de optimización

Según el motivo de la duplicación se puede deducir la solución a este problema, es decir, asegurar que la operación se escriba en el disco lo más rápido posible una vez completada la operación de la base de datos, existen tres métodos de ejecución: (1) Turno apagado del modo WAL; (2) Establezca el modo de sincronización en COMPLETO; (3) Ejecute manualmente el punto de control.

Después de comparar y probar múltiples soluciones en el lado de Android, finalmente se obtuvo una solución de compromiso: solo se garantiza la confiabilidad de la transacción de la base de datos "Eliminar datos empaquetados". Cuando el modo de sincronización es NORMAL, el punto de control se activa manualmente después de eliminar los datos, lo que activa Escritura del archivo WAL. Ingrese el archivo DB y asegúrese de que SQLite haya completado al menos la operación fsync del archivo WAL. El tiempo que lleva ejecutar un punto de control es básicamente el mismo que el tiempo que lleva ejecutar una transacción, y la degradación del rendimiento está dentro de un rango aceptable.

Para garantizar que las transacciones se escriban completamente en modo WAL en el lado de iOS, además de configurar el modo de sincronización en NORMAL, también debe habilitar la opción fullfsync para garantizar estrictamente que el orden de escritura sea coherente con el orden de envío. Después de las pruebas y evaluaciones, la degradación del rendimiento fue mayor que el beneficio de la optimización de la tasa de repetición y finalmente decidimos no realizar esta optimización.

Efecto de optimización

• Las fallas de escritura de WAL representan aproximadamente el 70% de los problemas de duplicación de cola larga en la nueva versión.

• Según los datos experimentales del lado de Android, en una sola hora, el grupo experimental redujo el empaquetado repetido más de 200 veces en comparación con el grupo de control.

3.2 Relacionado con el proceso

Después de optimizar el problema de empaquetado repetido causado por daños en la base de datos, consultamos los datos del mercado y descubrimos que todavía hay un problema en el lado de Android donde los registros se ingresan repetidamente en dos paquetes con un intervalo corto y el usuario no tiene información de excepción de la base de datos. .

Este problema de activar el empaquetado al mismo tiempo en un corto período de tiempo lleva naturalmente a otra pregunta: si el hilo UBC es seguro. Sin embargo, como se muestra en la Sección 1.2.2, solo hay dos colas dentro de UBC. La lectura de la base de datos y el empaquetado son operaciones de un solo subproceso. En teoría, no habrá problemas de concurrencia de subprocesos.

Por lo tanto, centramos nuestra atención en los problemas de seguridad del proceso en el lado de Android:

1. Además del proceso principal, la aplicación Baidu también tiene múltiples subprocesos, como pequeños programas y medios, diferentes procesos llamarán a la API de administración.

2. Para garantizar la velocidad de inicio, UBC adopta un método de inicialización de carga diferida: un singleton de UBC se inicializará solo cuando el proceso actual no tenga una instancia de UBC.

3. Si la parte comercial llama a la API en un proceso no principal, UBC realizará IPC en el hilo principal para su ejecución para garantizar que solo el proceso principal tenga un singleton UBC en el ciclo de vida. Si hay un problema con este proceso, puede provocar que se inicialice otra instancia de UBC en el proceso secundario.

Cuando dos procesos tienen singleton UBC al mismo tiempo, puede ocurrir inseguridad en el proceso, como se muestra en la siguiente figura.

1. Dos procesos empaquetan y operan la base de datos al mismo tiempo. Si un proceso ejecuta una consulta antes de que el otro proceso elimine los datos, el mismo lote de datos se escribirá en dos archivos.

2. La secuencia de ejecución de las operaciones de eliminación hará que la operación de eliminación posterior devuelva un número de eliminación de 0 porque los datos no existen, pero el informe no finalizará al generar una excepción.

Hay dos tipos de razones por las cuales los problemas de múltiples procesos conducen a la inicialización de dos singleton de UBC: falla de IPC y falla de juicio de proceso. Los dos problemas tienen diferentes manifestaciones y razones para el empaquetado repetido, que se presentan una por una a continuación.

3.2.1 La falla de IPC genera múltiples instancias de UBC

(1) Atribución de problemas

Características de los datos

• Si hay usuarios duplicados, un lote de puntos se empaquetará dos veces.

• El tiempo entre dos paquetes es corto (menos de 1 segundo).

• Entre las condiciones desencadenantes del paquete, la recuperación de la red y la conmutación en segundo plano ocurren con frecuencia.

• Cuando se empaquetan dos datos duplicados, el ID del proceso y el nombre del proceso son diferentes.

especulación de la razón

Los dos procesos tienen instancias UBC respectivamente, monitorean eventos del sistema simultáneamente y leen paquetes de bases de datos.

atribución adicional

Después de comunicarnos con el lado comercial del marco multiproceso, resolvimos las razones de la aparición de dos casos únicos de UBC y empaquetamientos repetidos:

1. Si se produce un error cuando el marco multiproceso IPC pasa del proceso secundario al proceso principal, se activará la gestión de fallas de IPC en el proceso secundario.

2. Esta administración llama a la interfaz antigua de administración multiproceso abandonada de UBC. La interfaz anterior permite inicializar un singleton de UBC en el proceso secundario y agrega monitoreo de la conmutación de front-end y back-end y del estado de la red.

3. La conmutación de front-end y back-end y la recuperación de la red activan el monitoreo, lo que hace que dos instancias de UBC realicen el empaquetado al mismo tiempo.

atribución de apoyo

Uno de los dos paquetes con problemas repetidos tiene un punto de falla de IPC, lo cual es consistente con la conclusión del análisis.

(2)Plan de optimización

En respuesta a este problema, después de la evaluación de impacto, finalmente se realizó una optimización en dos pasos:

1. Cuando el subproceso restringe el empaquetado, se activa la conmutación de front-end y la recuperación de la red, el proceso no principal no ejecuta el proceso de empaquetado;

2. Optimice la interfaz de administración de múltiples procesos, omita la lógica de programación UBC en procesos no principales, evite la inicialización de instancias y escriba directamente puntos de administración en archivos para generar informes.

Efecto de optimización

Después de optimizar este problema, la tasa de duplicación del mercado cayó a menos de una milésima, una disminución de aproximadamente 0,04 puntos porcentuales, lo que representa aproximadamente el 33% de la tasa previa a la optimización.

3.2.3 La falla en el juicio del proceso conduce a múltiples instancias de UBC

(1) Atribución de problemas

Características de los datos

• Si hay usuarios duplicados, un lote de puntos se empaquetará dos veces.

• El tiempo entre dos paquetes es corto (menos de 1 segundo).

• Los activadores en tiempo real representan la mayoría de las condiciones de activación del empaquetado, pero hay casos en los que ambos son activadores no en tiempo real. En circunstancias normales, los paquetes que no son en tiempo real deben estar separados por al menos 1 minuto.

• Uno de los dos paquetes tiene administración activada por subprocesos (como vistas de páginas de miniprogramas), pero no hay administración de fallas de IPC.

especulación de la razón

Hay dos instancias de UBC, y los RBI A y B ingresan y activan el empaquetado al mismo tiempo. Las dos instancias de UBC son concurrentes y ambos RBI C en la base de datos se consultan y empaquetan para generar informes.

atribución adicional

• Combinando el rendimiento de los datos y los resultados de optimización del problema de falla de IPC, el problema no es el informe concurrente de datos acumulados causado por la falla de IPC, sino la concurrencia de múltiples procesos desencadenados por RBI, por lo que el principal punto de sospecha es el juicio del proceso.

• El método proporcionado por el marco multiproceso se utiliza para determinar el proceso principal. La lógica para determinar si el nombre del proceso actual es igual al nombre del paquete es el proceso principal y obtener el nombre del proceso actual:

• Leer registros de memoria → Obtener del archivo del sistema /proc/self/cmdline → Obtener de ActivityManager

• Si los métodos anteriores no logran obtenerlo, use el nombre del paquete como nombre del proceso.

• El nombre del paquete suele ser el mismo que el del proceso principal. Si el nombre del paquete se utiliza como nombre del proceso en el proceso secundario, se producirá un error de juicio, lo que inicializará otro singleton UBC en el proceso secundario, lo que provocará problemas repetidos de empaquetado.

atribución de apoyo

El usuario empaquetó el proceso dos veces con el mismo nombre pero con diferentes ID de proceso, lo que es coherente con la conclusión del análisis del código.

(2)Plan de optimización

Como SDK de gestión, UBC no debe prestar demasiada atención a la lógica de juicio del proceso, por lo que es necesario promover la actualización del marco multiproceso y aumentar la forma de obtener el nombre del proceso:

Android API 28 agrega un nuevo método para obtener nombres de procesos, Application.getProcessName(), que no requiere reflexión ni IPC y puede usarse como un método de juicio redundante para nombres de procesos.

Efecto de optimización

• Los problemas de duplicación causados ​​por fallas en el juicio del proceso representan aproximadamente el 20% de los problemas de cola larga del empaquetado duplicado en nuevas versiones.

• Después de optimizar el método de evaluación del proceso, el número de paquetes repetidos dos veces en un segundo se ha reducido aproximadamente a la mitad. El problema de la duplicación de registros de nuevas versiones solo se debe a dispositivos de versión baja que no admiten esta API.

3.3 Relacionado con el mecanismo de gestión

3.3.1 volver a iniciar sesión

(1) Atribución de problemas

Reallog es un tipo especial de administración. No almacena en caché después de la administración. Solo realiza una operación de consulta de E/S. Lleva datos históricos de fallas y los informa directamente a la memoria. Después de que el informe falla, se escribe en la base de datos. .

Este mecanismo está configurado para garantizar la máxima puntualidad en el informe de datos, pero en circunstancias anormales provocará un empaquetado repetido de reallog: el registro se informó correctamente y se colocó en el disco, pero el resultado del servidor no se devolvió a tiempo y UBC lo almacena. el registro de acuerdo con la lógica de falla. Ingrese a la base de datos y sea consultado e informado cuando se active la próxima gestión de registro.

Como se muestra en la figura anterior, la administración del tipo de reallog se empaquetará e informará de forma independiente, y el indicador reallog=1 se incluirá en la URL. Utilice este identificador para verificar datos duplicados, lo que demuestra el problema de duplicación causado por el reallog.

(2) Plan de optimización

Para optimizar el problema de reallog, se pueden adoptar dos soluciones: la duplicación de registros se convierte en duplicación de paquetes o la gestión de reallog se degrada a gestión en tiempo real.

Evaluación de caso:

• Como tipo de gestión especial, el reallog no se puede configurar a través del centro de registro, solo lo utilizan muy pocos empresarios, es una gestión que no cumple con los estándares del centro.

• Después de múltiples rondas de optimización de la puntualidad, la puntualidad actual del percentil 97 de la gestión ordinaria en tiempo real es de aproximadamente 0,5 minutos, lo que es suficiente para satisfacer las necesidades de las partes comerciales.

Después de evaluar los costos y beneficios de las dos opciones y confirmarlos con las partes comerciales relevantes, finalmente se decidió optimizar mediante una reasignación gradual fuera de línea a través de experimentos y, al mismo tiempo, lograr la convergencia del tipo de punto UBC.

Efecto de optimización

• Aproximadamente el 10% de los problemas de duplicación de cola larga en las nuevas versiones son causados ​​por el reallog.

• Una vez que reallog esté fuera de línea, ya no habrá duplicaciones de este tipo en ambos extremos y no tendrá ningún impacto en el uso de partes comerciales relacionadas.

04 Resumen y perspectivas

Informar los registros de manera precisa y eficiente es la intención y el objetivo original de UBC SDK como fuente de datos de registros. Después de esfuerzos a largo plazo, UBC ha mejorado enormemente su puntualidad y tasa de llegada. Esta vez, exploramos y optimizamos los problemas que se informaron repetidamente, descubrimos y resolvimos varios problemas y peligros ocultos en el proceso de administración del SDK, y aumentaremos la tasa de duplicación de registros. se reduce de tres milésimas a menos de una milésima, lo que proporciona datos más confiables para los datos posteriores.

Al mismo tiempo, hemos acumulado una valiosa experiencia en la resolución de diversos problemas de administración final, optimizamos los registros locales y creamos un monitoreo más detallado del proceso de ejecución del SDK, sentando una base de datos sólida para descubrir y localizar rápidamente problemas en el futuro.

--FIN--

Lectura recomendada

Práctica de optimización y negocios del modelo de aprendizaje profundo de búsqueda de Baidu

Práctica a gran escala de Wenshengtu: ¡Revelando la historia detrás de la búsqueda de Baidu de herramientas de pintura AIGC!

Práctica de aplicación de modelos grandes en el campo de la detección de defectos de código.

Admite la práctica de reconstrucción de código OC a través de scripts de Python (2): los elementos de datos proporcionan generación de código para las rutas de datos de acceso al módulo

Hable con InfoQ sobre el motor de búsqueda de alto rendimiento y código abierto de Baidu, Puck

Alibaba Cloud sufrió un fallo grave y todos los productos se vieron afectados (restaurados). Tumblr enfrió el sistema operativo ruso Aurora OS 5.0. Se presentó la nueva interfaz de usuario Delphi 12 y C++ Builder 12, RAD Studio 12. Muchas empresas de Internet contratan urgentemente programadores de Hongmeng. Tiempo UNIX está a punto de entrar en la era de los 1.700 millones (ya entró). Meituan recluta tropas y planea desarrollar la aplicación del sistema Hongmeng. Amazon desarrolla un sistema operativo basado en Linux para deshacerse de la dependencia de Android de .NET 8 en Linux. El tamaño independiente es reducido en un 50%. Se lanza FFmpeg 6.1 "Heaviside"

{{o.nombre}}

{{m.nombre}}