redis 淘汰策略和持久化

news2024/11/18 22:43:36

文章目录

  • 一、淘汰策略
    • 1.1 背景
    • 1.2 淘汰策略
  • 二、持久化
    • 2.1 AOF日志
      • 2.1.1 AOF配置
      • 2.1.2 AOF策略
      • 2.1.3 AOF缺点
      • 2.1.4 AOF Rewrite
      • 2.1.5 AOF Rewrite配置
      • 2.1.6 AOF Rewrite缺点
      • 2.1.7 fork进程时的写时复制
      • 2.1.8 大key对持久化的影响
    • 2.2 RDB快照
      • 2.2.1 RDB配置
      • 2.2.2 RDB缺点
    • 2.3 混合持久化
    • 2.4 优缺点总结
    • 2.5 持久化的数据安全

一、淘汰策略

1.1 背景

Redis 之所以有淘汰策略，是因为 Redis 是基于内存的高性能键值存储系统，它将数据全部加载到内存中进行读写操作。但是，内存资源是有限的，当 Redis 使用的内存接近或超过系统可用内存时，就需要通过一些策略来释放内存空间。

1）键过期：通过expire / pexpire 设置key的生存时间。当key的生存周期达到时，将对应的key-value删除。

# 设置 key 的过期时间
expire key seconds
pexpire key milliseconds
# 查看 key 的过期时间
ttl key
pttl key

2）键的空闲时间（空转时长）：redis每次操作value时，会记录操作的时间戳和统计对key-value的操作次数。value 的类型有多种，底层由 redisObject 实现，这种通用的数据结构可以存储不同类型的 value。

typedef struct redisObject {
    unsigned type:4;        // 对象类型：string, hash, list, set
    unsigned encoding:4;    // 编码方式
    unsigned lru:LRU_BITS;  // lru：24位，最近一次访问时间，单位秒，
                            // lfu: 高16位，最近一次访问时间；低8位，逻辑访问次数
    int refcount;           // 引用计数，计数为 0，对象无人引用，可以回收
    void *ptr;              // 数据指针，指向对象内容
} robj;

lru字段用于记录操作value的时间，也会统计对key-value操作了多少次。可以使用object idletime key获取指定键的空闲时间。空闲时间指的是自上次对该键进行读取或写入操作以来所经过的时间。

# 对象空转时长
object idletime key

3）配置
redis.conf有两个参数配置淘汰策略，maxmemory和maxmemory-policy。
maxmemory限定redis可以使用的最大内存（单位是字节 ），一般设置为当前系统可用内存的一半；
maxmemory-policy用于制定淘汰策略。

# redis.conf
maxmemory <bytes>
maxmemory-policy noeviction

1.2 淘汰策略

1.2.1 针对过期key

  • volatile-lru：从设置了过期时间的键中，选择最近最少使用（Least Recently Used）（最长时间没有使用）的键进行删除。这种模式下， lru整个字段都用于记录时间。
  • volatile-lfu：从设置了过期时间的键中，选择最少使用次数的键进行删除。这种模式下 记录操作的时间和统计对key-value操作次数（8位统计次数，16位记录时间）。
  • volatile-ttl：从设置了过期时间的键中，选择剩余时间最短（最近就要过期）的键进行删除。这种模式下，记录操作的时间和统计对key-value操作次数（8位统计次数，16位记录时间）。
  • volatile-random：从设置了过期时间的键中，随机选择一个进行删除。ttl/pttl指令可以查询key还有多长时间到期。

1.2.2 针对所有key
allkeys-lru：从所有的键中，选择最近最少使用的键进行删除。无论键是否设置了过期时间。
allkeys-lfu，从所有的键中，选择最少使用次数的键进行删除。无论键是否设置了过期时间。
allkeys-random：从所有的键中，随机选择一个进行删除。无论键是否设置了过期时间。

1.2.3 禁止淘汰
noeviction：默认是禁止淘汰，如果数据达到了最大内存限制，在向redis中写入数据时会报错。

二、持久化

Redis 的数据全部在内存中，如果突然宕机，数据就会全部丢失。因此Redis 提供持久化机制，将内存中的数据以文件的形式存储到硬盘上， Redis 重启时加载持久化文件来恢复原来的数据。以此来保证Redis 的数据不会因为故障而丢失。

redis持久化的方式有：

  • AOF（Append-Only File）日志：记录了 Redis 服务器收到的所有写操作命令，每执行一条写操作命令，就以文本格式追加到一个日志文件中，通过回放这些写命令可以还原数据。
  • RDB（Redis Database）快照：以二进制形式将 Redis 数据库的快照（某一时刻的内存数据）保存在硬盘上，实现了数据的持久化存储。
  • 混合持久化：AOF+ RDB

2.1 AOF日志

AOF（Append-Only File）是 Redis 数据库中的一种持久化方式，用于将写操作追加到文件中。

Redis 每执行一条写操作命令，将命令以追加的方式写入 aof日志文件。aof文件存储的是Redis 协议的命令文本格式，例如：记录命令 set key value

 *3\r\n$3\r\nset\r\n$3\r\nkey\r\n$5\r\nvalue

Redis 重启时，通过重放（replay）AOF日志中指令序列来恢复 Redis 当前实例
的内存数据结构的状态；

2.1.1 AOF配置

通过修改 Redis 配置文件 redis.conf 进行设置，并在重启 Redis 服务后生效。

AOF（Append-Only File）持久化配置：

  • appendonly：若配置为 yes，启用 AOF 持久化。
  • appendfilename：设置 AOF 文件的名称。
  • appendfsync：设置刷新 AOF 文件到磁盘的策略。可选择的值有 always（每次修改都刷新）、everysec（每秒刷新一次）和 no（由操作系统决定刷新时机）。
  • no-appendfsync-on-rewrite：若配置为 yes，在执行 AOF 重写时禁止执行 AOF 文件刷新操作。
  • auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size：配置 AOF 自动重写的触发条件，其中 auto-aof-rewrite-percentage 表示 AOF 文件大小相对于上次重写后的大小增长的百分比，而 auto-aof-rewrite-min-size 表示 AOF 文件最小大小。
# 开启 aof
appendonly yes
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""

2.1.2 AOF策略

fsync 是一个与文件系统相关的系统调用，它用于将文件系统缓存区中的数据立即写入物理磁盘，主动刷盘。

Redis 写入 AOF 日志的过程：wirte 从用户缓冲写到内核缓冲，fysnc 从内核缓冲写到磁盘。

AOF 有三种策略：always、every_sec、no。这三种策略主要差异是fsync()的调用时机：

  • appendfsync always：在每次写操作完成后，都会立即将写命令追加到 AOF 文件，并调用系统的fsync函数将数据同步到磁盘。这是最安全的方式，但也会带来较大的性能开销。
  • appendfsync everysec：在每秒钟的间隔内，将写命令追加到 AOF 文件，然后调用系统的fsync函数将数据同步到磁盘。这种方式提供了较好的性能和较高的数据安全性之间的折中方案。在bio_aof_fsync线程中执行。
  • appendfsync no：不自己调用fsync()，由系统决定什么时候调用fsync()将数据刷到磁盘文件中。

2.1.3 AOF缺点

AOF会把所有的写操作命令都追加到文件中，包括一些冗余过期的数据，比如

127.0.0.1:6379> set jack 100
OK
127.0.0.1:6379> set jack 200
OK
127.0.0.1:6379> set jack 300
OK

AOF会将三个命令都保存到文件中，恢复数据的时候也是执行了这三个命令。但实际只需要最后一次的命令即可。

因此，随着时间越长，AOF 日志会越来越长，如果 redis 重启，重放整个 AOF 日志会非常耗时，导致 redis 长时间无法对外提供服务。

2.1.4 AOF Rewrite

AOF Rewrite 是 Redis 中一种用于优化和压缩 Append-Only 文件（AOF）的机制。

在 Redis 的 AOF 持久化模式中，所有写操作都会以追加方式记录到 AOF 文件中。随着时间的推移，AOF 文件会不断增长，可能变得非常大，占用大量存储空间，并且读取和恢复时也会变得较慢。为了解决这个问题，Redis 提供了 AOF Rewrite 机制，用于重写并优化 AOF 文件。

AOF Rewrite 的过程如下：

  1. 启动 AOF Rewrite：当启动 AOF Rewrite 时，Redis 将fork一个子进程来执行 AOF Rewrite 操作，同时继续接受客户端的新命令。

  2. 创建新的 AOF 文件：子进程首先会创建一个新的空白 AOF 文件，用于存储重写后的命令序列。

  3. 遍历现有 AOF 文件：子进程会读取并解析现有的 AOF 文件，将其中的命令逐个读取并转化为对应的数据结构。

  4. 合并相同命令：在重写过程中，子进程会合并相同的命令，以减少生成的新命令数量。这样可以减小新 AOF 文件的大小并提高读取性能。

  5. 写入新的 AOF 文件：合并后的命令将按顺序写入新的 AOF 文件中。在写入期间，子进程会继续接收并处理来自客户端的新命令。

  6. 更新主进程状态：当子进程完成写入新 AOF 文件后，它将向主进程发送信号，主进程接收到信号后将完成 AOF Rewrite 的最后步骤。

  7. 切换到新的 AOF 文件：主进程将关闭当前的 AOF 文件，并将新的 AOF 文件设置为当前的 AOF 文件。这样，之后的写操作将会追加到新的 AOF 文件中。

  8. 完成 AOF Rewrite：一旦切换完成，AOF Rewrite 过程就完成了。新的 AOF 文件将包含原始 AOF 文件中的所有数据，但经过了优化和压缩。

需要注意的是，在 AOF Rewrite 过程中，Redis 仍然会继续处理客户端的命令请求，不会停止服务。重写期间，Redis增加一个AOF重写缓冲区，主进程将期间执行后的写操作命令记录到AOF重写缓冲区。当子进程完成AOF重写后，会将AOF重写期间的AOF增量（AOF重写缓冲区的数据）追加到新的 AOF 文件中。并将新的 AOF 文件设置为当前的 AOF 文件。
在这里插入图片描述

2.1.5 AOF Rewrite配置

修改 redis.conf 配置，开启 AOF 重写。

# 开启 aof
appendonly yes

# 开启 aof复写
# 1. redis 会记录上次aof复写时的size，如果之后累计超过了
原来的size，则会发生aof复写；
auto-aof-rewrite-percentage 100
# 2. 为了避免策略1中，小数据量时产生多次发生aof复写，策略2
在满足策略1的前提下需要超过 64mb 才会发生aof复写；
auto-aof-rewrite-min-size 64mb

# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""

2.1.6 AOF Rewrite缺点

AOF Rewrite 在 AOF 基础上实现了瘦身，但是 AOF 复写的数据量仍然很大；加载会非常慢。因为数据恢复还是通过重放（replay）方式，即重新执行命令的方式，需要消耗CPU，需要走命令处理流程。

2.1.7 fork进程时的写时复制

fork 是一个系统调用，在操作系统中创建一个子进程。其中的写时复制（Copy-on-Write，COW）是一种优化技术，用于减少 fork 操作时的内存消耗和复制数据的开销。

写时复制的过程如下：

  1. 父子进程共享相同的物理内存：在执行 fork 时，父进程的内存空间会被完整地复制给子进程。但是实际上，父子进程会共享相同的物理内存页，并且这些页被标记为“只读”。

  2. 写操作触发缺页中断：当父进程（或子进程）尝试对共享的内存页进行写操作时，操作系统会检测到这个写操作，因为这些页是只读的。从而触发缺页中断

  3. 复制需要修改的内存页：当发生写操作并产生缺页中断时，操作系统会为触发缺页错误的父进程分配一块新的物理内存页，并将原始只读页中需要修改的部分复制到新的内存页中。

  4. 更新页表：在完成内存页的复制后，操作系统会更新父进程和子进程的页表，将对应的虚拟内存页映射到新的物理内存页上。子进程的页表指向原来的物理内存，父进程的页表指向新的物理内存。

  5. 继续执行：一旦复制和更新操作完成，父子进程就可以继续各自独立地执行，并且它们在内存中的数据是彼此隔离的。

写时复制的好处是避免了昂贵的内存复制操作。在 fork 之后，父子进程只有在需要进行写操作时才会发生实际的内存复制，避免物理内存的复制时间过长导致父进程长时间阻塞。

当然，这也是AOF Rewrite的时候，为了避免主进程写时复制造成父子进程内存数据不一致，使得重写后 AOF 日志的数据与 Redis 中的数据不一致，Redis 增加了一个 AOF 重写缓冲区。
在这里插入图片描述

2.1.8 大key对持久化的影响

大 key：Key 对应的 Value 很大，占用大量的空间。
1）fsync()压力大。比如AOF的always，它是在主线程中做的持久化，如果value非常的大，会长时间占用主线程，这就是一个耗时的操作，会影响redis的响应性能；大key对AOF的every_sec的影响较小，因为它在另外的线程 （bio_aof_fsync线程）进行持久化的；AOF的no对redis的影响也较小，因为fsync()由系统决定，因此压力在系统上。

2）fork时间比较长。redis中有一个object_info，会记录fork的时间，如果主线程fork超过1s，那么它的效率是非常低的，阻塞主线程。同时，写时复制造成持久化时间过长。

2.2 RDB快照

基于 AOF或 AOF Rewrite文件大的缺点，RDB是一种快照持久化；它通过 fork 进程，在子进程中将某一瞬间内存当中的数据键值对按照存储方式持久化到 RDB文件中；
RDB是基于内存中（所有数据）对象编码（ziplist、quiklist、intset、skiplist、int、embstr、raw等）直接持久化，存储的是经过压缩的二进制数据；由于是二进制数据，不管是落盘速度还是恢复数据速度都是最快的。
在这里插入图片描述

2.2.1 RDB配置

# 关闭 aof 同时也关闭了 aof复写
appendonly no
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 开启 rdb 也就是注释 save ""
# save ""

# redis 默认策略如下：
# 注意：写了多个 save 策略，只需要满足一个则开启rdb持久化
# 3600 秒内有以1次修改
save 3600 1
# 300 秒内有100次修改
save 300 100
# 60 秒内有10000次修改
save 60 10000

Redis 提供 save 和 bgsave 命令来生成 RDB 文件

# 自动开启 RDB
# 如果在 seconds 秒内，对 redis 共执行至少 changes 次修改，则自动执行命令
# 主线程生成 RDB 文件，阻塞主线程
save <seconds> <changes> 
# 子线程生成 RDB 文件，不阻塞主线程
bgsave <seconds> <changes>

2.2.2 RDB缺点

1）RDB的持久化方式是以某一时刻所有的内存数据为单位，而AOF持久化是以单条命令为单位。所以若采用 RDB持久化，一旦 redis 宕机，redis 将丢失一段时间的
内存数据，RDB方式丢失数据是最严重的。

2）RDB 需要经常 fork 子进程来保存数据集到硬盘上，当数据集比较大的时候，fork 的过程是非常耗时的，可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且 CPU性能不是很好的情况下，这种情况会持续1秒，AOF Rewrite 也需要 fork，但是你可以调节重写日志文件的频率来提高数据集的耐久度。

2.3 混合持久化

从上面知道，RDB文件小且加载快但丢失多，AOF文件大且加载慢但丢失少；混合持久化是吸取 RDB和 AOF两者优点的一种持久化方案；AOF Rewrite 的时候实际持久化的内容是 RDB，等持久化后，持久化期间修改的数据以AOF的形式附加到文件的尾部。

在混合持久化配置下，Redis 会同时进行 RDB 快照和 AOF 日志追加。这样，在遇到灾难性故障时，可以使用 RDB 文件进行快速恢复，而 AOF 文件可以提供更详细的日志记录并保证数据的更高持久性。

混合持久化的流程是：
1）当开启混合持久化时，在 AOF 重写日志时，fork 出来的子进程先根据与主线程共享的内存数据以 RDB 的方式写入新的 AOF 文件。主线程对 Redis 的写操作会记录到 AOF 重写缓冲区。

2）当 RDB 持久化结束后，重写缓冲区里的增量命令以 AOF 的形式追加到新的 AOF 文件。写入完成后，子线程通知主线程将新的的 AOF 文件替换旧的 AOF 文件。这样生成的 AOF 文件是： RDB 格式的全量数据 + AOF 格式的增量数据。

3）Redis 重启时，先加载 RDB 的内容，然后再重放增量 AOF 日志。
在这里插入图片描述

2.3.1 配置
混合持久化实际上是在 AOF Rewrite基础上进行优化；所以需要先开启 AOF Rewrite。

# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 开启 混合持久化
aof-use-rdb-preamble yes
# 关闭 rdb
save ""

2.3.2 缺点
启用混合持久化会带来额外的存储空间占用和性能开销，因为需要同时维护 RDB 文件和 AOF 文件。

2.4 优缺点总结

AOF

  • 优点：数据可靠，丢失较少。持久化鬼哟踩代价较低（只记录写命令）。
  • 缺点：AOF文件过大，数据恢复慢。

RDB：

  • 优点：RDB文件小，数据恢复快。
  • 缺点：数据一旦丢失，则丢失的数据量比较多。且持久化过程代价比较高（记录内存所以数据）。

混合持久化：

  • 优点：充分利用 RDB 和 AOF 持久化各自的优点，以提供更好的数据安全性和快速恢复能力
  • 缺点：带来额外的存储空间占用和性能开销，因为需要同时维护 RDB 文件和 AOF 文件。

2.5 持久化的数据安全

1）数据安全要考虑两个问题：

  1. 节点宕机（redis 是内存数据库，宕机数据会丢失）
  2. 磁盘故障

上述持久化方式只考虑到了节点宕机问题，但若磁盘故障，则无法恢复数据。因此，需要定期将持久化文件拷贝到其他地方。

2）拷贝持久化文件是安全的。
持久化文件一旦被创建， 就不会进行任何修改。 当服务器要创建一个新的持久化文件时， 它先将文件的内容保存在一个临时文件里面， 当临时文件写入完毕时， 程序才使用rename(2) 原子地用临时文件替换原来的持久化文件。

3）具体措施

  1. 创建一个定期任务 (cron job)， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹。
  2. 确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照。比如说， 你可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照。
  3. 至少每天一次， 将 RDB 备份到数据中心之外，或者至少是备份到运行 redis 服务器的物理机器之外。

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

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

相关文章

二分查找算法（全网最详细代码演示）

二分查找算法（全网最详细代码演示）

二分查找也称 半查找&#xff08;Binary Search&#xff09;&#xff0c;它时一种效率较高的查找方法。但是&#xff0c;折半查找要求线性表必须采用顺序存储结构&#xff0c;而且表中元素按关键字 有序 排列。 注意&#xff1a;使用二分查找的前提是 该数组是有序的。 在实际开…
阅读更多...
web前端常用调试工具

web前端常用调试工具

概述 当我们写 webapp 或者 移动端H5网页时&#xff0c;要在手机上调试并不容易。 alert&#xff1a;很早之前的调试办法&#xff08;已被抛弃&#xff09; vconsole&#xff1a;是2016年由微信公众平台前端团队推出&#xff08;目前大量使用&#xff09; eruda&#xff1a…
阅读更多...
解读随机森林的决策树：揭示模型背后的奥秘

解读随机森林的决策树：揭示模型背后的奥秘

一、引言 随机森林[1]是一种强大的机器学习算法&#xff0c;在许多领域都取得了显著的成功。它由多个决策树组成&#xff0c;而决策树则是构建随机森林的基本组件之一。通过深入解析决策树&#xff0c;我们可以更好地理解随机森林模型的工作原理和内在机制。 决策树是一种树状结…
阅读更多...
虚拟现实技术（VR）

虚拟现实技术（VR）

目录 1.什么是虚拟现实技术 2.虚拟现实技术的由来 3.虚拟现实技术给人类带来的好处 4.虚拟现实技术未来的走向 1.什么是虚拟现实技术 虚拟现实技术&#xff08;Virtual Reality&#xff0c;简称VR&#xff09;是一种通过计算机生成的模拟环境&#xff0c;使用户能够身临其境…
阅读更多...
【js】经纬度位置获取navigator.geolocation.getCurrentPosition:

【js】经纬度位置获取navigator.geolocation.getCurrentPosition:

文章目录 一、经纬度位置获取navigator.geolocation.getCurrentPosition二、getCurrentPosition()在google chrome上不起作用 一、经纬度位置获取navigator.geolocation.getCurrentPosition 【文档】https://developer.mozilla.org/zh-CN/docs/Web/API/Window/navigator // 获取…
阅读更多...
Redis 数据库高可用

Redis 数据库高可用

Redis 数据库的高可用 一.Redis 数据库的持久化 1.Redis 高可用概念 &#xff08;1&#xff09;在web服务器中&#xff0c;高可用是指服务器可以正常访问的时间&#xff0c;衡量的标准是在多长时间内可以提供正常服务&#xff08;99.9%、99.99%、99.999%等等&#xff09;。 …
阅读更多...
《MySQL 实战 45 讲》课程学习笔记（三）

《MySQL 实战 45 讲》课程学习笔记（三）

事务隔离 事务就是要保证一组数据库操作&#xff0c;要么全部成功&#xff0c;要么全部失败。 隔离性与隔离级别 事务特性&#xff1a;ACID&#xff08;Atomicity、Consistency、Isolation、Durability&#xff0c;即原子性、一致性、隔离性、持久性&#xff09;。当数据库上…
阅读更多...
Web-1-网站工作流程介绍

Web-1-网站工作流程介绍

我们学习web开发&#xff0c;首先要知道什么是Web&#xff1f; Web: 全球广域网&#xff0c;也称为万维网(www World Wide Web)&#xff0c;能够通过浏览器访问的网站 比如我展示的这京东&#xff0c;淘宝唯品会都叫做网站&#xff0c;那么现在大家想一下&#xff0c;你还知道什…
阅读更多...
用Ubuntu交叉编译Linux内核源码并部署到树莓派4B上

用Ubuntu交叉编译Linux内核源码并部署到树莓派4B上

参考文章 1. 配置交叉编译环境 之前在ubuntu上配置过了&#xff0c;直接跳过 2.获取Linux内核源码 Linux内核源码链接 到链接里面选择自己合适版本的内核源码下载下来&#xff0c;然后传到ubuntu中进行解压 3.Linux内核源码的配置 参考文章 厂家配linux内核源码&#xff…
阅读更多...
数据可视化库pyecharts简单入门

数据可视化库pyecharts简单入门

文章目录 0. 介绍1. 快速开始1.1 安装1.1.1 pip安装1.1.2 源码安装 1.2 快速上手1.2.1 柱状图1.2.2 链式调用1.2.3 使用options选项配置参数&#xff08;一切皆options&#xff09;1.2.4 渲染成图片文件1.2.5 使用主题1.2.6 地图 2. 全局配置项2.1 使用指南2.2 常用全局配置项2…
阅读更多...
直呼牛逼！阿里最新 SpringBoot 进阶笔记涵盖了 SpringBoot 所有骚操作

直呼牛逼！阿里最新 SpringBoot 进阶笔记涵盖了 SpringBoot 所有骚操作

相信从事 Java 开发的朋友都听说过 SSM 框架&#xff0c;老点的甚至经历过 SSH&#xff0c;说起来有点恐怖&#xff0c;比如我就是经历过 SSH 那个时代未流。当然无论是 SSM 还是 SSH 都不是今天的重点&#xff0c;今天要说的是 Spring Boot&#xff0c;一个令人眼前一亮的框架…
阅读更多...
Intellij IDEA有什么奇技淫巧?

Intellij IDEA有什么奇技淫巧?

IDEA全称 IntelliJIDEA&#xff0c;是java语言开发的集成环境&#xff0c;IntelliJ在业界被公认为最好的java开发工具之一&#xff0c;尤其在智能代码助手、代码自动提示、重构、J2EE支持、Ant、JUnit、CVS整合、代码审查、创新的GUI设计等方面的功能可以说是超常的。 idea下载…
阅读更多...
【大数据趋势】7月30日 汇率，恒指期货的大数据趋势概率分析。

【大数据趋势】7月30日 汇率，恒指期货的大数据趋势概率分析。

1. 数据源头之一 : 汇率变化 从程序模拟趋势来看&#xff0c;美元在持续弱势状态&#xff0c;周线上正在构建一个新的下跌趋势&#xff0c;而且正在反抽过程中&#xff0c;即将完成&#xff0c;如果没有外部干预&#xff0c;会顺势往下。从月线来看&#xff0c;高点逐步降低&a…
阅读更多...
【论文笔记】神经网络压缩调研

【论文笔记】神经网络压缩调研

神经网络压缩调研 背景现有的深度模型压缩方法NetWork Prunning 网络剪枝设计结构化矩阵知识蒸馏权值共享Parameter Quantization&#xff08;参数量化&#xff09;量化和二进制化伪量化Architecture Design&#xff08;Depth Separable Convolution&#xff09;分解卷积 背景 …
阅读更多...
【Linux】进程轻松入门

【Linux】进程轻松入门

目录 一&#xff0c; 冯* 诺依曼体系结构 1&#xff0c;存储结构 ​编辑 二&#xff0c; 操作系统 1&#xff0c;概念 2&#xff0c;设计OS的目的 3&#xff0c;定位 4&#xff0c;如何理解 "管理" 5&#xff0c; 总结 三&#xff0c;进程 1. 概念 那么…
阅读更多...
【C语言所有操作符详解2】

【C语言所有操作符详解2】

目录 条件操作符 逗号表达式 下标引用、函数调用和结构成员 [ ] 下标引用操作符 ( ) 函数调用操作符 访问一个结构的成员 表达式求值 隐式类型转换 隐式类型转换 整型提升 整型提升的意义: 如何进行整型提升呢? 算术转换 操作符的属性 操作符优先级 …
阅读更多...
Redis系列一：介绍

Redis系列一：介绍

介绍 The open source, in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker. 相关资源 Redis 官网&#xff1a;https://redis.io/ 源码地址&#xff1a;https://github.com/redis/redis Redis 在线测试&#…
阅读更多...
RS232转ETHERCAT连接ethercat通讯过程描述

RS232转ETHERCAT连接ethercat通讯过程描述

我们将为大家介绍一款强大的设备——捷米JM-ECT-RS485/232通讯网关。这是一款自主研发的ETHERCAT从站功能的网关&#xff0c;它能够将ETHERCAT网络和RS485或RS232设备无缝连接。 这款网关在ETHERCAT总线和RS485或RS232总线中均能发挥主站或从站的作用。它的最大特点就是解决了…
阅读更多...
企业情报管理系统

企业情报管理系统

软件简介 基于 SpringBoot 的权限管理系统&#xff0c;易读易懂、界面简洁美观。 核心技术采用 Spring、MyBatis、Shiro 没有任何其它重度依赖。直接运行即可。 平台简介 企业情报管理系统&#xff0c;主要包括情报分析、文章情报、报告情报、数据情报、数据管理、AI管理、平…
阅读更多...
动态规划 丑数（三指针 谁先创造谁先功德++）

动态规划 丑数（三指针 谁先创造谁先功德++）

无语这是medium题目吗 先放暴力解法 反正超时 无法ac本题 2, 3, 5 这前 3 个丑数一定要乘以其它的丑数&#xff0c; 所得的结果才是新的丑数 合并过程中重复解的处理 nums2, nums3, nums5 中是存在重复的解的&#xff0c; 例如 nums2[2] 32, nums3[1] 23 都计算出了 6 这个结…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023