Đỗ Xuân Đình a từng làm r đó. Cảm thấy nó chưa thực sự tối ưu Có thể mình chấp nhận lặp lại, với 1 lượng nhất định
Lê Hiếu cũng là 1 giải pháp tạm thời ạ, vì e làm tiện ích Chrome nên nếu dùng cùng 1 máy đó thì k sao
Nguyễn Nam Long liệu có thể gửi 1 ảnh cho nhiều người cùng 1 lúc (kiểu đồng bộ ấy) và cứ thế quay vòng !
Tạo danh sách/mảng 2 chiều gồm ID người dùng và ID ảnh Đánh dấu theo 1 quy luật tăng dần ID ảnh ( ví dụ ID ảnh gửi người sau trong mảng = ID ảnh của người ngay trước + 1 (chẳng hạn) -> mình thì thấy không random nhưng mà người nhận sẽ không nhận ra). Trước đấy nếu để cho không bị trùng mod thì anh có thể random ngẫu nhiên cái phần ảnh (theo kích thước ảnh, theo dung lượng ảnh,...) để sau đó đánh ID cho ổn, và để tránh việc cùng 1 ảnh mà chỉ khác kích thước, dung lượng,... thì em chưa nghĩ ra cách
Nguyễn Nam Long mục tiêu là đối với mỗi người dùng họ đều thấy ảnh khác nhau mỗi lần gửi chứ đâu phải tất cả ng dùng đều thấy ảnh khác nhau (khác những người khác) đúng k
Nguyễn Nam Long anh đã nghĩ đến cache chưa, em thấy cache (ví dụ như redis) có thể giải quyết được vấn đề này á, tầm 3 tháng mình reset cache một lần, như vậy sẽ không có hiện tượng ảnh bị lặp trong vòng 3 tháng trước đó, ưu điểm của cache là xử lý nhanh hơn db thưởng 1 vì nó dùng nosql, sau 1 thời gian thì reset cache nên k phải lo lắng vấn đề bộ nhớ
Nguyễn Nam Long không nặng đâu, 1 user chưa list id của hình, thì sẽ có n dòng thôi. Tùy theo lượng user, cái này là khá tối ưu rồi.
bác thử tạo cho mỗi ảnh 1 id, khi user gửi request thì đồng thời phía user tạo 1 số random gửi lên sv, để tránh lặp lại thì lưu những số đã xuất hiện ở client
Random một dãy số khoảng 8-9 chữ số hoặc nhiều hơn và đánh từng tệp tin Khi nào phát được 1 tệp thì ghi tên đó vào một tệp excel, check điều kiện, trùng thì random lại, ok thì phát xong lại ghi, cứ vậy đến bh đủ 1000 tệp
Nguyễn Văn Viên mỗi lần random xong thì cut ảnh đó nhét vào 1 folder khác để lần random sau ko bị trùng ))