Redis应用|青训营
一、Redis基本工作原理
1.Redis(Remote dictionary server)
远程字典服务，支持网络，可基于内存亦可持久化的日志型、key-value数据库,并提供多种语言的API。并且会周期性的把更新的数据写到磁盘或把修改操作写入追加的记录文件，并在此基础上实现了master-slave(主从)同步。
2.Redis事务
Redis事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中的所有命令都会被序列化。在事务执行的过程中，会按照顺序串行化执行队列中的命令，其他客户端的命令请求不会插入到事务执行命令序列中。
3.基本工作原理
- 数据从内存中读写
- 数据保存到硬盘上防止重启数据丢失
二、Redis五大数据类型
Redis无论什么数据类型，在数据库中都是以键值对形式保存，并且所有的key键都是字符串，讨论的是value的数据类型。
1.String
- 可以存储字符串、数字、二进制数据
- 通常和expire配合使用
- 场景：存储计数、Session
- 设置过期时间、不存在设置操作
2.List
- 对链表两端进行压入和弹出操作
图片源于t.csdn.cn/JCh2z
3.Set
- 字符串的集合，在此基础上进行增删改查
- 集合成员是不可重复
- Redis中集合是通过哈希表实现的
4.Hash
- 包含键值对的无序散列表
- 相比string更节省空间
5.Zset
- 同散列一样，用于存储键值对
- 每个元素都会关联一个double类型的权重参数，使得元素能够有序排序 -通过哈希表实现，增删差都是O(1)的复杂度
三、注意事项
1.分布式锁
并发场景，要求一次只能有一个协程执行。执行完成后，其他等待中的协程才能执行。
2.大Key、热Key
-
string类型，value的字节数大于10KB即为大Key。Hash，Zset,List,Set等数据类型。由于大Key读取成本高，查询慢，主从复制异常，服务阻塞，无法响应正常要求。为了消除大Key所带来的危害，我们将大Key拆成多个小Key,将一个string拆成多个string。或者将value压缩写入Redis,读取时解压后再使用。压缩算法可以是gzip、snappy、lz4等。通常情况下一个压缩算法压缩率高，则解压耗时长。需要对实际数据进行测试后，选择一个合适算法。如果存储的是JSON字符串，可以考虑使用MessagePack进行序列化。
-
热Key:用户访问一个key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况。热Key没有明确的标准，QPS超过500就有可能识别为热Key。为了解决热Key,可以选择在访问Redis前，将业务服务侧设置为Localcache，来降低访问Redis的QPS。或者将热Key复制写入多份键值对，访问时访问多个key，但value是同一个。以此将QPS分散到不同实例上，降低负载。代价是，更新时需要更新多个key，存在数据短暂不一致的风险。
3.慢查询场景
容易导致Redis慢查询的操作：
- 批量操作一次性传入过多的key/value，如mset/hmset/sadd/等O(n)操作。建议单批次不要超过100，超过100之后性能下降明显。
- zset大部分命令O(log(n))，当大小超过5k以上时，简单的zzam/zerm也可能导致慢查询。
- 操作的单个value过大，超过10KB。即避免使用大Key。
- 对大key的delete/expire操作也可能导致慢查询，Redis4.0之前不支持异步删除unlink，大key删除会阻塞Redis。
4.缓存穿透、缓存雪崩
缓存穿透：热点数据查询绕过缓存，直接查询数据库
缓存雪崩：大量缓存同时过期
如何减少缓存穿透？
- 缓存空值：如一个不存在的user ID。这个id在缓存和数据库中都不存在，则可以缓存一个空值，下次再查缓存直接返空值。
- 布隆过滤器：通过bloom filter算法来存储合法key,得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值。
参考文献
本文参考于：
