读60行代码完成的NoSQL数据库，看数据库打造面临的挑战

摘要：60行代码确实可以完成一个NoSQL数据库，增加一半的代码或许也可以完成预防重复插入及修改校验。然而数据库不只需要处理并发问题，还有其它需要注意的地方，比如：脏读和锁。

“不要试图去自建一个数据库”，从某些角度上来说这个观点所言非虚。虽然自建的数据从来都不会被真正投入使用、测试等，然而却是一个非常好的途径去讨论现实数据库打造中所遇到的挑战。下面是说的是一个代码不到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数据库有着非常好的并发模型，并且基于Last Write Wins策略。可以安全的应对并发问题，然而这样就万无一失了？

实际情况并非如此。在实际生产过程中，数据库不是只需要处理并发问题，比如其它需要注意的地方：

• 插入时必须检验该值是否已存在
• 修改时必须校验该值是否同于修改前

实现这些其实非常简单，你必须为每次修改增加一个元数据字段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使用了类似的并发写入控制，虽然RavenDB的ETag机制还可以做更多的事情。然而以上版本实际上是不够，它只可以做写入的并发控制，而缺乏读取的相关操作。

我们还需要对不可重复读和幻读做出处理：

• 不可重复读指在一个需要对数据进行重复读取的事务中，第一次读取到了数据，而在第二次却读取不到数据，因为这里存在被他人删除的情况。
• 幻读则是反过来的，第一次未读取到数据，而在第二次被其他人建立后，又读取到了数据。

因为你只注重单操作/事务/会话，所以在特定的场景下，可能会产生非常有意思的bug，实际上也没有办法去处理这个问题。

另一个需要处理的方面是锁。有些时候用户有着非常合理的理由去给某条记录加上一定时间的锁，而在多用户对某条记录并发修改时加锁也是唯一的解决方案。锁又分为Write和ReadWrite两种。Write锁只允许其它用户对被锁的数据进行读取，同时禁止其对数据进行修改。在实际情况中，让用户立刻失败也比让其等待要好的多。

之所以会立即返回失败是因为你操作的数据被加上了Write锁，这就意味着该数据已经被修改或者将要被修改。你写入将会作用在一个过期的数据，所以返回立即失败会更恰当一点。对于ReadWrite锁，情况会有所不同。在这种情况下，我们同时禁止了其它用户的读操作。这么做一般是为了保障系统的一致性，基本上任何作用在该条记录上的操作都要等待锁的失效。

在实践中，一旦加ReadWrite锁，你必须要去处理锁的有效期、手动解锁、锁失效检测、锁维护等一系列的问题。ReadWrite锁主要用于在不支持事务的系统中的进行一些事务操作，其它情况下谓之鸡肋亦不为过。