BlueDavy之技术blog

Many applications need rpc to realize their business,in java world,we can choose rmi/webserivce to do rpc,but they’re not fast enough for most cases,so many of us choose some difference high performance network framework to realize rpc,such as mina,netty,grizzly,also we can choose some cross-language framework,such as thrift.
I wrote an abstract rpc framework to intergrate difference network framework more quickly,and also I intergrate mina/netty and do a benchmark on them,hope some of u can give some advices or attend the project to modify code or integrate other network framework,current benchmark record(single connection,100 concurrents) is 168k created by grizzly-rpc & protobuf,let’s beat the rpc benchmark together,u can find more details at here.

这个贴用于记录自己碰到过的一些Java问题，会根据经验不断增加，以便总结，:)

《分布式Java应用：基础与实践》一书中会存在一些错误的地方，以及一些尚未深入讲解的部分，在这篇文章里会提供纠错的信息以及补充的内容的文章的链接，关于书中错误的部分，还请各位海涵和帮助指正。

样章请从此下载：
http://bluedavy.com/book/booksample.pdf

随书的代码请从此处下载：
http://bluedavy.com/book/source.zip

目前NoSQL产品最被人诟病的就是其稳定性，不得不承认，目前HBase离做到数据库那样的高稳定还有距离（丢数据、不能读写、DDL失败等严重问题），这篇blog将用来记录我们在运维HBase时碰到的问题（会不断更新），希望能给使用HBase的同学有一些帮助。

NFS-RPC框架从编写之初，到现在为止（应该还会有些提升，不过估计不大），每秒支撑的请求数上升了好几倍，测试结果的演变为：
37k –> 56k –> 65k –> 88k –> 93k –> 143k –> 148k –> 153k –> 160k –> 163k –> 168k
以上测试结果为在100并发、100 request byte、100 response byte以及单连接下的背景下得出的，在这篇blog中来分享下这个框架所做的一些优化动作，希望能给编写rpc框架或使用mina/netty/grizzly的同学们一点点帮助，也希望得到高手们更多的指点。

根据最近生产环境使用的经验，更多的项目的采用，以及采用了更加自动的测试平台，对HBase做了更多的场景的测试，在这篇blog中来分享下纯粹的随机写和随机读的性能数据，同时也分享下我们调整过后的参数。

ps: 强烈推荐同事的blog，其中记录了很多我们对HBase的改进，以及我们在运维HBase项目时碰到的各种奇怪、诡异的问题。

前两天碰到一个很诡异的GC频繁的现象，N种方法查找后才终于查明原因了，在这篇blog中记录下，以便以后碰到这类问题时能更快的解决。

这是根据最近HBase项目的一些经验，还有NB的Advanced HBase的slide重写的一份关于HBase的介绍，熟手可基本忽略此slide，:)

感兴趣的同学可以把下面的代码copy到机器上执行看看（例如java GenRandomStringTest 50 100 1024），会发现是挺耗CPU的，原因是什么呢？ 有什么建议吗？

ps: 不过话说以这种方式随机生成指定大小的字符串还是挺耗时的，也欢迎提供建议，:)

Facebook之前上线了新的messages实现，以前草草的看过相关的几篇blog还有facebook同学在qcon上讲的hbase的slide，但其实看的都很粗略，尤其是之前去facebook和相关同学交流后，发现和自己之前理解的太不一样了，于是近几天又翻出了messages的几篇blog来仔细的看了看，看完后的感触就是facebook在设计其messages实现时，会尽可能做到物尽其用，对于不满足的则更多的是在应用层来处理，这样可以保证很好的灵活性以及扩展性，下面就来讲讲我现在理解的facebook messages实现，请各位看官拍砖，:)