海量图片存储方案

  关于图片存储问题，主要关系到了前端的展示问题。

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

  随着数据量的级别上升，都有哪些方案？哪些方案更好？

  我在思考这个问题的时候：主考虑到的是并发量的问题；图片数量过多的问题；以及访问速度的问题。

  带着这些问题，我有搜索了网上的图片存储的方案。以及去看了电商系统淘宝的方案，还看了csdn的图片是如何存的。通过借鉴他们的存储方式，可以作为我们的解决问题的方案。

图片如何存储

  在看了一些博客以后，总结了一下，网上前几页的博客普遍提到的方案。

1.   存在tomcat服务上，image文件夹下，这样可以直接访问到。
   1. 适用场景：单体应用；很小的用户量，不用考虑并发的情况下。
   2. 好处：简单，基本不用做什么操作。
   3. 弊端：基本上没有什么价值。只能当做ppt演示项目。在并发情况下，有着非常大的问题。根本解决不了。扩展是一个很大的问题。
2.   把图片直接以二进制形式存储在数据库中。
   1. 使用场景：小项目，图片数据量没有那么多。不用考虑数据量的情况下。
   2. 好处：方便操作。
   3. 弊端：这是以来数据库的，一般来说图片都是要占用比较大的存储空间的。这会给数据库带来很大的负担。不信你去找你们公司的DBA商量一下这个事情，看DBA是不是会拿板凳砸你。并且这种方式太不主流了，我是基本上没有见过有这样用的。
3.   使用nginx搭建一个文件存储服务器。这样图片就可以作为url路径的方式给前端用于展示。
   1. 适用场景：这种方式比较常见的，中小型企业都可以适用的方案。它的性能依赖于nginx。nginx本身的出色性能，让这种方案变得可行。
   2. 好处：借用了nginx的性能。将图片作为静态资源来访问。并且可以给nginx配置独立的域名，可以做到静态资源分离，这样不会和业务抢占资源。
   3. 弊端：也不能说是弊端吧，主要是我们要考虑一些问题，比方说，我们在服务器下，特定配置下，单个目录下放多少个图片合适。还需要考虑图片增长问题，到达一定级别，我们应该如何去扩展。这可能我们需要使用一些代码，编写一些算法来完成。
   4. 注意事项：我们要注意图片的命名规则，要主要唯一性。比如网站的并发访问量大，目录的生成分得月细越好。比如精确到小时，一个小时都可以是一个文件夹。同时0.001秒有两个用户同时在上传图片(因为那么就会往同一个小时文件夹里面存图片)。因为时间戳是精确到秒的。为了做到图片名称唯一性而不至于覆盖，生成可以在在时间戳后面继续加毫秒微秒等。总结的规律是，并发访问量越大。就越精确就好了。
4.   使用 nginx + FTP，共享文件目录的方式。
   1. 适用场景：这种方式相当于是上边第二种方式的升级。
   2. 好处：解决了扩展性的问题。 将图片服务和应用服务分离，缓解应用服务器的I/O负载。通过共享目录的方式来进行读写操作，可以避免多服务器之间同步相关的问题。 相对来讲很灵活，也支持扩容/扩展。支持配置成独立图片服务器和域名访问，方便日后的扩展和优化。相对于更加复杂的分布式的NFS 系统，这种方式是性价比高，符合目前互联网的“短平快”的开发模式。
   3. 弊端：共享目录配置有些繁琐， 会造成一定的（读写和安全）性能损失。如果图片服务器出现问题，那所有的应用都会受到影响。同时也对存储服务器的性能要求特别高。图片上传操作，还是得经过Web服务器，这对Web服务器还是有巨大的压力。
   4. 参考文章：https://blog.csdn.net/haihongazar/article/details/
5.   使用云服务对象存储，（这么了解的不是很多）。
   1. 适用场景：不想自己维护图片存储服务器。
   2. 好处：去中心化存储架构，利于数据的长期维护。
   3. 弊端：花钱。
   4. 了解更多关于对象存储：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/.png  

  可以看到的是这是单独的图片存储服务器，以及单独配置的域名。也就是你在提交博客的时候，csdn会把你文章中的图片保存下来，并且根据算法进行命名。从这张图片的链接中，我们可以借鉴的是图片的命名规则基本上都用到了时间戳。

  巨大的电商系统-淘宝

  打开淘宝网，随便浏览一下，随便找一个商品，然后右击鼠标，同样可以复制图片地址：https://img.alicdn.com/bao/uploaded/i4//O1CN01aoaT5w1cGTq2b0pmE_!!.jpg_200x200q90.jpg_.webp  这个链接就是下边图片中红框商品的链接。

  淘宝的链接就比较有趣了，因为它更有内容。首先是命名规则更加复杂了，从域名中我们可以看出来，这应该是走了CDN加速了。 CDN加速是我在这篇文章中第一次提，这是优化访问速度不可少的手段。优化都做了，访问还是慢？试试CDN静态资源加速呀！ 

  再来一个加餐

  我这里有一个需求，就是把一张图片转成二维码。别人通过扫描二维码，可以扫出来这张图片。听起来就挺滑稽的，为什么不能直接展示图片呢，为什么要扫一扫再展示呢？我看了下需求是说要一些细节屏蔽掉。扫码可以展示跟多图片内容。

  其实这里就用到了一个知识点：如何把内容转变成二维码？ 文字是否可以转化成二维码，链接是否可以转化成二维码？图片是否可以转化成二维码？

  我在拿到这个需求的时候，我就搜了一下，网上各种文章都有，可能是我理解能力有问题，不是他们写的有问题，我实在是没看明白他们怎么做才行。而我的思路是：这个问题肯定是通用的。二维码出来不是一天两天了。肯定有人写过工具类，于是我就去 https://hutool.cn/ 上搜了搜 “二维码”这个关键词，果然有！

  只不过它提供只有把 url转成 二维码。 我一想，如果想要把图片转成二维码，然后再通过扫码展示的话，那正好，我们把图片放在图片服务器下（比如用nginx搭一个图片存储服务器）。 

  https://hutool.cn/  这个是java工具类的一个文档。实际上这上边有非常多的重复的轮子，我们并不用造。有些砖别人已经搬过了。

  这样我的需求就实现了。下班打卡！