Node.js-timers är mycket effektivt implementerade. Deras implementering (beskrivs i en detaljerad artikel om hur de fungerar) kan enkelt hantera ett väldigt stort antal timers.
De hålls i en dubbellänkad lista som är sorterad och bara nästa timer att avfyra har en faktisk libuv-systemtimer kopplad till sig. När den timern avfyras eller avbryts, blir nästa i listan den som är kopplad till en faktisk libuv-systemtimer. När en ny timer har ställts in, infogas den bara i den sorterade listan och, om den inte blir nästa att avfyra, sitter den bara i listan och väntar på sin tur att bli nästa. Du kan ha tusentals av dessa mycket effektivt.
Här är ett par resurser om hur dessa timer fungerar:
Hur många samtidiga setTimeouts före prestandaproblem?
Hur hanterar nodejs timers internt
Den första referensen innehåller ett gäng kommentarer från den faktiska nodejs-koden som beskriver hur det timerlänkade listsystemet fungerar och vad det är optimerat för.
Den andra artikeln ger dig en lite högre beskrivning av hur det är organiserat.
Det finns andra effektivitetsvinster så att när en timer kommer till början av listan och den startar, efter att ha anropat den återuppringningen, kontrollerar node.js framsidan av listan för eventuella andra timers som nu också är redo att avfyras. Detta kommer att sopa upp alla andra timers med samma "måltid" som den första och även alla andra som har kommit till betalning medan dessa olika andra återuppringningar pågick.
När du har tusentals kommer det att ta lite längre tid att infoga en ny timer i den sorterade länkade listan om det finns många timers där, men när den väl är insatt spelar det knappast någon roll hur många det finns eftersom den bara tittar på nästa att avfyra. Så processen att sitta där med tiotusentals timers väntande är bara en systemtimer (som representerar nästa timerhändelse som ska utlösas) och en massa data. All denna data för de andra framtida timerna kostar dig ingenting bara att sitta där.
För Javascript, liknande pytonens första lösning, skulle jag kunna skapa så många setTimeouts som behövs, men problemet är att alla timeouts fungerar på huvudtråden, men som jag sa, uppgifterna är inte resurskrävande och jag behöver bara noggrannhet för att andra.
Det verkar för mig som nodejs skulle kunna hantera din mängd setTimeout() ringer bra. Om du hade ett problem i node.js skulle det inte bero på antalet timers, men du måste vara säker på att du använder tillräckligt med CPU på problemet om du har mer arbete att bearbeta än en kärna kan hantera. Du kan utöka kärnanvändningen med nodejs-klustring eller med en arbetskö som använder Worker Threads eller andra nodejs-processer för att hjälpa till med bearbetningen. node.js är i sig mycket effektivt med allt I/O-relaterat så så länge du inte gör stora CPU-intensiva beräkningar kan en enda node.js-tråd hantera mycket händelsebearbetning.
Tänk på att Javascript-timers inte ger några exakthetsgarantier. Om du kör ner processorn kommer vissa timers att starta senare än planerat eftersom de inte är förebyggande. Men om dina uppgifter inte är CPU-intensiva kan det gå bra för dig.