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

tnv218 said:

Sao ko để mỗi tỉnh 1 db, số người di chuyển qua lại giữa các tỉnh rất thấp, phần giải thuật chắc cũng quan trọng.

Click to expand...

Mỗi tỉnh 1 db vậy thì mỗi tỉnh lại phải set up infra để handle network, connection đủ cho dân 1 tỉnh sao. Cái đó viễn vông quá trong khi sử dụng sẵn infra ở 2 đầu đất nước thì latency cũng ko kém bao nhiêu và có infra sẵn.

Mình thấy bài toán này cũng đơn giản, không có gì phức tạp lắm, mình có vài ý
(1) Nhân dân sử dụng app, chỉ có login, check status, và thêm chức năng yêu cầu hỗ trợ
(2) Người quản lý/ nhập liệu dữ liệu tiêm chủng quốc gia
Mình sẽ tách ra 2 database cho 2 đối tượng trên, cái (1) là cái CCU nhiều, và nó không có query filter gì phức tạp, nó chỉ có chức năng read. Vậy thì kiếm db nào hỗ trợ read tốt, bỏ C, giữ AP, và read kiểu key-value cũng được. Mình suggest cassandra. Khéo cũng không cần cache luôn ấy :v

cái số (2), database quản lý, chủ yếu cho cán bộ nhập liệu, filter, truy vấn, CCU không nhiều. dùng SQL RDBMS.
Hàng tối thêm con batch để sync data từ con (2) sang (1). Việc sync này mình thấy chấp nhận được. Không cần tới mức vừa tiêm 10h sáng, thì 10h30 phải có trên app (1) ngay.
Trường hợp các nhà khoa học cần data, để phân tích, thống kê, có thể thiết kế db (2) ETL sang 1 con db thứ 3 nữa.

Nếu yêu cầu thực sự chỉ là kiểm tra xem đã tiêm chưa thì sao phải cần request đến server với DB nhiều thế các thím?
Tình trạng tiêm của mỗi người chỉ thay đổi max là 2 lần theo đúng 1 chiều: chưa tiêm -> 1 mũi -> 2 mũi. Vậy thì cần gì lần nào cũng phải mò lên server để check?

Giải pháp đơn giản hơn là mô phỏng lại đúng như cấp giấy hiện tại nhưng làm digital: Mỗi lần tiêm thì sign cái số căn cước của mỗi người với tình trạng tiêm. Đến lúc scan thì cái app decrypt lại, cán bộ kiểm tra lại đảm bảo match với số căn cước là xong chứ nhỉ?

-RedSky.v2- said:

Cái API get status chích trên SSKĐT nó query có field name nữa. Đợt trước nhập liệu tên bị sai dấu query ko ra Mới fix đợt update này. Chả hiểu thiên tài nào nghĩ ra query bằng tên.

Click to expand...

Chắc sợ trùng số CMND cũ đấy mai fen.

mikloa02 said:

Chắc sợ trùng số CMND cũ đấy mai fen.

Click to expand...

Thì làm 1 cái enum idType là xong mà bọn nó nghĩ ra cách thiên tài vl.

znvdicrd said:

Nếu yêu cầu thực sự chỉ là kiểm tra xem đã tiêm chưa thì sao phải cần request đến server với DB nhiều thế các thím?
Tình trạng tiêm của mỗi người chỉ thay đổi max là 2 lần theo đúng 1 chiều: chưa tiêm -> 1 mũi -> 2 mũi. Vậy thì cần gì lần nào cũng phải mò lên server để check?

Click to expand...

Cập nhật tình trạng dương tính, âm tính nữa
Tiêm xong 2 mũi về bình thường mới cũng dương tính bỏ mẹ ra
Cho nó vào nơi đông người để lây lan thêm số ca à
Phải xác định bình thường mới sau tiêm vẫn ngày 20.000 ca nhiễm 1 ngày như Anh Quốc hiện tại nhé
Mà 20k ca nhiễm 1 ngày thì éo công an, dân phòng nào có thể quản lý được F0 đâu. Chỉ có thể quản lý bằng app thôi, không quét QR code read DB có mà ăn lol à

znvdicrd said:

Nếu yêu cầu thực sự chỉ là kiểm tra xem đã tiêm chưa thì sao phải cần request đến server với DB nhiều thế các thím?
Tình trạng tiêm của mỗi người chỉ thay đổi max là 2 lần theo đúng 1 chiều: chưa tiêm -> 1 mũi -> 2 mũi. Vậy thì cần gì lần nào cũng phải mò lên server để check?

Giải pháp đơn giản hơn là mô phỏng lại đúng như cấp giấy hiện tại nhưng làm digital: Mỗi lần tiêm thì sign cái số căn cước của mỗi người với tình trạng tiêm. Đến lúc scan thì cái app decrypt lại, cán bộ kiểm tra lại đảm bảo match với số căn cước là xong chứ nhỉ?

Click to expand...

Mình cũng nghĩ đến phương pháp này. Nó giống như việc cache mãi ở client cho đến khi server blacklist hoặc hết hạn token.
Khi nào bên masterDB có update thì phải blacklist cái token này để app request mới
Blacklist tương đối nhỏ ( theo số lượng thay đổi trong tình trạng y tế ) nên có thể fit hết lên 1 con cache rẻ được

qkhanhpro1 said:

Mình cũng nghĩ đến phương pháp này. Nó giống như việc cache mãi ở client cho đến khi server blacklist hoặc hết hạn token.
Khi nào bên masterDB có update thì phải blacklist cái token này để app request mới
Blacklist tương đối nhỏ ( theo số lượng thay đổi trong tình trạng y tế ) nên có thể fit hết lên 1 con cache rẻ được

Click to expand...

mình chưa đọc cái app sổ sk, chỉ sơ qua thấy nó đổi qr code sau 2 hay 3 lần refresh

Buonnguqua6 said:

Cập nhật tình trạng dương tính, âm tính nữa
Tiêm xong 2 mũi về bình thường mới cũng dương tính bỏ mẹ ra
Cho nó vào nơi đông người để lây lan thêm số ca à
Phải xác định bình thường mới sau tiêm vẫn ngày 20.000 ca nhiễm 1 ngày như Anh Quốc hiện tại nhé
Mà 20k ca nhiễm 1 ngày thì éo công an, dân phòng nào có thể quản lý được F0 đâu. Chỉ có thể quản lý bằng app thôi, không quét QR code read DB có mà ăn lol à

Click to expand...

Kể cả tình trạng dương tính/âm tính nó cũng không thể nào sáng âm, chiều dương, tối âm thay đổi liên tục được phải không thím?
Nếu muốn quan tâm cả tình trạng âm/dương tính theo cách của tôi thì thêm 1 field nữa vào, tức là sign bộ ba ID, tình trạng tiêm, tình trạng âm/dương tính. Lúc nào tiêm xong hoặc xét nghiệm có kết quả thay đổi thì sign lại cái bộ 3 này.

Anh em vẽ ra use cases để bàn xem có những giải pháp kỹ thuật nào cho vui, chứ thực tế nó không đến nỗi phức tạp thế đâu.

znvdicrd said:

Kể cả tình trạng dương tính/âm tính nó cũng không thể nào sáng âm, chiều dương, tối âm thay đổi liên tục được phải không thím?

Click to expand...

Chuẩn rồi
Đây, app đang dùng cho tình trạng Bình thường mới ở Sing
https://play.google.com/store/apps/details?id=sg.gov.tech.bluetrace&hl=vi&gl=US
Tính năng bật Bluetooth ngu học thì bỏ qua, không cần

Mình từng làm ở viettel, mình nghĩ không phải vấn hardware vì hệ thống server của Viettel khá mạnh. Vấn để ở code do outsource code rất nhiều bug, query db không tối ưu, leak mem nhiều nên nhiều người dùng n hay bị die server hay crash app

chích xong cho delay nửa tháng để có kháng thể hẵng update lên mũi. Chứ gặp mấy ông vừa chích xong là đi tung tăng cũng như không chích

cpanel10x said:

chích xong cho delay nửa tháng để có kháng thể hẵng update lên mũi. Chứ gặp mấy ông vừa chích xong là đi tung tăng cũng như không chích

Click to expand...

Hệ thống sẽ check là chích mũi 2 sau bao nhiêu ngày với từng loại vaccine thì mới cho màu xanh mà má

minhneo said:

1. Database 1 write, n read (n tùy nhu cầu). Bonus nếu dùng database hiệu con voi https://swarm64.com/
2. n api, phân tải theo khu vực, nhà mạng, dãi AS,...
3. app caching
4. Redis database caching dùng case của instagram đã áp dụng để lấy thông tin ảnh (google là ra, nhớ k nhầm cao điểm 300tr query vẫn chạy ào ào)
Write, update thông tin ngày chắc không quá 1tr thì đâu có lớn.

Kiến thức hạn hẹp, ae đừng gạch nha.

Click to expand...

Đặt gạch lúc nào cần tìm lại cho dễ

naiveryan said:

lướt web chứ có phải chơi game đâu mà request per second = x10 x20 CCU đc.

Đa số web giờ nó render, fetch API 1 lần lúc mới vào thôi, còn navigate giữa các page nó re-fetch ít thôi, nên t ko nghĩ là 1 user = 10req per second.

Click to expand...

Bật inspector lên là thấy load 1 web ra 1 đống request rồi fen.

thanhquangqb95 said:

mấy bác phải hiểu là cái này làm theo đơn đặt hàng của bác bộ phòng ban. Nghĩa là có thể server là tận dụng các con server đang dùng cho hệ thống cũ của các bộ, phòng ban đó chứ ko phải của đơn vị làm app đề suất ra. nên vì vậy mới dẫn đến việc lag khi sử dụng. Con mấy bác chê viettel này kia thì em nghĩ cái app viettel pay hay my viettel thì còn xịn hơn mấy con app mùa dịch này cũng có lag gì đâu. Nên cũng đừng đánh giá thấp mấy tập đoàn lớn, tập đoàn lớn thì cũng có người này người kia, nhưng nhân sự người ta lớn 10 thằng bt thì có 1 thằng giỏi. Nói chứ các bác làm dự án cho khách hàng cũng biết thôi, tối ưu nhất với mình nhưng chưa chắc tối ưu nhất với khách hàng. Dữ liệu quốc gia cũng nhảy cảm nên khả năng cao là server quản lý của nhà nước thôi.

Click to expand...

Fen nói làm tôi lại phải chửi cái đậu móe my viettel với viettel pay nó lag nó giật, app loằn gì đại diện cho tập đoàn tỷ đô mà như đồ án thực tập của mấy em năm cuối.

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 ( 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

Click to expand...

Anh để nó chết rồi mới lên phương án scale thì khách hàng nó xiên anh thành tổ ong nhé.
Ví dụ như hệ thống rikvip 1 phút nổ vài tỷ 1 phòng mà anh để nó downtime 30s thôi cũng vỡ mồm rồi.

Buonnguqua6 said:

Hệ thống sẽ check là chích mũi 2 sau bao nhiêu ngày với từng loại vaccine thì mới cho màu xanh mà má

Click to expand...

Có cc. T chích hôm sau lên xanh lè luôn roiif

đã là dữ liệu app check covid, dữ liệu công dân tối quan trọng như vậy nó không để ở nước ngoài đâu bác.
Nếu có cloud thì có thể sẽ là mấy ông lớn VN thôi.

cpanel10x said:

Có cc. T chích hôm sau lên xanh lè luôn roiif

Click to expand...

confirm là chích 1 mũi, hôm sau lên vàng, 2 mũi lên xanh. Không có vụ delay