Sistemas Distribuidos · Entrega 2 · Defensa
Asteria Online
Un MMORPG que corre en tres datacenters, donde nada se cobra dos veces.
Decoud
El mundo y sus reglas
Reparto a confirmar
Ritondale
Misiones 1 a 3
Reparto a confirmar
Santisi
Misiones 4 a 7
Reparto a confirmar
La pregunta del TP
Siete veces la misma pregunta: cuando algo falla, ¿quién pierde oro?
La respuesta que defendemos: nadie pierde oro ni objetos, nada se cobra dos veces y el juego sigue.
Arquitectura general
Siete componentes repartidos en tres datacenters
El gateway · Autenticación
Se inicia sesión una vez; después habla el token
Los cuatro mecanismos que usamos en todo el TP
Cuatro reglas del mundo responden casi todas las fallas
Id de operación
Lo mismo dos veces cuenta una vez
Cada acción con oro u objetos lleva un número único del cliente. Si llega repetida, el servidor devuelve el resultado de la primera vez.
Reserva y confirmación
Primero se aparta, después se cobra
El oro se reserva y se descuenta cuando el otro componente confirma; sin confirmación en 30 s, se libera. Si ya se cobró y algo falla: vuelve el oro más un 10 %.
Buzón de avisos
Lo que se acredita, queda escrito
Premios y devoluciones quedan en el buzón del jugador. Si estaba desconectado, se entera al volver a entrar.
Réplica en espera
Cada batalla tiene un doble
Una copia en otro datacenter recibe, cada 500 ms, sólo los golpes aplicados: unos 2,5 KB. Si el datacenter cae, la copia sigue desde ahí.
Cómo se comunican: todo por gRPC
Cada código de gRPC le dice al cliente qué hacer
Reintenta con el mismo id
No reintenta: muestra el motivo
Otro camino
gRPC tiene sus propios códigos. Usamos siete, y cuando algo se rechaza va también el motivo: "no tenés oro suficiente".
OKSalió bien.
FAILED_PRECONDITIONUna regla lo impide: sin oro, cerrada.
RESOURCE_EXHAUSTEDNo hay lugar: está lleno.
ABORTEDOtro llegó primero: ya vendido.
UNAUTHENTICATEDToken vencido: iniciar sesión.
UNAVAILABLENo disponible. Seguro no se hizo.
DEADLINE_EXCEEDEDNo contestó. No se sabe si se hizo.
Siempre puede consultar
Operaciones/ConsultarOperaciones/ListarRecientesBuzon/Leer · Operaciones/Cancelar
Otro datacenter: el gateway no reenvía pedidos; hace sólo la llamada interna que hace falta.
Mapa de interacciones
Dieciséis interacciones forman el contrato
Entrada1Cliente → Gateway · gRPC
2Cliente ↔ Servidor · stream
3Balanceador → Gateways · red
4Gateway → otro DC · gRPC
2Cliente ↔ Servidor · stream
3Balanceador → Gateways · red
4Gateway → otro DC · gRPC
El gateway reparte5→ Cuentas
6→ Servidor de instancia
7→ Directorio (copia local)
8→ Pagos
9→ Control de cupos · todo gRPC
6→ Servidor de instancia
7→ Directorio (copia local)
8→ Pagos
9→ Control de cupos · todo gRPC
La batalla10Servidor → Réplica
11Servidor → Cuentas
12Servidor → Directorio · gRPC
11Servidor → Cuentas
12Servidor → Directorio · gRPC
Entre copias13Directorio ↔ Directorio · replicación eventual
14Cuentas ↔ Cuentas · Raft
14Cuentas ↔ Cuentas · Raft
El dinero15Pagos → Cuentas · gRPC
16Pagos → Procesador · HTTPS (no gRPC)
16Pagos → Procesador · HTTPS (no gRPC)
Problema 1 · Interacciones
El oro se reserva antes de pedir lugar y se cobra después del sí
Nueva misiónMisión 1 de 7
Problema 1 · Entrar a una instancia de zona
Si pagó, entra. Si no entra, no paga.
SoluciónSe reserva el oro, la instancia confirma que hay lugar y recién ahí se cobra.
Id de operaciónReserva y confirmaciónBuzón
→ aceptar la misión
Problema 1 · Falla F1.3
Si el servidor no confirma en 30 s, el oro vuelve
Misión cumplidaFallas y trade-offs · Problema 1
Lo que se paga: segundos de duda y el 10 % de compensación
FallaQué hace el sistemaQué se gana y qué se pierde
F1.1clientePierde señal después de pedir entrar.Al volver, el cliente consulta la operación por su id y le muestra si entró o no.Gananunca queda pagado sin entrar.Pierdeunos segundos sin saber qué pasó.
F1.2clienteLa app reenvía el pedido.Llega con el mismo id: el servidor no cobra de nuevo.Ganase cobra una sola vez.Pierdehay que guardar el resultado de cada operación.
F1.3infraSe cae el datacenter de la instancia.Si todavía no confirmó, la reserva vence y el oro vuelve. Si ya confirmó, sigue la réplica (Problema 2). Si tampoco puede, se devuelve el oro más el 10 %.Ganael jugador entra o recupera su oro.Pierdeel costo de la compensación.
Problema 2 · Interacciones
Un stream por jugador; el servidor ordena los golpes y replica cada 500 ms
Nueva misiónMisión 2 de 7
Problema 2 · Batalla contra el jefe
El servidor manda en la batalla: cada golpe cuenta una vez
SoluciónEl servidor ordena los golpes, replica cada 500 ms y reparte al buzón.
Id de operaciónRéplica en esperaBuzón
→ aceptar la misión
Problema 2 · Fallas F2.3, F2.6 y F2.4
El servidor decide cada golpe; si cae, la réplica sigue
Misión cumplidaFallas y trade-offs · Problema 2
Siete fallas, una sola versión de la batalla
FallaQué hace el sistemaQué se gana y qué se pierde
F2.1clienteSe le corta la señal varias veces.Al volver, toma el estado que manda el servidor. Los golpes que llegan cuentan si el jefe sigue vivo.Ganave la batalla real.Pierdelos golpes que no llegaron durante el corte.
F2.2clienteTiene mucho lag.Su pantalla muestra el daño y se corrige con el estado siguiente. El tiempo se calcula con la hora de fin del servidor.Ganael lag no cambia qué golpes cuentan.Pierdepuede ver su daño corregido.
F2.3clienteLa app reenvía un golpe.Tiene un número de orden ya procesado: se ignora.Ganacada golpe cuenta una vez.
F2.4clienteEl teléfono le cierra la app durante el reparto.El reparto lo hace el servidor; su parte queda en el buzón.Ganacobra igual.Pierdese entera después.
F2.5clienteCambia de red (wifi a datos).La sesión va por el token, no por la conexión: se reconecta y lee el buzón.Ganacobra y se entera.
F2.6infraSe cae el datacenter de la batalla.La réplica nota que no llegan más datos y sigue la batalla. El reparto se reintenta con el mismo id: no se paga dos veces.Ganala batalla sigue.Pierdehasta 500 ms de combate.
F2.7infraParte de los jugadores no llega al datacenter de la batalla.Entran por otro datacenter, que les pasa el tráfico. Si ni así llegan, la batalla sigue sin ellos y conservan su daño.Ganauna sola versión de la batalla CPPierdelos jugadores aislados no pueden jugar.
Problema 3 · Interacciones
Una sola llamada decide al dueño, con el acuerdo de dos de tres
Nueva misiónMisión 3 de 7
Problema 3 · Mercado de objetos
Un objeto único tiene un solo dueño, siempre
SoluciónCambiar de dueño necesita dos de tres datacenters: gana el primero.
Id de operaciónReserva y confirmaciónCuentas con Raft
→ aceptar la misión
Problema 3 · Compra simultánea y falla F3.3
Gana el primero, el otro no paga, y el lado aislado no vende
Misión cumplidaFallas y trade-offs · Problema 3
Nunca dos dueños, aunque un lado no pueda comprar un rato
FallaQué hace el sistemaQué se gana y qué se pierde
F3.1clientePierde señal después de comprar.Al volver, consulta la compra por su id. Si la reenvía, no se compra dos veces.Ganacompra una sola vez y sabe cómo terminó.
F3.2clienteVe el mercado desactualizado.La compra se valida contra el servidor, no contra lo que ve el jugador. Si ya se vendió, se le libera la reserva (no pagó nada, así que no hay compensación).Ganaun solo dueño.Pierdepuede intentar comprar algo que ya no está.
F3.3infraSe cortan los datacenters entre sí.Del lado que quedó solo no se puede comprar: se le libera la reserva y se le avisa que reintente.Gananunca hay dos dueños CPPierdeno se puede comprar desde ese lado mientras dure el corte.
Problema 4 · Interacciones
La compra queda anotada antes de cobrar, con el id como clave
Nueva misiónMisión 4 de 7
Problema 4 · Compra de oro con dinero real
Si le cobraron, recibe el oro; nunca se cobra dos veces
SoluciónEl id de la compra es la clave del cobro; una conciliación diaria revisa todo.
Id de operaciónBuzónConciliación diaria
→ aceptar la misión
Problema 4 · Fallas F4.3 y F4.2
El mismo id viaja hasta el procesador: un solo cobro, aunque caiga el DC
Misión cumplidaFallas y trade-offs · Problema 4
En el peor caso el oro tarda un día; nunca se cobra dos veces
FallaQué hace el sistemaQué se gana y qué se pierde
F4.1clientePierde señal después de pagar.La compra sigue en el servidor. Al volver, ve el oro en el buzón.Ganasi pagó, tiene el oro.Pierdeno lo ve hasta volver.
F4.2clienteLa app reenvía la compra.Va con el mismo id: ni el juego ni el procesador cobran de nuevo.Ganaun solo cobro.
F4.3infraSe cae el datacenter durante el cobro.La compra quedó anotada como pendiente. Otro datacenter le pregunta al procesador si se cobró y entrega el oro. Si se escapa algo, lo encuentra el control diario.Ganasi pagó, tiene el oro en menos de 24 h.Pierdeen el peor caso, espera un día.
Problema 5 · Interacciones
Sesión, cola y latido: tres llamadas sostienen el lugar
Nueva misiónMisión 5 de 7
Problema 5 · Pico de jugadores nuevos
Quien ya juega no pierde su lugar por los que llegan
SoluciónA nadie que juega se lo echa; si pierde señal, su lugar se guarda 2 minutos. Los nuevos, en cola.
Lease de 2 minutosColaToken de sesión
→ aceptar la misión
Problema 5 · Falla F5.1
Un corte de menos de 2 minutos no le hace perder el lugar
Misión cumplidaFallas y trade-offs · Problema 5
El lugar vacío durante el corte lo pagan los que esperan
FallaQué hace el sistemaQué se gana y qué se pierde
F5.1clienteUn jugador que estaba jugando pierde señal un rato durante el pico.Su lugar sigue reservado. Si vuelve antes de los 2 minutos, entra directo sin hacer cola.Ganano pierde el lugar por un corte corto.Pierdeese lugar queda vacío mientras tanto y los nuevos esperan más.
¿Por qué 2 minutos? Es lo que fija la garantía: alcanza para un corte de señal común y no deja un lugar trabado para siempre.
Problema 6 · Interacciones
La lista sale de la copia local; la entrada se valida en la instancia
Nueva misiónMisión 6 de 7
Problema 6 · Directorio de zonas
El jugador entra a la que eligió, o a ninguna
SoluciónLa lista sólo sirve para elegir; la entrada se valida antes de cobrar.
Replicación eventualReserva y confirmaciónId de operación
→ aceptar la misión
Problema 6 · Fallas F6.1 y F6.3
La lista sirve para elegir; la decisión se toma al entrar
Misión cumplidaFallas y trade-offs · Problema 6
La lista siempre responde, aunque a veces muestre lo que ya no está
FallaQué hace el sistemaQué se gana y qué se pierde
F6.1clienteLa app no recibe las actualizaciones de la lista.Si eligió una instancia que ya se llenó, se rechaza antes de cobrar y la app actualiza la lista.Ganase entera antes de pagar.Pierdeun intento de más.
F6.2clientePierde señal después de tocar "entrar".El reintento va con el mismo id y la misma instancia.Ganaentra a la que eligió, no a otra.
F6.3infraUn datacenter tiene la lista atrasada.Sigue mostrándola, y la validación al entrar evita que pague por una instancia que no está.Ganala lista siempre responde rápido APPierdea veces muestra instancias que ya no están.
Problema 7 · Interacciones
Leer es local; cambiar el oro pasa por el líder y dos de tres
Nueva misiónMisión 7 de 7
Problema 7 · Cuenta del jugador entre datacenters
El mismo oro en cualquier datacenter, gastado una vez
SoluciónLa cuenta está en los tres datacenters con Raft: vale lo que aceptan dos.
RaftBalanceador globalToken de sesión
→ aceptar la misión
Problema 7 · Fallas F7.1, F7.3 y F7.2
Un cambio de oro vale cuando lo aceptan dos de tres
Misión cumplidaFallas y trade-offs · Problema 7
Del lado aislado se ve el saldo, pero no se gasta
FallaQué hace el sistemaQué se gana y qué se pierde
F7.1infraSe cortan dos datacenters entre sí.El lado con dos datacenters sigue normal. El que quedó solo puede mostrar el saldo pero no gastar.Ganano hay gasto doble CPPierdedesde ese lado no se puede gastar.
F7.2infraUn datacenter vuelve de una caída con datos viejos.No atiende hasta ponerse al día con los otros.Gananadie gasta con un saldo viejo.Pierdetarda en volver.
F7.3infraSe cae el datacenter del jugador.Lo mandan al más cercano; quedan dos datacenters, que alcanzan para seguir.Ganasigue jugando con su cuenta al día.Pierdemás lag.
F7.4infraSu datacenter anda lento.Si tarda más de 300 ms durante 30 s, el balanceador lo saca de rotación; vuelve tras 1 minuto sano.Ganajuega desde uno que anda bien.
CAP: la decisión que atraviesa el TP
Donde hay oro, consistencia. En la lista, disponibilidad.
CP
Mejor decir "no" que equivocarse
- Batalla (Problema 2): una sola versión del combate.
- Mercado (Problema 3): un solo dueño por objeto.
- Cuenta (Problema 7): el mismo oro no se gasta dos veces.
AP
Responder siempre, aunque esté atrasada
- Directorio (Problema 6): si la lista se atrasa, la entrada lo corrige.
DóndeElegidaDescartadaPor qué
P3 · mercado (F3.3)Acuerdo de dos de tresComprar igual y arreglar los choques despuésB puede dejar dos dueños del mismo objeto
P6 · directorioCopia local y validar al entrarPreguntarles a dos datacenters cada vezMisma garantía, más rápida, y la lista sigue si se cortan
P7 · cuentaRaft: dos de tresCada datacenter acepta gastos y se arregla despuésEs oro: B permite gastar dos veces
Definición ajustada · Instancia/SolicitarIngreso
Lo que cambiamos del ejemplo de la revisión
El ejemplo decíaAhora
El cliente manda su PlayerId→Sale del token: nadie pide por otro
Responde 200, 400 o 503→Códigos de gRPC, con el motivo
Un solo 400 para todo→Sin oro, cerrada, llena, ya en otra batalla
503 es no disponible o timeout→UNAVAILABLE no se hizo · DEADLINE_EXCEEDED no se sabe
"200: ingreso aceptado"→OK con battleId y ticket para la batalla
Instancia/ConsultarIngreso→Operaciones/Consultar y ListarRecientes
¿Y si llega al DC equivocado?→Sólo Instancia/Admitir a ese DC
¿Preguntas?
Casi todo se responde con cuatro reglas: lleva un id, se reserva y se confirma, queda en el buzón, está copiado en otro datacenter.
30 s
vence una reserva sin confirmar
Problema 1
10 %
compensación si cobramos y fallamos
Problemas 1 y 2
100 ms
cambios de la batalla a cada jugador
Problema 2
500 ms
sólo cambios a la réplica: lo máximo que se pierde
Problema 2
2 min
lugar guardado sin señal (lease)
Problema 5
30 s
cada latido que renueva el lugar
Problema 5
300 ms
30 s más lento: el DC sale de rotación
Problema 7
24 h
lo máximo que tarda el oro comprado
Problema 4
Decoud
El mundo y sus reglas · cierre
Ritondale
Misiones 1 a 3
Santisi
Misiones 4 a 7