“大集中”应用系统的结构和技术特点1——高并发联机事务处理

  何谓高并发？不同的应用系统具有不同的数字指标，但往往和应用系统的物理承载能力有关。另外，同应用系统的业务复杂度也存在很大的关联关系。比如笔 者所参与过的省级税收征管“大集中”系统，系统的实际并发数往往要超过100，峰值时刻可能会达到200。这个数值相比较于电信计费系统的并发数而言，在 数值上可能比较小，但如果同时参考税收征管业务的复杂性，就会体会到服务器要承载的计算负荷是非常巨大的了。
除并发数指标外，还有另外一个技术指 标来描述大集中应用系统所面临的计算压力：系统的响应时间。由于联机事务对交互性操作的敏感性，联机事务对访问响应时间的要求比较严格：一般在1-3秒 钟，极端情况可以延长到5秒。一旦超过这个极限值，就会给使用者带来“慢、无法忍受”等不好的用户体验，系统的可用性就会大打折扣了。

在这里，我们必须要理清一个概念：什么是“并发数”。在工作过程中，笔者曾经见过将每秒处理交易数量、在线数量等当做并发数，这是错误的。对于并发数可以给予如下定义：并发数是系统同时在线实时处理联机交易的数量。如平均并发数为100，则在每一个给定的时刻，系统中都会有100个交易在处理中… …

对于并发数的确认，有多种方法。最简单的方式是通过系统监控实时跟踪系统的运行状态，并根据记录数据来统计系统的并发量。但这是典型的“事后诸葛 亮”——因为很多时候要在系统架构设计之前估算系统的并发访问数量，并根据该数值来确定系统架构的技术和模式方案。——那时候系统还没有做出来呢。
事前估算也有不少方法，比如参考历史经验数值、类比推倒等。但如果不存在可供参考的案例和经验，笔者常用如下方法：
以税收征管业务为例，系统的终端数量为5000台，系统前后台交互的响应时间要求为3秒。计算并发数的方式如下：
假设：
1. 单笔业务处理时间为5分钟
2. 每笔业务需要前后台交互3次，每次3秒钟，其余为前台人机交互时间
3. 网络延迟时间为0秒，即忽略网络延迟
4. 每台终端所处理的业务类型和交易密度相同
5. 每天有效工作时间为6小时

计算：
1. 单笔业务后台处理时间比率：
后台时间比率 = 单笔业务后台处理时间/单笔业务前台业务处理时间
 = 3*3/(5*60) = 3%

2. 每天可处理业务数量（上限）
总业务数量 = (有效工作时间/单笔业务处理时间)*终端数量
 =(6*60/5)*5000 = 360000 (个)

3. 系统理论并发数计算（上限）
系统理论并发数 = 前台业务处理时间总数*后台时间比率/每日工作时间
 = 360000*5*3%/(6*60) = 150

也就是说，按照上述前提和假设，目标系统的并发数不超过150。

其实，上述计算过程可以进一步简化：
系统理论并发数 = 前台业务处理时间总数*后台时间比率/每日工作时间
 = 终端数量 * 每日工作时间 * 后台时间比率 / 每日工作时间
 = 终端数量 * 后台时间比率
 = 5000 * 3% = 150

 

 

高并发对系统设计的影响有哪些？主要体现在系统并发数、吞吐量和响应时间等因素的平衡方面。比如在一定范围内，增加设备可以提高系统的并发数，但良 好的架构和应用模式设计同样可以提供很好的并发性能；降低并发数可以缩短系统访问的响应时间，但缩短响应时间同样可以通过架构、应用业务模式、均衡部署等 多种手段实现。