? 關于圖片存儲問題，主要關系到了前端的展示問題。

? 怎么存更好？ 《===》?前端怎么展示更方便？

? 隨著數據量的級別上升，都有哪些方案？哪些方案更好？

? 我在思考這個問題的時候：主考慮到的是并發量的問題；圖片數量過多的問題；以及訪問速度的問題。

? 帶著這些問題，我有搜索了網上的圖片存儲的方案。以及去看了電商系統淘寶的方案，還看了csdn的圖片是如何存的。通過借鑒他們的存儲方式，可以作為我們的解決問題的方案。

圖片如何存儲

? 在看了一些博客以后，總結了一下，網上前幾頁的博客普遍提到的方案。

? 存在tomcat服務上，image文件夾下，這樣可以直接訪問到。

適用場景：單體應用；很小的用戶量，不用考慮并發的情況下。

好處：簡單，基本不用做什么操作。

弊端：基本上沒有什么價值。只能當做ppt演示項目。在并發情況下，有著非常大的問題。根本解決不了。擴展是一個很大的問題。

? 把圖片直接以二進制形式存儲在數據庫中。

使用場景：小項目，圖片數據量沒有那么多。不用考慮數據量的情況下。

好處：方便操作。

弊端：這是以來數據庫的，一般來說圖片都是要占用比較大的存儲空間的。這會給數據庫帶來很大的負擔。不信你去找你們公司的DBA商量一下這個事情，看DBA是不是會拿板凳砸你。并且這種方式太不主流了，我是基本上沒有見過有這樣用的。

? 使用nginx搭建一個文件存儲服務器。這樣圖片就可以作為url路徑的方式給前端用于展示。

適用場景：這種方式比較常見的，中小型企業都可以適用的方案。它的性能依賴于nginx。nginx本身的出色性能，讓這種方案變得可行。

好處：借用了nginx的性能。將圖片作為靜態資源來訪問。并且可以給nginx配置獨立的域名，可以做到靜態資源分離，這樣不會和業務搶占資源。

弊端：也不能說是弊端吧，主要是我們要考慮一些問題，比方說，我們在服務器下，特定配置下，單個目錄下放多少個圖片合適。還需要考慮圖片增長問題，到達一定級別，我們應該如何去擴展。這可能我們需要使用一些代碼，編寫一些算法來完成。

注意事項：我們要注意圖片的命名規則，要主要唯一性。比如網站的并發訪問量大，目錄的生成分得月細越好。比如精確到小時，一個小時都可以是一個文件夾。同時0.001秒有兩個用戶同時在上傳圖片(因為那么就會往同一個小時文件夾里面存圖片)。因為時間戳是精確到秒的。為了做到圖片名稱唯一性而不至于覆蓋，生成可以在在時間戳后面繼續加毫秒微秒等。總結的規律是，并發訪問量越大。就越精確就好了。

? 使用 nginx +?FTP，共享文件目錄的方式。

適用場景：這種方式相當于是上邊第二種方式的升級。

好處：解決了擴展性的問題。 將圖片服務和應用服務分離，緩解應用服務器的I/O負載。通過共享目錄的方式來進行讀寫操作，可以避免多服務器之間同步相關的問題。 相對來講很靈活，也支持擴容/擴展。支持配置成獨立圖片服務器和域名訪問，方便日后的擴展和優化。相對于更加復雜的分布式的NFS 系統，這種方式是性價比高，符合目前互聯網的“短平快”的開發模式。

弊端：共享目錄配置有些繁瑣，?會造成一定的（讀寫和安全）性能損失。如果圖片服務器出現問題，那所有的應用都會受到影響。同時也對存儲服務器的性能要求特別高。圖片上傳操作，還是得經過Web服務器，這對Web服務器還是有巨大的壓力。

參考文章：https://blog.csdn.net/haihongazar/article/details/52535676

? 使用云服務對象存儲，（這么了解的不是很多）。

適用場景：不想自己維護圖片存儲服務器。

好處：去中心化存儲架構，利于數據的長期維護。

弊端：花錢。

了解更多關于對象存儲：https://blog.csdn.net/sandstone2019/article/details/103597448?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-15.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-15.control

前端如何展示

• ? 非常主流的方式：url鏈接的方式訪問圖片。這也是普遍使用的。
• ? 基本上沒有見過的方式：二進制形式存儲圖片，把文件流給前端用于展示下載。

看看別人是怎么使用圖片的

? CSDN

? 在csdn上隨便找一篇有圖片的博客，鼠標放上去，我們可以復制該圖片的地址鏈接：https://img-blog.csdnimg.cn/20191218144118795.png??

? 可以看到的是這是單獨的圖片存儲服務器，以及單獨配置的域名。也就是你在提交博客的時候，csdn會把你文章中的圖片保存下來，并且根據算法進行命名。從這張圖片的鏈接中，我們可以借鑒的是圖片的命名規則基本上都用到了時間戳。

?

? 巨大的電商系統-淘寶

? 打開淘寶網，隨便瀏覽一下，隨便找一個商品，然后右擊鼠標，同樣可以復制圖片地址：https://img.alicdn.com/bao/uploaded/i4/2106073573/O1CN01aoaT5w1cGTq2b0pmE_!!2106073573.jpg_200x200q90.jpg_.webp? 這個鏈接就是下邊圖片中紅框商品的鏈接。

?

? 淘寶的鏈接就比較有趣了，因為它更有內容。首先是命名規則更加復雜了，從域名中我們可以看出來，這應該是走了CDN加速了。?CDN加速是我在這篇文章中第一次提，這是優化訪問速度不可少的手段。優化都做了，訪問還是慢？試試CDN靜態資源加速呀！?

? 再來一個加餐

? 我這里有一個需求，就是把一張圖片轉成二維碼。別人通過掃描二維碼，可以掃出來這張圖片。聽起來就挺滑稽的，為什么不能直接展示圖片呢，為什么要掃一掃再展示呢？我看了下需求是說要一些細節屏蔽掉。掃碼可以展示跟多圖片內容。

? 其實這里就用到了一個知識點：如何把內容轉變成二維碼？?文字是否可以轉化成二維碼，鏈接是否可以轉化成二維碼？圖片是否可以轉化成二維碼？

? 我在拿到這個需求的時候，我就搜了一下，網上各種文章都有，可能是我理解能力有問題，不是他們寫的有問題，我實在是沒看明白他們怎么做才行。而我的思路是：這個問題肯定是通用的。二維碼出來不是一天兩天了?？隙ㄓ腥藢戇^工具類，于是我就去?https://hutool.cn/?上搜了搜 “二維碼”這個關鍵詞，果然有！

?

? 只不過它提供只有把?url轉成?二維碼。?我一想，如果想要把圖片轉成二維碼，然后再通過掃碼展示的話，那正好，我們把圖片放在圖片服務器下（比如用nginx搭一個圖片存儲服務器）。?

??https://hutool.cn/? 這個是java工具類的一個文檔。實際上這上邊有非常多的重復的輪子，我們并不用造。有些磚別人已經搬過了。

? 這樣我的需求就實現了。下班打卡！

?

總結

以上是生活随笔為你收集整理的海量图片存储方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。