@NamNhiNhanh

1. Đúng rồi, không fair là đúng, vì mục đích của mình là để so sánh 2 phương pháp.
2. Mình nói là chưa thấy ai làm vậy, mình cũng chưa làm nên không có kinh nghiệm để bàn luận thêm.
3. TPS liên tục thì con nào cũng chết cả, con nào chết trước con nào chết sau thôi. Cũng tùy trường hợp, max bạn xử lý tốt 10 connection, mà bạn fixed 8 conn, thì sẽ thua cái pool max size 10 conn, pool size vẫn flexible hơn, cần ít xài ít, cần nhiều keep nhiều.
4. Câu này mình thấy không giống câu hỏi, mà chắc bạn cũng biết rồi nên mình không trả lời.

@VIIGstar2 Thanks b 😊 những vấn đề này mình đã giải thích chi tiết ở comment phía trên hết rồi. Mình hoàn toàn đồng ý với 3 ý này của bạn nhé!

@Plumpboy Bạn đọc kĩ bình luận mình có giải thích vấn đề này cho bạn Kỵ Long ở trên rồi đó 😊

@nguyentuan239

1. Đã sử dụng multipart và chunk rồi thì thường ng ta hướng đến việc gửi nhiều phần cùng lúc -> ko nên await từng phần. Theo template multipart của s3 thì mình có thể gửi các phần của file kèm với index của nó theo thứ tự. Sau khi upload hết các chunk thì gửi tín hiệu complete để BE thực hiện ghép theo index
2. Chặt chẽ hơn thì trước khi upload, cần khai báo (gọi API) request multipart upload, có timeout để BE chủ động biết những file rác/chunk rác nào có thể được clean. Khai báo tổng số phần, kích thước mỗi phần, loại dữ liệu, data hash để so sánh sau khi ghép ... rất nhiều cách để khớp thông tin server /client
3. Nếu mà lquan đến ổ đĩa đầy, thì định lưu disk, sẽ cần phải tính đến trường hợp scale nhiều bản sao service ở máy ảo, container khác nhau, ko chung disk để ghép -> anh nghĩ lưu db hơi chậm nhưng phù hợp hơn khi muốn scale

Cảm ơn anh vì series chất lượng này. Nhưng có một vấn đề em gặp phải khi làm theo đó mà dùng bcryptjs để mã hóa refreshToken trước khi lưu vào db, đó là việc giới hạn kí tự được mã hóa và cắt bỏ kí tự thừa. Dẫn đến việc em dùng refreshToken cũ gọi api /auth/refresh (api refresh token) vẫn hoạt động, tức bcrypt compare refresh token cũ và refresh token mới được mã hóa trong db bằng nhau. Em có thấy vấn đề trên Link. Không biết có phải do em làm sai ở bước nào đó không, mong được a giải đáp ạ😥

Hay đó bạn. Đúng chỉ những cty outsource lớn mới hay có role này.

e đổi thử 127.0.0.1 -> localhost xem nhé

hello a, đây là wu quals hay final v ạ

@systemdesign.vn

thank bác. Các vấn đề chưa xử lí đc chắc để mình nghĩ thêm và lên thêm 1 bài nữa

@NamNhiNhanh Em đồng ý với bác là việc sử dụng redis là rất cần thiết. Nhưng cái em focus là cơ chế recovery khi redis chết. Nếu chỉ load checkpoint của redis thì sẽ chưa đáng tin cậy (reliable). Em nghĩ nên có thể kết hợp với việc load dữ liệu từ 1 Source Of Truth nào đó sẽ reliable hơn.

Nếu không có yêu cầu về thứ tự kích hoạt lệnh thì em không có phản biện gì thêm. Nhưng giả sử có yêu cầu này thì sẽ phát sinh nhiều vấn đề hay ho về thứ tự, error handling, ...

Thank you bác ♥️

không thuyết phục, nếu await như vậy thì chunk ý nghĩa gì đâu

@Plumpboy Bạn có thể đọc câu trả lời ở bình luận ngay phía trên đó 😀

// Make an API call to upload the chunk to the backend
            await uploadChunk(chunk, chunkIndex);

Tại sao lại await ở đây nhỉ ?

anh ơi, cho em hỏi giữa thuật toán annoy và faiss thì cái nào search face encoding nhanh và chính xác hơn ạ. Em tìm hiểu thì annoy sẽ phù hợp với số lượng vector không quá lớn, faiss thì tối ưu hơn với số lượng lớn vector. Các bài toán nhận diện khuôn mặt với dữ liệu khoảng 5000 người thì nên chọn thuật toán nào hợp lý nhất vậy anh, có thể có nhiều thuật toán hay hơn faiss và annoy.

@kiendev

1. Vấn đề k fair benmark là bạn dùng pool có size > 1 khi b test thì ứng dụng của b sẽ mở nhiều hơn 1 connection còn singleton connection là 1 connection thôi
2. Bạn nói k ai dùng việc mở trực tiếp connection đến db thì bạn quá sai. Có thể b chỉ làm các hệ thống bé. Khi b làm hệ thống lớn thường b cần kiểm soát số lượng connection 1 cách triệt để. Ví dụ có 100 service thì b cần kiểm soát chặt chẽ nhất có thể. B thử dùng pool cho 100 service thì việc db hết connection sẽ cao hơn việc b kiểm soát số connection từ đầu. => ý này mình phản biện câu k ai mở connection trực tiếp chứ k bài trừ pool
3. Bạn ns việc việc tạo connection fixed size sẽ khi bị peak nó sẽ lỗi đúng k? Trường hợp bạn dùng pool với size đaya với các hệ thống lớn tps liên tục thì cũng chết như thường nhé

=> mục đích dùng pool là để protected database, tiết kiệm resource cái ý của b ns chỉ là 1 phần lợi điểm thôi.

Tiện đây mình hỏi b thêm 1 câu nữa. Việc dùng pool có nhược điểm gi không? Trên đời này chả có cái gi là ưu điểm tuyệt đối cả.

anh ơi của em bị lỗi như này anh ạ, event em thấy có rồi mà phải load lại mới có tin nhắn anh ạ

1. Pool size là số connection tối đa cho 1 pool, giống như số ghế trong lớp học, nhưng bạn không nhất thiết lúc nào cũng xếp đầy ghế.

2. Hình như bạn nói là không fair, chứ trên bài mình đâu có nói là không fair nhỉ? Nếu không fair thì giống như so sánh 1 CPU và 3 CPUs ấy.

3. Bạn có chắc chắn là 5 connection là đã ổn định, lỡ như user truy cập tăng đột ngột thì sao, 5 connection có đủ không?

   3.1 Tạo luôn 5 connection từ đầu? chưa thấy ai làm vậy vì keep connection alive rất tốn tài nguyên, server còn cần resource để làm việc khác.

   3.2 Bản chất của max pool size là giới hạn tối đa connection, còn idle connection là giữ lại các connection đã connect trước đó mà ko cần connect lại tới DB (handshake cho tốn thời gian)

=> Dùng pool để tiết kiệm resource, và sử dụng lại connection để tăng performance cao hơn. Mời bạn đọc kĩ lại object pool design pattern

Chào bạn. Mình muốn hỏi b một số câu như sau:

• Ví dụ bạn init pool size = 10 và start ứng dụng thì ứng dụng đã tạo connection đến database chưa?
• Benmark b test benmark như kia k fair đối với trường hợp singleton connection và pool? B có thể chỉ ra chỗ k fair ở đâu k?

=> Sau khi b trả lời đc 2 câu trên mình muốn đặt cho b 1 bài toán như sau: Ví dụ ứng dụng của b cần 5 connection đến database là hoạt động ổn định. Mình có 2 trường hợp sau:

1. Khi start app mình khởi tạo luôn 5 connection trực tiếp đến database luôn.
2. Mình dùng pool như bạn cấu hình init = 5

=> B có thể phản biện lí do b dùng pool thay vì khởi tạo trực tiếp 5 connection đến database luôn không? Mục đích chính là để làm gi, giải quyết vấn đề gi?

Cảm ơn bro ♥️

@systemdesign.vn Sau khi nhận được tín hiệu giá thị trường. hệ thống sẽ quét ra toàn bộ lệnh điều kiện thỏa mãn tiêu chi giá và kích hoạt lệnh thật. Việc kích hoạt lệnh thật là xử lí song song và k cần care đến thứ tự. Mọi thứ diễn biến khá nhanh nên latecy giữa các lệnh là k đáng kể.

Còn về redis là bác đang focus vào việc nó bị lỗi. Nhưng về mặt thực tế tỉ lệ chết của nó rất nhỏ hoặc k chết. ví dụ 1 năm bác chết redis 1-2 lần thì nó là tỉ lệ nhỏ và việc trade off tốc độ là rất cần thiết. Việc đo lường nó thì cần monitor, alert, tính toán tốc độ tăng trưởng.