使⽤redis的increment（）⽅法实现计数器功能案例
⼀直知道redis可以⽤来实现计数器功能，但是之前没有实际使⽤过，昨天碰到⼀个需求：⽤户扫码当天达到20次即提⽰：当⽇扫码次数达到上限！
当时就想到使⽤redis的递增⽅法increment()来实现计数器功能，⼀定要注意redisTemplate和stringRedisTemplate的使⽤
⾸先设置key：
该key我使⽤了⽤户id和当天⽇期作为key的⼀部分，date：xxxx-xx-xx格式，这样⼀来该⽤户在第⼆天扫码的时候⼜是⼀个新key，因为⽇期不同了
设置key的过期时间：
实现计数器功能：
通过使⽤上⾯的⽅法，redis的计数器功能就可以实现了。
在使⽤过程过遇到的问题：
在使⽤的过程中，⽼是会抛错：ERR value is not an integer or out of range
sql语句实现的四种功能
后来发现当时我使⽤的⽅法底层⽤的redisTemplate和stringRedisTemplate串了，当时setKey的时候⽤的⽅法底层是
stringRedisTemplate，后⾯我想get(key)的时候⽅法底层的模板使⽤的是redisTemplate，后⾯统⼀了⼀下模板的使⽤，然后计数
器功能正常运⾏不再抛错。
看过很多⽂章说是序列化器的锅，increment⽅法必须是stringRedisTemplate模板才能使⽤，但是我在实际使⽤的时候也确实是
⽤了redisTemplate，这个具体原因我还在看，此次使⽤中最主要的问题是setKey的时候使⽤的模板和取key的时候使⽤的模板不
⼀致导致的。写个笔记记录⼀下，⼀个坑不踩第⼆遍。⼤家如果遇到⼀样的问题可以⼀起讨论学习⼀下。
补充知识：认识redis：redis计数器与数量控制
这篇⽂章是我个⼈对redis的⼀些理解，可以帮助⼤家系统的认识redis。本⽂的⽬标读者是使⽤过redis，
但对redis了解不深的朋友。⽂章内容以redis为主，也会少量提到memcached。⽂章从redis的设计⽬的、⼯作模式、应⽤场景等⽅⾯阐述，最后会讲解⼀些具体的应⽤场景，还会夹带⼀些代码作为“⼲货”。
鉴于本⼈⽔平有限，⽂中如有不准确的内容，敬请斧正。
redis是什么
redis是⼀种内存型的数据存储器，使⽤场景
数据库
缓存
消息代理（message broker）
同memcached对⽐
memcached是分布式的内存对象缓存系统，设计意图为通过缓解数据库压⼒来加快web应⽤的响应速度。
上⾯的描述分别被放在了redis和memcached的官⽹⾸页最显眼的位置，这也回答了redis和memcached的本质区别。
redis的⼯作模式
redis的⼯作模式为单进程，这意味着redis只能利⽤到⼀个cpu内核。 redis对请求的处理是串⾏的，对于同时涌进来的多个请求，redis⾸先把请求存⼊队列，按请求到达的先后顺序串⾏处理。
了解单进程和串⾏这两个特点，有助于我们使⽤redis时“扬长避短”。
之前有同事提到过，为何redis不适合存储⼤块的数据？从redis的⼯作模式我们可以窥知⼀⼆：⼤块的数据意味着需要较长的io时间，包括内存io和⽹络的io，cpu资源在io过程中是⼀直被占⽤的，这会阻塞其它请求，从⽽影响redis的整体性能。
数据类型
⼤家对redis的数据类型已经⽐较熟悉了，主要有以下5种。
string
list
hash
set
sorted set
各种数据类型的常⽤操作
string
set，get，setnx，setex，psetex
拼接
增加、减少（整数型字符串）
位操作
list
⼊列，出列（这两个命令都有阻塞模式）
按排位获取部分元素
hash
设置某个索引
获取某个索引
增加/减少某个索引的值（整数型字符串）
获取所有索引的值
set
集合是⼀个数学概念，啰嗦提⼀下：集合中的元素都是唯⼀的
加⼊元素
删除元素
检查元素是否在集合
获取集合中的元素数量
取差集/并集/交集
元素转移（从集合a移⾄集合b）
zset
有序集合，每个元素都有⼀个分值，⽤于对元素进⾏排序
取交集/并集
获取⼀个元素的rank
获取分值在某个范围内的元素数量
获取分值在某个范围内的元素
按rank范围获取元素
redis事务
redis事务和我们熟悉的mysql事务有所区别，它们的相同在于都是对⼀个或⼀组命令的打包执⾏，不同的地⽅在于redis事务不可回滚。redis的事务具有原⼦性，⼀个事务的执⾏有两种结果
完全执⾏
完全不执⾏
⼀些不可抗⼒因素除外，如服务挂掉，服务器断电。redis事务是⼀个独⽴的请求，执⾏过程中会阻塞其它请求。
实现redis事务有以下两种⽅式
multi-exec
lua脚本
multi-exec
127.0.0.1:6380[1]> set counter1 1
OK
127.0.0.1:6380[1]> set counter2 2
OK
127.0.0.1:6380[1]> set counter3 3
OK
127.0.0.1:6380[1]>
127.0.0.1:6380[1]>
127.0.0.1:6380[1]> multi
OK
127.0.0.1:6380[1]> incr counter1
QUEUED
127.0.0.1:6380[1]> sadd counter2 1
QUEUED
127.0.0.1:6380[1]> incr counter3
QUEUED
127.0.0.1:6380[1]> exec
1) (integer) 2
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 4
从上⾯的事务执⾏输出可以看到，我们的sadd执⾏出错了，原因是操作的数据类型不正确，但redis没有中⽌整个事务，⽽是继续往下执⾏。redis这么做是有道理的，见参考⽂献1。
multi-exec和watch的组合可以实现类似于mysql事务的功能，如果被watch的key在事务执⾏前被修改了，redis会放弃执⾏事务。
lua脚本
和multi-exec相⽐，lua脚本的优势在于灵活性，也可以减少⼀定的⽹络时间消耗（为什么？）。
鉴于redis的⼯作模式，不建议⽤lua脚本实现耗时较长的事务。
下⾯模拟了lua脚本的执⾏阻塞其它请求的场景，⼤家可以亲⾃试⼀下。
client 1
eval "local i=0; while(i<1000000) do redis.call('keys', '*'); i=i+1; end" 0
client 2
incr counter
redis的实际应⽤
锁
类型：string
命令：setnx name alice |set name alice NX
返回true则锁定成功，否则锁定失败
了解了redis的⼯作模式，就知道为什么⽤redis实现锁是如此容易了。⽤memcache也可以实现锁，但代码层⾯要复杂⼀些，参见memcached.cas。
事件队列
类型：zset
命令：zadd，zrangebyscore，zrem
适合存储⼀些需要顺序处理的事件，将事件的score值设为时间戳或⾃增id即可。为什么⽤list不可以？
计数器
类型：string
命令：incr
抽奖限额
类型：string
命令：incrby
某活动的现⾦红包每天最多只能发送10000元。下⾯是这段逻辑的伪代码，如果能够举⼀反三，这段代码将⼤有⽤武之地。⼤家可以⽤并发测试⼯具测试这段代码，如果发现了bug，或者能有更好的实现⽅式，请不要告诉我 -_-
$key = 'max_amount';
$amountLimit = 10000;
if (!$currAmount = Redis::get($key)) {
$currAmount = 9990;    // 从持久化数据库获取当前已发放⾦额
// 初始化
Redis::setnx($key, $currAmount);
}
if ($currAmount >= $amountLimit) {
// 超出限额退出
}
// 抽奖⾦额
$rewardAmount = 10;
if ($rewardAmount > $amountLimit - $currAmount) {
$rewardAmount = $amountLimit - $currAmount;
}
if (Redis::incrby($key, $rewardAmount) > $amountLimit) {
// 超出限额退出
} else {
// 成功抽奖
}
初始化为何⽤setnx，⽤set可以吗？
最后为何使⽤incrby，不⽤可以吗？
总结
⽂章内容不多，所谓的⼲货更少，这和作者的⽔平有关，也和⽂章的定位有关。细⼼的朋友可能发现了，⽂中有⼀些内容是带有问号的，有兴趣的朋友可以加以思考。希望能给⼤家⼀个参考，也希望⼤家多多⽀持

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。