通过一年多时间的使用，统一日志系统，已经接入公司前台，在20个节点，几十万用户，数百亿交易额的大压力下，仅仅使用了一个普通的服务器，承受住了严峻的考验，在公司今年更宏大的目标，也是为了给大数据组提供更加全面信息的需求下，公司所有项目，要接入ULOG系统，主要包含管理后台，wap，app等，流量一下达到一个峰值，flume的瓶颈凸显出来，在解决的过程中，对flume的了解以及性能调优，有了更深入的认识，接下的文章，会比较紧凑，请大家紧随脚步，看看我们这几周的调优结果。

        大家还记得以前的ulog部署方案吗？我们通过一张图来回忆一下：

专栏地址：大数据下的日志

这是一个最初的方案，这个方案，马上面临了以下问题：

1，flume使用memory作为channel经常丢失数据

2，两个节点分担压力有限

基于此，我们进行了第一次优化，加入flume以file为基础的负载均衡，大家看效果图：

大家看flume负载均衡端的配置文件：

这样的初始方式，我们发现性能问题被解决了一小部分，但是仅仅是缓解，我们还需要优化，以便适应当下的需求，通过论坛，我们知道，sinkgroups，是单线程，意味着，我们启动的sink是一个线程在读数据，而如果删除sinkgroups，就是为每个sink启动一个线程，会优化文件的消费速度，大家看第二次的优化：

现象：

        我们去除sinkgroups后，虽然有些变化，但是数据依然有很大的延迟，随着时间推移，还是会达到性能瓶颈，具体，我们就要在下篇博客中介绍，如何从整体结构上优化数据传输效率。

总结：

        有时的负载均衡，也会成为性能瓶颈，在分配端，我们也要看，那种效率更高，效果更好，这样，我们就能找到合适的点，平衡我们的需求和性能。