目录

  • 1 redis基础
    • redis 中的数据类型有哪些
    • 为什么说redis能够快速执行
  • 2 Redis中的五种数据结构
    • string (字符串)
    • list (列表)
    • set (集合)
    • hash (哈希)
    • zset (有序集合)
  • 3 Redis的持久化
    • Redis 的持久化机制
    • Redis 持久化方案的建议
    • Redis 持久化方案的优缺点
  • 4 缓存穿透、缓存击穿、缓存雪崩解决方案
    • 缓存穿透
    • 缓存击穿
    • 缓存雪崩
  • 5 Redis 的集群模式
    • 主从复制
    • 哨兵模式
  • 6 Redis分布式锁
    • 使用过Redis分布式锁么，它是什么回事？
    • 红锁
  • 7 一些问题
    • 内存淘汰机制
    • Redis 和 Mysql 的数据不一致怎么办
    • Redis常见性能问题和解决方案：
    • mySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据
    • Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？
    • 项目中有没有用Redis事务
    • 布隆过滤器
    • redis 跳表原理
    • 一致性hash算法
  • 8 参考

1 redis基础

redis 中的数据类型有哪些

Redis 有 5 种基础数据结构，分别为：string (字符串)、list (列表)、set (集合)、hash (哈希) 和 zset (有序集合)。

Redis 的列表相当于 Java 语言里面的 LinkedList，注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为 O(n)，这点让人非常意外。 当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收。

Redis 的哈希相当于 Java 语言里面的 HashMap，它是无序字典。内部实现结构上同 Java 的 HashMap 也是一致的，同样的数组 + 链表二维结构。第一维 hash 的数组位置碰撞时，就会将碰撞的元素使用链表串接起来。

Redis 的集合相当于 Java 语言里面的 HashSet，它内部的键值对是无序的唯一的。它的内部实现相当于一个特殊的字典，字典中所有的 value 都是一个值NULL。 当集合中最后一个元素移除之后，数据结构自动删除，内存被回收。

zset 类似于 Java 的 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以给每个 value 赋予一个 score，代表这个 value 的排序权重。

为什么说redis能够快速执行

i. 绝大部分请求是纯粹的内存操作（非常快速）

ii. 采用单线程,避免了不必要的上下文切换和竞争条件

iii. 非阻塞IO - IO多路复用

2 Redis中的五种数据结构

string (字符串)

redis是使用C语言开发，但C中并没有字符串类型，只能使用指针或符数组的形式表示一个字符串，所以redis设计了一种简单动态字符串(SDS[Simple Dynamic String])作为底实现：

定义SDS对象，此对象中包含三个属性：

  • len buf中已经占有的长度(表示此字符串的实际长度)
  • free buf中未使用的缓冲区长度
  • buf[] 实际保存字符串数据的地方

所以取字符串的长度的时间复杂度为O(1)，另，buf[]中依然采用了C语言的以\0结尾可以直接使用C语言的部分标准C字符串库函数。

空间分配原则：当len小于IMB（1024*1024）时增加字符串分配空间大小为原来的2倍，当len大于等于1M时每次分配 额外多分配1M的空间。

由此可以得出以下特性：

  • redis为字符分配空间的次数是小于等于字符串的长度N，而原C语言中的分配原则必为N。降低了分配次数提高了追加速度，代价就是多占用一些内存空间，且这些空间不会自动释放。
  • 二进制安全的
  • 高效的计算字符串长度(时间复杂度为O(1))
  • 高效的追加字符串操作。

list (列表)

redis对键表的结构支持使得它在键值存储的世界中独树一帜，一个列表结构可以有序地存储多个字符串，拥有例如：lpush lpop rpush rpop等等操作命令。在3.2版本之前，列表是使用ziplist和linkedlist实现的，在这些老版本中，当列表对象同时满足以下两个条件时，列表对象使用ziplist编码：

  • 列表对象保存的所有字符串元素的长度都小于64字节
  • 列表对象保存的元素数量小于512个

当有任一条件 不满足时将会进行一次转码，使用linkedlist。

而在3.2版本之后，重新引入了一个quicklist的数据结构，列表的底层都是由quicklist实现的，它结合了ziplist和linkedlist的优点。按照原文的解释这种数据结构是【A doubly linked list of ziplists】意思就是一个由ziplist组成的双向链表。那么这两种数据结构怎么样结合的呢？

ziplist的结构

由表头和N个entry节点和压缩列表尾部标识符zlend组成的一个连续的内存块。然后通过一系列的编码规则，提高内存的利用率，主要用于存储整数和比较短的字符串。可以看出在插入和删除元素的时候，都需要对内存进行一次扩展或缩减，还要进行部分数据的移动操作，这样会造成更新效率低下的情况。

这篇文章对ziplist的结构讲的还是比较详细的：

https://blog.csdn.net/yellowriver007/article/details/79021049

linkedlist的结构

意思为一个双向链表，和普通的链表定义相同，每个entry包含向前向后的指针，当插入或删除元素的时候，只需要对此元素前后指针操作即可。所以插入和删除效率很高。但查询的效率却是O(n)[n为元素的个数]。

了解了上面的这两种数据结构，我们再来看看上面说的“ziplist组成的双向链表”是什么意思？实际上，它整体宏观上就是一个链表结构，只不过每个节点都是以压缩列表ziplist的结构保存着数据，而每个ziplist又可以包含多个entry。也可以说一个quicklist节点保存的是一片数据，而不是一个数据。总结：

  • 整体上quicklist就是一个双向链表结构，和普通的链表操作一样，插入删除效率很高，但查询的效率却是O(n)。不过，这样的链表访问两端的元素的时间复杂度却是O(1)。所以，对list的操作多数都是poll和push。
  • 每个quicklist节点就是一个ziplist，具备压缩列表的特性。

set (集合)

redis的集合和列表都可以存储多个字符串，它们之间的不同在于，列表可以存储多个相同的字符串，而集合则通过使用散列表（hashtable）来保证自已存储的每个字符串都是各不相同的(这些散列表只有键，但没有与键相关联的值)，redis中的集合是无序的。还可能存在另一种集合，那就是intset，它是用于存储整数的有序集合，里面存放同一类型的整数。共有三种整数：int16_t、int32_t、int64_t。查找的时间复杂度为O(logN)，但是插入的时候，有可能会涉及到升级（比如：原来是int16_t的集合，当插入int32_t的整数的时候就会为每个元素升级为int32_t）这时候会对内存重新分配，所以此时的时间复杂度就是O(N)级别的了。注意：intset只支持升级不支持降级操作。

intset在redis.conf中也有一个配置参数set-max-intset-entries默认值为512。表示如果entry的个数小于此值，则可以编码成REDIS_ENCODING_INTSET类型存储，节约内存。否则采用dict的形式存储。

hash (哈希)

hash底层的数据结构实现有两种：

  • 一种是ziplist，上面已经提到过。当存储的数据超过配置的阀值时就是转用hashtable的结构。这种转换比较消耗性能，所以应该尽量避免这种转换操作。同时满足以下两个条件时才会使用这种结构：

    • 当键的个数小于hash-max-ziplist-entries（默认512）
    • 当所有值都小于hash-max-ziplist-value（默认64）
  • 另一种就是hashtable。这种结构的时间复杂度为O(1)，但是会消耗比较多的内存空间。

zset (有序集合)

有序集合和散列一样，都用于存储键值对：有序集合的键被称为成员（member),每个成员都是各不相同的。有序集合的值则被称为分值（score），分值必须为浮点数。有序集合是redis里面唯一一个既可以根据成员访问元素(这一点和散列一样),又可以根据分值以及分值的排列顺序访问元素的结构。它的存储方式也有两种：

  • 是ziplist结构。

与上面的hash中的ziplist类似，member和score顺序存放并按score的顺序排列

  • 另一种是skiplist与dict的结合。

skiplist是一种跳跃表结构，用于有序集合中快速查找，大多数情况下它的效率与平衡树差不多，但比平衡树实现简单。redis的作者对普通的跳跃表进行了修改，包括添加span\tail\backward指针、score的值可重复这些设计，从而实现排序功能和反向遍历的功能。

一般跳跃表的实现，主要包含以下几个部分：

  • 表头（head）：指向头节点
  • 表尾（tail）：指向尾节点
  • 节点（node）：实际保存的元素节点，每个节点可以有多层，层数是在创建此节点的时候随机生成的一个数值，而且每一层都是一个指向后面某个节点的指针。
  • 层（level）：目前表内节点的最大层数
  • 长度（length）：节点的数量。

跳跃表的遍历总是从高层开始，然后随着元素值范围的缩小，慢慢降低到低层。

跳跃表的实现原理可以参考：https://blog.csdn.net/Acceptedxukai/article/details/17333673

前面也说了，有序列表是使用skiplist和dict结合实现的，skiplist用来保障有序性和访问查找性能，dict就用来存储元素信息，并且dict的访问时间复杂度为O(1)。

3 Redis的持久化

Redis 的持久化机制

RDB持久化

RDB持久化即通过创建快照（压缩的二进制文件）的方式进行持久化，保存某个时间点的全量数据。RDB持久化是Redis默认的持久化方式。RDB持久化的触发包括手动触发与自动触发两种方式。

AOF持久化

AOF（Append-Only-File）持久化即记录所有变更数据库状态的指令，以append的形式追加保存到AOF文件中。在服务器下次启动时，就可以通过载入和执行AOF文件中保存的命令，来还原服务器关闭前的数据库状态。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。该方案的优点是充分利用了RDB加载快、备份文件小及AOF尽可能不丢数据的特性。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

Redis 持久化方案的建议

如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。

如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用RDB。

通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

Redis 持久化方案的优缺点

RDB持久化

优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。

4 缓存穿透、缓存击穿、缓存雪崩解决方案

缓存穿透

指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。

解决方案：

i. 查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短

ii. 布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对 DB 的查询。

缓存击穿

对于设置了过期时间的 key，缓存在某个时间点过期的时候，恰好这时间点对这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案：

i. 使用互斥锁：当缓存失效时，不立即去 load db，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db 的操作并回设缓存，否则重试 get 缓存的方法。

ii 永远不过期：物理不过期，但逻辑过期（后台异步线程去刷新）。

缓存雪崩

设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到 DB， DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多 key，击穿是某一个key 缓存。

解决方案：

将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

5 Redis 的集群模式

主从复制

当从数据库启动时，会向主数据库发送sync命令，主数据库接收到sync后开始在后台保存快照rdb，在保存快照期间收到的命令缓存起来，当快照完成时，主数据库会将快照和缓存的命令一块发送给从**。复制初始化结束。 之后，主每收到1个命令就同步发送给从。 当出现断开重连后，2.8之后的版本会将断线期间的命令传给重数据库。增量复制

主从复制是乐观复制，当客户端发送写执行给主，主执行完立即将结果返回客户端，并异步的把命令发送给从，从而不影响性能。也可以设置至少同步给多少个从主才可写。 无硬盘复制:如果硬盘效率低将会影响复制性能，2.8之后可以设置无硬盘复制，repl-diskless-sync yes

哨兵模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Hzcc1bJo-1613794914158)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/3e8c3ce5-a43d-45f0-a384-90ecc42dbaff/Untitled.png)]

哨兵的作用：

1、监控redis主、从数据库是否正常运行

2、主出现故障自动将从数据库转换为主数据库。

哨兵的核心知识

1、哨兵至少需要 3 个实例，来保证自己的健壮性。

2、哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。

3、对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

4、配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。

6 Redis分布式锁

使用过Redis分布式锁么，它是什么回事？

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。

如果在setnx之后执行expire之前进程意外crash或者要重启维护了，这个锁就永远得不到释放了，使用set指令把setnx和expire合成一条指令来用

红锁

用Redis中的多个master实例，来获取锁，只有大多数实例获取到了锁，才算是获取成功。具体的红锁算法分为以下五步：

  1. 获取当前的时间（单位是毫秒）。
  2. 使用相同的key和随机值在N个节点上请求锁。这里获取锁的尝试时间要远远小于锁的超时时间，防止某个masterDown了，我们还在不断的获取锁，而被阻塞过长的时间。
  3. 只有在大多数节点上获取到了锁，而且总的获取时间小于锁的超时时间的情况下，认为锁获取成功了。
  4. 如果锁获取成功了，锁的超时时间就是最初的锁超时时间进去获取锁的总耗时时间。
  5. 如果锁获取失败了，不管是因为获取成功的节点的数目没有过半，还是因为获取锁的耗时超过了锁的释放时间，都会将已经设置了key的master上的key删除。

7 一些问题

内存淘汰机制

redis 内存淘汰机制有以下几个：

  • noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了。
  • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
  • allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的 key 给干掉啊。
  • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key（这个一般不太合适）。
  • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
  • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

Redis 和 Mysql 的数据不一致怎么办

采用延时双删策略

  1. 第二个删redis。如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
  2. 第一个删redis。如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。
public void use(String key, Object data){redis.delKey(key);db.updateData(data);Thread.sleep(800);redis.delKey(key);
}

（1）先淘汰缓存

（2）再写数据库（这两步和原来一样）

（3）休眠800ms，再次淘汰缓存

这么做，可以将800ms内所造成的缓存脏数据，再次删除。

Redis常见性能问题和解决方案：

i. Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件；(Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照;AOF文件过大会影响Master重启的恢复速度)

ii. 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

iii. 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

iv. 尽量避免在压力很大的主库上增加从库

v. 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…；这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

mySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

注意这里的6种机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的lru、ttl以及random是三种不同的淘汰策略，再加上一种no-enviction永不回收的策略。

使用策略规则：

1、如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru

2、如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

项目中有没有用Redis事务

采用的是Redis Cluster集群架构，不同的key是有可能分配在不同的Redis节点上的，在这种情况下Redis的事务机制是不生效的。其次，Redis事务不支持回滚操作，所以基本不用！

布隆过滤器

5 分钟搞懂布隆过滤器，亿级数据过滤算法你值得拥有！

redis 跳表原理

一文彻底搞懂跳表的时间复杂度、实现原理以及应用场景

一致性hash算法

一致性Hash原理与实现

8 参考

可能没记全，如果有拉下的，请提醒后续补上

https://blog.csdn.net/bird73/article/details/79792548

https://www.cnblogs.com/spec-dog/p/12466276.html

https://blog.csdn.net/xpsallwell/article/details/84030285

2021年Redis面试题（持续更新）相关推荐

  1. Dubbo面试题及答案，2021年Dubbo面试题-持续更新中

    2021最新Dubbo面试题[附答案解析]Dubbo面试题及答案2021,Dubbo最新面试题及答案,Dubbo面试题新答案已经全部更新完了,有些答案是自己总结的,也有些答案是在网上搜集整理的.这些答 ...

  2. Redis面试题及答案（2021年Redis面试题大全带答案）

    最近梳理2021最新 Redis面试题[附答案解析],包含了 Java基础.并发.JVM.数据库.Spring.SpringMVC.Redis.SpringCloud.设计模式.MQ.Linux.Re ...

  3. Redis 知识点和面试题(持续更新ing)

    推荐 书籍 <Redis实战>,<Redis设计与实现>,<Redis使用手册> 视频 [[趣话Redis第二弹]Redis数据持久化AOF和RDB原理一次搞懂!- ...

  4. SpringBoot面试题大汇总附答案，SpringBoot面试题-持续更新中

    2021最新SpringBoot面试题[附答案解析]SpringBoot面试题及答案2021,SpringBoot2021最新面试题及答案,SpringBoot面试题新答案已经全部更新完了,有些答案是 ...

  5. 2021好看小说推荐（持续更新中）

    2021好看小说推荐<持续更新中> 我师兄实在太稳健了(完结,字数:364万) 踏星(连载中,字数:1382万) 万族之劫(完结,字数:830万) 三寸人间(连载中,字数:350万) 大奉 ...

  6. 前端javaScript高频面试题——持续更新

    目录 1.== 和 ===区别,分别在什么情况使用 2. 判断数据类型的方法 3.说说JavaScript中的数据类型?存储上的差别? 4.JavaScript中的操作符 5.var,let,cons ...

  7. 达州铭仁园2021年高考成绩查询,持续更新！达州各县市区中学2019年高考成绩报喜了...

    原标题:持续更新!达州各县市区中学2019年高考成绩报喜了 四川2019年高考成绩于22日晚公布 达州各县市区高中2019年高考成绩陆续揭晓, 昨日,小编已经收集了部分学校高考喜报 今日,小编又收集了 ...

  8. java面试题之-Redis篇（持续更新）

    文章目录 Redis基础 01.Redis里有哪些数据类型? 02.Redis为什么能够快速执行? 03.那Redis怎样防止异常数据不丢失的(Redis的如何持久化)? 04.缓存穿透.缓存击穿.缓 ...

  9. java史上最全面试题--持续更新中（一）

    1.面向对象的特征有哪些方面? 抽象:将同类对象的共同特征提取出来构造类. 继承:基于基类创建新类. 封装:将数据隐藏起来,对数据的访问只能通过特定接口. 多态性:不同子类型对象对相同消息作出不同响应 ...

最新文章

  1. 理想的教育是从父母自我改变开始
  2. Vue中实现检测当前是否为IE模式(极速模式还是兼容模式)
  3. Vmware Vsphere虚拟化技术：6.7新特性介绍
  4. 商品管理后台html,商品类型管理.html
  5. bzoj 1634: [Usaco2007 Jan]Protecting the Flowers 护花（贪心排序）
  6. Mysql 高负载排查思路
  7. FastAPI用户安全性解决方案
  8. 小程序--下拉刷新/上拉触底
  9. 写论文word生成目录
  10. scrapy settings和管道的深入
  11. 固定成本、可变成本、沉没成本、机会成本
  12. 黑苹果登录apple id_充分利用Apple登录功能
  13. 微波放大器和混频器的测试
  14. Redis过期键删除策略
  15. 【012】基于51单片机的可燃气体报警装置proteus仿真与实物设计
  16. 一文读懂 | 数据中台如何为企业赋能？
  17. 怎么用计算机弹出光年之外,明日之后光年之外简谱代码-明日之后光年之外怎么弹-明日之后光年之外钢琴曲谱分享_牛游戏网...
  18. Anaconda 安装及使用
  19. hdu 4544 优先队列
  20. MySQL密码忘记了如何操作

热门文章

  1. 单点登录解决方案--网关、认证、鉴权
  2. [Android]开机自启动脚本和selinux权限配置
  3. 五行与情志的之间的相生相克
  4. STC51单片机21——EEPROM测试
  5. mysql数据库替换语句_Mysql数据库字符串替换常用语句
  6. 「深入源码」Spring拦截器的实现原理和执行机制
  7. linux7 epel源,CentOS7安装EPEL源
  8. 韩语计算机级词汇表,韩语考试TOPIK单词整理中级（十）
  9. 关于开发app内部阅读pdf文件
  10. java实现fifo算法_java算法：FIFO队列