Node持续运行订单簿缓存更新函数是否阻塞服务及优化咨询

首先得明确：Node.js的事件循环机制决定了异步任务不会阻塞主线程，但同步的密集操作（比如大量同步计算、同步IO）肯定会卡住服务器，导致API请求无法及时响应。下面逐个解答你的问题：

1. 持续运行的更新函数会不会阻塞其他服务器功能？ #

这完全取决于你的缓存函数是怎么实现的：

• 如果你的代码是异步IO为主（比如用axios/fetch异步请求交易所API，用异步方式解析和存储订单簿）：那不会阻塞主线程。Node会把这些异步请求丢给操作系统处理，主线程可以继续处理用户的API请求，等异步操作完成后再回来处理回调。
• 如果你的代码里有同步的密集计算（比如大量订单数据的同步排序、校验）或者同步IO（比如用fs.readFileSync写文件）：那肯定会阻塞。因为同步操作会占用主线程，事件循环被卡住，所有后续的API请求都得排队等它完成。

2. 用户能否正常与服务器交互？ #

还是看上面的实现方式：

• 异步实现：用户的API请求会被正常处理，响应速度不会受太大影响（除非你的异步请求并发太高，占满了网络带宽，但这是资源问题不是阻塞问题）。
• 同步实现：用户的请求会超时或者响应极慢，因为主线程被缓存任务占着，根本没时间处理API请求。

3. 是否需要创建单独服务？ #

分两种情况考虑：

• 不需要的情况：如果你的缓存任务异步实现良好，并发控制得当（比如一次只发起20-30个交易所请求，避免网络过载），服务器CPU、内存、带宽资源都充足，那完全可以把缓存任务放在主服务里，用定时任务异步执行。
• 需要的情况：如果缓存任务非常繁重（比如几百个订单簿的解析/处理是CPU密集型的，或者并发请求太多导致网络拥堵），已经影响到主服务的API响应速度，那建议拆分出单独的服务：
  • 可以用一个独立的Node进程专门跑缓存任务，和主服务通过Redis或者消息队列（比如BullMQ）传递数据。
  • 或者用微服务架构，缓存服务负责拉取和存储订单簿，主服务直接从缓存（比如Redis）读取数据即可，这样两者完全解耦，互不影响。

4. Node能否优先处理API请求并暂停缓存函数？ #

可以实现，但需要合理设计任务优先级：

• 控制缓存任务的并发数：用p-limit这类库限制同时发起的交易所请求数量，避免占满事件循环的异步队列，给API请求留出处理空间。
• 利用事件循环的优先级：在缓存任务的回调里用setImmediate或者process.nextTick把非紧急的处理逻辑延后，让主线程先处理完当前的API请求再继续处理缓存任务。
• 用优先级队列管理任务：把API请求设为高优先级，缓存任务设为低优先级，比如用priorityqueue库，让事件循环优先处理高优先级的API任务。
• Worker线程处理CPU密集任务：如果订单簿的解析是CPU密集型的，把这部分逻辑放到Worker线程里执行，主线程只负责处理API请求和调度任务，这样CPU密集操作不会阻塞主线程。

一些实践小建议 #

• 不要用setInterval来触发缓存任务，因为如果前一次缓存任务还没完成，setInterval会继续发起新的任务，导致任务堆积。建议用递归的setTimeout，前一次任务完成后再触发下一次。
• 把订单簿数据存在Redis这类内存数据库里，主服务读取时速度更快，也避免缓存任务和主服务抢数据库连接。
• 给缓存任务加超时和重试机制，避免某个交易所API超时导致整个缓存流程卡住。

内容的提问来源于stack exchange，提问作者icey-t