不是爬虫！！    还是那句话，量大了，屁事都是大事 ~~~     过年到现在，工作的内容基本是调优，调优，调优….   从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的时间。 

[ruifengyun@bj-buzz-docker05 ~]docker exec -it nginx tail -n 25 /usr/local/nginx/conf/nginx.conf
    }

}
tcp {
	access_log logs/tcp_access.log buffer=2K;
    timeout 1d;
    proxy_read_timeout 10d;
    proxy_send_timeout 10d;
    proxy_connect_timeout 300;
    upstream oracle {
        server xx:9090;
        server xx:9090;
        #我这里差不多贴了15个hbase的链接
        check interval=3000 rise=2 fall=5 timeout=10000;
    }
    server {
        listen 9090;
        proxy_pass oracle;
        so_keepalive on;
	access_log logs/tcp_access.log buffer=2K;
        tcp_nodelay on;
    }
}
[ruifengyun@bj-buzz-docker05 ~]

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

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

---

大家觉得文章对你有些作用！ 如果想赏钱，可以用微信扫描下面的二维码，感谢!
另外再次标注博客原地址  xiaorui.cc