TarsCloud_TarsCpp/docs/tars_cpp_server_thread.md

# 目录
> * 概述
> * 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. 改变服务端网络线程、客户端网络线程、异步回调处理线程的方法

如果要改变服务端网络线程、客户端网络线程、异步回调线程数目，可以在模版上修改，或者增加对应的服务私有模版。