IM开发——图片文件服务器

IM开发——图片文件服务器

一个完善的IM系统中通常充斥着大量的图片内容,包括:用户头像、图片消息、相册、图片表情等等,那么在做服务端架构设计时该如何存储这些图片呢?

  • 旧式的PC端IM中,诸如图片消息这种业务形态,可能是通过长连接直接推送过去(所谓的实时图片传输),这种情况理论上是不需要服务端存储的。

  • 现今的主流移动端IM,基于移动网络抖动大、 不稳定的特性和随时随地社交分享的现实,已很少使用实时传输这种技术手段。现在主流IM都是本文所述的这种:通过Http短连接从云(即服务端)“拉取”,这种方式的好处是:随时随地分享、对网络稳定性要求低(只要上传者一次上传,服务端可长时间存储,下一个阅读者通过URL按需随读随取即可,再次分享时只要分享URL而无需再次完整传输整个图片)

**以此类推:**IM系统中,实际上还存在其它类似于图片的小文件存储需求,比如:语音留言消息中的AMR短音频文件(有些IM中为了音质可能使用的是AAC音频格式,比如易信)、短视频功能中的小视频文件等,这些文件的存储和使用跟图片文件基本类似,所以考虑到通用性,如果能把这些小文件存储也纳入到图片的存储架构中,对于整体系统架构来说(尤其存储部分)就显的更通用。所以实际上完全可以套用到其他小文件的存储上

单机时代的图片服务器架构(集中式)

直接在website文件所在的目录下,建立1个upload子目录,用于保存用户上传的图片文件:
  • 如果按业务再细分,可以在upload目录下再建立不同的子目录来区分,例如:upload\QA,upload\Face等
  • 在数据库表中保存的也是“upload/qa/test.jpg”这类相对路径;
  • 用户的访问方式如下:http://www.yourdomain.com/upload/qa/test.jpg
程序上传和写入方式:
  • 程序员A通过在web.config中配置物理目录D:\Web\yourdomain\upload 然后通过stream的方式写入文件;
  • 程序员B通过Server.MapPath等方式,根据相对路径获取物理目录 然后也通过stream的方式写入文件。
优缺点:
  • 优点:实现起来最简单,无需任何复杂技术,就能成功将用户上传的文件写入指定目录。保存数据库记录和访问起来倒是也很方便;
  • 缺点:上传方式混乱,严重不利于扩展。
针对上述最原始的架构,主要面临着如下问题:
  • 随着upload目录中文件越来越多,所在分区如果出现容量不足,则很难扩容。只能停机后更换更大容量的存储设备,再将旧数据导入;
  • 在部署新版本(部署新版本前通过需要备份)和日常备份website文件的时候,需要同时操作upload目录中的文件,如果考虑到访问量上升,后边部署由多台Web服务器组成的负载均衡集群,集群节点之间如果做好文件实时同步将是个难题。

集群时代的图片服务器架构(实时同步)

一个传统的Web服务端站点下面,新建一个名为upload的虚拟目录,由于虚拟目录的灵活性,能在一定程度上取代物理目录,并兼容原有的图片上传和访问方式。

在这里插入图片描述

  • **优点:**配置更加灵活,也能兼容老版本的上传和访问方式。因为虚拟目录,可以指向本地任意盘符下的任意目录。这样一来,还可以通过接入外置存储,来进行单机的容量扩展。

  • **缺点:**部署成由多台Web服务器组成的集群,各个Web服务器(集群节点)之间(虚拟目录下的)需要实时的去同步文件,由于同步效率和实时性的限制,很难保证某一时刻各节点上文件是完全一致的。

同步操作里面,一般有比较经典的两种模型,即推拉模型:所谓“拉”,就是指轮询地去获取更新,所谓推,就是发生更改后主动的“推”给其它机器。当然,也可以采用加高级的事件通知机制来完成此类动作。

集群时代的图片服务器架构改进(共享存储)

沿用虚拟目录的方式,通过UNC(网络路径)的方式实现共享存储(将upload虚拟目录指向UNC)。

支持UNC所在server上配置独立域名指向,并配置轻量级的web服务器,来实现独立图片服务器。

  • 优点: 通过UNC(网络路径)的方式来进行读写操作,可以避免多服务器之间同步相关的问题。相对来讲很灵活,也支持扩容/扩展。支持配置成独立图片服务器和域名访问,也完整兼容旧版本的访问规则。

  • **缺点:**但是UNC配置有些繁琐,而且会造成一定的(读写和安全)性能损失。可能会出现“单点故障”。如果存储级别没有raid或者更高级的灾备措施,还会造成数据丢失。

在这里插入图片描述

独立图片服务器/独立域名的好处

图片访问是很消耗服务器资源的(因为会涉及到操作系统的上下文切换和磁盘I/O操作)。分离出来后,Web/App服务器可以更专注发挥动态处理的能力。

  • 独立存储,更方便做扩容、容灾和数据迁移;
  • 浏览器(相同域名下的)并发策略限制,性能损失;
  • 访问图片时,请求信息中总带cookie信息,也会造成性能损失;
  • 方便做图片访问请求的负载均衡,方便应用各种缓存策略(HTTP Header、Proxy Cache等),也更加方便迁移到CDN;

我们可以使用Lighttpd或者Nginx等轻量级的web服务器来架构独立图片服务器。

总结,有关图片服务器架构扩展,大致围绕这些问题展开:

  • 容量规划和扩展问题;
  • 数据的同步、冗余和容灾;
  • 硬件设备的成本和可靠性(是普通机械硬盘,还是SSD,或者更高端的存储设备和方案);
  • 文件系统的选择。根据文件特性(例如文件大小、读写比例等)选择是用ext3/4或者NFS/GFS/TFS这些开源的(分布式)文件系统;
  • 图片的加速访问。采用商用CDN或者自建的代理缓存、web静态缓存架构;
  • 旧图片路径和访问规则的兼容性,应用程序层面的可扩展,上传和访问的性能和安全性等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值