Redis篇

文章目录

  • Redis-使用场景
    • 1、缓存穿透
    • 2、缓存击穿
    • 3、缓存雪崩
    • 4、双写一致
    • 5、Redis持久化
    • 6、数据过期策略
    • 7、数据淘汰策略
  • Redis-分布式锁
    • 1、redis分布式锁,是如何实现的?
    • 2、redisson实现的分布式锁执行流程
    • 3、redisson实现的分布式锁-可重入
    • 4、redisson实现的分布式锁-主从一致性
  • Redis-其他面试题
    • 1、Redis集群有哪些方案?
      • 1.1 主从复制
      • 1.2 哨兵模式
        • 1.2.1、redis集群(哨兵模式)脑裂
      • 1.3 分片集群结构
    • 2、Redis是单线程的,但是为什么还那么快
    • 3、能解释一下I/O多路复用模型?
    • 4、网络模型-Redis是单线程的吗?为什么使用单线程?
    • 5、Redis的单线程模型-Redis单线程和多线程网络模型变更

Redis-使用场景

1、缓存穿透

出现原因:

查询一个不存在的数据,mysql查询不到数据也不会直接写入缓存,就会导致每次请求都查数据库。
在这里插入图片描述

  1. 缓存空数据

原理:缓存空数据,查询返回的数据为空,仍把这个空结果进行缓存
在这里插入图片描述
优点:简单

缺点: 消耗内存,可能会发生不一致的问题

  1. 布隆过滤器

原理:在进行缓存预热时,同时也会预热过滤器,当查询一个不存在的数据时,会经过过滤器查询是否存在,若不存在,则直接返回,不会去查询redis,也不会去查数据库。
在这里插入图片描述
布隆过滤器的过滤流程:

原理就是将请求元素进行(3次)多次哈希,记录哈希值为1的区域,下次查询会根据请求元素计算的哈希值位置都为1 来判断是否需要去查询redis。
在这里插入图片描述
误判情况:

误判率:数组越小误判率就越大,数组越大误判率就越小,但是同时带来了更多的内存消耗。
在这里插入图片描述


2、缓存击穿

出现原因: 给某一个key设置了过期时间,当key过期的时候,恰好这时间点对这个key有大量的并发请求过来,这些并发的请求可能会瞬间把DB压垮

在这里插入图片描述

  1. 解决方案一:互斥锁

原理就是当线程一进来去redis查询数据时,数据过期了,这时候线程一就会加上一把互斥锁,别的线程进来获得锁失败只能休眠或者重试,当线程一进行缓存重建完成后,会释放锁,别的线程进来也可以查到数据了。
在这里插入图片描述

  1. 解决方案二:逻辑过期

原理就是:
①:在设置key的时候,设置一个过期时间字段一块存入缓存中,不给当前key设置过期时间
②:当查询的时候,从redis取出数据后判断时间是否过期
③:如果过期则开通另外一个线程进行数据同步,当前线程正常返回数据,这个数据不是最新
在这里插入图片描述


3、缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力。

  1. 大量的缓存key同时失效
    在这里插入图片描述
    给不同的Key的TTL添加随机值

  2. Redis服务宕机
    在这里插入图片描述


4、双写一致

双写一致性:当修改了数据库的数据也要同时更新缓存的数据,缓存和数据库的数据要保持一致。

  1. 延迟双删

在这里插入图片描述
延迟双删,如果是写操作,我们先把缓存中的数据删除,然后更新数据库,最后再延时删除缓存中的数据,其中这个延时多久不太好确定,在延时的过程中可能会出现脏数据,并不能保证强一致性,所以没有采用它。

参考链接:redis的延迟双删策略总结------作者:Hellboy_M

  1. 分布式锁

在这里插入图片描述
又分为共享锁排他锁:

在这里插入图片描述
采用的是redisson实现的读写锁,在读的时候添加共享锁,可以保证读读不互斥,读写互斥。当我们更新数据的时候,添加排他锁,它是读写,读读都互斥,这样就能保证在写数据的同时是不会让其他线程读数据的,避免了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。

  1. 异步通知
    在这里插入图片描述
  2. 基于Canal的异步通知
    在这里插入图片描述
    采用的阿里的canal组件实现数据同步:不需要更改业务代码,部署一个canal服务。canal服务把自己伪装成mysql的一个从节点,当mysql数据更新以后,canal会读取binlog数据,然后在通过canal的客户端获取到数据,更新缓存即可。

5、Redis持久化

  1. RDB(Redis数据备份文件)

把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据

RDB文件是一种紧凑、可压缩的二进制文件,它包含了Redis的键值对数据、过期时间数据类型等信息

在这里插入图片描述
RDB的执行原理?
在这里插入图片描述
执行流程:

  1. 主进程会fork一个子进程,同时也会将页表拷贝过去(类似拷贝)
  2. 这时主子进程的页表会同时指向物理内存,共享内存数据
  3. 子进程进行写新RDB文件操作,覆盖掉旧的文件
  4. 执行RDB持久化操作同时主进程在进行写的操作时,会拷贝一份数据再执行写操作,原本的数据会设置成只读,同时读的时候只会读拷贝后写完的数据副本。
  5. RDB文件的加载:当Redis服务器启动时,它会检查是否存在RDB文件。如果存在,Redis会读取RDB文件,并将其中的数据加载到内存中进行恢复。

如果是通过BGSAVE命令生成RDB文件,那么Redis会在子进程中完成这个过程,然后继续处理客户端请求。
如果是通过SAVE命令生成RDB文件,那么Redis会阻塞客户端请求,直到RDB操作完成才继续处理。

  1. AOF(追加文件)

Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件

存储的是Redis服务器接收到的写操作命令。它记录了所有的写操作命令,包括对不同类型数据的操作。

在这里插入图片描述

因为是记录命令,AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果。
在这里插入图片描述
AOF的执行原理?

  1. 写入操作追加到AOF缓冲区:当客户端发送写操作到Redis服务器时,服务器会将该操作追加到AOF缓冲区中,而不是直接写入磁盘文件。AOF缓冲区是一个内存缓冲区,用于临时存储待持久化的写操作。
  2. AOF缓冲区数据写入AOF文件:Redis服务器使用文件事件处理器在合适的时机将AOF缓冲区中的数据写入到AOF文件中。写入操作可以通过多种方式触发,如定时、命令计数等。
  3. AOF文件重写(可选):为了避免AOF文件过大,Redis支持对AOF文件进行重写。AOF重写是通过生成一份与当前数据集完全一致的新AOF文件来实现的,过程中会跳过不必要的写操作。重写过程不会阻塞客户端请求,并且生成的新AOF文件比旧文件更小,节省磁盘空间。
  4. AOF文件加载恢复数据:当Redis重启时,可以通过加载AOF文件来恢复数据。Redis会读取AOF文件中记录的写操作,并按照顺序重新执行这些写操作,以还原数据集状态。

RDB与AOF对比

在这里插入图片描述


6、数据过期策略

  1. 惰性删除

设置该key过期时间后,我们不去管它,当需要该key时,我们在检查其是否过期,如果过期,我们就删掉它,反之返回该key

优点 :对CPU友好,只会在使用该key时才会进行过期检查,对于很多用不到的key不用浪费时间进行过期检查

缺点 :对内存不友好,如果一个key已经过期,但是一直没有使用,那么该key就会一直存在内存中,内存永远不会释放

  1. 定期删除

每隔一段时间,我们就对一些key进行检查,删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查,并删除其中的过期key)。

定期清理有两种模式
SLOW模式是定时任务,执行频率默认为10hz,每次不超过25ms,以通过修改配置文件redis.conf 的hz 选项来调整这个次数

FAST模式执行频率不固定,但两次间隔不低于2ms,每次耗时不超过1ms

优点:可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除,也能有效释放过期键占用的内存。

缺点:难以确定删除操作执行的时长和频率。

Redis的过期删除策略:惰性删除 + 定期删除两种策略进行配合使用


7、数据淘汰策略

当Redis中的内存不够用时,此时在向Redis中添加新的key,那么Redis就会按照某一种规则将内存中的数据删除掉,这种数据的删除规则被称之为内存的淘汰策略。
Redis支持8种不同策略来选择要删除的key:

noeviction: 不淘汰任何key,但是内存满时不允许写入新数据,默认就是这种策略。
volatile-ttl: 对设置了TTL的key,比较key的剩余TTL值,TTL越小越先被淘汰
allkeys-random:对全体key ,随机进行淘汰。
volatile-random:对设置了TTL的key ,随机进行淘汰。
allkeys-lru: 对全体key,基于LRU算法进行淘汰
volatile-lru:对设置了TTL的key,基于LRU算法进行淘汰
allkeys-lfu: 对全体key,基于LFU算法进行淘汰
volatile-lfu: 对设置了TTL的key,基于LFU算法进行淘汰

其中:
LRU(Least Recently Used)最近最少使用。用当前时间减去最后一次访问时间,这个值越大则淘汰优先级越高。

key1是在3s之前访问的, key2是在9s之前访问的,删除的就是key2

LFU(Least Frequently Used)最少频率使用。会统计每个key的访问频率,值越小淘汰优先级越高。

key1最近5s访问了4次, key2最近5s访问了9次, 删除的就是key1

数据淘汰策略-使用建议

在这里插入图片描述关于数据淘汰策略其他的面试问题

在这里插入图片描述


Redis-分布式锁

1、redis分布式锁,是如何实现的?

Redis实现分布式锁主要利用Redis的setnx命令

死锁的情况,就是在拿到锁执行业务的时候,服务突然宕机,导致锁没有被释放
解决办法就是给锁设置过期时间

在这里插入图片描述

锁的失效时长怎么控制:
在这里插入图片描述
但是这两种方式都不是很靠谱,实现起来也很复杂,可以使用redisson实现的分布式锁


2、redisson实现的分布式锁执行流程

在这里插入图片描述
其中:枷锁成功后,可以保证业务执行完成才会去释放锁,业务如果未完成,锁的时间到期了,看门狗会每隔30秒做一次续约,直到业务执行完成释放锁的时候会给看门狗一个信号,不需要对锁续时间了。

如果在执行线程一的时候,拿到了分布式锁,线程二也进来了,这个时候线程二想要拿到锁,发现拿不到,就会进行一个重试机制,当然如果重试到一定的次数会停止重试获取锁的操作。

参考链接:Redission可重入,锁重试,锁续约,watchDog机制------->作者:
alonePointer

锁重试和续约------>作者:阿千弟


3、redisson实现的分布式锁-可重入

针对同一个线程多次请求获取分布式锁的情况,Redisson使用一个计数器来记录当前线程对锁的获取次数。初始时计数器为1,每次成功获取锁后,将计数器加1;每次释放锁后,将计数器减1。只有当计数器归零时,才会真正释放锁。
在这里插入图片描述
参考链接:Redission可重入,锁重试,锁续约,watchDog机制------->作者:
alonePointer

锁重试和续约------>作者:阿千弟

4、redisson实现的分布式锁-主从一致性

RedLock(红锁):不能只在一个redis实例上创建锁,应该是在多个redis实例上创建锁(n / 2 + 1),避免在一个redis实例上加锁。

使用redisson提供的红锁来解决,但是这样的话,性能就太低了,如果业务中非要保证数据的强一致性,建议采用zookeeper实现的分布式锁。

在这里插入图片描述

参考链接:Redisson 分布式锁主从一致性问题-----作者:刘婉晴

Redis-其他面试题

1、Redis集群有哪些方案?

1.1 主从复制

单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。

一般redis都是读多写少,主节点执行写操作,然后同步到从节点,从节点只执行读操作。

在这里插入图片描述

  1. 第一部分:主从全量同步(一般都是第一次主节点和从节点同步)

在这里插入图片描述
其中:
Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid。

offset:偏移量,随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。
流程:

  • 1.从节点请求主节点同步数据(replication id、 offset
  • 2.主节点判断是否是第一次请求,是第一次就与从节点同步版本信息(replication id和offset)
  • 3.主节点执行bgsave,生成rdb文件后,发送给从节点去执行
  • 4.在rdb生成执行期间,主节点会以命令的方式记录到缓冲区(一个日志文件)
  • 5.把生成之后的命令日志文件发送给从节点进行同步

主从是否同步取决于主从offset偏移量是否相等

第二部分:主从增量同步(一般是从节点slave重启或后期数据变化)
在这里插入图片描述
流程:

  • 1.从节点请求主节点同步数据,主节点判断不是第一次请求,不是第一次就获取从节点的offset值
  • 2.主节点从命令日志中获取offset值之后的数据,发送给从节点进行数据同步

1.2 哨兵模式

Redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复。
在这里插入图片描述
其中服务状态监控

Sentinel基于心跳机制监测服务状态,每隔1秒向集群的每个实例发送ping命令
主观下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线。
客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线,则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

在这里插入图片描述
哨兵选主规则:

  1. 首先判断主与从节点断开时间长短,如超过指定值就排该从节点
  2. 然后判断从节点的slave-priority值,越小优先级越高
  3. 如果slave-prority一样,则判断slave节点的offset值,越大优先级越高
  4. 最后是判断slave节点的运行id大小,越小优先级越高。

1.2.1、redis集群(哨兵模式)脑裂

脑裂(Split Brain)是指由于网络分区或其他故障导致多个主节点同时存在的情况。这会导致数据不一致和服务不可用的问题。

由于主节点和从节点和sentinel处于不同的网络分区,使得sentinel没有能够心跳感知到主节点,所以通过选举的方式提升了一个从节点为主,这样就存在了两个master,就像大脑分裂了一样,这样会导致客户端还在老的主节点那里写入数据,新节点无法同步数据,当网络恢复后,sentinel会将老的主节点降为从节点,这时再从新master同步数据,就会导致数据丢失.
在这里插入图片描述
解决:我们可以修改redis的配置,可以设置最少的从节点数量以及缩短主从数据同步的延迟时间,达不到要求就拒绝请求,就可以避免大量的数据丢失
在这里插入图片描述

1.3 分片集群结构

主从解决高并发读的问题,和哨兵可以解决高可用的问题。但是依然有两个问题没有解决:

  1. 海量数据存储问题
  2. 高并发的问题

使用分片集群可以解决上述问题,分片集群特征:

  • 集群中有多个master,每个master保存不同数据
  • 每个master都可以有多个slave节点
  • master之间通过ping监测彼此健康状态
  • 客户端请求可以访问集群任意节点,最终都会被转发到正确节点

在这里插入图片描述
分片集群结构-数据读写

Redis 分片集群引入了哈希槽的概念,Redis 集群有 16384 个哈希槽,每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽,集群的每个节点负责一部分 hash 槽。
在这里插入图片描述
其中:Redis分片集群中数据是怎么存储和读取的?

  • Redis 分片集群引入了哈希槽的概念,Redis 集群有 16384 个哈希槽
  • 将16384个插槽分配到不同的实例(主节点)
  • 读写数据:根据key的有效部分计算哈希值对16384取余(有效部分,如果key前面有大括号,大括号的内容就是有效部分,如果没有,则以key本身做为有效部分)余数做为插槽,寻找插槽所在的实例

2、Redis是单线程的,但是为什么还那么快

  • Redis是纯内存操作,执行速度非常快
  • 采用单线程,避免不必要的上下文切换可竞争条件,多线程还要考虑线程安全问题
  • 使用I/O多路复用模型,非阻塞IO

3、能解释一下I/O多路复用模型?

Redis是纯内存操作,执行速度非常快,它的性能瓶颈是网络延迟而不是执行速度, I/O多路复用模型主要就是实现了高效的网络请求。
参考链接:网络模型

4、网络模型-Redis是单线程的吗?为什么使用单线程?

Redis到底是单线程还是多线程?

  • 如果仅仅聊Redis的核心业务部分(命令处理),答案是单线程
  • 如果是聊整个Redis,那么答案就是多线程

在Redis版本迭代过程中,在两个重要的时间节点上引入了多线程的支持:

  • Redis v4.0:引入多线程异步处理一些耗时较旧的任务,例如异步删除命令unlink
  • Redis v6.0:在核心网络模型中引入 多线程,进一步提高对于多核CPU的利用率

因此,对于Redis的核心网络模型,在Redis 6.0之前确实都是单线程。是利用epoll(Linux系统)这样的IO多路复用技术在事件循环中不断处理客户端情况。

为什么Redis要选择单线程?

  • 抛开持久化不谈,Redis是纯 内存操作,执行速度非常快,它的性能瓶颈是网络延迟不是执行速度,因此多线程并不会带来巨大的性能提升
  • 多线程会导致过多的上下文切换,带来不必要的开销
  • 引入多线程会面临线程安全问题,必然要引入线程锁这样的安全手段,实现复杂度增高,而且性能也会大打折扣

5、Redis的单线程模型-Redis单线程和多线程网络模型变更

核心在于:在这里插入图片描述

  • 单线程的模型

在这里插入图片描述

执行流程:包括三种事件

  1. server socket 可读事件(建立连接和持续监听客户读写请求)
    在这里插入图片描述
  2. client socket 可读事件
    在这里插入图片描述
  3. client socket 可写事件
    在这里插入图片描述
  • 多线程的模型(redis 6.0)

影响性能的最大的就是IO操作
在这里插入图片描述
多线程体现在于:

  • 命令处理器解析客户端命令

也就是命令请求处理器在将客户端输入的命令(多线程下会有很多的请求,都等待着读)(此时是二进制)加入到缓冲区,并且解析除redis命令,这个过程是多线程的,至于执行命令把结果写入client队列之后的事还是单线程。

  • 命令回复处理器写响应结果

也就是通过命令回复处理器,开启多线程去客户端缓冲区去拿数据,在写出来,

需要指出的是,虽然 Redis 6.0 引入了多线程模型,但 Redis 的关键操作(如命令执行、写操作)仍然是单线程的,这是为了保证数据的一致性和避免竞态条件。多线程主要用于网络 I/O 操作接收客户端命令,而实际的数据读写操作仍然是单线程执行的。因此,在 Redis 中,多线程并不意味着完全的并行执行,仍然保持了单线程的简洁性和高性能


相关面试回答:
gitee-redis

持续更新中…,若内容有误,欢迎留言

素材来源:黑马程序员

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/17426.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

技术复盘(5)--git

技术复盘--git 资料地址原理图安装配置基本命令分支命令对接gitee练习:远程仓库操作 资料地址 学习地址-B站黑马:https://www.bilibili.com/video/BV1MU4y1Y7h5 git官方:https://git-scm.com/ gitee官网:https://gitee.com/ 原理图 说明&am…

Twitter 劲敌 Threads,“魔改”了哪些 Python 技术栈?

Meta 创始人 Mark Zuckerberg 昨天在 Threads 上宣布,周三正式上线的 Threads 注册量已突破三千万。 Threads 是一个基本文本的社交应用,由 Instagram 团队开发。虽然它在功能上还无法真正取代 Twitter,但目前看来事实上已是 Twitter 的替代方…

耗时3个月,线下访谈30+ csdn大佬,规划出了我的云原生学习路线

前言 大家好,我是沐风晓月,最近线下拜访不少云原生方向的大佬和csdn其他方向的大佬,受益匪浅。 于是在 5月23日,我定下来自己的目标: 我的目标: 可以说,这个世代给予的机遇,让我…

对外接口签名生成方式

接口签名生成方式 前言 当某个系统对外部系统提供接口访问时,为提高接口请求安全性,往往会在接口访问时添加签名,当外部系统访问本系统签名验证成功时才能正常返回数据,一般接口提供方会与外部系统提前约定好,不同外…

基于飞桨paddle的极简方案构建手写数字识别模型测试代码

基于飞桨paddle的极简方案构建手写数字识别模型测试代码 原始测试图片为255X252的图片 因为是极简方案采用的是线性回归模型,所以预测结果数字不一致 本次预测的数字是 [[3]] 测试结果: PS E:\project\python> & D:/Python39/python.exe e:/pro…

你知道HTTP与HTTPS有什么区别吗?

作者:Insist-- 个人主页:insist--个人主页 作者会持续更新网络知识和python基础知识,期待你的关注 目录 一、什么是HTTP? 二、什么是HTTPS? 三、HTTPS 的工作原理 1、客户端发起 HTTPS 请求 2、服务端的配置 3、…

Android如何用系统签名打包应用

前言 应用使用系统签名可以在用户不需要手动授权的情况下自动获取权限。适合一些定制系统中集成apk的方案商。 步骤 需要在AndroidManifest.xml中添加共享系统进程属性: android:sharedUserId"android.uid.system"如下图所示: 找到系统定制…

windows环境安装elasticsearch+kibana并完成JAVA客户端查询

下载elasticsearch和kibana安装包 原文连接:https://juejin.cn/post/7261262567304298554 elasticsearch官网下载比较慢,有时还打不开,可以通过https://elasticsearch.cn/download/下载,先找到对应的版本,最好使用迅…

LeetCode每日一题——1331.数组序号转换

题目传送门 题目描述 给你一个整数数组 arr ,请你将数组中的每个元素替换为它们排序后的序号。 序号代表了一个元素有多大。序号编号的规则如下: 序号从 1 开始编号。一个元素越大,那么序号越大。如果两个元素相等,那么它们的…

集团MySQL的酒店管理系统

酒店管理系统 概述 基于Spring Spring MVC MyBatis的酒店管理系统,主要实现酒店客房的预定、入住以及结账等功能。使用Maven进行包管理。 用户端主要功能包括: 登录注册、客房预订、客房评论(编写评论和查看评论) 后台管理主要…

Java maven的下载解压配置(保姆级教学)

mamen基本概念 Maven项目对象模型(POM),可以通过一小段描述信息来管理项目的构建,报告和文档的项目管理工具软件。 Maven 除了以程序构建能力为特色之外,还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性,所以…

【已解决】windows7添加打印机报错:加载Tcp Mib库时的错误,无法加载标准TCP/IP端口的向导页

windows7 添加打印机的时候,输入完打印机的IP地址后,点击下一步,报错: 加载Tcp Mib库时的错误,无法加载标准TCP/IP端口的向导页 解决办法: 复制以下的代码到新建文本文档.txt中,然后修改文本文…

【机器学习】 奇异值分解 (SVD) 和主成分分析 (PCA)

一、说明 在机器学习 (ML) 中,一些最重要的线性代数概念是奇异值分解 (SVD) 和主成分分析 (PCA)。收集到所有原始数据后,我们如何发现结构?例如,通过过去 6 天…

华为OD机试真题 JavaScript 实现【小朋友排队】【2023 B卷 100分】,附详细解题思路

目录 一、题目描述二、输入描述三、输出描述四、解题思路五、JavaScript算法源码六、效果展示1、输入2、输出 华为OD机试 2023B卷题库疯狂收录中,刷题点这里 刷的越多,抽中的概率越大,每一题都有详细的答题思路、详细的代码注释、样例测试&am…

Vue引入

1. vue引入 第一种方法&#xff1a;在线引入 <script src"https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> 第二种方法&#xff1a;本地引入 2. 语法学习 el用于绑定id&#xff0c;data用于定义数据如下例题 <!DOCTYPE html> <html…

GFS分布式文件系统概述以及集群部署

目录 一、GlusterFS简介 二、GlusterFS特点 1、扩展性和高性能 2、高可用性 3、全局统一命名空间 4、弹性卷管理 5、基于标准协议 三、GlusterFS术语 四、GlusterFS构成 五、后端存储如何定位文件 六、GFS支持的七种卷 1、分布式卷&#xff08;Distribute volume&a…

JAVA- SQL注入案例(黑马程序员)和避免 超级详细

文章目录 sql注入准备1.创建应该新的数据库用于测试&#xff1b;2.修改配置3.启动jar包4.打开网页测试5.测试sql注入 sql注入避免1. java中的登录逻辑代码2.演示sql注入3.原因5.参数化查询-PreparedStatement SQL注入是什么&#xff1f; SQL 注入&#xff08;SQL Injection&…

Kubernetes系列

文章目录 1 详解docker,踏入容器大门1.1 引言1.2 初始docker1.3 docker安装1.4 docker 卸载1.5 docker 核心概念和底层原理1.5.1 核心概念1.5.2 docker底层原理 1.6 细说docker镜像1.6.1 镜像的常用命令 1.7 docker 容器1.8 docker 容器数据卷1.8.1 直接命令添加1.8.2 Dockerfi…

cocosCreator 之 2D物理

版本&#xff1a; v3.4.0 简介 cocosCreator 内置了 2D 物理系统 和 3D 物理系统&#xff0c;开发者可以通过项目 -> 项目设置 -> 功能裁切来配置物理系统相关&#xff1a; 本文仅对2D 物理系统 做下说明和遇到的问题汇总。该物理系统在cocosCreator的功能裁切中&#x…

android 如何分析应用的内存(十三)——perfetto

android 如何分析应用的内存&#xff08;十三&#xff09; 本篇文章是native内存的最后一篇文章——perfetto perfetto简介 从2018年始&#xff0c;android开发者峰会正式推出perfetto工具。从此perfetto成为安卓最重要的工具之一。在2018年以前&#xff0c;android使用syst…