分布式服务调用问题处理总结

push发送延迟

业务特点：

运营push发送数量较大，发送时间密集，同一时间段调用baixin发送push的数量几十万上百万不等。

问题描述：

之前我们的push发送使用两个项目实现，分别是：

• push项目：接收和处理push信息，调用baixin项目进行push发送
• baixin项目：负责接收和发送push信息，将push分发给IOS和Android客户端用户

在运营push业务里，push项目使用线程数量为200的固定线程池发送push信息给baixin项目，发送很快，五分钟发送五十万左右的push，但是用户收到push信息很慢，查询baixin项目的日志发现，大量push信息阻塞在了baixin项目的线程池队列中。

原因——线程池太小

下游baixin项目的发送push信息线程池太小。

解决办法——扩大线程池：

将baixin项目线程池由100扩为500后，线程池处理push发送的速度明显加快，线程池队列堆积减少。

历史解决办法——两个简单限流措施：

• 限制运营上传接收push的用户id文件为2M，一个文件约为20万用户id，并给push发送时间设置间隔，每次push的发送时间间隔为10分钟。
• 发送10万push，使发送push的方法主线程睡眠十秒。

经验总结：

分布式环境中，一个应用调用另一个应用同时大批量集中处理任务时，要考虑另一个应用的处理能力，在采用线程池提高系统并发能力的同时，必要时候采取限流等措施保证其他应用的可用性。

磁盘满导致系统调用变慢

问题描述：

内网测试发送十万动态push，速度突然变慢，主要是磁盘IO影响。查看日志发现，push调用pushCenter正常，但是会出现SocketTimeOutException响应异常，发送速度很慢，二十分钟发送了两万条数据，正常10分钟处理十万数据。

原因：

pushCenter所在服务器的磁盘满了。

解决办法：

1、top命令查看系统负载： push服务器负载正常，pushCenter服务器5、10、15分钟系统负载数值在2.0左右，CPU空闲90%，内存使用不大。

top c M

输入图片说明

2、查找最大文件：

查看pushCenter服务器磁盘空间，发现磁盘空间已满：

df -h

怀疑是日志文件导致的，接着去日志目录查找最大的日志文件：

find / -type f -name "*log*" | xargs ls -lSh | more

输入图片说明

找到最大的日志文件后，使用rm命令进行删除。push调用pushCenter的速度变快。

经验总结：

分布式环境中，一个应用调用另一个应用变慢，要同时查看两台服务器的负载，Linux系统性能一般受CPU、内存、磁盘、网络四个指标影响，任何一项指标负载高都有可能导致服务器处理请求的速度变慢，可以借助于top、iotop、netstat命令查看这四个指标的负载。参考链接：Linux性能监测与优化命令。