session存放数据过大导致频繁GC影响服务器性能以及高并发问题解决

刚过完年，就一直比较忙，一直也没空更新。
先是客户要求紧急上线，足足加了一个礼拜的班，紧赶慢赶做了一套订票系统出来。妈的。。。需求还没给，就提了上线申请。简直日了狗。（吐槽。。。。还一个傻逼业务，跟着客户一块烦我。）
然后问题随之而来。哎，果然紧急上线的东西问题频出。

直接记录问题吧。
1，开发购票时，因为任务紧急，简单设计，直接把从EPM查出来的航班全部信息（EPM返回数据很庞大，并且控制权不在我们手里，它返回list，里面还有很多list，这些list里面还是list。简直了。。）放入了session方便后续比对得到他所选仓位的基础仓位及基础仓位运价，当初还在想：这东西有点大，会不会影响性能呢。先试试。到了测试环节发现并没有什么问题，也没太在意了。就草草上线了。上完线发现服务器可用性明显降低，CPU使用率提高了30%，经过和组内大神以及各种硬件中间件老师们的漫长的排查。发现大致原因如下：服务器上jboss的JVM内存是2G，之前应该已经是在出现问题的临界值了，所以，再往里放一个很大的东西，再高并发的情况下，内存一下就不够用了。导致GC回收频繁，系统响应时间变长，影响了可用性。最后我提出来两个解决方案：一，在前台点选时，就去遍历，选出旅客选中的舱位，基础仓位，基础仓位运价。二，在放入session中的时候，把他打散， 只取需要的数据放入，后续进行遍历比对。  最终领导采取的是方案2，原因大概是放入js中取遍历取这个东西，可能一定程度上会影响客户操作的响应速度。还是在服务器进行这类操作，避免影响用户体验。而且我们的前端最近比较忙。还是JAVA解决吧。
整件事情吧，客户需求提的确实不太合理，正常情况下这个需求做下来要最少2个月，一周给他搞定的，设计和实现上肯定是有问题的。设计时确实我当初应该考虑到这个东西的影响，但光看组内几个人的测试，并不能模拟出问题，也没做压测，也是疏忽。最终问题解决了是好的，也算是个自己长个记性。这算是踩的第一个坑吧。

2，上线当天，由于我新做的功能，换了一个IBE的JAR包，导致了上线失败，差点回滚出事故。
原因是这样的，我又采坑了，我们的测试服务器和生产服务器以及8台生产服务器之间。都是存在差异的。再开发测试阶段，3台测试服务器是一样的，都没出现jar包冲突问题，但是上线之后，发现生产服务器却出现jar包冲突，但8台中2台却没有这个问题。经过组内大神和运行中心沟通，发现是存在差异的。而且，jboss在启动项目时，他在部署的war包的同级下，有一个lib文件夹，这个文件夹下存放的jar包，如果有同名的会覆盖掉war包内的jar包，导致jar包的地址变了，然后这个IBE包由于要读取ibe.properties文件，而且是相对路径，直接读取不到了。抛出异常。

3，并发问题

上完线之后，跟性能优化同期处理了一个接口方面的高并发问题。

问题大概是这样，先说流程，三方发送报文到我们总部的一个系统，由他进行一下报文处理，转发到我们的系统。
由于之前一个二把刀做了一个全舱位查询，没评估风险，直接就把全舱开放了。同程再3月搞了一次上线，把查询由低价改为全舱，而且是频繁使用，每天查询量相当高。每次查询都是全舱。全舱的报文一般都相当巨大，这就导致了我们系统处理每个同程进来的请求时间变长了。处理时间变长，导致后面的请求进不来，阻塞之后，等待时间变长，进而超过并发数，导致可用性下降。但由于上线日期和我们的上线日期是一样的，这就让客户联想到了我的需求导致的接口问题，其实并不会导致接口问题，因为接口跟官网是两个集群。泪奔。。。。差点又算我头上。。

好了，大概最近烦心事就这么多吧。好在有个nice领导给扛着，有大神帮衬着去查找问题，这算是工作也来，遇到的比较大的挑战了，从紧急讨论。加班加点开发，处理客户之间关系，分清主次，出现问题的跟踪排查，不同角度的去思考，虽然过程不美好，但是是有收获的。