【Java八股面试系列】中间件-Redis

目录

Redis

什么是Redis

Redis解决了什么问题

Redis的实现原理

数据结构

String

常用命令

应用场景

List(列表)

常用命令

应用场景

Hash(哈希)

常用命令

应用场景

set(集合)

常见命令​编辑

应用场景

Sorted Set(有序集合)

常见命令​编辑

应用场景

数据持久化

RDB

优缺点

AOF

工作流程

AOF持久化的策略

AOF重写

AOF校验

Redis内存管理

内存淘汰机制

Redis实现分布式锁

Redis缓存问题

缓存穿透

解决方法

缓存击穿

解决办法

缓存雪崩

解决办法

缓存预热

数据库和缓存一致性

CAP原理

解决方法

常见问题


Redis

什么是Redis

Remote Dictionary Server(远程字典服务),是一个开源的使用C语言编写,基于内存,并且支持持久化的一个NoSQL数据库。

Redis解决了什么问题

Redis实现了:

  1. 高性能高并发缓存:Redis的数据是存放在内存中,所以读写都是非常快速

  2. 数据结构存储:Redis支持多种数据结构,字符串,哈希,列表等

  3. 数据持久化:使用AOF持久化,RDB持久化方案

  4. 发布与订阅:Redis支持发布与订阅模式,可以实现消息的发布和订阅。

Redis的实现原理

1、高性能

将经常访问的数据都放在Redis中,保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存,不用去磁盘中读取,所以速度相当快。

2、高并发

一般像 MySQL 这类的数据库的 QPS 大概都在 w 左右 ,但是使用 Redis 缓存之后很容易达到 10w级别(就单机 Redis 的情况,Redis 集群的话会更高)。

QPS(Query Per Second):服务器每秒可以执行的查询次数;

所以我们可以考虑把数据库中的部分数据转移到缓存中去,这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而,我们也就提高了系统整体的并发。

数据结构

5 种基础数据类型:String(字符串)、List(列表)、Set(集合)、Hash(散列)、Zset(有序集合)。

String
常用命令

应用场景
  • 存储键值对的场景

  • 需要计数的场景,使用INCR key进行数字的增减

  • 分布式锁

List(列表)

Redis 的 List 的实现为一个 双向链表,即可以支持反向查找和遍历

常用命令

应用场景

保存历史记录,按照日期进行保存

Hash(哈希)

Redis 中的 Hash 是一个 String 类型的 field-value(键值对) 的映射表,特别适合用于存储对象,后续操作的时候,你可以直接修改这个对象中的某些字段的值。

常用命令

应用场景

可以用来对象数据的存储,一个用户下面的各种信息

set(集合)

类似Java中的 HashSet,集合中的元素无序但是唯一,提供了查询元素是否存在的接口

常见命令
应用场景
  • 可以做两个集合的交集例如共同好友

  • 抽奖系统,能够随机出一个名额

Sorted Set(有序集合)

Sorted Set 类似于 Set,但和 Set 相比,Sorted Set 增加了一个权重参数 score,使得集合中的元素能够按 score 进行有序排列,还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMapTreeSet 的结合体。

常见命令
应用场景

数据持久化

数据持久化指的是将数据保存到磁盘中,Redis在4.0以后支持了三种持久化方式:

  • 快照(snapshotting,RDB)

  • 只追加文件(append-only file, AOF)

  • RDB 和 AOF 的混合持久化(Redis 4.0 新增)

数据持久化解决了重启机器或者就是机器故障以后的数据恢复工作

RDB

通过创建快照来获得存储在内存里面的数据在某个时间的副本。Redis获得了快照以后,可以使用快照进行重启恢复,可以复制给从服务器进行同步(提高Redis性能和高可用)

开启

通过在 redis.conf配置文件中设置

save 900 1           #在900秒(15分钟)之后,如果至少有1个key发生变化,Redis就会自动触发bgsave命令创建快照。
​
save 300 10          #在300秒(5分钟)之后,如果至少有10个key发生变化,Redis就会自动触发bgsave命令创建快照。
​
save 60 10000        #在60秒(1分钟)之后,如果至少有10000个key发生变化,Redis就会自动触发bgsave命令创建快照。
​

是否阻塞主线程

Redis 提供了两个命令来生成 RDB 快照文件:

  • save : 同步保存操作,会阻塞 Redis 主线程;

  • bgsave : fork 出一个子进程,子进程执行,不会阻塞 Redis 主线程,默认选项

这里说 Redis 主线程而不是主进程的主要是因为 Redis 启动之后主要是通过单线程的方式完成主要的工作。如果你想将其描述为 Redis 主进程,也没毛病

执行后,会在服务端目录下生成一个dump.rdb文件,而这个文件中就保存了内存中存放的数据,当服务器重启后,会自动加载里面的内容到对应数据库中。

优缺点

优点:恢复快速,保存简单

缺点:

  • 可能丢失最新更新的数据

  • 性能开销,如果我们数据比较大的时候,子线程进行保存的时候会消耗较多的cpu资源

AOF

与快照持久化相比,AOF 持久化的实时性更好。

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令,Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中,然后再写入到 AOF 文件中(此时还在系统内核缓存区未同步到磁盘),最后再根据持久化方式( fsync策略)的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

只有同步到磁盘中才算持久化保存了,否则依然存在数据丢失的风险,比如说:系统内核缓存区的数据还未同步,磁盘机器就宕机了,那这部分数据就算丢失了。

AOF 文件的保存位置和 RDB 文件的位置相同,都是通过 dir 参数设置的,默认的文件名是 appendonly.aof

工作流程

AOF 持久化功能的实现可以简单分为 5 步:

  1. 命令追加(append):所有的写命令会追加到 AOF 缓冲区中。

  2. 文件写入(write):将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数(系统调用),write将数据写入到了系统内核缓冲区之后直接返回了(延迟写)。注意!!!此时并没有同步到磁盘。

  3. 文件同步(fsync):AOF 缓冲区根据对应的持久化方式( fsync 策略)向硬盘做同步操作。这一步需要调用 fsync 函数(系统调用), fsync 针对单个文件操作,对其进行强制硬盘同步,fsync 将阻塞直到写入磁盘完成后返回,保证了数据持久化。

  4. 文件重写(rewrite):随着 AOF 文件越来越大,需要定期对 AOF 文件进行重写,达到压缩的目的。

  5. 重启加载(load):当 Redis 重启时,可以加载 AOF 文件进行数据恢复

AOF持久化的策略

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式( fsync策略),它们分别是:

  1. appendfsync always:主线程调用 write 执行写操作后,后台线程( aof_fsync 线程)立即会调用 fsync 函数同步 AOF 文件(刷盘),fsync 完成后线程返回,这样会严重降低 Redis 的性能(write + fsync)。

  2. appendfsync everysec:主线程调用 write 执行写操作后立即返回,由后台线程( aof_fsync 线程)每秒钟调用 fsync 函数(系统调用)同步一次 AOF 文件(write+fsyncfsync间隔为 1 秒)

  3. appendfsync no:主线程调用 write 执行写操作后立即返回,让操作系统决定何时进行同步,Linux 下一般为 30 秒一次(write但不fsyncfsync 的时机由操作系统决定)。

可以看出:这 3 种持久化方式的主要区别在于 fsync 同步 AOF 文件的时机(刷盘)

为了兼顾数据和写入性能,可以考虑 appendfsync everysec 选项 ,让 Redis 每秒同步一次 AOF 文件,Redis 性能受到的影响较小。而且这样即使出现系统崩溃,用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候,Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

AOF重写

当 AOF 变得太大时,Redis 能够在后台自动重写 AOF 产生一个新的 AOF 文件,这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样,但体积更小。

AOF 重写

AOF 重写(rewrite) 是一个有歧义的名字,该功能是通过读取数据库中的键值对来实现的,程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。

由于 AOF 重写会进行大量的写入操作,为了避免对 Redis 正常处理命令请求造成影响,Redis 将 AOF 重写程序放到子进程里执行。

AOF 文件重写期间,Redis 还会维护一个 AOF 重写缓冲区,该缓冲区会在子进程创建新 AOF 文件期间,记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后,服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾,使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后,服务器用新的 AOF 文件替换旧的 AOF 文件,以此来完成 AOF 文件重写操作。

AOF校验

AOF 校验机制是 Redis 在启动时对 AOF 文件进行检查,以判断文件是否完整,是否有损坏或者丢失的数据。这个机制的原理其实非常简单,就是通过使用一种叫做 校验和(checksum) 的数字来验证 AOF 文件。这个校验和是通过对整个 AOF 文件内容进行 CRC64 算法计算得出的数字。如果文件内容发生了变化,那么校验和也会随之改变。因此,Redis 在启动时会比较计算出的校验和与文件末尾保存的校验和(计算的时候会把最后一行保存校验和的内容给忽略点),从而判断 AOF 文件是否完整。如果发现文件有问题,Redis 就会拒绝启动并提供相应的错误信息。AOF 校验机制十分简单有效,可以提高 Redis 数据的可靠性。

Redis内存管理

一般我们都是需要给内存设置过期时间,首先考虑我们的内存是有限的,其次有些数据也是有时效性的。

如何判断数据过期

Redis 通过一个叫做过期字典(可以看作是 hash 表)来保存数据过期的时间。

过期数据的删除策略

  1. 惰性删除:只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好,但是可能会造成太多过期 key 没有被删除。

  2. 定期删除:每隔一段时间抽取一批 key 执行删除过期 key 操作。并且,Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。

定期删除对内存更加友好,惰性删除对 CPU 更加友好。两者各有千秋,所以 Redis 采用的是 定期删除+惰性/懒汉式删除

但是,仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里,然后就 Out of memory 了。

怎么解决这个问题呢?答案就是:Redis 内存淘汰机制。

内存淘汰机制

因为过期时间的删除策略都是具有局限性,惰性删除有时无法及时删除,定期删除会占用cpu大量的时间

相关问题:MySQL 里有 2000w 数据,Redis 中只存 20w 的数据,如何保证 Redis 中的数据都是热点数据?

Redis 提供 6 种数据淘汰策略:

  1. volatile-lru(least recently used):从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰。

  2. volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰。

  3. volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰。

  4. allkeys-lru(least recently used):当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的 key(这个是最常用的)。

  5. allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰。

  6. no-eviction:禁止驱逐数据,也就是说当内存不足以容纳新写入数据时,新写入操作会报错。这个应该没人使用吧!

Redis实现分布式锁

Redis缓存问题

缓存穿透

指的是访问一个数据库和缓存中都不存在的数据,每一次都会去访问数据库,也不会存在缓存中

解决方法

布隆过滤

布隆过滤器是将我们数据库中存在的数据都放置在一个二进制向量中,使用N个哈希值,将数据进行hash然后存放在里面。每一次查询的时候都先将我们查询的目标都进行N次hash然后如果有一个位置为0,则表示数据不存在。

缺点:

  • 数据越来越多则会越来越不准确。

  • 存放在布隆过滤器中的值不容易删除

接口限流

按照我们的用户或者IP对接口进行限流,设置防刷机制。

缓存击穿

比如某条热点数据过期,然后大量的数据去访问数据库,带来巨大的压力

穿透和击穿的区别就是数据库中有或者没有

解决办法

设置热点数据永不过期或者过期时间比较长。

针对热点数据提前预热,将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。

请求数据库写数据到缓存之前,先获取互斥锁,保证只有一个请求会落到数据库上,减少数据库的压力。

缓存雪崩

当你的Redis服务器炸了或是大量的Key在同一时间过期,这时相当于缓存直接GG了,那么如果这时又有很多的请求来访问不同的数据,同一时间内缓存服务器就得向数据库大量发起请求来重新建立缓存,很容易把数据库也搞GG。

解决办法
  • 采用 Redis 集群,避免单机出现问题整个缓存服务都没办法使用。

  • 限流,避免同时处理大量的请求。

  • 多级缓存,例如本地缓存+Redis 缓存的组合,当 Redis 缓存出现问题时,还可以从本地缓存中获取到部分数据。

缓存预热

常见的缓存预热方式有两种:

  1. 使用定时任务,比如 xxl-job,来定时触发缓存预热的逻辑,将数据库中的热点数据查询出来并存入缓存中。

  2. 使用消息队列,比如 RabbitMQ,来异步地进行缓存预热,将数据库中的热点数据的主键或者 ID 发送到消息队列中,然后由缓存服务消费消息队列中的数据,根据主键或者 ID 查询数据库并更新缓存。

数据库和缓存一致性

Redis可以将常访问的数据保存起来,新的请求先在Redis中进行查询,能够缓解数据库的压力。

在读的情况下,无论怎样都是不会出现问题的,所以关键就是读写出现不一致的问题。

CAP原理

根据CAP原理,CAP原则又称CAP定理,指的是在一个分布式系统中,存在Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),三者不可同时保证,最多只能保证其中的两者。

一致性(C):在分布式系统中的所有数据备份,在同一时刻都是同样的值(所有的节点无论何时访问都能拿到最新的值)

可用性(A):系统中非故障节点收到的每个请求都必须得到响应(比如我们之前使用的服务降级和熔断,其实就是一种维持可用性的措施,虽然服务返回的是没有什么意义的数据,但是不至于用户的请求会被服务器忽略)

分区容错性(P):一个分布式系统里面,节点之间组成的网络本来应该是连通的,然而可能因为一些故障(比如网络丢包等,这是很难避免的),使得有些节点之间不连通了,整个网络就分成了几块区域,数据就散布在了这些不连通的区域中(这样就可能出现某些被分区节点存放的数据访问失败,我们需要来容忍这些不可靠的情况)

总的来说,数据存放的节点数越多,分区容忍性就越高,但是要复制更新的次数就越多,一致性就越难保证。同时为了保证一致性,更新所有节点数据所需要的时间就越长,那么可用性就会降低。

所以这里我们只能保证最终一致性

解决方法

当我们修改数据库的数据的时候,先更新数据库还是Redis缓存?

  1. 先删除缓存,再更新数据库

当多线程进行访问的时候,当线程A需要写入X,然后更新数据库的时候,线程2来访问缓存X,缓存中没有消息,进入数据库进行读取,读取旧的值X到缓存中,这个时候线程1再修改好数据库则最终一致性都不能保证。

  1. 先更新数据库再删除缓存

虽然有可能还是会最终一致性无法满足,但是概率很小,因为读和写请求的并发,读请求会更快的读取并且更新到缓存中,而读更慢。

  1. 双重删除

  2. 消息队列

使用消息队列异步删除,因为消息队列采用了确认机制,所以能够确保缓存中的数据被删除,虽然也会读取到脏数据,但是这个可以看作MVcc,读的操作是在更新的操作之前,不能看到更新完成后的失误,最后也能实现数据的最终一致性

常见问题

String 还是 Hash存储对象更好呢?

具体看我们的使用情况,string存储的是已经序列化的数据,存放整个对象。Hash是对每个字段单独的进行存储,可以获取部分的信息,可以修改。所以如果需要经常修改则Hash合适

String 存储更加的节省内存,因为Hash 需要保存更多的结构信息

        

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

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

相关文章

Day46:WEB攻防-注入工具SQLMAPTamper编写指纹修改高权限操作目录架构

目录 数据猜解-库表列数据&字典 权限操作-文件&命令&交互式 提交方法-POST&HEAD&JSON 绕过模块-Tamper脚本-使用&开发 分析拓展-代理&调试&指纹&风险&等级 知识点: 1、注入工具-SQLMAP-常规猜解&字典配置 2、注入…

助力低碳出行 | 基于ACM32 MCU的电动滑板车方案

前言 随着智能科技的快速发展,电动滑板车的驱动系统也得到了长足的发展。国内外的电动滑板车用电机驱动系统分为传统刷式电机和无刷电机两种类型。其中,传统的刷式电机已经逐渐被无刷电机所取代,无刷电机的性能和寿命都更出色,已成…

pandas数据保存与加载

安装操作Excel模拟数据写入编辑读取切片操作 统计 安装 pip install pandas pip install numpyExcel环境安装 pip install xlrd pip install xlwt pip install openpyxi操作Excel import pandas as pd 模拟数据 写入 import pandas as pd# 模拟需要写入的数据 dic{name:[…

【计算机网络篇】数据链路层(4.2)可靠传输的实现机制

文章目录 🍔可靠传输的实现机制⭐停止 - 等待协议🗒️注意 🔎停止 - 等待协议的信道利用率🗃️练习题 ⭐回退N帧协议🎈回退N帧协议的基本工作流程🔎无传输差错的情况🔎超时重传的情况&#x1f5…

大话设计模式之迪米特法则

迪米特法则,也称为最少知识原则(Law of Demeter),是面向对象设计中的一个重要原则,其核心思想是降低耦合度、减少对象之间的依赖关系,从而使系统更加灵活、易于维护和扩展。 根据迪米特法则,一…

【考研数学】线代跟张宇,还是李永乐?

干吗要做选择,你可以全部都要的嘛! 基础阶段选张宇,强化阶段选李永乐,这样搭配可以说是最佳了。 先来说下两位老师各自的特点,张宇老师,讲线代通俗易懂,技巧运用得溜溜的。他的课,…

samba实现linux共享文件夹

一、samba安装 sudo apt install samba 二、配置Samba 编辑Samba配置文件sudo vi /etc/samba/smb.conf 在文件末尾添加以下内容,设置一个简单的共享目录(替换path_to_share为实际的共享目录路径): [Share] path /path_to_sha…

Linux:详解TCP协议段格式

文章目录 认识TCPTCP协议段格式 本篇主要总结的是TCP协议的一些字段 认识TCP TCP协议全称是传输控制协议,也就是说是要对于数据的传输进行一个控制 以上所示的是对于TCP协议进行数据传输的一个理解过程 全双工 至此就可以对于TCP协议是全双工的来进行理解了&…

【计算机图形学】3D Implicit Transporter for Temporally Consistent Keypoint Discovery

对3D Implicit Transporter for Temporally Consistent Keypoint Discovery的简单理解 文章目录 1. 现有方法限制和文章改进2. 方法2.1 寻找时间上一致的3D特征点2.1.1 3D特征Transporter2.1.2 几何隐式解码器2.1.3 损失函数 2.2 使用一致特征点的操纵 1. 现有方法限制和文章改…

[2023] 14届

1.日期统计 题意 1.日期统计 - 蓝桥云课 (lanqiao.cn) 思路 用dfs扫 对每一个位进行限制 花了一个小时 注意把答案枚举出来 对应一下看到底对不对 code #include<iostream> #include<cstdio> #include<stack> #include<vector> #include<al…

VSCode 如何同步显示网页在手机或者平板上

首先要确保 ①电脑上安装了VsCode ②VsCode安装插件LiveServer 安装成功之后 连续按住 Alt L 、Alt O 会跳转到对应的html页面上 http://127.0.0.1:5500/....... 是这个开头的 然后打开网络 如果桌面有网上邻居的可以直接点桌面的网上邻居 进来找到WLAN这个…

为什么我的微信小程序 窗口背景色backgroundColor设置参数 无效的问题处理记录!

当我们在微信小程序 json 中设置 backgroundColor 时&#xff0c;实际在电脑的模拟器中根本看不到效果。 这是因为 backgroundColor 指的窗体背景颜色&#xff0c;而不是页面的背景颜色&#xff0c;即窗体下拉刷新或上拉加载时露出的背景。在电脑的模拟器中是看不到这个动作的…

智能工具管理系统-智能工具柜系统

智能工具管理系统-智能工具柜系统 智能工具可视化管理系统(智工具DW-S308)是依托互3D技术、云计算、大数据、RFID技术、数据库技术、AI、视频分析技术对RFID工具进行统一管理、分析的信息化、智能化、规范化的系统。 一、工具管理现状 东识RFID工具管理系统是一种便捷化的工具…

C# 高级文件操作与异步编程探索(初步)

文章目录 文本文件的读写探秘StreamReader 类深度剖析StreamWriter 类细节解读编码和中文乱码的解决方案 二进制文件的读写BinaryReader 类全面解析BinaryWriter 类深度探讨 异步编程与C#的未来方向同步与异步&#xff1a;本质解读Task 的神奇所在async/await 的魔法 在现代编程…

【ESP32S3 Sense接入语音识别+MiniMax模型对话】

1. 前言 围绕ESP32S3 Sense接入语音识别MiniMax模型对话展开&#xff0c;首先串口输入“1”字符&#xff0c;随后麦克风采集2s声音数据&#xff0c;对接百度在线语音识别&#xff0c;将返回文本结果丢入MiniMax模型&#xff0c;进而返回第二次结果文本&#xff0c;实现语言对话…

Day53:WEB攻防-XSS跨站SVGPDFFlashMXSSUXSS配合上传文件添加脚本

目录 MXSS UXSS&#xff1a;Universal Cross-Site Scripting HTML&SVG&PDF&SWF-XSS&上传&反编译(有几率碰到) SVG-XSS PDF-XSS Python生成XSS Flash-XSS 知识点&#xff1a; 1、XSS跨站-MXSS&UXSS 2、XSS跨站-SVG制作&配合上传 3、XSS跨站-…

【MySQL】6.MySQL主从复制和读写分离

主从复制 主从复制与读写分离 通常数据库的读/写都在同一个数据库服务器中进行&#xff1b; 但这样在安全性、高可用性和高并发等各个方面无法满足生产环境的实际需求&#xff1b; 因此&#xff0c;通过主从复制的方式同步数据&#xff0c;再通过读写分离提升数据库的并发负载…

Spring Boot | SpringBoo“开发入门“

目录 : 1.SpringBoot的“介绍”SpringBoot”概述” &#xff1a;SpringBoot”简介“SpringBoot的“优点” 2. SpringBoot入门程序环境准备使用 “Maven”方式构建SpringBoot 项目使用“Spring Initializr”方式构建Spring Boot 项目 3. “单元测试” 和“热部署”单元测试热部署…

【算法刷题 | 二叉树 05】3.28(左叶子之和、找树 左下角的值)

文章目录 11.左叶子之和11.1问题11.2解法一&#xff1a;递归11.2.1递归思路11.2.2代码实现 11.3解法二&#xff1a;栈11.3.1栈思想11.3.2代码实现 12.找树左下角的值12.1问题12.2解法一&#xff1a;层序遍历 11.左叶子之和 11.1问题 给定二叉树的根节点 root &#xff0c;返回…

大模型时代下的“金融业生物识别安全挑战”机遇

作者&#xff1a;中关村科金AI安全攻防实验室 冯月 金融行业正在面临着前所未有的安全挑战&#xff0c;人脸安全事件频发&#xff0c;国家高度重视并提出警告&#xff0c;全行业每年黑产欺诈涉及资金额超过1100亿元。冰山上是安全事件&#xff0c;冰山下隐藏的是“裸奔”的技术…