Dieses Mal zeige ich Ihnen, wie Sie den Cluster-Cluster im Knoten verwenden und welche Vorsichtsmaßnahmen bei der Verwendung des Cluster-Clusters im Knoten gelten. Das Folgende ist ein praktischer Fall, schauen wir uns das an.
Fazit
Obwohl die Anzahl der Worker-Prozesse normalerweise auf die Anzahl der CPU-Prozesse festgelegt ist, kann sie diese Anzahl und die Hauptzahl überschreiten Prozess wird nicht zuerst erstellt
if (cluster.isMaster) {
// 循环 fork 任务 CPU i5-7300HQ 四核四进程
for (let i = 0; i < 6; i++) {
cluster.fork()
}
console.log(chalk.green(`主进程运行在${process.pid}`))
} else {
app.listen(1314) // export app 一个 Koa 服务器的实例
console.log(chalk.green(`子进程运行在${process.pid}`))
}
#子进程运行在17768
#子进程运行在5784
#子进程运行在11232
#子进程运行在7904
#主进程运行在12960
#子进程运行在4300
#子进程运行在16056Im Hauptprozess stellt Cluster den Hauptprozess dar (wird zum Überwachen und Senden von Ereignissen verwendet), Prozess ist ein eigener Prozess und Worker stellt den untergeordneten Prozess dar, der über Cluster.workers erhalten wird
Im untergeordneten Prozess stellt der Prozess einen untergeordneten Prozess dar (wird zum Abhören und Senden von Ereignissen verwendet) und kann auch den aktuellen untergeordneten Prozess über Cluster.worker darstellen.
Cluster.worker.process entspricht dem Prozess (in einem untergeordneten Prozess)
Hauptprozess und untergeordnete Prozesse kommunizieren miteinander
Cluster wird verwendet, um auf Auslöser von Prozessen (untergeordneten) untergeordneten Prozessen zu warten. Verschiedene Ereignisse von
Worker werden im Hauptprozess abgerufen und zur Kommunikation mit sich selbst verwendet. Wenn der untergeordnete Prozess ein Ereignis auslöst, gibt er den aktuellen Worker und zugehörige Informationen an das entsprechende Ereignis des Hauptprozesses zurück
process(parent) Die Prozessinstanz des Hauptprozesses selbst, während des Kommunikationsprozesses Grundsätzlich wird die
process(child)-Instanz des untergeordneten Prozesses selbst grundsätzlich nicht verwendet. Ereignisse zur Überwachung selbst können nur im untergeordneten Prozess
<🎜 abgerufen werden >Planungsrichtlinie des untergeordneten Prozesses „cluster.schedulingPolicy“
Planungsstrategien, einschließlich Cluster.SCHED_RR für die Schleifenzählung und Cluster.SCHED_NONE, abhängig vom Betriebssystem. Dies ist eine globale Einstellung, die sofort wirksam wird, wenn der erste Arbeitsprozess gestartet oder Cluster.setupMaster() aufgerufen wird. SCHED_RR ist die Standardeinstellung in allen Betriebssystemen außer Windows. Auch Windows-Systeme werden auf SCHED_RR umgestellt, solange libuv IOCP-Handles effizient verteilen kann, ohne dass es zu ernsthaften Leistungseinbußen kommt. Cluster.schedulingPolicy kann durch Festlegen der Umgebungsvariable NODE_CLUSTER_SCHED_POLICYimplementiert werden. Gültige Werte für diese Umgebungsvariable sind „rr“ und „none“.
RR ist Round-Robin-Polling-Planung, das heißt, jeder untergeordnete Prozess hat die gleiche Chance, Ereignisse abzurufen, was mit Ausnahme von Windows die Standardeinstellung ist. Die Planungsstrategie unter Windows ist sehr seltsam, wie in der folgenden Abbildung dargestellt. Derzeit gibt es keine relevante API zum Festlegen des Planungsstrategie-Knotens, der uns nur zwei Werte liefert
Der Planungsalgorithmus des Clusters hängt derzeit mit dem System zusammen
Authentifizierungsprobleme zwischen mehreren Prozessen
Hinweis:Knoten. js Routing-Logik wird nicht unterstützt. Daher sollten Sie sich beim Entwerfen von Anwendungen nicht zu sehr auf Speicherdaten Objekte (wie Sitzungens und Anmeldung usw.) verlassen. Da es sich bei jedem Arbeitsprozess um einen unabhängigen Prozess handelt, können sie bei Bedarf jederzeit heruntergefahren oder neu generiert werden, ohne den normalen Betrieb anderer Prozesse zu beeinträchtigen. Solange Arbeitsprozesse aktiv sind, kann der Server weiterhin Verbindungen verarbeiten. Wenn keine überlebenden Arbeitsprozesse vorhanden sind, gehen bestehende Verbindungen verloren und neue Verbindungen werden abgelehnt. Node.js verwaltet die Anzahl der Worker-Prozesse nicht automatisch, aber es liegt an der jeweiligen Anwendung, den Prozesspool entsprechend den tatsächlichen Anforderungen zu verwalten.
文档中已明确说明了，每一个工作进程都是独立的，并且互相之间除了能够进行通信外，没有办法共享内存。所以在设计鉴权的时候，有两种方法
通过共有的主进程存储鉴权信息，每次前端提交帐号密码，授权完成后，将 token 发送给主进程，下次前台查询时先在主进程获取授权信息
通过统一的外部 redis 存取
两种方法看来还是第二种好的不要太多，因此多进程的环境下，应该使用外部数据库统一存储 token 信息
进一步的子进程间通信思考
虽然 node 中并没有直接提供的进程间通讯功能，但是我们可以通过主进程相互协调进程间的通讯功能，需要定义标准的通信格式，例如
interface cmd {
type: string
from: number
to: number
msg: any
}这样通过统一的格式，主进程就可以识别来自各个进程间的通信，起到进程通信中枢的功能
egg.js 中 agent 的实现
+--------+ +-------+
| Master |<-------->| Agent |
+--------+ +-------+
^ ^ ^
/ | \
/ | \
/ | \
v v v
+----------+ +----------+ +----------+
| Worker 1 | | Worker 2 | | Worker 3 |
+----------+ +----------+ +----------+我们看到 egg 在多进程模型之间实现了一个 agent 进程，这个进程主要负责对整个系统的定期维护
说到这里，Node.js 多进程方案貌似已经成型，这也是我们早期线上使用的方案。但后来我们发现有些工作其实不需要每个 Worker 都去做，如果都做，一来是浪费资源，更重要的是可能会导致多进程间资源访问冲突。举个例子：生产环境的日志文件我们一般会按照日期进行归档，在单进程模型下这再简单不过了：
每天凌晨 0 点，将当前日志文件按照日期进行重命名
销毁以前的文件句柄，并创建新的日志文件继续写入
试想如果现在是 4 个进程来做同样的事情，是不是就乱套了。所以，对于这一类后台运行的逻辑，我们希望将它们放到一个单独的进程上去执行，这个进程就叫 Agent Worker，简称 Agent。Agent 好比是 Master 给其他 Worker 请的一个『秘书』，它不对外提供服务，只给 App Worker 打工，专门处理一些公共事务。
这样我们可以指定一个进程作为 agent 进程，用于实现自己定义的事务。在 egg 中，主线程启动后 首先 fork agent进程，当 agent 进程启动完成后再启动具体的 worker 进程。参照上面的代码，相信这部分逻辑现在也不难实现了。这样 agent 就会获得 id 为1的进程
相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！
推荐阅读：
Das obige ist der detaillierte Inhalt vonSo verwenden Sie Cluster-Cluster im Knoten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
