在系统经巨量流量洗涤后的记录与反思

前言

我司即将迎来一场巨大流量的活动，流量大的我们可能不太好预估，我们提前扩容了很多的服务，数据库，中间件。进行了大量的压测。但间歇性的人数暴涨仍然给我们的系统上了一课，以下对本次出现的问题进行总结。

redis间歇性报错

在前期，在优化接口时，将一些对于数据库的操作转移到了缓存中，（我们是用的缓存中间件是redis）但缓存在稍微高峰期总出现can’t get resouce from pool 的问题，参考网上的解决方案，我们加大了最大连接池的数量，但在高峰突刺产生时任然会出现大量的报错。

对，我们使用的连接池是jedis连接池，底层是使用阻塞队列来borrow连接池资源，

• 添加超时时间 按逻辑在连接未归还时会阻塞等待，并很可能一直等待不到，有些离谱的线程能等待1分钟多。于是按照正常逻辑我们加上了超时连接时间，虽然获取不到连接会在超时时放弃获取。虽然这样不会长时间阻塞住，但大量的出错任为解决。
• 增加获取时校验 由于经常出现失效连接我们添加了在获取前校验的逻辑，虽然这样可能会增加一次验证TestOnBorrow，但为了整体性能还是打算尝试一下。
• 更换连接池 由于jedis的连接池性质我们决定更换成spring目前默认支持的连接池lettuce，在更换后貌似性能好了一些，但是总会出现一个问题就是会出现间歇性的大量获取连接报错。不知道是换连接池的问题还是redis测导致的。但lettuce的坑确实比较多，这款基于netty nio机制实现的号称线程安全的框架貌似并没有给我们带来多大的提升，而且在没有配置一定参数时不能实现高可用主从节点切换。
  
  看 这报错的间歇性是不是规律的让人诡异，在排查了定时任务和询问DBA redis是否开启持久化后任没有任何的出入。
• 切换集群，在找不出问题时，权衡了利弊最终决定切换另一套更高效的redis集群，紧急搭建了一上午切换后，redis的报错在流量达到高峰时却神奇般的消失了。那到底是什么情况导致的呢？
• 在解决了问题后回溯，DBA表示网络问题在其中产生了重要的影响，部分节点的网络差别较大，单个操作可能要达到30ms甚至更高 而快的仅需3ms。access_latency代表延时
  

mongoBb大量超时

考虑到mongoBb的性能可能不是太好，前期大量对于mongo的操作以及转移到了redis之中，但在热门比赛时任会出现大量的报错。

• 关于连接的参数，每台机器都有足够的量，超时时间也设置的较短，以防止耗时操作影响系统对于数据库仅有连接数的占有，及时让出宝贵的资源。
  但在多次的参数调优之后，在高峰期时数据库仍然像一个豆腐渣一般，出现大量的异常
  
• 奇怪的一点是，本服务使用的大量操作属于更新，但是DBA表示我们居然有超高的插入操作，表示服务器磁盘快坚持不住了。

在经过排查后，最终了发现导致问题的原因

• mongo采用的是主从集群，我们大量的update操作在主节点操作后，会以insert的方式同步到从节点，由于服务器的网络问题，有时候会同步少些，有时候大量同步导致IO量剧增。又是由于网络导致的问题。

反思

反思是为了更好的前进，本次解决的问题是和大佬们一起反馈寻找出来的，作为一名开发可能不太能接触和监察到现网的资源信息和网络信息，但可能需要我们有这样的想法和考虑，在出现问题后有一定的方向。细微的差别在大流量时会暴露的更加明显。

相关连接：
jedispool参数
cantborrow问题分析