当前位置：首页 > news >正文

做游戏脚本的网站百度网站

news 2025/7/7 7:30:33

做游戏脚本的网站,百度网站,麻城网站设计,最优惠的郑州网站建设目录 1.什么是Redis？ 2.为什么要使用Redis？ 3.Redis为什么这么快？ 4.Redis的使用场景有哪些？ 5.Redis的基本数据类型 5.1 5种基础数据类型 5.1.1 String字符串 5.1.2 List列表 5.1.3 Set集合 5.1.4 Hash散列 5.1.5 Zset有序集…

1.什么是Redis？

2.为什么要使用Redis？

3.Redis为什么这么快？

4.Redis的使用场景有哪些？

5.Redis的基本数据类型

5.1 5种基础数据类型

5.1.1 String字符串

5.1.2 List列表

5.1.3 Set集合

5.1.4 Hash散列

5.1.5 Zset有序集合

5.2 3种特殊数据类型

5.3 Stream详解

6.Redis基础常见问题

1.什么是Redis？

Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。与传统数据库不同的是 Redis 的数据是存在内存中的（内存数据库），读写速度非常快，被广泛应用于缓存，事件发布或订阅，高速队列等场景。支持网络，提供字符串，哈希，列表，队列，集合结构直接存取，基于内存，可持久化。

Redis 与其他 key - value 缓存产品有以下三个特点：

Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list（列表），set（集合），zset（有序集合），hash（哈希表）等数据结构的存储。
Redis支持数据的备份，即master-slave（主从模式）模式的数据备份。

zset原为sorted set。为了避免sorted set简写sset导致命令冲突，所以改为zset。

Redis 没有外部依赖，Linux 和 OS X 是 Redis 开发和测试最多的两个操作系统，官方推荐生产环境使用 Linux 部署 Redis。

个人学习的话，你可以自己本机安装 Redis 或者通过 Redis 官网提供的 Try Redis（进不去开梯子即可）来实际体验 Redis。

Redis官网:Redis

2.为什么要使用Redis？

读写性能优异
- Redis能读的速度是110000次/s,写的速度是81000次/s （测试条件见下一节）。
数据类型丰富
- Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
原子性
- Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
丰富的特性
- Redis支持 publish/subscribe, 通知, key 过期等特性。
持久化
- Redis支持RDB, AOF等持久化方式
发布订阅
- Redis支持发布/订阅模式
分布式
- Redis Cluster

3.Redis为什么这么快？

Redis 内部做了非常多的性能优化，比较重要的有下面 3 点：

Redis 基于内存，内存的访问速度是磁盘的上千倍；
Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，主要是单线程事件循环和 IO 多路复用（Redis 线程模式下篇会详细介绍）；
Redis 内置了多种优化过后的数据结构实现，性能非常高。

4.Redis的使用场景有哪些？

热点数据的缓存

缓存是Redis最常见的应用场景，之所有这么使用，主要是因为Redis读写性能优异。而且逐渐有取代memcached，成为首选服务端缓存的组件。而且，Redis内部是支持事务的，在使用时候能有效保证数据的一致性。

作为缓存使用时，一般有两种方式保存数据：

读取前，先去读Redis，如果没有数据，读取数据库，将数据拉入Redis。
插入数据时，同时写入Redis。

方案一：实施起来简单，但是有两个需要注意的地方：

避免缓存击穿。（数据库没有就需要命中的数据，导致Redis一直没有数据，而一直命中数据库。）
数据的实时性相对会差一点。

方案二：数据实时性强，但是开发时不便于统一处理。

当然，两种方式根据实际情况来适用。如：方案一适用于对于数据实时性要求不是特别高的场景。方案二适用于字典表、数据量不大的数据存储。

限时业务的应用

redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。

计数器相关问题

redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。

分布式锁

这个主要利用redis的setnx命令进行，setnx："set if not exists"就是如果不存在则成功设置缓存同时返回1，否则返回0 ，这个特性在很多后台中都有所运用，因为我们服务器是集群的，定时任务可能在两台机器上都会运行，所以在定时任务中首先通过setnx设置一个lock，如果成功设置则执行，如果没有成功设置，则表明该定时任务已执行。当然结合具体业务，我们可以给这个lock加一个过期时间，比如说30分钟执行一次的定时任务，那么这个过期时间设置为小于30分钟的一个时间就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。

在分布式锁的场景中，主要用在比如秒杀系统等。

延时操作

比如在订单生产后我们占用了库存，10分钟后去检验用户是否真正购买，如果没有购买将该单据设置无效，同时还原库存。由于redis自2.8.0之后版本提供Keyspace Notifications功能，允许客户订阅Pub/Sub频道，以便以某种方式接收影响Redis数据集的事件。所以我们对于上面的需求就可以用以下解决方案，我们在订单生产时，设置一个key，同时设置10分钟后过期，我们在后台实现一个监听器，监听key的实效，监听到key失效时将后续逻辑加上。

当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。

排行榜相关问题

关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。

比如点赞排行榜，做一个SortedSet, 然后以用户的openid作为上面的username, 以用户的点赞数作为上面的score, 然后针对每个用户做一个hash, 通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息，这个当时在实际运用中性能体验也蛮不错的。

点赞，好友等相互关系的存储

Redis 利用集合的一些命令，比如求交集、并集、差集等。

在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。

简单队列

由于Redis有list push和list pop这样的命令，所以能够很方便的执行队列操作。

5.Redis的基本数据类型

5.1 5种基础数据类型

首先对redis来说，所有的key（键）都是字符串。我们在谈基础数据结构时，讨论的是存储值的数据类型，主要包括常见的5种数据类型，分别是：String、List、Set、Zset、Hash。

5.1.1 String字符串

String是redis中最基本的数据类型，一个key对应一个value。

String类型是二进制安全的，意思是 redis 的 string 可以包含任何数据。如数字，字符串，jpg图片或者序列化的对象。

下图是一个String类型的实例，其中键为hello，值为world

实战场景

缓存：经典使用场景，把常用信息，字符串，图片或者视频等信息放到redis中，redis作为缓存层，mysql做持久化层，降低mysql的读写压力。
计数器：用户单位时间的请求数（简单限流可以用到）、页面单位时间的访问数。。
session：常见方案spring session + redis实现session共享

5.1.2 List列表

Redis中的List其实就是链表（Redis用双端链表实现List）

使用List结构，我们可以轻松地实现最新消息排队功能（比如新浪微博的TimeLine）。List的另一个应用就是消息队列，可以利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。

实战场景
- 微博TimeLine: 有人发布微博，用lpush加入时间轴，展示新的列表信息。
- 消息队列

5.1.3 Set集合

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

实战场景
- 标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人。
- 点赞，或点踩，收藏等，可以放到set中实现

5.1.4 Hash散列

Redis hash 是一个 string 类型的 field（字段）和 value（值）的映射表，hash 特别适合用于存储对象。

实战场景
- 缓存：能直观，相比string更节省空间，的维护缓存信息，如用户信息，视频信息等。

5.1.5 Zset有序集合

Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的, 但分数(score)却可以重复。有序集合是通过两种数据结构实现：

压缩列表(ziplist): ziplist是为了提高存储效率而设计的一种特殊编码的双向链表。它可以存储字符串或者整数，存储整数时是采用整数的二进制而不是字符串形式存储。它能在O(1)的时间复杂度下完成list两端的push和pop操作。但是因为每次操作都需要重新分配ziplist的内存，所以实际复杂度和ziplist的内存使用量相关
跳跃表（zSkiplist): 跳跃表的性能可以保证在查找，删除，添加等操作的时候在对数期望时间内完成，这个性能是可以和平衡树来相比较的，而且在实现方面比平衡树要优雅，这是采用跳跃表的主要原因。跳跃表的复杂度是O(log(n))。

实战场景
- 排行榜：有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行。

5.2 3种特殊数据类型

5.2.1 HyperLogLogs（基数统计）

这个结构可以非常省内存的去统计各种计数，比如注册 IP 数、每日访问 IP 数、页面实时UV、在线用户数，共同好友数等。

Redis 提供的 HyperLogLog 占用空间非常非常小，只需要 12k 的空间就能存储接近2^64个不同元素。这是真的厉害，并且，Redis 对 HyperLogLog 的存储结构做了优化，采用两种方式计数：

稀疏矩阵：计数较少的时候，占用空间很小。
稠密矩阵：计数达到某个阈值的时候，占用 12k 的空间。

Redis 官方文档中有对应的详细说明：

基数计数概率算法为了节省内存并不会直接存储元数据，而是通过一定的概率统计方法预估基数值（集合中包含元素的个数）。因此， HyperLogLog 的计数结果并不是一个精确值，存在一定的误差（标准误差为 0.81% ）。

实战场景
- 数量量巨大（百万、千万级别以上）的计数场景：热门网站每日/每周/每月访问 ip 数统计、热门帖子 uv 统计

5.2.2 Bitmap （位存储）

Bitmap 即位图数据结构，都是操作二进制位来进行记录，只有0 和 1 两个状态。

实战场景
- 需要保存状态信息（0/1 即可表示）的场景：用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。两个状态的，都可以使用 Bitmaps！

5.2.3 geospatial (地理位置)

主要用于存储地理位置信息，基于 Sorted Set 实现。通过 GEO 我们可以轻松实现两个位置距离的计算、获取指定位置附近的元素等功能。

实战场景
- 需要管理使用地理空间数据的场景：附近的人。

5.3 Stream详解

Redis5.0 中还增加了一个数据结构Stream，从字面上看是流类型，但其实从功能上看，应该是Redis对消息队列（MQ，Message Queue）的完善实现。

解释：

消费者组： Consumer Group,即使用 XGROUP CREATE 命令创建的，一个消费者组中可以存在多个消费者，这些消费者之间是竞争关系。
1. 同一条消息，只能被这个消费者组中的某个消费者获取。
2. 多个消费者之间是相互独立的，互不干扰。
消费者： Consumer 消费消息。
last_delivered_id： 这个id保证了在同一个消费者组中，一个消息只能被一个消费者获取。每当消费者组的某个消费者读取到了这个消息后，这个last_delivered_id的值会往后移动一位，保证消费者不会读取到重复的消息。
pending_ids：记录了消费者读取到的消息id列表，但是这些消息可能还没有处理，如果认为某个消息处理，需要调用ack命令。这样就确保了某个消息一定会被执行一次。
消息内容：是一个键值对的格式。
Stream 中消息的 ID： 默认情况下，ID使用 * ，redis可以自动生成一个，格式为 时间戳-序列号，也可以自己指定，一般使用默认生成的即可，且后生成的id号要比之前生成的大。