哪些地方会影响交易核心和结算数据库
本篇废话少说直接开始。下图是CTP系统交易核心和结算核心实现交互的主要对象，我们本篇主要分析这些地方对交易核心和结算核心的影响，未必全面只是简单罗列一下，细节我们后续需要其他篇幅更深入的讨论。
什么叫影响，就是哪些操作或者组件有资格消耗交易核心或者结算核心的资源。影响不是一个危险的词语，很多正常的操作和业务也会对系统有所影响。但如果一个非常规的操作产生的影响可能是致命的。
一．有什么地方会影响交易核心
1.交易前置。
交易核心Tkernel.ini中的SingleUserSession_MaxNum配置是设置一个用户（客户号）同时在线Session的上限。一般主席默认配置是6，就是同一个客户号可以同时在交易前置上登陆6个Session。如果修改这个参数，是对所有客户都生效的。打个比方：如果你有个活跃客户，那你的前置上的Session总数最大就是*6=个。如果你从6改为8，那Session总数就是*8=个。一个你看似从6到8的配置，对于系统来讲最大值却是从个Session到个Session的变化。
交易前置front.ini中的FTDMaxCommFlux=6，ConnectFreq=10。
第一个参数FTDMaxCommFlux是表示交易前置针对一个客户的一个Session最多接受6笔/秒，如果Session数量是6个，每秒最大值就是6*6=36笔/秒。如果个客户针对交易核心的最大指令量为*6*6=笔/秒。如果你将FTDMaxCommFlux从6改为8，如果Session数量是6个，每秒最大值就是8*6=48笔/秒。如果个客户针对交易核心的最大指令量为*8*6=2笔/秒。一个FTDMaxCommFlux的参数从6改为8，对于系统来讲最大值却是从笔/秒到2笔/秒的改变。
第二个参数ConnectFreq是表示如果登录失败超过每秒10次，就是断开这个session。当然，程序本身可能后续会进行重新连接。防火墙上可以禁止某个具体IP的非正常行为，但必须是在该session断开后才生效，所以配合ConnectFreq这个参数就能有效的解决这个问题
交易前置如果不进行控制，比如：FTDMaxCommFlux改为，这个时候你有一个客户，他的程序出现问题了，每秒就向你系统发出条指令，一分钟就是笔指令，10分钟就是30万笔，这个时候你系统真能处理得了吗？当然，这些都是极端的情况，但人生有时候就是这么背。
2.交易所报盘
每个交易所针对每个席位的每秒下单是有限制的。中金所每个席位每秒50笔，上海每个席位每秒笔，大连每个席位每秒笔，郑州每个席位每秒50笔。我们举个例子：你一个套系统有两个上海席位、两个中金所席位，一个大连系统，一个郑州席位。那你的每秒流量就是上海笔/秒，中金所笔/秒，大连笔/秒，郑州50笔/秒。如果你的席位上的量正好都是委托单（我们不算撤单），而且数量正好和报盘流量相符。针对每个交易所的每笔委托是手，那我们算出来的最大量是多少呢？
先算从系统到交易所的：
上海：笔/秒，中金所笔/秒，大连笔/秒，郑州50笔/秒。总的就是+++50=笔/秒。现在来看这个量对于系统来说并不算恐怖，但下面我们算一下交易所回来的数据。
从交易所回到系统的：
委托回报也是笔/秒。
成交回报如果都是分一笔一笔回来的，上海：*=00，中金所*=00，大连*=00，郑州50*=。假设这些都是在一秒内回来（最极限情况），那一秒内你的系统4笔/秒，针对这个值，还仅仅是成交回报的量，同时肯定还有客户报单要处理，这个时候核心估计已经处理不过来了。你还要加上核心每两秒接收一下四个交易所的行情数据。报盘上看似正常回来的数据也会对交易核心造成很大压力。
3.四种操作员端
Thostuser，thostman，thostbank，RCwin（强平单是需要发到交易核心进行处理的）。
Thostuer就是俗称交易员，期货公司交易室使用频率最高。查询之类的都是查本地，对交易核心会什么什么冲击呢？其实单单一个交易员这种情况是不太会，造车交易核心Cpu冲高的。情况如下：如果你的交易员设置中勾选了下单不用确认并且不清空下单选项，如果你下一笔单子后，你的回车键被压住了，正好该客户很有钱。好吧，你的交易员就会连续不断的下单。这种情况一般都是故意的，无意出现是比较少的，但是极端情况下可能会有该问题出现。
Thostman本身对交易核心不会造成很大压力，但是它的菜单上有一个应急菜单，下面很多操作都是在主系统宕掉的情况下的应急菜单，如果误操作，也会对系统造成使用上的影响。
Thostbank个人觉得不会造成太大影响，但它本身也会消耗一点资源。
RCwin是风控终端，它的强平单会发到交易核心，只要强平的客户不是非常巨大的量，也不会对系统造成巨大影响。
总的来说，上面四个终端的风险一般是可控的。
4.上场组件
上场组件的名字叫DBMT，就是从DB到Trade的意思。交易核心就是Trade核心，数据库就是DB。
CTP的开发初期就预料到控制柜台数据的修改（数据库）对交易核心的冲击，所以控制上场数据的速度为6笔/秒。但还是有些操作会对场上数据造成冲击，具体分析的过程牛大湿有专门的分析文档，但不是很完整，原因如下：从数据库的t_tb北京治疗白癜风究竟要花多少钱专业的白癜风治疗医院