Shopify trasladou as reservas de inventario a MySQL

Que abrangue este vídeo

• O antigo modelo de contador de cantidade de Redis xestionaba a concorrencia, pero a limpeza da reserva e a actualización do libro maior de MySQL non podían compartir unha única transacción atómica local.
• A substitución usa unha fila por unidade dispoñible nun conxunto limitado a 1.000 por combinación de artigo/localización. Un conxunto baleiro pode activar a reposición en liña con solicitudes concurrentes esperando detrás dun bloqueo de reposición.
• A clave principal composta é (shop_id, inventory_item_id, inventory_group_id, id). Shopify reduciu a sobrecarga de bloqueo no seu prototipo e usou READ COMMITTED para evitar bloqueos de oco que bloqueaban a reposición.
• A reserva elimina as filas do conxunto antes de inserir os rexistros de reserva. A confirmación libera os bloqueos da base de datos mentres a retención almacenada persiste durante o pago; o pago exitoso reclama o libro maior e elimina a reserva nunha transacción atómica posterior.
• MySQL documenta SKIP LOCKED como unha vista inconsistente que omite as filas bloqueadas. Non establece un reconto completo de existencias nin unha quenda xusta, aplícase só a bloqueos a nivel de fila e non é seguro para a replicación baseada en declaracións.
• O exemplo de orixe inclúe expires_at, pero Shopify non documenta o algoritmo de limpeza por caducidade de MySQL. A rama de liberación/caducidade do vídeo é un requisito explicativo do ciclo de vida.
• O tempo de retención da conexión noutro código de compra foi o pescozo de botella final no rendemento. Shopify escribiu en sombra ambos os sistemas, comparou os resultados e cambiou gradualmente cunha opción de retorno de emerxencia a Redis.

Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

Por que trasladar as reservas a MySQL?

0:00 Unha compra necesita que Redis sexa rápido. Shopify trasladou as reservas de inventario a MySQL usando unha fila por unidade nun conxunto delimitado. Por que elixir MySQL? Como se saltan os bloqueos de forma segura? Este é The Daily Diff, entre bastidores. E por que as consultas rápidas aínda atoparon un límite? Shopify é unha plataforma de comercio para vender en liña e en persoa. Redis é un almacén de datos en memoria.

0:21 MySQL é unha base de datos relacional, e Shopify xa gardaba o seu libro maior de inventario alí. Unha reserva mantén brevemente o stock mentres un comprador paga.

Por que dous almacéns eran arriscados?

0:29 O seu modelo Redis decrementaba un contador de artigos. Reclamar unha orde pagada significaba actualizar o libro maior de MySQL e limpar Redis. Esas escrituras separadas podían deixar o stock vendido dúas veces ou non dispoñible cando debería ser vendible. O antigo modelo tamén carecía de coñecemento da localización. A substitución debe escoller o stock dalgún lugar que poida cumprir a orde. Un almacén no continente equivocado fai unha excelente entrada na base de datos e unha terrible promesa de entrega. Intentos anteriores de MySQL usaban unha fila de cantidade, polo que as compras competidoras facían cola no

Cal se converte na unidade bloqueable?

0:56 mesmo bloqueo. Pense nunha corda de veludo arredor dunha cela de folla de cálculo. Engadir máis traballadores só alonga a cola. Shopify cambiou o obxecto bloqueable. Cada unidade dispoñible obtén a súa propia fila. Unha lectura de bloqueo salta as unidades que outra transacción ten e selecciona outras unidades elixibles. Diferentes traballadores poden adquirir diferentes filas, mentres o contador quente se mantén fóra do seu camiño.

Que ocorre cando o conxunto se baleira?

1:15 Ese conxunto está limitado a mil filas por artigo e localización. A reposición extráese do libro maior. Se se baleira, a ruta de reserva repón en liña, con solicitudes competidoras esperando detrás dun bloqueo de reposición. Un conxunto baleiro non significa un almacén baleiro. A reserva elimina as filas do conxunto seleccionadas e despois insere os rexistros de reserva nunha transacción. A confirmación libera os bloqueos da base de datos.

1:35 A reversión desface os cambios. A reserva sobrevive ao procesamento do pago como estado almacenado. O pago exitoso reclama o libro maior e elimina a reserva atomicamente. Os bloqueos da base de datos nunca necesitan vixiar o formulario de pago. A súa clave principal composta comeza con tenda, artigo, grupo, despois a identidade da unidade. Coincidir coa busca reduciu o bloqueo de índices no seu prototipo. Tamén usan a lectura confirmada para evitar os bloqueos de oco que bloqueaban a

1:57 reposición do conxunto e unha orde de táboa consistente para evitar esperas circulares. O exemplo publicado rexistra un tempo de caducidade. Os pagos abandonados necesitan que o stock sexa liberado eventualmente, ou o carro da compra convértese nun propietario. A publicación de Shopify deixa ese algoritmo de limpeza sen especificar, polo que este diagrama mostra o requisito do ciclo de vida. Aquí está o truco.

Que omite SKIP LOCKED?

2:14 Skip locked exclúe as filas bloqueadas, polo que o manual chama ao seu resultado unha vista inconsistente. Non proporciona nin un reconto completo de existencias nin unha quenda xusta. Manteña a decisión de dispoñibilidade e as regras de reposición arredor dela.

Onde estaba o verdadeiro límite?

2:26 E ese límite? Outro código de compra estaba retendo as conexións á base de datos demasiado tempo. Shopify etiquetou os chamadores e mediu o tempo de retención da conexión, despois limpou a ruta de compra e revisou a concorrencia de fíos. As consultas rápidas aínda poden facer cola fóra da consulta.

Por que enviaría este deseño?

2:38 Escribiron en sombra ambos os sistemas con Redis autoritario, compararon os resultados e despois cambiaron gradualmente cun interruptor de emerxencia. O meu veredicto é SHIP IT. Enviaríame o límite de transaccións compartido e esa implementación reversible, coa ruta de compra completa instrumentada. Tes algunha pregunta sobre isto? Ponla nos comentarios. E esa é a diferenza por hoxe.

2:54 Son Niko de Axrisi. Fusionar con responsabilidade.

Fontes

1. We replaced Redis with MySQL for inventory reservations—and it scaledShopify Engineering — Emilie Noel
2. Simplified reservation SQL embedded in Shopify's articleShopify Engineering / CourtneySymons on GitHub Gist
3. MySQL 8.0 — Locking ReadsOracle / MySQL Reference Manual
4. MySQL 8.0 — Transaction Isolation LevelsOracle / MySQL Reference Manual
5. What Is Shopify and How Does It Work?Shopify
6. Redis quick startsRedis documentation
7. What is MySQL?Oracle / MySQL Reference Manual