zookeeper3.3.3源码分析(二)FastLeader选举算法

如何在zookeeper集群中选举出一个leader,zookeeper使用了三种算法,具体使用哪种算法,在配置文件中是可以配置的,对应的配置项是”electionAlg”,其中1对应的是LeaderElection算法,2对应的是AuthFastLeaderElection算法,3对应的是FastLeaderElection算法.默认使用FastLeaderElection算法.其他两种算法我没有研究过,就不多说了.

要理解这个算法,最好需要一些paxos算法的理论基础.

1) 数据恢复阶段

zookeeper3.3.3源码分析(一)工作原理概述

阅读zookeeper代码一段时间(注:是很长一段时间,断断续续得有半年了吧?)之后,我要开始将一些积累下来的东西写下来了,鉴于我的java是这个过程中现学的,难免有说的不对的地方,所以如果有的话,请指教.

阅读时参考的版本是3.3.3.

简单的说一下zookeeper工作的过程,如果对这个过程还不太清楚,或者说对它如何使用等不太清楚的,可以参考一下其他的文章,比如

zeromq源码分析–TCP连接处理流程

1) 全异步的处理
zeromq的几乎所有I/O操作,都是异步的,也就是说主线程不会被阻塞.如何完成这个工作?它会根据zmq_init函数中的参数创建对应数量的I/O thread,然后将I/O相关的操作push到这些I/O线程中.

zeromq解决了什么问题

很早就听说了zeromq这个项目,当时不太在意.
后来同事kasicass对这个项目做了研究和分享,开始重视起这个项目来.
再后来,就是看到这篇博文:<<

向eventrpc 客户端加入异步/同步操作

之前的实现中,使用一个单独的Dispatcher类,用于分发网络事件,但是这个类也是在主线程中的,这样带来的问题,诚如上一篇文章说的那样, 不能支持异步事件的通知.对客户端而言,当发出一个请求时,必须阻塞等待回复的返回.

于是,今天抽出时间,将Dispatcher类实现为与线程绑定,它运行在副线程中.

使用google protobuf RPC实现echo service

这篇文章将讲述如何使用google的protobuf库实现一个RPC service,就实现一个最简单的service吧:echo.
文章对应的代码都可以在eventrpc中找到,写下这篇文章时的svn revision是138.

1) 定义协议
首先需要为这个service定义proto文件, 如下:

package echo;

message EchoRequest
{
  required string message = 1;
};

message EchoResponse
{
  required string response = 1;
};

service EchoService
{
  rpc Echo(EchoRequest)

苏紫紫

这个女孩叫苏紫紫,看了这个视频就可以知道她的故事了.

之所以强烈推荐这个视频,是因为她的勇敢和坚韧,没有因为所谓命运和社会的不公放弃自己,这是正向积极的人生态度.

你可以哭可以迷茫可以堕落过,但不能不学会勇敢和面对.”除了战斗之外我一无所有”.

另外,我同样欣赏这个女孩勇敢选择自己生活的态度,她没有活在别人的眼光里过着别人认为理所当然的生活.

P.S:原来搓衣板真的有人用还真的管用啊…

我的2010

今年,入职新公司,重新回到互联网的怀抱中.这个过程,说的夸张些,有点跟初恋分别多时,最后想清楚自己,重回最爱怀抱一般.

年度看过最让我脊梁发凉的好文章是申音的

git与项目review机制的配合

之前提过

glog简单分析

项目组一直使用google的glog开源库进行日志输出, 花时间研究了一下, 做些分享.

这里就不分析它的使用方式了, 还是比较简单的, 几乎可以不用配置就直接使用了.另外, 如果真的需要配置的话, glog和一般的日志系统(如log4系列)是不太一样的, 后者一般使用配置文件, 而glog是在命令行参数中指定的.对比优缺点, 配置文件做的配置可能更加强大一些,

Pages: Prev 1 2 3 4 5 6 7 8 9 Next