系統中，用戶的消息在移動設備與接入服務器建立的Tcp長連接上傳遞。這些消息包括：文本，復合文本，位置信息，音頻剪輯，圖像等等。
發送者傳送消息到平臺系統內部并將消息寫入gridfs，待接收者上線時平臺將消息推送至接收者。
考慮到帶寬利用，接收者得到的消息將不包含二進制數據，例如: 音頻，圖像等等。 這要求接收者對平臺發起一次獲取消息包內指定的音頻和圖像數據的請求。
移動端向平臺請求二進制數據的情況還包含 【離線文件傳送】場景 。
二進制數據往往是指那些數據量比較大的對象，這些對象在移動兩端交換時，交互通道將不占用與接入服務器的連接通道，而是通過nginx傳送到平臺內部； 同樣接收者獲取二進制數據也是通過nginx獲取。這種請求是HTTP的。
這里整理的是如何在平臺部署 【負載均衡的集群的分布式的文件服務】
nginx : http服務，提供反向代理和負載均衡服務（集群可用DNS或考慮LVS方案）
mongodb+gridfs : 用于文件服務提供，其內置gridfs提供了分布式，海量存儲的方案
gevent+webpy : nginx直接讀取gridfs是不合適的，配置了cgi才能完成特定功能，這里使用webpy，比django更輕更好用。
webpy的作用是接收到上傳和下傳文件的請求，讀寫gridfs文件內容給移動端。
gevent是高效的通信框架，雖然單線程工作，但性能非常的好；
用好gevent關鍵在與外部的io必須全部都是異步的，例如： 數據庫，文件磁盤訪問等等。
mongodb對gevent已經支持，gevent對webpy，django，psycopg2支持也相當的好，所以要提供webservice服務那就考慮用gevent+webpy或django把，性能是杠杠的，比 apache+mod_wsgi要好很多 ，而且gevent是進程內的不同的HTTP REQUEST可以是共享數據的，這一點非常誘惑(apache+mod_wsgi的REQUEST可是隔離的哦！除非您通過redis的PUB/SUB實現兩個REQUEST的通信)
關注的問題：
１.下傳大文件時的處理
如果直接用nginx當然沒有這個問題 ，但用webpy讀取文件返回HttpResponse時問題來了，總不至于讀取整個文件，然后再return。
這種方式在php有flush方法，python只能用yield來做
2.上傳大文件時的處理
當接收到http的文件POST請求時，文件已經全部緩存到web服務器，如果同時幾千個文件上傳在進行，服務器就會被擠爆，這也是很多網站不允許大文件上傳的緣故吧。關于這個問題，我想就需要修改一下webpy關于文件上傳的處理代碼了，將接收到的文件數據以流的形式寫入到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