谈谈工作中遇到的系统优化问题

　　二八定律即80/20法则（The 80/20 Rule）。这个原理是由十九世纪末期与二十世纪初期的意大利经济学家兼社会学家维弗利度·帕累托所提出的。它的大意是：在任何特定群体中，重要的因子通常只占少数，而不重要的因子则占多数，因此只要能控制具有重要性 的少数因子即能控制全局。80/20的法则认为：原因和结果、投入和产出、努力和报酬之间本来存在着无法解释的不平衡。一般来说，投入和努力可以分为两种 不同的类型：

1.多数，它们只能造成少许的影响；

2.少数，它们造成主要的、重大的影响。

　　二八定律的现实社会中无处不在，同样体现在我们书写的程序中：80%的运行时间都花在执行20%的代码上。那么，在优化系统（程序）时，应该先找到性能的瓶颈，通常这20%的代码就是我们需要注意的关键。当然要优化，需要先找出这20%的瓶颈，系统的压力测试可以找出瓶颈所在。找到程序的瓶颈之后，需要对代码进行分析。

　　影响系统效率的因素很多，根据所处的行业，仅谈谈个人的一些见解。目前所处的行业系统的瓶颈主要在吞吐量和系统延迟，由于用户感知，所以对时效性要求很高。通常来说吞吐量和系统延迟的关系如此：

1. 吞吐量越大，延迟会越大。因为请求量过大，系统太繁忙，所以响应速度自然会低。

2. 延迟小，能支持的吞吐量就会越高。因为延迟短说明处理速度快，于是就可以处理更多的请求。

　　目前，系统采用的是多进程，多主机部署，分类原则根据不同客户端业务请求，客户端区域标志；多个进程之间采用socket/消息队列进行通信，进程中采用线程池+中间件处理，即one loop per thread + thread_pool模式编程。一般来说大型系统中底层（进程/线程通信于交互）趋于稳定，吞吐量和延迟决定于业务处理的效率，而业务处理中20%代码可能会有80%耗时。要对这些代码进行优化，首先要非常熟悉业务需求，一般来说在开始时确定一个清晰的业务思路，那么效率自然不会差。框架定了，那么在实现代码时，需要注意很多细节，这里谈谈我所遇到的问题：

1. 数据结构的选择。工作中主要用到的数据结构式AVLTree和HashTable。二者均用于存储数据，AVLTree通常将数据库中的数据信息（费用、清单等）加载到内存，AVLTree有排序功能，便于查找，可以方便的对数据进行汇总分类，一般使用方式为:

const char * getAreaCode(int region)
{
static const char * g_AreaCodeList[] =
{"029", "0915", "0914", "0919", "0913", "0911", "029", "0912", "0916", "0917"};

//获取下标，double转换和+0.5用于1095分区下标的计算
int index = double(region-1010)/10+0.5;
return g_AreaCodeList[index];
}

View Code
5 SQL语句优化。工作中用到的SQL语句太多了，说到优化，目前接触到最常见的两种方式：

a. 分区和索引。如果表的数据量特别大，并且查询频率很高，那么应当用到分区和索引，可以改善查询性能，经常接触oracle的人应该很清楚这两点。这里需要注意的是一些操作会导致索引失效，而建立索引时最好避免使用字符串类型，如果使用字符串，那么效率仍会大打折扣。通常使用执行计划可以获取到SQL语句的cost，根据其值进行优化。

b. 使用临时表。在系统中经常会出现多长表关联的情况，并且这些表大部分都是比较庞大，而关联的时候发现其中的某一张或者某几张表关联之后得到的结果集非常小，并且查询得到这个结果集的速度非常快，那么这个时候可以考虑创建临时表。采用临时表本质上来说也是一种空间换时间的做法。

　　影响系统的效率有太多方面的因素，而优化也应该在保证程序的正确性上来进行，也就是说先实现程序的基本功能，其次在进行优化。系统优化是一个很广泛的话题，影响效率的原因太多，这篇文章提到了工作中遇到的一些性能问题，以及当时的解决方案，方法可能不是最好的，但是也得到了一些提升，此处作以总结，还有一些暂时没有想到，之后一并补上。