zookeeper metamorphosis

zookeeper 和 metamorphosis 研究完成

目前搭建的环境是在 2台 ubuntu server 64下 简称 USA USB ... 

USA下 安装了 server1 server3 目录 分别是两个 zookeeper   metamorphosis消息中间件

USB下 安装了 server2 目录 一个zookeeper     metamorphosis消息中间件

3个zookeeper 形成一个集群   metamorphosis也是通过 zookeeper形成集群

zookeeper 是2n+1 可以容许n台机器故障

metamorphosis 单台机器故障不引想使用

第一阶段 完成的是 zk集群的配置 各种故障测试 和 不同机器数据获取的测试

第二阶段 完成的是 metamorphosis单机的正确 消息传递测试 和 集群配置 及单点故障测试

第三阶段 完成的是 metamorphosis收发消息的细节研究 

brokerId是metamorphosis集群中的唯一标识 第一台 我们的唯一标识是1

metamorphosis 的 topic 会发布到 zk的 /meta/brokers/topics 目录下 并且每个消息可以有多个区

被命名为 0,0-m 如果有另一台集群机器  brokerId 为 1 那么 消息为 0，0-m，1，1-m 

也就是说两个消息中间件发布同一个消息名称的话 会被认为是要做一个 消息集群

在客户端发布消息的时候 会按照 0-1 0-2 0-3...1-1...1-m的 顺序区间去发布（可以自定义） 发布者发布的消息在服务端写入磁盘被认为成功返回成功消息（不一定落到磁盘设备）

客户端消费者采取的pull方式 这种方式和寻常的消费者监听不一样 而是主动的定时去查看 zk下的信息 并拉下来（落到磁盘设备的消息）

上面就产生了一个 我看了很久的问题 就是 metamorphosis默认设置是 1000条 强制写入磁盘设备一次 或者10秒强制写入 一次 磁盘设备 导致我发布者发布消息并成功很快 接收消息却总是延迟

后来邮件咨询了下 淘宝团队的工程师 才知道以上原因 （应该是淘宝的队列中总是瞬间有很多消息 所以默认都设置的比较注重吞吐量）

这里就有一个问题 pull方式的消息接收可能比较适合 并发处理量特别大的系统 对小系统可能 却消耗比较大

发布者的发布负载均衡策略是 分区轮询

消费者的消费负载均衡策略是 消费者数目 大于 分区时 消费者1对1分区 多余的消费者闲着  消费者小于分区时 有部分消费者 可能要1对n分区