為什么需要鎖服務？
有時候，在分布式系統中，不同的服務實例需要操作同一份資源，所以我們需要一套機制保證對該資源并發操作的數據一致性。
最通常的做法，就是lock。各個服務在操作資源之前，首先lock住該資源，處理完成之后在釋放lock。也就是說，我們通過lock使得并行操作串行化，保證了資源的數據一致性。
為什么要實現重新實現一個？
雖然現在有很多不錯的鎖服務實現，譬如基于Zookeeper，Etcd，甚至Redis，但這里我仍然想自己實現一個簡易的lock服務，主要有以下幾點原因：
Multi Lock
同時獲取多個lock，有時候我們想同時對多個資源進行操作，所以需要多把lock，但是無論是Zookeeper還是Redis，我們都需要對其進行多次調用，影響整體性能。
Hierarchical Lock
支持hierarchical lock，我稱之為path lock，我們的系統是有類似文件夾的概念的，假設現在我們需要往文件夾a/b/c下面增加一個文件，我們就必須得保證另一個進程不會同時操作該文件夾以及其祖先和后繼（譬如刪除a，或者a/b，或者也往a/b/c下面增加文件），但是允許操作其兄弟（譬如在a/b/d下面增加文件）。
仍然是上面那個例子，假設我們需要操作a/b/c，首先我們需要對a加read lock，然后對a/b加read lock，最后在對a/b/c加write lock，如果這個通過Zookeeper來實現，真心很麻煩，而且性能存疑。
TLock
tlock是一個簡單的中心化lock service，現階段為了性能沒有High Availability支持，所以如果當掉了后果還是有點嚴重的。:-)
tlock支持兩種模式，key和path，key就是最通常的對某個資源進行操作，而path則是我上面說的Hierarchical Lock。同時tlock支持Multi Lock。
tlock提供Restful API以及RESP(Redis Serialization Protocol) API，所以你可以通過任意HTTP客戶端或者Redis客戶端使用。
一個簡單的HTTP例子：
// shell1
// 同時lock a，b，c三個資源，如果30s之后仍沒lock成功，返回超時錯誤
// 返回lockid供后續unlock使用
POST http://localhost/lock?names=a,b,c&type=key&timeout=30
// Unlock
DELETE http://localhost/lock?id=lockid
// shell2
POST http://localhost/lock?names=a,b,c&type=key&timeout=30
DELETE http://localhost/lock?id=lockid
一個簡單的RESP例子：
# shell1 redis-cli
redis>LOCK abc TYPE key TIMEOUT 10
redis>lockid
redis>UNLOCK lockid
redis>OK
# shell2 redis-cli
redis>LOCK abc TYPE key TIMEOUT 10
// 一直掛起直到shell1 unlock
redis>lockid
redis>UNLOCK lockid
redis>OK
tlock同時提供了RESP的客戶端：
import "github.com/siddontang/tlock"
client := NewRESPClient(addr)
locker, _ := client.GetLocker("key", "abc")
locker.Lock()
locker.Unlock()
Todo
可以看到，tlock是一個非常簡單的服務，雖然是一個單點并且沒有HA支持，但是已經能滿足我們項目的需求，畢竟我們只是需要一個簡單的鎖服務。
后續，我可能會基于Zookeeper嘗試實現path lock，雖然這樣HA能夠保證，但是性能怎樣，到時候壓測了再說吧。
