¿Cómo maneja el lado del servidor las mismas solicitudes múltiples al mismo tiempo?

1. La forma en que el tiempo de ejecución de un lenguaje de programación garantiza que las solicitudes simultáneas que apuntan al mismo estado no interfieran entre sí es, en última instancia, a través de un mecanismo llamado "comparar y establecer" que debe ser ofrecido por el hardware en el que se encuentra. el código se está ejecutando.

   "Comparar y configurar" funciona de la siguiente manera: dos subprocesos dicen al hardware- "compara el valor de la variable X a 300, luego, si es igual, configura X a 301", y el hardware garantizará que solo una de esas instrucciones Se ejecuta a la vez. El primero devolverá un nuevo resultado para la variable X, el segundo no lo hará.

   Dicho esto, hay mucho, mucho más en la historia. Las CPU ofrecen el mecanismo de comparar y establecer en el contexto de los datos en los registros. Esos datos aún tienen que convertirse en RAM y, por lo tanto, almacenarse de manera duradera en un disco. Hay un número infinito de formas en que los constructores de un sistema pueden no organizar todas las partes móviles requeridas para que esta maquinaria se complete con éxito, lo que lleva a que la contabilidad salga mal.

2. No sucede nada por casualidad, pero hay muchas clases de fallas de diseño, implementación y operación que pueden hacer que los sistemas concurrentes se comporten con una consistencia menor a la deseada.

3. No hay un nombre único para las vulnerabilidades de este tipo, ni un solo nombre para el subcampo de informática en el que se produce trabajo relevante para este tipo de problema. La concurrencia, los sistemas distribuidos, los modelos de consistencia, el aislamiento de las transacciones, el uso de Google en cualquiera de esos términos dará lugar a vetas ricas para estudiar y aprender más.

   En el contexto de los dos ejemplos citados, la visualización de videos en YouTube y las transacciones bancarias, lo que es importante entender es que estos dos problemas tienen diferentes requisitos.

   No importa mucho si YouTube congela las vistas en 300 o 310 o incluso 500 o algún otro número mágico. El límite es arbitrario y fue elegido por google para optimizar su flujo de trabajo. Ligeras cuentas erróneas no tienen ningún impacto económico o de otro tipo.

   Por otro lado, las cuentas erróneas en las transacciones bancarias, por supuesto, tienen un impacto económico directo.

   También es importante entender que el trabajo requerido por los programadores e ingenieros de sistemas distribuidos para obtener la contabilidad exactamente correcta es significativamente diferente y mucho más difícil que obtener la contabilidad aproximadamente correctamente.

   En resumen, estos dos problemas tienen requisitos diferentes y soluciones diferentes.

   La falta de coherencia en la solución detrás del conteo de vistas de YouTube es un reflejo de los requisitos, no una implicación de que otras soluciones en Google o en cualquier otro contexto contable se comporten de la misma manera.

  

¿Cómo maneja este tipo de solicitud un lenguaje de programación del lado del servidor?

La mayoría de los lenguajes de programación no se ocupan de esto. En cambio, este problema generalmente se resuelve mediante bases de datos, que están diseñadas para resolver este tipo de problemas mediante transacciones.

Ahora la pregunta cambia a, ¿cómo resuelven esto las bases de datos? Una variedad de formas, antiguas bases de datos relacionales usadas para bloquear registros de modo que solo una solicitud pueda modificar un valor particular al mismo tiempo. Las bases de datos relacionales modernas utilizaron una técnica llamada MVCC (control de concurrencia de múltiples versiones), que usó una estructura de datos basada en registros para permitir que varios lectores y escritores múltiples accedan al mismo registro de forma segura y concurrente, y para detectar y restaurar cuando hay conflictos de actualización. Algunas bases de datos distribuidas no relacionales eliminan el requisito de una consistencia estricta de los datos y, en cambio, permiten datos inconsistentes temporalmente, con una garantía "eventualmente consistente".

En el nivel más básico, la primitiva usaba una instrucción de CPU llamada comparar y cambiar. En un nivel superior, tiene una estructura de datos, un registro / diario de escritura anticipada, que realiza un seguimiento de los cambios en un archivo de solo anexo antes de que los cambios se incorporen a la estructura de datos actual. A nivel de infraestructura distribuida, tiene varios algoritmos de consenso como Paxos o Raft, y una serie de libros de contabilidad distribuidos especializados para garantizar una contabilidad coherente en múltiples máquinas.

Es probable que el contador de vistas de YouTube emplee una infraestructura distribuida con un contador "eventualmente consistente" en lugar de un contador totalmente consistente. Esto significa que, en cualquier momento, el contador de cada réplica puede que nunca refleje el conteo de la vista universal real, pero supuestamente, si el mundo deja de acceder a YouTube y se le da un poco de tiempo al sistema para alcanzar un estado estable, la infraestructura distribuida eventualmente convergen al recuento de vistas reales.

  

¿Pueden dos solicitudes acceder a una variable o cualquier tipo de datos y cambiar su valor al mismo tiempo? ¿Es la primera solicitud que se debe manejar primero y luego la segunda espera su turno?

Con las bases de datos que emplean bloqueos, sí, solo una solicitud puede acceder a una información a la vez, la solicitud que viene más tarde tuvo que esperar a que finalice la primera. Con las bases de datos que emplean MVCC, es posible manejar múltiples solicitudes al mismo tiempo, pero el conflicto de escritura se detecta y la solicitud que se realiza posteriormente se cancela. Con un contador distribuido y eventualmente coherente, son posibles múltiples escritores, pero se sacrifica una vista coherente de los datos.

  

Pregunta: ¿podría suceder solo por casualidad o el 100% del tiempo?

Ocurre todo el tiempo, no necesariamente el 100% del tiempo, pero a menudo es suficiente para que cuando una aplicación necesite escalar, tenga que tenerla en cuenta.

  

Pregunta: ¿Qué tipo de vulnerabilidad es esta? ¿Tiene una definición específica?

Cuando se maneja bien, no debería haber vulnerabilidad. Las aplicaciones deben definir el nivel de consistencia que la garantía necesita. Las aplicaciones financieras generalmente necesitan una garantía de coherencia sólida, mientras que el recuento de vistas de YouTube puede permitir una consistencia más flexible para un mayor rendimiento.