Nhờ tư vấn cấu hình nginx cho static files để tốc độ phản hồi nhanh

Google drive hiển thị file theo file id, còn việc sắp xếp file thì như trên local thôi, như em hiện tại thì sử dụng thư mục 3,4 hoặc 5 cấp md5 tuỳ theo số lượng file.
Còn việc ánh xạ domain đến file trên google drive thì là kỹ thuật reverse proxy của nginx thôi mà (trên forum này đã bàn rất nhiều về nó).

Ví dụ có 1 file images trên google drive id là ETrya3rNkZ_ZpQVXg_a3xKPtSXO01et thì đường dẫn có file đó khi đã được publish share là https://lh3.googleusercontent.com/d/ETrya3rNkZ_ZpQVXg_a3xKPtSXO01et
Bây giờ chỉ cần proxy từ nginx đến địa chỉ này là được (ví dụ muốn thành là: https://mydomain.com/a/b/1/5/e/test-image-500px-xxxx.png chẳng hạn).

muốn custom url cho đẹp và tốt cho SEO thì code trong nginx thôi (giờ nginx hỗ trợ cả js nên thích hiển thị kiểu gì chẳng được

 

Thanks bác @noenmo , hình như bác ko hiểu ý của mình rồi. Dĩ nhiên nếu biết id của 1 shared file đc chia sẽ trên Google Drive dễ rồi. Tuy nhiên, chúng ta chỉ biết tên file (trên remote file server và trong CSDL cũng lưu tên file thôi), nên muốn mapping được thì chắc chắn chúng ta phải biết cách Google Drive mã hóa tên file thành ID thế nào hoặc viết mã duyệt hết folder nào đó trong Google Drive và map tên file - ID trên Drive với nhau. Khi đó users khi truy cập vào tên file này thì mới thực hiện được việc truy cập đúng file đó trên Google Drive. Mình đoán cách làm của drv.tw trong video comment trên nó hoạt động tương tự như thế.

Nếu mình nhớ ko lầm các site phim lậu Việt hay dùng Google Drive để streaming phim lúc trước, tuy nhiên, suy đó Google đã xây dựng cơ chế chống rate limit với read files trong Google Drive rồi, nên việc ứng dụng CDN cho static files với Google Drive có hiệu quả trong thực tế với site có traffic vừa phải ko là 1 vấn đề nữa.

 

À, căn bản khi upload lên em cũng toàn API nên nó đã trả về sẵn fileID rồi, chỉ lưu CSDL thôi, mà kiểu gì khi upload lên bác chẳng dùng API.
Trường hợp lỡ quên thì search chính xác theo tên file thì cũng ra được fileID mà, với vài chục triệu hay vài trăm triệu file thì cũng không nhiều nên việc lấy fileID trong trường hợp cần thiết cũng nhanh.
Nói chung là em đưa ra giải pháp cho vấn đề của bác thôi, làm sao vừa tiết kiệm vừa hiệu quả mà quan trọng nhất là ổn định (tốc độ tốt chỉ là một yếu tố).
Em cũng hay làm load balancing nhiều, cố gắng cải thiện tốc độ ở càng nhiều location càng tốt (ttfb có site bình quân 60ms / các locations) nhưng kết quả vẫn bết bát => kết luận không cần quá quan trọng tốc độ (đừng quá chậm là được).

Ngoài ra nếu dùng drive thì bác còn tận dụng được bộ máy render của gồ (resize, crop, render for web, stream...) nói chung là khó có đơn vị nào bằng được.

--- Double Post Merged, Jun 8, 2022, Original Post Date: Jun 8, 2022 ---

Đảm bảo không vấn đề gì nhé, vài chục TB không thấm đâu cả (em đã làm và chạy site >3PB media => tuy nhiên đã thất bại do không có kinh phí duy trì)

 

@noenmo nginx proxy drive thì phải cache vào disk. nếu cache ngắn thì lượt request vào file drive quá nhiều sẽ bị limit file còn nếu cache lâu thì disk có mấy chục gb sao đủ vậy bác

 

em thì không cache bác nhé, em sử dụng browser cache (phía client), còn dung lượng storage của server nginx thì em không quan tâm lắm, khi stream hay load từ một bên thứ ba nào đó (VD: drive) thì chủ yếu em cần là bộ nhớ (RAM) và tốc độ đường truyền.

 

ko cache rồi nếu lượng request lớn vào 1 file thì limit sao bác

 

Bác chưa hiểu cơ chế render của drive rồi, và cache client bác nhé, đấy là chưa tính cache bên thứ 3 khác như cf chẳng hạn.

 

Drive limit theo file hay theo tài khoản thế mấy bác

 

Cả 2 bạn nhé, nó limit theo action nên không xác định chính xác được con số cụ thể, kể cả đối với API, tos là 1 billion request per day nhưng nó là loại request gì (GET, POST, PUT...)

 

Thật ra bác cứ mua thêm 1 con server ở hetzner rồi clone y hệt ảnh qua, sau đó load balancing cho 2 con hetzner. Lúc thì về server này, lúc server kia.
Vì con hetzner của bác là HDD nó bị nghẽn ở cái ổ cứng do hết iops mà thôi.
Làm cách này của mình vừa đảm bảo ko tốn thêm quá nhiều tiền, mà lại còn kèo chắc cốp là xui bị bad HDD vẫn còn server backup.

hetzner vẫn bị bad HDD, nhiều là đằng khác. Chưa bị là do bác hên thôi )

 

ssd thì sao bác? :3

 

Cái thớt muốn là tốc độ phản hồi ở nhiều location khác nhau <500ms.

Vấn đề là chi phí, nếu nhiều $ thì giải quyết được ngay.

 

Nếu site bác không chuyên về ảnh thì có thể xài wasabi, còn không thì nên xài backblaze. 2 thằng này đều dùng s3, có thể dùng rclone để sync lên xuống vps hoặc server. Minh từng bị wasabi đuổi cổ, mình nói tính thêm tiền cho download bandwith mà nó cũng không chịu.