客服服务的性能优化之路（一）

客服服务的性能优化之路（一）

目前，负责了某客服产品的后台开发。该项目是基于网易云信开发的一款即时通讯的产品，提供人工客服接待，机器人智能接待，表单收集，访客轨迹搜集等功能。
由于本产品是部署到三方的官网来提供服务的，所以三方官网的访问量就是我的用户量，随着大客户的接入，在高峰期已经出现了接口响应缓慢的现象，以此，记录一下我的优化过程。

背景

该客服产品呢，其实属于快速开发的一个产品，由于先前需要尽快的实现功能，就导致设计上存在很多的不足，在高峰期已经出现了接口响应缓慢，不断的出现504的服务异常提示。

排查

1. 接口轮询 ，由于要做一个智能弹出的功能，以及需要搜集到访客的页面停留时长和浏览轨迹等，设计了心跳接口的轮询请求，此后还增加了对客服入口状态的接口轮询请求，极大的加大服务器压力；
2. 安全认证，没有对开放接口做任何的认证校验，有的接口甚至没有校验任何id，就直接写入数据库，此举导致后续的一些统计逻辑处理大量的报错；
3. 数据读取，开发接口的逻辑内部最终都落到了数据库层面，且有不少的数据是从主数据库进行的读取，数据库的性能也严重受到影响；
4. 心跳数据记录，直接将数据写入数据库，5秒一次的心跳在庞大的用户量情况下，写入量急剧上升。且心跳数据仅是在统计停留时长的时候才会使用到；
5. 逻辑结构，逻辑处理层级太深，过于复杂，且嵌入了一次又一次的数据库查询，包括循环查，重复查的现象。
6. 服务资源，只有一台服务器部署，没办法，谁让这款产品不被重视呢。

思路

1. 当初用接口轮询的原因，就是因为无法通知到前端进行指定的动作，其实是该引入socket进行通讯的，由服务端主动推送消息。该方案后续进行
2. 安全认证，因为每个开发接口都是依赖渠道进行信息查询的，所以可以要求每个接口请求都附带渠道的id，服务端首先对渠道进行校验，不符合的直接响应错误码，连续请求错误的，应该要将该cookie拉黑若干时间，若单个ip在一定时间内达到错误上限，拉黑该ip若干时间
3. 数据读取方面，对外接口里除了心跳接口，其余的多数还是数据读取的请求，根据数据的二八原则，我们可以将一些变更频率小，量级可预见的一些数据缓存下来，来减少数据库的压力。
4. 心跳数据，这种庞大且利用率不高的数据，其特征是按访客记录，而且系统的统计时间节点是按小时进行的，所以干脆按访客id和时间写入文件吧。以文件的形式去检索统计，可以考虑在数据库里保存每个访客的心跳数据路径。
5. 逻辑结构需要重构，没啥好说的，到时具体再分析吧。
6. 服务资源，目前已申请加多一个服务，但主要原因还是以上的几点吧

总结

思路大概这么多，总的来说就是先尽量利用缓存对热数据的读取进行压力的分担，后续有好的想法再补充。