por Fadi Obeid, ingeniero principal y líder técnico, productos ad

Si ha trabajado en o con tiempo real, probablemente tuvo que lidiar con el registro de eventos. A las ShareThis, estamos en tiempo real – recolectamos señales sociales a medida que suceden, aplicamos lógica empresarial a estas señales y finalmente transformamos estas señales en reglas complejas de segmentación publicitaria. 

En este post vamos a cubrir el registro de eventos a escala de aspecto. Una versión simplificada de nuestra tubería se parece a la siguiente:

La corriente de Kafka está bombeando alrededor de 800.000.001.000.000.000 acontecimientos/día. Cada evento se expande en un promedio de 12 eventos virtuales, por lo que la lógica de negocio dentro del clúster de consumidores de Kafka tendrá que procesar y evaluar 9-12 billones de eventos por día, y registra los eventos de calificación en disco.

Inicialmente, teníamos un 1 × 1 traz del acontecimiento crudo al acontecimiento virtual que no era un reparto grande puesto que teníamos "bastantes máquinas". La capacidad del clúster fue de 3 instancias C3. Xlarge y fue respaldada por un registrador sincrónico de cosecha propia.

Con el tiempo, el mapeo aumentó – de 1 × 1 a 1 × 3 y así sucesivamente. Cada cuadro de Kafka del clúster se ejecutaba con 25 subprocesos y, al cargar, el efecto de bloquear la operación de escritura como se veía en este fragmento de código era paralizante. El ejecutor del grupo de subprocesos estaba atrasado en su capacidad para dar servicio a la solicitud entrante, y el offset de Kafka comenzó a rezagarse, a veces hasta un punto en el que nunca pudo ponerse al día.

Un perfil de los subprocesos de ejecución mostró que los hilos están bloqueados casi todo el tiempo, yikes!

Empezamos a ver nuestras opciones. Nuestra lista llegó a: 

• Agregar más máquinas
• Registrador asincrónico de cosecha propia
• Log4j2 asincrónico + disruptores + RandomAccessFile

Pasamos por pros y contras y aterrizamos en Log4j2. Lo comparamos, y los resultados fueron muy impresionantes. Para los propósitos de este post, estamos mostrando dos gráficas: la primera muestra el rendimiento a bajas cargas, y la segunda muestra el rendimiento a alta carga. La parte buena era lo fácil que era para conectarlo en el proyecto existente, el apoyo y la documentación amplia.

En conclusión, podemos decir con seguridad que nuestra opción "log4j2 asincrónico + disruptores + RandomAccessFile" para el registro fue la correcta. Si está pasando por un proceso similar, le recomendamos que Perfile su aplicación, que establezca sus opciones y que la evalúe.