redis在.net架構中的應用(2)--並發和原子操作不可兼得

在上一篇文章中，我主要向大家介紹了利用servicestack連接redis以及一些redis的基本數據類型，傳送門

本文中，我將通過一個具體應用場景為大家介紹redis中的並發和原子操作

其中用到的redis命令，請大家去redis官網查詢http://www.redis.io/commands

一 一個投票統計的應用場景

假設我要做一個實時統計投票數的應用，這個投票總共有A、B、C、D四個選項，因為是一個高並發的場景，所以我准備用redis來存儲投票數

  我們首先利用redis-cli模擬這個過程，打開命令終端，新建一個hash類型的key，叫做TicketCount, 編號為1，然后我們將選項作為其field值,

redis命令如下：

然后我們利用servicestack模擬投票場景，代碼如下：

 static void Main(string[] args)
        {

            RedisClient[] redisCli = new RedisClient[8]{
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379),
                new RedisClient("192.168.101.165", 6379)
              };
            ThreadPool.QueueUserWorkItem(o =>
             {
                 testTicketCount(redisCli[0], "A");
             });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[1], "A");
            });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[2], "B");
            });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[3], "B");
            });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[4], "C");
            });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[5], "C");
            });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[6], "D");
            });
            ThreadPool.QueueUserWorkItem(o =>
            {
                testTicketCount(redisCli[7], "D");
            });
          
            Console.Read();
        }
        /// <summary>
        /// 對某個選項進行投票，投票數加1
        /// </summary>
        /// <param name="rediscli"></param>
        /// <param name="field"></param>
        internal static void testTicketCount(IRedisClient rediscli, string field)
        {
            int k = 0;
            for (int i = 0; i <= 99; i++)
            {

                k = int.Parse(rediscli.GetValueFromHash("TicketCount", field))+1;
                rediscli.SetEntryInHash("TicketCount", field, k.ToString());
            }
        }

 

我們設想的結果是A、B、C、D四個選項各獲得了200票，但是對多線程比較熟悉的同學馬上就能看出問題了，

事實上最終的結果是

沒錯，在一個線程執行GetValueFromHash和SetEntryInHash兩條命令的時候，另一個線程修改了key的值，破壞了操作的原子性

 

這個過程中，A選項明顯丟掉了一張投票。

二 Nosql中的原子性

要保證數據操作的原子性，在傳統的RDBMS應用中，我們首先想到的就是事物和鎖，但是在這個場景中，我們需要獲得保證{get key;set key}這兩步

操作的原子性，我們需要獲得key的值，所以無法用到事物。

讓我們回到nosql的本質上來，來談談鎖的運用，有興趣的同學可以看看關於nosql的CAP原則和傳統的RDBMS的ACID原則：

從上圖中，我們可以看到，NoSQL系統更加注重性能，是不保證一客戶端的兩個操作的原子性保證的

（redis中的事物比較特殊，我將會在下一篇文章中討論）

三 利用hincrby

幸虧redis還提供hincrby命令，也就是直接對hset某個字段的值加上某個整數

也就是對某個hash key中的某個value 值 提供加一操作。我們可以將TicketCount函數修改一下：

 

    internal static void testTicketCount(IRedisClient rediscli, string field)
        {
            int k = 0;
            for (int i = 0; i <= 99; i++)
            {
                rediscli.IncrementValueInHash("TicketCount", field, 1);
                //k = int.Parse(rediscli.GetValueFromHash("TicketCount", field))+1;
                //rediscli.SetEntryInHash("TicketCount", field, k.ToString());
            }
        }

但是問題是，如果換了一個應用場景，A中存儲的不是數值而是字符串呢？

四 並發和原子操作

這兩個特性是完全矛盾的，nosql的設計理念就是為了支持高並發，所以它注定就對原子操作的支持性不高。

因為原子操作必然要涉及到數據庫級別的鎖，會帶來各種性能損耗。

至於redis中的事物，完全是和redis的實現機制有關的，我將會在下一篇文章中和大家討論

有同學提到了樂觀鎖機制，servicestack中也已經實現了樂觀鎖，我也會在下一篇中提到

 

作者:Mars

 

出處:http://www.cnblogs.com/marsblog/

 

本文基於署名-非商業性使用 3.0中國大陸許可協議發布,歡迎轉載,演繹或用於商業目的,但是必須保留本文的署名 Mars (包含鏈接)