Redis-实践知识

转自极客时间Redis 亚风 原文视频：https://u.geekbang.org/lesson/535?article=681062

Redis最佳实践

普通KEY

Redis 的key虽然可以自定义，但是最好遵循下面几个实践的约定：
格式：[业务名称]:[数据名]:[id] 长度不超过44字节 不包含特殊字符
例如： login:user:10
这样做的好处是
• 可读性强
• 避免key冲突
• ⽅便管理
• 节省内存：key是string类型，底层编码包含int、embstr和raw三种。embstr在⼩于44字节使⽤，采⽤连续内存空间，内存占⽤更⼩。

set key "123"
object encoding key

在这里插入图片描述
在这里插入图片描述

BigKey

什么是bigKey?

  • BigKey通常以Key的⼤⼩和Key中成员的数量来综合判定，例如：
  • Key本身的数据量过⼤：⼀个String类型的Key，它的值为5 MB（key + val 加在一起 也就是一个Entry）。
  • Key中的成员数过多：⼀个ZSET类型的Key，它的成员数量为10,000个。
    Key中成员的数据量过⼤：⼀个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总⼤⼩为100 MB。
    推荐值：
    单个key的value⼩于10KB。
    对于集合类型的key，建议元素数量⼩于1000。
    BigKey的问题
    • ⽹络阻塞
    对Bigkey执⾏读请求时，少量的QPS就可能导致带宽使⽤率被占满，导致Redis实例，乃⾄所在物理机变慢
    • 数据倾斜
    BigKey所在的Redis实例内存使⽤率远超其他实例，⽆法使数据分⽚的內存资源达到均衡
    • Redis阻塞
    对元素较多的hash、 list、 zset等做运算会耗时较久，使主线程被阻塞
    • CPU压⼒
    对BigKey的数据序列化和反序列化会导致CPU的使⽤率飙升，影响Redis实例和本机其它应⽤

BigKey的发现
• redis-cli --bigkeys
利⽤ redis-cli提供的–bigkeys参数，可以遍历分析所有key，并返回Key的整体统计信息与每个数据的Top1的big key

redis-cli --bigkeys #扫描bigkeys

这里只得出了最大的key是54bytes,没有统计有那些key占用了多少空间，实际用用价值不大。
在这里插入图片描述

memory usage key #使用内存大小 (integer) 112
strlen key #也是使用内存大小
llen list #求内存大小
#最好是使用后面两个命令来求  memory usage性能不好

在这里插入图片描述

• scan扫描
⾃⼰编程，利⽤scan扫描Redis中的所有key，利⽤strlen、hlen等命令判断key的⻓度（此处不建议使⽤MEMORY USAGE)

scan 0 #第一页是0
#第二页则是 返回什么值 往下翻页就是转这个值
scan 7

在这里插入图片描述

// 自己编程
final static int STR_MAX_LEN = 10 * 1024;
final static int HASH_MAX_LEN = 1000;@Testvoid testScan() {int maxLen = 0;long len = 0;String cursor = "0";do {// 扫描并获取⼀部分keyScanResult<String> result = jedis.scan(cursor);// 记录cursorcursor = result.getCursor();List<String> list = result.getResult();if (list == null || list.isEmpty()) {break;}// 遍历for (String key : list) {// 判断key的类型String type = jedis.type(key);switch (type) {case "string":len = jedis.strlen(key);maxLen = STR_MAX_LEN;break;case "hash":len = jedis.hlen(key);maxLen = HASH_MAX_LEN;break;case "list":len = jedis.llen(key);maxLen = HASH_MAX_LEN;break;case "set":len = jedis.scard(key);maxLen = HASH_MAX_LEN;break;case "zset":len = jedis.zcard(key);maxLen = HASH_MAX_LEN;break;default:break;}if (len >= maxLen) {System.out.printf("Found big key : %s, ty
pe: %s, length or size: %d %n", key, type, len);}}} while (!cursor.equals("0"));}

• 第三⽅⼯具
利⽤第三⽅⼯具，如 Redis-Rdb-Tools 分析RDB快照⽂件，全⾯分析内存使⽤情况（推荐使用，但是实时性比较差）
• ⽹络监控
⾃定义⼯具，监控进出Redis的⽹络数据，超出预警值时主动告警。直接监控网络数据包。

如何删除BigKey
BigKey内存占⽤较多，即便时删除这样的key也需要耗费很⻓时间，导致
Redis主线程阻塞，引发⼀系列问题。
• redis 3.0 及以下版本
如果是集合类型，则遍历BigKey的元素，先逐个删除⼦元素，最后删除Bigkey
• Redis 4.0以后
Redis在4.0后提供了异步删除的命令：unlink

怎么存储key
例1：⽐如存储⼀个User对象，我们有三种存储⽅式：
⽅式⼀：json字符串

user:1 {"name":"jack","age":21}

优点：
简单粗暴
缺点：
数据耦合，不够灵活
方式二
字段打散

user:1:name jack
user:1:age 21

优点：可以灵活访问对象任意字段
缺点：占⽤空间⼤、没办法做统⼀控制
方式三

hset uid name zhonglimo #单字段赋值
hmset uid name zhonglimo age 24 #多字段赋值

在这里插入图片描述
优点：底层使⽤ziplist，空间占⽤⼩，可以灵活访问对象的任意字段
缺点：代码相对复杂
实战案例

假如有hash类型的key，其中有100万对field和value，field是⾃增id，这个key存在什么问题？如何优化？
在这里插入图片描述

存在的问题：
• hash的entry数量超过500时，会使⽤dict⽽不是ZipList，内存占⽤较多
• 可以通过hash-max-ziplist-entries配置entry上限。但是如果entry过多就会
导致BigKey问题
解决方案一直接将hash进行拆分成String：
在这里插入图片描述
存在的问题：
• string结构底层没有太多内存优化，内存占⽤较多
• 想要批量获取这些数据⽐较麻烦

方式二：拆分为⼩的hash，将 id / 100 作为key，将id % 100 作为field，这样每100个元素为⼀个Hash

在这里插入图片描述

HotKey

比如我有一个redis集群，由于2有一个热键，所有的请都打到了这个机器上有可能这个机器扛不住压力会挂掉，服务因而无法使用。
在这里插入图片描述
如果是读：
比如用哈希取模的方法进行路由到不同的机器，但是键也要做同样的拆分因为一个集群不能相同的键。

在这里插入图片描述
如果是写，比如秒杀扣库存，每台机器存放100个库存：
在这里插入图片描述
但是如果消耗到最后可能有碎片，比如剩了5个这个时候可以通过限流排队取消耗这些碎片。还有一种解决方案是消耗到剩一些碎片的时候，直接关闭流量，保证不超消费就行。

Pipeline批处理

MSET（不能被打断）虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使⽤Pipeline功能：

void testPipeline() {Pipline pipeline = jedis.pipelined();for (int i = 1; i <= 10000; i ++) {if (i % 1000 == 0） {pipline.sync();}}
}

注意事项：
• 批处理时不建议⼀次携带太多命令
• Pipeline的多个命令之间不具备原⼦性

MSET/Pipeline这样的批处理需要在⼀次请求中携带多条命令，⽽此时如果Redis是⼀个集群，那批处理命令的多个key必须落在⼀个插槽中，否则就会导致执⾏失败。
解决方案：
在这里插入图片描述
并行Slot在spring中的应用Spring->lettuce or Jedis->MultiKeyCommands

@Override
public RedisFuture<String> mset(Map<K,V> map) {Map<Integer, List<K>> partitioned = SlotHash.partition(codec, map.keySet());if (partitioned.size() < 2) {return super.mset(map);}
}

hash_tag

mset {a}name  zhangsan {a}age 12 {a}set male #这个hash Tag可以将key路由到同一个槽中

但是hash_tag 存在数据倾斜的问题，实战中推荐使用并行slot.

RDB 数据文件备份

RDB全称Redis Database Backup file (Redis数据备份⽂件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照⽂件，恢复数据。快照⽂件称为RDB⽂件，默认是保存在当前运⾏⽬录。

#有两种命令
save #由redis主进程来执行RDB,会阻塞所有命令
#fork 出⼀个⼦进程，⼦进程执⾏，不会阻塞 Redis 主线程，默认选项
bgsave #开启子进程执行RDB，避免主进程受到影响

Redis 可以通过创建快照来获得存储在内存⾥⾯的数据在 某个时间点 上的副本。Redis 创建快照之后，可以对快照进⾏备份，可以将快照复制到其他服务器从⽽创建具有相同数据的服务器副本（Redis 主从结构，主要⽤来提⾼Redis 性能），还可以将快照留在原地以便重启服务器的时候使⽤。快照持久化是 Redis 默认采⽤的持久化⽅式，在 redis.conf 配置⽂件中默认有此下配置：

#这些配置是一个或的关系，可以多个都生效，底层执行的都是bgsave 会自动转换为bgsave
save 900 1 #900秒以后如果有一个key变化触发bgsave
save 300 10 #300秒以后如果有10个key变化可以出发bgsave
save 60 10000 #一分钟如果有10000个key发生变化触发bgsave
rdbcompression yes #是否开启压缩，建议不开启，压缩会消耗cpu
dbfilename dump.rdb #rdb文件名称
dir ./ #文件保存目录

bgsave开始时会fork主进程得到⼦进程，⼦进程共享主进程的内存数据。完成fork后读取内存数据并写RDB ⽂件。fork采⽤的是copy-on-write技术：当主进程执⾏读操作时，访问共享内存；当主进程执⾏写操作时，则会拷⻉⼀份数据，执⾏写操作。
在这里插入图片描述

AOF 追加文件

AOF全称为Append Only File（追加⽂件）。Redis处理的每⼀个写命令都会记录在AOF⽂件，可以看做是命令⽇志⽂件。
与快照持久化相⽐，AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF⽅式的持久（Redis6.0 之后已经默认是开启了），可以通过 appendonly 参数开启：appendonly yes

开启 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 ⽂件进⾏数据恢复。

Linux 系统直接提供了⼀些函数⽤于对⽂件和设备进⾏访问和控制，这些函数被称为系统调⽤（syscall）。

write ：写⼊系统内核缓冲区之后直接返回（仅仅是写到缓冲区），不会⽴即同步到硬盘。虽然提⾼了效率，但也带来了数据丢失的⻛险。同步硬盘操作通常依赖于系统调度机制，Linux 内核通常为 30s 同步⼀次，具体值取决于写出的数据量和 I/O 缓冲区的状态。
fsync ： fsync⽤于强制刷新系统内核缓冲区（同步到到磁盘），确保写磁盘操作结束才会返回。

在这里插入图片描述
Redis fsync策略
在 Redis 的配置⽂件中存在三种不同的 AOF 持久化⽅式（ fsync策略），它们分别是：
• appendfsync always：主线程调⽤ write 执⾏写操作后，后台线程（ aof_fsync 线程）⽴即会调⽤ fsync 函数同步 AOF ⽂件（刷盘），fsync 完成后线程返回，这样会严重降低 Redis 的性能

• appendfsync everysec ：主线程调⽤ write 执⾏写操作后⽴即返回，由后台线程（ aof_fsync 线程）每秒钟调⽤ fsync 函数（系统调⽤）同步⼀次 AOF ⽂件

• appendfsync no ：主线程调⽤ write 执⾏写操作后⽴即返回，让操作系统决定何时进⾏同步，Linux 下⼀般为 30 秒⼀次为了兼顾数据和写⼊性能，可以考虑 appendfsync everysec 选项 ，让 Redis 每秒同步⼀次 AOF ⽂件，Redis 性能收到的影响较⼩。⽽且这样即使出现系统崩溃，⽤户最多只会丢失⼀秒之内产⽣的数据。当硬盘忙于执⾏写⼊操作的时候，Redis 还会优雅的放慢⾃⼰的速度以便适应硬盘的最⼤写⼊度。
**Multi Part AOF **
从 Redis 7 开始，Redis 使⽤了 Multi Part AOF 机制。顾名思义，Multi Part AOF 就是将原来的单个 AOF ⽂件拆分成多个 AOF ⽂件。在 Multi Part AOF 中，AOF ⽂件被分为三种类型，分别为：
BASE：表示基础 AOF ⽂件，它⼀般由⼦进程通过重写产⽣，该⽂件最多只有⼀个。
INCR：表示增量 AOF ⽂件，它⼀般会在 AOFRW 开始执⾏时被创建，该⽂件可能存在多个。
HISTORY：表示历史 AOF ⽂件，它由 BASE 和 INCR AOF 变化⽽来，每次 AOFRW 成功完成时，本次 AOFRW 之前对应的 BASE 和 INCR AOF 都将变为 HISTORY，HISTORY 类型的 AOF 会被 Redis ⾃动删除。
当 AOF 变得太⼤时，Redis 能够在后台⾃动重写 AOF 产⽣⼀个新的 AOF ⽂件，这个新的 AOF ⽂件和原有的 AOF ⽂件所保存的数据库状态⼀样，但体积更⼩。

AOF重写

AOF 重写是⼀个有歧义的名字，该功能是通过读取数据库中的键值对来实现的（扫描键值对重新写一个新文件，不会对之前的AOF进行读写），程序⽆须对现有 AOF ⽂件进⾏任何读⼊或写⼊操作。

由于 AOF 重写会进⾏⼤量的写⼊操作，为了避免对 Redis 正常处理命令请求造成影响，Redis 将 AOF 重写程序放到⼦进程⾥执⾏。
AOF ⽂件重写期间，Redis 还会维护⼀个 AOF 重写缓冲区，该缓冲区会在⼦进程创建新 AOF ⽂件期间，记录服务器执⾏的所有写命令。当⼦进程完成创建新 AOF ⽂件的⼯作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF ⽂件的末尾，使得新的 AOF ⽂件保存的数据库状态与现有的数据库状态⼀致。最后，服务器⽤新的 AOF ⽂件替换旧的 AOF ⽂件，以此来完成 AOF ⽂件重写操作。

开启 AOF 重写功能，可以调⽤ BGREWRITEAOF 命令⼿动执⾏，也可以设置下⾯两个配置项，让程序⾃动决定触发时机：

#增长超过多少百分比触发重写
auto-aof-rewrite-percentage 100
#体积多大触发重写
auto-aof-rewrite-min-size 64mb

Redis 7.0 版本之前，如果在重写期间有写⼊命令，AOF 可能会使⽤⼤量内存，重写期间到达的所有写⼊命令都会写⼊磁盘两次。AOF 重写期间的增量数据如何处理⼀直是个问题，在过去写期间的增量数据需
要在内存中保留，写结束后再把这部分增量数据写⼊新的 AOF ⽂件中以保证数据完整性。可以看出来 AOF 写会额外消耗内存和磁盘 IO，这也是 Redis AOF 写的痛点，虽然之前也进⾏过多次改进但是资源消耗的本质问题⼀直没有解决。
阿⾥ Redis 在最初也遇到了这个问题，在内部经过多次迭代开发，实现了 Multi-part AOF 机制来解决，同时也贡献给了社区并随此次 7.0 发布。具体⽅法是采⽤ base（全量数据）+incr（增量数据）独⽴⽂件存储的⽅式。由于 RDB 和 AOF 各有优势，Redis 4.0 开始⽀持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF ⽂件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF ⾥⾯的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

RDB与AOF的对比

RDB ⽐ AOF 优秀的地⽅ ：
RDB ⽂件存储的内容是经过压缩的⼆进制数据， 保存着某个时间点的数据集，⽂件很⼩，适合做数据的备份，灾难恢复。AOF ⽂件存储的是每⼀次写命令，类似于 MySQL 的 binlog ⽇志，通常会必 RDB ⽂件⼤很多。当 AOF 变得太⼤时，Redis 能够在后台⾃动重写 AOF。新的 AOF ⽂件和原有的 AOF ⽂件所保存的数据库状态⼀样，但体积更⼩。不过， Redis 7 之前，如果在重写期间有写⼊命令，AOF 可能会使⽤⼤量内存，重写期间到达的所有写⼊命令都会写⼊磁盘两次。使⽤ RDB ⽂件恢复数据，直接解析还原数据即可，不需要⼀条⼀条地执⾏命令，速度⾮常快。⽽ AOF 则需要依次执⾏每个写命令，速度⾮常慢。也就是
说，与 AOF 相⽐，恢复⼤数据集的时候，RDB 速度更快。

AOF ⽐ RDB 优秀的地⽅ ：
RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。⽣成 RDB ⽂件的过程是⽐较繁重的， 虽然 BGSAVE ⼦进程写⼊ RDB ⽂件的⼯作不会阻塞主线程，但会对机器的 CPU 资源和内存资源产⽣影响，严重的情况下甚⾄会直接把 Redis 服务⼲宕机。AOF ⽀持秒级数据丢失（取决 fsync 策略，如果是 everysec，最多丢失 1 秒的数据），仅仅是追加命令到 AOF ⽂件，操作轻量。
RDB ⽂件是以特定的⼆进制格式保存的，并且在 Redis 版本演进中有多个版本的 RDB，所以存在⽼版本的 Redis 服务不兼容新版本的 RDB 格式的问题。AOF 以⼀种易于理解和解析的格式包含所有操作的⽇志。你可以轻松地导出 AOF ⽂件进⾏分析。⽐如，如果执⾏FLUSHALL命令意外地刷新了所有内容后，删除最新命令并重启即可恢复之前的状态。持久化可以保证数据安全，但会带来额外的开销，请遵循下列建议：
• ⽤来做缓存的Redis实例尽量不要开启持久化功能
• 建议关闭RDB持久化功能，使⽤AOF持久化
• 利⽤脚本定期在slave节点做RDB，实现数据备份
• 设置合理的rewrite阈值，避免频繁的bgrewrite
• 配置no-appendfsync-on-rewrite =yes，禁⽌在rewrite期间做aof，避免因
AOF引起的阻塞

部署建议

• Redis实例的物理机要预留⾜够内存，应对fork和rewrite
• 单个Redis实例内存上限不要太⼤，例如8G。可以加快fork的速度（fork是到页如果句柄太大，fork也会很慢）、减少主从同步、数据迁移压⼒
• 不要与CPU密集型应⽤部署在⼀起
• 不要与⾼硬盘负载应⽤⼀起部署。例如：数据库、消息队列

慢查询

慢查询阈值可以通过配置指定：slowlog-log-slower-than：慢查询阈值，单位是微秒。默认是10000（10ms），建议1000（1ms）
慢查询会被放⼊慢查询⽇志中，⽇志的⻓度有上限，可以通过配置指定：slowlog-max-len：慢查询⽇志（本质是⼀个队列）的⻓度。默认是128，建议1000
• slowlog len：查询慢查询⽇志⻓度
• slowlog get n：读取n条慢查询⽇志
• slowlog reset：清空慢查询列表、

Redis 安全设置

Redis会绑定在0.0.0.0:6379，这样将会将Redis服务暴露到公⽹上，⽽Redis如果没有做身份认证，会出现严重的安全漏洞.
漏洞出现的核⼼的原因有以下3点：
• Redis未设置密码
• 利⽤了Redis的config set命令动态修改Redis配置
• 使⽤了Root账号权限启动Redis

为了避免漏洞，这⾥给出⼀些建议：
• Redis⼀定要设置密码
• 禁⽌线上使⽤下⾯命令：keys、 flushall、 flushdb、 config set等命令。可以利⽤rename-command禁⽤。

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 #把修改配置的命令重新命名
rename-command KEYS ""      #必禁命令，线上用这种查询方式绝对是不对的
rename-command FLUSHALL ""  #必禁命令，谁会清除数据呢
rename-command FLUSHDB ""   #必禁命令，谁会清除数据呢
rename-command CONFIG ""    #可以考虑重命名下

• bind：限制⽹卡，禁⽌外⽹⽹卡访问
• 开启防⽕墙
• 不要使⽤Root账户启动Redis
• 尽量不是有默认的端⼝

Redis内存优化

当Redis内存不⾜时，可能导致Key频繁被删除、响应时间变⻓、QPS不稳定等问题。当内存使⽤率达到90％以上时就需要我们警惕，并快速定位到内存占⽤的原因。
在这里插入图片描述
redis info 详解

内存占用
在这里插入图片描述
内存缓冲区常⻅的有三种：
复制缓冲区：主从复制的repl-backlog_buf，如果太⼩可能导致频繁的全量复制，影响性能。通过repl-backlog-size来设置，默认1mb。
AOF缓冲区：AOF刷盘之前的缓存区域，AOF执⾏rewrite的缓冲区。⽆法设置容量上限。
客户端缓冲区：分为输⼊缓冲区和输出缓冲区，输⼊缓冲区最⼤1G且不能设置，输出缓冲区可以设置。
通过下面这个命令进行设置：
class 是一个什么，集群的时候配replica

在这里插入图片描述

CLIENT LIST #可以通过Client List 定位问题客户端
Redis集群优化

在Redis的默认配置中，如果发现任意⼀个插槽不可⽤，则整个集群都会停⽌对外服务：

cluster-require-full-coverage  yes #通过这个配置来进行设置 no 是有个一个插槽不可以也可以使用

集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息⾄少包括：
• 插槽信息
• 集群状态信息
• 集群中节点越多，集群状态信息数据量也越⼤，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会⾮常⾼。
解决途径：
• 避免⼤集群，集群节点数不要太多，最好少于1000，如果业务庞⼤，则建⽴多个集群
• 避免在单个物理机中运⾏太多Redis实例
• 配置合适的cluster-node-timeout值

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

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

相关文章

MicroProfile OpenAPI上的Swagger UI

MicroProfile OpenAPI上的Swagger UI

MicroProfile OpenApi为我们提供了一种使用OpenApi 3描述我们JAX-RS API的标准化方法。如果您以前使用过swagger-jaxrs和swagger-annotations &#xff0c;由于OpenApi是基于Swagger构建的&#xff0c;因此您会感到非常熟悉。 2015年11月5日&#xff0c;SmartBear与3Scale&…
阅读更多...
linux 跟踪内存,用strace跟踪malloc内存分配

linux 跟踪内存,用strace跟踪malloc内存分配

strace介绍strace是一个非常有用的命令&#xff0c;它用于记录和跟踪程序运行期间收到的信号和调用的系统调用。strace的简单使用ubuntu64:~$ strace cat /dev/nullexecve("/bin/cat", ["cat", "/dev/null"], [/* 32 vars */]) 0brk(NULL) 0x1…
阅读更多...
归一化、标准化和正则化

归一化、标准化和正则化

归一化 Normalization 归一化一般是将数据映射到指定的范围&#xff0c;用于去除不同维度数据的量纲以及量纲单位。 常见的映射范围有 [0, 1] 和 [-1, 1] &#xff0c;最常见的归一化方法就是 Min-Max 归一化&#xff1a; 举个例子&#xff0c;我们判断一个人的身体状况是否健…
阅读更多...
slf4j绑定器_用于ADFLogger的SLF4J绑定–缺少的部分

slf4j绑定器_用于ADFLogger的SLF4J绑定–缺少的部分

slf4j绑定器由于最好的原因&#xff0c;在我的日常工作中&#xff0c;我希望为ADF Logger Oracle ADF提供一个SLF4J适配器。 毫不奇怪&#xff0c;slf4j没有用于ADFLogger的适配器&#xff0c;但是由于ADFLogger只是Java Util Logging的轻巧包装&#xff0c;因此花了一个多小时…
阅读更多...
核心网

核心网

在我们正式讲解之前&#xff0c;我想通过这张网络简图帮助大家认识一下全网的网络架构&#xff0c;通过对全网架构的了解&#xff0c;将方便您对后面每一块网络细节的理解。 这张图分为左右两部分&#xff0c;右边为无线侧网络架构&#xff0c;左边为固定侧网络架构。 无线侧…
阅读更多...
JDK 11：轻松取出单文件Java源代码程序

JDK 11：轻松取出单文件Java源代码程序

JDK 11 Early Access Builds包含与JEP 330相关的预览功能&#xff08;“启动单个文件源代码程序”&#xff09;。 我之前在“ Shebang即将来到Java&#xff1f; ”和“ 为JDK 11提议的JEP 329和JEP 330 ”&#xff0c;由于JDK 11 Early Access Builds&#xff0c;在这篇文章中…
阅读更多...
瑞利、莱斯与Nakagami-m信道衰落模型

瑞利、莱斯与Nakagami-m信道衰落模型

一、信道的定义与调制信道的数学模型 1.信道的定义与分类 信道&#xff08;Channel&#xff09;是指以传输媒质为基础的信号通道。根据新到的定义&#xff0c;如果信道仅是指信号的传输媒质&#xff0c;这种信道称为狭义信道&#xff1b;如果这种信道不仅是传输媒质&#xff…
阅读更多...
linux用if语句编程序,Shell 脚本基础 - 使用 if 语句进行条件检测

linux用if语句编程序,Shell 脚本基础 - 使用 if 语句进行条件检测

Bourne Shell 的 if 语句和大部分编程语言一样 - 检测条件是否真实&#xff0c;如果条件为真&#xff0c;shell 会执行这个 if 语句指定的代码块&#xff0c;如果条件为假&#xff0c;shell 就会跳过 if 代码块&#xff0c;继续执行之后的代码。if 语句的语法&#xff1a;if[判…
阅读更多...
卫星导航定位 -- 坐标系统与时间系统

卫星导航定位 -- 坐标系统与时间系统

原文https://blog.csdn.net/f2157120/article/details/81210843 1 协议天球坐标系 以地球质心为坐标原点&#xff0c;以地球自转的轴为z轴 2 协议地球坐标系 3 WGS-84坐标系 4 CGS2000坐标系统 5 直角坐标系与大地坐标系转换 6 大地坐标系转换 7 时间系统 8 GNSS时间系统 …
阅读更多...
博弈论学科整体概览

博弈论学科整体概览

一、博弈论的概念 博弈论又被称为对策论&#xff08;Game Theory&#xff09;既是现代数学的一个新分支&#xff0c;也是运筹学的一个重要学科。博弈论主要研究公式化了的激励结构间的相互作用。是研究具有斗争或竞争性质现象的数学理论和方法。博弈论考虑游戏中的个体的预测行…
阅读更多...
linux 进程组id 错乱,【Linux】终端，进程组，作业，会话及作业控制

linux 进程组id 错乱,【Linux】终端，进程组，作业，会话及作业控制

终端概念在UNIX系统中,用用户通过终端登录系统后得到一一个Shell进程,这个终端成为Shell进程的控制终端 (Controlling Terminal),控制终端是保存在PCB中的信息,而我们知道fork会复制PCB中的信息,因此由Shell进程启动的其它进程的控制终端也是这个终端。默认情况 下(没有重定向)…
阅读更多...
纳什均衡

纳什均衡

纳什均衡&#xff08;或者纳什平衡&#xff09;&#xff0c;Nash equilibrium ,又称为非合作博弈均衡&#xff0c;是博弈论的一个重要策略组合&#xff0c;以约翰纳什命名。 定义 经济学定义 数学定义 纳什均衡的定义&#xff1a;在博弈G﹛S1,…,Sn&#xff1a;u1,…&#x…
阅读更多...
奇异值分解(SVD)原理与在降维中的应用

奇异值分解(SVD)原理与在降维中的应用

奇异值分解 奇异值分解(Singular Value Decomposition&#xff0c;以下简称SVD)是在机器学习领域广泛应用的算法&#xff0c;它不光可以用于降维算法中的特征分解&#xff0c;还可以用于推荐系统&#xff0c;以及自然语言处理等领域。是很多机器学习算法的基石。本文就对SVD的…
阅读更多...
自相关函数与互相关函数

自相关函数与互相关函数

1 概念 1 自相关函数 2 互相关函数 从定义式中可以看到&#xff0c;互相关函数和卷积运算类似&#xff0c;也是两个序列滑动相乘&#xff0c;但是区别在于&#xff1a;互相关的两个序列都不翻转&#xff0c;直接滑动相乘&#xff0c;求和&#xff1b;卷积的其中一个序列需要先…
阅读更多...
Linux as4开启telnet,linux as4 虚拟机 上开启 telnet 和ssh 和 ftp 服务

Linux as4开启telnet,linux as4 虚拟机 上开启 telnet 和ssh 和 ftp 服务

1.telnet服务开启(1)输入[rootrehat ~]# chkconfig krb5-telnet --listkrb5-telnet on这是你的服务存在的状态&#xff0c;如果没有的话&#xff0c;可能是你的telnet名字和我的不一样&#xff0c;也可能是你的那个rpm包没有安装。我第一次的Linux中是没有安装的&#xff0…
阅读更多...
5G的场景、需求、通信速率

5G的场景、需求、通信速率

5G三大典型场景 5G有三大典型场景&#xff0c;这三大场景描述了5G的需求也反应了5G与4G的不同&#xff0c;如图所示&#xff0c;三大场景分别为&#xff1a;增强型移动宽带通信&#xff08;eMBB&#xff09;&#xff0c;大规模机器型通信&#xff08;eMTC&#xff09;和超高可…
阅读更多...
linux7禁用ipv6,RHEL 7 及 CentOS 7 彻底禁用IPv6的方法

linux7禁用ipv6,RHEL 7 及 CentOS 7 彻底禁用IPv6的方法

原标题&#xff1a;RHEL 7 及 CentOS 7 彻底禁用IPv6的方法IPv6在未来可能成为主流&#xff0c;但是就目前而言&#xff0c;很多软件对IPv6的支持并不是很完善&#xff0c;可能导致各类问题。RHEL 7 & CentOS 7 在启动时默认是加载IPv6相关模块的&#xff0c;而禁用IPV6的方…
阅读更多...
宏基站、分布式基站、小基站

宏基站、分布式基站、小基站

基站即公用移动通信基站&#xff0c;是无线电台站的一种形式&#xff0c;是指在一定的无线电覆盖区中&#xff0c;通过移动通信交换中心&#xff0c;与移动电话终端之间进行信息传递的无线电收发信电台。 目前&#xff0c;在 5G时代 &#xff0c;“ 宏基站 为主&#xff0c; 小…
阅读更多...
struts2面试问题_Struts2面试问答

struts2面试问题_Struts2面试问答

struts2面试问题Struts2是用Java开发Web应用程序的著名框架之一。 最近&#xff0c;我写了很多Struts2教程 &#xff0c;在这篇文章中&#xff0c;我列出了一些重要的Struts2面试问题以及答案&#xff0c;以帮助您进行面试。 什么是Struts2&#xff1f; Struts1和Struts2之间…
阅读更多...
什么是Mesh网络

什么是Mesh网络

网络间的通信原理 假设你的名字叫小不点&#xff0c;你住在一个大院子里&#xff0c;你的邻居有很多小伙伴&#xff0c;在门口传达室还有个看大门的李大爷&#xff0c;李大爷就是你的网关。当你想跟院子里的某个小伙伴玩&#xff0c;只要你在院子里大喊一声他的名字&#xff0…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023