发布日期:2024-02-12 19:41:27

Nosql之Redis详解

今天给各位分享Nosql之Redis详解的知识,其中也会对Nosql之Redis详解进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文导读目录:

1、yy频道分组设计图可复制

2、Nosql之Redis详解

3、50 个最佳 After Effects 插件和脚本

  ★©无忧考网校园生活频道为大家整理的《yy频道分组设计图可复制》,供大家参考。更多阅读请查看本站校园生活频道!

  ╭゛更新中

  ╭゛2014

  灬Forever丶 回忆

  灬 Forever丶过客

  灬 Forever丶陌生

  灬 Forever丶嘆息

  灬 Forever丶落寞

  灬 Forever丶忧伤

  灬 Forever丶空虚

  ■■■■■

  □□□□□

  有了新欢

  忘了旧爱

  ═════

  "没想到

  就连友情

  "也会用到这句

  &

  会不会有一个人

  在我难过的时候

  二话不说

  给我一个拥抱  定义: Redis(Remote Dictionary Server ),即远程字典服务,它是一个开源的,使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。Redis 默认端口为 6379,是一个NoSQL数据库。

      Redis是一个key-value存储系统,和Memcached类似,只是它支持存储的value类型相对更多,包括 字符串(strings), 散列(hashes), 列表(lists), 集合(sets), zset有序集合(sorted sets) 与范围查询, bitmaps, hyperloglogs 和 地理空间(geospatial) 索引半径查询。 Redis 内置了 复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(transactions) 和不同级别的 磁盘持久化(persistence), 并通过 Redis哨兵(Sentinel)和自动 分区(Cluster)提供高可用性(high availability)。这些数据类型都支持push/pop(汇编中的堆栈操作指令,操作数与栈的压入和弹出)、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。Redis也被称为数据结构服务器,因为值(value)可以是 字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

      Redis还支持各种不同方式的排序。与memcached一样,为了提高数据效率,将数据缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。

      Redis 是一个高性能的key-value数据库,其补偿了memcached对key/value类数据存储的短板,对关系数据库起到很好的补充作用,且其有适应Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等多种平台环境的客户端,便于用户操作。

  集群:Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步。

  附: 参考书籍《redis开发与运维》,地址:https://pan.baidu.com/s/12rlHhOKP7_72GE8a74lN1g;eep2 2.1 Redis主从复制原理:

  1、当启动一个Slave进程后,它会向Master发送一个SYNC Command,请求同步连接。当master接到命令后,会执行BGSAVE命令生成RDB文件(即快照文件),如果主节点在生成RDB的过程当中,客户端发来了写入指令,这个时候主节点会把指令全部写入缓冲区,等RDB生成完了,会把RDB文件发送给从节点,最后再把缓冲区的指令发送给从节点。无论是第一次连接还是重新连接,Master都会启动一个后台进程,将数据快照保存到数据文件中,同时Master会记录所有修改数据的命令并追加缓存在数据文件中;

  2、后台进程完成缓存操作后,Master就发送数据文件(dump.rdb)给Slave,Slave端将数据文件保存到硬盘上,然后将其在加载到内存中,接着Master将缓存下来的所有修改数据的操作命令,发送给Slave端。

  3、若Slave出现故障导致宕机,恢复正常后会自动重新连接,Master收到Slave的连接后,将其完整的数据文件发送给Slave,如果Mater同时收到多个Slave发来的同步请求,Master只会在后台启动一个进程保存数据文件,然后将**其发送给所有的Slave,**确保Slave正常。

  4、实际工作中,我们要存储海量的数据,那么BGSAVE指令生成的RDB文件会非常巨大,这个文件传送给从节点也会非常慢,如果缓冲区命令很多的话,从节点同步数据时也会执行很久,所以,考虑解决单点问题和海量存储问题,就要做Redis集群。可以考虑:把一个主从结构变成多个,把存储的key分摊到各个主从结构中来分担压力。

  Redis复制工作原理: 如果设置了一个Slave,无论是第一次连接还是重连到Master,它都会发出一个SYNC命令;

  当Master收到SYNC命令之后,会做两件事:

  a) Master执行BGSAVE,即在后台保存数据到磁盘(rdb快照文件);

  b) Master同时将新收到的写入和修改数据集的命令存入缓冲区(非查询类);

  当Master在后台把数据保存到快照文件完成之后,Master会把这个快照文件传送给Slave,而Slave则把内存清空后,加载该文件到内存中;

  而Master也会把此前收集到缓冲区中的命令,通过Reids命令协议形式转发给Slave,Slave执行这些命令,实现和Master的同步;

  Master/Slave此后会不断通过异步方式进行命令的同步,达到最终数据的同步一致;

  需要注意的是Master和Slave之间一旦发生重连都会引发全量同步操作。但在2.8之后版本,也可能是部分同步操作。

  注:部分复制工作从 2.8版本开始,当Master和Slave之间的连接断开之后,他们之间可以采用持续复制处理方式代替采用全量同步。 Master端为复制流维护一个内存缓冲区(in-memory backlog),记录最近发送的复制流命令;同时,Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID(Master run id)。当网络断开,Slave尝试重连时: a. 如果MasterID相同(即仍是断网前的Master服务器),并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在,则Master会将缺失的这段时间的所有命令发送给Slave执行,然后复制工作就可以继续执行了; 否则,依然需要全量复制操作; 2.2 Redis主从复制架构:

  如上图所示,Redis 在 Master-Slave(主从)模式下,可像图中树状结构那样,级联多个salve,Redis Server 可以设置为另一个 Redis Server 的主机(从机),从机定期从主机拿数据,而master下的一个从机同样可以设置为另一个 Redis Server 的主机,即三层关系模型,从而形成 Redis Server 集群,同一个Master可以拥有多个Slaves,Master下的Slave还可以继续接受同一架构中其它slave的链接与同步请求,实现数据的级联复制,即Master->Slave->Slave模式;无论是主机还是从机都是 Redis Server。主机Master可负责读写服务,从机**Slave只负责读,**其中多个slave专门提供只读查询与数据的冗余,Master端专门提供写操作;

  Redis 复制在 master 这一侧是非阻塞的,也就是说在和 slave 同步数据的时候,master 仍然可以执行客户端的操作命令而无需等待相关命令结束退出,不受正在复制/同步命令的影响,Master会继续处理一个或多个slave的读写请求。Slave端同步数据也可以修改为非阻塞的方式,当slave在执行新的同步时,它仍可以用旧的数据信息来提供查询;否则,当slave与master失去联系时,slave会返回一个错误给客户端;

  另外,可通过配置禁用Master数据持久化机制,将其数据持久化操作交给Slaves完成,避免在Master中需开销独立的进程来完成此操作,降低master的负载,实现其的轻量级。 2.3 Redis 分区

  分区是分割数据到多个Redis实例的处理过程,因此每个实例只保存key的一个子集。

  分区类型

  Redis 有两种类型分区。 假设有4个Redis实例 R0,R1,R2,R3,和类似user:1,user:2这样的表示用户的多个key,对既定的key有多种不同方式来选择这个key存放在哪个实例中。也就是说,有不同的系统来映射某个key到某个Redis服务。

  范围分区

  最简单的分区方式是按范围分区,就是映射一定范围的对象到特定的Redis实例。

  比如,ID从0到10000的用户会保存到实例R0,ID从10001到 20000的用户会保存到R1,以此类推。

  这种方式是可行的,并且在实际中使用,不足就是要有一个区间范围到实例的映射表。这个表要被管理,同时还需要各 种对象的映射表,通常对Redis来说并非是好的方法。

  哈希分区:

  另外一种分区方法是hash分区。这对任何key都适用,也无需是object_name:这种形式,像下面描述的一样简单:

  用一个hash函数将key转换为一个数字,比如使用crc32 hash函数。对key foobar执行crc32(foobar)会输出类似93024922的整数。

  对这个整数取模,将其转化为0-3之间的数字,就可以将这个整数映射到4个Redis实例中的一个了。93024922 % 4 = 2,就是说key foobar应该被存到R2实例中。注意:取模操作是取除的余数,通常在多种编程语言中用%操作符实现。 2.4 Redis 持久化

  Redis 作为内存数据库,数据运行期间都是放在内存里的,但是内存中数据容易在进程重启后丢失,因此需要将内存中的数据,包括数据库状态保存到磁盘,即内存落盘来实现持久化,Redis是通过将操作写入日志文件来实现这一功能的,从而来保证数据不会因为宕机而丢失。Redis 为我们提供了2种持久化方案:一种是基于快照的RDB(Redis DataBase),另外一种是基于 AOF 日志。实际Redis服务提供四种持久化存储方案:RDB、AOF、虚拟内存(VM)和 DISKSTORE。虚拟内存(VM)方式,从Redis Version 2.4开始就被官方明确表示不再建议使用,Version 3.2版本中更找不到关于虚拟内存(VM)的任何配置范例;DISKSTORE方式,是从Redis Version 2.8版本开始提出的一个存储设想,到目前为止Redis官方也没有在任何stable版本中明确建议使用这用方式。在Version 3.2版本中同样找不到对于这种存储方式的明确支持。

  首先我们来回顾下数据从 Redis 中到磁盘的这一过程: 客户端向数据库发起 write 指令(数据在客户端的内存中);数据库收到 write 指令和对应的写数据(数据在服务端内存中);数据库调用将数据写入磁盘的系统调用函数(数据在系统内核缓冲区);操作系统将写入缓冲区中的数据写到磁盘控制器中(数据在磁盘缓冲区中);磁盘控制器将磁盘缓冲区中的数据写入磁盘的物理介质中(数据真正写入磁盘中)。

  1)RDB (Redis Database快照/内存快照) 通过快照的形式将数据保存到磁盘中。所谓快照,可以理解为在某一时间点将数据集拍照并保存下来。Redis 通过这种方式可以在指定的时间间隔或者执行特定命令(save/bgsave)时将当前系统中的数据保存备份,以二进制的形式写入磁盘中,默认文件名为dump.rdb。RDB 的触发有3种机制,执行save命令;执行bgsave命令;在redis.config中配置自动化,rdb文件保存的目录是有dir配置项决定;文件名则是由dbfilename决定;触发机制则有save决定;rdbcompression配置项就决定是否压缩rdb文件,默认为yes。Redis作为单线程程序,要同时负责多个客户端套接字的并发读写操作和内存结构的逻辑读写。前2种方式多用于调试时客户端执行,而在生产环境中我们更多地需要是自动化的触发机制,即在redus.config中对持久化进行配置:

  save 900 1 //是指在 900 秒内,如果有一个或一个以上的修改操作,那么就自动进行一次自动化备份;格式:save 秒钟 写操作次数;默认是1分钟内改了1万次,或5分钟内改了10次,或15分钟内改了1次。

  save 300 10 //意味着在 300 秒内如果有十次或以上的修改操作,那么就进行数据备份

  save “” //禁止掉数据持久化

  stop-writes-on-bgsave-error yes //如果持久化出错,主进程是否停止写入,yes停止写

  ​​​​​​​rdbcompression yes //开启压缩,即对存储到磁盘中的快照执行压缩后再存储,edis会采用LZF算法进行压缩,当然这会消耗一定的CPU

  rdbchecksum yes //开启完整性检查,存储快照后,让redis使用CRC64算法来进行数据校验,可能会增加大约10%的性能消耗

  dbfilename dump.rdb //制定rdb文件名称

  dir /home/redis/data/ //文件保存路径

  RDB生成过程:(*.rdb文件)

  RDB中的核心思路是Copy-on-Write(COW),来保证在进行快照操作的这段时间,需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中,一方面Redis主进程会fork一个新的快照进程专门来做这个事情,这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域,待快照操作结束后才会同步到原来的内存区域。在没有将数据全部写入到磁盘前,这次快照操作都不算成功。如果出现了服务崩溃的情况,将以上一次完整的RDB快照文件作为恢复内存数据的参考。Redis会自动读取rdb日志恢复数据;在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作,待操作成功后才会用这个临时文件替换掉上一次的备份。鉴于RDB文件生成机制的资源消耗,4.0版本中引入的RDB和AOF的混合方式。

  父进程进程会fork()产生一个和自己完全相同的子进程,这里借用了Linux内核的“写时复制技术COW”,父子进程会共享(此共享并不是我们通常所说的共享映射和私有映射,而是通过将页映射到每个进程页表形成共享)所有的私有可写的物理页,并将父子进程对应的页表项修改为只读,当有一方试图写共享的物理页,由于页表项属性是只读的会发生COW缺页异常,缺页异常处理程序会为写操作的一方分配新的物理页,并将原来共享的物理页内容拷贝到新页,然后建立新页的页表映射关系,这样写操作的进程就可以继续执行,不会影响另一方,父子进程对共享的私有页面访问就互相不干扰了,当共享的页面最终只有一个拥有者(即使其他映射页面到自己页表的进程都发生写时复制分配了新的物理页),这个时候如果拥有者进程想要写这个页就会重新使用这个页而不用分配新页。这样,通过 fork 创建的子进程能够获得和父进程完全相同的内存空间,而父进程对内存的修改对于子进程是不可见的,两者不会相互影响;通过 fork 创建子进程时不会立刻触发大量内存的拷贝,内存在被修改时会以页为单位进行拷贝,这也就避免了大量拷贝内存而带来的性能问题;

  save :save时只管保存,其它不管,全部阻塞。手动保存。不建议。

  bgsave:Redis会在后台异步进行快照操作, 快照同时还可以响应客户端请求。

  注意:

  RDB文件体积小,生成及加载快,但是rdb持久化方式不能做到实时持久化,异常情况下容易导致数据丢失。另外,不同版本的rdb文件可能存在不兼容的情况。RDB文件非常适合做容灾备份,比如每天凌晨生成RDB文件。另外,如果redis里存放的数据不是太重要,比如使用redis做缓存,丢失部分数据没有影响的话,使用RDB通常是更佳的方式。redis数据存放的分区快要写满时,在不停止redis下将数据写到另一个分区中。我们可以使用config set dir ‘新分区目录’ 修改rdb文件存放的目录。然后执行bgsave生成新的RDB文件到新的目录中。

  RDB生成过程函数调用:

  RDB优点: RDB文件是某个时间节点的快照,默认使用LZF算法进行压缩,压缩后的文件体积远远小于内存大小,适用于备份、全量复制等场景;Redis加载RDB文件恢复数据要远远快于AOF方式;

  RDB缺点: RDB方式实时性不够,无法做到秒级的持久化;每次调用bgsave都需要fork子进程,fork子进程属于重量级操作,频繁执行成本较高;RDB文件是二进制的,没有可读性,AOF文件在了解其结构的情况下可以手动修改或者补全;

  版本兼容RDB文件问题;针对RDB不适合实时持久化的问题,Redis提供了AOF持久化方式来解决

  2)AOF:(Append Only-file)

  RDB 持久化是全量备份,比较耗时,所以Redis就提供了一种更为高效地AOF持久化方案,它的工作原理可简单理解如下:Redis的AOF日志采用写后日志,即先写内存,后写日志,因为Redis 在向 AOF 里面记录日志的时候,并不会先去对这些命令进行语法检查。Redis先执行命令,把数据写入内存,然后才记录日志。AOF日志记录Redis的每个写命令,步骤分为:命令追加(append)、文件写入(write)和文件同步(sync),这些命令是以文本形式保存。AOF日志存储的是Redis服务器指令序列,AOF只记录对内存进行修改的指令记录。当服务器异常从新启动时,Redis就会利用 AOF 日志中记录的这些操作从新构建原始数据集。

  Redis会在收到客户端修改指令后,进行参数修改、逻辑处理,如果没有问题,就立即将该指令文本存储到 AOF 日志中,也就是说,先执行指令才将日志存盘。这点不同于 leveldb、hbase等存储引擎,它们都是先存储日志再做逻辑处理。服务器在执行完一个写命令之后,会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。关于何时将 aof_buf 缓冲区的内容写入AOF文件中,Redis提供了3种写回策略:它是通过appendfsync参数来配置,简要描述如下: always:每次发生数据修改就会立即记录到磁盘文件中,这种方案的完整性好但是IO开销很大,性能较差;everysec:在每一秒中进行同步,速度有所提升。但是如果在一秒内宕机的话可能失去这一秒内的数据;no:默认配置,即不使用 AOF 持久化方案。可以在redis.config中进行配置,appendonly no改换为yes;

  AOF 重写机制:

  AOF会记录每个写命令到AOF文件,随着Redis的运行,AOF文件会变得越来越大。如果不加以控制,会对Redis服务器,甚至对操作系统造成影响,另外如果实例宕机重启,那么重放整个AOF将会变得十分耗时,而在日志记录中,又有很多无意义的记录,比如我现在将一个数据 incr 一千次,那么就不需要去记录这1000次修改,只需要记录最后的值即可。数据恢复也越慢。为了解决AOF文件体积膨胀的问题,Redis提供AOF文件重写机制来对AOF文件进行“瘦身”。

  Redis 提供了bgrewriteaof指令用于对AOF日志进行重写,该指令运行时会开辟一个子进程,即主线程fork出后台的bgrewriteaof子进程,fork会把主线程的内存拷贝一份给bgrewriteaof子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。所以aof在重写过程,在fork进程时是会阻塞主线程的。

  同样的也可以在redis.config中对重写机制的触发进行配置:通过将no-appendfsync-on-rewrite设置为yes,开启重写机制;auto-aof-rewrite-percentage 100意为比上次从写后文件大小增长了100%再次触发重写;auto-aof-rewrite-min-size 64mb意为当文件至少要达到64mb才会触发自动重写;重写也是会耗费资源的,所以当磁盘空间足够的时候,这里可以将 64mb 调整更大写,降低重写的频率,达到优化效果。将AOF配置为appendfsync everysec之后,Redis在处理一条命令后,并不直接立即调用write将数据写入 AOF 文件,而是先将数据写入AOF buffer(server.aof_buf)。调用write和命令处理是分开的,Redis只在每次进入epoll_wait之前做 write 操作。Redis另外的两种策略,一个是永不调用 fsync,让操作系统来决定合适同步磁盘,这样做很不安全;另一个是来一个指令就调用 fsync 一次,这种导致结果非常慢。这两种策略在生产环境中基本都不会使用。

  AOF持久化开启:默认情况下,Redis是没有开启AOF的;可以通过配置redis.conf文件来开启AOF持久化,关于AOF的配置如下:

  3) RDB和AOF混合方式(4.0版本)

  Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说,就是内存快照以一定的频率执行,在两次快照之间,使用 AOF 日志记录这期间的所有命令操作。

  这样一来,快照不用很频繁地执行,这就避免了频繁 fork 对主线程的影响。而且,AOF 日志也只用记录两次快照间的操作,也就是说,不需要记录所有操作了,因此,就不会出现文件过大的情况了,也可以避免重写开销。这个方式既能享受到 RDB 文件快速恢复的好处,又能享受到 AOF 只记录操作命令的简单优势, 实际环境中用的很多。

  恢复过程: 这时,我们只需重启redis,Redis重启时会判断是否开启aof,如果开启了aof,那么就优先加载aof文件;如果aof存在,那么就去加载aof文件,加载成功的话redis重启成功,如果aof文件加载失败,那么会打印日志表示启动失败,此时可以去修复aof文件后重新启动;若aof文件不存在,那么redis就会转而去加载rdb文件,如果rdb文件不存在,redis直接启动成功;

  如果rdb文件存在就会去加载rdb文件恢复数据,如加载失败则打印日志提示启动失败,如加载成功,那么redis重启成功,且使用rdb文件恢复数据;至于为什么会优先加载AOF呢?因为AOF保存的数据更完整,理论上AOF基本上最多损失1s的数据。

  总结:RDB的快照、AOF的重写都需要fork,这是一个重量级操作,会对Redis造成阻塞。为了不影响Redis主进程响应,我们需要尽可能降低阻塞。比如: 降低fork的频率,如:手动来触发RDB生成快照、与AOF重写;建议定期检查Redis的情况,然后可以手动触发备份、重写数据;控制Redis最大使用内存,防止fork耗时过长;使用更高配置的硬件;合理配置Linux的内存分配策略,避免因为物理内存不足导致fork失败。如果Redis中的数据不是特别敏感或者可以通过其它方式重写生成数据,可以考虑关闭持久化,如果丢失数据可以通过其它途径补回;单机上部署多个实例的情况,要防止多个机器同时运行持久化、重写操作,防止出现内存、CPU、IO资源竞争,让持久化变为串行;配置主从机器,利用一台从机器进行备份处理,其它机器正常响应客户端的命令;最后就是考虑RDB持久化与AOF持久化可以同时使用。 2.5 Key和哈希槽(slot)

  1)Redis中key的理解

  Redis 服务器都有多个 Redis 数据库,每个Redis 数据库都有自己独立的键值空间。Redis的key都是以字符串的形式存储的,它使用一个SDS ( simple dynamic string (简单的动态字符串)变量来存储字符串。每个 Redis 数据库使用 dict 保存数据库中所有的键值对,用它作为数据库的底层实现,同样也是哈希键的底层实现,而键值空间的键也就是数据库的键,每个键都是一个字符串对象,而值对象有5种,可能为:字符串对象、列表对象、哈希表对象、集合对象和有序集合对象中的一种对象,因Redis支持5种数据类型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。但Redis并没有直接使用数据结构来实现键值对数据库,而是基于这些数据结构创建了一个对象系统,这个系统包含了上述五种类型对象;Redis使用对象来表示数据库中的键和值,每次当我们在Redis的数据库中新创建一个键值对时,我们至少要创建两个对象,一个对象用作键值对的键(键对象),另一个对象用作键值对的值(值对象)。Redis中的每个对象都由一个RedisObject结构表示。

  除了键空间,Redis 也使用 Dict 结构来保存键的过期时间,其键是键空间中的键值,而值是过期时间;通过过期字典,Redis 可以直接判断一个键是否过期,首先查看该键是否存在于过期字典,如果存在,则比较该键的过期时间和当前服务器时间戳,如果大于,则该键过期,否则未过期。如下图所示:

  Key-value在redis存储的时候,通常会有层级或者说是目录,这时候我们在set的时候,需要将key值使用":"的 符号来区分层级关系;每个key都对应位Redis中的一个对象,对象的类型也是五种,分别代表字符串、列表、集合、有序集合和哈希对象。redis的对象系统中使用引用计数来实现内存回收。当引用计数为0时,释放对象回收内存。另外,对象的ptr指针指向对象的底层数据结构,对应encoding属性。

  Redis的key是以hash表的形式存储的,上层存储表现是字典;Redis 使用「dict」结构来保存所有的键值对(key-value)数据,它是一个全局哈希表,所以对 key 的查询能以 O(1) 时间得到( O(1) 表耗时/耗空间与输入数据大小无关,无论输入数据增大多少倍,耗时/耗空间都不变。 哈希算法就是典型的O(1)时间复杂度,无论数据规模多大,都可以在一次计算后找到目标(不考虑冲突的话));

  总之,每个 key 计算之后都会对应一个编号在 0-16383 之间的哈希槽,redis使用一个「哈希表」来保存所有键值对,哈希表的最大好处就是让我们可以用 O(1) 的时间复杂度来快速查找到键值对。哈希表实际就是一个数组,哈希表可以类比 Java 中的 HashMap来理解,数组的每个元素叫做哈希桶。至于哈希桶,它存放的是指向键值对数据的指针(dictEntry*),这样通过指针就能找到键值对数据,然后因为键值对的值可以保存字符串对象和集合数据类型的对象,所以键值对的数据结构中并不是直接保存值本身,而是保存了 "void * key "和 "void * value "指针,分别指向了实际的键对象和值对象,这样一来,即使值是集合数据,也可以通过 void * value 指针找到。void * key 和 void * value 指针指向的就是 Redis 对象,Redis 中的每个对象都由 redisObject 结构表示。更多参看数据结构回顾,如下图所示:

  其中,ht_table为长度为 2 的 数组,正常情况使用 ht_table[0] 存储数据,当执行 rehash 的时候,使用 ht_table[1] 配合完成 。如下图所示的ht[2]:

  redisDb 结构:即 Redis 数据库的结构,结构体里存放了指向了 dict 结构的指针;dict 结构:结构体里存放了 2 个哈希表,正常情况下都是用「哈希表1」(ht1),「哈希表2」只有在 rehash 的时候才用;dictht 结构:哈希表的结构,结构里存放了哈希表数组,数组中的每个(条)元素都是指向一个哈希表节点结构(dictEntry)的指针;dictEntry 结构:哈希表节点的结构,结构里存放了 **void * key 和 void * value 指针, key 指向的是 String 对象,而 value 则可以指向 String 对象,也可以指向集合类型的对象,比如 List 对象、Hash 对象、Set 对象和 Zset 对象。

  key 的哈希值最终会映射到 ht_table 的一个位置,如果发生哈希冲突,则拉出一个哈希链表。ht_table 数组每个位置就是哈希桶,保存了Redis 对象的所有键值对。哈希桶的每个元素的结构由 dictEntry (字典元素)定义,包括 指向 key 的指针、 指向实际 value 的指针和哈希冲突拉出的链表;这里的key 都是 string 类型,value 是个 union(联合体),当它的值是 uint64_t、int64_t 或 double 类型时,就不再需要额外的存储,这有利于减少内存碎片。当然,val 也可以是 void 指针,指向值的指针,以便能存储任何类型的数据。next 指向另一个 dictEntry 结构, 多个 dictEntry 可以通过 next 指针串连成链表;当多个不同的键拥有相同的哈希值时,哈希表用一个链表将这些键连接起来,处理 哈希冲突。而哈希桶并没有保存值本身,而是存储了指向具体值的指针,从而实现了哈希桶能存不同数据类型的需求。哈希桶中,键值对的值都是由一个叫做 redisObject 的对象定义,Redis 中每个对象都是用 redisObject 表示。其中的encoding属性(编码方式):表示 ptr 指向的数据类型的具体数据结构,即这个对象使用了什么数据结构作为底层实现保存数据。同一个对象使用不同编码实现内存占用存在明显差异,内部编码对内存优化非常重要。

  当需要查询一个key时,首先利用预设的哈希计算初key的数组位置,然后找到数组的位置,再去链表中遍历找到相关的节点进行返回。

  当我们执行 set key value 的命令,*key指针指向 SDS 字符串保存 key,而 value 的值保存在 *ptr 指针指向的数据结构,消耗的内存:key + value。我们设置key的时候,应尽量考虑降低 Redis 内存使用,最简单的方式就是缩减键(key)与值(value)的长度。另外,key也推荐采用命名空间的方式来命名,key 的命名推荐使用业务模块名:表名:数据唯一id这种格式,方便快速定位key;再比如我们执行:HSET person name “xiaolincoding” age 18后,就创建了一个哈希表键,而键的值是一个包含两个键值对的哈希表对象;执行:RPUSH stu “xiaolin” “xiaomei”,创建一个个列表键,键的值是一个包含两个元素的列表对象;

  Redis集群方案目前主流的有三种,分别是Twemproxy、Codis和Redis Cluster。

  其中前两者属于“代理模式”,分别由推特和豌豆荚开发后开源,而Codis还解决了Twemproxy扩缩容的问题,且兼容Twemproxy,运行稳定;Redis Cluster是由官方出品的,用去中心化的方式实现,不属于代理模式。 3.1 Codis原理

  如上图所示:当只有一个master,多个slave时,要保证master高可用,避免单点,就需要将salve提升为master,实现主从切换,而图中右侧的“Sentinel”,中文名又称哨兵,在Redis里其主要负责监控主从节点,如果主节点挂了,就会把从提升为主节点。而Redis Sentinel做集群就可避免本身的单点故障,造成主从切换失败。

  Sentinel哨兵的运行机制示意图图下,了解哨兵时怎样故障切换的:

  图中是三个哨兵和一主两从的节点,哨兵之间会互相监测运行状态,并且会交换一下节点监测的状态,同时哨兵也会监测主从节点的状态。

  当哨兵检测到某一个节点没有正常回复,并且距离上次正常回复的时间超过了某个阈值,那么就认为该节点为主观下线。这时,其他哨兵也会来监测该节点是不是真的主观下线,如果有足够多数量的哨兵都认为它确实主观下线了,那么它就会被标记为客观下线,这个时候哨兵会找下线节点的从节点,然后与其他哨兵协商出一个从节点做主节点,并将剩余的从节点指向新的主节点。如下如所示:

  关于主从节点的切换有两个环节,第一个是哨兵要选举出领头人来负责下线机器的故障转移,第二是从Slave中选出主节点,领头人的选举规则是谁发现客观下线谁就可以马上要求其他哨兵认自己做老大,其他哨兵会无条件接受第一个发过来的人,并告知老大,如果超过一半人都同意了,那他老大的位置就坐实了。

  关于从节点选举,一共有四个因素影响选举的结果,分别是断开连接时长、优先级排序、复制数量、进程id,如果连接断开的比较久,超过了某个阈值,就直接失去了选举权,如果拥有选举权,那就看谁的优先级高,这个在配置文件里可以设置,数值越小优先级越高,如果优先级相同,就看谁从master中复制的数据最多,选最多的那个,如果复制数量也相同,就选择进程id最小的那个。

  【海量数据下的codis】:存储海量数据的需求,同步会非常缓慢,所以我们应该把一个主从结构变成多个,把存储的key分摊到各个主从结构中来分担压力。代理通过一种算法把要操作的key经过计算后分配到各个组中,这个过程叫做分片。

  在Codis里面,它把所有的key分为1024个槽,每一个槽位都对应了一个分组,具体槽位的分配,可以进行自定义,现在如果有一个key进来,首先要根据CRC32算法,针对key算出32位的哈希值,然后除以1024取余,然后就能算出这个KEY属于哪个槽,然后根据槽与分组的映射关系,就能去对应的分组当中处理数据了。CRC全称是循环冗余校验,主要在数据存储和通信领域保证数据正确性的校验手段。

  注: 槽位的映射关系是保存在proxy里面;不同proxy需要同步映射关系,从而保持数据一致性。

  codis有一个进程叫codis-ha,codis-ha实时监测proxy的运行状态,如果有异常就会干掉,它包含了哨兵的功能,从而替换了上述的sentinel;codis-ha利用了k8s的pod的特性,保证启动的proxy和设置的数量一样,该进程监测Proxy的异常,并且干掉异常的proxy,然后自动拉起来一个新的proxy替代,永远保证足够数量的proxy。

  但是codis-ha在Codis整个架构中是没有办法直接操作代理和服务,因为所有的代理和服务的操作都要经过dashboard处理。所以部署的时候会利用k8s的亲和性将codis-ha与dashboard部署在同一个节点上。

  另外,codis自己开发了集群管理界面,集群管理可以通过界面化的方式更方便的管理集群,这个模块叫codis-fe。 3.2 Redis Cluster原理

  Redis集群与codis不同,Codis它是通过代理分片的,但是Redis Cluster是去中心化的没有代理,所以只能通过客户端分片,它分片的槽数跟Codis不太一样,Codis是1024个,而Redis cluster有16384个,槽跟节点的映射关系保存在每个节点上,每个节点每秒钟会ping十次其他几个最久没通信的节点,其他节点也是一样的原理互相PING ,PING的时候一个是判断其他节点有没有问题,另一个是顺便交换一下当前集群的节点信息、包括槽与节点映射的关系等。客户端操作key的时候先通过分片算法算出所属的槽,然后随机找一个服务端请求。

  从上图可看到的信息:

  1、 对象保存到Redis之前先经过CRC16哈希到一个指定的Node上,例如Object4最终Hash到了Node1上。

  2、 每个Node被平均分配了一个Slot段,对应着0-16384,Slot不能重复也不能缺失,否则会导致对象重复存储或无法存储。

  3、 Node之间也互相监听,一旦有Node退出或者加入,会按照Slot为单位做数据的迁移。例如Node1如果掉线了,0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配,所以迁移过程中不会影响到5641-16384Slot段的使用。

  简单总结下哈希Slot的优缺点: 缺点:每个Node承担着互相监听、高并发数据写入、高并发数据读出,工作任务繁重优点:将Redis的写操作分摊到了多个节点上,提高写的并发能力,扩容简单。总结:Redis主从和哈希的设计优缺点正好是相互弥补的。

  想扩展并发读就添加Slaver,想扩展并发写就添加Master,想扩容也就是添加Master。

  但是可能这个槽并不归随机找的这个节点管,节点如果发现不归自己管,就会返回一个MOVED ERROR通知,引导客户端去正确的节点访问,这个时候客户端就会去正确的节点操作数据。

  1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

  2))节点的fail是通过集群中超过半数的节点检测失效时才生效.

  3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可;

  4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value;

  5) redis-cluster选举:集群中所有master参与选举,如果半数以上master节点与master节点通信超时(cluster-node-timeout),即超过半数以上的master发现其他master挂掉后,认为当前master节点挂掉;。会将其他对应的Slave节点升级成Master,超过半数mster挂掉,那redis cluster就挂掉了。

  6)整个集群不可用(cluster_state:fail):

  6.1> 如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成进群的slot映射[0-16383]不完成时进入fail状态;

  6.2> 如果进群超过半数以上master挂掉,无论是否有slave集群进入fail状态。

  3.3 Redis 集群架构演变

  1)2.8版本以前 ,Redis官方并没有高可用框架, 主从模式的弊端非常明显,从节点仅能作为数据备份,无法做到高可用,当主节点宕机以后,需要手动切换或者依赖第三方的框架,比如codis 等;

  2)2.8版中官方给出了 Sentinel模式,解决了主节点宕机故障切换问题,哨兵sentinel可监控master节点的状态,如果master节点异常,则会做主从切换,将某一台slave自动提升为master并接管集群的功能,但哨兵模式下,是中心化的,主节点的压力大时,节点无法扩容。哨兵模式基于主从模式(实际为主备),实现读写分离,解决了主从模式的自动切换问题,系统可用性也更高。

  主从:两个角色:主服务器,和从服务器两种,客户端均可以访问,一个读写,一个只读。

  主备:只有主服务器可以访问,其他备用的服务器只是在主服务器挂掉的情况下顶替使用;当使用主备模式,主服务器其实就是一个单点,还是会有单点的故障问题,只不过是挂掉的时候会及时切换备用服务器。

  另外该模式还存在以下问题: 在主从切换的瞬间会导致业务瞬断的情况,哨兵模式只有一个主节点对外提供服务,没法支持很高的并发单个主节点内存不宜设置得过大,否则会导致持久化文件过大,影响数据恢复或主从同步的效率每个节点存储的数据是一样的,每个节点的数据都是全量复制,哨兵模式下的存储受限于内存最小的节点,这样就会导致浪费内存,且不好在线扩容

  Redis 3.0 版官方提供了Cluster模式,支持数据分片存储(即每台Redis节点上存储不同的内容,很容易在线扩容),去中心化,多个master,所有节点都可提供读写,这样节点就可方便扩容,单个节点写的压力就小了很多,官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。该集群模式性能和高可用性均优于之前版本的哨兵模式,且集群配置非常简单。集群节点之间使用 Gossip 协议(流言协议,它是一个最终一致性协议)通信,交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。常用的Gossip消息分为4种,分别是:ping、pong、meet、fail。Redis Cluster 采用虚拟哈希槽分区,所有的键根据哈希函数映射到 0 ~ 16383 整数槽内,每一个节点负责维护一部分槽以及槽所映射的键值数据。

  更多参看Redis Cluster;

  软件下载地址:http://redis.io/download, 4.1 普通安装:

  解压编译:

  附录:Redis的tutorial教程练习界面:http://try.redis.io/,可以带初学者熟悉相关命令;

  4.2 集群安装

  分别编辑三个节点下的配置文件:

  daemonize yes //redis后台运行

  pidfile /var/run/redis_7000.pid //pidfile文件对应7000,7002,7003

  port 7000 //端口7000,7002,7003

  cluster-enabled yes //开启集群 把注释#去掉

  cluster-config-file nodes_7000.conf //集群的配置 配置文件首次启动自动生成 7000,7001,7002

  cluster-node-timeout 5000 //请求超时 设置5秒够了

  appendonly yes //aof日志开启 有需要就开启,它会每次写操作都记录一条日志

  启动服务器上的三个节点实例:(一个进程就是一个实例,可以看做一个虚拟主机)

  注:redis-server会以非daemon的方式来运行,且默认服务端口为6379,会占用当前的窗口,一旦ctrl+c,redis也会结束,因此当需要已daemon方式启动时,需配置文件中开机,命令行用nohup redis命令 & 这种形式启动redis;

  服务启动验证:

  ps -ef | grep redis #查看是否启动成功;

  netstat -tnlp | grep redis #可以看到redis监听端口` 把上述创建好的节点都串连起来搭建集群:

  默认目录:redis-trib.rb(/usr/local/redis-你的版本/src/redis-trib.rb),这是redis官方提供的一个工具,它是用ruby写的一个程序,故还需要安装ruby,构建环境:

  yum -y install ruby ruby-devel rubygems rpm-build

  #再用 gem 这个命令来安装 redis接口 gem是ruby的一个工具包.

  gem install redis

  /usr/local/redis-3.2.1/src/redis-trib.rb create --replicas 1 192.168.1.237:7000 192.168.1.237:7001 192.168.1.237:7003 192.168.1.238:7003 192.168.1.238:7004 192.168.1.238:7005

  执行完命令即可完成redis集群搭建。

  说明:

  –replicas 1 表示 自动为每一个master节点分配一个slave节点 上面有6个节点,程序会按照一定规则生成 3个master(主)3个slave(从);

  另外注意: 防火墙一定要开放监听的端口,否则会创建失败。

  运行中,提示Can I set the above configuration? (type ‘yes’ to accept): yes //输入yes

  接下来 提示 Waiting for the cluster to join… 安装的时候在这里就一直等等等,没反应,傻傻等半天,看这句提示上面一句,Sending Cluster Meet Message to join the Cluster.

  这是因上述redis配置只在其中一台Server上完成,里还需要到Server2和3上做同样的操作。

  在192.168.1.238, redis-cli -c -p 700* 分别进入redis各节点的客户端命令窗口, 依次输入 cluster meet 192.168.1.238 7000……

  回到Server1,已经创建完毕了。

  查看一下 /usr/local/redis/src/redis-trib.rb check 192.168.1.237:7000

  到这里集群已经初步搭建好了。

  在Redis中,数据库是由一个整数索引标识,而不是由一个数据库名称。默认情况下,一个客户端连接到数据库0。redis配置文件中下面的参数来控制数据库总数:

  上图中,databases 16 表示数据库从0可以连接到15,共16个redist数据库。更多配置选项说明如下:

  1)Redis客户端工具:redis-cli

  启动 redis 客户端,打开终端并输入命令 redis-cli。该命令会连接本地的 redis 服务,

  2)远程/以其他端口执行上述命令:

  语法:redis-cli -h host -p port -a password

  参考实例:

  3)验证密码是否正确:

  4)其他连接:

  5)其他操作:

  未完待续…… 6)key管理

  7)集群管理

  参考文献:https://c.lanmit.com/shujuku/NoSQL/7764.html,下载最新稳定版目前为:Stable (5.0);https://redis.io/commands 8.1 Redis缓存穿透,击穿和雪崩

  1)Redis缓存雪崩:是指redis在某个时间大量key失效,比如,大量的热点数据过期时间相同,导致数据在同一时刻集体失效。这是就会去后台的数据库去请求数据,造成数据库访问压力突然急剧增大,压力骤增,引起雪崩,redis雪崩危害巨大,甚至有可能造成服务器宕机,给公司造成巨大的经济损失。

  解决方案:

  1.将热点数据的过期时间打散。给热点数据设置过期时间时加个随机值;即设置超时时间的时候要设置随机值,不要设置固定值;

  2.加互斥锁。当热点key过期后,大量的请求涌入时,只有第一个请求能获取锁并阻塞,此时该请求查询数据库,并将查询结果写入redis后释放锁。后续的请求直接走缓存。

  3.设置缓存不过期或者后台有线程一直给热点数据续期。

  2)缓存穿透:是指访问一个Redis缓存和数据库中都不存在的数据,请求从持久层查不到数据则就无法写入缓存,而用户不断发起请求,由于缓存是不命中时被动写的,导致这个不存在的数据每次请求都要到存储层去查询,失去了Redis缓存的意义。此时,缓存起不到保护后端持久层的意义,就像被穿透了一样。导致数据库存在被打挂的风险。

  在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。

  如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大直至崩溃。

  解决方案:

  1、设置并发锁,防止大量请求压力到达数据库,如果获取到锁了,去数据库查询,如果没有,说明有其他线程在查询数据库,那么只需要重试一下就好了

  2、增加对接口请求参数的校验。对请求的接口进行鉴权,数据合法性的校验等;比如查询的userId不能是负值或者包含非法字符等。

  3、当数据库返回空值时,将空值缓存到redis,并设置合理的过期时间。

  4、配置布隆过滤器。使用布隆过滤器存储所有可能访问的 key,不存在的 key 直接被过滤,存在的 key 则再进一步查询缓存和数据库。

  布隆过滤器是防止缓存穿透的方案之一。布隆过滤器主要是解决大规模数据下不需要精确过滤的业务场景,如检查垃圾邮件地址,爬虫URL地址去重, 解决缓存穿透问题等。布隆过滤器用于在一个存在一定数量的集合中过滤一个对应的元素,判断该元素是否一定不在集合中或者可能在集合中。它的优点是空间效率和查询时间都比一般的算法要好的多,缺点是有一定的误识别率和删除困难。布隆过滤器是基于bitmap和若干个hash算法实现的。如下图所示:

  1.元素tie经过hash1,hash2,hash3运算出对应的三个值落到了数组下标为4,6,8的位置上,并将其位置的默认值0,修改成1。

  2.元素niu同理落到了数组下标为1,3,4的位置上,并将其位置的默认值0,修改成1。此时bitmap中已经存储了tie,niu数据元素。当请求想通过布隆过滤器判断tie元素在程序中是否存在时,通过hash运算结果到数组对应下标位置上发现值已经都被置为1,此时返回true。

  什么不使用HashMap呢?如果用HashSet或Hashmap存储的话,每一个用户ID都要存成int,占4个字节即32bit。而一个用户在bitmap中只需要1个bit,内存节省了32倍。

  并且大数据量会产生大量的hash冲突,结果就是产生hash冲突的数据,仍然会进行遍历挨个比对(即使转成红黑树),这样对内存空间和查询效率的提升,仍然是有限的。如果数据量不大时,尽管使用。而且hashmap方便进行CRUD。更多参看布隆过滤器。

  3)缓存击穿:是指请求缓存中没有但数据库中有的数据(一般是某个热点 key缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,就同时去数据库去取数据,引起数据库压力瞬间增大,造成瞬时数据库请求量大、压力骤增,导致数据库被打挂。

  解决方案:

  1、设置热点数据永不过期,或者后台有线程一直给热点数据续期。

  2、加互斥锁:当热点key过期后,大量的请求涌入时,只有第一个请求能获取锁并阻塞,此时该请求查询数据库,并将查询结果写入redis后释放锁。后续的请求直接走缓存。 8.2 相关知识关联

  Java 常见的序列化工具空间压缩比:

  8.3 Redis CAP理论

  CAP 即三个单词首字母的缩写:Consistency、Availability、Partition tolerance;CAP的3个特性,只能满足其中2个,这涉及到取舍的问题,采用一定策略来满足。我们一般认为redis为CP型的。

  Consistency(一致性):强调的是数据正确且最新Availability(可用性):强调的是系统返回不出错(高可用),但是返回的结果不一定是最新的Partition tolerance(分区容忍性):指分布式系统中的节点被划分为多个区域,每个区域内部可以通信,但是区域之间无法通信,在分布式系统中,分区容忍性必不可少,因为需要总是假设网络是不可靠的

  Redistribution不同模式下的CAP选择: 单机模式:单机部署redis,保证了数据的一致性而牺牲了可用性,只是保证了用户可以看到相同的数据和当网络通信出问题是能够保证隔离的子系统能够继续运行,单机模式下master与slave之间不存在通信问题,但当master节点挂掉以后子节点便不能保证能够正常的提供服务;这种默斯和只实现了数据的一致性Consistency(一致性);哨兵模式sentinel:实现了故障自动转移,保障了高可用性,但该模式的确定也很大,它实现了数据的一致性和高可用性 Consistency(一致性)、Availability(可用性)集群模式:该模式下采用数据分片的方式存储,即采用虚拟槽分区,所有的键值根据哈希算法映射到数据槽内,每个节点负责维护一部分的槽及槽锁映射的键值数据,这使得redis由一个单纯的nosql内存数据库变为一个分布式的nosql数据库使redis具有了分区容忍性,并且实现了负载均衡,当某个节点挂了以后数据在其他节点上具有备份并且这个节点马上就可以投入使用,实现了高可用性,但也同时因为这一点redis失去了数据的强一致性;cluster模式实现了分区容忍性和高可用性 Availability(可用性)、Partition Tolerance(分区容错性)

  CAP取舍策略:

  参考文献:redis内存优化;Redis 的 9 种数据结构图解;  拥有一套合适的工具来创建专业的动态图形和视觉特效始终很重要。尽管 After Effects 提供了广泛的功能,但第三方插件和脚本将其提升到了一个全新的水平。

  After Effects一般来说素材文件巨大、占用电脑内存高、所需插件特别多,如何节省硬件成本的同时,提升After Effects的运行速率和渲染速度:

  渲云-云渲染支持After Effects,可批量渲染,批量出结果,速度更快,效率更高。支持批量处理任务:极致渲染性能,实时预览等多种智能服务智能渲染:弹性扩容,批量拖拽提交,实时预警等多种智能服务极速传输:超带宽传输引擎,超大文件秒速远距上传数据安全:通过ISO27017/IOS027018认证,美国电影协会MPA云端存储:最大5T容量,渲染结果云盘备份,云端协作多人办公软件插件全类型支持:与市场无缝衔接,实时补充用户所需实时更新插件:同步更新常用插件,自动匹配版本

  此外本地普通电脑连接到赞奇云工作站,秒变超算机,根据需求选择合适的配置,不仅仅能提升渲染速度,还能提升AE的运行速率。通过赞奇云工作站打造云制作平台,实现权限管理、流程管理、 项目进程管理、任务信息同步通过云工作站、软件中心、云盘、渲云云渲染 打通 素材上传 -> 云 上制作坐席置备 -> 设计 -> 渲染 -> 特效合成,呈现全流程环节

  Neat Video Pro是Adob​​e After Effects 强大的降噪插件。它结合使用复杂的数学算法和基于小波的技术来减少视频噪声,同时保留真实的细节和颜色。

  Video Copilot Element 3D 是 Video Copilot 开发的一款功能强大的 3D 动画和合成工具。它允许视觉效果艺术家 在 After Effects 中导入 3D 模型并制作动画,并轻松创建令人惊叹的 VFX。

  True Comp Duplicator 创建合成层次结构的副本,包括子合成。它确保多次使用的合成仅复制一次,后续引用指向初始副本。此外,该工具还根据用户首选项在“项目”面板中保留或复制重复合成的文件夹层次结构。

  Rift是一个After Effects 插件,提供各种用于移动、排序、交错或随机化图层属性(例如入点和出点、关键帧、标记等)的方法。所有这些功能都呈现在一个紧凑的用户界面中。

  Zorro允许您通过向图层添加标签来对 After Effects 中的图层进行分组。就像在 Flickr 上标记照片的方式一样,您可以标记合成中的图层,然后根据指定的标记轻松选择或隔离组中的这些图层。

  当您将蒙版从一层复制到另一层时,它通常会发生位置变化。但是,使用CopyMask2Layer,您可以无缝复制蒙版,同时保留其精确位置,无论图层移动或关键帧蒙版路径如何。

  数小时的动画浪费在重复性任务、重新调整关键帧时间以及在窗口之间切换。Mt. Mograph Motion 提供了 50 多种工具,可以自动执行这些重复性任务并提升您的动画效果。创建动态运动从未如此简单。

  GifGun是一个 After Effects 脚本,允许在 After Effects 中超级简单地创建动画 GIF。使用 GifGun,您可以轻松自定义设置、优化文件大小并直接从您的作品生成 GIF。

  Auto Crop 3是一个 After Effects 脚本,可让您快速裁剪合成以匹配其内容的大小。您可以在当前帧裁剪合成,也可以分析整个合成的内容并进行裁剪,而不切断任何动画。

  FX Console是一个 After Effects 插件,它添加了一个可停靠面板,使您可以快速找到并应用效果和预设。该工具具有高度可定制性,提供诸如为效果分配自定义名称、调整优先级、添加收藏夹、修改默认 FX 设置等功能。价格:免费

  BG Renderer MAX for After Effects允许您在后台渲染合成,同时保留完全的控制。这一强大的工具将多处理、大量集成、通知和文件类型转换结合在一个综合解决方案中。

  无需编写或读取一行代码即可释放After Effects 表达式的潜力。访问超过125 个预构建表达式,全部可供使用且可自定义,每个表达式都具有用户友好且直观的界面。

  PQ Grit Kit 2是一款 After Effects 插件,提供了一个巨大的超级可用的日常移动纹理库,例如纸张或卡片、墨水或油漆、混凝土、木材、涂鸦和沙子,以便在 After Effects 中混合。

  Motion Boutique Newton 3是一个 After Effects 插件,它将真实物理引入 After Effects 中,使您的 2D 合成图层能够充当彼此交互的实体对象,模仿现实世界的动态。

  Video Copilot Optical Flares 是一款流行的 After Effects 插件,旨在帮助视觉效果艺术家 向他们的项目添加逼真的镜头光晕 和其他光学效果。该插件提供了广泛的可定制预设,允许用户创建各种镜头光晕效果,包括自然光斑、科幻光斑等。价格: 118.70 美元

  Yanobox 的 Nodes 是一个插件,可让您 直接在 After Effects 内创建连接的运动图形和抽象粒子宇宙 。它配备了预设浏览器,只需单击一下即可快速搜索并加载 After Effects 中的 300 个动画预设和模板之一。

  Sapphire After Effects 插件可让您通过 270 多种效果和 3000 多个预设、强大的效果和过渡生成器以及与奥斯卡获奖 Mocha 集成的跟踪和遮罩来 创建令人惊叹的有机外观

  Flow是一个 After Effects 插件,它在 After Effects 中提供了一个轻松的界面,用于自定义动画曲线,无需导航过时且令人困惑的图形编辑器。

  Digital Anarchy 的 Flicker Free 是一款功能强大且简单的 After Effects 插件,可消除视频中的闪烁。该插件提供了许多预设,您可以为不同类型的视频选择。这使得消除由 LED 灯、慢动作镜头、无人机镜头、不同步摄像机等引起的闪烁变得非常容易。

  ScaleUp 是一个 After Effects 插件,能够将视频放大 10 倍。然而,它也可以用来降低噪音。它采用人工智能技术,利用神经网络研究和分析视频像素,以提高质量并减少噪音。

  Hawaiki Keyer 是一款 After Effects 插件,具有两个独立的键控模块,一个用于删除绿屏,另一个用于删除蓝屏。它使用创新的遮罩提取算法来轻松去除绿/蓝屏。价格: 141.55 美元

  Mt. Mograph Wander是一款为 After Effects 用户提供的强大媒体搜索插件。它是一个可以帮助您轻松查找和收集媒体的搜索引擎。凭借其用户友好的界面,您可以快速浏览大量图像、Gif、表情符号、SVG 和图标包库。它提供来自互联网的快速结果。

  Blace是一款适用于 Adob​​e After Effects 的基于人工智能的自动人脸检测和模糊插件。只需选择您想要模糊的面孔,插件就会处理剩下的事情。您可以模糊整个脸部或仅模糊眼睛,或者完全排除您不想模糊的脸部。

  Yanobox Motype是After Effects 的版式插件,用于创建动画文本和其他动态图形效果。它有超过 250 个预设,您可以混合搭配来创建无限的动作标题变化。

  借助REZup,您可以直接在 Adob​​e After Effects 中放大并提高视频质量。该产品包含两个插件 - REZup Enhance 和 REZup Resize。两者都提供了由机器学习支持的行业标准视频处理的独特组合。价格: 161.45 美元

  如果您正在寻找After Effects 的媒体导入器插件,那么Autokroma Influx可能是一个不错的选择。该插件可让您在 After Effects 中导入大量新扩展、格式和编解码器。例如,您无法直接在 After Effects 中导入 MKV 文件,但使用 Autokroma,您只需单击一个按钮即可完成此操作。

  Mt. Mograph Boombox是After Effects 的声音设计和音频库插件。声音库拥有超过 9500 种自定义声音,您可以使用它们并与视频同步。它具有一个搜索栏,您可以在其中输入自定义标签来查找适合您的项目的完美音频。

  ISP Robuskey采用先进的色度键控算法, 是一款功能强大的After Effects 插件,用于消除绿屏。它使剪切背景变得非常容易,以创建更具视觉吸引力的复合材料。

  Version Raptor是一款免费的 After Effects 插件,可让您轻松版本化项目或伴奏/序列。该插件将检测最后一组数字,并在您创建版本号时通过复制安全地增加它。这样,您随时可以返回到以前的版本。价格:免费

  SF Subtitles 是一个 功能强大且易于使用的脚本,可让您在 Adob​​e After Effects 中 快速、简单地创建和添加字幕。借助 SF Subtitles,您可以轻松创建字幕并设计其样式,使用关键帧为其设置动画,甚至可以控制它们在合成中的时间和位置。

  虽然 在 After Effects 中抠出绿色或蓝色屏幕非常容易 ,但抠出其他颜色要困难得多。这就是 Composite Brush After Effects 插件可以发挥作用的地方。使用此插件,您可以轻松选择素材中的任何颜色并立即将其删除,从而拉出成功的关键。

  AE Face Tools 是After Effects 的面部跟踪和替换插件,可让您添加面部特征、滤镜和道具。它包括数百个即用型预设,只需单击一下即可应用。它是最好和最广泛使用的 面部跟踪和替换 After Effects 插件之一。

  Red Giant Trapcode Suite是运动图形的行业标准软件包,可将 3D 粒子系统的强大功能直接引入 After Effects 中。该套件中有 11 个插件 - Pspecial、Form、Mir、3D Stroke、Shine、Starglow、Sound Keys、Tao、Lux、Echosapce 和 Horizo​​n。

  Overlord是 After Effects 的一个插件,可以 将 Adob​​e Illustrator 形状 实时传输到 After Effects 并返回。使用 Overlord,Illustrator 和 After Effects 感觉像是配套程序,因为您可以在两者之间传输形状,而无需导入、转换或重绘。

  LoopF​​low是一个 After Effects 插件,允许将静态图像动画化为循环视频,也称为Cinemagraphs或 Plotagraphs。您可以使用它来制作连续流体运动的动画,例如流动的水、滚滚的烟雾、飞行的粒子、火焰、头发、毛皮、织物或图案。

  GEOlayers是一个 After Effects 脚本,可让您从 After Effects 中的各种在线数据源设计地图并制作地图动画。您可以轻松地将建筑物绘制到 After Effects 形状图层,突出显示国家边界、街道、湖泊、河流、地点和地区、制作驾驶路线动画以及挤出建筑物。

  Lockdown是一个用于跟踪 After Effects 中变形表面的插件。它非常适合美容修饰和其他以前困难的具有挑战性的清理任务。当涉及到运动跟踪扭曲和不规则表面时,Lockdown 确实是一个改变游戏规则的插件。

  Depth Scanner是一款基于 AI 的插件,可以自动估计深度。它从静态图像和视频生成深度图。生成的深度图可用于各种后处理任务,例如添加雾、将素材转换为立体 3D 以及许多其他图像效果。

  Long Shadows是一个免费的 After Effects 脚本,可帮助您创建逼真且自然的阴影。它非常易于使用,让您可以完全控制许多设置来彻底改变阴影的外观。价格:免费

  这个用于删除绿屏的 After Effects 插件 由人工智能 和一组在任何其他插件中找不到的独特功能提供支持。它使用人工智能来分析场景,即使在没有绿屏或蓝屏的情况下,也可以根据显着的前景物体创建遮罩。

  Subtitle Pro 是一个插件,可让您在 Adob​​e After Effects 和 Premiere Pro 中为视频创建字幕和字幕。该插件提供 自动字幕生成功能,可以轻松导入 SRT 文件或编写自己的文本。

  一键标题和标注工具是一个 After Effects 脚本,执行后允许您自动创建下三分之一。脚本中有许多不同的动画预设可用,您可以立即将其应用到下三分之一。

  Bendio是一个 After Effects 插件,允许您弯曲图层并轻松地将其他图层作为弯曲的父对象。它是一种快速而简单的工具,可用于任何类型的图层,包括栅格和矢量。

  Universe是专业视频编辑器、动态图形艺术家和 VFX 专家的重要资源,提供全面的GPU加速效果和过渡插件集合。

  Beauty Box 是 After Effects 的视频修饰插件 ,可让您实时平滑皮肤并消除视频中的其他伪影。它自动识别肤色并创建蒙版以限制皮肤区域的皮肤平滑效果。

  此 After Effects 脚本是创建完美白板动画的简单解决方案。自动白板提供 60 多种绘图选项,包括记号笔、铅笔、钢笔、橡皮擦等,可以单独或组合使用。

  文件夹设置脚本是一个免费的 Adob​​e After Effects 脚本,用于在项目面板内自动创建文件夹层次结构。该脚本对于组织 After Effects 项目非常有用。价格:免费

  Matte Lock是一个免费下载的 After Effects 脚本,只需单击一个按钮即可自动突出显示文本。只需 3 个简单步骤即可运行此脚本并突出显示您选择的任何文本。价格:免费

  Layer Manager构建于 Adob​​e 的通用可扩展性平台之上,是 Adob​​e After Effects 最重要但又缺失的工具。该脚本提供了广泛的工具,可在使用 AE 图层时提高工作效率。价格: 27 美元

  Nebulosity是一款 GPU 加速的体积 After Effects 插件,可让您轻松创建星云、星系、云和烟雾。它使用噪声、图层和斜坡生成体积,可以使用各种技术对体积进行着色。


Nosql之Redis详解的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于Nosql之Redis详解Nosql之Redis详解的信息别忘了在本站进行查找喔。

  • Nosql之Redis详解已关闭评论
  • A+
所属分类:解读回应