+− THE DAILY DIFFdev & AI news
SHIP IT

Shopify đã chuyển việc đặt trước hàng tồn kho vào MySQL

Shopify đã chuyển hệ thống đặt trước hàng tồn kho từ Redis sang cơ sở dữ liệu MySQL, nơi đã lưu trữ sổ cái hàng tồn kho.

Shopify đã chuyển hệ thống đặt trước hàng tồn kho từ Redis sang cơ sở dữ liệu MySQL, nơi đã lưu trữ sổ cái hàng tồn kho. Một nhóm các hàng đơn vị có thể khóa riêng lẻ với giới hạn cho phép các giao dịch thanh toán đồng thời sử dụng SKIP LOCKED để chọn các đơn vị đủ điều kiện khác nhau. Thiết kế này cũng phụ thuộc vào ranh giới giao dịch, bố cục khóa chính, quy tắc bổ sung và việc quan sát thời gian giữ kết nối trong suốt quá trình thanh toán.

Đọc phiên bản viết (tiếng Anh) ↗

Nội dung video này đề cập

  • Mô hình đếm số lượng của Redis trước đây đã xử lý tính đồng thời, nhưng việc dọn dẹp đặt trước và cập nhật sổ cái MySQL không thể chia sẻ một giao dịch nguyên tử cục bộ duy nhất.
  • Hệ thống thay thế sử dụng một hàng cho mỗi đơn vị có sẵn trong một nhóm được giới hạn ở 1.000 đơn vị cho mỗi sự kết hợp sản phẩm/địa điểm. Một nhóm trống có thể kích hoạt việc bổ sung ngay lập tức với các yêu cầu đồng thời chờ sau một khóa bổ sung.
  • Khóa chính tổng hợp là (shop_id, inventory_item_id, inventory_group_id, id). Shopify đã giảm chi phí khóa trong nguyên mẫu của mình và sử dụng READ COMMITTED để tránh các khóa khoảng trống gây chặn việc bổ sung.
  • Việc đặt trước xóa các hàng trong nhóm trước khi chèn các bản ghi đặt trước. Việc cam kết giải phóng các khóa cơ sở dữ liệu trong khi việc giữ đã lưu vẫn tồn tại trong suốt quá trình thanh toán; thanh toán thành công sẽ yêu cầu sổ cái và loại bỏ đặt trước trong một giao dịch nguyên tử sau đó.
  • MySQL tài liệu SKIP LOCKED như một chế độ xem không nhất quán bỏ qua các hàng bị khóa. Nó không thiết lập số lượng kho hoàn chỉnh hoặc việc luân phiên công bằng, chỉ áp dụng cho các khóa cấp hàng và không an toàn cho việc sao chép dựa trên câu lệnh.
  • Ví dụ nguồn bao gồm expires_at, nhưng Shopify không tài liệu thuật toán dọn dẹp hết hạn của MySQL. Nhánh phát hành/hết hạn của video là một yêu cầu về vòng đời giải thích.
  • Thời gian giữ kết nối trong các mã thanh toán khác là nút cổ chai thông lượng cuối cùng. Shopify đã ghi song song cả hai hệ thống, so sánh kết quả và chuyển đổi dần dần với một công tắc ngắt Redis dự phòng.

Bản ghi đã dịch

Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.

Tại sao chuyển đặt trước hàng tồn kho vào MySQL?

0:00 Một giao dịch thanh toán cần Redis để duy trì tốc độ. Shopify đã chuyển việc đặt trước hàng tồn kho vào MySQL bằng cách sử dụng một hàng cho mỗi đơn vị trong một nhóm giới hạn. Tại sao chọn MySQL? Làm cách nào để bỏ qua các khóa một cách an toàn? Đây là The Daily Diff, đi sâu vào bên trong. Và tại sao các truy vấn nhanh vẫn đạt đến giới hạn? Shopify là một nền tảng thương mại để bán hàng trực tuyến và trực tiếp. Redis là một kho dữ liệu trong bộ nhớ.

0:21 MySQL là một cơ sở dữ liệu quan hệ, và Shopify đã lưu giữ sổ cái hàng tồn kho của mình ở đó. Một đặt trước giữ hàng tồn kho trong thời gian ngắn khi người mua thanh toán.

Tại sao hai kho lưu trữ lại rủi ro?

0:29 Mô hình Redis của họ giảm một bộ đếm mặt hàng. Việc yêu cầu một đơn hàng đã thanh toán có nghĩa là cập nhật sổ cái MySQL và dọn dẹp Redis. Những thao tác ghi riêng biệt đó có thể khiến hàng tồn kho bị bán hai lần hoặc không có sẵn khi đáng lẽ nó phải có thể bán được. Mô hình cũ cũng thiếu khả năng nhận biết vị trí. Hệ thống thay thế phải chọn hàng tồn kho từ một nơi nào đó có thể thực hiện đơn hàng. Một nhà kho ở sai châu lục là một mục nhập cơ sở dữ liệu tuyệt vời và một lời hứa giao hàng tồi tệ. Các nỗ lực MySQL trước đây đã sử dụng một hàng số lượng, vì vậy các giao dịch thanh toán cạnh tranh đã xếp hàng tại cùng một

Đơn vị có thể khóa trở thành gì?

0:56 khóa. Hãy tưởng tượng một sợi dây nhung quanh một ô bảng tính. Thêm nhiều công nhân chỉ làm cho hàng đợi dài thêm. Shopify đã thay đổi đối tượng có thể khóa. Mỗi đơn vị có sẵn đều có hàng riêng. Một thao tác đọc khóa bỏ qua các đơn vị mà một giao dịch khác đang giữ và chọn các đơn vị đủ điều kiện khác. Các công nhân khác nhau có thể lấy các hàng khác nhau, trong khi bộ đếm nóng vẫn không cản đường họ.

Điều gì xảy ra khi nhóm trống?

1:15 Nhóm đó được giới hạn ở một nghìn hàng cho mỗi mặt hàng và vị trí. Việc bổ sung rút từ sổ cái. Nếu nó trống, đường dẫn đặt trước sẽ bổ sung ngay lập tức, với các yêu cầu cạnh tranh chờ sau một khóa bổ sung. Nhóm trống không có nghĩa là nhà kho trống. Đặt trước xóa các hàng đã chọn trong nhóm, sau đó chèn các bản ghi đặt trước trong một giao dịch. Cam kết giải phóng các khóa cơ sở dữ liệu.

1:35 Hoàn tác các thay đổi. Việc đặt trước tồn tại sau quá trình xử lý thanh toán dưới dạng trạng thái được lưu trữ. Thanh toán thành công yêu cầu sổ cái và loại bỏ đặt trước một cách nguyên tử. Các khóa cơ sở dữ liệu không bao giờ cần phải giám sát biểu mẫu thanh toán. Khóa chính tổng hợp của họ bắt đầu bằng shop, item, group, sau đó là định danh đơn vị. Việc khớp tìm kiếm đã giảm khóa chỉ mục trong nguyên mẫu của họ. Họ cũng sử dụng read committed để tránh các khóa khoảng trống gây chặn việc

1:57 bổ sung nhóm, và một thứ tự bảng nhất quán để ngăn chặn các đợi tròn. Ví dụ được công bố ghi lại thời gian hết hạn. Các khoản thanh toán bị bỏ dở cần được giải phóng hàng tồn kho cuối cùng, hoặc giỏ hàng trở thành một người cho thuê. Bài đăng của Shopify để thuật toán dọn dẹp đó không được chỉ rõ, vì vậy sơ đồ này hiển thị yêu cầu vòng đời. Đây là vấn đề.

SKIP LOCKED bỏ qua những gì?

2:14 Skip locked loại trừ các hàng bị khóa, vì vậy hướng dẫn sử dụng gọi kết quả của nó là một chế độ xem không nhất quán. Nó không cung cấp cả số lượng hàng tồn kho hoàn chỉnh lẫn việc luân phiên công bằng. Giữ quyết định khả dụng và các quy tắc bổ sung xung quanh nó.

Giới hạn thực sự ở đâu?

2:26 Và cái giới hạn đó? Các mã thanh toán khác đang giữ các kết nối cơ sở dữ liệu quá lâu. Shopify đã gắn thẻ người gọi và đo thời gian giữ kết nối, sau đó dọn dẹp đường dẫn thanh toán và xem xét lại tính đồng thời của luồng. Các truy vấn nhanh vẫn có thể xếp hàng bên ngoài truy vấn.

Tại sao tôi lại triển khai thiết kế này?

2:38 Họ đã ghi song song cả hai hệ thống với Redis là nguồn chính thức, so sánh kết quả, sau đó chuyển đổi dần dần với một công tắc ngắt. Phán quyết của tôi là SHIP IT. Tôi sẽ triển khai ranh giới giao dịch được chia sẻ và việc triển khai có thể hoàn tác đó, với toàn bộ đường dẫn thanh toán được trang bị công cụ. Có câu hỏi nào về điều này không? Đặt nó trong phần bình luận. Và đó là sự khác biệt của ngày hôm nay.

2:54 Tôi là Niko từ Axrisi. Hợp nhất có trách nhiệm.

Nguồn

  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

Video liên quan