Node.js 多进程/线程 —— 日志系统架构优化实践

2022-06-29 15:03:28 浏览数 (1)

1. 背景

  在日常的项目中,常常需要在用户侧记录一些关键的行为,以日志的形式存储在用户本地,对日志进行定期上报。这样能够在用户反馈问题时,准确及时的对问题进行定位。

  为了保证日志信息传输的安全、缩小日志文件的体积,在实际的日志上传过程中会对日志进行加密和压缩,最后上传由若干个加密文件组成的一个压缩包。

  为了更清晰的查看用户的日志信息。需要搭建一个用户日志管理系统,在管理系统中可以清晰的查看用户的日志信息。但是用户上传的都是经过加密和压缩过的文件,所以就需要在用户上传日志后,实时的对用户上传的日志进行解密和解压缩,还原出用户的关键操作。如下图所示,是一个用户基本的使用过程。

  但是解密和解压缩都是十分耗时的操作,需要进行大量的计算,在众多用户庞大的日志量的情况下无法立即完成所有的解密操作,所以上传的日志拥有状态。(解密中、解密完成、解密失败等)

  一个常见的日志系统架构如下:

  其中按照解密状态的变化,大体分为三个阶段:

  1. 用户终端上传日志到 cos 并通知后台日志服务已经上传了日志,后台日志服务记录这条日志,将其状态设置为未解密
  2. 日志服务通知解密服务对刚上传的日志进行解密,收到响应后将日志的状态更改为解密中
  3. 解密服务进行解密,完成后将明文日志上传并通知日志服务已完成解密,日志服务将解密状态更改为解密完成。如果过程中出现错误,则将日志解密状态更改为解密失败

  但是在实际的项目使用过程中,发现系统中有很多问题,具体表现如下:

  • 有些日志在上传很久以后,状态仍然为解密中。
  • 日志会大量解密失败。(只要有一个步骤出现错误,状态就会设置为解密失败)

接下来将以这些问题为线索,对其背后的技术实现进行深入探索。

2. 问题分析

  第一个问题是有些日志上传很久之后,状态仍然为解密中。根据表现,可以初步确定问题出现在上述的阶段 3(日志状态已设置为解密中,但并未进行进一步的状态设置),因此,可以判断是解密服务内部出现异常。

  解密服务使用 Node.js 实现,整体架构如下:

  解密服务 Master 主进程负责进程调度与负载均衡,由它开启多个工作进程(Work Process)处理 cgi 请求,同时它也开启一个解密进程专用于解密操作。下面将着重介绍 Node.js 实现多进程和其通信的方法

2.1 Node.js 实现多进程

2.1.1 使用多进程的好处

  进程是资源分配的最小单位,不同进程之间是隔离开来,内存不共享的,使用多进程将相对复杂且独立的内容分隔开来,能降低代码的复杂度,每个进程只需要关注其具体工作内容即可,降低了程序之间的耦合。并且子进程崩溃不影响主进程的稳定性,能够增加系统的鲁棒性。  进程作为线程的容器,使用多进程也充分享受多线程所带来的好处。在下文会有多线程的详细介绍。

2.1.2 使用多进程的劣势

  进程作为资源分配的最小单位,启动一个进程必须分配给它独立的内存地址空间,需要建立众多的数据表来维护它的代码段、堆栈段和数据段,在进程切换时开销很大,速度较为缓慢。除此之外,进程之间的数据不共享,进程之间的数据传输会造成一定的消耗。

  因此,在使用多进程时应充分考虑程序的可靠性、运行效率等,创建适量的进程。

2.1.2 Node.js 提供的实现多进程的模块

  Node.js 内部通过两个库创建子进程:child_process 和 cluster,下文先介绍 child_process 模块。

  child_process 模块提供了四个创建子进程的函数,分别为:spawn、execFile、exec、fork,可以根据实际的需求选用适当的方法,各个函数的区别如下:

  其中 fork 用于开启 Node.js 应用,在 Node.js 中较为常用,其用法如下:

  一个简单的 demo 如下:

代码语言:javascript复制
// demo/parent.js
const ChildProcess = require('child_process');

console.log(`parent pid: ${process.pid}`)

const childProcess = ChildProcess.fork('./child.js');
childProcess.on('message', (msg) => {
    console.log("parent received:", msg);
})
// demo/child.js
console.log(`child pid: ${process.pid}`)

setInterval(() => {
    process.send(newDate());
}, 2000)
$ cd demo && node parent.js // 在demo目录下执行parent.js文件

  结果:

  在任务管理器(活动监视器)中看到,确实创建了对应 pid 的 Node.js 进程:

2.2 Node.js 实现多进程通信

2.2.1 常见的进程通信方式

  试想有以下两个独立的进程,它们通过执行两个 js 文件创建,那么如何在它们之间传递信息呢?

代码语言:javascript复制
// Process 1
console.log("PID 1:", process.pid);

setInterval(() => { // 保持进程不退出
    console.log("PROCESS 1 is alive");
}, 5000)
代码语言:javascript复制
// Process 2
console.log("PID 2:", process.pid);

setInterval(() => { // 保持进程不退出
    console.log("PROCESS 2 is alive");
}, 5000)

  接下来介绍几种通信方式:

1. 信号

  信号是一种通信机制,程序运行时会接受并处理一系列信号,并且可以发送信号。

1.1 发送信号

  可以通过 kill 指令向指定进程发送信号,如下例子表示向 pid 为 3000 的进程发送 USR2 信号(用户自定义信号)

代码语言:javascript复制
// shell指令,可以直接在命令行中输入
$ kill -USR2 3000

1.2 接收信号

  定义 process 在指定信号事件时,执行处理函数即可接收并处理信号。在收到未定义处理函数的信号时进程会直接退出

代码语言:javascript复制
// javascript
process.on('SIGUSR2', () => {
    console.log("接收到了信号USR2");
}

1.3 示例

代码语言:javascript复制
// Receiver
console.log("PID", process.pid);

setInterval(() => {
    console.log("PROCESS 1 is alive");
}, 5000)

process.on('SIGUSR2', () => {
    console.log("收到了USR2信号");
})

  假设 Receiver 执行之后的 pid 为 58241,则:

代码语言:javascript复制
// Sender
const ChildProcess = require('child_process');

console.log("PID", process.pid);

setInterval(() => {
    console.log("PROCESS 2 is alive");
}, 5000)

const result = ChildProcess.execSync('kill -USR2 58241');

  在运行 Sender 后,Receiver 成功收到信号,实现了进程间的通信。同样的方式,Receiver 也可以向 Sender 发送信号。

2. 套接字通信

  通过在接受方和发送方之间建立 socket 连接实现全双工通信,例如在两者间建立 TCP 连接:

代码语言:javascript复制
// Server
const net = require('net');

let server = net.createServer((client) => {
    client.on('data', (msg) => {
        console.log("ONCE", String(msg));
        client.write('server send message');
    })
})

server.listen(8087);
// Client
const net = require('net');

const client = new net.Socket();

client.connect('8087', '127.0.0.1');
client.on('data', data =>console.log(String(data)));
client.write('client send message');

  创建 server 和 client 进程后成功发送并接收消息,分别输出以下内容:

3. 共享内存

  在两个进程之间共享部分内存段,两个进程都可以访问,可用于进程之间的通信。Node.js 中暂无原生的共享内存方式,可通过使用 cpp 扩展模块实现,实现较为复杂,在此不再举例。

4. 命名管道

  命名管道可以在不相关的进程之间和不同的计算机之间使用,建立命名管道时给他指定一个名字,任何进程都可以使用名字将其打开,根据给定权限进行通信。

  例如我们创建一个命名管道,通过它在 server 和 client 之间传输信息,例如 server 向 client 发送消息:

代码语言:javascript复制
// shell
$ mkfifo /tmp/nfifo
// Server
const fs = require('fs');

fs.writeFile('/tmp/tmpipe', 'info to send', (data, err) =>console.log(data, err));
// Client

const fs = require('fs');

fs.readFile('/tmp/tmpipe', (err, data) => {
    console.log(err, String(data));
})

先创建命名管道 /tmp/nfifo 后运行 client,与读取一般的文件不同,读取一般的文件会直接返回结果,而读取 fifo 则会等待,在 fifo 有数据写入时返回结果,然后开启 server,server 向 fifo 中写入信息,client 将收到信息,并打印结果,如下所示:

5. 匿名管道

  匿名管道与命名管道类似,但是它是在调用 pipe 函数生成匿名管道后返回一个读端和一个写端,而不具备名字,没有具名管道灵活,在此不做过多介绍。

2.2.2 Node.js 原生的通信方式

  原生的 Node.js 在 windows 中使用命名管道实现,在 * nix 系统采用 unix domain socket(套接字)实现,它们都可以实现全双工通信,Node.js 对这些底层实现进行了封装,表现在应用层上的进程间通信,只有简单的 message 事件和 send () 方法,例如父子进程发送消息:

代码语言:javascript复制
// 主进程 process.js
const fork = require('child_process').fork;

const worker = fork('./child_process.js');
worker.send('start');
worker.on('message', (msg) => {
    console.log(`SERVER RECEIVED: ${msg}`)
})

// 子进程 child_process.js

process.on('message', (msg) => {
    console.log("CLIENT RECEIVED", msg)
    process.send('done');
});

2.2.3 兄弟进程之间通信的实现

  Node.js 创建进程时便实现了其进程间通信,但这种方式只能够用于父子进程之间的通信,而不能在兄弟进程之间通信,若要利用原生的方式实现兄弟进程之间的通信,则需要借助它们公共的父进程,发送消息的子进程将消息发送给父进程,然后父进程收到消息时将消息转发给接收消息的进程。但是使用这种方式进行进程间的通信经过父进程的转发效率低下,所以我们可以根据 Node.js 原生的进程间通信方式实现兄弟进程的通信:在 windows 上使用命名管道,在 * nix 上使用 unix 域套接字,该方法与上文套接字通信类似,只是这里不是监听一个端口,而是使用一个文件。

代码语言:javascript复制
// Server
const net = require('net');

let server = net.createServer(() => {
    console.log("Server start");
})
server.on('connection', (client) => {
    client.on('data', (msg) => {
        console.log(String(msg));
        client.write('server send message');
    })
})

server.listen('/tmp/unix.sock');
// Client
const net = require('net');

const client = new net.Socket();

client.connect('/tmp/unix.sock');
client.on('data', data =>console.log(String(data)));
client.write('client send message');

  启动 server 后会在指定路径创建文件,用于 ipc 通信。

2.2.4 本案例中的问题分析

  本项目中通过一个 requestManager 实现兄弟进程之间的通信,set 方法用于设定当指定序列号收到消息时执行的回调函数。

  在本项目中过程如下:

  1 和 2 流程:

  3 流程:

  解密数据处理片段:

  而本项目的第一个问题,就出现在这里:程序在返回结果时,调用了 res.toString 方法,在出现异常时调用 e.toString 方法获取异常字符串,而实际中项目抛出的异常可能为空异常 null,null 不具有 toString 方法,所以向客户端写入数据失败,导致了解密状态的更新没有触发。

提示:在处理异常时,返回的异常信息一般情况下应该能描述具体的异常,而不应该返回空值;其次,可以使用 String (e) 代替 e.toString (),并且不应该在捕获到异常时静默处理。

2.3 “粘包” 问题的解决

  在解决完上述的问题后,发现 bug 并没有完全解决,于是发现了另一个问题:接收端每次接受的数据并不一定是发送的单条数据,而可能是多条数据的合体。当发送端只发送单条 JSON 数据时,服务端 JSON.parse 单条数据顺利处理消息;然而,当接收端同时接受多条消息时,便会出现错误,最终造成进程间通信超时:

代码语言:javascript复制
Uncaught SyntaxError: Unexpected token { inJSON

2.3.1 “粘包” 问题的出现原因

  由于 TCP 协议是面向字节流的,为了减少网络中报文的数量,默认采取 Nagle 算法进行优化,当向缓冲区写入数据后不会立即将缓冲区的数据发送出去,而可能在写入多条数据后将数据一同发送出去,所以接收端收到的消息可能是多条数据的组合体。除此之外,也有可能是发送端一次发送一条数据,但是接收端没有及时读取,导致后续一次读取多条消息。

2.3.1 “粘包” 问题的解决办法

  “粘包” 问题的根本原因就在于传输的数据边界不明确,因此确定数据边界即可。

  可以通过在发送的消息前指定消息的长度大小,服务端读取指定长度大小的数据。

  除此之外,还能够制定消息的起始和结束符号,起始符和结束符中间的内容即为一条消息。

2.4 异常的处理

  在本项目中,解密会大量失败,而大量失败的原因是进程间通信失败,查看具体原因后发现是解密进程已经退出,导致大量的失败。接下来将探讨 Node.js 进程退出的原因和其解决办法。

2.4.1 Node.js 进程退出的原因

在实际 Node.js 进程使用中,如果异常处理不当,会造成进程的退出,使服务不可用。Node.js 退出的原因有以下几种:

  • Node.js 事件循环不再需要执行任何额外的工作,这是一种最常见的进程退出原因,当运行一个 js 文件时,发现文件执行完成之后,进程会自动退出,其原因就是因为事件循环不需要执行额外的工作。阻止此类进程退出可以不断在事件循环中添加事件,如使用 setInterval 方法定时添加任务。
  • 显式调用 process.exit() 方法,该方法可接受一个参数,表示返回代码,代码为 0 表示正常退出,否则为异常。
  • 未捕获的异常, 未捕获的异常会导致进程退出并打印错误信息。使用 process.setUncaughtExceptionCaptureCallback(fn) 可以在有未捕获异常时调用 fn,防止进程的退出。
  • 未兑现的承诺,未捕获的 Promise.reject 在高版本的 Node.js(v15 以后)会导致进程的退出,而在低版本不会。
  • 未监听的错误事件new EventEmitter().emit('error') 若没有监听 error 事件则会导致进程退出,处理方法同未捕获的异常
  • 未处理的信号,在向进程发送信号时,若没有设置监听函数,则进程会退出。 $ kill -USR2 <程序中输出的pid>

2.4.2 处理异常的方式

对于上述造成 Node.js 退出的原因,都有其解决办法。

  • Node.js 事件循环不再需要执行任何额外的工作,可以在事件循环中定时添加任务,例如 setInterval 会定时添加任务,阻止进程退出。
  • 显示调用 process.exit() 方法,在程序中非必要情况下,不要调用 exit 方法。
  • 未捕获的异常,使用 try { ... } catch (e) { } 对异常进行捕获,并且可以设置 process.setUncaughtExceptionCaptureCallback(fn) 可以在有未捕获异常时调用 fn,防止进程的退出,作为兜底策略。
  • 未兑现的承诺,在 promise 后调用.catch 方法或者设置 process.on('unhandledRejection', fn),防止进程退出,作为兜底策略。
  • 未监听的错误事件,在触发 'error' 事件前,可以通过 EventEmitter.listenerCount 方法查看其监听器的个数,如果没有监听器,则使用其它策略提示错误。
  • 未处理的信号,对于信号量,设置监听函数 process.on('信号量', fn) 监听其信号量的接受,防止进程退出。

2.4.3 异常对于 Promise 状态的影响

代码语言:javascript复制
process.on('uncaughtException', err =>console.log(err));
let pro = newPromise((resolve, reject) => {
    thrownewError('error');
});
setInterval(() =>console.log(pro), 1000);

这种情况这个 promise 的状态如何呢?在 promise 内部既没有调用 resolve 方法,也没有调用 reject 方法。那么 promise 的状态为 pending 吗?

-- 答案是否定的,在 promise 内部抛出异常,会立即将 promise 的状态更改为 reject,而不会使 promise 的状态始终为 pending。

那么又有另外一个问题,如果当前不捕获异常的情况下,这里使用那个事件捕获异常呢?

unhandledRejectionuncaughtException?

答案是都可以,这个异常会先由 unhandledRejection 的 handler 处理,如果该事件未定义则由 uncaughtException 的 handler 处理,如果两个事件都未定义则会提示错误并终止进程,具体原因在此处不作过多讨论。

2.5 Node.js 多线程

  由于需要进行大量的解密和解压缩操作,在本项目中的解密进程中,创建了多个线程,接下来将对 Node.js 多线程做详细的介绍。

2.5.1 使用多线程的好处

  前文已经提到过,进程是资源分配的最小单位,使用多进程能够将关联很小的部分隔离开来,使其各自关注自己的职责。

  而线程则是 CPU 调度的最小单位,使用多线程能够充分利用 CPU 的多核特性,在每一个核心中执行一个线程,多线程并发执行,提高 CPU 的利用率,适合用于计算密集型任务。

2.5.2 Node.js 提供的实现多线程的模块

  在 Node.js 中,内置了用于实现多线程的模块 worker_threads ,该模块提供了如下方法 / 变量:

  • isMainThread:当线程不运行在 Worker 线程中时,为 true。
  • Worker 类:代表独立的 javascript 执行线程:
  • parentPort:用于父子线程之间的信息传输: // 子线程 -> 父线程 // 子线程中 const { parentPort } = require('worker_threads'); parentPort.postMessage(`msg`); // 父线程中 const { Worker } = require('worker_threads'); const worker = new Worker('filepath'); worker.on('message', (msg) => { console.log(msg) }); // 父线程 -> 子线程 // 父线程中 const { Worker } = require('worker_threads'); const worker = new Worker('filepath'); worker.postMessage(`msg`); // 子线程中 const { parentPort } = require('worker_threads'); parentPort.on('message', (msg) =>console.log(msg));

2.5.3 单线程、多线程、多进程的比较

  接下来,将使用单线程、多线程、多进程完成相同的操作。

代码语言:javascript复制
// 单线程
console.time('timer');
let j;

for(let i = 0;i<6e9;i  ) {
    Math.random();
}

console.timeEnd('timer');
代码语言:javascript复制
// 多线程

// 主线程 thread.js
console.time('timer');

const { Worker, isMainThread } = require('worker_threads')

let cnt = 15;
for(let i = 0;i<15;i  ) {
    const worker = new Worker('./worker.js');
    worker.postMessage('start');
    worker.on('message', () => {
        if(--cnt === 0) {
            console.timeEnd('timer');
            process.exit(0);
        }
    })
}

// 工作线程 worker.js
const { parentPort, isMainThread } = require('worker_threads');

parentPort.on('message', () => {
    for(let i = 0;i<1e9;i  ) {
        Math.random();
    }
    parentPort.postMessage('done');
})
代码语言:javascript复制
// 多进程

// 主进程 process.js

console.time('timer');
const fork = require('child_process').fork;

let cnt = 15;
for(let i = 0;i<15;i  ) {
    const worker = fork('./child_process.js');
    worker.send('start');
    worker.on('message', () => {
        if(--cnt === 0) {
            console.timeEnd('timer');
            process.exit(0);
        }
    })
}

// 子进程 child_process.js

process.on('message', () => {
    for(let i = 0;i<1e9;i  ) {
        Math.random();
    }
    process.send('done');
});

  实际运行结果如下(测试机为 8 核 CPU):

  分别为单个线程、6 个线程、6 个进程的运行结果,(在多次实验后)结果有以下规律:

  多线程 <多进程 < 单线程 < (多线程 / 多进程) * 6

  其原因如下:

多线程:由于充分利用 CPU,所以执行的最快。

多进程:由于每个进程中都有一个线程,同样能充分利用 CPU,但是进程创建的开销要比线程大,所以执行的略慢于多线程。

单线程:由于 CPU 利用不充分所以慢于多线程和多进程,但是由于多线程 / 多进程的创建需要一定的开销,所以快于单个线程执行时间 * 线程个数。

  结果与预期一致。

2.5.2 本案例中线程池的问题

  在本系统中,实现了一个线程池,它能够在线程持续空闲的时候将线程退出,它会在线程创建时监听它的退出事件。

代码语言:javascript复制
worker.on('exit', () => {
  // 找到该线程对应的数据结构,然后删除该线程的数据结构
  const position = this.workerQueue.findIndex(({worker}) => {
    return worker.threadId === threadId;
  });
  const exitedThread = this.workerQueue.splice(position, 1);
  // 退出时状态是BUSY说明还在处理任务(非正常退出)
  this.totalWork -= exitedThread.state === THREAD_STATE.BUSY ? 1 : 0;
});

  当线程一段时间内都是空闲时,调用线程的 terminate 方法,将其退出。然而,这段代码中的问题是,线程在调用 terminate 函数退出后,其 threadId 自动重置为 - 1,所以这段代码并不会在线程池中将其移除,而由于 splice (-1, 1) 会将线程池中的最后一个线程移出。这样,当线程池分配任务时,会分配给已经退出的线程,而已经退出的线程不具备处理任务的能力,因此造成进程间通信超时。

2.6 内存泄漏问题的处理

  在实际的应用中一个服务端项目往往都会持续运行很长时间,Node.js 会自动对没有引用的变量所占用的内存进行回收,但是还有很多内存泄漏的问题,系统并不能够自动对其进行处理,例如使用对象作为缓存,在对象上不断添加数据,而不对无用的缓存做清除,则会导致这个对象占用的内存越来越大,直到达到内存分配的最大限度后进程自动退出。下文将介绍如何分析内存泄漏问题。

2.6.1 内存快照分析

  分析内存泄漏问题最基本的方式是通过内存快照,在 Node.js 中可以通过 heapdump 库获取内存快照,内存快照可以用于查看内存的具体占用情况。

代码语言:javascript复制
const heapdump = require('heapdump');

const A = { // 4587
    b: { // 4585
        c: { // 4583
            d: newArray(1e7),
        }
    }
}

heapdump.writeSnapshot();

  例如在 Chrome 调试工具中查看内存快照:

  在 Summary 快照总览中可以看到内存分配的详细信息。

  第一列是 Constructor 构造函数,表示该内存的对象由该构造函数创建,()包裹的部分为内置的底层构造函数,后方的 x1407 表示有 1407 个实例通过该构造函数创建,下方 Object @4583 表示该 Object 实例的唯一内存标识为 4583,下方 d::Array 表示其内部的键为 d 的值为一个 Array 类型的数据;

  第二列为 Distance,距离顶层 GCroot 的距离,例如直接在全局作用域中的变量。

  第三列为 Shallow Size,表示其自身真实占用的内存大小。

  第四列为 Retained Size,表示与其关联的内存大小,此处和此处可释放的子节点占用的内存总和。

  从上图可以看出,标记为 4583 的对象,它的键为 d 的数组下真实分配了 80 000 016 字节大小的数据,占总堆分配的数据的 98%,点击它查看详情,可以看到它以 c 这个键存在于标记为 4585 对象下,查看 4585 对象可以看到,它以 b 这个键存在于标记为 4587 的对象下:

  查看标记为 4587 的对象可以看到,它直接存在于垃圾回收根节点上 GCRoot,与代码完全对应,相关对应关系如下:

代码语言:javascript复制
const A = { // 4587
    b: { // 4585
        c: { // 4583
            d: e,
        }
    }
}

2.6.2 本案例中的内存泄漏问题

  在本案例中,也发现其一些任务始终存在于内存中,下图为时间间隔为一天后内存的占用量,可以看出内存占用量提升的非常快,

  查看其内存占用后发现是线程池中部分任务,由于进程间通信超时,始终没有得到释放,解决进程间通信超时问题,并且设置一个 timeout 超时释放即可。

2.7 npm 包发布流程

  在一个大型项目中,往往需要用到多方面的技术,如果各方面内容的实现都放在一起,会比较杂乱,耦合度高,难以阅读和维护。因此,需要对程序的模块进行划分,对每一个模块进行良好的设计,让每一个模块都各司其职,最后组成整个程序。

  在本项目中的 nodejs-i-p-c 进程间通信库,nodejs-threadpool 线程池均以包的形式发布到了 npm 上。接下来将介绍基本的 npm 包发布流程。

  1. 注册 npm 账号(https://www.npmjs.com/) 在 npm 官网使用邮箱注册账号,需要注意的是 npm 官网登录只能使用用户名 密码登录,而不能使用邮箱 密码登录!
  2. 初始化本地 npm 包。在一个本地的空文件夹中运行 npm init 指令,创建一个 npm 仓库,仓库的名称即为将要发布的包的名称。(package.json 文件中的 name 字段)
  3. 登录 npm 账号 在本地命令行中运行 npm login 指令即可进行登录操作,在输入用户名、密码、邮箱后即可完成,登录成功则会提示 Logged in as <username> on https://registry.npmjs.org/. npm whoami 指令可以查看当前登录的账户。
  4. 在(2)中初始化的仓库中运行 npm publish 即可快速发布当前包 如果发布失败,可能是因为包名重复,提示没有权限发布该包,需要更改包名重新发布。
  5. 使用 npm view <package-name> 验证包发布,如果出现该包的详细信息则说明包发布成功了!

  在包发布成功之后其他人都能够访问到该包,通过 npm i <package-name> 即可安装您发布的包使用啦。

3. 成果展示

处理前:日志解密大量失败,一些日志持续停留在解密中状态

处理后:解密全部成功,无其它异常。

紧追技术前沿,深挖专业领域

扫码关注我们吧!

0 人点赞