Updated Architecture: Cluster Multi Process (markdown)

TJKoury 2017-03-20 20:03:32 -04:00
parent c6f9644744
commit e657d597b6
1 changed files with 6 additions and 6 deletions

@ -1,14 +1,14 @@
### *THIS SECTION IS REFERRING TO AN [EXPERIMENTAL FORK](https://github.com/TJKoury/node-red/tree/cluster)*
### *THIS SECTION IS REFERRING TO AN [EXPERIMENTAL FORK](https://github.com/TJKoury/node-red/tree/cluster)
***
#Multi-Process Model
# Multi-Process Model
##Overview
## Overview
This Node-Red fork uses the native Node-Red cluster module for multi-processing.
###Design Notes
### Design Notes
1. A master process is spun up that reads the setting file and initializes at least 1 worker process
2. Each worker process is running the full version of the node-red runtime, including the admin interface
@ -22,7 +22,7 @@ This Node-Red fork uses the native Node-Red cluster module for multi-processing.
9. If a context is initialized with the 'shared' parameter equal to true, the .get method on the returned object requests an optional allback, allowing for async storage.
##Files
## Files
| File | Description |
|:-----|:------------|
|/cluster/index.js| In charge of general process management. Returns a 'clusterRED' object. Has methods to initialize master and Worker processes, spawn and kill new processes, provide status on child processes. |
@ -45,7 +45,7 @@ This Node-Red fork uses the native Node-Red cluster module for multi-processing.
- [x] Need to write tests for cluster features
- [x] Need to write tests for storage features
##General Notes
## General Notes
- Using the Cluster module, instantiate the master process within which runs the main server instance with the admin interface. The settings file defines how many processes to spawn, with a 'max' argument spinning up one process per logical core. The master process listens for child death and respawns a set number of times as configured in the settings file.
- Communication between the cluster master and child processes is handled by passing serialized JSON messages. All messages are defined by originating node id designation, and multi-process enabled nodes listen to the message event from the cluster master on the local cluster and call the 'send' method on the enabled node, activating the flow at that point.