flare的今生 挖坑 填坑小续...

ps:百度你咋还不死, 不信你搜索一个flare和google比一下,

ps2:政府真是蛋疼,翻个墙很累。

吸一口气,贴一张图,翻过墙写的图片传不上去,不知51cto咋地了?

如果想要玩懂flare估计要懂memcache 废话不多少,不服你去百度。

地址: http://labs.gree.jp/Top/OpenSource/Flare/Document/Installation-en.html

wget ‘http://labs.gree.jp/data/source/flare-1.0.11.tgz‘

tar zxvf flare-1.0.11.tgz

cd flare-1.0.11

./configure --with-boost=/usr/local/boost --with-tokyocabinet=/usr/local/tokyocabinet --prefix=/usr/local/flare

make

make install

配置:

mkdir /usr/local/flare/etc

cp etc/* /usr/local/flare/etc/

启动:

/usr/local/flare/bin/flarei --daemonize  -f /usr/local/flare/etc/flarei.conf

概念

Flare有几个概念,需要理解

index server

这是索引服务器,用于控制node server的状态

注意,client并不直接和index server进行交互。

node server

这是实际存储节点. node有3种role:

master/slave/proxy

master是主节点,slave是分流节点,用于同步复制master

proxy则将client的请求转发到当前合适的节点(包括master/slave)。

有的人不太理解为什么要用proxy,是否多此一举,而实际测试表明,

通过proxy转发的请求的确要比直接connect到实际节点速度差很多。

这是因为,flare是一个集群,其中的node server是可以动态添加,删除的。

当某个node down后,index server会检测到,并标志其state为down。

此外,master 支持partition,因此通过proxy节点,client无需处理这些复杂问题。

根据作者的建议, proxy node应该和client本地运行,这样可以减少多余的tcp请求。

下面是我写的一个脚本,用于搭建一个典型的测试场景:

1个index server

2个master node,启用partition

1个slave,启用balance

由于flare把ip:port作为一个node,因此只需要1个ip,不同的port就可以快速实现测试需要的环境。

$./start_flare.sh

配置文件开始:

#!/bin/sh

#启动index server,监听 127.0.0.1:12120

flarei=‘/usr/local/flare/bin/flarei‘

flarei_config=‘/usr/local/flare/etc/flarei.conf‘

flared=‘/usr/local/flare/bin/flared‘

flared_config=‘/usr/local/flare/etc/flared.conf‘

data=‘/data/httpd/flare‘

cmd="$flarei --daemonize -f $flarei_config"

echo "$cmd"

$cmd

sleep 0.5

#proxy

cmd="$flared --daemonize --data-dir $data/d0 --index-server-name 127.0.0.1 --index-server-port 12120 --server-name 127.0.0.1 --server-port 12121"

echo $cmd

$cmd

sleep 0.5

#master1 node

cmd="$flared --daemonize --data-dir $data/d1 --index-server-name 127.0.0.1 --index-server-port 12120 --server-name 127.0.0.1 --server-port 12122"

echo  $cmd

$cmd

sleep 0.5

#slave node

cmd="$flared --daemonize --data-dir $data/d2 --index-server-name 127.0.0.1 --index-server-port 12120 --server-name 127.0.0.1 --server-port 12123"

echo $cmd

$cmd

sleep 0.5

#master2

cmd="$flared --daemonize --data-dir $data/d3 --index-server-name 127.0.0.1 --index-server-port 12120 --server-name 127.0.0.1 --server-port 12124"

echo $cmd

$cmd

echo "waiting dameon startup…"

sleep 3

echo "set nodes role…."

#exit 1

# 当某个node加入时,默认是proxy role,因此需要修改这些role

# 通过telnet到index server,可以执行这些命令,我们在脚本中可以使用

# nc来自动执行

# node role的命令格式:

# node role server port master|slave|proxy balance partiion

echo "node role 127.0.0.1 12122 master 1 0"|nc 127.0.0.1 12120

# 设置为slave, balance 为2,给于2倍read权重

echo "node role 127.0.0.1 12123 slave 2 0"|nc 127.0.0.1 12120

# 第2个master node,将partition设置为1,表明这是第2个partion,允许

#将部分数据从原来的master 同步过来

echo "node role 127.0.0.1 12124 master 1 1"|nc 127.0.0.1 12120

sleep 2

echo "stats nodes"|nc 127.0.0.1 12120

配置文件结束

时间: 2024-10-05 21:13:20

flare的今生 挖坑 填坑小续...的相关文章

微信JSSDK分享--挖坑填坑之小结

最近参与微信服务号小项目的开发,关于微信分享,我是只知其功能,并没深入了解其中的弯弯道道.虽然项目中不是我负责微信分享这一块(因为我也不太会),但是团队在这个功能上,那可是说多了都是泪,耗费了超级多的时间:一句话就是加班加点的挖坑,制造解决不了的bug,然后加班加点的找问题所在,去解决.主要是我们对于微信分享这块的了解并不深入,没想到的太多. 当时一直分享不成功,我们前端一直以为是我们的js代码写的有问题,谁知道最大的问题是配置问题: 一.不再同一个服务号. 因为微信端,为了识别用户,每个用户针

WebView填坑——小功能篇

这两天负责修改了几个关于在webview中打开公司移动站的bug.本身不是很难解,网上查查都有,但是也有必要记录下来作为备忘. Webview中上传文件 这里的效果类似在pc端上传文件效果,点击打开一个文件选择器,上传文件图片之类的. openFileChooser()方法的重载是因为在不同系统中调用的方法参数不一样,具体看注释. ValueCallback<Uri> mUploadMessage作为成员变量的目的是我们要在打开的系统文件选择器finish()后在onActivityResul

传统行业转型微服务的挖坑与填坑

原文:传统行业转型微服务的挖坑与填坑 一.微服务落地是一个复杂问题,牵扯到IT架构,应用架构,组织架构多个方面 在多家传统行业的企业走访和落地了微服务之后,发现落地微服务是一个非常复杂的问题,甚至都不完全是技术问题. 当时想微服务既然是改造应用,做微服务治理,类似注册,发现,熔断,限流,降级等,当然应该从应用开发组切入,一般一开始聊的会比较开心,从单体架构,到SOA,再到微服务架构,从Dubbo聊到SpringCloud,但是必然会涉及到微服务的发布和运维问题,涉及到DevOps和容器层,这些都

一名Android开发者的微信小程序填坑之路(2)

前言 上一篇是九月二十七日写的,而这一篇我动笔的时间是十月十日(特殊的日子),中间相隔十三天--当然是因为国庆节.说老实话,这十三天里面我都没有碰和小程序有关的东西--毕竟学习小程序的开发也只是起于兴趣,而平时的工作并不会涉及与其相关的东西--但是在这十三天里,我能明显的感受到小程序热正在逐渐的消退,或者说大家正在逐渐以一种较为平和的姿态接受它的存在,其实这是一件好事.期待公测的到来. 接下来我就直接进入正题了,另外,文末我想和大家分享一下我的国庆节. PS:这篇文章是接着上一篇文章 一名And

[转]前人挖坑,后人填坑—如何把那些bug挖掘出来

当我们放下一个项目转投下一个时,手头的东西就要转交给他人处理,或者..不再有人处理,可代码还在那里,搞不好你就引用了别人的东西,保不准哪天别人的代码里就爆出了个大 bug,当然这里的“别人”也可能是 你!我们既不希望自己是受害者,更不希望自己是施害者. 写代码不免出点bug,没有人可以保证自己写的代码不出问题,而那些没有被挖掘出来的bug,便成了后来者哭笑不得的坑... 这段时间公司全面 https 改造,涉及到域名的迁移,域名的迁移不是 nginx 做个映射就完事儿了,还有各种代码的去 sch

小程序项目之再填坑

简诉 是的,真的,你没有看错,我就是上次那个加薪的,但是现在问题来了,最近又搞了个小程序的需求,又填了不少坑,其中的辛酸就不说了,说多了都是泪,此处省略三千字 ---^--,说重点吧,反正最后就是差点这让老板叫走人了,你说优秀不优秀-. 前段时间网上一直说的"<你可以骂那些中年人,尤其是有车有房的-->",虽然我没有房.也没有车,但也坚决不做那个可以随便骂的中年人(人到中年不如狗??),不存在的啦,这个仇宝宝已经记下了,先分享一下最近遇到的几个坑吧. -- 我是首席填坑官-

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程

Maybe 这个问题很简单,因为解决方法是非常简单,但填坑过程会把人逼疯,在阿里云ONS工作人员.同事和朋友的协助下,经过一天的调试和瞎捣鼓,终于解决了这个坑,把问题记下来,也许更多人在碰到类似问题的时候,会开放思路.当然不得不说,Ons的.NET接口还很不完善,甚至没有独立在Windos 2008/2012服务器测试过,希望官方加把力. 1.阿里云ONS介绍 ONS(Open Notification Service)即开放消息服务,是基于阿里开源消息中间件MetaQ(RocketMQ)打造的

初涉node.js做微信测试公众号一路填坑顺便发现个有趣的其他漏洞

[微信测试公众号] 半年前耍着玩搭起来的“微信简历”,是LAMP版的,很皮毛. 微信的官方文档在这 http://mp.weixin.qq.com/wiki/index.php 1.获取access token 2.自定义菜单创建,直接在调试工具上做了 http://mp.weixin.qq.com/debug 3.接入指南(接入自己的网站) 4.接收微信消息,判断消息类型,判断消息关键字(比如来自哪个按钮),响应消息 这里有个小坑,不同类型的消息数据结构略有不同,判空最好做细致点. [V2.0

踩坑(Running)填坑(ZSSURE):DevExpress的XtraTabControl、Telerik的OpenAccessContext以及StarUML

题记: 今天好友在朋友圈分享了一篇有深度的好文"请鼓励你的孩子做个幸福普通人",文章略显长,细细品读下来感触颇多.加之最近天天看着小外甥大睿睿的一步步的成长,已渐渐远离年轻稚嫩.走向成熟稳重的我对学习有了新的认识,回想起自己的成长过程,经验和技能并非是父母手把手教导的,反而是他们给我营造的"自由.开放.甚至略显放纵"的环境.他们以身作则的行动,让我从中体会.感悟出了所有的点点滴滴. 说到现在从事的软件研发工作,想想同学中毕业鲜有留下来做技术的(姑且认为IT民工也属于