1 概述
在历时2个月的不断优化过程中，将数据采集系统的处理能力(kafka一个topic)从2.5万提升到了10万，基本符合对下一次峰值的要求了。
所有日志中，其中广告日志和作品日志量是最大的，所以本次的优化也是针对这两块进行优化。
广告日志接口TPS从之前的不到1k/s，提升到现在的2.1w/s，提升了20倍。
作品日志接口TPS从之前的不到1k/s，提升到现在的1.4w/s，提升了13倍。
在数据采集的优化过程中，设计到很多地方，包含代码的优化，框架的优化，服务的优化，现在将对吞吐率的提高有明显左右的优化点记录下来。
2 面向对象
技术负责人，后端服务开发工程师
3 撰写时间
2020年04月03日
4 技术框架图
5 后端日志ETL程序LogServer的优化
广告日志接口TPS从之前的不到1k/s，提升到现在的2.1w/s，提升了将近20倍。
作品日志接口TPS从之前的不到1k/s，提升到现在的1.4w/s，提升了13倍。
1.广告日志接口的压测结果部分截图
2.作品日志接口的压测结果部分截图
以下TPS的提升是一个大概的值。
5.1 删除代码中不必要的打印日志
例如
System.out.println
System.out.println
logger.info
TPS 1k -> 3k
5.2 将logback.xml文件中的打印日志关闭
例如
TPS 3k -> 5k
5.3 对获取kafka相关的logger的代码优化
例如
之前的代码
public synchronized static Logger getLogger(String topic) {
Logger logger = loggers.get(topic);
try {
if (logger == null) {
logger = LoggerFactory.getLogger(topic);
loggers.put(topic, logger);
}
return logger;
}
优化后的代码
public static Logger getLogger(String topic) {
if (logger == null) {
synchronized(KafkaLoggerFactory.class){
if(logger == null){
logger = LoggerFactory.getLogger(topic);
loggers.put(topic, logger);
}
}
}
}
TPS 5k -> 9k
5.4 对流量广告的逻辑进行简化
之前的做法：
将广告数据当成普通的日志数据来处理，会经历所有的日志判断逻辑，最后经过验证，数据没问题，才会发送到kafka，整个逻辑链条比较长。
现在的做法：
先看代码
ip: String ip = request.getIp();
collection.put("ip", ip);
// 国家、地区、城市： collection.putAll(Constant.getRegionInfo(ip));
server_host: collection.put("srh", Constant.serverHost);
server_time: collection.put("s_t", System.currentTimeMillis());
if( "traffic_view".equals(collection.get("product")) ){
parseAdRecord(collection);
return Constant.RESPONSE_CODE_NORMAL;
}
...
public void parseAdRecord(Map collection){
try {
collection = Constant.clearAdCollection(collection);
log2kafka(Constant.eventTopic, JSONObject.toJSONString(collection));
} catch (Exception e) {
e.printStackTrace();
}
}
从上边的代码可以看出，将广告的逻辑单独处理进行处理，整个链路短了很多，大概总共分3步：
1 必须的公共字段处理
2 判断是否广告日志
3 将广告日志发送到kafka
TPS 9k -> 1.2w
5.5 对广告日志中的字段进行精简
将HDFS上广告日志总共的85个字段，现在精简到45个左右。这一步虽然对LogServer的吞吐率没有太多的提升。但是却可以将kafka的吞吐量提升将近一倍。
5.6 升级和简化依赖
- 首先将非必要的maven依赖全部删除掉了，使得依赖的数量从217个减少到了51个。
- 将maven依赖升级成比较新的版本。
- 有些依赖被删掉了，相关的类也做了调整，比如StringUtils.isEmpty()已经从spring类
org.springframework.util.StringUtils
调整成了commons-lang3包内的org.apache.commons.lang3.StringUtils
org.apache.commons
commons-lang3
3.10
6 服务器硬件层面
从之前的4核8G服务器迁移到8核16G的服务器上。
并且对服务器内核参数做了以下优化：
net.core.somaxconn = 10240
net.core.netdev_max_backlog =262144
net.ipv4.tcp_keepalive_intvl = 5
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 60999
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
1.2w -> 2w
7 对前端SDK的优化
经过对kafka的写入压测，当日志大小为1024字节的时候的QPS是2048的接近2倍。
1 减少前端上报日志字段数量，将暂时未用的的字段删掉。前端sdk上报的日志字段从71个删减到48个字段，减少了32%的字段数量。
2 不必要的日志不再上报，主要是通过修改前端日志上报的逻辑来实现。
8 对Nginx的优化：
对Nginx的优化主要有2个方面：
- 服务器层面的优化，如上述第5项
- Nginx本身的配置优化
- 增加了ip防刷的机制
8.1 Nginx一部分配置的优化。
worker_connections从20480上调到了102400，调大了5倍。调大之后nginx的吞吐量从2w/s,提升到3.5w/s，设置的时候最好结合业务和服务器的性能先做个压测。
worker_processes 默认是1，官方建议和cpu的核数相同，或者直接设置成auto。有人建议设置成cpu核数的2倍，从我的测试情况来看，不会有明显的提高，也可能是场景覆盖的有限。
worker_cpu_affinity Nginx默认没有开启利用多核cpu，通过worker_cpu_affinity开启nginx利用多核cpu，并将worker绑定到指定的线程上，以此来提高nginx的性能。
multi_accept 默认Nginx没有开启multi_accept。multi_accept可以让nginx worker进程尽可能多地接受请求。它的作用是让worker进程一次性地接受监听队列里的所有请求，然后处理。如果multi_accept的值设为off，那么worker进程必须一个一个地接受监听队列里的请求。
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
worker_connections 102400;
multi_accept on;
优化完之后QPS从1万左右上升到3.5万。
8.2 ip防刷
在conf/module/定义了一个blacklist文件:
map $http_x_forwarded_for $ip_action{
default 0;
~123\.123\.29 1;
}
在nginx.conf中增加ip过滤的配置:
location /log.gif {
if ($ip_action) {
return 403;
}
proxy_pass http://big-da/log-server/push;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 128k;
client_body_buffer_size 32k;
proxy_connect_timeout 5;
proxy_send_timeout 5;
proxy_read_timeout 5;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
如果是黑名单中的ip，则直接拒绝请求。
9 对kafka的优化
1.将所有重要topic的Replication从1改成了2，这样保证在kafka有1个节点故障的时候，topic也能正常工作。
2.为每个节点的kafka设置了独用的SSD硬盘。
3.topic分区的分区数量根据业务需求设置，我们设置了6个分区。
3.在producer端写kafka的使用使用snappy压缩格式
4.在producer端合理设置batch.size
batch.size用来控制producer在将消息发送到kafka之前需要攒够多少自己的数据。默认是16kB，经过测试，在32kB的情况下，吞吐量和压测都在接受的接受的范围内。
5.在producer端合理设置linger.ms
默认没有设置，只要有数据就会立即发送。可以将linger.ms设置为100，在流量比较大的时候，可以减少发送请求的数量，从而提高吞吐量。
6.升级版本，将kafka从0.10升到了2.2.1
作者：易企秀工程师 Peace -> 个人主页