Windows平台网站图片服务器架构的演进

　　同步操作内里，一样平常有比力经典的两种模子，即推拉模子：所谓“拉”，就是指轮询地去获取更新，所谓推，就是发生更改后自动的“推”给其它机械。固然，也可以接纳加高级的事务通知机制来完成此类行动。

　　在高并发写入的场景中，同步都市泛起效率和实时性问题，而且大量文件同步也是很消耗系统和带宽资源的（跨网段则更显着）。

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

　　沿用虚拟目录的方式，通过UNC（网络路径）的方式实现共享存储（将upload虚拟目录指向UNC）

　　用户的会见方式1：

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

　　用户的会见方式2（可以设置自力域名）：

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

　　支持UNC所在server上设置自力域名指向，并设置轻量级的web服务器，来实现自力图片服务器。

　　优点： 通过UNC（网络路径）的方式来举行读写操作，可以制止多服务器之间同步相关的问题。相对来讲很天真，也支持扩容/扩展。支持设置成自力图片服务器和域名会见，也完整兼容旧版本的会见规则。

　　弱点 ：可是UNC设置有些繁琐，而且会造成一定的（读写和宁静）性能损失。可能会泛起“单点故障”。若是存储级别没有raid或者更高级的灾备措施，还会造成数据丢失。

　　基本架构如下图所示：

　　在早期的许多基于Linux开源架构的网站中，若是不想同步图片，可能会使用NFS来实现。事实证实，NFS在高并发读写和海量存储方面，效率上存在一定问题，并非最佳的选择，以是大部门互联网公司都不会使用NFS来实现此类应用。固然，也可以通过Windows自带的DFS来实现，弱点是“设置庞大，效率未知，而且缺乏资料大量的现实案例”。另外，也有一些公司接纳FTP或Samba来实现。

　　上面提到的几种架构，在上传/下载操作时，都经由了Web服务器（虽然共享存储的这种架构，也可以设置自力域名和站点来提供图片会见，但上传写入仍然得经由Web服务器上的应用程序来处置惩罚），这对Web服务器来讲无疑是造成庞大的压力。以是，更建议使用自力的图片服务器和自力的域名，来提供用户图片的上传和会见。

　　自力图片服务器/自力域名的利益

图片会见是很消耗服务器资源的（由于会涉及到操作系统的上下文切换和磁盘I/O操作）。分散出来后，Web/App服务器可以更专注施展动态处置惩罚的能力。自力存储，更利便做扩容、容灾和数据迁徙。浏览器（相同域名下的）并发计谋限制，性能损失。会见图片时，请求信息中总带cookie信息，也会造成性能损失。利便做图片会见请求的负载平衡，利便应用种种缓存计谋（HTTP Header、Proxy Cache等），也越发利便迁徙到CDN。

　　......

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

　　当前的图片服务器架构（漫衍式文件系统+CDN）

　　在构建当前的图片服务器架构之前，可以先彻底撇开web服务器，直接设置单独的图片服务器/域名。但面临如下的问题：

旧图片数据怎么办？能否继续兼容旧图片路径会见规则？自力的图片服务器上需要提供单独的上传写入的接口（服务API对外公布），宁静问题怎样保证？同理，如果有多台自力图片服务器，是使用可扩展的共享存储方案，照旧接纳实时同步机制？

　　直到应用级此外（非系统级） DFS（例如FastDFS HDFS MogileFs MooseFS、TFS）的盛行，简化了这个问题：执行冗余备份、支持自动同步、支持线性扩展、支持主流语言的客户端api上传/下载/删除等操作，部门支持文件索引，部门支持提供Web的方式来会见。

　　思量到各DFS的特点，客户端API语言支持情形(需要支持C#)，文档和案例，以及社区的支持度，我们最终选择了FastDFS来部署。

　　唯一的问题是：可能会不兼容旧版本的会见规则。若是将旧图片一次性导入FastDFS，但由于旧图片会见路径漫衍存储在差别营业数据库的各个表中，整体更新起来也十分难题，以是必须得兼容旧版本的会见规则。架构升级往往比做全新架构更有难度，就是由于还要兼容之前版本的问题。（给飞机在空中换引擎可比造架飞机难过多）

 2/3   首页 上一页 1 2 3 下一页 尾页