很多Java工程师都会遇到因为需要操作数据库，但是很多系统都不会存在高并发的问题，这样并没有任何需要解决的问题
随着分布式高并发架构的出现，给我们程序员增加了很多挑战
随着电商时代的到来，涌现出一些大数据量的市场需求，比如秒杀的情景，某一功能单位时间内访问频率非常大的时候，仅仅只是使用数据库来保存数据的系统会因为磁盘读写问题减弱了整体的性能
单位时间内千万级的访问量请求的时候，需要系统非常短的时间内完成请求的逻辑操作，这样的访问数组库远远不能支撑，会造成整个系统的瘫痪
针对于这个问题的解决方案不言而喻，一般是采用一个nosql数据库，我们会想到使用redis缓存来解决这个问题，redis是基于内存的数据库，并却具有一定范围时就内的持久化功能
我们来看一下redis常用的五种表格数据类型，需要注意的是redis不仅仅是这五种
我们来看一下这五种类型分别适用场景
String应用场景
单值缓存
SET Key Value
GET Key
如电商场景秒杀功能经常需要把库存放到redis缓存中去，这个用的一般都是string类型的
key作为商品id，value作为库存
阅读数
实现原值+1
INCR article:readcount:文章的id
对象缓存
SET user:1 value(json格式数据)
MSET user:1:name zhuge user:1:balance 18888
MSET适用场景是当需要修改balance字段的时候
分布式锁
先来了解一个setnx命令
格式：setnx key value
将key的值设为value，当且仅当key不存在
若给定的key已经存在，则setnx不做任何操作
SETNX product:10010 true 返回1代表获取锁成功
SETNX product:10010 false 返回0代表获取锁失败
..........................................................................执行业务操作
DEL product：10010 删除锁也称为释放锁
SET product:10010 true ex 10 nx 防止程序意外终止导致死锁
hash应用场景
对象缓存
HMSET user {userId}:name zhuge {userId}:balance 18888
HMSET user 1:name zhuge 1:balance 18888
HMGET user 1:name 1:balance
电商购物车
用户id为key
商品id为field
商品数量为value
购物车操作
添加商品-->hset cart:10010 10088 1
增加数量-->hincrby cart:10010 10088 1
商品总数-->hlen cart:10010
删除商品-->hdel cart:10010 10088
获取购物车所有商品-->hgetall cart:10010
hash比较string的优缺点
优点：
1.同类数据归类存储，方便数据管理
2.相比string操作消耗内存和cpu更小
3.相比string存储更节省空间
缺点：
1.过期功能不能使用filed上，只能用在key上
2.redis集群架构下不适合大规模使用
list应用场景
微博消息和微信公众号消息
zhuge老师关注了刘亦菲liu和娜扎nz大V
liu发微博消息id为10000
LPUSH msg{诸葛id} 10000
nz发微博消息id为：10010
LPUSH msg{诸葛id} 10010
查看最新微博消息
LRANGE msg {诸葛老师id} 0 5
set应用场景
微信抽奖小程序
1.点击参与抽奖加入集合
SADD key {userId}
2.查看参与抽奖所有用户
SMEMBERS key
3.抽取conut名中奖者
ARANDMEMBER key [count]/SPOP key [count] 值得注意的是这个只适用颁布中间号一次，因为这个不会删除会累积中奖号
微信微博点赞，收藏，标签
1.点赞
SADD like:{消息id} {用户id}
2.取消点赞
SREM like:{消息id} {用户id}
3.检查用户是否点过赞
SISMEMBER like:{消息id} {用户id}
4.获取点赞的用户列表
SMEMBERS like:{消息id}
5.获取点赞用户数
SCARD like:{消息id}
zset应用场景
zset有续集合操作实现排行榜
1.点击新闻
ZINCRBY hotNews:20190819 1 守护香港
2.展示当日排行前十
ZREVRANGE hotNews:20190819 0 9 WITHSCORES
