Redis 인스턴스는 기본적으로 모두 마스터 노드이므로 마스터-슬레이브 아키텍처를 구축하려면 일부 구성을 수정해야 합니다. Redis의 마스터-슬레이브 아키텍처는 구축하기가 비교적 간단합니다. 나중에 소개할 마스터-슬레이브 아키텍처를 구축하기 전에 먼저 마스터-슬레이브 아키텍처의 특징을 이해해야 합니다. 마스터-슬레이브 아키텍처에는 마스터 노드(마스터)와 하나 이상의 슬레이브가 있습니다. 노드(슬레이브)이며 데이터 복제는 단방향이므로 마스터 노드에서 슬레이브 노드로만 복사할 수 있고 슬레이브 노드에서 마스터 노드로는 복사할 수 없습니다.
마스터-슬레이브 아키텍처를 설정하는 방법에는 세 가지가 있습니다:
Redis.conf 구성 파일에 Slaveof {masterHost} {masterPort} 명령을 추가하고 Redis 인스턴스가 시작되면 적용됩니다.
redis-server 시작 명령 뒤에 --slaveof {masterHost} {masterPort} 매개변수를 추가하세요
redis-cli 대화형 창에서 직접 명령을 사용하세요. {masterHost} {masterPort}
위의 세 가지 Redis 마스터-슬레이브 아키텍처는 첫 번째 방법을 보여주고 나머지 두 가지 방법은 직접 시도해 보겠습니다. 여러 시스템에서 Redis 인스턴스를 시작하는 대신 로컬에서 두 개의 Redis 인스턴스를 시작합니다. 이제 포트 6379가 있는 마스터 노드 인스턴스와 포트 6480이 있는 슬레이브 노드 인스턴스를 준비합니다. 포트 6480의 Redis 인스턴스 구성 파일 이름은 6480.conf이며 다음을 추가합니다. 구성 파일 끝에 다음 문을 추가합니다.
slaveof 127.0.0.1 6379
두 개의 Redis 인스턴스를 각각 시작하면 자동으로 마스터-슬레이브 관계가 설정됩니다. 이에 대한 원리에 대해서는 먼저 마스터-슬레이브 아키텍처가 성공적으로 구축되었는지 확인하겠습니다. 먼저 6379 마스터 노드에 새로운 데이터 조각을 추가합니다:
마스터 노드가 데이터를 추가합니다
그런 다음 6480 슬레이브 노드에서 데이터를 가져옵니다.
슬레이브 노드가 데이터를 가져옵니다
볼 수 있습니다. 슬레이브 노드에 있음 마스터 노드에 새로 추가된 값을 성공적으로 얻었으며 이는 마스터-슬레이브 아키텍처가 성공적으로 설정되었음을 나타냅니다. 먼저 두 노드의 정보를 보기 위해 info 복제 명령을 사용합니다. 마스터 노드의 정보에서.
마스터 정보 복제
포트 6379의 인스턴스 역할이 마스터이고, 연결 중인 인스턴스가 있으며, 기타 실행 정보를 확인할 수 있는 포트 6480의 redis 인스턴스 정보를 살펴보겠습니다.
slave 정보 복제
두 노드가 서로 객체 정보를 기록하고, 이 정보가 데이터 복제 중에 사용되는 것을 볼 수 있습니다. 여기서 한 가지 설명해야 할 점은 기본적으로 슬레이브 노드는 읽기 전용이며 쓰기를 지원하지 않는다는 점입니다. 이를 확인하고 6480 인스턴스에 데이터를 쓸 수는 없습니다.
127.0.0.1:6480> set x 3 (error) READONLY You can't write against a read only replica. 127.0.0.1:6480>
프롬프트는 읽기 전용이며 쓰기 작업을 지원하지 않습니다. 물론 구성을 수정할 수도 있습니다. 구성 파일의 Replica-read-only yes 구성 항목은 서버에서 읽기 전용을 제어하는 데 사용됩니다. 왜 읽기 전용만 가능합니까? 복제는 단방향이므로 데이터는 마스터에서 슬레이브 노드로만 전송될 수 있습니다. 슬레이브 노드에서 쓰기가 활성화되면 슬레이브 노드의 데이터가 수정됩니다. 마스터 노드는 이를 감지할 수 없고, 슬레이브 노드의 데이터를 마스터 노드에 복사할 수 없으므로 데이터 불일치가 발생하므로 슬레이브 노드는 읽기 전용으로 설정하는 것이 좋습니다.
마스터-슬레이브 아키텍처의 연결 해제도 슬레이브 노드에서 Slaveof no one 명령을 실행하면 마스터 노드에서 다음 관계의 연결을 끊을 수 있습니다. 6480 노드에서 하나의 명령.
127.0.0.1:6480> slaveof no one OK 127.0.0.1:6480> info replication # Replication role:master connected_slaves:0 master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27 master_repl_offset:4367 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4367 127.0.0.1:6480>
slaveof no one 명령을 실행한 후 6480 노드의 역할이 즉시 마스터로 복원되었습니다. 다시 살펴보고 여전히 6379 인스턴스에 연결되어 있는지 확인하겠습니다. 6379에 새로운 키-값을 추가합니다. 마디.
127.0.0.1:6379> set y 3 OK
6480 노드에서 y를 가져오세요
127.0.0.1:6480> get y (nil) 127.0.0.1:6480>
6480 노드에서 y를 가져올 수 없습니다. 6480 노드가 6379 노드에서 연결이 끊어졌고 마스터-슬레이브 관계가 없기 때문입니다. 또한 마스터 서버를 전환하려면 슬레이브of{newMasterIp} {newMasterPort} 명령을 사용합니다. 6379를 6480의 슬레이브 노드로 만듭니다. 6379 노드에서 슬레이브of 127.0.0.1 6480 명령을 실행합니다. .
127.0.0.1:6379> info replication # Replication role:slave master_host:127.0.0.1 master_port:6480 master_link_status:up master_last_io_seconds_ago:2 master_sync_in_progress:0 slave_repl_offset:4367 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:0000000000000000000000000000000000000000 master_repl_offset:4367 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:4368 repl_backlog_histlen:0 127.0.0.1:6379>
노드 6379의 역할은 이미 슬레이브이고, 마스터 노드는 6480입니다. 노드 6480의 정보 복제를 볼 수 있습니다.
127.0.0.1:6480> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6379,state=online,offset=4479,lag=1 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_repl_offset:4479 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4479 127.0.0.1:6480>
6480 노드에는 6379개의 슬레이브 노드 정보가 있습니다. 슬레이브of 명령이 마스터 서버 전환을 완료하는 데 도움이 되었음을 알 수 있습니다.
redis 的主从架构好像很简单一样，我们就执行了一条命令就成功搭建了主从架构，并且数据复制也没有问题，使用起来确实简单，但是这背后 redis 还是帮我们做了很多的事情，比如主从服务器之间的数据同步、主从服务器的状态检测等，这背后 redis 是如何实现的呢?接下来我们就一起看看。
我们执行完 slaveof 命令之后，我们的主从关系就建立好了，在这个过程中， master 服务器与 slave 服务器之间需要经历多个步骤，如下图所示：
redis 复制原理
slaveof 命令背后，主从服务器大致经历了七步，其中权限验证这一步不是必须的，为了能够更好的理解这些步骤，就以我们上面搭建的 redis 实例为例来详细聊一聊各步骤。
在 6480 的客户端向 6480 节点服务器发送 slaveof 127.0.0.1 6379 命令时，我们会立马得到一个 OK。
127.0.0.1:6480> slaveof 127.0.0.1 6379 OK 127.0.0.1:6480>
这时候数据复制工作并没有开始，数据复制工作是在返回 OK 之后才开始执行的，这时候 6480 从节点做的事情是将给定的主服务器 IP 地址 127.0.0.1 以及端口 6379 保存到服务器状态的 masterhost 属性和 masterport 属性里面。
在 slaveof 命令执行完之后，从服务器会根据命令设置的 IP 地址和端口，跟主服务器创建套接字连接， 如果从服务器能够跟主服务器成功的建立 socket 连接，那么从服务器将会为这个 socket 关联一个专门用于处理复制工作的文件事件处理器，这个处理器将负责后续的复制工作，比如接受全量复制的 RDB 文件以及服务器传来的写命令。同样主服务器在接受从服务器的 socket 连接之后，将为该 socket 创建一个客户端状态，这时候的从服务器同时具有服务器和客户端两个身份，从服务器可以向主服务器发送命令请求而主服务器则会向从服务器返回命令回复。
从服务器与主服务器连接成功后，做的第一件事情就是向主服务器发送一个 ping 命令，发送 ping 命令主要有以下目的：
检测主从之间网络套接字是否可用
检测主节点当前是否可接受处理命令
在发送 ping 命令之后，正常情况下主服务器会返回 pong 命令，接受到主服务器返回的 pong 回复之后就会进行下一步工作，如果没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从服务器会断开复制连接，等待下一次定时任务的调度。
从服务器在接收到主服务器返回的 pong 回复之后，下一步要做的事情就是根据配置信息决定是否需要身份验证：
如果从服务器设置了 masterauth 参数，则进行身份验证
如果从服务器没有设置 masterauth 参数，则不进行身份验证
在需要身份验证的情况下，从服务器将就向主服务器发送一条 auth 命令，命令参数为从服务器 masterauth 选项的值，举个例子，如果从服务器的配置里将 masterauth 参数设置为：123456，那么从服务器将向主服务器发送 auth 123456 命令，身份验证的过程也不是一帆风顺的，可能会遇到以下几种情况：
从服务器通过 auth 命令发送的密码与主服务器的 requirepass 参数值一致，那么将继续进行后续操作，如果密码不一致，主服务将返回一个 invalid password 错误
如果主服务器没有设置 requirepass 参数，那么主服务器将返回一个 no password is set 错误
所有的错误情况都会令从服务器中止当前的复制工作，并且要从建立 socket 开始重新发起复制流程，直到身份验证通过或者从服务器放弃执行复制为止。
인증이 통과된 후 슬레이브 서버는 REPLCONF 청취 명령을 실행하고 슬레이브 서버의 청취 포트 번호를 마스터 서버로 보냅니다. 6480이면 슬레이브 서버는 마스터 서버에 REPLCONF listening 6480 명령을 보냅니다. 마스터 서버는 이 명령을 받은 후 슬레이브 서버에 해당하는 클라이언트 상태의slave_listening_port 속성에 포트 번호를 기록합니다. 마스터 서버의 포트 값에 대한 정보 복제에서 이를 확인할 수 있습니다.
데이터 복제는 psync 명령으로 완료됩니다. Redis 버전 2.8 이전에는 슬레이브 서버가 동기화 명령을 사용합니다. 서로 다른 명령어를 사용하는 것 외에도 복제 방법에도 큰 차이가 있는데, redis 버전 2.8 이전에는 전체 복제를 사용했는데, 이는 redis 버전 2.8 이후에는 마스터 노드와 네트워크에 많은 오버헤드를 발생시켰습니다. , 데이터 동기화는 전체 동기화와 부분 동기화로 구분됩니다.
전체 복제: 일반적으로 초기 복제 시나리오에서 사용됩니다. Redis의 이전 버전이나 새 버전에 관계없이 슬레이브 서버가 처음으로 마스터 서비스에 연결될 때 전체 데이터가 전송됩니다. 마스터 노드부터 슬레이브 노드까지 데이터가 대용량일 경우 마스터 노드와 네트워크에 많은 오버헤드가 발생하게 됩니다. 초기 버전의 Redis는 전체 복제만 지원하므로 효율적인 데이터 복제 방법이 아닙니다
부분 복제: 마스터-슬레이브 복제의 네트워크 중단 및 기타 이유로 인한 데이터 손실 시나리오에서 슬레이브 노드가 마스터 노드에 다시 연결될 때 조건이 허용되면 마스터 노드는 손실된 데이터를 다시 전송합니다. 슬레이브 노드로. 재발행된 데이터는 전체 데이터 양보다 훨씬 작기 때문에 전체 복사의 과도한 오버헤드를 효과적으로 피할 수 있습니다. 부분 복사는 이전 버전 복사의 주요 최적화로, 불필요한 전체 복사 작업을 효과적으로 피할 수 있습니다. 전체 복사 및 부분 복사는 주로 동기화 명령의 최적화를 위해 사용됩니다. Redis 버전 2.8 이후에는 새로운 psync 명령이 사용됩니다. 명령 형식은 psync {runId} {offset}입니다.
복제에 참여하는 마스터 노드와 슬레이브 노드는 각각 자체 복제 오프셋을 유지합니다. 마스터 서버가 슬레이브 서버에 N바이트의 데이터를 전송할 때마다 , 슬레이브 서버는 마스터 서버가 전송한 N바이트의 데이터를 수신할 때마다 자신의 오프셋 값에 N을 추가합니다. 마스터 서버와 슬레이브 서버의 복제 오프셋을 비교하면 마스터 서버와 슬레이브 서버의 데이터가 일치하는지 여부를 알 수 있습니다. 마스터 서버와 슬레이브 서버의 오프셋이 항상 동일하면 마스터와 슬레이브 데이터가 일치합니다. 반대로, 마스터 서버와 슬레이브 서버의 오프셋이 일치하는 경우, 시프트량이 동일하지 않은 경우, 예를 들어 슬레이브 서버가 여러 대 있는 경우 마스터 서버와 슬레이브 서버의 데이터 상태가 일치하지 않는다는 의미입니다. , 아래 그림과 같이 전송 과정에서 특정 서버가 오프라인 상태가 됩니다.
오프셋 불일치슬레이브 서버 A가 데이터 전송 중 네트워크 문제로 오프라인 상태이므로 오프셋이 마스터 서버와 일치하지 않습니다. 그러면 슬레이브 서버 A가 다시 시작하여 마스터 서버에 성공적으로 연결되면 psync 명령을 마스터 서버로 다시 보냅니다. 이때 데이터 복제를 전체 또는 부분 복제로 수행해야 합니까? 마스터 서버는 연결 해제 중에 슬레이브 서버 A가 손실한 데이터 부분을 보상합니까? 이러한 질문에 대한 답변은 복제 백로그 버퍼에 있습니다.
복제 백로그 버퍼는 마스터 노드에 저장되는 고정 길이의 큐입니다. 이때 마스터 노드에 연결된 슬레이브가 있을 때 생성됩니다. 마스터 노드가 쓰기 명령에 응답하면 아래 그림과 같이 슬레이브 노드에 명령을 보낼 뿐만 아니라 복제 백로그 버퍼에도 씁니다.
복제 백로그 버퍼 따라서 마스터 서버 복제 백로그 버퍼는 최근 전파된 쓰기 명령의 일부를 보유하고, 백로그 복사 버퍼는 큐의 각 바이트에 해당하는 복사 오프셋을 기록합니다. 따라서 슬레이브 서버가 마스터 서버에 다시 연결되면 슬레이브 서버는 psync 명령을 통해 복제 오프셋 오프셋을 마스터 서버로 보냅니다. 마스터 서버는 이 복제 오프셋을 기반으로 슬레이브 서버에서 수행할 데이터 동기화 작업을 결정합니다.
如果从服务器的复制偏移量之后的数据不存在于复制积压缓冲区里面，那么主服务器将对从服务器执行全量复制操作
3、服务器运行ID
每个 Redis 节点启动后都会动态分配一个 40 位的十六进制字符串作为运行 ID，运行 ID 的主要作用是用来唯一识别 Redis 节点，我们可以使用 info server 命令来查看
127.0.0.1:6379> info server # Server redis_version:5.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:2ef1d58592147923 redis_mode:standalone os:Linux 3.10.0-957.27.2.el7.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:25214 run_id:7b987673dfb4dfc10dd8d65b9a198e239d20d2b1 tcp_port:6379 uptime_in_seconds:14382 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:14554933 executable:/usr/local/redis-5.0.5/src/./redis-server config_file:/usr/local/redis-5.0.5/redis.conf 127.0.0.1:6379>
这里面有一个run_id 字段就是服务器运行的ID
在熟悉这几个概念之后，我们可以一起探讨 psync 命令的运行流程，具体如下图所示：
psync 运行流程
psync 命令的逻辑比较简单，整个流程分为两步：
1、从节点发送 psync 命令给主节点，参数 runId 是当前从节点保存的主节点运行ID，参数offset是当前从节点保存的复制偏移量，如果是第一次参与复制则默认值为 -1。
2、主节点接收到 psync 命令之后，会向从服务器返回以下三种回复中的一种：
回复 +FULLRESYNC {runId} {offset}：表示主服务器将与从服务器执行一次全量复制操作，其中 runid 是这个主服务器的运行 id，从服务器会保存这个id，在下一次发送 psync 命令时使用，而 offset 则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量
回复 +CONTINUE：那么表示主服务器与从服务器将执行部分复制操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了
回复 +ERR：那么表示主服务器的版本低于 redis 2.8，它识别不了 psync 命令，从服务器将向主服务器发送 sync 命令，并与主服务器执行全量复制
当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。主从服务器之间的连接不会中断，因为主节点会持续发送写命令到从节点，以确保主从数据的一致性。
经过上面 7 步就完成了主从服务器之间的数据同步，由于这篇文章的篇幅比较长，关于全量复制和部分复制的细节就不介绍了，全量复制就是将主节点的当前的数据生产 RDB 文件，发送给从服务器，从服务器再从本地磁盘加载，这样当文件过大时就需要特别大的网络开销，不然由于数据传输比较慢会导致主从数据延时较大，部分复制就是主服务器将复制积压缓冲区的写命令直接发送给从服务器。
心跳检测是发生在主从节点在建立复制后，它们之间维护着长连接并彼此发送心跳命令，便以后续持续发送写命令，主从心跳检测如下图所示：
主从心跳检测
主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，主从心跳检测的规则如下：
默认情况下，主节点会每隔 10 秒向从节点发送 ping 命令，以检测从节点的连接状态和是否存活。可通过修改 redis.conf 配置文件里面的 repl-ping-replica-period 参数来控制发送频率
从节点在主线程中每隔 1 秒发送 replconf ack {offset} 命令，给主节点 上报自身当前的复制偏移量，这条命令除了检测主从节点网络之外，还通过发送复制偏移量来保证主从的数据一致
主节点根据 replconf 命令判断从节点超时时间，体现在 info replication 统 计中的 lag 信息中，我们在主服务器上执行 info replication 命令：
127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6480,state=online,offset=25774,lag=0 master_replid:c62b6621e3acac55d122556a94f92d8679d93ea0 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:25774 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:25774 127.0.0.1:6379>
可以看出 slave0 字段的值最后面有一个 lag，lag 表示与从节点最后一次通信延迟的秒数，正常延迟应该在 0 和 1 之间。如果超过 repl-timeout 配置的值(默认60秒)，则判定从节点下线并断开复制客户端连接，如果从节点重新恢复，心跳检测会继续进行。
Redis 的主从拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从架构。
一主一从结构是最简单的复制拓扑结构，我们前面搭建的就是一主一从的架构，架构如图所示：
一主一从架构
는 마스터 노드가 다운될 때 슬레이브 노드에 대한 장애 조치 지원을 제공하는 데 사용됩니다. 애플리케이션 쓰기 명령 동시성이 높고 지속성이 필요한 경우 슬레이브 노드에서만 AOF를 활성화할 수 있습니다. 이는 데이터 보안을 보장하고 마스터 노드의 지속성 성능 간섭을 방지합니다. 하지만 여기에는 주의가 필요한 구덩이가 있습니다. 즉, 마스터 노드가 지속성 기능을 끌 때 마스터 노드가 오프라인이 되면 자동 재시작을 피하는 것입니다. 마스터 노드가 이전에 지속성 기능을 활성화하지 않았기 때문에 자동 재시작 후 데이터 세트가 비어 있게 됩니다. 이때 슬레이브 노드가 마스터 노드를 계속 복사하면 슬레이브 노드 데이터도 지워지며 이는 의미가 있습니다. 지속력이 떨어지게 됩니다. 안전한 접근 방식은 슬레이브 노드에서 Slaveof no one을 실행하여 마스터 노드와의 복제 관계를 끊은 다음 마스터 노드를 다시 시작하여 이 문제를 방지하는 것입니다.
하나의 마스터와 다중 슬레이브 아키텍처 하나의 마스터와 다중 슬레이브 아키텍처는 스타 토폴로지라고도 합니다. 하나의 마스터와 다중 슬레이브 아키텍처는 아래 그림과 같습니다.
하나의 마스터와 다중 슬레이브 아키텍처
하나의 마스터와 다중 슬레이브 아키텍처는 읽기를 실현할 수 있습니다. 쓰기 분리는 마스터 서버에 대한 부담을 줄이는 데 사용됩니다. 읽기에 많은 시간이 소요되는 시나리오의 경우 마스터 노드에 대한 부담을 공유하기 위해 읽기 명령을 슬레이브 노드에 보낼 수 있습니다. 동시에 키, 정렬 등과 같이 일상적인 개발 중에 시간이 많이 걸리는 읽기 명령을 실행해야 하는 경우 슬레이브 노드 중 하나에서 실행하여 느린 쿼리가 마스터 노드를 차단하고 영향을 미치는 것을 방지할 수 있습니다. 온라인 서비스의 안정성. 쓰기 동시성이 높은 시나리오의 경우 여러 슬레이브 노드로 인해 마스터 노드가 쓰기 명령을 여러 번 보내게 되어 네트워크 대역폭을 과도하게 소비하고 마스터 노드의 로드가 증가하여 서비스 안정성에 영향을 미칩니다.
트리 마스터-슬레이브 아키텍처는 트리 토폴로지 아키텍처라고도 합니다. 트리 마스터-슬레이브 아키텍처는 아래 그림과 같습니다.
트리 마스터-슬레이브 아키텍처
트리 마스터 -slave 이 아키텍처에서는 슬레이브 노드가 마스터 노드의 데이터를 복사할 뿐만 아니라 다른 슬레이브 노드가 하위 계층에 계속 복제할 수 있도록 마스터 노드 역할도 할 수 있습니다. One-Master-Multi-Slave 아키텍처의 단점을 해결하고 복제 중간 계층을 도입하여 마스터 노드의 부하와 슬레이브 노드로 전송해야 하는 데이터의 양을 효과적으로 줄일 수 있습니다. 아키텍처 다이어그램에 표시된 것처럼 노드 A에 데이터가 기록된 후 노드 B와 C에 동기화됩니다. 그런 다음 노드 B는 데이터를 노드 D와 E에 동기화합니다. 데이터는 계층별로 복제됩니다. 마스터 노드의 성능에 대한 간섭을 피하기 위해 마스터 노드는 부하 압력을 줄이기 위해 여러 슬레이브 노드를 장착해야 할 때 트리 마스터-슬레이브 구조를 채택할 수 있습니다.
위 내용은 Redis 마스터-슬레이브 아키텍처를 구축하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
