thắc mắc Backend của 1 app check trạng thái Covid gần 100 triệu active users, làm sao để nó không lag

Còn tóm lại như này, tôi thấy a có 2 luận điểm.
1 là Ccu ( Concurent requests, tôi nghĩ ccu là concurent request. Chỗ này sai tự gạch), anh tính cả Cdn vào.
2 là ngồi tính resources cache cho 40tr items, tôi kết luận là anh rảnh vl ))
Xong, thích thì phản biện tiếp. Đọc cách anh dọa Ignore ng khác tôi thấy ngứa mắt nên vào vật nhau cho vui thôi ))
Còn cách tôi làm sẽ là như sau.
Cbi infrastructure sao cho cái backend nó bắt đầu từ vài records, xong theo dõi xem có bao nhiêu người dùng. Rồi scale nó lên, tạch đâu scale đó. Dùng microservices chia nhỏ nó ra.
Xong theo dõi insights từng chỗ một, ko ngồi đếm cua trong lỗ để làm gì cả.
À mấy năm nay tôi làm FE chứ ko làm BE

Sent from Samsung SM-G996B using vozFApp

katoshi said:

Đĩ mẹ , anh vứt cái đoạn tính number of items của cache của tôi đâu rồi anh chó điên?
Tôi nói là cache 40tr hết hả?


Mở to mắt chó lên nhìn cho kỹ. Đĩ mẹ, công đoạn tính và cân đối number of items của ngta rõ ràng thế mắt đui ko thấy à

Click to expand...

Bỏ đi.
Nửa đêm ngồi cãi nhau với mấy thanh niên này chi cho rách việc
Ng khác đọc vô họ tự hiểu.

Dựng 1 con cache mà ko tính nó cache bao nhiêu item, tốn bao nhiêu GB ram (mặc dù chỉ là ước lượng thôi) thì chắc chắn là thằng này xạo lol rồi. Đảm bảo với thím luôn.
Cứ ignore đi cho đời vui vẻ
Ai ko thích cách nc của mình cứ ignore mình thoải mái, đôi bên đỡ tốn thời gian.

katoshi said:

Đĩ mẹ , anh vứt cái đoạn tính number of items của cache của tôi đâu rồi anh chó điên?
Tôi nói là cache 40tr hết hả?


Mở to mắt chó lên nhìn cho kỹ. Đĩ mẹ, công đoạn tính và cân đối number of items của ngta rõ ràng thế mắt đui ko thấy à

Click to expand...

Number of items lại đi tính 40tr items rồi chia ra, thế tới hơn 40tr rồi ngồi khóc hay gì
Rồi còn rảnh đưa ra định lượng về mặt dữ liệu tính ra bytes rồi nhân chia
Việc tiếp cận vấn đề nó đã sai mẹ ngay từ đầu rồi còn gì?

Sent from Samsung SM-G996B using vozFApp

freedom.9 said:

Number of items lại đi tính 40tr items rồi chia ra, thế tới hơn 40tr rồi ngồi khóc hay gì
Rồi còn rảnh đưa ra định lượng về mặt dữ liệu tính ra bytes rồi nhân chia
Việc tiếp cận vấn đề nó đã sai mẹ ngay từ đầu rồi còn gì?

Sent from Samsung SM-G996B using vozFApp

Click to expand...

Anh ngu vậy.

Đề bài là 100 tr active users. Chưa cần quan tâm tới 100tr này là MAU hay DAU nhé.

ĐÉO AI KÊU THUÊ SERVER ĐỂ CACHE 40TR LIỀN ( Cái này là a tự biên tự diễn ra)
Hơn 40tr thì cứ theo lượng cơ sở là 4tr/1GB để tính ước lượng số RAM
VD: nếu 160tr thì 40GB, 80tr thì 20GB, 40tr thì 10GB ,nếu có 4tr thì tốn 1GB, nếu 1tr thì tốn ~250MB , cứ vậy anh ước lương.
Đó bây giờ a đo đạc monitor muốn bao nhiêu là biết số RAM ước lượng cho caching rồi a thuê server cho hợp lý và túi tiền.
Giờ tôi phải chỉ anh nhân chia à?

Anh đéo thấy ngta tính từ 1 item lên là. Cơ sở là: 1 item tốn 250bytes

Mai rô sơ vít.
Một con login, một con trả data về, một con tạo QR code, một con nhập liệu thêm một con làm NV sync Database nữa. Rồi chia vùng ra mà đặt server. l

freedom.9 said:

Còn tóm lại như này, tôi thấy a có 2 luận điểm.
1 là Ccu, anh tính cả Cdn vào.
2 là ngồi tính resources cache cho 40tr items, tôi kết luận là anh rảnh vl ))
Xong, thích thì phản biện tiếp. Đọc cách anh dọa Ignore ng khác tôi thấy ngứa mắt nên vào vật nhau cho vui thôi ))
Còn cách tôi làm sẽ là như sau.
Cbi infrastructure sao cho cái backend nó bắt đầu từ vài records, xong theo dõi xem có bao nhiêu người dùng. Rồi scale nó lên, tạch đâu scale đó. Dùng microservices chia nhỏ nó ra.
Xong theo dõi insights từng chỗ một, ko ngồi đếm cua trong lỗ để làm gì cả.
À mấy năm nay tôi làm FE chứ ko làm BE

Sent from Samsung SM-G996B using vozFApp

Click to expand...

Hệ thống cho 100tr user vn xài mà kêu bắt đầu từ vài record rồi tạch đâu scale đó )))

chắc mấy ông làm app cũng đang mang suy nghĩ này hay sao mấy nay dân kêu ca app delay quá trời.

mà anh kêu đi bid prj thì chắc là làm outsource rồi, chứ làm product làm gì ai đi bid prj bao giờ ))))

thôi về làm front end tiếp đi. Càng nói càng thấy ngu

Buonnguqua6 said:

Nhân vụ việc cái app Sổ Sức Khỏe Điện Tử của Bộ y tế do Viettel Software dev bị toàn dân ném gạch, ném đá vì quá lag dù mới chỉ tầm hơn 2 triệu users đã cài đặt

Spoiler

Mời nhìn rating hiện tại của app trên 2 nền tảng

Yêu cầu thực tế trong 6 tháng-1 năm tới chắc chắn là 60% dân số tức 60 triệu active users rồi (trừ người quá già không thể đi lại và trẻ em dưới 12 tuổi), éo ai muốn ở nhà cả
CCU thực tế chắc cỡ là 6 triệu, vì nếu về cái gọi là "cuộc sống bình thường mới" là dân đi vào cao ốc văn phòng, trường học, nhà hàng, quán cafe, rạp chiếu phim, gym, siêu thị, chợ, cửa ngõ các tỉnh thành... cũng phải quét mã

DB 100 triệu bản ghi,
có web frontend cho các nhân viên y tế tuyến cơ sở tìm kiếm và nhập liệu tình trạng tiêm mũi 1 ngày bao nhiêu vaccine gì, mũi 2, mũi 3, mũi 4, âm tính, dương tính, đã khỏi bệnh,...lên DB
Và sinh ra QR code tương ứng
Client app tính năng 1: show QR code và tình trạng của cá nhân tài khoản
Client app tính năng 2: quét mã QR code của người khác check tình trạng.
Dành cho chủ quán xá quét khách
Và những người không có smartphone có thể in QR code ra giấy

Chưa tính bài toàn khó hơn là lưu log lại tất cả những chỗ quét rồi gửi notification đến app của chính quyền để dễ bề truy vết F0 nhé

Tôi mạn phép hỏi các anh cao nhân Backend Dev trong đây bàn giải pháp như tech stack, băng thông và server cần cấu hình như thế nào, nếu dùng cloud như AWS thì cần gói bao nhiêu tiền 1 tháng ?

Click to expand...

Bỏ tư tưởng xài AWS nhé, viettel không xài hàng ngoài đâu. Mà hàng cloud của họ thì thế nào các ae tự biết

Câu chuyện đơn giản thế này:
Anh thiết kế 1 hệ thống, anh biết 100mil user xài rồi đó.
Để tối ưu, anh dựng cache ở 3 miền.
Giờ anh báo với sếp cần cbi để mua server, hay thuê gì đó. Sếp hỏi anh cần bao nhiêu để còn chuẩn bị mua.
Sau 1 hồi suy nghĩ anh bảo cần 1 con CPU xxx, Ram 16 gb, v.v….
Sếp hỏi anh vậy đủ ko? Tại sao là 16 GB mà ko phải 32, 64 v.v….
Các a trả lời kiểu gì? Em thích? Số đẹp? Hay hôm nay đề về?

Tôi lựa redis vì: persist xuống disk. Tự build LRU hay xài memcache thì ko có cái này, scale cũng kém hơn. (Memcache bản mới chắc có persist thì phải, ko nhớ), redis scale cũng tiện hơn lại theo mô hình master slave.

Giờ muốn tính thì phải ước lượng cache bao nhiêu item, size bao nhiêu trên redis.

Chính xác hơn thì insert thử 100k record, tôi lười nên tính vài cái cho vui.

Estimate số lượng thì tuỳ.
Miền bắc/nam đông dân thì cho size lớn, miền trung thưa thì size nhỏ hơn. Cái này tôi chưa tính, nhưng tạm cho 2 đầu Bắc/nam mỗi nơi 40tr dân. Miền trung cho 20 tr đi.
Kích thước thì 40mil/10gb theo đó mà lựa cho phù hợp.

Còn tôi ignore 1 ng, ko phải là ng ta ý kiến khác tôi mà ignore. Như thread này Tôi vẫn tranh luận với các bạn khác bt.

Tôi ignore khi thái độ, ngôn từ của họ với tôi làm tôi khó chịu. Đơn giản mà. Lên đây để giải trí.
Ng ta làm mình khó chịu thì lơ đi. Việc quái gì phải cãi nhau cho mệt.
Thanh niên freedom kia, vô là công kích mình. Ok tiễn. Ko tiếp

Mình code gà. Nhưng theo mình thì nên sử dụng VPS cho dễ nâng cấp, mở rộng tài nguyên nếu cần. Rồi sau đó là chia ra nhiều VPS tương ứng mỗi thành phố 1 VPS cho nó linh hoạt, dễ quản lý

Fire Of Heart said:

Bỏ đi.
Nửa đêm ngồi cãi nhau với mấy thanh niên này chi cho rách việc
Ng khác đọc vô họ tự hiểu.

Dựng 1 con cache mà ko tính nó cache bao nhiêu item, tốn bao nhiêu GB ram (mặc dù chỉ là ước lượng thôi) thì chắc chắn là thằng này xạo lol rồi. Đảm bảo với thím luôn.
Cứ ignore đi cho đời vui vẻ
Ai ko thích cách nc của mình cứ ignore mình thoải mái, đôi bên đỡ tốn thời gian.

Click to expand...

Đúng rồi, system design nào cũng phải tính toán Ram, dung lượn ổ đĩa cần có. Dựa trên ước lượng ban đầu. Cache thì có thể ap dụng qui tắc 80/20. 80% user truy cập vào 20% resource thường xuyên nhất.

Sent using vozFApp

Tôi chỉ cần 1 ông dev trực tiếp làm cái backend này vào giới thiệu 1 số nghiệp vụ thôi, chứ tất cả phương pháp tối ưu perf chỉ là "thầy bói xem voi" khi ko rõ nghiệp vụ cụ thể.

luckyted said:

Mình code gà. Nhưng theo mình thì nên sử dụng VPS cho dễ nâng cấp, mở rộng tài nguyên nếu cần. Rồi sau đó là chia ra nhiều VPS tương ứng mỗi thành phố 1 VPS cho nó linh hoạt, dễ quản lý

Click to expand...

VPS thì sao quản lí tập trung được? Cái server thế nào cũng phải nằm ở Hà Nội, trung tâm đầu não của cả nước

Hôm trước tôi vọc thử cái app SSKĐT, thấy nó gọi api vô tội vạ vl ra. Có lúc get 2 cái api y chang nhau cùng một lúc chắc để tăng traffic cho dễ report với mấy sếp đây mà

Doge Coin said:

Hệ thống cho 100tr user vn xài mà kêu bắt đầu từ vài record rồi tạch đâu scale đó )))

chắc mấy ông làm app cũng đang mang suy nghĩ này hay sao mấy nay dân kêu ca app delay quá trời.

mà anh kêu đi bid prj thì chắc là làm outsource rồi, chứ làm product làm gì ai đi bid prj bao giờ ))))

thôi về làm front end tiếp đi. Càng nói càng thấy ngu

Click to expand...

Mình cũng thấy tn đó máy móc và bảo thủ vl.
Cách thanh niên đó bắt đầu lượng nhỏ users và monitor tạch đâu scale đó, thiếu đau đắp đó. Là cách ĐÚNG trong trường:

• Ko hề biết lượng users khoảng nhiêu
• Chưa có kinh nghiệm giải quyết và cũng chưa biết các egde case sẽ gặp là gì nên chọn build dần dần.
• Chưa biết API nào sẽ đc gọi nhiều xài nhiều.

Chứ đây là biết rõ rồi. Đéo tính ước lượng thì tn đó tính tay không bắt giặc.
Giống như đánh trận, địch dàn trận 100tr quân. Anh này thấy thế kêu:

• thôi chỉ cần huy động trong thành tổng 500 ngàn quân đánh trước.
• Đánh thua thì lại tính tiếp, thua thì tuyển thêm quân, chứ lên kế hoạch dự trù và kết hoạch tuyển/huy động quân giờ triều đình CHỬI là tốn quân lương.

katoshi said:

Mình cũng thấy tn đó máy móc và bảo thủ vl.
Cách thanh niên đó bắt đầu lượng nhỏ users và monitor tạch đâu scale đó, thiếu đau đắp đó. Là cách ĐÚNG trong trường:

• Ko hề biết lượng users khoảng nhiêu
• Chưa có kinh nghiệm giải quyết và cũng chưa biết các egde case sẽ gặp là gì nên chọn build dần dần.
• Chưa biết API nào sẽ đc gọi nhiều xài nhiều.

Chứ đây là biết rõ rồi. Đéo tính ước lượng thì tn đó tính tay không bắt giặc.
Giống như đánh trận, địch dàn trận 100tr quân. Anh này thấy thế kêu:

• thôi chỉ cần huy động trong thành tổng 500 ngàn quân đánh trước.
• Đánh thua thì lại tính tiếp, thua thì tuyển thêm quân, chứ lên kế hoạch dự trù và kết hoạch tuyển/huy động quân giờ triều đình CHỬI là tốn quân lương.

Click to expand...

1) Tôi có kêu ko biết lượng users bao nhiêu đâu? vấn đề anh tiếp cận là anh ngồi đếm bytes của 1 record rồi nhân lên. Con nít nó cũng đếm được thôi, mà anh có biết chính xác dữ liệu ở 1 record là gì? business như nào? cần cache cái gì mà cho ra con số rồi ngồi đếm? Nếu anh đếm ko được thì cách tốt nhất là đừng đếm. Xong dữ liệu nó đi vào hệ thống liên tục rồi anh đếm cũng đâu có sao? Việc của anh là làm ra 1 hệ thống có thể scale lên được khi cần thiết, đề phòng trường hợp xấu nhất có thể xảy ra thì cần làm cái gì. Checklist cần phải làm là gì chứ tự dưng đi đếm 1 lượng dữ liệu ko có thật thì design cái gì
2) Anh kia cố tình ignore tôi vụ CDN nữa kìa, đếm cả request tải html/css/js/ json files tính vào CCU thì tôi cũng hiểu rồi ko cần nói gì thêm

phtdce said:

Tôi chỉ cần 1 ông dev trực tiếp làm cái backend này vào giới thiệu 1 số nghiệp vụ thôi, chứ tất cả phương pháp tối ưu perf chỉ là "thầy bói xem voi" khi ko rõ nghiệp vụ cụ thể.

Click to expand...

Các anh ấy chưa rõ nghiệp vụ cụ thể, chưa rõ cái cần cache là gì mà ngồi đếm số bytes như thật. Rồi áp dụng quy tắc 80 20 như ai với software là hiểu rồi.

Niels Henrik Abel said:

Đúng rồi, system design nào cũng phải tính toán Ram, dung lượn ổ đĩa cần có. Dựa trên ước lượng ban đầu. Cache thì có thể ap dụng qui tắc 80/20. 80% user truy cập vào 20% resource thường xuyên nhất.

Sent using vozFApp

Click to expand...

Quy tắc gì nữa thế này, cho tôi 1 cái course hay 1 cái bài viết về quy tắc này để tôi áp dụng với. Hay toàn kiểu tự nghĩ ra qui tắc rồi viết vào thế, cũng kiểu như định lượng 1 item cache là 250 bytes vậy à

Fire Of Heart said:

Câu chuyện đơn giản thế này:
Anh thiết kế 1 hệ thống, anh biết 100mil user xài rồi đó.
Để tối ưu, anh dựng cache ở 3 miền.
Giờ anh báo với sếp cần cbi để mua server, hay thuê gì đó. Sếp hỏi anh cần bao nhiêu để còn chuẩn bị mua.
Sau 1 hồi suy nghĩ anh bảo cần 1 con CPU xxx, Ram 16 gb, v.v….
Sếp hỏi anh vậy đủ ko? Tại sao là 16 GB mà ko phải 32, 64 v.v….
Các a trả lời kiểu gì? Em thích? Số đẹp? Hay hôm nay đề về?

Tôi lựa redis vì: persist xuống disk. Tự build LRU hay xài memcache thì ko có cái này, scale cũng kém hơn. (Memcache bản mới chắc có persist thì phải, ko nhớ), redis scale cũng tiện hơn lại theo mô hình master slave.

Giờ muốn tính thì phải ước lượng cache bao nhiêu item, size bao nhiêu trên redis.

Chính xác hơn thì insert thử 100k record, tôi lười nên tính vài cái cho vui.

Estimate số lượng thì tuỳ.
Miền bắc/nam đông dân thì cho size lớn, miền trung thưa thì size nhỏ hơn. Cái này tôi chưa tính, nhưng tạm cho 2 đầu Bắc/nam mỗi nơi 40tr dân. Miền trung cho 20 tr đi.
Kích thước thì 40mil/10gb theo đó mà lựa cho phù hợp.

Còn tôi ignore 1 ng, ko phải là ng ta ý kiến khác tôi mà ignore. Như thread này Tôi vẫn tranh luận với các bạn khác bt.

Tôi ignore khi thái độ, ngôn từ của họ với tôi làm tôi khó chịu. Đơn giản mà. Lên đây để giải trí.
Ng ta làm mình khó chịu thì lơ đi. Việc quái gì phải cãi nhau cho mệt.
Thanh niên freedom kia, vô là công kích mình. Ok tiễn. Ko tiếp

Click to expand...

Thôi anh ạ, tranh luận ko được thì chạy đi Ignore người khác. Đã dám vào tranh luận thì dám vào làm cho ra vấn đề, chứ cãi nhau ko được lại chạy đi Ignore người khác thì thằng nào làm chả được

freedom.9 said:

Quy tắc gì nữa thế này, cho tôi 1 cái course hay 1 cái bài viết về quy tắc này để tôi áp dụng với. Hay toàn kiểu tự nghĩ ra qui tắc rồi viết vào thế, cũng kiểu như định lượng 1 item cache là 250 bytes vậy à

Click to expand...

thím lên đây nhé
https://www.educative.io/courses/grokking-the-system-design-interview/m2ygV4E81AR

Tôi ignore khi thái độ, ngôn từ của họ với tôi làm tôi khó chịu.
Muốn tranh luận thì trc tiên hãy học cách tôn trọng ng khác

Vấn đề đếm request đã nói ở mấy page khác và đã chốt với bác kia rồi. Đéo ai chạy cả, tự dưng ở đâu chui ra chửi bới này nọ thì biến đi, không cần phải khích.

Bị ignore quê quá xong giờ quay ra khích tướng ng khác
Thích thì cứ réo tiếp đi

freedom.9 said:

1) Tôi có kêu ko biết lượng users bao nhiêu đâu? vấn đề anh tiếp cận là anh ngồi đếm bytes của 1 record rồi nhân lên. Con nít nó cũng đếm được thôi, mà anh có biết chính xác dữ liệu ở 1 record là gì? business như nào? cần cache cái gì mà cho ra con số rồi ngồi đếm? Nếu anh đếm ko được thì cách tốt nhất là đừng đếm. Xong dữ liệu nó đi vào hệ thống liên tục rồi anh đếm cũng đâu có sao? Việc của anh là làm ra 1 hệ thống có thể scale lên được khi cần thiết, đề phòng trường hợp xấu nhất có thể xảy ra thì cần làm cái gì. Checklist cần phải làm là gì chứ tự dưng đi đếm 1 lượng dữ liệu ko có thật thì design cái gì
2) Anh kia cố tình ignore tôi vụ CDN nữa kìa, đếm cả request tải html/css/js/ json files tính vào CCU thì tôi cũng hiểu rồi ko cần nói gì thêm


Các anh ấy chưa rõ nghiệp vụ cụ thể, chưa rõ cái cần cache là gì mà ngồi đếm số bytes như thật. Rồi áp dụng quy tắc 80 20 như ai với software là hiểu rồi.

Quy tắc gì nữa thế này, cho tôi 1 cái course hay 1 cái bài viết về quy tắc này để tôi áp dụng với. Hay toàn kiểu tự nghĩ ra qui tắc rồi viết vào thế, cũng kiểu như định lượng 1 item cache là 250 bytes vậy à

Click to expand...

80 20 rule phổ biến mà.
https://dzone.com/articles/applying-8020-rule-software
https://www.linkedin.com/pulse/8020-rule-software-development-chong-yu

Sent using vozFApp

Fire Of Heart said:

Query 1:

Code:

Select qrcode from table tbl_qrcode where user_id = xxxx

Vậy ta sẽ có 1 table với 2 col: user_id và qrcode. (Giả sử ta lưu lại qr vào db để tránh việc phải gen 1 qr code nhiều lần).

Sample qr code:

Code:

D9LOgcTFAS1MeC3kD4J+5PmAW5C4mOrPcbwbynsY6GEuGNkpe/dwIM5cr0MS/a+LT1y9z+8sKJA9UaPZTmYJwQ==|Nguyễn Ánh Ngọc| Status | 1234565764635353252342235234324232

(Cái này tôi lấy từ mẫu đi đường, xóa mấy cái ko cần thiết, chứ cũng chả biết các anh dev kia làm qr code có cái gì)
Phần phía đầu là chữ ký điện tử, phần sau là tên + 1 số thông tin đi kèm.

Vào đâu đó khoảng 150 char
Chuỗi này tôi có thể encode lại hoặc giữ nguyên thì tùy:

Code:

RDlMT2djVEZBUzFNZUMza0Q0Sis1UG1BVzVDNG1PclBjYndieW5zWTZHRXVHTmtwZS9kd0lNNWNyME1TL2ErTFQxeTl6KzhzS0pBOVVhUFpUbVlKd1E9PXxOZ3V54buFbiDDgW5oIE5n4buNY3wgU3RhdHVzIHwgMTIzNDU2NTc2NDYzNTM1MzI1MjM0MjIzNTIzNDMyNDIzMg==

Nếu encode Khoảng 200 byte.
UserID -> (Dùng cmnd/cccd/passport làm userid). Kích thước cccd là 12 số. Passport thì bỏ qua đi, case này chắc hiếm.

Đẩy vào cache dạng key (20 byte) - value (200 byte)

Giả sử dùng redis:

Code:

docker run -it redis bash
redis-server &
redis-cli
INFO memory

used_memory:871864 // Ban đầu

used_memory:872112 // insert 1 cặp key-value
--> 250 byte

used_memory:872328 // insert cặp thứ 2
--> 216 byte

(Ở đây mình dùng qrcode chưa encode, nếu encode lại thì có thể sẽ lớn hơn 1 chút, key là 1 chuỗi 12 số)

Giả sử mỗi cặp là 250 byte đi
Cache khoảng 40 mil record -> 10Gbs!

Cái này ước lượng thôi chứ cũng chưa chính xác lắm đâu.

Click to expand...

Nhớ mấy bài mẫu của Grokking System design