元旦前后，网站增加了直播功能，但发现，有时候打开页面，网站反应很慢。
吓死宝宝了，以为服务器出了啥子问题。
后来发现，由于上传图片，当一个页面有十多张图片，每个图片都有一兆多的时候，瞬间占满了一兆的带宽。
问题来了，就得解决。
原来的服务器文件，上传了，就放在那里，请求来了，便给。这样，如果一个页面有三两个一兆以上的文件，便会加载很慢，同时，其他访问，便拥堵了。
还有一个问题，原来的文件，都放到了数据库里，这样方便服务器横向扩展的时候，不用关心文件，反正都在数据库里。但，租用的数据库，也渐渐地满了。
最快捷的解决方法：加钱买啊！
钱能解决的问题，就不是问题。可，问题是没钱。
且，这么简单粗暴地解决问题，也不是我得风格。
于是，挽起袖子，自己解决。
需求如下：
1.图片要处理。图片有多种使用场景，缩略图，常规图，广告图片，海报图片等，规格都不一样。要随需供应。
2.语音也要处理。目前找到的文件500KB左右，加载要三两秒时间，明显等待。不爽。
3.要缓存。
4.支持所有文件。一个是用户上传的文件，另一个是ckeditor插件上传和管理的文件。
功能实现。
这是有史以来最废纸的功能，用了两页纸！平日里，一个功能，半张一张的，也就够了。
FreeFile领域类，用于存储文件元数据。主要是名称大小，路径之类（不再存数据库了）。为啥叫FreeFile，没啥意思，我是个爱自由的人。也想，这个设计能行云流水般的流畅好用。
FileHub工具类，用于处理文件。一个是收文件，用户上传后，他负责存储到FreeFile和本地，也负责整合ckeditor里面的文件。另一个是发文件，根据FreeFile和场景生成文件链接，根据链接返回处理过（压缩和缓存）的文件。
功能基本也就这么实现了。还有一些支持工具类。
FileConvert工具类。用于压缩转换文件。使用FFMPEG来处理语音，用ImageMagick处理图片。以前倒是用纯Java处理图片，图片质量下降明显，且有隐含的性能问题。
写了一大批临时代码，用于迁移现有的文件到新的系统。
这不是第一次给飞驰的火车换轮子了，好在，有惊无险。
实际效果。
图片经过处理，体积大大缩小。缩略图（80X80），一般7KB左右，头像（200X200），一般17KB左右，大图（640X）一般30KB左右。这样一个页面上，即便有几十张图片，也可以快速加载了。这些图片，都是请求时，按需生成。
语音经过压缩，测试，码率24k是一个较均衡的选择。体积从500KB降低到180KB，点击，瞬间便播放了。基本在一秒以内。
完善了缓存。通过浏览器缓存，etag等，极大地减少服务器的压力和流量。
这个方案，估计能坚持一阵儿了。
本文出处 http://luoyouzhijia.cn/blogs/461?tc=201706261108.1.0
来源：oschina
链接：https://my.oschina.net/u/71378/blog/613941