Redistribución del tráfico
1) Qué es la redistribución y por qué es necesaria
La redistribución del tráfico es un cambio controlado de rutas/proveedores/colas para partes de carga (hilos, claves de causalidad, clases QoS) en congestiones, incidentes, shocks de precios o cambios en los estados de cumplimiento. Objetivos:- sostener SLO (p95/p99, tasa de éxito) en ráfagas;
- reducir la amplificación de la etiqueta y el tiempo de finalización;
- minimizar el costo al servicio sin perder calidad y orden;
- proporcionar un comportamiento cerrado a los riesgos y las irregularidades.
2) Objetos, roles y clases QoS
Objetos de redistribución: rutas, bridges, secuenciadores, grupos DA, POP/edge, clústeres GPU/CPU, colas de servicio.
Роли: Operator/Router, Provider (узел/бридж/DA/GPU), Compliance Gate, Orchestrator, Auditor/Regulator, Treasury/治理.
- Q4 son comandos de dedo (críticos con el orden/final).
- Q3 - hilos ordenados (llave de la causalidad).
- Q2 - exactly-once eficientemente (snapshots/facturación).
- Q1/Q0 - telemetría/analítica/best-efort.
3) Cuándo iniciar la redistribución (detalle)
Desencadenadores (cualquiera de las condiciones):- p95/p99 por encima del corredor, TailAmplification = p99/p50 crece.
- Queue depth o consumer lag superan los umbrales.
- Los errores finalistas/puente crecen, el reorg/orphan está por encima de lo normal.
- El costo/Req en la ruta va más allá del presupuesto.
- Compliance event: geo/edad/sanción → bloque/restricción.
- Degradation signals: SLA-брейки, flap-rate, error-budget burn.
4) Decisión sobre la nueva ruta (función utility)
La ruta/proveedor se selecciona a un «costo» mínimo esperado, respetando los invariantes:
Utility(route) =
wL·Latency_p95_EWMA
+ wJ·Jitter
+ wQ·QueueDepth
+ wC·Cost_per_unit (gas + DA + egress + compute)
+ wF·FinalityTime
+ wR·RiskScore
+ wA·AvailabilityPenalty
+ wG·Geo/CompliancePenalty
Los perfiles de escala dependen de la clase QoS: para Q4 ↑wL, ↑wF, ↑wR; para Q1 ↑wC, ↓wF.
Invariantes duros: 'Order (true) ∧ Idempotency (true) ∧ Quotas (true) ∧ Compliance (true)'.
5) Algoritmos y mecánica de redistribución
Consistent hashing per key → minimiza las permutaciones;
Hot-Shard Relief es una subagmentación temporal de claves «hot».
Percentile-aware routing - soluciones p95/p99, no p50.
EDF/LLF для Q4 (Earliest Deadline / Least Laxity First).
Weighted Fair Queuing/DRR es una participación justa en las colas totales.
Leaky/Token buckets - cuotas por clase/ruta/proveedor.
Circuit breakers — trip → reroute; muestras de recuperación half-open.
Adaptive retries - Retras limitadas con jitter y deadline.
Spillover tiers - downshift: los Q0/Q1 se van a batch/edge, liberando el carril de Q3/Q4.
6) Orden, idempotencia, finalidad
Strict order per key (Q3/Q4) en la ruta seleccionada; cuando failover es «stop barrera» + replay desde outbox/inbox, luego «descongelar».
Idempotency key + seen table (TTL) - dedoup cuando se vuelve a entregar.
X-chain finality: tenemos en cuenta la ventana 'FinalityTime '/challenge; las operaciones críticas reciben un recorrido con una mínima finalidad total.
7) Economía redistributiva
Recargos de Surge: cuando las colas/colas de ↑ wC crecen en rutas congestionadas.
Factor de calidad (QF) del proveedor afecta el volumen y el pago.
Límites de budget: topes de costo diario/hora y egresos.
Treasury hooks: dominios de calidad sostenible obtienen ↓take - rate/↑obyem.
8) Cumplimiento y geo-reglas
Fail-cerrado: duda sobre el estado → bloque, quórum manual.
ZK-pases: dock-wa edad/geo sin la apertura del PDn.
Política de exportación/retención: DA/egresos por región, retenciones fiscales en el camino de los pagos.
Geo-evasion guard: firmas de elusión → cuarentena + auditoría.
9) Observabilidad y alerting
Trace: 'x _ msg _ id', 'route _ id', 'provider _ id', bridge/DA stage, finality.
Métricas: p50/p95/p99, retry%, timeout%, duplicate/out-of-order%, queue depth, finality lag, cost/req, surge index.
Дашборды: Reroute Live, Tail Heatmap, Queue/Finality Monitor, Cost-per-Route, Fairness Panel.
Alertas: error-budget burn, flap-rate, DLQ depth, bloques de cumplimiento.
10) Incidentes (RCA) y protocolo de degradación
1. Detect (ver § 3) → aislamiento de la ruta (trip), redistribución de las acciones.
2. Suavizar: downshift Q0/Q1, reforzar la prioridad de Q4/Q3, cortar los límites a los flujos «ruidosos».
3. Compensación: de la piscina de seguros (S-fianza, reglas RNFT).
4. Post-mortem: causas, ajuste de pesos/límites, actualización de firmas, rehearsal.
11) Fórmulas y puntos de referencia
SuccessRate = 1 − (timeouts + errors)/requests
TailAmplification = p99/p50 (objetivo: ↓, corredores por QoS)
Headroom = (cap − current)/cap
Costo/Req = Σ (recurso × tasa )/solicitudes exitosas _
FairnessIndex (Jain) = (Σ x) ²/( n· Σ x ²) por cuota/recurso
QualityFactor del proveedor: (QF = f (\text {success}, p95, DLQ, finality))
Puntos de referencia de SLO (ejemplo):- Q4: success ≥ 99. 99%, p95 ≤ 200 ms, DLQ = 0, MTTR ≤ 15 min.
- Q3: violación del orden ≤ 10⁻⁶/soobshch., p95 ≤ 500 ms.
- DA/Bridge: finality ≤ 3 × T _ block, falsas confirmaciones = 0.
12) 治理: normas para la modificación de las ponderaciones/cuotas/precios
Proposales para sustituir (w), contingentes, aranceles y bonos QF.
R-modificador de voces para roles de calidad (pasillo [0. 8..1. 2]).
Sunset-editar: cambios temporales con auto-apagado.
Informes públicos: métricas de redistribución trimestrales y auditoría fairness.
13) Playbook de implementación (por pasos)
1. Mapeo de hilos y llaves de causalidad (por QoS/región/cumplimiento).
2. Telemetría y muestras: OWD/RTT/jitter/queue/finality/cost (EWMA + p95/p99).
3. Políticas de utilidad: perfiles de ponderación por QoS, presupuestos de costos, corredores de surge.
4. Cuotas y sombreadores: token baquetas per ruta/proveedor/clase.
5. Garantías de envío: outbox/inbox, idempotencia, barreras ordinales.
6. Fairness & backpressure: WFQ/DRR, anti-noise, spillover tiers.
7. Observabilidad: dashboards, alertas, presupuesto de error, DLQ/Replay.
8. Juegos-días/chaos: caída de dominio/puente/DA, choque de precios, geo-bloque.
9. 治理: procedimientos para cambiar los pesos/límites/precios (proposales, sunset).
10. Piloto → escala: perfiles A/B, retrocalibración, informe público.
14) KPI del programa de redistribución
Entrega: éxito por clases QoS, DLQ = 0 (Q3/Q4), duplicate/out-of-order ↓.
Latencia: p95/p99 y TailAmplificación en los corredores de destino.
Sostenibilidad: MTTR mediana ≤ objetivo, flap-rate ↓.
Economía: Costo/Req ↓ mientras se conserva el SLO; aumento de la proporción de rutas «baratas».
Justicia: Jain en el pasillo; reducción de los incidentes de «noisy neighbor».
Finalidad/seguridad: finality lag ↓, 0 confirmaciones falsas.
Cumplimiento: 100% pasar geo/age/sanciones, cero infracciones.
15) Lista de comprobación de disponibilidad
- QoS, SLO/SLA, claves de causalidad y presupuestos de errores definidos
- Se implementaron políticas de utilidad, cuotas y token bakets per route/provider
- Incluido consistent hashing, hot-shard relief, EDF/LLF (Q4)
- Outbox/inbox, idempotencia y barreras de orden personalizados
- WFQ/DRR, backpressure y spillover tiers funcionan
- Los dashboards latency/tail/queue/finality/cost y alertas están disponibles
- Circuit breakers, DLQ/Replay y compensación (S-escrow) incluidos
- Juegos-días/chaos realizados y post-mortems formalizados
- Conectado a Compliance Gate y retenciones fiscales en los pagos
- Utverzhden治理 - proceso de cambio de pesos/límites/precios (sunset)
16) Glosario
Redistribución de tráfico: reroute administrado/reasignación de colas/proveedores.
Amplificación de la cola: p99/p50 - La fuerza de la «cola» de los retrasos.
FinalityTime: tiempo antes de que el evento sea irreversible.
Utility-routing: seleccione una ruta de acceso por utilidad agregada.
WFQ/DRR: una disciplina justa de mantenimiento de colas.
Spillover tiers: rebajar las clases «blandas» en batch/edge en caso de sobrecarga.
Circuito breaker: desconexión automática de la ruta degradada.
17) Resultado
La redistribución del tráfico es un circuito operativo de sostenibilidad: medimos → resolvemos → redireccionamos sin alterar el orden, la finalidad y las reglas. La combinación de enrutamiento de utilidades, fairness/cuotas, estrictas garantías de entrega i治理 -el control convierte el ecosistema multi-in en un sistema adaptativo capaz de soportar picos de demanda, incidentes y shocks de precios - de forma rápida, honesta y económica.