Principales conclusiones
El libro mayor de Binance almacena saldos de cuentas y transacciones, al mismo tiempo que permite servicios para realizar transacciones.
Crea las condiciones necesarias para un alto rendimiento, disponibilidad 24 horas al día, 7 días a la semana y precisión de datos a nivel de bits.
El papel de Binance Ledger detrás de escena la convierte en una de las tecnologías más importantes de Binance. Aprenda exactamente cómo funciona y los problemas que resuelve en el funcionamiento del intercambio de cifrado más grande del mundo aquí.
¿Alguna vez te has preguntado exactamente qué es lo que motiva a Binance? Con la necesidad de procesar millones de transacciones diariamente a través de una base de usuarios masiva, vale la pena echar un vistazo a lo que Binance tiene bajo el capó.
La base de las operaciones técnicas de Binance es su libro mayor. El libro mayor almacena los saldos y las transacciones de las cuentas y al mismo tiempo habilita los servicios para realizar transacciones.
Binance tiene altos requisitos para el libro mayor
Como puede imaginar, los requisitos para Ledger son altos para que pueda satisfacer la demanda masiva de los usuarios. Hay tres puntos principales que deben considerarse:
Alto rendimiento con capacidad para una gran cantidad de TPS (transacciones por segundo) en horas pico.
Disponibilidad 24 horas al día, 7 días a la semana sin tiempo de inactividad.
Precisión de datos a nivel de bits, sin pérdida de fondos ni errores de transacción.
Veamos un ejemplo de una entrada básica en el Libro mayor. Aquí hay una transacción común en la que la cuenta 1 transfiere 1 BTC a la cuenta 2.
Saldo antes de la transacción:
tabla 1
Saldo después de la transacción:
Tabla 2
En esta transacción, hay dos comandos:
Cuenta 1 -1 BTC
Cuenta 2 +1 BTC
Cuando se realiza la transacción, se almacenarán dos registros de saldo para auditoría y conciliación.
Tabla 3
La solución estándar de la industria
Una solución de contabilidad estándar de la industria se basa en una base de datos relacional. Volviendo al ejemplo anterior, los dos comandos de la transacción se pueden traducir en dos declaraciones SQL y ejecutarse en una transacción de base de datos (tabla 4).
tabla-4
Las ventajas de la solución.
Es bastante sencillo de implementar.
Es fácil aplicar técnicas comunes de ajuste de bases de datos, como división de lectura/escritura y fragmentación, para mejorar el rendimiento.
No es difícil para los desarrolladores recuperarse de la conmutación por error, así como monitorear y mantener una base de datos comercial.
Las desventajas de la solución.
El TPS caerá bruscamente cuando haya condiciones de carrera debido a bloqueos de filas.
Es difícil escalar horizontalmente para mejorar el rendimiento.
El problema de las cuentas calientes
Desafortunadamente para Binance, la solución industrial demostrada anteriormente no cumple con sus altos requisitos. Cuando ocurre una transacción, debe mantener los bloqueos de fila de cada fila involucrada. Si bien algunas cuentas tienen relativamente pocas transacciones con las que lidiar, hay, por supuesto, cuentas ocupadas con muchas transacciones simultáneas. En este caso, sólo una transacción puede mantener el bloqueo de fila de la cuenta.
Las otras transacciones no pueden hacer nada más que esperar a que se libere el bloqueo. Llamamos a esta situación un problema de cuenta importante y las pruebas internas muestran que el TPS disminuirá al menos 10 veces en esta situación. Puede ver este problema en la tabla 5 a continuación.
Ejemplo de cuenta activa:
tabla-5
La solución de libro mayor de Binance
¿Cómo solucionamos el problema de las cuentas activas?
Una posible solución a nuestro problema es convertir de forma innovadora el modelo de subprocesos múltiples a un modo de subproceso único. Esto evita el problema de la condición de carrera y, como resultado, no habrá un problema de cuenta importante.
Nuevo modelo de hilo
Comunicación basada en mensajes
Después de implementar nuestro nuevo modelo de subprocesos, es necesario resolver un problema de comunicación. La capa de la máquina de estado es de un solo subproceso, pero la capa de red es de múltiples subprocesos, entonces, ¿cómo nos comunicamos de manera eficiente entre los dos?
Un Disruptor [1] es el siguiente paso del rompecabezas. Crea una cola de alto rendimiento y sin bloqueos basada en un diseño de búfer en anillo.
Alta disponibilidad
Hasta ahora, hemos logrado un alto rendimiento utilizando un modelo en memoria y almacenamiento local RocksDB [2]. Pero, una vez más, surge un nuevo desafío. Ahora debemos ocuparnos de la alta disponibilidad de datos.
Para garantizar la coherencia de los datos entre los nodos, utilizamos un algoritmo de consenso Raft [3]. Esto significa que la cantidad de copias de seguridad de datos es igual a la cantidad de nodos no líderes presentes. El algoritmo también garantiza que el sistema seguirá funcionando con al menos la mitad de los nodos en buen estado, para ayudar a proporcionar una alta disponibilidad del servicio.
Funciones del dominio de balsa:
Líder. Leader procesa todas las solicitudes de los clientes y replica la operación a todos los seguidores.
Seguidor. Los seguidores siguen al líder en todas las operaciones. Si el líder fracasa, uno de los seguidores será elegido nuevo líder.
Aprendiz. Los estudiantes son seguidores sin derecho a voto que envían cada registro de cambio de transacción/idempotente a otros servicios.
Roles de dominio de balsa
CQRS (Segregación de responsabilidad de consulta de comando)
Otro criterio clave que queremos garantizar es el mayor rendimiento de escritura del Ledger y su capacidad para condiciones de consulta más diversas. Para ello, necesitamos crear diferentes dominios. El dominio raft proporciona una escritura más eficiente basada en rocksdb + raft, y el dominio de vista escucha los mensajes del dominio raft y los guarda en la base de datos relacional para consultas externas. También podemos implementar la segregación de responsabilidades de consultas de comandos a nivel arquitectónico.
Arquitectura de libro mayor
Arquitectura general
Términos entre Raft y Ledger:
tabla-6
Ver roles de dominio
Centro de contabilidad de balsa
Consuma el mensaje producido por el alumno y almacene los datos de transacciones y saldos en MySQL para realizar consultas.
Procesamiento de solicitudes
Una solicitud de transacción pasará primero por la capa de red, la capa de libro mayor (controlador de solicitudes) y la capa de balsa (sincronización de registros de balsa). Luego volverá a la capa del libro mayor (máquina de estado), a la capa de red (controlador de respuestas) y finalmente devolverá una respuesta al cliente.
Los datos se pasan a través de la cola entre las dos capas.
Capa de red: deserialice la solicitud rpc y colóquela en la cola de solicitudes.
Capa de libro mayor: obtenga la solicitud de la cola y prepare el contexto. Luego colocará los metadatos de la solicitud en la cola de balsa.
Capa de balsa: obtenga los metadatos de la solicitud de la cola de balsa y sincronícelos entre todos los seguidores. Luego pondrá el resultado en la cola de aplicación.
Capa de libro mayor: obtenga los datos de la cola de aplicación y actualice la máquina de estado. Luego pondrá el resultado en la cola de respuestas.
Capa de red: obtenga el resultado de la cola de respuestas y construya y serialice los datos de respuesta antes de devolverlos al cliente.
Procesamiento de solicitudes
Recuperación de datos
Cada nodo de Ledger activará una instantánea genérica basada en un período de tiempo. Además, también implementamos una instantánea consistente. Cada nodo se activa en el mismo índice de registro de balsa para garantizar que la máquina de estado sea exactamente la misma cuando cada nodo activa una instantánea. Luego, la instantánea se cargará en S3 para que Checker la verifique y como copia de seguridad en frío.
Cuando Ledger se reinicia, lee la instantánea local y reconstruye la máquina de estado. Luego reproduce el registro de la balsa local y sincroniza el último registro del líder hasta que alcanza el último índice. Si la instantánea local o el registro de la balsa no existe, se obtendrá del líder.
Instantánea y recuperación
Tolerancia a los desastres
Para mejorar la disponibilidad y la tolerancia a fallos, los nodos Ledger se implementan en diferentes zonas. Siempre que más de la mitad de los nodos estén en buen estado, los datos no se perderán y la conmutación por error se completará en un segundo.
Incluso si todo el clúster falla, lo cual existe una probabilidad muy baja, aún podemos restaurar el clúster a través de la instantánea consistente almacenada en Amazon S3 y recuperar los datos perdidos más recientes a través del sistema descendente.
Tolerancia a fallos
Actuación
La siguiente tabla muestra las especificaciones de hardware para la prueba de rendimiento.
Las pruebas internas demuestran que un clúster de 4 nodos (un líder, dos seguidores y un alumno) puede procesar más de 10.000 TPS. Por diseño, el clúster procesa todas las transacciones una por una. No existe ninguna condición de bloqueo ni de carrera. Entonces, en el escenario de cuenta activa, el TPS es tan alto como en los escenarios normales.
Cuenta caliente TPS
La siguiente figura muestra la latencia de cada transacción. La mayoría de las transacciones podrían finalizarse en 10 ms. Las transacciones más lentas podrían finalizarse en 25 ms.
Latencia ms
Impulsando nuestros servicios con Binance Ledger
Como ha visto, la respuesta de la industria tradicional al problema de las cuentas calientes no satisface las necesidades de Binance y sus clientes. Al utilizar un enfoque diseñado específicamente para la infraestructura de Binance, terminamos con una de las experiencias de intercambio y productos más fluidas disponibles. Estamos felices de compartir con usted nuestra experiencia y esperamos que comprenda mejor lo que implica hacer que un servicio como Binance funcione.
Lea el siguiente artículo para obtener más información sobre nuestra infraestructura tecnológica:
(Blog de Binance) Uso de MLOps para crear un canal de aprendizaje automático de extremo a extremo en tiempo real
(Blog de Binance) Conozca al CTO: Rohit reflexiona sobre Crypto, Blockchain, Web3 y su primer mes en Binance
Referencias
[1] Disruptor LMAX
[2] RocasDB
[3] El algoritmo de consenso de la balsa
