在运维日志分发任务的时候，经常碰到一些突发性的数据量增大，导致分发资源不足，最后数据延迟了。

之前，只能依赖监控Kafka的消息积压情况，如果积压非常多，就增加任务的副本数或者增大任务的

资源规格（分配更多的cpu和内存）。增加多少副本或者资源只能凭经验去判断，无法量化，每个任务的

数据单条大小是不一样的，连接的HDFS集群也是不一样的，所处的网络环境也会有差异，这些变量都

导致了无法用一个固定的指标衡量或者预警。

自旋时间

经过一段时间的思考和测试我们选择了一个叫做自旋时间的指标来做衡量。

我们的任务中使用了ringbuffer作为生产消费模型中的缓冲队列，在高资源规格的任务中，会有多个

并行的ringbuffer。之前我的blog提到过，我们在选择哪一条channel时有一个复合策略，就是roundrobin

+余量最大。当source下游的所有ringbuffer都处于full状态时，source就一直处于wait状态（自旋），

这个自旋的时间被我们统计了下来，通过nanotime的delta来统计。如果每分钟里自旋的累加时间超过5s，

我们就会认为该任务的消费能力低于生产能力，需要扩大资源规格，具体含义就是写HDFS的性能低于拉

kafka的性能。在我们的测试中，3个channel同时写HDFS，能超过单线程拉kafka的速度。

告警的策略

有一些kafka的数据是定期上报的，所以会存在短期数据量很大的情况，如果我们设置的报警策略非常敏感

的话，会导致频繁告警，所以经过一段时间的微调，我们最终选定15分钟内有10次超过5s的自旋，就任务

该任务需要增加资源规格了。

副本与资源规格

需要注意的是增加副本和增加资源规格其实都能达到降低任务繁忙度的目的，但是增加资源规格从整体

上来说是更为经济的选择，增加副本还依赖于kafka的partition数量。

在运维这批任务的时候，我们会有一个基本的原则：

1、副本数不超过kafka分区数的二分之一，保证至少还有一倍的临时扩容余量。

2、如果是单副本任务，优先增加副本。

3、副本数超过5个的话，尽量扩资源规格。

4、如果单个任务平均每秒处理的数据超过50m，则选择增加副本数量。

另外，这个自旋时间并不能替代数据延迟的告警，只是用来衡量单任务是否达到性能瓶颈。

未来

这些扩容的规则还在慢慢积累，不断的在增加Metric的丰富度，希望未来可以通过对metric的实时处理，

得到运营决策，将系统的运营工作自动化起来。