IT_YUAN的专栏

随着非结构化数据的爆炸，分布式文件系统进入了发展的黄金时期，从高性能计算到数据中心，从数据共享到互联网应用，已经渗透到数据应用的各方各面。对于大多数分布式文件系统(或集群文件系统，或并行文件系统)而言，通常将元数据与数据两者独立开来，即控制流与数据流进行分离，从而获得更高的系统扩展性和I/O并发性。因而，元数据管理模型显得至关重要，直接影响到系统的扩展性、性能、可靠性和稳定性等。存储系统要具有很高

http://www.ibm.com/developerworks/cn/linux/l-ofs/index.html

问题： 如何增量同步文件，例如一个文本文件有10M，分别存放在A，B两个地方，现在两个文件是完全一样的，但是我马上要在A上对这个文件进行修改，B如何实现自动和A上的文件保持一致，并且网络的传输量最少。   应用场景： 这样的使用场景太多，这里随便列举几个 1.A机器为线上运营的机器，现在需要一台备份的机器B，当A发生宕机的时候，或者硬盘损坏等各种认为非人为原因导致数据

rsync 的核心算法       rsync是unix/linux下同步文件的一个高效算法，它能同步更新两处计算机的文件与目录，并适当利用查找文件中的不同块以减少数据传输。rsync中重要的特性就是对有变更的部分进行传送。rsync可拷贝/显示目录属性，以及拷贝文件，并可选择性的压缩以及递归拷贝。      问题：      首先，我们来想一下rsync要解决的问题

本地文件系统如ext3，reiserfs等（这里不讨论基于内存的文件系统），它们管理本地的磁盘存储资源、提供文件到存储位置的映射，并抽象出一套文件访问接口供用户使用。但随着互联网企业的高速发展，这些企业对数据存储的要求越来越高，而且模式各异，如淘宝主站的大量商品图片，其特点是文件较小，但数量巨大；而类似于youtube，优酷这样的视频服务网站，其后台存储着大量的视频文件，尺寸大多在数十兆到数吉字节

文/余庆 FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。准确地讲，Google FS以及FastDFS、mogileFS、HDFS、TFS等类Google FS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务

摘要 本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用。首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题。 分布式缓存问题 假设我们有一个网站，最近发现随着流量增加，服务器压力越来越大

http://blademaster.ixiezi.com/2010/03/27/the-google-file-system%E4%B8%AD%E6%96%87%E7%89%88/

Google文件系统（Google File System，GFS）是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。 GFS是Google云存储的基石，其它存储系统，如Google Bigtable，Google Megastore，Google Percolator均直接或者间接地构建在GF

背景和介绍 缓存是计算机里广泛使用的一种技术，对降低读取延迟、网络流量和服务器负载都非常有效，但也带来了一致性(Consistency)的问题。所谓一致就是客户端总能读到最新的数据，使用缓存后有可能服务器端的数据已经被修改，但客户端仍然从缓存中读取陈旧的数据。为了保证一致性，有两种常见的解决办法，第一种是轮询（Polling），即每次读取数据时都先询问服务器数据是不是最新的，如果不是就从

连接数据库 MongoClient VS Connection class MongoClient(pymongo.common.BaseObject) | Connection to MongoDB. | | Method resolution order: | MongoClient | pymongo.common.BaseObject |