Bàn luận về scalability, từ case study VFF

scale
architecture

(doanguyen) #1

Dev chat bàn luận về scalability

Hello mọi người,

Không biết ở DNH có ai làm fullstack mà quan tâm tới scalability không? Bài toán bán vé của VFF có đề bài đưa ra bạn có thể đọc từ:

[1] https://laodong.vn/the-thao/vff-giai-thich-viec-chi-ban-15000-ve-online-tran-viet-nam-philippines-644127.ldo

Vì lượng truy cập mạng quá lớn, có thời điểm lên đến 130.000 người cùng vào một lúc để mua vé.

[2] http://webthethao.vn/ttk-vff-le-hoai-anh-phuong-thuc-ban-ve-online-tao-su-cong-bang-cho-nguoi-ham-mo-20181130114857388.htm

Theo thống kê từ VFF, có tổng số hơn 250.000 địa chỉ IP truy cập vào các tranng bán vé online với 1.7 triệu lượt truy cập.

Bỏ qua các yếu tố chính trị ngoài lề, nếu là dev chân chính thì stack (backend languages, architechture, …) bạn chọn là gì? làm sao overcome được những vấn đề kể trên?

Update 1:
Một vài ý kiến chưa suy nghĩ kỹ của m:

Đặc điểm việc mua bán vé của VFF là:

  1. Highload trong 1 thời gian ngắn nên không cần phải xây dựng 1 infrastructure riêng cho nó.
  2. Việc thanh toán qua third-party nên payment processing không phải lo lắng.
  3. Trang vebongdaonline.vn đang không truy cập được nên mình không rõ ngôn ngữ họ sử dụng là gì. Nhưng từ trang chủ VFF, có thể đoán họ dùng PHP (5.4 khá outdated) cùng Apache Web Service.

Vì vậy mình nghĩ có thể giảm tải bằng 1 trong những phương pháp sau:

  1. Sử dụng CDN để giảm tải về cả băng thông lẫn tài nguyên máy tính.
  2. Static caching những trang không thay đổi thường xuyên. Điều này giảm tối đa SQL connections đến DB Service. Hoặc thậm chí routing những trang đã cached đến 1 instance khác.
  3. Thực tế thì trong 1.7M requests chỉ có ~250k request có liên quan tới thanh toán, do đó, có thể thiết kế riêng 1 service để phục vụ những request này.
  4. Nếu xây dựng từ đầu thì tránh chọn những ngôn ngữ có blocking IO (PHP/Python, Ruby,…) cho những application có highload nếu muốn giảm thiểu tối đa server costs. Hoặc ngược lại, nếu đã chọn những ngôn ngữ trên thì buộc phải tăng thêm số lượng server.
  5. Your comments?

(Chẵn) #2

Anh có thể đưa ra những giải pháp của riêng anh để mọi nguời cùng thảo luận và đóng góp ý kiến được không nhỉ?


(doanguyen) #3

updated. See above.
@@@@@@@@@@@@@@@@@@@@


(*grab popcorn*) #4

Mình có vài góp ý thế này :kissing: Kinh nghiệm mình về cái này không nhiều nên có gì sai mọi người góp ý nhé.

Việc mua vé cần update DB phải nhanh. Vì nhiều khi xảy ra lỗi gì đó mà thông báo không thành công. Nhưng DB xử lý kịp thời để add vào DB rồi, khi người dùng kiểm tra vé, mà vé lại xuất hiện thì người dùng cũng kiểu: “Oh, ngon”.
Thế nên có thể tách DB ra 2 DB, 1 DB được optimize để ghi và 1 DB chuyên để đọc, áp dụng pattern CQRS.
Ngoài ra có thể tăng UX bàng cách thông báo 1 tn là bạn mua vé thành công (mặc dù bị báo không thành công trên web).

Để giảm tải server, thì bên server có thể build một queue để xử lý dần. Áp dụng thêm command pattern thì có thể dễ dàng logging lại các sự kiện đc add vào queue và lấy ra xử lý. Dễ audit sau này. Tuy nhiên queue thì có thể bị chậm. Tuy nhiên mình nghĩ vậy đỡ hơn là bị sập luôn server.


(Hung) #5


(from FTS)


(doanguyen) #6

Mostly agreed!

Mình không rõ áp dụng CQRS vào trường hợp này làm gì? Theo mình hiểu thì CQRS chỉ hữu dụng khi phải store các events/states (trong state machines) mà tất cả các event/state phải được lưu trữ, trong trường hợp này thì mình cần phải lưu state/event gì nhỉ?

Cả queue nữa, m hiểu là họ dùng 3rd party payment nên phần payment processing coi như là không phải bận tâm rồi.


(doanguyen) #7

Như mình đã nói, ở đây chỉ bàn về technical details, mọi ch khác không thuộc về team tech. :slight_smile:


(*grab popcorn*) #8

Event Sourcing mới lưu state với event :3
CQRS đơn giản tách DB ra thôi (tất nhiên là có sync qua sync lại nữa).
Hai thằng này thường đi cặp với nhau nhưng là 2 pattern khác nhau.

Còn phần queue thì form tách thành nhiều phần. Mỗi lần xong phải chờ xử lý (theo nhũng gì mình theo dõi được) thì làm một queue xử lý dần. Vừa log lại được ng dùng khó khăn hay bước nào xử lý lâu thì có thể cải thiện về sau.


(doanguyen) #9

Thank bạn :slight_smile: trước giờ m có đọc về state machine trên 1 instance nên cứ nghĩ CQRS là implementation của Event Sourcing :((

Còn phần queue thì mình chưa thấy có mục đích chính là gì vì việc postprocessing (payment verification thuộc về 3rd party rồi).


83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?