Sistemas Distribuidos
Reading time: 5 min
The Graph es un protocolo implementado como un sistema distribuido.
Las conexiones fallan. Las solicitudes llegan fuera de orden. Diferentes computadoras con relojes y estados desincronizados procesan solicitudes relacionadas. Los servidores se reinician. Las reorganizaciones se producen entre las solicitudes. Estos problemas son inherentes a todos los sistemas distribuidos, pero se agravan en los sistemas que funcionan a escala mundial.
Considera este ejemplo de lo que puede ocurrir si un cliente pregunta a un Indexador por los últimos datos durante una reorganización.
- El indexador ingiere el bloque 8
- Solicitud servida al cliente para el bloque 8
- El indexador ingiere el bloque 9
- El indexador ingiere el bloque 10A
- Solicitud servida al cliente para el bloque 10A
- El indexador detecta la reorganización a 10B y revierte 10A
- Solicitud servida al cliente para el bloque 9
- El indexador ingiere el bloque 10B
- El indexador ingiere el bloque 11
- Solicitud servida al cliente para el bloque 11
Desde el punto de vista del indexador, las cosas avanzan lógicamente. El tiempo avanza, aunque tuvimos que revertir un bloque uncle y jugar el bloque bajo consenso hacia adelante encima de él. En el camino, el Indexador sirve las peticiones utilizando el último estado que conoce en ese momento.
Sin embargo, desde el punto de vista del cliente, las cosas parecen caóticas. El cliente observa que las respuestas fueron para los bloques 8, 10, 9 y 11 en ese orden. Lo llamamos el problema del "block wobble" (bamboleo del bloque). Cuando un cliente experimenta un bamboleo de bloques, los datos pueden parecer contradecirse a lo largo del tiempo. La situación se agrava si tenemos en cuenta que no todos los indexadores ingieren los últimos bloques de forma simultánea, y tus peticiones pueden ser dirigidas a varios indexadores.
Es responsabilidad del cliente y del servidor trabajar juntos para proporcionar datos coherentes al usuario. Hay que utilizar diferentes enfoques en función de la consistencia deseada, ya que no existe un programa adecuado para todos los problemas.
Razonar las implicaciones de los sistemas distribuidos es difícil, pero la solución puede no serlo! Hemos establecido APIs y patrones para ayudarte a navegar por algunos casos de uso comunes. Los siguientes ejemplos ilustran estos patrones pero eluden los detalles requeridos por el código de producción (como el manejo de errores y la cancelación) para no ofuscar las ideas principales.
The Graph proporciona la API block: { number_gte: $minBlock }
, que asegura que la respuesta es para un solo bloque igual o superior a $minBlock
. Si la petición se realiza a una instancia de graph-node
y el bloque mínimo no está aún sincronizado, graph-node
devolverá un error. Si graph-node
ha sincronizado el bloque mínimo, ejecutará la respuesta para el último bloque. Si la solicitud se hace a un Edge & Node Gateway, el Gateway filtrará los Indexadores que aún no hayan sincronizado el bloque mínimo y hará la solicitud para el último bloque que el Indexador haya sincronizado.
Podemos utilizar number_gte
para asegurarnos de que el tiempo nunca viaja hacia atrás cuando se realizan sondeos de datos en un loop. Aquí hay un ejemplo:
/// Updates the protocol.paused variable to the latest/// known value in a loop by fetching it using The Graph.async function updateProtocolPaused() {// It's ok to start with minBlock at 0. The query will be served// using the latest block available. Setting minBlock to 0 is the// same as leaving out that argument.let minBlock = 0for (;;) {// Schedule a promise that will be ready once// the next Ethereum block will likely be available.const nextBlock = new Promise((f) => {setTimeout(f, 14000)})const query = `query GetProtocol($minBlock: Int!) {protocol(block: { number_gte: $minBlock } id: "0") {paused}_meta {block {number}}}`const variables = { minBlock }const response = await graphql(query, variables)minBlock = response._meta.block.number// TODO: Do something with the response data here instead of logging it.console.log(response.protocol.paused)// Sleep to wait for the next blockawait nextBlock}}
Otro caso de uso es la recuperación de un conjunto grande o, más generalmente, la recuperación de elementos relacionados a través de múltiples solicitudes. A diferencia del caso del sondeo (en el que la consistencia deseada era avanzar en el tiempo), la consistencia deseada es para un único punto en el tiempo.
Aquí utilizaremos el argumento block: { hash: $blockHash }
para anclar todos nuestros resultados al mismo bloque.
// Gets a list of domain names from a single block using paginationasync function getDomainNames() {// Set a cap on the maximum number of items to pull.let pages = 5const perPage = 1000// The first query will get the first page of results and also get the block// hash so that the remainder of the queries are consistent with the first.const listDomainsQuery = `query ListDomains($perPage: Int!) {domains(first: $perPage) {nameid}_meta {block {hash}}}`let data = await graphql(listDomainsQuery, { perPage })let result = data.domains.map((d) => d.name)let blockHash = data._meta.block.hashlet query// Continue fetching additional pages until either we run into the limit of// 5 pages total (specified above) or we know we have reached the last page// because the page has fewer entities than a full page.while (data.domains.length == perPage && --pages) {let lastID = data.domains[data.domains.length - 1].idquery = `query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {nameid}}`data = await graphql(query, { perPage, lastID, blockHash })// Accumulate domain names into the resultfor (domain of data.domains) {result.push(domain.name)}}return result}
Ten en cuenta que en caso de reorganización, el cliente tendrá que reintentar desde la primera solicitud para actualizar el hash del bloque a un bloque no-uncle.