原文:
redis簡單案例(三) 連續登陸活動的簡單實現
連續登陸活動，或許大家都不會陌生，簡單理解就是使用者連續登陸了多少天之後，系統就會送一些禮品給相應的使用者。最常見的
莫過於遊戲和**這些。遊戲就送遊戲幣之類的東西，**就送一些禮券。正值國慶，應該也有不少類似的活動。
下面就對這個的實現提供兩個思路，並提供解決方案。
思路1(以使用者為維度)：
連續登陸活動，必然是要求連續登陸，不能有間隔。用1表示登陸，0表示沒有登陸，這樣我們可以為每個使用者建立乙個key去儲存
他的登陸情況，就可以得到類似這樣的乙個二進位制序列：1110111，如果是7個1，就表示連續7天，如果不是7個1就表示沒有連續登
陸7天。所以就能實現這個登陸活動的要求了。
思路2(以天數為維度)：
一天之內，使用者要麼是登陸過，要麼是沒有登陸過。同樣的用1來表示登陸過，用0表示沒有登陸過。假設我們連續登陸的活動是2天，
同時有3個使用者，那麼就要有2個key去儲存這3個使用者的登陸資訊，這樣就會得到類似這樣的兩個二進位制序列：101(key1),111(key2)。
此時，對這兩個key的每一位都進行邏輯與運算，就會得到101，就表明，使用者1和使用者3連續登陸了兩天。從而達到活動的要求。
下面就簡單模擬一下國慶7天假期連續登陸七天的活動。
方案1 ：以使用者為維度
先為每個使用者建立乙個key(holiday:使用者標識)，對於我們的例子來說，每個key就會有7位二進位制位。這時key會有這樣的結構
七天。這樣就可以在第七天使用者登陸的時間去處理了是否傳送禮品了。處理的邏輯是十分簡單的。控制器簡單邏輯如下：
在這裡還是用隨機數的方法來模擬資料。主要操作有兩個，乙個是模擬登陸後把當天對應的偏移設定為1(true)，另乙個是取出使用者
登陸的天數。這是一次性模擬操作，與正常情況的登陸操作還是有些許不同的。大致如下：
回到我們模擬的情況，在介面展示時，模擬登陸後會顯示累計登陸使用者的id。
1下面來看看效果：<
script
id="everyonetpl"
type
="text/html"
>
2<
span
>
total:}
<
/span>
3<
ul>4}
5<
li>6}
7<
/li>8}
9<
/ul>
10script
>
11<
script
>
12$(
function
() 23}24
})25
});26
})27
script
>
方案2 ：以天數為維度
既然是以天數為維度，那麼就要定義7個redis的key用來當作每天的登陸記錄，類似：
這樣的話就要讓我們的使用者標識是數字才行，如果是用guid做的使用者標識就要做一定的處理將其轉化成數字，這樣方便我們
在給使用者設定是否登陸。現在假設我們的使用者標識是從1~1000。使用者標識對應的就是在key中的偏移量。這時我們就會得到每天
對應的二進位制序列，然後就可以用bitop命令去得到邏輯與運算之後的key/value。如果這個key對應偏移量(使用者標識)是1，就是
連續登陸了七天，處理的邏輯是十分簡單的。控制器簡單邏輯如下：
前台的處理與方案一的一模一樣，所以就不貼**了。下面來看看效果圖。
可能光看效果圖沒太大意義，還是要看一下redis中的資料來驗證一下的。圖中取了76和991這兩個使用者標識(偏移量)來驗證。
一大堆16進製制的東西，有興趣可以去轉換成二進位制試試。
對這兩種方案簡單的總結一下： 方案
優點缺點
以使用者為維度
1.可以無縫對接，無論使用者標識是數字還是其他
2.key對應的資料較少便於觀察
隨著使用者數量的增長，要管理的key會越來越多
以天數為維度
1.有確定數量的key，方便管理
2.key對應的基數大
1.偏移量可能需要根據實際情況處理
2.資料檢視不是很清晰
可至於實際中用那種方案更合適，要根據情況來選擇。使用者量少的時候，可以用第一種方案，也可以用第二種方案，當使用者量很大的時候，
建議採用第二種方案，畢竟只要使用者數量沒有超過43億，就不會超出其二進位制位數的限制。是可以比較放心使用的。
redis使用案例
1.計數器 string 單執行緒，避免併發問題，保證不會出錯，毫秒級效能 命令 incrby incrby 2.佇列 list 簡單訊息佇列 使用者第幾個訪問 新聞列表排序 由於redis把資料新增到佇列是返回新增元素在佇列的第幾位，所以可以做判斷使用者是第幾個訪問這種業務 新聞列表頁面最新的新聞...
三層架構簡單案例分析
最近在網上找了一些資料學習三層架構的知識，初學者就像我來說理解那些抽象的道理還是很困難的，其實不妨用乙個小例子來好好地分析一下 首先，我們需要明白的是三層架構的劃分原理 如下圖所示 各個層的任務 資料訪問層 為資料庫中的每個表，設計乙個資料訪問類，類中實現 記錄的插入 刪除 單條記錄的查詢 記錄集的...
Redis之事務案例
一次執行多個命令，本質是一組命令的集合。乙個事務中的所有命令都會序列化，按順序地序列化執行而不會被其它命令插入，不許加塞。乙個佇列中，一次性 順序性 排他性的執行一系列命令。單獨的隔離操作 事務中的所有命令都會序列化 按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷 沒有隔離...