怎么存储base64⽂件流_⼩⼼base64编码数据拖慢你的后台服 务
今天，同事⼩赵接到客户导⼊新闻数据要求，由客户提供新闻数据。于是⼩赵通过 SQL 脚本把新闻数据⼊库后，发现前台展⽰新闻特别慢。幸好当时是晚上凌晨1点，⽤户⽐较少，处理问题来得及，最终经过近半⼩时的排查问题，原来问题出在这⾥。 伪装ip
问题定位
在⼩赵导完数据后，测试⼩赵发现内容管理列表页访问特别慢，加载完数据需要 16 秒左右。
于是我⽤ F12 打开 chrome 调试⼯具，发现获取新闻内容列表数据的 API 接⼝：“getManageArticleList" 接收的数据有 7.1 M，接⼝响应时间长达 16 秒多，太不正常了。
但是同⼀个接⼝换⼀个查询条件，接收的数据只有 367 KB，响应时间 4.5 秒。
由此，这说明两个问题：
第⼀、API 接⼝的请求与响应是没问题的
第⼆、换查询条件后，接⼝响应时间差距近 12 秒之多，说明接收数据有问题我为教育添光彩
既然是数据问题，于是在和⼩赵对⽐⼊库前和⼊库后的新闻数据后，发现问题出在图⽚ base64 加密存储。
原来，客户提供的⽂章数据中包含图⽚，但由于客户原图不在了，只能从别的地⽅收集新闻时，把包含图⽚的新闻采⽤了 base64 加密串给了⼩赵。⽽这些 base64 加密的图⽚每张基本上在 1 M 左右，前端⼀次性分页加载 10 条共 7M 的数据，变慢就不⾜为怪了。
另外，为什么新闻列表页需要加载图⽚呢？
通过代码⾛查，发现图⽚是放在 contentText 字段⾥⾯，但是 新闻内容列表 select 分页语句却包含了 contentText 字段，明显 select 语句不合理。货款结算方式
select ..., contenText from article
解决⽅案
由于时间⽐较紧迫，本次发版⼜不涉及服务升级，只能从修改数据⼊⼿了。
3721网络实名第⼀步，⽤ like 模糊查询存在包含 base64 串的⽂章，共 34 条记录，数据⽐较少
select id,title,contenText from article where contenText like '%data:image%'
第⼆步， 从新闻详情页下载图⽚，⽤ fastdfs 分布式⽂件服务器上传图⽚后，得到图⽚的下载地址，替换 img 标签的 src 属性值。
图⽚地址格式如下：
group1/M00/00/00/rBIK6VcaP0aARXDSNFHrUgHEviQ663.jpg
10 个⼈ 34 条新闻，花了近 20 分钟，完成 base64 图⽚地址替换后，问题解决。
问题总结
什么是 base64 编码？
base64 编码简单来说就是把⼀张图⽚数据加密成⼀串字符，使⽤该字符串代替图像地址。
党的思想路线⽤ base64 把图⽚加密成⼀串字符的好处是：“可以不需要单独⽤⽂件服务器存储⽂件，节省⼀个 http 图⽚请求。”
但是，如果不合理利⽤ base64 带来的问题是：“CSS ⽂件的体积变⼤，CSS ⽂件的体积直接影响渲染，导致⽤户会长时间注视空⽩屏幕。”
#index { background: url(data:image/png;base64,xxxxx) no-repeat center;}
所以，使⽤ base64 编码的前提是图⽚⾜够⼩，以⼀个 3kb 的 logo 图⽚为例:
⼀张 3.27 KB logo 图⽚，已经很⼩了，但是如果将其制作转化成 base64 编码，⽣成的 base64 字符串编码⾜⾜有 4406 个，也就是说，图⽚被编码之后，⽣成的字符串编码⼤⼩⼀般⽽⾔都会⽐原⽂件稍⼤⼀些。即便 base64 编码能够被 gzip 压缩，压缩率能达到 50% 以上，想象⼀下，⼀个元素的 css 样式编写居然超过了 2000个 字符，那对 css 整体的可读性将会造成⼗分⼤的影响，代码的冗余使得在此使⽤ base64 编码将得不偿失。
tornado
看似微不⾜道的问题，如果追踪溯源，还是能学习到⼀些技术有趣的⼀⾯，只是看你有⼼了。
延伸
CssSprites 与 base64 ⽐较？参考
喜欢就点个关注吧。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议