关于Redis知识总结

1，redis的五种数据类型及应用场景

1，String: 一般做一些复杂的计数功能的缓存
2，List: 做简单的消息队列的功能
3，Hash: 单点登录
4，Set: 做全局去重的功能
5，SortedSet: 做排行榜应用，取TopN操作；延时任务；做范围查找

2，Redis的事务

概念：
Redis事务的本质是一组命令的集合，事务支持一次执行多个命令，一个事务中所有的命令都会被序列化。在事务执行过程，会按照串行化执行队列中的命令，其他客户端的命令请求不会插入打我事务执行命令中
总结：redis事务就时一次性，排序性，排他性的执行一个队列中的一系列命令

Redis事务的三个阶段：
1，开始事务
2，命令入队
3，执行事务

Redis事务相关命令：
1，watch key1 key2… ：监视一个或多个key，如果在事务执行之前，被监视的key被其他的命令改动，则事务被打断，类似于乐观锁
2，multi：标记一个事务的开始（queued）
3，exec：执行所有的事务块的命令（一旦执行exec后，之前加的监控锁都会被取消掉）
4，discard：取消事务，放弃事务块中的所有命令
5，unwatch：取消watch对所有key的监控

Redis事务使用案例：
1，正常执行

2，放弃事务

3，若在事务队列中存在命令行错误（类似于java编译性报错），则执行exec命令时，所有命令都不会执行

4，若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。

5，使用watch命令
案例一：使用watch检测balance，事务期间balance数据未变动，事务执行成功

案例二：使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。

一但执行 EXEC 开启事务的执行后，无论事务使用执行成功， WARCH 对变量的监控都将被取消。
故当事务执行失败后，需重新执行WATCH命令对变量进行监控，并开启新的事务进行操作。

总结：
　　watch指令类似于乐观锁，在事务提交时，如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改，则使用EXEC执行事务时，事务队列将不会被执行，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
参考：redis的事务

3，Redis常见问题

1，缓存穿透
高并发情况下。短时间内请求会被穿透，请求直接打到数据库上，导致数据库压力过大

解决方案： 对代码上锁，双重检索

2，缓存击穿
高并发情况下，如果查询不存在的数据，因为缓存和数据库都不存在，请求都会打到数据库上，可能导致系统崩溃

解决方案：
1，设置不存在的数据到缓存中，设置一定的过期时间
2，布隆过滤器（直接过滤不存在数据的请求），不能准确判断数据是否存在数据，能准确判断数据不存在

3，缓存雪崩
高并发情况下，缓存服务器重启或特点数据同时过期，全部访问数据库，导致数据库宕机

解决方案：
1，配置缓存集群
2，给热点数据设置不一样的过期时间，相对均匀

4，Redis的存储

问题一：redis 如果用string hash存储一个对象，哪个更容易取对象的属性？
现有一个有多属性的对象，如何在redis中存储比较合适？
例如：user ： { id , name , sex , age , …}
取决于业务场景，在多数访问中是取该对象的所有属性还是只需要该对象的某些属性？

1， 使用String :
用 user + id 作为 key ， 其他属性编码为JSON，作为value存储。例如：

SET user:{id} ‘{“name”:“Fred”,“age”:25}’

每次都能通过 id属性精准的找到对应user的所有属性
优点：通过id精确查找，速度很快，合适查找单个对象所有属性的业务情景。
缺点：若只访问单个属性，需解析JSON ， 相比之下较慢 。

2，使用 Hash:
使用 users 作为 key + id作为 key ， 其他属性的key作为 field ， 属性的值作为value ，建立一个hash 存储所有的user

HMSET user:{id} name “Fred” HMSET user:{id} age 25

优点： 无需解析JSON字符串 ，适合每次查只需要user的单个属性。
缺点： 查找多个属性时要多次查找，不合适。