佰草集CRM服务端优化经验——致曾经的小白（一）

2014年10月，当时我还在和几个兄弟一起创业，10月底我们接到了一个外包项目就是题目中介绍的这个佰草集CRM项目，项目是上海家化集团为旗下品牌佰草集开发一款移动端的CRM系统。拿到这个系统，对方要求我们到上海驻场开发，然后我们就派出了2位Android开发的伙伴去上海了，过去大概半个月开始数据集成了我也来到了上海。

       刚开始接触这个项目我们是抱着尽快完成的心思来做的，现目前国内的外包开发大部分都是注重功能的实现往往忽略了性能，但是当系统开始使用的时候数据量急速上升，性能就显得特别突出，在后来我就被这个问题给坑了。记得是在年前我们就按照对方的要求完成了这个系统，过年后我们团队也被对方整体挖过来专门从事移动CRM的开发。

先大概介绍一下这个系统，系统分为前端（APP,IOS） 和后端（API ）和 数据交互（API和CRM中央数据库交互信息），其中我负责整个后端 和数据交互的开发。第一版中我们是怎么快怎么来的，在这里就我就说一下当时做的很不合理的地方。

       场景一：在一个循环中每次循环都去查询数据库

                       这个可能是大部分刚刚入门的程序员都会惯性的使用这种方式，但是数据量到了一定的大小就会很慢，简单的例子循环10000次，每次访问数据库大概需要30ms,总共就需要30s,到了后期这种写法导致的访问速度会大幅下降。

       解决办法：参用局部缓存的方式，把循环中使用到的数据提前拿到，在循环中直接使用缓存中的查询到的数据，一般的采用这种方式后性能至少可以提升10倍，数据量大的时候可以提升几百到几千倍。基于这一点可以把数据库中保存的一些不经常发生变化却经常使用的数据采用缓存的形式保存在内存中，使用这些数据的时候不去查询数据库直接在内存中查询。采用这种方式优势：速度会提高，节省io时间；缺点：占用内存

       场景二：平衡服务器间性能

在本项目中采用数据库服务器和应用服务器分开的策略，分为数据服务器，应用服务器。项目上线一段时间后发现应用相应时间过长，开始排查这个问题，原来是应用服务器计算比较多资源消耗大的缘故，同时发现数据库服务有5G的内存资源被闲置

      解决办法：利用闲置的数据库资源进行计算，可以把原本在应用服务器消耗资源较多计算以存储过程的形式运行在数据库服务器。这样可以减少应用服务器压力，缩短响应时间。（采用这种方式一定要谨慎，不要弄巧成拙）

       时间有限就先到这里