Nginx参数配置详细说明【全局、http块、server块、events块】【已亲测】

Nginx重点参数配置说明

本文包含Nginx参数配置说明全局块、http块、server块、events块共计30多个参数配置与解释,其中常见参数包含配置错误出现的错误日志,能让你更快的解决问题。
该文的所有参数大部分经过单独测试,错误都是自己收集出来的,如有疑问可以私聊,文档有误感谢指正,文章对你有帮助请点赞收藏,非常感谢!

一、全局块

1.worker_processes [size] 工作进程数量

用于指定工作进程的数量,通常情况下,建议将worker_processes设置为机器的CPU核心数。 grep -c processor /proc/cpuinfo查看cpu核心数,也可以设置为自动(worker_processes auto),会根据核心数来设置。增加工作进程数可以提高并发处理请求的能力,worker_processes的设置过大会占用过多的系统资源,导致系统负载过高。

当使用量超出配置时可能会出现:1.资源耗尽:nginx的worker_processes配置定义了能同时处理的最大并发连接数。如果实际并发连接数超过了配置的数量,可能会导致服务器的资源(如CPU、内存)耗尽,导致服务器崩溃或变得不稳定。2.连接被拒绝:当并发连接数超过配置的最大数量时,新的连接请求可能会被拒绝。客户端会收到一个连接被拒绝的错误信息。3.响应时间延长

2.worker_rlimit_nofile [size] 最大文件描述符数

用来设置每个worker进程可以打开的最大文件描述符数(文件句柄)的限制。默认值是平台相关的,在大多数Linux系统中,默认值为1024。

在Linux系统中,每个进程都有一个文件描述符表。当进程打开一个文件时,系统会分配一个文件描述符给该文件。该文件描述符可以用来通过文件描述符表进行读写操作,简单的理解为可以建立连接的数量。

由于每一个socket都会打开一个文件描述符,所以服务器可以同时处理连接数量受到系统文件描述符数量的限制。文件描述符的数量是有限的,取决于系统配置(通常是1024个)和系统限制(ulimit设置),使用ulimit -n查看。

如果一个进程需要打开的文件数量超过了其允许的文件描述符数目上限,则会导致文件描述符用尽的问题,一般日志会报错:“…failed(24:Too many open files)”或者日志报错:“worker process 54219 exited with fatal code 2 and cannot be respawned”。浏览器会一致加载卡住。

二、Events块

1.use [method]; IO 模型

我们现在使用的 Linux 都支持包括 select、epoll、kqueue、epoll 这一类的 IO 模型。现在最主流的就是 epoll ,它是完全的事件机制,可以实现多路 IO 复用。当一个 IO 阻塞后,让其它的 IO 继续处理,然后这个 IO 处理完成后触发事件回调回来继续处理。这个选项通常不需要显式指定,因为 Nginx 会默认使用当前系统中最有效的模式。

2.multi_accept\ [on/off]; 连接多路复用

multi_accept是用于控制是否启用“接收新连接”的多路复用。它的默认值是off,即不启用多路复用。默认情况下,Nginx使用异步的方式处理请求,对于每个新的连接请求,Nginx会创建一个新的worker进程来处理。当multi_accept被设置为"on"时,Nginx允许同时接受多个新连接,多个worker进程可以同时接受新连接,提高并发处理能力。而当multi_accept被设置为"off"时,Nginx只会顺序地接受新连接,一个worker进程只能处理一个新连接,降低了并发能力。

设置multi_accept为"on"可以提高Nginx的性能,特别是在高并发的场景下。然而,在低并发或资源有限的情况下,多个worker进程同时接受连接可能导致系统资源的消耗。

3.worker_connections [size]; 每个进程最大连接数

worker_connections用于设置每个worker进程的最大连接数。每个客户端连接到nginx时,都会占用一个worker连接。如果达到了worker_connections的最大值,那么nginx将不再接受新的客户端连接,后续连接就会等待。这个数字包括所有连接(例如与后台服务器的连接等),而不仅仅是与客户端的连接。另一个考虑因素是,同时连接的实际数量不能超过当前打开文件的最大数量限制,也就是说,它不应该超过 worker_rlimit_nofile 设置的数量。

理论上nginx服务器的最大连接数为 worker_processes*worker_connections。作为反向代理的时候为:(worker_connections * worker_processes)/2。当超过worker_connections的设值时,客户端请求页面会卡住加载,等待空闲连接。nginx日志会报错:epoll_create() failed (22:inalid argument)。

三、http块

(一) 请求处理(客户端与nginx服务)

1.请求头处理

1.1 client_header_buffer_size ;请求头缓冲区空间

client_header_buffer_size 用于设置客户端请求的请求行+请求头缓冲区大小。client_header_buffer_size的默认值是1k或者4k,具体取决于操作系统,默认情况下,如果操作系统的页大小是4k,则client_header_buffer_size的默认值为1k,如果操作系统的页大小是8k,则client_header_buffer_size的默认值为4k,一般默认值为1k。当Nginx接收到一个HTTP请求时,它首先会读取请求行和头部,然后将其存储在一个缓冲区中。当请求行+请求头的大小超过了client_header_buffer_size指定的大小时,会首先按照large_client_header_buffers配置的大小,如果还是超出范围,Nginx会返回HTTP 400 Bad Request响应。

1.2 large_client_header_buffers 请求头最大缓冲区空间

large_client_header_buffers用于设置nginx服务器接收和缓存客户端请求头的缓冲区的大小。该指令用于处理大型或包含大量请求头的客户端请求。默认值为4 8k,表示nginx为请求头分配4个大小为8k的缓冲区。这意味着nginx服务器将使用总共32 KB的内存来缓存客户端请求头。请求行(request line)的大小不能超过8k,否则返回414 Request-URI Too Large错误。请求头(request header)中的每一个头部字段的大小也不能超过8k,否则返回400 Bad Request或者400 Request Header Or Cookie Too Large错误,总的(请求行+请求头)的大小不能超过32k(4 * 8k)。

1.3 client_header_timeout [time] 请求头超时时间\

client_header_timeout定义nginx读取客户端请求头部的超时时间。默认值是 60s,如果客户端在这段时间内没有传送完整的头部到 Nginx ,则会断开与客户端的连接,Nginx 将返回错误 408 (Request Time-out) 到客户端。

2. 请求体处理

2.1 client_max_body_size [size]

client_max_body_size 用于限制客户端请求的主体(body)的最大大小,默认值为1m(1024kb)。当客户端向NGINX发送请求时,请求的主体可以包含数据,例如在POST或PUT请求中发送的表单数据或文件。client_max_body_size指令用于设置NGINX接受的最大请求主体大小。如果客户端请求的主体超过了指定的最大大小,NGINX将返回一个错误响应,通常是"413 Request Entity Too Large",并且不会将请求体传递给后端应用程序服务器。该值需要根据后台服务器接受请求体大小来配置,如使用的是JBoss需要根据standalone.xml文件中的参数的实际情况来配置client_max_body_size 的大小。

2.2client_body_buffer_size [size]

client_body_buffer_size 是用于指定客户端请求主体缓冲区大小的配置项。在旧版本的nginx中(在Nginx 1.17.x版本之前),默认值为client_body_buffer_size 8k,而在新版本的nginx中,默认值为client_body_buffer_size 16k。当客户端发送请求主体时,nginx会将数据暂存在缓冲区中,然后再根据配置的方式进行处理。如果请求的数据小于client_body_buffer_size直接将数据先在内存中存储。如果请求的值大于client_body_buffer_size小于client_max_body_size,就会将数据先存储到临时文件中,默认情况下,它是位于当前运行的 Nginx 程序目录下的 client_body_temp,可以由client_body_temp_path 手动设置。

2.3 client_body_timeout [size]

client_body_timeout用于定义读取客户端请求正文的超时时间。默认值60s,当客户端向服务器发送请求,并且请求中包含了请求体(如POST请求),服务器需要等待客户端将请求体完全发送过来。如果客户端在连接建立后这段时间内没有传输完数据,则会断开与客户端的连接,Nginx 将返回408(Request Time-out) 错误到客户端,这个和client_header_timeout一样。

2.4 client_body_temp_path

定义存储客户端请求正文的临时文件的目录,没错,就是超出 client_body_buffer_size 设置大小的数据所保存的临时文件的位置。默认情况下,它是位于当前运行的 Nginx 程序目录下的 client_body_temp。配置方式如:client_body_temp_path /spool/nginx/client_temp 1 2;

2.5 client_body_in_file_only [clean/off/on]

此指令禁用NGINX缓冲区并将请求体存储在临时文件中。文件包含纯文本数据。该指令在NGINX配置的http,server和location区块使用。可选值有:

off:该值将禁用文件写入。

clean:请求body将被写入文件。 该文件将在处理请求后删除。

on: 请求正文将被写入文件。 处理请求后,将不会删除该文件。

默认情况下,指令值为关闭。

2.6 client_body_in_single_buffer [on/off]

该指令设置NGINX将完整的请求主体存储在单个缓冲区中。 默认情况下,指令值为off。 如果启用,它将优化读取$request_body变量时涉及的I/O操作。推荐在使用 $request_body 变量时使用,可以节省引入的拷贝操作。

(二)代理区处理(nginx与后台服务器)

1.响应缓冲区

1.1 proxy_buffering [on/off] 开启响应缓冲区

proxy_buffering该指令开启从后端服务器的响应body缓冲。默认值为on。如果proxy_buffering开启,nginx假定后台服务器会以最快速度响应,并把内容保存在由指令 proxy_buffer_size 和 proxy_buffers 指定的缓冲区里。如果响应body无法放在内存里边,那么部分内容会被写到磁盘上。如果proxy_buffering被关闭了,那么响应body会按照获取body的多少立刻同步传送到客户端。nginx不尝试计算后台服务器整个响应body的大小,nginx能从服务器接受的最大数据,是由指令 proxy_buffer_size指定的。对于基于长轮询(long-polling)的Comet 应用来说,关闭 proxy_buffering 是重要的,不然异步响应将被缓存导致Comet无法工作。但是无论proxy_buffering是否开启,proxy_buffer_size都是生效的。如果这个设置为off,那么proxy_buffers和proxy_busy_buffers_size这两个指令将会失效。

1.2 proxy_buffers [number] [size]代理缓冲区空间

number:表示每个worker进程的代理缓冲区的数量。size:表示每个缓冲区的大小。可以使用字节(B)、千字节(K)、兆字节(M)或者高级(G)作为单位。

proxy_buffers默认值为proxy_buffers 8 4k|8k,是 4K 或 8K,具体取决于服务器。proxy_buffers 8 4k意味着每个worker进程可以使用8个大小为4k的缓冲区。可以使用proxy_buffering参数控制是否启用代理缓冲,默认为关闭。若禁用代理缓冲,则proxy_buffers参数将不起作用。

1.3 proxy_buffer_size [size] 单个代理缓冲区空间

proxy_buffer_size 这个指令指定了单个代理缓冲区的大小。默认值为4k或者8k,具体取决于服务器。当Nginx作为代理服务器时,它会将来自上游服务器的响应存储在缓冲区中,然后再将其传输给客户端。proxy_buffer_size所设置的size的作用是用来存储upstream端response的header(响应头)。如果超出该值则会返回502(Bad Gateway)。并会出现错误nginx提示界面。

1.4 proxy_busy_buffer_size [size] 响应临时缓冲区空间

proxy_busy_buffers_size默认值为proxy_buffer_size*2。Nginx服务器在读取上游服务器响应时的临时缓冲区大小。proxy_busy_buffers_size不是独立的空间,他是proxy_buffers和proxy_buffer_size的一部分。 nginx会在没有完全读完后端响应就开始向客户端传送数据,所以它会划出一部分busy状态的buffer来专门向客户端传送数据(建议为proxy_buffers中单个缓冲区的2倍),然后它继续从后端取数据。proxy_busy_buffer_size参数用来设置处于busy状态的buffer有多大。(1)如果完整数据大小小于proxy_busy_buffer_size大小,当数据传输完成后,马上传给客户端;(2)如果完整数据大小不小于proxy_busy_buffer_size大小,则装满busy_buffer后,马上传给客户端。

以上配置工作原理:

在proxy_buffering 开启的情况下,Nginx将会尽可能的读取所有的upstream端传输的数据到buffer,直到proxy_buffers设置的所有buffer们 被写满或者数据被读取完(EOF)。此时nginx开始向客户端传输数据,会同时传输这一整串buffer们。同时如果response的内容很大的话,Nginx会接收并把他们写入到temp_file里去。大小由proxy_max_temp_file_size控制。如果busy的buffer 传输完了会从temp_file里面接着读数据,直到传输完毕。

一旦proxy_buffers设置的buffer被写入,直到buffer里面的数据被完整的传输完(传输到客户端),这个buffer将会一直处 在busy状态,我们不能对这个buffer进行任何别的操作。所有处在busy状态的buffer size加起来不能超过proxy_busy_buffers_size,所以proxy_busy_buffers_size是用来控制同时传输到客户 端的buffer数量的。

2.代理时间设置

2.1 proxy_connect_timeout [time];代理连接超时时间

代理连接超时时间:指定nginx与后端服务器建立连接的超时时间,默认为60秒。如果在这个时间内无法与后台服务器建立连接(跟服务器处理业务时间无关,如网络不可用),nginx会中断连接尝试。nginx会认为该服务器不可用,会自动切换到可用服务器上去。并且会记录到max_fails的次数中,当次数达到设置的值时,该服务器会被移除负载均衡,后续请求不在转发,移除时间根据 max_timeout决定,如果在max_timeout期间检测到该服务器可用会立马加入负载均衡中。如果在proxy_connect_timeout时间内后端服务恢复了,会立马建立连接。

日志错误记录:connect() failed (110: Connection timed out) while connecting to upstream

2.2 proxy_read_timeout [time];代理响应超时时间

Nginx服务器读取后台服务器响应的超时时间,默认的超时时间是60秒。如果在代理请求期间,Nginx在指定的时间内没有接收到后台服务器的响应,它将终止与后台服务器的连接,并且不会自动切换到其服务上去,并将错误返回给客户端504 Gateway Timeout。会算作一次错误记录到max_fails中,当达到错误次数时,下一次请求就会切换到其他可用后台服务器。

日志记录:upstream timed out (110: Connection timed out) while reading response header from upstream

2.3 proxy_send_timeout [time];代理请求发送时间

用于设置nginx服务器向后端服务器发送请求的超时时间。默认值为60s。当nginx作为代理服务器转发请求给后端服务器时,如果发送请求的时间超过了proxy_send_timeout所设置的时间,nginx将会中断与后端服务器的连接。并添加错误次数,当达到max_fails次数后,下一次请求会切换到另一台服务器。

(三)server块

1.max_fails=[number] 最大失败次数

max_fails:默认值为1,表示在连续请求失败的次数,超过此值后,Nginx会认为该后端服务器不可用。当一个请求失败时,max_fails会被增加1;当一个请求成功时,max_fails会被重置为0。一旦达到max_fails的值,Nginx将不再将请求发送到该服务器,直到fail_timeout时间过去后,将重新尝试请求。

2.max_timeout=[time];失败超时时间

max_timeout:默认值为10秒,表示在失败的连续请求达到max_fails之后,Nginx会暂时将该后端服务器标记为不可用,并等待fail_timeout时间后再重新尝试请求。在这段时间内,Nginx将不会将请求发送到该服务器。如果在fail_timeout时间内,这个服务器恢复正常,Nginx将重新开始将请求发送到该服务器。

(四)缓存模块

可以在一定程度上,减少服务器的处理请求压力。比如对一些图片,css或js做一些缓存,那么在每次刷新浏览器的时候,就不会重新请求了,而是从缓存里面读取。这样就可以减轻服务器的压力。注意:缓存中含有jsp代码时会出现的问题,jsp文件中的动态数据不正确问题,例如使用java代码赋值。因为nginx缓存jsp文件后,查看已缓存的文件可以发现,nginx缓存的jsp文件中的动态数据是写死的,后续的访问直接返回jsp,没有动态更新。

1.proxy_cache_path 缓存的路径和其他参数

例如:

http{

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

}

path:强制参数,指定缓存文件的存放路径。

levels:定义了缓存目录的层级。每层可以用1(最多16种选择,0-f)或2(最多256种选择,00-ff)表示,中间用 : 分隔。

proxy_cache_path /data/nginx/cache; 代表所有缓存只有一个目录,比如/data/nginx/cache/d7b6e5978e3f042f52e875005925e51b

proxy_cache_path /data/nginx/cache levels=1:2; 代表缓存是二层目录(有16*256=4096个目录),比如/data/nginx/cache/b/51/d7b6e5978e3f042f52e875005925e51

keys_zone:强制参数,定义共享内存区的名称和大小,该共享内存用于保存缓存项目的元数据(所有活动的key和缓存数据相关的信息),这样nginx可以快速判断一个request是否命中或者未命中缓存,1m可以存储8000个key,10m可以存储80000个key。

inactive:删除指定时间内未被访问的缓存文件,默认10分钟。

max_size:设置了缓存存储的上限,如果不指定,最大会用掉所有磁盘空间,一般10g起。

use_temp_path:直接把临时文件放在缓存目录中,一般不建议开启。

在这里插入图片描述

2.proxy_cache [zone] 缓存区域

proxy_cache指令用于配置HTTP代理缓存。它用于控制NGINX是否应该缓存来自上游服务器的响应,并在后续请求中提供缓存的响应,而无需再次访问上游服务>器。zone 是自定义的缓存名称,zone名称由proxy_cache_path指令定义,用于标识特定的缓存区域。off为不使用。

3.proxy_cache_valid response_code1 [response_code2 …] time;有效期

用于指定代理缓存中缓存的不同HTTP响应的有效期。response_code1, response_code2, … 是HTTP响应码,可以指定多个,比如:proxy_cache_valid 200 302 5m。对于状态码200和302的响应,缓存将保留5分钟。可以配置多个proxy_cache_valid,建议这个指令跟随在proxy_cache指令之后。

4.proxy_cache_key [string] 缓存键值

proxy_cache_key指令用于定义代理缓存的键值。键值决定了缓存内容的唯一性,并且可以根据特定的请求属性进行定制。string可以是一个包含变量和静态文本的字符串,用于构建缓存键值。例如配置为:proxy_cache_key scheme r e q u e s t m e t h o d request_method requestmethodhost$request_uri; http协议 + 请求方式 + 主机名 + uri 把这四个作为一个单独的key来缓存。

5.proxy_cache_bypass [string] 绕过缓存

proxy_cache_bypass 指令用于在特定条件下绕过缓存并直接向后端服务器发起请求。可以使用一个或多个条件来配置。如果满足任何一个条件,将绕过缓存。这里的string通常为nginx的的一些内置变量或者自己定义的变量。

例如:proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment $http_pragma h t t p a u t h o r i z a t i o n ; 其中, http_authorization; 其中, httpauthorization;其中,cookie_nocache、 a r g n o c a c h e 、 arg_nocache、 argnocachearg_comment、 h t t p p r a g m a 和 http_pragma 和 httppragmahttp_authorization 都是Nginx配置文件的变量。

例如:proxy_cache_bypass $http_pragma $http_authorization; 在这个示例中,如果请求头部中包含 “pragma” 或 “authorization” 的字段,则会绕过缓存。

6.proxy_no_cache 不缓存指令

proxy_no_cache指令用于控制哪些响应不应该被缓存。可以在location块中使用proxy_no_cache指令来定义不应该缓存的条件。proxy_no_cache $http_cookie $arg_nocache;在示例中,如果请求中包含名为nocache的查询参数或者有Cookie头,则该请求的响应将不会被缓存。proxy_no_cache r e q u e s t u r i j ˙ s o n request_uri ~ \.json requesturi j˙son;表示不缓存以".json"结尾的URL。

7.proxy_cache_background_update 后台更新缓存

proxy_cache_background_update指令用于控制是否在后台更新缓存。 当使用NGINX作为代理服务器时,它通常会将请求的响应存储在缓存中,以减少重复请求的响应时间。然而,有时候后端服务器可能需要一些时间才能生成响应,或者在响应生成之前发生了错误。在这种情况下,NGINX默认会等待后端服务器生成响应并缓存,然后再将响应发送给客户端。

但是,有时候你可能希望在后端服务器正在生成响应时,NGINX能够立即将响应发送给客户端,并在后台异步地更新缓存。这种情况下,就可以使用proxy_cache_background_update指令。

当指令的值为on时,NGINX将允许在后台更新缓存。这意味着当后端服务器正在生成响应时,NGINX将立即将响应发送给客户端,并在后台异步地更新缓存。

8.proxy_cache_lock 缓存锁

proxy_cache_lock 是一个用于控制缓存锁的指令。当多个请求同时访问缓存时,可以使用proxy_cache_lock来确保只有一个请求能够更新缓存,而其他请求将等待锁释放。proxy_cache_lock on;:启用缓存锁。当一个请求开始更新缓存时,其他请求将等待锁释放。proxy_cache_lock off;:禁用缓存锁。多个请求可以同时更新缓存,可能导致缓存不一致的情况。

(五)其他配置

1.keepalive_timeout [time]

keepalive_timeout指令用于设置持久化连接的超时时间。默认值是 75 秒,有些浏览器最多只保持 60 秒,所以可以设定为 60 秒。持久化连接也称为长连接,它允许客户端和nginx服务器之间保持一段时间的连接,而不需要为每个请求都建立新的连接。即在点击一个链接后,在指定时间内没有点击另一个链接,则会关闭当前TCP连接。如果在指定时间内点击了其它链接,则会复用当前的TCP连接,不用进行三次握手,超时时间为 0 表示不使用 TCP 长连接。通过使用持久化连接,可以减少建立连接的开销,提高网络性能和响应速度。

2.send_timeout [time]

send_timeout用来限制nginx服务器向客户端发送响应的时间,如果在指定的时间内服务器没有能够发送完整的响应,则会断开连接。默认情况下,send_timeout的值为60s。

3.reset_timedout_connection [on/off]

reset_timedout_connection用于在 Nginx 服务器上处理超时的连接。当 Nginx 接收到一个来自客户端的请求,但是在设定的超时时间内没有接收到完整的请求数据时,Nginx 将会强制关闭这个连接,会立即关闭该连接,客户端不会收到任何关于超时连接的错误信息。使用 reset_timedout_connection 指令可以防止在多个后端服务器上同时进行请求时,连接超时后 Nginx 服务器继续等待请求完成的情况,从而释放服务器资源。

四、检测模块

(一)nginx http_stub_status 相关参数

1.配置:

location nginx_status {

Stub_status on;

}

访问:ip+端口+/nginx_status可以实时查看nginx状态信息

2.参数说明:

Active connections: 1161 server accepts handled requests207378 207378 3625441 Reading: 0 Writing: 777 Waiting: 384 

说明:

Active connections:当前活动客户端连接数,包括等待连接。

accepts:接受的客户端连接总数。

Handled:已处理的连接总数。 一般情况下,除非达到某些资源限制,否则该参数值与accepts相同 (例如,worker_connections 限制)。

requests:客户端请求总数。

Reading:nginx 正在读取请求标头的当前连接数。

Writing: nginx 将响应写回客户端的当前连接数。

Waiting:当前等待请求的空闲客户端连接数。

活动连接 – 所有打开的连接数。 这并不意味着用户数量。

单个用户对于单个综合浏览量可以打开许多到服务器的并发连接。

服务器接受已处理的请求 - 这显示三个值。

首先是接受的连接总数。

其次是处理的连接总数。 通常前 2 个值是相同的。

第三个值是请求的数量和处理量。 这通常大于第二个值。

将第三个值除以第二个值将得到 Nginx 处理的每个连接的请求数。

在上面的示例中,10993/7368,每个连接有 1.49 个请求。

Reading —nginx读取请求头

Writing —nginx 读取请求正文、处理请求或将响应写入客户端

Waiting —keep-alive连接,实际上它是active – (reading + writing).

该值取决于 keepalive-timeout。

不要将非零等待值与性能不佳相混淆。 可以忽略不计。

不过,您可以通过设置 keepalive_timeout 0 来强制零等待;

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

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

相关文章

如何将安防视频监控系统/视频云存储EasyCVR平台推流到公网直播间?

视频云存储/安防监控EasyCVR视频汇聚平台基于云边端智能协同,支持海量视频的轻量化接入与汇聚、转码与处理、全网智能分发、视频集中存储等。音视频流媒体视频平台EasyCVR拓展性强,视频能力丰富,具体可实现视频监控直播、视频轮播、视频录像、…

基于PyTorch使用LSTM实现新闻文本分类任务

本文参考 PyTorch深度学习项目实战100例 https://weibaohang.blog.csdn.net/article/details/127154284?spm1001.2014.3001.5501 文章目录 本文参考任务介绍做数据的导入 环境介绍导入必要的包介绍torchnet和keras做数据的导入给必要的参数命名加载文本数据数据前处理模型训…

防火墙概述及实战

目录 前言 一、概述 (一)、防火墙分类 (二)、防火墙性能 (三)、iptables (四)、iptables中表的概念 二、iptables规则匹配条件分类 (一)、基本匹配条…

sklearn中的数据集使用

导库 from sklearn.datasets import load_iris 实现 # 加载数据集 iris load_iris() print(f查看数据集:{iris}) print(f查看数据集的特征:{iris.feature_names}) print(f查看数据集的标签:{iris.target_names}) print(f查看数据集的描述…

看板管理:以可视化方式确定任务优先级

确定工作的优先级是我们今天都要面对的挑战。若处理不当,我们就可能试图一心多用,从而严重损害工作效率。 使用看板方法来设定工作优先级是一种非常直观、快速的方法。 确定工作优先级的看板方法 看板工作流程管理方法的核心在于工作可视化。工作被划…

Elasticsearch:什么是生成式人工智能?

生成式人工智能定义 给学生的解释(基本): 生成式人工智能是一种可以创造新的原创内容的技术,例如艺术、音乐、软件代码和写作。 当用户输入提示时,人工智能会根据从互联网上现有示例中学到的知识生成响应,…

记录vite下使用require报错和解决办法

前情提要 我们现在项目用的是vite4react18开发的项目、但是最近公司有个睿智的人让我把webpack中的bpmn组件迁移过来、结果就出现问题啦:因为webpack是commonjs规范、但是vite不是、好像是es吧、可想而知各种报错 废话不多说啦 直接上代码: 注释是之前c…

【Spring】手动实现Spring底层机制-问题的引出

🎄欢迎来到边境矢梦的csdn博文🎄 🎄本文主要梳理手动实现Spring底层机制-问题的引出 🎄 🌈我是边境矢梦,一个正在为秋招和算法竞赛做准备的学生🌈 🎆喜欢的朋友可以关注一下&#x1…

工厂设计模式

github:GitHub - QiuliangLee/pattern: 设计模式 概念 根据产品是具体产品还是具体工厂可分为简单工厂模式和工厂方法模式,根据工厂的抽象程度可分为工厂方法模式和抽象工厂模式。 简单工厂模式、工厂方法模式和抽象工厂模式有何区别? - 知…

一点整理

(1) 美国在2010年以后开始流行数字化转型的。 在2010年以前, 2006年社交网络FB “YOU”:在2004-2006 Web2.0热之前,企业是无法直接触达到每个消费者的2006年Amazon电子商务:这个是我瞎凑的,但因…

运算放大器学习笔记

目录 一、基本定理二、基本定义三、负反馈电路四、同向放大电路五、反向放大电路六、差分放大电路 一、基本定理 【电路示意图】 开环放大公式 VOAvo(V-V-) 开环放大倍数(增益)非常大,105 或 106 输入阻抗超级大(可以理解为电…

八股文学习一(存储)

一. 存储 行式存储的原理与特点 对于 OLAP 场景,大多都是对一整行记录进行增删改查操作的,那么行式存储采用以行的行式在磁盘上存储数据就是一个不错的选择。 当查询基于需求字段查询和返回结果时,由于这些字段都埋藏在各行数据中&#xf…

Uniapp学习之从零开始写一个简单的小程序demo(新建页面,通过导航切换页面,发送请求)

先把官网文档摆在这,后面会用到的 [uniapp官网文档]: https://uniapp.dcloud.net.cn/vernacular.html# 一、开发工具准备 1-1 安装HBuilder 按照官方推荐,先装一个HBuilder 下载地址: https://www.dcloud.io/hbuilderx.html1-2 安装微信开…

chrome插件:一个基于webpack + react的chrome 插件项目模板

项目结构 $ tree -L 1 . ├── README.md ├── node_modules # npm依赖 ├── package.json # 详细依赖 ├── pnpm-lock.yaml ├── public # 里边包含dist,安装的时候安装这个目录即可 ├── src …

postgre 12.11单实例安装文档

一 下载 访问https://www.postgresql.org/download/,点击左侧的‘source进行下载,一般选择bz2的安装包。 二 安装 这里安装12.11版本的postgre,数据目录路径为/data/server/pgdata,端口为5432. 2.1 安装依赖包 #安装 yum in…

C++信息学奥赛1171:大整数的因子

该程序是一个寻找能够整除输入数字的最小正整数的程序。下面是代码的逻辑解析&#xff1a; #include <iostream> #include <string> #include <cstring>using namespace std;int main() {string n; // 定义一个字符串变量nint fale 0; // 用于标记是否能…

企业形象片宣传片策划要从哪里展开

企业形象片宣传片是一种有效的营销工具&#xff0c;能够向潜在客户传达企业的核心价值观、品牌形象和产品服务。对于企业来说&#xff0c;一个成功的宣传片可以增加品牌知名度&#xff0c;提高销售额&#xff0c;并建立与客户的良好关系。然而&#xff0c;要想策划一部成功的企…

换行符转换

将\t\n、\n、多个\n\n\n...转换为\n\n。 import pandas as pd import re # 创建一个示例DataFrame data {msgText: [这是示例文本1&#xff0c;包含\t\n换行符,这是示例文本2&#xff0c;包含\n\n多个\n换行符,这是示例文本3&#xff0c;没有换行符]} df pd.DataFrame(data)…

多语言开发(vant

参考&#xff1a;https://blog.csdn.net/qq_44649801/article/details/131878128?spm1001.2014.3001.5506 一、抛出字段对象A export default { } 二、引入汇总文件&#xff0c;&#xff08;主要的是 模块分割 汇总&#xff0c;对A 等的处理 export default { A&#xff0c;B,…

Redis RedLock算法和底层源码分析

Redlock红锁算法 官网地址&#xff1a;Distributed Locks with Redis | Redis 为什么要使用RedLock&#xff1f; 解释&#xff1a; 线程 1 首先获取锁成功&#xff0c;将键值对写入 redis 的 master 节点&#xff0c;在 redis 将该键值对同步到 slave 节点之前&#xff0c;mas…