1.前言

 

 一个完美的即时通讯系统通常会充满大量的图片,包括:用户的头像、图片信息、相册、图片表达等。在设计服务器架构时,如何存储这些图片?

 

 本文分享了典型网络应用中服务器端存储和构建大量图片的演变过程,但基本的技术原理和架构思想也适用于即时消息系统,因此您在阅读时可以根据自己即时消息的实际架构吸收适合自己的内容。本文中的一些观点可以作为参考,但这可能不是最佳实践。请不要迷信。

 

 实际上:在旧的个人电脑端即时消息中,服务形式,如图片消息,可以通过长连接(所谓的实时图片传输)直接推送,理论上不需要存储在服务器端。然而,当前主流的移动即时通信,基于移动网络抖动大、不稳定的特点和随时随地进行社会共享的现实,很少使用实时传输技术。目前,主流的即时消息是本文所描述的:它是通过Http短连接从云(即服务器)中“拉”出来的。这种方法的优点是:随时随地共享,对网络稳定性要求低(只要上传者上传一次,服务器就可以长时间保存,下一个读者可以通过网址阅读并根据需要取用,当再次共享时,只需要共享网址,不需要再次完整传输整个图片)。

 

 类比:在即时通讯系统中,实际上还有其他类似于图片的小文件存储要求,如语音信息中的AMR短音频文件(在某些即时通讯中,如电子邮件,AAC音频格式可用于音质),短视频功能中的小视频文件等。这些文件的存储和使用基本上类似于图片文件,所以考虑到通用性,如果这些小文件的存储可以包含在图片存储架构中,对于整个系统架构来说。因此,尽管本文以图像存储为切入点,但您实际上可以将其应用于其他小文件的存储。

 2.相关文章

 

 ▼有几篇关于即时消息数据存储架构的文章,可能对您有用:

 

 腾讯原创分享(一):如何在移动网络下大幅提高手机QQ的图片传输速度和成功率

 微信大用户后台系统存储架构(视频+PPT)[附件下载]

 微信后台基于时序的海量数据冷热分层架构设计实践

 现代即时通讯系统中聊天信息同步存储方案的探讨

 

 ▼即时通讯开发干货系列文章适合作为即时通讯开发热点问题的参考材料(本文是其第十一篇文章):

 

 即时消息传递保证机制的实现(一):保证在线实时消息的可靠传递

 即时消息传递保证机制的实现(二):保证离线消息的可靠传递

 如何确保即时消息的“时间”和“一致性”?》

 我应该使用“推”还是“拉”来同步即时消息单聊和群聊的在线状态?》

 即时消息群聊新闻如此复杂,如何确保它不丢失或沉重?》

 安卓即时通讯智能心跳算法的设计与实现探讨(含示例代码)

 “当即时消息登录移动终端时,如何通过提取数据来节省流量?》

 易于理解:基于集群共享移动终端即时通信接入层的负载均衡方案

 浅谈移动即时通信的多点登录和消息漫游原理

 构成即时通讯开发的基础知识(一):正确理解前端HTTP单点登录接口的原理

 构成即时消息开发的基础知识(2):如何为大量图像文件设计服务器端存储架构?”(本条)

 补充即时通讯开发的基础知识(3):快速了解服务器端数据库读写分离的原理和实用建议

 构成即时消息开发的基础知识(4):正确理解短连接中的Cookie、会话和令牌

 如何实现即时通讯群聊信息的阅读回执功能?》

 即时消息群聊消息是一份拷贝(即扩散阅读)还是多份拷贝(即扩散写作)?》

 构成即时消息开发的基础知识(5):易于理解、正确理解并充分利用MQ消息队列

 一种低成本保证即时消息定时的方法探讨

 补上一课关于即时消息开发的基础知识(6):您的数据库使用NoSQL还是SQL?读读这个!》

 在即时通讯中实现“身边人”功能的原则是什么?如何有效地实现它?》

 构成即时通讯开发的基础知识(七):主流移动账户登录方法的原理和设计思路

 弥补即时通讯发展的基础知识(8):历史上最流行的,彻底了解字符乱码问题的本质

 如何实现即时通讯的扫描码板功能?有一篇文章了解主流应用的扫描代码登陆技术的原理

 “即时通讯做手机扫描码登录?让我们先来看看微信扫描码登录功能的技术原理

 构成即时通讯发展的基础知识(9):想发展即时通讯集群吗?首先了解什么是RPC!》

 

 如果你是即时通讯开发的初学者,强烈建议你先阅读“初学者:从头开始开发移动即时通讯”。

 3.独立时代的图像服务器架构(集中式)

 

 在初始阶段,由于时间紧,开发商的水平非常有限。

 

 因此,上传子目录通常直接建立在网站文件所在的目录中,用于保存用户上传的图片文件:

 

 如果您按业务细分,您可以在上传目录下创建不同的子目录来区分它们,如上传\质量保证、上传\面子等。

 相对路径如“upload/qa/test.jpg”也保存在数据库表中。

 用户的访问方法如下:http://www.yourdomain.com/upload/qa/test.jpg

 

 程序的上传和编写方法:

 

 程序员A在web.config中配置物理目录D:\ Web \您的域\上传,然后以流的形式写入文件。

 程序员B通过服务器根据相对路径获取物理目录。然后通过流的方式写入文件。

 

 结果是:

 

 优点:实现最简单,用户上传的文件可以成功写入指定的目录,不需要任何复杂的技术。保存和访问数据库记录也非常方便;

 缺点:上传方式混乱,严重不利于网站的扩展。

 

 鉴于上述原始架构,它主要面临以下问题:

 

 随着上传目录中文件越来越多,如果容量不足,很难扩展其所在分区的容量。关机后只能更换容量较大的存储设备,然后才能导入旧数据;

 当部署新版本(在部署新版本之前需要备份)和每天备份网站文件时,必须同时操作上传目录中的文件。如果由多个网络服务器组成的负载平衡集群部署在后台,那么如果文件在集群节点之间实时同步将是一个难题。

 

 4.集群时代的图像服务器体系结构(实时同步)

 

 在传统的网络服务器站点下,创建了一个名为upload的新虚拟目录。由于虚拟目录的灵活性,它可以在一定程度上替代物理目录,并且与原来上传和访问图片的方式兼容。

 

 用户的访问方法仍然是:

 http://www.yourdomain.com/upload/qa/test.jpg

 

 优点:配置更加灵活,也兼容旧版本的上传和访问方式。由于虚拟目录,您可以指向任何本地驱动器号下的任何目录。这样,可以通过访问外部存储来扩展单台机器的容量。

 

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

 

 基本架构如下图所示:

 构成即时消息开发的基础知识(2):如何为大量图像文件设计服务器端存储架构?_1.jpg

 

 从上图可以看出,整个网络服务器体系结构是“可扩展和高度可用的”,主要问题和瓶颈集中在多个服务器之间的文件同步上。

 

 在上述体系结构中,只有这些网络服务器可以彼此“增量同步”,因此不支持文件“删除和更新”操作的同步。

 

 早期的想法是,当用户请求在web1服务器上上传和写入时,它还会同步调用其他web服务器上的上传接口,这显然是不值得的。因此,我们选择使用Rsync软件定期同步文件,从而节省了“重复制造车轮”的成本,降低了风险。

 

 在同步操作中,通常有两种经典模型,即推挽模型:所谓的“拉”指的是轮询以获得更新,而所谓的“推”指的是主动“推”改变到其他机器。当然,也可以使用高级事件通知机制来完成此类操作。

 

 在高并发写入的情况下,同步会有效率和实时性的问题,并且大量的文件同步也会消耗系统和带宽资源(尤其是跨网段)。

 5.集群时代映像服务器体系结构的改进(共享存储)

 

 遵循虚拟目录的方式,通过网络路径实现共享存储(将上传的虚拟目录指向网络路径)。

 

 用户访问方法1:

 http://www.yourdomain.com/upload/qa/test.jpg

 

 用户访问模式2(可以配置独立域名):

 http://img.yourdomain.com/upload/qa/test.jpg

 

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

 

 优点:读写操作由UNC(网络路径)执行,可以避免多个服务器之间的同步相关问题。相对灵活,它还支持扩展/扩展。支持配置独立的图片服务器和域名访问,并完全兼容旧版本的访问规则。

 

 缺点:然而,UNC配置有点麻烦,并且会导致某些性能损失(读、写和安全性)。可能存在“单点故障”。如果存储级别没有raid或更高级别的灾难恢复措施,也会导致数据丢失。

 

 基本架构如下图所示:

 构成即时消息开发的基础知识(2):如何为大量图像文件设计服务器端存储架构?_2.jpg

 

 在许多基于Linux开源架构的早期网站中,如果你不想同步图片,你可以使用NFS。事实证明,NFS在高并发读写和大容量存储效率方面存在一些问题,这不是最佳选择,因此大多数互联网公司不会使用NFS来实现这种应用。当然,它也可以通过Windows自己的DFS来实现,缺点是“配置复杂,效率未知,缺少大量数据的实际案例”。此外,一些公司使用FTP或桑巴来实现它。

 

 上述体系结构在上传/下载时都要经过网络服务器(虽然共享存储的体系结构也可以配置独立的域名和站点来提供图像访问,但上传和写入仍然要由网络服务器上的应用程序来处理),这无疑给网络服务器带来了很大的压力。因此,建议使用独立的图片服务器和独立的域名为用户提供上传和访问图片的功能。

 6.独立图像服务器/独立域名的优势

 

 映像访问消耗服务器资源(因为它涉及操作系统和磁盘输入/输出操作的上下文切换)。分离后,网络/应用服务器可以专注于动态处理。

 

 独立存储更便于扩展、灾难恢复和数据迁移;

 浏览器(在同一域名下)并发策略限制,性能损失;

 当访问图片时,cookie信息总是包含在请求信息中,这也会导致性能损失;

 它可以方便地平衡图片访问请求的负载,应用各种缓存策略(HTTP头、代理缓存等)。),并迁移到CDN更方便;

 ......

 

 我们可以使用轻量级的网络服务器,如Lighttpd或Nginx来构建独立的图片服务器。

 7.我们当前的图像服务器架构

 

 目前的图片服务器架构采用分布式文件系统+CDN。

 

 在构建当前的图片服务器架构之前,我们可以完全撇开网络服务器,直接配置一个单独的图片服务器/域名。

 

 但它面临以下问题:

 

 旧的图片数据呢?您能否继续兼容旧的图片路径访问规则?

 独立的图片服务器需要为上传和写入提供一个独立的接口(服务API对外发布)。如何保证安全?

 同样,如果有多个独立的图片服务器,我们应该使用可扩展的共享存储方案还是采用实时同步机制?

 

 在应用级(非系统级)DFS(如FastDFS HDFS MogileFs MooseFS,TFS)普及之前,这个问题已经得到简化:冗余备份、支持自动同步、支持线性扩展、支持主流语言的上传/下载/删除客户端应用编程接口等。有些支持文件索引,有些支持提供网络访问。

 

 考虑到分布式文件系统的特点、客户端API语言支持(需要支持C#)、文档和案例以及社区支持,我们最终选择了快速分布式文件系统进行部署。

 

 唯一的问题是它可能与旧版本的访问规则不兼容。如果旧图片一次导入到FastDFS中,但是因为旧图片的访问路径是分布式的,并且存储在不同业务数据库的各种表中,所以很难将它们作为一个整体进行更新,所以它们必须与旧版本的访问规则兼容。升级架构通常比创建一个全新的架构更困难,因为它与以前的版本兼容。在空中更换飞机的发动机比制造一架飞机要困难得多

 

 解决方案如下:

 首先,关闭旧版本的上传门户(以避免因继续使用而导致数据不一致)。通过rsync工具将旧图像数据迁移到独立的图像服务器(即下图中描述的旧图像服务器)。在前端(七层代理,如Haproxy、Nginx),使用访问规则控制(ACL)来匹配与旧图片相对应的URL规则的请求(常规),然后该请求被直接转发到指定的网络服务器列表,并且在列表中的服务器上配置提供图片访问(在网络模式下)的站点,并且添加缓存策略。这样,旧图片服务器被分离和缓存,与旧图片访问规则兼容,提高了旧图片访问效率,避免了实时同步带来的问题。

 

 总体结构如下:

 构成即时消息开发的基础知识(2):如何为大量图像文件设计服务器端存储架构?_3.jpg

 8.使用第三方CDN的方案

 

 虽然基于FastDFS的独立图片服务器集群架构已经非常成熟,但是由于中国“南北互联”和国际数据中心带宽成本的问题(图片非常消耗流量),我们最终选择了商用CDN技术,这也非常容易实现,原理实际上也非常简单。我在这里只做一个简单的介绍。

 

 img域名cname被发送到CDN制造商指定的域名。当用户请求访问图片时,CDN制造商提供智能的域名解析,并返回最近的服务节点的地址(当然,可能还有其他更复杂的策略,如负载状况、健康状态等。)发送给用户。用户请求到达指定的服务器节点,该节点提供类似于Squid/Vanish的代理缓存服务。如果第一次请求该路径,图像资源将从源站获得并返回到客户端浏览器。如果它存在于缓存中,它将直接从缓存中获取并返回到客户端浏览器以完成请求/响应过程。

 

 由于商业CDN服务,我们没有考虑使用Squid/Vanish来构建代理前缓存。

 

 上述整个集群架构可以很容易地横向扩展,并且可以满足一般垂直领域大型网站的图片服务需求(当然,像淘宝这样的超大规模的可能性是另一回事)。经过测试,提供映像访问的单个Nginx服务器(至强E5四核处理器、16G内存、固态硬盘)可以处理数千个并发页面(压缩后仅约10kb),没有任何压力。当然,因为图像本身比纯文本的静态页面大得多,所以提供图像访问的服务器的反并发能力经常受到磁盘的输入/输出处理能力和IDC提供的带宽的限制。Nginx具有很强的反并发能力,占用的资源很少,尤其是在处理静态资源时,所以似乎没有必要太担心。根据实际的流量需求,通过调整Nginx的参数,增加分级缓存策略等,可以在更大程度上优化Linux内核。还可以通过添加服务器或升级服务器配置来扩展它。最直接的方法是购买更高级的存储设备和更大的带宽,以满足更大流量的需求。

 

 值得一提的是,随着“云计算”的普及,也推荐使用“云存储”方案,这不仅可以帮助您解决各种存储、扩容和备灾问题,还可以加速CDN。最重要的是,价格不贵。

 

 总而言之,映像服务器体系结构的扩展围绕着这些问题:

 

 容量规划和扩展问题;

 数据同步、冗余和容灾;

 硬件设备的成本和可靠性(无论是普通机械硬盘、固态硬盘,还是高端存储设备和解决方案);

 文件系统选择。根据文件特征(如文件大小、读写比等。),ext3/4或NFS/GFS/TFS被选为开源(分布式)文件系统;

 加速获取图片。采用商业CDN或自建代理缓存和网络静态缓存架构;

 旧图片路径和访问规则的兼容性、应用层的可扩展性、上传和访问的性能和安全性等。

 


----------------------------------------------------------------------------------

哇谷im_im即时通讯_私有云_公有云-哇谷云科技官网-JM沟通

IM下载体验 - 哇谷IM-企业云办公IM即时聊天社交系统-JM 沟通下载

IM功能与价格 - 哇谷IM-提供即时通讯IM开发-APP搭建私有化-公有云-私有化云-海外云搭建

新闻动态 - 哇谷IM-即时通讯热门动态博客聊天JM沟通APP

哇谷IM-JM沟通热门动态博客短视频娱乐生活

关于哇谷-哇谷IM-提供企业即时通讯IM开发-语音通话-APP搭建私有化-公有云-私有化云-海外云搭建

联系我们 - 哇谷IM-即时通讯IM私有化搭建提供接口与SDK及哇谷云服务

即时通讯IM融云世界

IM即时通讯钉钉技术:企业IM钉钉在后端架构上的优越之处

新的市场叫板环信、融云、腾讯云!开源版IM即使聊天工具

企业IM即时通讯聊天办公APP钉钉技术分析交流

哇谷云-怎么样正确认识海外云服务器

公有云和私有云之间有什么区别?类似融云、环信云、网易云、哇谷云?