关于架构升级的一次体悟

   在做A业务的时候,刚开始是阿里云的esc, 4core8g,2个硬盘分别是90  40 吧, 后去由于用户量迅速增长,服务器在半个月的时候挂了,并发当时看到是18w。。。 cpu满了,内存和硬盘已经全部耗完,我只能说是好可怕。。。

  这台机器上nginx,做分发已经反向代理,有统计服务 和业务服务各4个tomcat实例,后来由于并发量高,以及tomcat并发上限来不及处理,又增加了2个业务tomcat实例, 分析了服务器挂了的原因:

    1:nginx分发已经达到上限,当时nginx的配置如下,感觉没有做防护处理,

   2:是tomcat的并发上限,导致nginx分发过的很多请求都处理不了,nginx日志异常多,日志占用了很大的硬盘,

  3:统计业务量异常巨大,经过推算,由于推广用户量的迅速增长,统计量每天至少几千万吧,队列塞满已经达到上线

 再来讲讲我们的架构:

   技术基础架构是典型的spring+springmvc+mybatis+druid+redis+rabbitmq

   我是追寻基础服务组合来处理业务的,所以加入有十张表,那么有是个基础服务,用扩展server来聚合处理业务

   数据源用的是开源数据源Druid, 为加快访问速度,访问结果第一次访问缓存到redis里,后续再访问直接获取,key是接口名称外加参数名称拼接,所以key的唯一性上不用担忧(key的设计以及刷新后续说明)  

     队里呢是统计数据把打入到队列里,做统计处理,当然也有quartz平台来定时处理一些业务

     以上框架以及架构就这么多了

      为啥要用redis,这个做所周知了,优良的读写并发,以及超快的响应速度,以及内存的嘛

   有时间待补