Lời mở đầu
Nhiều bạn phản hồi rằng đã học chuyên đề đồng thời trong một thời gian dài, nhưng khi thực sự làm dự án, vẫn không biết bắt đầu từ đâu để xử lý các trường hợp sử dụng đồng thời! Thậm chí nhiều bạn vẫn dừng lại ở mức cung cấp giao diện đơn giản (CRUD), không biết cách áp dụng kiến thức đồng thời đã học vào dự án thực tế, chưa nói đến cách xây dựng hệ thống đồng thời!
Hệ thống nào được coi là hệ thống đồng thời? Hôm nay, chúng ta cùng giải mã kiến trúc của hệ thống săn hàng flash sale điển hình trong trường hợp sử dụng đồng thời, kết hợp với các bài viết khác trong chuyên đề đồng thời, vận dụng kiến thức đã học.
Kiến trúc hệ thống thương mại điện tử
Trong lĩnh vực thương mại điện tử, tồn tại trường hợp sử dụng điển hình là săn hàng flash sale, vậy săn hàng flash sale là gì? Nói một cách đơn giản, đó là việc số lượng người mua một sản phẩm nhiều hơn nhiều so với số lượng hàng tồn kho của sản phẩm đó, và sản phẩm này sẽ hết hàng trong một thời gian rất ngắn. Chẳng hạn, các trường hợp sử dụng kinh doanh điển hình như khuyến mãi 10/10, khuyến mãi 11/11 hàng năm, v.v., đều là những trường hợp sử dụng điển hình của săn hàng flash sale.
Chúng ta có thể đơn giản hóa kiến trúc của hệ thống thương mại điện tử như sơ đồ dưới đây.
Như sơ đồ cho thấy, chúng ta có thể đơn giản hóa lớp cốt lõi của hệ thống thương mại điện tử thành: lớp cân bằng tải, lớp ứng dụng và lớp lưu trữ. Tiếp theo, chúng ta sẽ ước tính mức đồng thời của mỗi lớp.
-
Giả sử lớp cân bằng tải sử dụng Nginx hiệu suất cao, thì chúng ta có thể ước tính mức đồng thời tối đa của Nginx là: >1.000.000.
-
Giả sử lớp ứng dụng của chúng ta sử dụng Tomcat, và mức đồng thời tối đa của Tomcat có thể ước tính là khoảng 800, đơn vị là trăm.
-
Giả sử lớp lưu trữ sử dụng Redis làm bộ nhớ đệm và MySQL làm cơ sở dữ liệu, thì mức đồng thời tối đa của MySQL có thể ước tính là khoảng 1000, đơn vị là nghìn. Mức đồng thời tối đa của Redis có thể ước tính là khoảng 50.000.
Do đó, mức đồng thời của lớp cân bằng tải, lớp ứng dụng và lớp lưu trữ là khác nhau, vậy để nâng cao mức đồng thời tổng thể của hệ thống và bộ nhớ đệm, chúng ta thường có thể áp dụng những phương án nào?
(1) Mở rộng hệ thống
Mở rộng hệ thống bao gồm mở rộng theo chiều dọc và mở rộng theo chiều ngang, tăng thêm thiết bị và cấu hình máy móc, hiệu quả trong hầu hết các trường hợp.
(2) Bộ nhớ đệm
Bộ nhớ đệm cục bộ hoặc bộ nhớ đệm tập trung, giảm thiểu IO mạng, đọc dữ liệu dựa trên bộ nhớ. Hiệu quả trong hầu hết các trường hợp.
(3) Tách biệt đọc/ghi
Áp dụng tách biệt đọc/ghi, chia để trị, tăng khả năng xử lý song song của máy móc.
Đặc điểm của hệ thống săn hàng flash sale
Đối với hệ thống săn hàng flash sale, chúng ta có thể trình bày những đặc điểm riêng biệt của hệ thống này từ hai góc độ là kinh doanh và kỹ thuật.
Đặc điểm kinh doanh của hệ thống săn hàng flash sale
Ở đây, chúng ta có thể lấy ví dụ về Shopee, lượng truy cập của shopee rất lớn vào mỗi dịp ngày tháng cặp như 5/5, nhưng lượng truy cập bình thường của shopee lại tương đối ổn định, điều đó có nghĩa là lượng truy cập của shopee sẽ tăng đột biến vào mỗi dịp đặc biệt.
Ví dụ nữa, hệ thống săn hàng flash sale của Lazada, sản phẩm được bán vào lúc 0 giờ sáng, lượng truy cập trước 0 giờ tương đối ổn định, đến 0 giờ cũng sẽ xuất hiện hiện tượng lượng truy cập tăng đột biến.
Do đó, lượng truy cập và mức đồng thời của hệ thống săn hàng flash sale có thể được thể hiện bằng sơ đồ dưới đây.
Như sơ đồ cho thấy, mức đồng thời của hệ thống săn hàng flash sale có đặc điểm đột biến tức thời, còn được gọi là hiện tượng đột biến lưu lượng.
Chúng ta có thể tóm tắt các đặc điểm của hệ thống săn hàng flash sale như sau.
(1) Giới hạn thời gian, giới hạn số lượng, giới hạn giá
Trong thời gian quy định; số lượng sản phẩm trong hoạt động săn hàng flash sale là có hạn; giá của sản phẩm sẽ thấp hơn nhiều so với giá ban đầu, có nghĩa là trong hoạt động săn hàng flash sale, sản phẩm sẽ được bán với giá thấp hơn nhiều so với giá ban đầu.
Ví dụ, thời gian của hoạt động săn hàng flash sale chỉ giới hạn trong khoảng 0 giờ sáng đến 0 giờ 30 phút của một ngày nào đó, số lượng sản phẩm chỉ có 100.000 sản phẩm, bán hết là hết, và giá của sản phẩm rất thấp, chẳng hạn: mua 1 đồng v.v.
Giới hạn thời gian, giới hạn số lượng và giới hạn giá có thể tồn tại độc lập hoặc kết hợp với nhau.
(2) Làm nóng hoạt động
Cần cấu hình hoạt động trước; khi hoạt động chưa bắt đầu, người dùng có thể xem thông tin liên quan đến hoạt động; trước khi hoạt động săn hàng flash sale bắt đầu, hãy quảng bá rầm rộ cho hoạt động.
(3) Thời gian ngắn
Số lượng người mua rất lớn; sản phẩm sẽ nhanh chóng bán hết.
Về mặt lưu lượng của hệ thống, sẽ xuất hiện hiện tượng đột biến, mức đồng thời truy cập vào thời điểm này là rất cao, trong hầu hết các trường hợp săn hàng flash sale, sản phẩm sẽ bán hết trong thời gian rất ngắn.
Đặc điểm kỹ thuật của hệ thống săn hàng flash sale
Chúng ta có thể tóm tắt các đặc điểm kỹ thuật của hệ thống săn hàng flash sale như sau.
(1) Mức đồng thời tức thời rất cao
Rất nhiều người dùng sẽ cùng lúc tranh giành mua sản phẩm; đỉnh điểm đồng thời tức thời rất cao.
(2) Đọc nhiều, ghi ít
Lượng truy cập vào trang sản phẩm trong hệ thống rất lớn; số lượng sản phẩm có thể mua được rất ít; số lượng truy cập truy vấn hàng tồn kho lớn hơn nhiều so với số lượng mua sản phẩm.
Trong trang sản phẩm, thường sẽ thêm một số biện pháp hạn chế lưu lượng, chẳng hạn như hệ thống săn hàng flash sale giai đoạn đầu sẽ thêm mã xác thực vào trang sản phẩm để làm mượt lưu lượng truy cập của phía trước vào hệ thống, hệ thống săn hàng flash sale gần đây sẽ nhắc nhở người dùng đăng nhập hệ thống khi người dùng mở trang chi tiết sản phẩm. Đây đều là một số biện pháp hạn chế lưu lượng truy cập vào hệ thống.
(3) Quy trình đơn giản
Quy trình kinh doanh của hệ thống săn hàng flash sale thường tương đối đơn giản; nói chung, quy trình kinh doanh của hệ thống săn hàng flash sale có thể được tóm tắt là: đặt hàng giảm hàng tồn kho.
Đối với hệ thống có lưu lượng lớn trong thời gian ngắn như vậy, việc mở rộng hệ thống không phù hợp lắm, bởi vì ngay cả khi hệ thống được mở rộng, nó cũng chỉ được sử dụng trong một thời gian rất ngắn, trong phần lớn thời gian, hệ thống không cần mở rộng để truy cập bình thường. Vậy, chúng ta có thể áp dụng những phương án nào để nâng cao hiệu suất săn hàng flash sale của hệ thống?
Phương án hệ thống săn hàng flash sale
Nhắm vào các đặc điểm của hệ thống săn hàng flash sale, chúng ta có thể áp dụng các biện pháp sau để nâng cao hiệu suất của hệ thống.
(1) Giải tách đồng bộ hóa
Phân tách toàn bộ quy trình, điều khiển quy trình cốt lõi bằng cách sử dụng hàng đợi.
(2) Hạn chế lưu lượng, chống gian lận
Kiểm soát lưu lượng tổng thể của trang web, nâng cao ngưỡng yêu cầu, tránh cạn kiệt tài nguyên hệ thống.
(3) Kiểm soát tài nguyên
Kiểm soát việc phân bổ tài nguyên trong toàn bộ quy trình, phát huy ưu điểm của từng phần.
Do mức đồng thời mà lớp ứng dụng có thể chịu đựng được nhỏ hơn nhiều so với mức đồng thời mà bộ nhớ đệm có thể chịu đựng được. Do đó, trong hệ thống đồng thời cao, chúng ta có thể sử dụng OpenResty trực tiếp từ lớp cân bằng tải để truy cập bộ nhớ đệm, tránh tổn thất hiệu suất khi gọi lớp ứng dụng. Mọi người có thể truy cập https://openresty.org/cn/ để tìm hiểu thêm về OpenResty. Đồng thời, do số lượng sản phẩm trong hệ thống săn hàng flash sale tương đối ít, chúng ta cũng có thể sử dụng kỹ thuật hiển thị động, kỹ thuật CDN để tăng tốc hiệu suất truy cập trang web.
Nếu mức đồng thời quá cao khi hoạt động săn hàng flash sale bắt đầu, chúng ta có thể đặt yêu cầu của người dùng vào hàng đợi để xử lý và hiển thị trang xếp hàng cho người dùng.
Sơ đồ thời gian hệ thống săn hàng flash sale
Rất nhiều hệ thống săn hàng flash sale và giải pháp cho hệ thống săn hàng flash sale trên mạng không phải là hệ thống săn hàng flash sale thực sự, họ chỉ áp dụng phương án xử lý yêu cầu đồng bộ, một khi mức đồng thời thực sự tăng lên, hiệu suất của hệ thống săn hàng flash sale được gọi là sẽ giảm mạnh. Trước tiên, hãy xem sơ đồ thời gian của hệ thống săn hàng flash sale khi đặt hàng đồng bộ.
Quy trình đặt hàng đồng bộ
- Người dùng khởi tạo yêu cầu săn hàng flash sale.
Trong quy trình đặt hàng đồng bộ, trước tiên, người dùng khởi tạo yêu cầu săn hàng flash sale. Dịch vụ thương mại cần thực hiện các quy trình sau theo trình tự để xử lý yêu cầu kinh doanh của yêu cầu săn hàng flash sale.
(1) Nhận biết mã xác thực có chính xác hay không
Dịch vụ thương mại xác định xem mã xác thực mà người dùng gửi khi khởi tạo yêu cầu săn hàng flash sale có chính xác hay không.
(2) Xác định xem hoạt động đã kết thúc chưa
Xác định xem hoạt động săn hàng flash sale hiện tại đã kết thúc chưa.
(3) Xác định xem yêu cầu truy cập có nằm trong danh sách đen hay không
Trong lĩnh vực thương mại điện tử, tồn tại rất nhiều cạnh tranh ác ý, có nghĩa là các nhà cung cấp khác có thể sử dụng các biện pháp bất chính để yêu cầu ác ý hệ thống săn hàng flash sale, chiếm dụng lượng băng thông và các tài nguyên hệ thống khác của hệ thống. Vào thời điểm này, cần sử dụng hệ thống kiểm soát rủi ro, v.v. để thực hiện cơ chế danh sách đen. Để đơn giản hóa, bạn cũng có thể sử dụng bộ lọc để thống kê tần suất truy cập và thực hiện cơ chế danh sách đen.
(4) Xác định xem hàng tồn kho thực tế có đủ hay không
Hệ thống cần xác định xem hàng tồn kho thực tế của sản phẩm có đủ hay không, có thể hỗ trợ số lượng hàng tồn kho của sản phẩm cho hoạt động săn hàng flash sale hiện tại hay không.
(5) Trừ đi hàng tồn kho trong bộ nhớ đệm
Trong hoạt động săn hàng flash sale, thông tin hàng tồn kho của sản phẩm, v.v. thường được lưu trữ trong bộ nhớ đệm, vào thời điểm này, cũng cần xác định xem hàng tồn kho của sản phẩm được sử dụng trong hoạt động săn hàng flash sale có đủ hay không và cần trừ đi số lượng hàng tồn kho của sản phẩm cho hoạt động săn hàng flash sale.
(6) Tính toán giá săn hàng flash sale
Do trong hoạt động săn hàng flash sale, giá săn hàng flash sale của sản phẩm khác với giá thực tế của sản phẩm, do đó cần tính toán giá săn hàng flash sale của sản phẩm.
Lưu ý: Nếu hoạt động kinh doanh liên quan trong trường hợp săn hàng flash sale phức tạp hơn, sẽ liên quan đến nhiều thao tác kinh doanh hơn, ở đây tôi chỉ liệt kê một số thao tác kinh doanh phổ biến.
- Gửi đơn hàng
(1) Lối vào đơn hàng
Lưu trữ thông tin đơn hàng mà người dùng gửi vào cơ sở dữ liệu.
(2) Trừ đi hàng tồn kho thực tế
Sau khi đơn hàng được lưu trữ, cần trừ đi số lượng sản phẩm đã đặt hàng thành công trong hàng tồn kho thực tế của sản phẩm.
Nếu chúng ta sử dụng quy trình trên để phát triển hệ thống săn hàng flash sale, khi người dùng khởi tạo yêu cầu săn hàng flash sale, do mỗi quy trình kinh doanh của hệ thống đều được thực hiện tuần tự, hiệu suất tổng thể của hệ thống sẽ không cao lắm, khi mức đồng thời quá
Thời gian xếp hàng có thể là 15 giây, hoặc 30 giây, thậm chí lâu hơn. Điều này dẫn đến một vấn đề: trong khoảng thời gian từ khi người dùng khởi tạo yêu cầu săn hàng flash sale đến khi máy chủ trả về kết quả, kết nối giữa máy khách và máy chủ sẽ không được giải phóng, điều này sẽ chiếm dụng rất nhiều tài nguyên của máy chủ.
Rất nhiều bài viết giới thiệu cách thực hiện hệ thống săn hàng flash sale trên mạng đều sử dụng phương thức này, vậy phương thức này có thể làm hệ thống săn hàng flash sale không? Câu trả lời là có, nhưng mức đồng thời mà phương thức này có thể hỗ trợ không cao lắm. Vào thời điểm này, một số người dùng có thể hỏi: Công ty của chúng tôi đang làm hệ thống săn hàng flash sale như vậy! Đã được đưa vào sử dụng và không có vấn đề gì! Tôi muốn nói rằng: Sử dụng phương thức đặt hàng đồng bộ thực sự có thể làm hệ thống săn hàng flash sale, nhưng hiệu suất của đặt hàng đồng bộ sẽ không cao lắm. Lý do tại sao hệ thống săn hàng flash sale sử dụng phương thức đặt hàng đồng bộ mà công ty của bạn không gặp vấn đề lớn, bởi vì mức đồng thời của hệ thống săn hàng flash sale của bạn chưa đạt đến một mức nhất định, có nghĩa là mức đồng thời của hệ thống săn hàng flash sale của bạn thực ra không cao lắm.
Do đó, rất nhiều hệ thống săn hàng flash sale được gọi là có hoạt động săn hàng flash sale, nhưng không phải là hệ thống săn hàng flash sale thực sự, lý do là họ sử dụng quy trình đặt hàng đồng bộ, hạn chế lưu lượng đồng thời của hệ thống. Lý do tại sao nó không gặp vấn đề lớn sau khi đưa vào sử dụng là bởi vì mức đồng thời của hệ thống không cao lắm, không đủ để đánh sập toàn bộ hệ thống.
Nếu hệ thống săn hàng flash sale của Shopee, Lazada, Tiki, v.v. các thương mại điện tử lớn chơi theo cách này, thì hệ thống của họ chắc chắn sẽ bị đánh sập, các kỹ sư hệ thống của họ không bị sa thải mới là lạ! Do đó, trong hệ thống săn hàng flash sale, phương án quy trình kinh doanh xử lý đặt hàng đồng bộ này là không thể chấp nhận được.
Trên đây là toàn bộ quy trình hoạt động của đặt hàng đồng bộ, nếu quy trình đặt hàng phức tạp hơn, sẽ liên quan đến nhiều thao tác kinh doanh hơn.
Quy trình đặt hàng bất đồng bộ
Do hệ thống săn hàng flash sale sử dụng quy trình đặt hàng đồng bộ không được coi là hệ thống săn hàng flash sale thực sự, do đó chúng ta cần áp dụng quy trình đặt hàng bất đồng bộ. Quy trình đặt hàng bất đồng bộ sẽ không hạn chế lưu lượng đồng thời cao của hệ thống.
- Người dùng khởi tạo yêu cầu săn hàng flash sale
Sau khi người dùng khởi tạo yêu cầu săn hàng flash sale, dịch vụ thương mại sẽ trải qua các quy trình kinh doanh sau.
(1) Kiểm tra xem mã xác thực có chính xác hay không
Khi người dùng khởi tạo yêu cầu săn hàng flash sale, họ sẽ cùng gửi mã xác thực, hệ thống sẽ kiểm tra xem mã xác thực có hợp lệ và chính xác hay không.
(2) Có giới hạn lưu lượng hay không
Hệ thống sẽ xác định xem có giới hạn lưu lượng cho yêu cầu của người dùng hay không, ở đây, chúng ta có thể xác định bằng cách xác định độ dài của hàng đợi tin nhắn. Bởi vì chúng ta đặt yêu cầu của người dùng vào hàng đợi tin nhắn, hàng đợi tin nhắn chứa yêu cầu của người dùng, chúng ta có thể xác định xem có cần giới hạn lưu lượng cho yêu cầu của người dùng hay không dựa trên số lượng yêu cầu chưa xử lý hiện có trong hàng đợi tin nhắn.
Ví dụ, trong hoạt động săn hàng flash sale, chúng ta bán 1.000 sản phẩm, vào thời điểm này, có 1.000 yêu cầu trong hàng đợi tin nhắn, nếu sau đó vẫn có người dùng khởi tạo yêu cầu săn hàng flash sale, thì chúng ta có thể không xử lý các yêu cầu sau đó nữa, mà trực tiếp trả về thông báo sản phẩm đã bán hết cho người dùng.
Do đó, sau khi sử dụng giới hạn lưu lượng, chúng ta có thể xử lý yêu cầu của người dùng nhanh hơn và giải phóng tài nguyên kết nối.
(3) Gửi MQ
Sau khi yêu cầu săn hàng flash sale của người dùng vượt qua kiểm tra trước đó, chúng ta có thể gửi thông tin như tham số yêu cầu của người dùng vào MQ để xử lý bất đồng bộ, đồng thời trả về thông tin kết quả cho người dùng. Trong dịch vụ thương mại, sẽ có một mô-đun xử lý tác vụ bất đồng bộ chuyên dụng để tiêu thụ tin nhắn trong hàng đợi tin nhắn và xử lý các quy trình bất đồng bộ tiếp theo.
Khi người dùng khởi tạo yêu cầu săn hàng flash sale, quy trình đặt hàng bất đồng bộ xử lý ít thao tác kinh doanh hơn quy trình đặt hàng đồng bộ, nó sẽ gửi các thao tác tiếp theo thông qua MQ cho mô-đun xử lý bất đồng bộ để xử lý và nhanh chóng trả về kết quả phản hồi cho người dùng, giải phóng kết nối yêu cầu.
- Xử lý bất đồng bộ
Chúng ta có thể xử lý các thao tác sau trong quy trình đặt hàng bất đồng bộ.
(1) Xác định xem hoạt động đã kết thúc chưa
(2) Xác định xem yêu cầu hiện tại có nằm trong danh sách đen của hệ thống hay không, để ngăn chặn cạnh tranh ác ý giữa các nhà cung cấp thương mại điện tử, bạn có thể thêm cơ chế danh sách đen cho hệ thống, đặt các yêu cầu ác ý vào danh sách đen của hệ thống. Bạn có thể sử dụng bộ lọc để thống kê tần suất truy cập để thực hiện.
(3) Trừ đi số lượng hàng tồn kho của sản phẩm săn hàng flash sale trong bộ nhớ đệm.
(4) Tạo Token săn hàng flash sale, Token này được liên kết với người dùng hiện tại và hoạt động săn hàng flash sale hiện tại, chỉ những yêu cầu đã tạo Token săn hàng flash sale mới đủ điều kiện tham gia hoạt động săn hàng flash sale.
Ở đây, chúng ta giới thiệu cơ chế xử lý bất đồng bộ, trong xử lý bất đồng bộ, hệ thống sử dụng bao nhiêu tài nguyên, phân bổ bao nhiêu luồng để xử lý các tác vụ tương ứng, đều có thể được kiểm soát.
- Yêu cầu ngắn hạn để kiểm tra kết quả săn hàng flash sale
Ở đây, bạn có thể áp dụng phương án máy khách yêu cầu ngắn hạn để kiểm tra xem có được quyền săn hàng flash sale hay không. Ví dụ, máy khách có thể yêu cầu máy chủ cứ 3 giây một lần để kiểm tra xem có được quyền săn hàng flash sale hay không, ở đây, chúng ta xử lý trên máy chủ là xác định xem người dùng hiện tại có Token săn hàng flash sale hay không, nếu máy chủ đã tạo Token săn hàng flash sale cho người dùng hiện tại, thì người dùng hiện tại có quyền săn hàng flash sale. Nếu không, hãy tiếp tục yêu cầu ngắn hạn cho đến khi hết thời gian hoặc máy chủ trả về thông báo sản phẩm đã bán hết hoặc không có quyền săn hàng flash sale, v.v.
Khi sử dụng yêu cầu ngắn hạn để kiểm tra kết quả săn hàng flash sale, chúng ta cũng có thể nhắc nhở người dùng đang xếp hàng xử lý trên trang web, nhưng vào thời điểm này, máy khách sẽ yêu cầu máy chủ kiểm tra trạng thái quyền săn hàng flash sale cứ sau vài giây một lần, so với quy trình đặt hàng đồng bộ, nó không cần phải chiếm dụng kết nối yêu cầu trong thời gian dài.
Vào thời điểm này, một số người dùng có thể hỏi: Sử dụng phương thức yêu cầu ngắn hạn, liệu có thể xảy ra trường hợp không thể kiểm tra xem có quyền săn hàng flash sale hay không cho đến khi hết thời gian hay không? Câu trả lời là: Có thể! Hãy suy nghĩ về trường hợp săn hàng flash sale thực tế, về bản chất, nhà cung cấp tham gia hoạt động săn hàng flash sale không phải để kiếm tiền, mà là để nâng cao doanh số bán hàng của sản phẩm và mức độ nổi tiếng của nhà cung cấp, thu hút nhiều người dùng hơn để mua sản phẩm của mình. Do đó, chúng ta không cần phải đảm bảo người dùng có thể kiểm tra 100% xem có quyền săn hàng flash sale hay không.
- Thanh toán săn hàng flash sale
(1) Xác thực Token đặt hàng
Khi máy khách gửi thanh toán săn hàng flash sale, họ sẽ cùng gửi Token săn hàng flash sale đến máy chủ, dịch vụ thương mại sẽ xác thực xem Token săn hàng flash sale hiện tại có hợp lệ hay không.
(2) Thêm vào giỏ hàng săn hàng flash sale
Sau khi dịch vụ thương mại xác thực Token săn hàng flash sale hợp lệ và hiệu quả, họ sẽ thêm sản phẩm săn hàng flash sale của người dùng vào giỏ hàng săn hàng flash sale.
- Gửi đơn hàng
(1) Lưu trữ đơn hàng
Lưu trữ thông tin đơn hàng mà người dùng gửi vào cơ sở dữ liệu.
(2) Xóa Token
Sau khi đơn hàng của sản phẩm săn hàng flash sale được lưu trữ thành công, hãy xóa Token săn hàng flash sale.
Ở đây, mọi người có thể suy nghĩ về một vấn đề: Tại sao chúng ta chỉ áp dụng xử lý bất đồng bộ ở phần màu hồng của quy trình đặt hàng bất đồng bộ, mà không áp dụng các biện pháp bất đồng bộ để làm mượt đỉnh cao và lấp đầy hố ở các phần khác?
Bởi vì trong thiết kế quy trình đặt hàng bất đồng bộ, dù là về thiết kế sản phẩm hay thiết kế giao diện, chúng ta đều thực hiện giới hạn lưu lượng cho yêu cầu của người dùng trong giai đoạn người dùng khởi tạo yêu cầu săn hàng flash sale, có thể nói việc giới hạn lưu lượng của hệ thống là rất sớm. Khi người dùng khởi tạo yêu cầu săn hàng flash sale, lưu lượng đỉnh cao của hệ thống đã được làm mượt, đi xa hơn, thực tế mức đồng thời và lưu lượng của hệ thống không cao lắm.
Do đó, rất nhiều bài viết và bài đăng trên mạng giới thiệu về hệ thống săn hàng flash sale đều nói rằng sử dụng làm mượt đỉnh cao bất đồng bộ để thực hiện một số thao tác giới hạn lưu lượng khi đặt hàng, điều đó là vô lý! Bởi vì thao tác đặt hàng là thao tác tương đối phía sau trong toàn bộ quy trình của hệ thống săn hàng flash sale, thao tác giới hạn lưu lượng phải được xử lý trước, việc giới hạn lưu lượng trong quy trình phía sau của hoạt động kinh doanh săn hàng flash sale là vô dụng.
"Công nghệ đen" và bí quyết chiến thắng trong đồng thời cao
Giả sử, trong hệ thống săn hàng flash sale, chúng ta sử dụng Redis để thực hiện bộ nhớ đệm, giả sử mức đồng thời đọc/ghi của Redis là khoảng 5 vạn. Hoạt động săn hàng flash sale của thương mại điện tử của chúng ta cần hỗ trợ mức đồng thời là khoảng 100 vạn. Nếu 100 vạn đồng thời này đều đánh vào Redis, Redis rất có thể sẽ sập, vậy chúng ta phải làm sao để giải quyết vấn đề này? Tiếp theo, chúng ta hãy cùng thảo luận về vấn đề này.
Trong hệ thống săn hàng flash sale đồng thời cao, nếu sử dụng Redis để lưu trữ dữ liệu bộ nhớ đệm, thì khả năng xử lý đồng thời của bộ nhớ đệm Redis là rất quan trọng, bởi vì rất nhiều thao tác tiền tố cần truy cập Redis. Và việc làm mượt đỉnh cao bất đồng bộ chỉ là thao tác cơ bản, điều quan trọng là phải đảm bảo khả năng xử lý đồng thời của Redis.
Ý tưởng chính để giải quyết vấn đề này là: Chia để trị, phân tách hàng tồn kho của sản phẩm.
Âm thầm lặng lẽ
Khi chúng ta lưu trữ số lượng hàng tồn kho của sản phẩm săn hàng flash sale trong Redis, chúng ta có thể "phân tách" hàng tồn kho của sản phẩm săn hàng flash sale để lưu trữ để nâng cao mức đồng thời đọc/ghi của Redis.
Ví dụ, ID ban đầu của sản phẩm săn hàng flash sale là 10001, hàng tồn kho là 1000 sản phẩm, lưu trữ trong Redis là (10001, 1000), chúng ta chia hàng tồn kho ban đầu thành 5 phần, mỗi phần hàng tồn kho là 200 sản phẩm, vào thời điểm này, thông tin lưu trữ trong Redia của chúng ta là (10001_0, 200), (10001_1, 200), (10001_2, 200), (10001_3, 200), (10001_4, 200).
Vào thời điểm này, sau khi chúng ta chia nhỏ hàng tồn kho, mỗi hàng tồn kho được chia nhỏ sẽ sử dụng ID sản phẩm cộng thêm một chữ số để biểu thị để lưu trữ, như vậy khi thực hiện tính toán băm cho mỗi Key lưu trữ thông tin hàng tồn kho, kết quả băm thu được sẽ khác nhau, điều này cho thấy Key lưu trữ thông tin hàng tồn kho có khả năng rất cao sẽ không nằm trong cùng một khe của Redis, điều này có thể nâng cao hiệu suất và mức đồng thời xử lý yêu cầu của Redis.
Sau khi chia nhỏ hàng tồn kho, chúng ta cũng cần lưu trữ một bản đồ ID sản phẩm và Key sau khi chia nhỏ hàng tồn kho trong Redis, vào thời điểm này, Key của bản đồ là ID sản phẩm, tức là 10001, Value là Key sau khi chia nhỏ hàng tồn kho để lưu trữ thông tin hàng tồn kho, tức là 10001_0, 10001_1, 10001_2, 10001_3, 10001_4. Chúng ta có thể sử dụng List để lưu trữ các giá trị này trong Redis.
Khi xử lý thông tin hàng tồn kho thực sự, chúng ta có thể truy vấn tất cả các Key sau khi chia nhỏ hàng tồn kho tương ứng với sản phẩm săn hàng flash sale từ Redis trước, đồng thời sử dụng AtomicLong để ghi lại số lượng yêu cầu hiện tại, sử dụng số lượng yêu cầu để thực hiện phép tính modulo với độ dài của tất cả các Key sau khi chia nhỏ hàng tồn kho tương ứng với sản phẩm săn hàng flash sale được truy vấn từ Redia, kết quả thu được là 0, 1, 2, 3, 4. Sau đó nối thêm ID sản phẩm ở phía trước, bạn có thể thu được Key bộ nhớ đệm hàng tồn kho thực sự. Vào thời điểm này, bạn có thể lấy thông tin hàng tồn kho tương ứng trực tiếp từ Redis dựa trên Key này.
Thay đổi cách sắp xếp
Trong trường hợp sử dụng đồng thời cao, chúng ta có thể sử dụng thư viện kịch bản Lua (OpenResty) trực tiếp từ lớp cân bằng tải để truy cập bộ nhớ đệm.
Ở đây, chúng ta hãy suy nghĩ về một trường hợp: Nếu sản phẩm săn hàng flash sale bị bán hết trong nháy mắt trong trường hợp sử dụng săn hàng flash sale. Vào thời điểm này, khi người dùng khởi tạo yêu cầu săn hàng flash sale, nếu hệ thống yêu cầu các dịch vụ khác nhau của lớp ứng dụng từ lớp cân bằng tải, sau đó các dịch vụ khác nhau của lớp ứng dụng truy cập bộ nhớ đệm và cơ sở dữ liệu, về bản chất, nó không còn ý nghĩa gì nữa, bởi vì sản phẩm đã bán hết, việc xác thực từng lớp thông qua lớp ứng dụng của hệ thống không còn nhiều ý nghĩa nữa! Và mức đồng thời truy cập của lớp ứng dụng là theo đơn vị hàng trăm, điều này sẽ làm giảm mức đồng thời của hệ thống ở một mức độ nhất định.
Để giải quyết vấn đề này, vào thời điểm này, chúng ta có thể lấy ID người dùng, ID sản phẩm và ID hoạt động săn hàng flash sale, v.v. mà người dùng gửi khi khởi tạo yêu cầu từ lớp cân bằng tải của hệ thống, trực tiếp truy cập thông tin hàng tồn kho trong bộ nhớ đệm thông qua kỹ thuật kịch bản Lua, v.v. Nếu hàng tồn kho của sản phẩm săn hàng flash sale nhỏ hơn hoặc bằng 0, hãy trực tiếp trả về thông báo sản phẩm đã bán hết cho người dùng, không cần xác thực từng lớp thông qua lớp ứng dụng nữa. Đối với kiến trúc này, chúng ta có thể tham khảo sơ đồ kiến trúc của hệ thống thương mại điện tử trong bài viết này (sơ đồ đầu tiên khi bắt đầu bài viết).
Lời kết
Nếu bạn cảm thấy bài dịch này có ích cho bạn, cho mình xin một một like :v.