mirror of
https://gitee.com/TarsCloud/TarsCpp.git
synced 2025-01-05 17:42:24 +08:00
74 lines
3.5 KiB
Markdown
74 lines
3.5 KiB
Markdown
# 目录
|
||
> * 概述
|
||
> * Tars C++框架服务线程组成
|
||
> * 分析运行中线程任务
|
||
> * 改变线程数目的方法
|
||
|
||
# 1. 概述
|
||
|
||
Tars C++框架服务是单进程多线程RPC系统。本文讲述一个标准的Tars C++框架服务启动的线程数目，以及各线程的职责。
|
||
|
||
# 2. Tars C++框架服务线程组成
|
||
|
||
启动者 |线程功能|线程数目
|
||
------|--------|-----
|
||
SERVER |服务主线程，负责服务端初始化|1
|
||
SERVER|服务端网络线程，负责服务端网络收发数据包（数目可配置）|可配置
|
||
SERVER|管理端口业务逻辑线程，负责接受和处理用户自定义命令、服务关闭命令等|1
|
||
SERVER|时间辅助线程，负责定期计算时间，减少系统对gettimeofday的调用|1
|
||
SERVER|滚动日志线程，负责本地的文件创建和日志写入|1
|
||
SERVER|本地日志线程，负责本地、染色日志的文件创建和日志写入（有打印按天日志或者相关初始化，线程才会创建）|1
|
||
SERVER|远程日志线程，负责同步本地、染色日志到远程（有打印按天日志或者相关初始化，线程才会创建）|1
|
||
SERVER|业务逻辑处理线程，负责处理用户业务逻辑，完成服务的主要功能。（默认各个ServantObj有自己对应的业务逻辑处理线程，也可以共用）|可配置
|
||
通信器|客户端网络线程，负责管理对外服务链接、监听读写事件、网络读写|可配置
|
||
通信器|统计属性上报线程，负责收集统计和属性信息，定时同步到stat和property|1
|
||
通信器|异步回调线程，负责执行异步回调函数，客户端每个网络线程有自己的异步线程|可配置
|
||
|
||
# 3. 分析运行中线程任务
|
||
|
||
我们观察一个运行中的TAF框架服务，看下每个线程的特征，并对各个线程功能做下区分。
|
||
|
||
实验场景：
|
||
|
||
> * 服务端配置1个ServantObj，其配置5个业务逻辑线程。
|
||
|
||
> * 服务端配置1个网络线程
|
||
|
||
> * 客户端配置2个网络线程
|
||
|
||
> * 异步回调线程设置为2个。
|
||
|
||
按照上节所述的线程启动策略，这种场景下这个服务应该有：
|
||
|
||
7（固定数）+ 1(服务端网络线程数目) + 5（业务处理线程数目）+ 2(客户端网络线程数目) + 2（异步回调线程数目）* 2(客户端网络线程数目) = 19个线程。
|
||
|
||
|
||
|
||
# 4. 改变线程数目的方法
|
||
|
||
上面看到了一个标准的Tars C++服务是如何组成的，凡是表明线程数目为1的部分是框架内部实现的，用户不能改变数目。
|
||
|
||
能改变的就是服务端网络线程、业务逻辑处理线程、客户端网络线程、异步回调处理线程。
|
||
|
||
## 4.1. 改变业务处理线程数目的方法
|
||
|
||
改变业务逻辑处理线程数据，可以在Tars管理平台配置Servant对象时，在“线程数”输入自己想要的线程，那么框架将会为本Servant启动相应的线程数。
|
||
|
||
|
||
注意：
|
||
|
||
如果服务拥有两个Servant对象，分别属于不同的线程组，计算线程数目时，我们只需将不同Servant对象的线程数简单相加即可。
|
||
|
||
可如果设置了线程组，那么计算方法就有所不同了。
|
||
|
||
比如：
|
||
|
||
ServantA 属于线程组HandleGroupA，启动线程数为10
|
||
|
||
ServantB和ServantC 属于线程组HandleGroupBC，启动线程数为10
|
||
|
||
那么总的业务线程数应该是：10 + 10
|
||
|
||
## 4.2. 改变服务端网络线程、客户端网络线程、异步回调处理线程的方法
|
||
|
||
如果要改变服务端网络线程、客户端网络线程、异步回调线程数目，可以在模版上修改，或者增加对应的服务私有模版。 |