Làm thế nào để một công ty như Amazon tránh tắc nghẽn khi truy cập vào lớp cơ sở dữ liệu?

Nếu bạn tưởng tượng một công ty như Amazon (hoặc bất kỳ ứng dụng web thương mại điện tử lớn nào khác), đang điều hành một cửa hàng trực tuyến ở quy mô lớn và chỉ có số lượng vật phẩm vật lý hạn chế trong kho của mình, làm sao họ có thể tối ưu hóa điều này sao cho không có nút cổ chai đơn? Tất nhiên, họ phải có một số cơ sở dữ liệu có bản sao và nhiều máy chủ đang xử lý tải độc lập. Tuy nhiên, nếu nhiều người dùng đang được phục vụ bởi các máy chủ riêng biệt và cả hai đều cố gắng thêm cùng một mặt hàng vào giỏ hàng của họ, chỉ còn một mặt hàng, thì phải có một số "nguồn sự thật" cho số lượng còn lại cho mặt hàng đó. Điều này có nghĩa là ít nhất, tất cả người dùng truy cập thông tin sản phẩm cho một mục phải được truy vấn cùng một cơ sở dữ liệu?

Tôi muốn hiểu làm thế nào bạn có thể vận hành một cửa hàng lớn bằng cách sử dụng điện toán phân tán và không tạo ra một nút cổ chai lớn trên một DB chứa thông tin hàng tồn kho.

Tuy nhiên, nếu nhiều người dùng đang được phục vụ bởi các máy chủ riêng biệt và cả hai đều cố gắng thêm cùng một mặt hàng vào giỏ hàng của họ, chỉ còn một mặt hàng, thì phải có một số "nguồn sự thật" cho số lượng còn lại cho mặt hàng đó.

Không hẳn vậy. Đây không phải là vấn đề đòi hỏi một giải pháp kỹ thuật hoàn hảo 100%, bởi vì cả hai trường hợp lỗi đều có giải pháp kinh doanh không quá tốn kém:

• Nếu bạn thông báo không chính xác cho người dùng một mặt hàng được bán hết, bạn sẽ mất việc bán hàng. Nếu bạn bán hàng triệu mặt hàng mỗi ngày và điều này có thể xảy ra một hoặc hai lần một ngày, nó sẽ bị mất trong tiếng ồn.
• Nếu bạn chấp nhận đơn đặt hàng và trong khi xử lý, bạn thấy rằng bạn đã hết hàng, bạn chỉ cần nói với khách hàng và cho họ lựa chọn chờ cho đến khi bạn có thể đặt lại hoặc hủy đơn hàng. Bạn có một khách hàng hơi khó chịu. Một lần nữa không phải là một vấn đề lớn khi 99,99% đơn hàng hoạt động tốt.

Trên thực tế, gần đây tôi đã trải nghiệm trường hợp thứ hai, vì vậy nó không phải là giả thuyết: đó là những gì xảy ra và cách Amazon xử lý nó.

Đó là một khái niệm áp dụng thường xuyên khi bạn gặp vấn đề về mặt lý thuyết rất khó giải quyết (về mặt hiệu suất, tối ưu hóa hoặc bất cứ điều gì): bạn thường có thể sống với một giải pháp hoạt động thực sự tốt trong hầu hết các trường hợp và đôi khi chấp nhận rằng thất bại, miễn là bạn có thể phát hiện và xử lý các lỗi khi chúng xảy ra.

Một sự kết hợp của

• băm
• bảo vệ
• nhân rộng
• phân phối
• thất bại cao
• cửa hàng khóa-giá trị

Không có phép thuật, chỉ là những tình huống ngày càng phức tạp hơn. Giống như DNS, nó được tạo ra theo tỷ lệ.

"Phiên bản duy nhất của sự thật" là một phần của các hệ thống như vậy. Tạo khóa mới trở thành một hoạt động phức tạp hơn là chỉ tạo số tiếp theo trong chuỗi. Ví dụ các trình tự khác tồn tại. Đây là loại phức tạp mà các hệ thống cơ sở dữ liệu phân tán có thể xử lý và chúng thực hiện bằng cách thực hiện một số thao tác đến và từ các thành phần khi tạo đối tượng mới, cung cấp chúng cho các đối tượng khác, đảm bảo rằng các chuỗi là duy nhất khi chúng cần, các khóa tổng hợp, v.v. .

Tôi đã thấy vấn đề 'Sản phẩm cuối cùng trong kho' được giải quyết theo cách sau:

Cập nhật tất cả các mức chứng khoán hàng ngày và gắn cờ các sản phẩm cao, thấp, theo đơn đặt hàng hoặc ra khỏi danh mục chứng khoán theo mức ngưỡng.

Rõ ràng đó là các mặt hàng 'cổ phiếu thấp' có vấn đề

• Các mặt hàng có mức cổ phiếu cao

Đừng bận tâm kiểm tra mức chứng khoán. Chỉ cần đặt hàng

• Các mặt hàng có mức cổ phiếu thấp

Cảnh báo người dùng khi duyệt 'Vài lần cuối còn lại!'. khi họ đi thanh toán, kiểm tra và giảm mức chứng khoán. Nếu nó hết hàng, Cập nhật trạng thái mục.

Bằng cách này, bạn chỉ truy cập cơ sở dữ liệu cho các mặt hàng 'cổ phiếu thấp' và bạn chỉ làm điều đó khi khách hàng ở quá xa quá trình mua hàng. Chi phí là một số khách hàng sẽ không thể hoàn thành giao dịch mua hàng của họ.

Tuy nhiên, trong hầu hết các trường hợp 'hết hàng' thực sự chỉ có nghĩa là bạn đang chờ giao hàng khác, vì vậy dù sao bạn cũng muốn chấp nhận đơn đặt hàng và có thể chỉ bật lên một cảnh báo hoặc hạn chế các tùy chọn giao hàng. Vì vậy, những khách hàng không mất.

Trong thời gian tải cao như bán hàng, bạn thậm chí có thể tắt kiểm tra chứng khoán và chỉ gửi email cho khách hàng sau, 'xin lỗi chúng tôi đã hết X, bạn có muốn Y'

Về cơ bản, mục tiêu của bất kỳ nền tảng thương mại điện tử nào là không bao giờ được đọc từ cơ sở dữ liệu. Luôn phục vụ các trang được lưu trữ và làm mọi thứ phía máy khách.

Trong video này, Martin Fowler thảo luận về cơ sở dữ liệu NoQuery:

https://www.youtube.com/watch?v=qI_g07C_Q5I

Một trong những điểm (ở đâu đó trong đó), là những nơi như Amazon thà giữ 99% mọi người vui vẻ bằng cách chấp nhận đơn đặt hàng của họ mà không thể kiểm tra "chắc chắn" liệu nó có thực sự hay không và có thể gây khó chịu cho một tỷ lệ rất nhỏ khi có để nói "xin lỗi, có vẻ như ai đó đánh bạn với nó."

Có thể nói, không có xử lý thực sự cho kịch bản mà bạn mô tả, chỉ là Amazon có lợi ích của sự nghi ngờ dựa trên lần đọc hàng tồn kho thành công cuối cùng và nếu một giao dịch đồng thời bị trượt giữa - oopsie.

(btw, đó là một video tuyệt vời nếu bạn tò mò về NoQuery)