Instantáneas de políticas, activación de control de acceso y observabilidad a largo plazo (5-A / 5-B / 5-C)

Estimado usuario, este capítulo presenta tres capacidades avanzadas: instantáneas de datos antes de la ejecución de la estrategia, control de acceso al inicio antes de la apertura del mercado y conciliación y registro durante tiradas largas. Si aún no ha ejecutado correctamente la aplicación Live básica, lea primero Plataforma de negociación simulada: configuración y funcionamiento.

¿Qué problema aborda este capítulo? Las estrategias de nivel minuto que extraen datos repetidamente en cada paso son lentas y propensas a perder datos de mercado; Realizar pedidos antes de que se abra el mercado sin la configuración o los datos adecuados conlleva un riesgo significativo. Hemos configurado estas comprobaciones y las hemos registrado para facilitar su revisión.

Mapeo de nombres de códigos internos (utilizado por mantenedores/documentos de humo)

En la evolución de qteasy en vivo, 5-A / 5-B / 5-C se refieren a tres capacidades: instantáneas de políticas, control de acceso a activación y observabilidad a largo plazo, respectivamente. La documentación sobre humo y las notas del mantenedor utilizarán nombres en clave; Como usuario, sólo necesita recordar el «nombre dirigido por el usuario» a la derecha. La siguiente tabla establece la correspondencia entre los nombres en clave y el uso común; al leer el resto de este capítulo, podrá entender «5-B» como «control de acceso de activación».

Significado de cada columna: Código es el número de etapa interna; Nombre asignado por el usuario es el nombre recomendado en la documentación; Una oración indica la posición de esta capacidad en la canalización activa.

Cómo utilizar: Cuando vea códigos como 5-A en el texto principal, consulte esta tabla; consulte el nombre de la clave de configuración en Plataforma de negociación simulada: configuración y funcionamiento §4 «Instantánea de política» línea «Iniciar control de acceso».

nombre en clave

Nombre de usuario

En breve

5-A

Instantánea de la estrategia

Los datos se obtienen previamente antes de que se ejecute la estrategia y este paso reutiliza los datos para reducir las E/S redundantes.

5-B

Activar control de acceso

Antes de abrir/ejecutar, verifique el estado de preparación; si falla, se debe activar una alarma o bloqueo.

5-C

Observable a largo plazo

Mapeo de órdenes con cuenta de corretaje, rotación del registro de riesgos, conciliación y diagnóstico de órdenes en tránsito

5-A: Panorama de la estrategia

Puede pensarlo de la siguiente manera: antes de cada «examen», prepare el examen y los materiales en su escritorio; Cuando esté respondiendo las preguntas, ya no tendrá que correr a la sala de impresión.

  • Cuando live_trade_split_strategy_prepare=True, qteasy insertará una tarea prepare_strategy_snapshot antes de cada tiempo programado run_strategy (el tiempo de entrega está controlado por live_trade_prepare_lead_seconds; 0 significa poner en cola al mismo tiempo, pero el orden aún garantiza que la preparación sea la primera).

  • La función prepare_strategy_snapshot completa el trabajo pesado que se realizó antes de run_strategy: actualizar los datos de frecuencia subdiaria, preparar buffers de datos, actualizar precios en vivo e inyectar datos de proceso; una vez finalizado, deja un marcador de «instantánea válida» en la memoria (día de negociación + número de paso + hora).

  • Posteriormente, si run_strategy encuentra que la instantánea todavía está dentro de live_trade_strategy_snapshot_max_age_seconds y el número de paso es consistente, entonces la búsqueda anterior no se repetirá; de lo contrario, se registra snapshot_missing / snapshot_stale y la estrategia de este paso se omite (para evitar el uso de datos caducados para calcular señales).

  • Cuando la división está habilitada, prepare_strategy_snapshot y run_strategy se ejecutan sincrónicamente en el subproceso principal (separados de las tareas asincrónicas de fijación de precios en vivo), evitando que varios subprocesos accedan simultáneamente a Operator.

Diferencias con el comportamiento real: las instantáneas están en la memoria y deben prepararse nuevamente después de que se reinicia el proceso; no son cachés permanentes en el disco.

5-B: Iniciar el control de acceso (run_startup_gate)

Puede considerarlo como: una verificación de seguridad antes de la salida: si la estrategia está lista, si las tablas de datos necesarias están disponibles y (opcionalmente) si el libro local es consistente con el fin de la intermediación.

  • live_trade_startup_gate_mode:

    • off — Desactivar el control de acceso

    • warn: las fallas solo se registran/rastrean, pero aún se permiten transacciones (recomendado para una implementación gradual primero).

    • block: rechaza si falla. Luego, run_strategy se pone en cola (skip_reason=gate_failed).

  • Trader invocará el control de acceso después de generar el programa diario (los días no comerciales se omiten rápidamente).

  • Verifique las capas (los códigos de falla se escribirán en la traza ``failures`):

    • L1: ¿Está listo el Operator? ¿Existe la cuenta?

    • L2: Si la tabla de historial principal está en la fuente de datos (asignada a la tabla de frecuencia diaria por asset_type, etc.)

    • L3 (Opcional): Si el Broker devuelve un efectivo/posición remota no vacía, compárelo con el local; no realice una comparación estricta si la API remota no está implementada.

Para obtener una lista completa de carreteras en cuadrícula manuales con humo vivo, consulte Solución de generación de humo manual de operaciones simuladas en vivo (live_grid_multi).

5-C: Libro mayor, registros y observabilidad de recuperación

Por encima de 5-A/5-B, facilita la solución de problemas y auditoría a larga distancia (excluyendo la modificación/compensación automática de pedidos; la consulta remota QMT real es una versión posterior):

  • Pedido ↔ Asignación de ID de corredor: Tras la aceptación exitosa, se reescribirá broker_order_id / broker_name will be written back; if the order is rejected, rejected y el campo del corredor estará vacío.

  • Extensión de rotación de registros: rotate_trade_logs limpia el *.risk.log caducado además de intercambiar CSV (consulte Lista de productos y solución de problemas para conocer las reglas).

  • Conciliación y Seguimiento de Diagnóstico:

    • Los comandos pre_open y post_close generan el punto de control reconcile (por ejemplo, checkpoint_passed, checkpoint_warn).

    • Tarea DEBUG ``diagnose_pending_orders`: Comparación de solo lectura de órdenes pendientes locales y remotas.

Conclusión para principiantes: dos tipos de «rechazo de pedido»

En el proceso de orden en vivo, el «rechazo» puede ocurrir en el RiskManager mostrador de revisión (control de riesgos) o en el procesamiento del corredor (mostrador), donde las pruebas se ubican en lugares completamente diferentes. La documentación 3-risk-and-order-lifecycle ya ha explicado esto desde una perspectiva de proceso; La siguiente tabla proporciona una comparación entre la tabla de pedidos y el broker_order_id para una rápida solución de problemas.

Significados de las columnas: Ruta indica el tipo de rechazo/éxito del pedido; Tabla de pedidos locales indica si se ha agregado una nueva fila; broker_order_id indica si se requiere una reescritura; Auditoría indica el archivo o tabla que se recomienda abrir primero.

Cómo utilizar: CLI muestra un motivo de rechazo riesgoso y no hay nuevos pedidos → primera línea; la lista de pedidos muestra «rechazado» y el número del corredor está vacío → segunda línea; El número de corredor existe → tercera línea, luego verifique el estado de la transacción.

Ejemplo: risk_log contiene ``<RIESGO RECHAZADO> Además, si no hay nuevas órdenes correspondientes en la sección «órdenes», la orden será rechazada por control de riesgos. No verifique la información de conexión de la correduría.

el camino

Formulario de pedido local

broker_order_id

Auditoría

Rechazo de pedido por control de riesgos

No guardarlo

—

*.risk.log + ``<RISK REJECTED> ``

柜台受理拒单

Hay una línea, rejected

vacío

Formulario de pedido + seguimiento

Solicitud exitosa

⟦CÓDIGO0⟧ etc.

Contestar

Formulario de pedido + seguimiento

diagnostic_pending_orders campos de salida (breve)

  • local_pending_count — Recuento pendiente local

  • ``remote_pending_count`: número impar de solicitudes remotas pendientes (el simulador suele estar vacío)

  • local_pending_without_broker_order_id — Órdenes locales enviadas pero sin ID de corredor

  • local_pending_missing_remote: existe una cuenta de corretaje localmente pero no de forma remota.

  • remote_pending_not_in_local: asignado en el extremo remoto pero no en el extremo local.

CLI y DEBUG (Operaciones y Mantenimiento)

Trader Shell (–ui cli) comandos de uso común (la ayuda está en inglés):

  • gate / startup-gate: ejecute manualmente el proceso de inicio del control de puerta.

  • reconcile / snapshot-reconcile — JSON de reconciliación

  • run –task diagnose_pending_orders — Diagnosticar órdenes pendientes (requiere DEBUG)

  • artifacts / ls-artifacts — Ruta de artefactos de cuatro enlaces

  • rotatelogs / rotate-logs — Rotación manual de registros

  • broker status|connect|disconnect — Sesión de corretaje (el simulador es la bandera)

  • sync / pull-state — Reservado, la sincronización remota real aún no se ha implementado.

Recomendaciones para el próximo día de negociación

  • 5-A: ¿Hay demasiadas entradas strategy_run_skipped en el seguimiento? ¿La frecuencia del precio en vivo no es menor que la frecuencia del paso de la estrategia?

  • 5-B: Primero use warn para verificar gate_warn / gate_failed; luego use CLI gate para verificar antes de intentar block.

  • 5-C: Cerrar el mercado con reconcile y diagnose_pending_orders; si es necesario, rotatelogs –days N para verificar la limpieza de riesgos.

Documentos relacionados