关于20170701出现IM列表无法加载用户信息的问题

---

1. 表现问题说明

2. 用户信息显示配置问题说明

• 简要说明

• 详细过程

• 临时解决方案

• 问题跟进处理

• 后期优化方案

• 21:43分补充

3. IM问题解析

• 代码走查结果：

• 对服务端压力描述：

• 结论：

• pc客户端改进：

4. 关系认证服务端问题分析

• 问题描述:

• 过程分析：

• 代码走查：

• 整改初步方案

---

表现问题说明

IM列表页面无法显示用户扩展信息，有些页面只显示UID

用户信息显示配置问题分析及解决方案

简要说明

经排查发现是关系认证服务端报500错误，导致的连锁反应

详细过程

1. 表单模板服务在早上9点36分时出现假死，见下图：

   
   
   

   图1
   
   

   排查发现请求用户关系认证出现超时，查看日志发现关系认证服务请求超时，在99U上使用建立关系无响应。近两天请求数据，见下图：

   
   
   

   图2

2. 在上周PC端接入后，Nginx请求数量从100万一下升到500万，见下图：

   
   
   

   图3
   
   

   另外查看日志发现PC端请求在同一时间内存在频繁的重复请求，见下图：

   
   
   

   图4
3. 表单模板服务在请求关系认证超时的情况下，也产生了超时情况，目前确认是在请求关系认证时，关系认证超时后，表单请求端口占满却没有及时释放，导致用户信息显示新的请求全部超时响应。

临时解决方案

• 先移除关系认证数据源，保证用户信息显示配置服务正常

问题跟进处理

• PC端请求过多问题需要优化
• 关系认证服务挂死问题需要排查
• 表单模板服务减少并发线程数，对数据源参数进行预检，对缓存穿透进行拦截

后期优化方案

• 架构调整：表单模板服务数据源声明、数据获取分离
• 提供根据数据源声明获取数据的SDK（服务端、Android、iOS、JS），各业务使用SDK获取数据，从而防止出现Single Point of Failure(SPoF)
• 同时使用第二点提供的SDK实现一个有限并发的服务端，给一些并发量低的组件使用，减少开发量

21:43分补充

• 压力部分可能来自自动建群（7.1上线）。

IM问题分析及解决方案

今天过来看了下代码,pc客户端代码实现上面。

代码走查结果：

1. 好友列表、群成员列表、群成员聊天的没有批量请求，只是单个请求（这个下周版本做成批量请求，客户端需要优化）。最近联系人、组织树、查找等模板都有批量请求。
2. 如果服务端返回错误，客户端不会重复去尝试。

对服务端压力描述：

1. 对关系服务有压力的点：就是好友列表模板（这个包含了关系信息）请求可以做成获取批量的。但是即使没有批量也不会有非常大的压力。
   因为只有登录成功的情况下，会根据这个登陆账号的好友数量来发单挑请求信息，这个其实只有一次，并且好友人数一般不会太多。
2. 请求B06群模板会对信息配置服务造成压力。但是从服务端设计上面看，是以模板+群id作为标识的；所以这个压力最终还是很大。

结论：

昨天仙钟发的文档上面的 这块，说PC端会失败后重复请求的结论,和我理解的不一致。原因如下：

1. 不是重复请求，从截图上面看是同一个人同一时间，对不同的人去进行B06模板请求（这个截图信息上只体现了suid表示的是请求者）；
2. 请求的是群B06的模板,而B06模板上面是没有好友关系配置的。从设计上对关系服务端不会有压力，会对信息配置服务有压力。

pc客户端改进：

1. 将好友列表、群成员列表、群成员聊天的做成批量请求。
2. 不再按照服务端设计的群模板+群号来请求以及对照客户端的缓存数据，要做降级处理。群信息模板在客户端数据结构上面去掉群号key。（按照目前的需求实现上，群模板只有vip，和群号无关）

关系认证服务端问题分析及解决方案

问题描述:

昨天出现服务器无响应的情况经过排查,是由于关系认证服务端数据库链接耗尽。无法处理新的数据库相关的请求。
下图为连接耗尽时的情况（此时关系认证服务端无法处理新的请求）:

Paste_Image.png

Paste_Image.png

过程分析：

在9点04分开始 请求量开始增大，最多增加到每秒接近40个请求，到9点34分 数据库连接池达到最大3000个。连接池耗尽。无法及时处理新的请求，造成请求阻塞和超时。
通过分析nginx日志和服务端的错误日志发现有如下问题。

1. 有较多的无效请求到关系认证服务端：这个问题需要业务方排查一下。

   
   
   

   Paste_Image.png

2. 请求量同周四和周五来看有明显的增加，在平均在一秒内收到的请求数峰值增加2-4倍。

   
   
   

   Paste_Image.png
3. 获取关系的接口业务逻辑较复杂，流程较长（响应时间在请求量大时会有明显的增加）在代码走查中会进行详细描述。

代码走查：

对关系认证接口实现逻辑进行走查结果如下:

1. 获取关系显示的流程（下图）

   
   
   

   Paste_Image.png
2. 代码中没有对关键信息部分进行缓存处理，每次请求均直接穿透到数据库，导致数据库压力 较大。
3. 业务流程较长，耗用的数据库资源较多。

整改初步方案

1、优化关系认证的业务逻辑，减少数据库查询。
2、关系认证增加关系信息的缓存，减少数据库访问，增加吞吐量。
3、用户信息话配置优化处理逻辑，避免因为某个数据源出现问题导致整个服务出现问题。