n8n 主從架構，解放n8n效能，進行更多任務
n8n 有提供主從架構，讓多個 n8n 程式一起為你工作。
他們會懂得調派任務。
比如你把任務給主管，主管收到任務，就會把任務分配給底下的員工。而你身為老闆的你，只要面對主管。
這主管就是 Master, 員工就是 Slave (奴隸，真貼切)
透過多個程式，讓效率大幅提高。同時間能進行的任務更多。
那實際怎麼做呢？
設定 N8N_ENCRYPTION_KEY
這是用來加密資料庫資料的密鑰，在原本單一 n8n ，不是那麼需要，啟動時就會幫你建立。
會存在 .n8n/config 中，長得就像這樣
{
"encryptionKey": "cjw5GKuWL6eoqaC0MOnHdBNWOfxAzXsn"
}今天你要跑多個 n8n ，每個 n8n 都要讀資料庫，那些加密的資料就需要同樣的 encryptionKey 才能讀取。
所以需要直接在環境變數中直接設定 N8N_ENCRYPTION_KEY ，讓每個 n8n 程式，都用相同的 encryptionKey。
像是 N8N_ENCRYPTION_KEY=cjw5GKuWL6eoqaC0MOnHdBNWOfxAzXsn
設定相同的 PostgreSQL DB
這沒什麼好說的
你會需要設定 6 個 環境變數，用於指定 PostgreSQL DB
DB_POSTGRESDB_DATABASE
DB_POSTGRESDB_HOST
DB_POSTGRESDB_PASSWORD
DB_POSTGRESDB_PORT
DB_POSTGRESDB_USER
DB_TYPE設定執行模式 Queue
原本執行任務的模式是 regular ，就是常規的意思。
但今天你要用主從架構，會要改用 Queue ，任務要先排隊，等待被指派給哪個 n8n 。
所以要設定 EXECUTIONS_MODE=queue
設定 Redis 作為 Queue 存放的地方
你可以想像，任務一疊放在桌上，工人從桌上的任務，從上面一張一張的拿。這桌子就是 Redis 。
和 Postgre SQL 一樣要設定主機、PORT、密碼
QUEUE_BULL_REDIS_HOST
QUEUE_BULL_REDIS_PASSWORD
QUEUE_BULL_REDIS_PORT執行 n8n 程式
以上全部設定完了，就是執行 n8n
啟動 main
main 程式，就是你可登進去 Web 的，和之前一樣 n8n 就可以啟動。
main 會同時擔任 master 和 slave ，主管跳下來和員工一起工作。
如果希望主管別那麼累，可以增加 N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true ，讓 main n8n 不接收 webhook 。
n8n啟動 worker
對於 worker 程式，他只會在背後默默等待任務
concurrency 是一次最多能攬下幾件任務做，至於是不是能同時做，取決於使用的機器。
n8n worker --concurrency=10 # 預設就是 10啟動 webhook (option)
如果你把 main 的 N8N_DISABLE_PRODUCTION_MAIN_PROCESS 打開的話。就不能收 webhook
那可能就需要有 n8n 專門收 webhook。
n8n webhook效能比較 Latency
以下全部都是在 Zeabur 的 Japan Tokey 地區進行測試，使用 JMeter 進行壓力測試。 100 threads * 30 次 Request。
其中 Code Node 只回傳一個 0~100 隨機數。
Webhook When Last Node Finishes ：等待最後一個節點的結束，並回傳最後一個節點結果。
| 方式 | Average | Median | 90% Line | Received KB/sec | Send KB/sec |
| 1.main + worker | 3586 | 3574 | 4079 | 8.585005991 | 3.547030892 |
| 2.沒有 worker | 5876 | 5802 | 6294 | 5.276703763 | 2.196450152 |
| 3.concurrency = 20 | 3235 | 3246 | 3441 | 9.523796938 | 3.964394452 |
| 4.main + 2 個 worker | 2419 | 2317 | 2672 | 12.67951829 | 5.277864604 |
| 5.main+worker+webhook | 1727 | 1754 | 1868 | 18.5725722 | 7.3312785 |
Webhook Immediately ：被調用即刻返回 {"message":"Workflow was started"}
| 方式 | Average | Median | 90% Line | Received KB/sec | Send KB/sec |
| 1.main + worker | 1512 | 1569 | 1629 | 21.15074569 | 8.225289992 |
| 2.沒有 worker | 5349 | 5689 | 6253 | 6.058490295 | 2.373794443 |
| 3.concurrency = 20 | 1651 | 1708 | 1811 | 19.38201228 | 7.594121772 |
| 4.main + 2 個 worker | 1570 | 1598 | 1699 | 20.65329139 | 8.09222528 |
| 5.main+worker+webhook | 1643 | 1674 | 1812 | 19.5820182 | 7.729744024 |
可以看到，會 care response ，一次3000個 request，可以看到 沒有 worker 真的有顯著差異。
增加 worker 會有明顯的提升效率，設定 concurrency 則不太明顯。
並且使用 webhook 的 n8n ，有更顯著提升效能。（這也是官方推薦的）
但官方並不推薦無腦增加 worker ，而是優先提高 concurrency ，避免 PostgreSQL 連線數過多。
如果不 care response，另我超意外的是，沒有 worker 的情況，都已經直接回傳 response 效能還那麼差。
其他方法則沒有顯著提升，畢竟 webhook node 處理完就返回了，但背後其實還在繼續執行任務。
即刻使用
看得霧傻傻嗎？現在 Zeabur 上已經有人，把 main + 1 worker 做成公開模板，可以立刻使用。
