4.9K 252 25

Đã đăng vào thg 6 28, 2:48 CH 15 phút đọc

2.6K

Bên trong hệ thống bán vé cho ngoại hạng anh sẽ có những gì - Khám phá hệ thống Seatgeek

Chắc hẳn anh em đã từng dùng hoặc biết đến một hệ thống bán vé để mua vé các show ca nhạc (có ai hold vé đợt blackpink không =)) ) hoặc vé xem các trận của đội tuyển bóng đá Việt Nam rồi nhỉ. Để có thể tạo ra một nền tảng mà mọi người có thể đặt vé trược tuyến như vậy thì chúng ta sẽ cần đối mặt với rất nhiều bài toán khó để có thể chịu tải cho lượng đặt vé ồ ạt trong các sự kiện lớn

Screenshot from 2024-06-28 21-27-36.png

Hôm nay cùng sydexa.com tìm hiểu về Seatgeek, một trong những nền tảng bán vé sự kiện trực tuyến hàng đầu thế giới, phục vụ hàng triệu người dùng trên toàn cầu, là nơi bán vé cho ngoại hạng anh, các clb lớn như Liverpool or Manchester City. SeatGeek đã xử lý thành công hàng trăm nghìn yêu cầu mỗi phút mà không gặp sự cố về hiệu suất. Cùng tìm hiểu xem họ đã làm như nào nha!!!

Chúng mình có tạo Group cho các bạn cùng chia sẻ và học hỏi về thiết kế hệ thống nha 😄😄😄

Các bạn tham gia để gây dựng cộng đồng System Design Việt Nam thật lớn mạnh nhé 😍😍😍

Cộng Đồng System Design Việt Nam: https://www.facebook.com/groups/sydexa

Kênh TikTok: https://www.tiktok.com/@sydexa.com

1. Các thách thức

Lượng truy cập tăng đột biến: Trong các sự kiện lớn, Seatgeek phải đối mặt với lượng truy cập khổng lồ trong thời gian ngắn, đòi hỏi hệ thống ổn định tránh bị quá tải. Trong các tình huống này thì autoscaling sẽ không thể đủ nhanh chóng đáp ứng được kịp thời, khi lượng truy cập tăng đột biến, autoscaling sẽ mất quá nhiều thời gian để nhận ra và thêm tài nguyên cho hệ thống

Vấn đề mua vé đồng thời: Nhiều người có thể cố gắng đặt cùng một chỗ ngồi cùng lúc, đòi hỏi hệ thống phải có cơ chế xử lý để đảm bảo tính công bằng và tránh xung đột.

Chống gian lận: Hệ thống cần có các biện pháp bảo mật mạnh mẽ để ngăn chặn các hoạt động gian lận như mua vé số lượng lớn để bán lại với giá cao hơn.

Tối ưu hóa trải nghiệm người dùng: Hệ thống cần phải dễ sử dụng, nhanh chóng và đáng tin cậy để thu hút và giữ chân người dùng.

2. Virtual waiting room

Và một giải pháp được các kỹ sư tại Seatgeek sử dụng đó chính là phòng chờ ảo (Virtual waiting room)

Hãy tượng tượng 11h sẽ là đợt mở bán vé cho show ca nhạc của Sơn Tùng MTP. Nhưng khi bạn vào sớm hơn thời gian đó lúc 10h50, bạn sẽ được đưa vào một phòng chờ ảo này và đợi đợt mở bán. Khi đợt mở bán bắt đầu, bạn sẽ được xếp vào hàng đợi để được mua vé. Bài toán của Seatgeek là cần xử lý hàng đợi này nhanh nhất có thể

Virtual Waiting Room có hai chế độ hoạt động chính: chế độ chặn toàn bộ truy cập khi sự kiện chưa bắt đầu và chế độ xếp hàng khi sự kiện đã diễn ra. Khi sự kiện bắt đầu, họ sẽ được đưa vào hàng đợi để vào khu vực bảo vệ protected zone - nơi mà mọi người có thể mua vé

Hàng đợi đảm bảo tính công bằng, ưu tiên người đến trước. Trong quá trình mua vé, nếu gặp sự cố như thẻ bị từ chối hoặc đổi ý vì giá vé, bạn có thể bỏ và nhường cơ hội cho người khác. Phòng chờ ảo sẽ tiếp nhận lượng truy cập khổng lồ và điều tiết, đảm bảo hệ thống xử lý ổn định.

3. Giảm tải cho Backend

Fastly là một nền tảng điện toán biên (edge computing) mạnh mẽ, đóng vai trò quan trọng trong việc quản lý và bảo vệ các trang bán vé có lưu lượng truy cập cao. Trong trường hợp này, Fastly hoạt động như một lớp trung gian giữa người dùng và máy chủ backend, đảm nhận việc xử lý các yêu cầu, xác thực truy cập và điều hướng người dùng.

Để giảm tải cho Backend, Fastly sẽ hoạt động như một bộ nhớ đệm, lưu trữ trạng thái sự kiện trên Edge Datastore. Khi sự kiện chưa diễn ra, yêu cầu từ người dùng sẽ được CDN xử lý, kiểm tra trạng thái và chuyển hướng đến phòng chờ ảo, giúp giảm tải đáng kể cho Backend.

4. Hệ thống hoạt động như nào nhỉ ???

1. Trạng thái Phong tỏa (Blockade):

Ban đầu, khi chưa mở bán vé, khu vực được bảo vệ ở trạng thái phong tỏa, không cho phép bất kỳ truy cập nào.

Khi người dùng cố gắng truy cập trang bán vé, Fastly (một mạng lưới phân phối nội dung - CDN) sẽ xác định trạng thái protected zone bị phong tỏa và chuyển hướng người dùng đến trang phòng chờ ảo.

Toàn bộ quá trình này diễn ra trên Fastly, không cần giao tiếp với máy chủ backend. Giúp giảm gánh nặng cho server

2. Mở bán và cuộc đua bắt đầu:

Ngay khi thời điểm mở bán vé được công bố, khu vực được bảo vệ sẽ chuyển sang trạng thái điều tiết, đồng thời một hệ thống hàng đợi ảo được thiết lập để quản lý lượng truy cập lớn. Mỗi người dùng mong muốn sở hữu tấm vé sẽ được Fastly cấp một mã visitor token duy nhất, đóng vai trò như "tấm vé" để tham gia vào hàng đợi ảo này.

3. Chạy đua vào hàng đợi:

Tại trang xếp hàng, một đoạn mã JavaScript kích hoạt để mở kết nối WebSocket đến API gateway cho phép giao tiếp hai chiều giữa trình duyệt và máy chủ.

Visitor vừa được cấp sẽ được gửi qua kết nối WebSocket đã thiết lập đến API gateway. API gateway nhận visitor token và thực hiện việc đăng ký người dùng vào hàng đợi ảo. API gateway sẽ liên kết một mốc thời gian (chính là thời điểm người dùng vào hàng đợi) với visitor token, cặp thông tin visitor token và mốc thời gian này sau đó được lưu trữ cẩn thận vào DynamoDB - một cơ sở dữ liệu được thiết kế để xử lý lượng lớn dữ liệu một cách hiệu quả.

Bằng cách ghi lại thời điểm tham gia hàng đợi, hệ thống đảm bảo tính công bằng và minh bạch, cho phép những người đến trước được phục vụ trước, đúng theo nguyên tắc "ai đến trước được phục vụ trước".

Hình ảnh minh họa dữ liệu cặp visitor token và mốc thời gian được lưu trong dynamoDB :

4. Trao đổi Visitor token và bắt đầu mua vé

Một Exchanger function chạy định kỳ để "xả" hàng đợi ảo. Nó tìm kiếm tất cả visitor token đã đăng ký nhưng chưa được cấp access token tương ứng và tiến hành trao đổi chúng.

Khi quá trình trao đổi diễn ra, cơ sở dữ liệu DynamoDB được cập nhật. Đặc biệt, thay đổi dữ liệu này được truyền trực tiếp (stream) đến Dynamo Stream, giúp nắm bắt các thay đổi dữ liệu trong DynamoDB một cách gần như tức thời.

Lamda notifier lắng nghe các thông báo từ Dynamo Stream. Khi nhận được thông báo về việc cập nhật access token, hàm này sẽ tận dụng kết nối WebSocket đã thiết lập trước đó để gửi access token mới này trực tiếp đến người dùng. Người dùng không cần gửi yêu cầu access token một cách chủ động, mà hệ thống tự động cung cấp khi access token sẵn sàng.

5. Đến lượt, đặt vé thôi nào!!!

Với access token, người dùng có thể truy cập vào trang mua vé và tiến hành đặt mua thanh toán,....

Acccess token sẽ tự động được gửi kèm và xác thực ngay tại Fastly CDN mà không cần thông qua máy chủ backend, giúp tăng tốc độ xử lý và đảm bảo tính bảo mật.

Toàn bộ quy trình này như một "người gác cổng" thông minh, chỉ cho phép những người dùng thực sự có nhu cầu mua vé vào khu vực bán vé, đồng thời phát hiện và ngăn chặn các hành vi đáng ngờ, giúp quá trình mua vé diễn ra an toàn và minh bạch hơn.

5. Thuật toán Leadky Bucket được áp dụng

Hệ thống sử dụng mô hình "leaky bucket" (xô rò rỉ) để kiểm soát lưu lượng truy cập. Mỗi khu vực được bảo vệ, sẽ có một "xô" riêng với tốc độ "rò rỉ" (tức là tốc độ cho phép yêu cầu đi qua) khác nhau.

Khi có yêu cầu truy cập, hệ thống sẽ kiểm tra "xô" tương ứng với khu vực đó. Nếu "xô" đã đầy, yêu cầu sẽ được chuyển hướng đến trang xếp hàng ảo. Nếu "xô" chưa đầy, hệ thống sẽ tạo ra một access token ngay lập tức để cho phép người dùng truy cập vào protected zone để tiến hành mua vé.

Để thực hiện việc này, hệ thống sử dụng một hàm Lambda đơn giản được viết bằng ngôn ngữ Go giúp giao tiếp và lưu thông tin vào Fastly (CDN), đặc biệt là kiểm soát bộ nhớ đệm. Khi "xô" chứa yêu cầu bị đầy, hàm Lambda sẽ báo hiệu cho Fastly và lưu thông tin này vào bộ nhớ đệm trong một khoảng thời gian. Trong thời gian đó, các yêu cầu mới sẽ được Fastly xử lý dựa trên thông tin từ bộ nhớ đệm mà không cần gọi lại máy chủ backend.

6. Tại sao lại là Lambda???

SeatGeek sử dụng Lambda cho hệ thống phòng chờ ảo vì các lý do sau:

Tránh hiệu ứng domino (cascade effects): Nếu phòng chờ ảo chạy cùng môi trường với các sản phẩm nó bảo vệ, khi môi trường gặp sự cố, cả phòng chờ ảo cũng sẽ bị ảnh hưởng, dẫn đến việc không thể bảo vệ được hệ thống. Chạy phòng chờ ảo trên Lambda tách biệt nó với môi trường sản phẩm, giúp giảm thiểu rủi ro này.
Khởi tạo và mở rộng dễ dàng: AWS Lambda cho phép triển khai nhanh chóng môi trường từ đầu và dễ dàng mở rộng quy mô dựa trên lưu lượng truy cập, đáp ứng nhu cầu thay đổi.
Tính linh hoạt: Lambda là một dịch vụ điện toán không máy chủ (serverless), có nghĩa là Seatgeek chỉ trả tiền cho thời gian thực tế mà sử dụng tài nguyên, không cần quản lý cơ sở hạ tầng, giúp tiết kiệm chi phí và tăng tính linh hoạt.

Việc sử dụng Lambda giúp SeatGeek đảm bảo tính ổn định và khả năng mở rộng cho hệ thống phòng chờ ảo, đồng thời giảm thiểu rủi ro và tối ưu hóa chi phí.

7. Thách thức đồng bộ với Fastly

Hệ thống phòng chờ ảo của SeatGeek phải đối mặt với thách thức đồng bộ dữ liệu giữa bộ nhớ đệm (edge dictionary) trên Fastly và cơ sở dữ liệu chính DynamoDB. Để giải quyết vấn đề này, họ sử dụng một giải pháp được gọi là transactional outbox pattern giúp đơn giản hóa kiến trúc hệ thống bằng cách tránh việc sử dụng các cơ chế đồng bộ phức tạp khác.

Cách hoạt động sẽ như sau

Ghi dữ liệu vào DynamoDB: Khi có yêu cầu thay đổi trạng thái của khu vực được bảo vệ (ví dụ: từ chặn sang cho phép), thông tin này được ghi trực tiếp vào DynamoDB trong một thao tác duy nhất.
Truyền trực tiếp thay đổi: Thay đổi dữ liệu này được truyền trực tiếp (streaming) thông qua Dynamo Stream, một tính năng của DynamoDB cho phép nắm bắt các thay đổi dữ liệu gần như tức thời.
Hàm Lambda xử lý: Một hàm Lambda sẽ "lắng nghe" các thay đổi từ Dynamo Stream và thực hiện việc cập nhật tương ứng vào edge dictionary trên Fastly. Nếu việc cập nhật không thành công, hàm Lambda sẽ thử lại cho đến khi thành công.