讀60行代碼完成的NoSQL數據庫，看數據庫打造面臨的挑戰(zhàn)
“不要試圖去自建一個數據庫”，從某些角度上來說這個觀點所言非虛。雖然自建的數據從來都不會被真正投入使用、測試等，然而卻是一個非常好的途徑去討論現(xiàn)實數據庫打造中所遇到的挑戰(zhàn)。下面是說的是一個代碼不到60行的鍵值存儲NoSQL數據庫 ，具備完善的功能、良好的可擴展性并且允許分片。或許它可以稱得上最小的數據庫，然而待完善的方面也不可謂不多。
首先是服務器端代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
public class NoSqlDbController : ApiController{static readonly ConcurrentDictionary<string, byte[]=""> data =new ConcurrentDictionary<string, byte[]="">(StringComparer.InvariantCultureIgnoreCase);public HttpResponseMessage Get(string key){byte[] value;if(data.TryGetValue(key, out value) == false)return new HttpResponseMessage(HttpStatusCode.NotFound);return new HttpResponseMessage{Content = new ByteArrayContent(value)};}public void Put(string key, [FromBody]byte[] value){data.AddOrUpdate(key, value, (_, __) => value);}public void Delete(string key){byte[] value;data.TryRemove(key, out value);}} |
然后是客戶端代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
public class NoSqlDbClient{private readonly HttpClient[] clients; public NoSqlDbClient(string[] urls){clients = new HttpClient[urls.Length];for (var i = 0; i < urls.Length; i++){clients[i] = new HttpClient { BaseAddress = new Uri(urls[i]) };}} public Task PutAsync(string key, byte[] data){var client = clients[key.GetHashCode()%clients.Length];return client.PutAsync("?key=" + key, new ByteArrayContent(data));} public Task DeleteAsync(string key, byte[] data){var client = clients[key.GetHashCode() % clients.Length];return client.DeleteAsync("?key=" + key);} public async Task<byte[]> GetAsync(string key){var client = clients[key.GetHashCode() % clients.Length];var r = await client.GetAsync("?key=" + key);return await r.Content.ReadAsByteArrayAsync(); }} |
如代碼所見，這個世界上最小的NoSQL數據庫有著非常好的并發(fā)模型，并且基于Last Write Wins策略?？梢园踩膽獙Σl(fā)問題，然而這樣就萬無一失了?
實際情況并非如此。在實際生產過程中，數據庫不是只需要處理并發(fā)問題，比如其它需要注意的地方：
插入時必須檢驗該值是否已存在
修改時必須校驗該值是否同于修改前
實現(xiàn)這些其實非常簡單，你必須為每次修改增加一個元數據字段version。下面是所需修改代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
public class Data { public byte[] Value; public int Version; } static readonly ConcurrentDictionary<string, Data> data = new ConcurrentDictionary<string, Data>(StringComparer.InvariantCultureIgnoreCase); public HttpResponseMessage Get(string key) { Data value; if(data.TryGetValue(key, out value) == false) return new HttpResponseMessage(HttpStatusCode.NotFound); return new HttpResponseMessage { Headers = { "Version", value.Version }, Content = new ByteArrayContent(value.Value) }; } public void Put(string key, [FromBody]byte[] value, int version) { data.AddOrUpdate(key, () => {// create if(version != 0) throw new ConcurrencyException(); return new Data{ Value = value, Version = 1 }; }, (_, prev) => {// update if(prev.Version != version) throw new ConcurrencyException(); return new Data{ Value = value, Version = prev.Version +1 }; });} |
如上所見，僅僅將代碼量改為雙倍，但是卻解決了很多問題。RavenDB使用了類似的并發(fā)寫入控制，雖然RavenDB的ETag機制還可以做更多的事情。然而以上版本實際上是不夠，它只可以做寫入的并發(fā)控制，而缺乏讀取的相關操作。
我們還需要對不可重復讀和幻讀做出處理：
不可重復讀指在一個需要對數據進行重復讀取的事務中，第一次讀取到了數據，而在第二次卻讀取不到數據，因為這里存在被他人刪除的情況。
幻讀則是反過來的，第一次未讀取到數據，而在第二次被其他人建立后，又讀取到了數據。
因為你只注重單操作/事務/會話，所以在特定的場景下，可能會產生非常有意思的bug，實際上也沒有辦法去處理這個問題。
另一個需要處理的方面是鎖。有些時候用戶有著非常合理的理由去給某條記錄加上一定時間的鎖，而在多用戶對某條記錄并發(fā)修改時加鎖也是唯一的解決方案。鎖又分為Write和ReadWrite兩種。Write鎖只允許其它用戶對被鎖的數據進行讀取，同時禁止其對數據進行修改。在實際情況中，讓用戶立刻失敗也比讓其等待要好的多。
之所以會立即返回失敗是因為你操作的數據被加上了Write鎖，這就意味著該數據已經被修改或者將要被修改。你寫入將會作用在一個過期的數據，所以返回立即失敗會更恰當一點。對于ReadWrite鎖，情況會有所不同。在這種情況下，我們同時禁止了其它用戶的讀操作。這么做一般是為了保障系統(tǒng)的一致性，基本上任何作用在該條記錄上的操作都要等待鎖的失效。
在實踐中，一旦加ReadWrite鎖，你必須要去處理鎖的有效期、手動解鎖、鎖失效檢測、鎖維護等一系列的問題。ReadWrite鎖主要用于在不支持事務的系統(tǒng)中的進行一些事務操作，其它情況下謂之雞肋亦不為過。
