系統(tǒng)中，用戶的消息在移動設備與接入服務器建立的Tcp長連接上傳遞。這些消息包括：文本，復合文本，位置信息，音頻剪輯，圖像等等。
發(fā)送者傳送消息到平臺系統(tǒng)內部并將消息寫入gridfs，待接收者上線時平臺將消息推送至接收者。
考慮到帶寬利用，接收者得到的消息將不包含二進制數(shù)據(jù)，例如: 音頻，圖像等等。 這要求接收者對平臺發(fā)起一次獲取消息包內指定的音頻和圖像數(shù)據(jù)的請求。
移動端向平臺請求二進制數(shù)據(jù)的情況還包含 【離線文件傳送】場景 。
二進制數(shù)據(jù)往往是指那些數(shù)據(jù)量比較大的對象，這些對象在移動兩端交換時，交互通道將不占用與接入服務器的連接通道，而是通過nginx傳送到平臺內部； 同樣接收者獲取二進制數(shù)據(jù)也是通過nginx獲取。這種請求是HTTP的。
這里整理的是如何在平臺部署 【負載均衡的集群的分布式的文件服務】
nginx : http服務，提供反向代理和負載均衡服務（集群可用DNS或考慮LVS方案）
mongodb+gridfs : 用于文件服務提供，其內置gridfs提供了分布式，海量存儲的方案
gevent+webpy : nginx直接讀取gridfs是不合適的，配置了cgi才能完成特定功能，這里使用webpy，比django更輕更好用。
webpy的作用是接收到上傳和下傳文件的請求，讀寫gridfs文件內容給移動端。
gevent是高效的通信框架，雖然單線程工作，但性能非常的好；
用好gevent關鍵在與外部的io必須全部都是異步的，例如： 數(shù)據(jù)庫，文件磁盤訪問等等。
mongodb對gevent已經(jīng)支持，gevent對webpy，django，psycopg2支持也相當?shù)暮茫砸峁﹚ebservice服務那就考慮用gevent+webpy或django把，性能是杠杠的，比 apache+mod_wsgi要好很多 ，而且gevent是進程內的不同的HTTP REQUEST可以是共享數(shù)據(jù)的，這一點非常誘惑(apache+mod_wsgi的REQUEST可是隔離的哦！除非您通過redis的PUB/SUB實現(xiàn)兩個REQUEST的通信)
關注的問題：
１.下傳大文件時的處理
如果直接用nginx當然沒有這個問題 ，但用webpy讀取文件返回HttpResponse時問題來了，總不至于讀取整個文件，然后再return。
這種方式在php有flush方法，python只能用yield來做
2.上傳大文件時的處理
當接收到http的文件POST請求時，文件已經(jīng)全部緩存到web服務器，如果同時幾千個文件上傳在進行，服務器就會被擠爆，這也是很多網(wǎng)站不允許大文件上傳的緣故吧。關于這個問題，我想就需要修改一下webpy關于文件上傳的處理代碼了，將接收到的文件數(shù)據(jù)以流的形式寫入到gridfs里去作為臨時文件被緩存，等完全接收文件時，才通知到handler代碼，這樣必定高效很多(新的問題又來了，會不會把gridfs搞爆掉! 處理時考慮延時緩存提交gridfs把)。
BUF_SIZE = 262144
class download:
def GET(self):
file_name = 'file_name'
file_path = os.path.join('file_path', file_name)
f = None
try:
f = open(file_path, "rb")
webpy.header('Content-Type','application/octet-stream')
webpy.header('Content-disposition', 'attachment; filename=%s.dat' % file_name)
while True:
c = f.read(BUF_SIZE)
if c:
yield c
else:
break
except Exception, e:
print e
yield 'Error'
finally:
if f:
f.close()
links:
http://api.mongodb.org/python
http://webpy.org/cookbook/storeupload.zh-cn
http://webpy.org/cookbook/streaming_large_files
http://gevent.org 下份代碼 demo很值得看哦 gevent 1.0 由libev 替換了libevent