]flume高并发优化——（1）load

原文:http://blog.csdn.net/xvshu/article/details/51243332

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

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

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

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

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

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

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

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

[html] view plaincopy

balance.sources = source1
balance.sinks = k1 k2
balance.channels = channel1
# Describe/configure source1
balance.sources.source1.type = avro
balance.sources.source1.bind = 192.168.10.83
balance.sources.source1.port = 12300
#define sinkgroups
balance.sinkgroups=g1
balance.sinkgroups.g1.sinks=k1 k2
balance.sinkgroups.g1.processor.type=load_balance
balance.sinkgroups.g1.processor.backoff=true
balance.sinkgroups.g1.processor.selector=round_robin
#define the sink 1
balance.sinks.k1.type=avro
balance.sinks.k1.hostname=192.168.10.83
balance.sinks.k1.port=12301
#define the sink 2
balance.sinks.k2.type=avro
balance.sinks.k2.hostname=192.168.10.84
balance.sinks.k2.port=12302
# Use a channel which buffers events in memory
# Use a channel which buffers events in memory
balance.channels.channel1.type = file
balance.channels.channel1.checkpointDir = /export/data/flume/flume-1.6.0/dataeckPoint/balance
balance.channels.channel1.useDualCheckpoints = true
balance.channels.channel1.backupCheckpointDir = /export/data/flume/flume-1.6.0/data/bakcheckPoint/balance
balance.channels.channel1.dataDirs =/export/data/flume/flume-1.6.0/data/balance
balance.channels.channel1.transactionCapacity = 10000
balance.channels.channel1.checkpointInterval = 30000
balance.channels.channel1.maxFileSize = 2146435071
balance.channels.channel1.minimumRequiredSpace = 524288000
balance.channels.channel1.capacity = 1000000
balance.channels.channel1.keep-alive=3
# Bind the source and sink to the channel
balance.sources.source1.channels = channel1
balance.sinks.k1.channel = channel1
balance.sinks.k2.channel=channel1

优化：

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

[html] view plaincopy

balance.sources = source1
balance.sinks = k1 k2
balance.channels = channel1
# Describe/configure source1
balance.sources.source1.type = avro
balance.sources.source1.bind = 192.168.10.83
balance.sources.source1.port = 12300
#define the sink 1
balance.sinks.k1.type=avro
balance.sinks.k1.hostname=192.168.10.83
balance.sinks.k1.port=12301
#define the sink 2
balance.sinks.k2.type=avro
balance.sinks.k2.hostname=192.168.10.84
balance.sinks.k2.port=12302
# Use a channel which buffers events in memory
# Use a channel which buffers events in memory
balance.channels.channel1.type = file
balance.channels.channel1.checkpointDir = /export/data/flume/flume-1.6.0/dataeckPoint/balance
balance.channels.channel1.useDualCheckpoints = true
balance.channels.channel1.backupCheckpointDir = /export/data/flume/flume-1.6.0/data/bakcheckPoint/balance
balance.channels.channel1.dataDirs =/export/data/flume/flume-1.6.0/data/balance
balance.channels.channel1.transactionCapacity = 10000
balance.channels.channel1.checkpointInterval = 30000
balance.channels.channel1.maxFileSize = 2146435071
balance.channels.channel1.minimumRequiredSpace = 524288000
balance.channels.channel1.capacity = 1000000
balance.channels.channel1.keep-alive=3
# Bind the source and sink to the channel
balance.sources.source1.channels = channel1
balance.sinks.k1.channel = channel1
balance.sinks.k2.channel=channel1

现象：

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

总结：

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

]flume高并发优化——（1）load_balance相关推荐

flume高并发优化——（9）配置文件交由zookeeper管理
我们都希望,配置文件是从一个服务引出,然后客户端监听服务端变化,实时重启自身加载最新配置,这样,我们就不用维护每个独立的客户端配置,更新也变得非常简单,而flume,显然意识到了这一个巨大的实惠,他是 ...
每秒上千订单场景下的分布式锁高并发优化实践！
本文授权转自石杉的架构笔记背景引入首先,我们一起来看看这个问题的背景? 前段时间有个朋友在外面面试,然后有一天找我聊说:有一个国内不错的电商公司,面试官给他出了一个场景题: 假如下单时,用分布式锁 ...
Java架构-每秒上千订单场景下的分布式锁高并发优化实践！
"上一篇文章我们聊了聊Redisson这个开源框架对Redis分布式锁的实现原理,如果有不了解的兄弟可以看一下:<拜托,面试请不要再问我Redis分布式锁实现原理>. 今天就给大 ...
网易高并发优化 | 公开课-02
网易严选中的高并发优化 (一)单机系统缓存优化 1.背景导入在单机情况下,CSD模型如果出现慢查询一般会把问题归结到数据库 CSD模型: 实际操作发现:当有2KW级别数据层查询是,统计总行数约1s, ...
抽奖活动的高可用、高并发优化
这几年工作中做过不少营销活动,这里以抽奖活动为例,讨论一下如何设计出一个高可用.高并发的营销系统. 高可用.高并发架构的核心是分流和限流.系统架构时,应根据每一种营销活动的场景与特性,制定不同的分流. ...
Seckill系统高并发优化
绝大多数秒杀系统都需要实现高并发,这样就必须在原来的项目基础上进行优化.简单的优化很有可能就会很大地提高系统的并发性能,但是这些优化往往是系统开发人员很少注意的,或者直接被人们忽略.因此要成为一个出色 ...
Java高并发秒杀API(四)之高并发优化
Java高并发秒杀API(四)之高并发优化 1. 高并发优化分析关于并发并发性上不去是因为当多个线程同时访问一行数据时,产生了事务,因此产生写锁,每当一个获取了事务的线程把锁释放,另一个排队线程才 ...
MySQL的性能优化及自动化运维实践与Mysql高并发优化
首先,我们来看看DBA的具体工作,我觉得 DBA 真的很忙:备份和恢复.监控状态.集群搭建与扩容.数据迁移和高可用,这是我们 DBA 的功能. 了解这些功能以后要对体系结构有更加深入的了解,你不知道怎 ...
用分布式锁来防止库存超卖，但是是每秒上千订单的高并发场景，如何对分布式锁进行高并发优化来应对这个场景？
用分布式锁来防止库存超卖,但是是每秒上千订单的高并发场景,如何对分布式锁进行高并发优化来应对这个场景? 转载 codeing_doc 最后发布于2018-11-23 09:44:41 阅读数 1073 ...
[php]如何做到高并发优化
在实际的开发过程中我们遇到过各种各样的活动,但像用户流量较大的平台就需要考虑高并发的问题,但是如何去解决呢?我总结了几种解决方案,欢迎大家指正! 一.什么是PV/UV/QPS? PV:页面访问量,即P ...

]flume高并发优化——（1）load_balance

]flume高并发优化——（1）load_balance相关推荐

最新文章

热门文章