Archive for September, 2014

作者:AngryFox 分类: Uncategorized September 2nd, 2014 暂无评论

安装phabricator时报错
>>> UNRECOVERABLE FATAL ERROR <<< Call to undefined function fnmatch() /opt/libphutil/src/filesystem/FileFinder.php:118 ┻━┻ ︵ ¯\_(ツ)_/¯ ︵ ┻━┻>>> UNRECOVERABLE FATAL ERROR <<< Call to undefined function fnmatch() /opt/libphutil/src/filesystem/FileFinder.php:118 ┻━┻ ︵ ¯\_(ツ)_/¯ ︵ ┻━┻

http://cn2.php.net/fnmatch

在centos6,php 5.3.17上这个函数不能用
浪费了好长时间查错
换成 preg_match

http://cn2.php.net/manual/zh/function.preg-match.php

定义和用法
fnmatch() 函数根据指定的模式来匹配文件名或字符串。
语法
fnmatch(pattern,string,flags)
参数 描述
pattern 必需。规定要检索的模式。
string 必需。规定要检查的字符串或文件。
flags 可选。
说明
此函数对于文件名尤其有用,但也可以用于普通的字符串。普通用户可能习惯于 shell 模式或者至少其中最简单的形式 ‘?’ 和 ‘*’ 通配符,因此使用 fnmatch() 来代替 ereg() 或者 preg_match() 来进行前端搜索表达式输入对于非程序员用户更加方便。

作者:AngryFox 分类: Uncategorized September 1st, 2014 暂无评论

整个系统运行的顺序:
1.启动zookeeper的server
2.启动kafka的server
3.Producer如果生产了数据,会先通过zookeeper找到broker,然后将数据存放进broker
4.Consumer如果要消费数据,会先通过zookeeper找对应的broker,然后消费。

Kafka的瓶颈有两个,一个是网卡流量,一个是内存。网卡比较好理解,
对于内存的瓶颈,那是由于从Kafka读取数据,几乎全部都是从Linux buffer中获取的,所以我们看Kafka的机器,用sar是看不到磁盘读的。如下图
一旦进的流量超过一定值的时候,会出现磁盘读飙升,造成Kafka吞吐急剧下降。这个问题是去年419发现的,因为当时Kafka集群有32G内存的机器,也有64G内存的机器,32G的机器会比64G的机器率先出现问题。所以判断时buffer没法buffer住所有的读热点,读hit到磁盘,造成磁盘读上升,故而影响磁盘写,如此造成Kafka雪崩。

producer不支持写zookeeper ip,一定要在程序中写kafka broker ip。这样无法动态扩展机器了。有一个折衷的方案是在程序中连接zk,从zk中获取broker ip。
fail over支持不好。比如集群有2个机器——broker0和broker1,1个topic,其中partition0在broker0上,partition1在broker1上。当broker1挂了以后,如果还有往partition1上发送数据,那么这次发送会不成功。这种问题,如何解决呢?
当1个broker挂了以后,这个broker上的partition全部不可用,那么发送到这些partition上的message都会报错。
这些问题很影响kafka的fail over

Kafka之所以和其它绝大多数信息系统不同,是因为下面这几个为数不多的比较重要的设计决策:
Kafka在设计之时为就将持久化消息作为通常的使用情况进行了考虑。
主要的设计约束是吞吐量而不是功能。
有关哪些数据已经被使用了的状态信息保存为数据使用者(consumer)的一部分,而不是保存在服务器之上。
Kafka是一种显式的分布式系统。它假设,数据生产者(producer)、代理(brokers)和数据使用者(consumer)分散于多台机器之上

kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.
消息被路由到哪个partition上,有producer客户端决定.比如可以采用”random”"key-hash”"轮询”等,如果一个topic中有多个partitions,那么在producer端实现”消息均衡分发”是必要的.
每个分区至少有一个leader和0个或者多个的followers,所有的读写在leader分区进行

一:kafka集群8台机器,3台zookpeer
二:客户端生成者
每个生产者生成一个topic,自动分成8个partions,每次发送的时候随机发送到其中一个partions
(应用分开各自topic,便于管理知道哪个应用的
8个parttion官方推荐,8个为了以后有多个consumer,随机选择partions的负载均衡)
三:消费者:
每个consumer消费若干个topic,map(app,topic)由管理端管理
以后加一个consumer,也只是在管理端配置其消费的topic

https://github.com/nmred/kafka-php

http://kafka.apache.org/