nginx tcp实现hbase thrift server负载均衡

不是爬虫!!    还是那句话,量大了,屁事都是大事 ~~~     过年到现在,工作的内容基本是调优,调优,调优….   从hbase替换成Elasticsearch,分布式任务的docker化,大量的拆解逻辑,改为MQ离线,时序任务队列,查询逻辑加cache层….. 


我想有不少人都会遇到thrift堵塞情况,我们这是经常的遇到,以前的解决的方法,提供了n组thrift 地址,然后系统启动的时候,每个进程占用一个thrift的连接地址….    这种情况貌似是不错的,但是还是会遇到坑爹的堵塞的情况….. 

这里提一下,我这里用的不是官方的python thrift库,是happybase库…  我这里也是推荐大家用happybase这个python库,真心不错… 


thrift的堵塞,让我很是郁闷….  因为ES本身用的haproxy做的负载均衡,就选用haproxy tcp模式做thrift调度,但是总是提示失败,具体的原因没有再去追究,就这么放弃了…. 这是前段时间的事情了,也就没有追究….  就是这么任性!

还是老样子,爬虫太刁了,标注下我的网站…

http://xiaorui.cc

http://xiaorui.cc


今天因为有大量的回溯任务要跑,所以上线了两个docker,专门来跑任务分析…. 中间是要和hbase做大量交互的,结果当然是堵塞了….  自己也懒得改写动态加载配置的逻辑,就临时做了一个nginx针对thrift server的负载均衡,用的模块是咱们中国人,taobao 姚伟斌 出的 nginx_tcp_proxy_module …   身为前运维的我,更加的倾向于用lvs来解决,但是问题来了。 我们这边的thrift server都是在hbase节点上配置的,不太方便做lvs的各种模式,所以我这边才会采用专业http代理服务器nginx做tcp的代理…


关于配置很是简单,我这里也不描述是如何安装及模块的patch的使用,网上有很多资料的..


下面是我的配置,我在nginx的tcp upstream里面加入了15个thrift server,效果还是不错的,但是这里需要说明的是,nginx做thrift代理貌似不能解决心跳的问题,如果你是get put数据,没啥问题,最少我这边是没有出现异常,都是OK的。  今天的项目也没有scan的逻辑,所以不敢确认在scan扫描的场景下行的通…    

看了作者的github里,有人针对类似的问题提问,具体的结论还是没有的。  其他项目有针对hbase scan扫描的逻辑,但是逻辑是用java写的,不用费劲的通过thrift….

经过测试,nginx针对thrift server是支持scan的操作的。。。 完全没有问题的,有一个点大家要注意,因为scan的时候,会消耗大量的时间,大家注意timeout的时间。 

这是效果的图片,会发现在8号的时候,性能一下子就上来了,最多的时候一分钟处理1万条数据。

好了,就先这样了…     我会继续跟踪 nginx做thrift server负载时,遇到的问题..   

2 Responses

  1. 去哪儿 2015年4月22日 / 上午8:13

    哎,写文章的风格太跳跃了

  2. 莱茵自由者 2015年4月12日 / 上午8:43

    一般没什么吧,我们均衡都用nginx

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">