根据erlang自定义behaviour生成编译依赖关系

erlang中可以自定义behaviour,但是如果一个模块是实现了该自定义behaviour的话,那么首先要编译behaviour,其次在编译该模块时加入-pa指定编译好的behaviour.beam路径,否则编译的时候会提示该behaviour未定义.

换句话说,实现需要依赖到behaviour模块编译.

因此需要根据代码中的这种依赖关系,对代码进行一次梳理,定义一个正确的编译顺序.幸而rabbitmq项目已经有这样的代码,我就抽取出来用了,具体的实现还没有细看.在这个框架的文件组织中,erl文件放在src子目录下面,在src/Makefile中,首先以当前目录的所有erl文件为参数调用../generate_deps(这个文件取自rabbitmq项目)来产生依赖关系文件deps.mk,注意要在Makefile中include这个文件,这样新的依赖关系才会起效,然后编译会自动根据新的依赖关系来安排编译的顺序了.有了这些,你所需要做的就是把你写的erl文件放在src目录下面,依赖关系什么的,由Makefie搞定了.

示例项目在

zmq-rpc:基于zeromq网络层编写的protobuf RPC框架

阅读过zmq的代码之后,感觉这个网络层是我目前见过最高效的–线程之间使用lockfree的消息队列保存消息,可以启动多个I/O线程分担压力等等特性.于是决定基于它写一个protobuf

抽取rabbitmq网络层做的echo server

传说rabbitmq网络层实现的优雅高效,于是我就尝试着将其中的网络层抽取出来,模拟着做了一个echo服务器,代码放在

shared_ptr真能防止内存泄漏吗?

这个命题有些诡异,因为shared_ptr设计的初衷就是为了防止内存泄漏,但是先别急,等我把问题描述清楚.

事出缘由是这几天项目出现一个内存泄漏的bug,之前这部分是使用shared_ptr封装了很多指针的操作,后来出于效率的考虑,改回了裸指针.由于我们使用的google

全局定义结构体名称冲突导致的问题(C++)

上周项目代码中出现一个诡异的问题,我在某个数据结构中新增了一个string类型的成员变量,但是每次到了赋值的时候必然出现core dump.跟踪了好久,也猜想到应该是string的函数指针表之类的被破坏了,但是始终找不到原因.最后突然想到搜索代码中该结构体定义的地方,发现同时有两个.cc文件中都定义了该名字的结构体(其中一个也是这一次新增的),于是恍然大悟,应该是结构体的定义名称冲突导致的.

我将这段出错的代码,抽取出来写了个demo,放在

erlang中使用ets的一个弱问题

这几天纠结在一个erlang的ets操作问题上,最后才发现,其实是一个很弱的问题.

问题大致是这样的:程序启动之后,读取配置文件,将其中的配置保存到ets表中,然后创建superviser监控进程,再由这个进程拉起几个工作进程,工作进程中会根据情况通过之前创建的保存配置的ets表获取一些配置进行操作.可就是在work操作ets表的过程中,偶尔会有出现报错,大意是这个ets表是无效的,未定义的.查了一些ets的资料,起初以为问题在于表的时候没有设置属性为public所致,但是还是出现问题.

找了很多地方无果,最后想起之前有同事提过公司内有玩erlang比较熟悉的人,遂赶紧将出错的代码提炼出来求教.问题出在于,这个ets表是在程序开始之后马上创建的,而后这个进程又创建了superviser进程等,而在这个过程完结了之后,这个最初的进程就退出了,于是由它创建的ets表也就失效了.因此,偶有出现访问异常的原因,实际上跟erlang虚拟机的进程调度相关(一般这些灵异的问题都跟这些有关系).因此解决的办法是,在superviser进程中创建ets表,由于这个进程一直常驻,所以就不会由于它的退出导致访问异常了.

不过,话说回来,我的这个思路还是不那么COP的编程思路.更好的做法是,给这个ets表包一个gen_server的访问层,对这个表的访问,操作等都通过gen_server的回调函数handle_call/handle_cast等来进行,也就是对这个表的操作局限在这个进程中,其他进程如果要访问还是走的erlang惯用的消息通信的方式.而之前的方式,虽然也可以,但是必然会造成大量的对ets表的加解锁同步问题.

erlang中使用google protobuf进行通信

初学erlang,花了不少的功夫,想要在erlang中集成google的protobuf用于消息通信.个人觉得,使用类似protobuf这样通用的编解码模块,有一个好处就是这部分完全交给别人,再不用自己关心什么很操蛋的大小端,数据长度等琐碎的问题,另外,protobuf使用.proto文件自描述协议,C/S端人员可以通过这个来讨论问题,一目了然.

然而,要把它集成到erlang中还是一件比较麻烦的事情,一来google官方没有对erlang进行支持,这也许是因为google官方认定的编程语言只有C++,java,Python三种的缘故吧,而它的竞争对手,如thrift等都提供了erlang的支持.虽然官网上给出了第三方做的其他语言的实现,但是毕竟不是官方的实现,可能会有些未知的问题.比如我很担心我使用erlang非官方的protobuf实现写了一个服务器,但是再用比如python写了一个客户端,C/S两端都使用protobuf进行通信,但是由于编解码实现的差异,导致了协议数据有出入.

不过,鉴于我在搜索资料的时候未发现比较好的介绍如何在erlang中使用protobuf的方式,还是记录一下吧.

1)

zookeeper3.3.3源码分析(四)对leader选举过程分析的纠正

很抱歉,之前分析的zookeeper

zookeeper3.3.3源码分析(三)Leader与Follower同步数据流程

根据二)中的分析,如果一台zookeeper服务器成为集群中的leader,那么一定是当前所有服务器中保存数据最多的服务器,所以在这台服务器成为leader之后,首先要做的事情就是与集群中的其它服务器(现在是follower)同步数据,保证大家的数据一致,这个过程完毕了才开始正式处理来自客户端的连接请求.

首先来看Leader做的工作:

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

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

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

1) 数据恢复阶段

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