問題根源來自一個客戶，客戶的問題是，我有一個文件需要同時被多人訪問，怎麼實現？性能怎麼樣？有問題就有答案，只是目前這個答案對我還不太清晰，試着探討以下。
手頭正好有一本冬瓜頭的《大話存儲》，就抱着一絲希望，翻了翻，找到關於該問題的一些描述。以下是《大話存儲》中的描述。
集羣中的分佈式鎖機制
在單個節點的單一操作系統內，存在多個應用程序進程，如果某時刻，應用程序A試圖訪問一個記錄文件F，F中包含有地址薄和地址信息，A將其打開之後，又有一個應用程序B將其打開，此時，F同時存在於A和B的Buffer內。之後，A將F中的對應的某人的電話號碼做了更改，並且將更改寫入了F。此時如果B也對F中的電話號碼做更改並保存，那A做的更改將丟失。
這顯然是一個很大的問題。所以，所有文件系統都會提供一種API，讓一個程序在打開一個文件的時候，順便給這個文件家個鎖，讓其他程序不可以打開或者只能以只讀的方式打開這個文件，只有當加鎖的程序退出後，或者將鎖釋放了之後，其他程序纔可以修改這個文件。即，一旦遇到多個程序需要修改同一個文件，那麼這些程序只能排隊一個一個來，如果某個程序給文件加了鎖，但是卻遲遲不作爲，比如操作員離開，而其他的操作員終端就只能等待，那麼時間就白白的浪費了。
不鎖不是，鎖也不是，那麼有沒有兩全其美的解決辦法呢？當然有。
1、 字節鎖（Byte Range Lock）
應用程序可以不要就加鎖整個文件，而只是加鎖文件中的某段或者某幾段字節，這些字節是這個程序當前讀入並且打算更改的。而其他程序如果訪問這個文件的字節偏移不處於被加鎖的範圍內，則多個程序就可以進行並行的讀寫這個文件的不同部分，互補影響。這樣，鎖的粒度就被極大的降低了，對應地可以並行讀寫同一個文件的程序也就可以並行的執行了，提高系統的性能。
2、 並行衝突訪問鎖仲裁
在字節鎖的基礎上，如果有多個應用程序同時訪問同一段字節，或者訪問的字節段有交集，那麼一次只能夠由一個應用程序掌握對這段交集的更改權，其他應用程序可以處於只讀狀態。
應用程序一般不會被設計爲多個進程進程同時寫同一個文件的同一段字節，如果真的需要這種應用場景，那麼必須加鎖—更改—釋放，之後由其他程序在加鎖—更改—釋放，這樣纔可以保持一致性。
以上是書中內容，給我的思考是：如果同一個文件，不同的應用程序在更改不同的部分，那麼是可以同時的進行的，那麼更改完成後可以將做的所有不同更改進行合成形成一個最終的版本嗎？比如有一個視頻原文件，需要進行配音，畫面的處理，假如這兩個過程同時進行，兩個過程都完成後，可以合成得到一個畫面和配音都更改好了的視頻文件嗎？希望大家多多提意見。
同一個文件的被不同的用戶同時訪問，性能問題怎麼樣？這個問題在NAS集羣中應該不用擔心，NAS集羣畢竟是多節點，每個節點都可以提供一定的帶寬。如果是單臺的NAS Server，應該會出現一定的性能瓶頸。
