连续登陆活动,或许大家都不会陌生,简单理解就是用户连续登陆了多少天之后,系统就会送一些礼品给相应的用户。最常见的
莫过于游戏和商城这些。游戏就送游戏币之类的东西,商城就送一些礼券。正值国庆,应该也有不少类似的活动。
下面就对这个的实现提供两个思路,并提供解决方案。
思路1(以用户为维度):
他的登陆情况,就可以得到类似这样的一个二进制序列: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 :以用户为维度
这时我们就会得到每个用户对应的二进制序列,然后就可以用bitcount命令去得到key含有的1的个数。如果等于7,就是连续登陆了
七天。这样就可以在第七天用户登陆的时间去处理了是否发送礼品了。处理的逻辑是十分简单的。控制器简单逻辑如下:
[HttpPost]
public IActionResult LoginForEveryone()
{
Random rd = new Random();
var tran = _redis.GetTransaction();
for (int i = ; i < ; i++)
{
for (int j = ; j < ; j++)
{
string activity_key = string.Format("holiday:{0}", j.ToString());
// login 1(true) other 0(false)
if (rd.Next(,) > )
{
tran.StringSetBitAsync(activity_key, i, true);
}
}
}
tran.ExecuteAsync(); List<int> res = new List<int>();
for (int i = ; i < ; i++)
{
string activity_key = string.Format("holiday:{0}", i.ToString());
//7 days
if (_redis.BitCount(activity_key) == )
{
res.Add(i);
}
}
return Json(new { code = "", data = res, count = res.Count });
}
登陆的天数。这是一次性模拟操作,与正常情况的登陆操作还是有些许不同的。大致如下:
[HttpPost]
public IActionResult LoginForEveryone()
{
//1.login and get the identify of user
//2.get the Current day and write to redis
string activity_key = string.Format("holiday:{0}", "identify of user");
_redis.SetBit(activity_key, currend day, true);
//3.send gift
if(currend day==&& _redis.BitCount(activity_key)==)
{
send gift
}
return ...;
}
回到我们模拟的情况,在界面展示时,模拟登陆后会显示累计登陆用户的id。
<script id="everyoneTpl" type="text/html">
<span>total:{{count}}</span>
<ul>
{{each data as item}}
<li>
{{item}}
</li>
{{/each}}
</ul>
</script>
<script>
$(function () {
$("#btn_everyone").click(function () {
$.ajax({
url: "/Holiday/LoginForEveryone",
dataType: "json",
method:"post",
success: function (res) {
if (res.code == "000") {
var html = template('everyoneTpl', res);
$("#div_everyone").html(html);
}
}
})
});
})
</script>
这样的话就要让我们的用户标识是数字才行,如果是用guid做的用户标识就要做一定的处理将其转化成数字,这样方便我们
在给用户设置是否登陆。现在假设我们的用户标识是从1~1000。用户标识对应的就是在key中的偏移量。这时我们就会得到每天
对应的二进制序列,然后就可以用bitop命令去得到逻辑与运算之后的key/value。如果这个key对应偏移量(用户标识)是1,就是
连续登陆了七天,处理的逻辑是十分简单的。控制器简单逻辑如下:
[HttpPost]
public IActionResult LoginForEveryday()
{
var tran = _redis.GetTransaction(); for (int i = ; i < ; i++)
{
for (int j = ; j < ; j++)
{
//i day,j userId
SetBit(i, j, tran);
}
}
tran.Execute();
//get the result
_redis.BitOP(_bitWise, _res, _redisKeys.ToArray());
IList<int> res = new List<int>();
for (int i = ; i < ; i++)
{
if (_redis.GetBit(_res, i) == true)
{
res.Add(i);
}
}
return Json(new { code = "", data = res, count = res.Count });
} private void SetBit(int day, int userId, StackExchange.Redis.ITransaction tran)
{
switch (day)
{
case :
if (_rd.Next(, ) > )
{
tran.StringSetBitAsync(_first, userId, true);
}
else
{
tran.StringSetBitAsync(_first, userId, false);
}
break;
case :
if (_rd.Next(, ) > )
{
tran.StringSetBitAsync(_second, userId, true);
}
else
{
tran.StringSetBitAsync(_second, userId, false);
}
break;
case :
if (_rd.Next(, ) > )
{
tran.StringSetBitAsync(_thrid, userId, true);
}
else
{
tran.StringSetBitAsync(_thrid, userId, false);
}
break;
case :
if (_rd.Next(, ) > )
{
tran.StringSetBitAsync(_fourth, userId, true);
}
else
{
tran.StringSetBitAsync(_fourth, userId, false);
}
break;
case :
if (_rd.Next(, ) > )
{
tran.StringSetBitAsync(_fifth, userId, true);
}
else
{
tran.StringSetBitAsync(_fifth, userId, false);
}
break;
case :
if (_rd.Next(, ) > )
{
tran.StringSetBitAsync(_sixth, userId, true);
}
else
{
tran.StringSetBitAsync(_sixth, userId, false);
}
break;
case :
if (_rd.Next(, ) >)
{
tran.StringSetBitAsync(_seventh, userId, true);
}
else
{
tran.StringSetBitAsync(_seventh, userId, false);
}
break;
default:
break;
}
}
可以看到76和991这两个偏移量(用户标识)对应的二进制位是1,也验证了其连续登陆了7天。当然,更多的明细数据也贴出来了
方案 | 优点 | 缺点 |
以用户为维度 | 1.可以无缝对接,无论用户标识是数字还是其他 2.key对应的数据较少便于观察 |
随着用户数量的增长,要管理的key会越来越多 |
以天数为维度 | 1.有确定数量的key,方便管理 2.key对应的基数大 |
1.偏移量可能需要根据实际情况处理 2.数据查看不是很清晰 |
可至于实际中用那种方案更合适,要根据情况来选择。用户量少的时候,可以用第一种方案,也可以用第二种方案,当用户量很大的时候,