博客协会挨踢技术专业委员会"哥学社"正式成立

哥学社

最新的成员列表和任务列表都会记录在 http://www.54chen.com/blog-brother

博客协会挨踢技术专业委员会"哥学社"今日在成立。博客协会无会长、盛大坦克、人人网54chen分别在会上做了演讲。来自三大运营商的表示将全力支持哥学社开展工作,提升哥学社挨踢技术水平。

有容乃大在发言中总结出,回眸2009年,技术博客频发,发了又发、信息重复等非传统博客问题十分突出,网络恶意行为的趋利化特征日益明显,黑客个体、地下产业链等方面的问题都给挨踢技术带来了严峻挑战,技术整体形势日趋严峻。哥学社的成立,将有助于对发博客探讨技术提供规范化有效化管理,更好地为遇到难题解决不了的兄弟提供决策依据,有助于互联网各公司对解决方案做出全面客观的评定。大家希望,哥学社要充分发挥学社作为各大公司间的桥梁纽带作用,企业积极主动向大家反映他们的合理诉求,维护企业利益,促进企业发展。

大家还就如何做好当前的工作提出了几点规则:一要切实增强每个会员工作的责任感、紧迫感和使命感,凡参加必须提出博客议题;二要深入开展博客内容建设,定时定量挑选有意义的博客议题进行发挥;三要充分发挥学会的支撑作用,到处宣扬,拉新鲜血液入会;四要积极拓展博客工作的服务范围,不仅仅局限在挨踢技术;五要大力开展自己博客的自律,积极主动提议题、发内容。
作者:郭庆婧    来源:人民邮电报 转自:http://www.c114.net/news/16/a495168.html

现有议题:
1.mysql explain全解
2.shorturl算法方案
3.tokyo cabinet使用
4.no-sql原理

现有成员列表:
54chen http://www.54chen.com
Tank http://skiyo.cn
虫zi http://www.xiaoxiaozi.com
show http://www.showframework.com
风雪之隅 http://www.laruence.com/
Zoro http://t.sina.com.cn/10514

加入 哥学社 需要的条件:
1.有博客 2.有理想 3.哥

如果满足,请联系cc0cc@126.com或者留言。
如果不满足,想知道什么,请投递 cc0cc@126.com 或者留言。 一个临时沟通的 group(为防,加s)

最新的成员列表和任务列表都会记录在 http://www.54chen.com/blog-brother

试用新型JAVA构建工具Gradle

54chen在研究一个开源项目的时候,发现其使用的构建工具很特殊,叫Gradle,和ant maven类似,他提供的东西更加有感觉,不过冒似版本还不高,最新的0.9也只是一个预览版本。

名词解释

ant
当一个代码项目大了以后,每次重新编译,打包,测试等都会变得非常复杂而且重复,因此c语言中有make脚本来帮助这些工作的批量完成。在Java 中应用是平台无关性的,当然不会用平台相关的make脚本来完成这些批处理任务了,ANT本身就是这样一个流程脚本引擎,用于自动化调用程序完成项目的编译,打包,测试等。除了基于JAVA是平台无关的外,脚本的格式是基于XML的,比make脚本来说还要好维护一些。

maven
Maven是基于项目对象模型(POM),可以通过一小段描述信息来管理项目的构建,报告和文档的软件项目管理工具.
如果你已经有十次输入同样的Ant targets来编译你的代码、jar或者war、生成javadocs,你一定会自问,是否有有一个重复性更少却能同样完成该工作的方法。Maven便提供了这样一种选择,将你的注意力从作业层转移到项目管理层。Maven项目已经能够知道如何构建和捆绑代码,运行测试,生成文档并宿主项目网页.
项目的主页地址为:http://maven.apache.org/

Gradle
Gradle是一个基于Groovy的build工具——“Ease - Freedom - Power for your build
Gradle试图使用Groovy语法来提供Ant的灵活性;它支持多项目的创建,为Ivy提供了一个layer,提供了build-by-convention集成;而且它还让你获得许多类似Maven的功能比如传递依赖管理和约定大于配置。

Groovy
Groovy 是 JVM 的一个替代语言 — 替代 是指可以用 Groovy 在 Java 平台上进行 Java 编程,使用方式基本与使用 Java 代码的方式相同。在编写新应用程序时,Groovy 代码能够与 Java 代码很好地结合,也能用于扩展现有代码。目前的 Groovy 版本是 1.6.3,在 Java 1.4 和 Java 5 平台上都能使用,也能在 Java 6 上使用。

为何使用Gradle 尽管Ant没有内置的依赖管理是个事实,但是将Ivy整合到你build.xml中还是很简单的。Maven有构建脚本,只需要几行代码来配置就可以有许多功能:依赖管理、内置的编译和打包应用的任务、与Jetty的集成、干净的项目web网址,与cobertura的集成、pmd或者findbugs。
Maven和Ant就只是我们的选择么?是否还有比它们更好的选择?在过去的几年中,我们看到很多项目,他们使用的工具不再使用XML来定义构建逻辑,而是真正的编程语言像Groovy、Ruby、Python,它们经常允许依赖管理。这里有几个:GRADLE 、Gant、Kundo、 Raven、 Buildr。

如何使用Gradle 用Groovy语法(相当类似java)写好构建的逻辑。类似下面这个(elasticsearch项目的):

import java.text.SimpleDateFormat
defaultTasks "clean", "release"
usePlugin BasePlugin
archivesBaseName = 'elasticsearch'
buildTime = new Date()
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
buildTimeStr = sdf.format(buildTime)

versionNumber = '0.5.1-SNAPSHOT'

explodedDistDir = new File(distsDir, 'exploded')
explodedDistLibDir = new File(explodedDistDir, 'lib')
explodedDistBinDir = new File(explodedDistDir, 'bin')
explodedDistConfigDir = new File(explodedDistDir, 'config')

allprojects {
group = 'org.elasticsearch'
version = versionNumber

plugins.withType(JavaPlugin).whenPluginAdded {
sourceCompatibility = 1.6
targetCompatibility = 1.6
}

repositories {
mavenCentral()
mavenRepo urls: 'http://repository.jboss.com/maven2/'
} }

configurations {
dists
distLib {
visible = false
} }

dependencies {
distLib project(':elasticsearch')
}

task explodedDist(dependsOn: [configurations.distLib], description: 'Builds a minimal distribution image') << {
[explodedDistDir, explodedDistLibDir, explodedDistBinDir, explodedDistConfigDir]*.mkdirs()
// remove old elasticsearch files
ant.delete { fileset(dir: explodedDistLibDir, includes: "$archivesBaseName-*.jar") }

copy {
from configurations.distLib
into explodedDistLibDir
}

copy { from('bin'); into explodedDistBinDir }
copy { from('config'); into explodedDistConfigDir }

copy {
from('.')
into explodedDistDir
include 'LICENSE.txt'
include 'NOTICE.txt'
include 'README.textile'
}

ant.chmod(dir: "$explodedDistDir/bin", perm: "ugo+rx", includes: "**/*")
}

task zip(type: Zip) {
dependsOn explodedDist
// classifier = 'all'
}

zip.doFirst {task ->
zipRootFolder = "$archivesBaseName-${-> version}"
task.configure {
zipFileSet(dir: explodedDistDir, prefix: zipRootFolder) {
exclude 'bin/*'
} zipFileSet(dir: explodedDistDir, prefix: zipRootFolder, fileMode: '775') {
include 'bin/*'
exclude 'bin/*.*'
} zipFileSet(dir: explodedDistDir, prefix: zipRootFolder) {
include 'bin/*.*'
} }
}

task release(dependsOn: [zip]) {
}

 
task wrapper(type: Wrapper) {
gradleVersion = '0.8'
jarPath = 'gradle'
} 到Gradle下载zip包,解压到任何位置,设置环境变量中的GRADLE_HOME过程此位置,path中增加gradle的bin目录,http://www.gradle.org (杯具,需翻)

到项目目录下直接运行 gradle,编译成功有如下提示:

如果直接运行 gradle --gui,还能以gui的模式来选择,非常人性化:

本文作者:
54chen(陈臻),人人网分布式存储研究人员,业余时间混迹于各技术组织且乐此不疲。目前关注实施PHP培训。对flex等前端技术有一点研究。
个人技术站点:http://www.54chen.com/ 。可以通过电子邮件 cc0cc@126.com 联系到他。

本文提到的网址

Gradle: http://www.gradle.org

国内的评论:http://news.csdn.net/n/20090313/124106.html

的一些讨论:http://stackoverflow.com/questions/1163173/why-use-gradle-instead-of-ant-or-maven

闲谈分布式key-value存储服务nuclear及其他

现在很多国内公司都纷纷开始了key-value的nosql存储方式,然而,从什么时候开始key-value会变得这么流行呢?是风靡一时,还是顺应时代的潮流?前后数一数,有豆瓣网的beandb、有新浪的SDD、小道消息还有腾讯的TDB以及人人网的nuclear。再数,吹起这阵风的原因是亚马逊的一篇文档,这篇文档讲述了在亚马逊的S3服务中所使用的存储系统dynamo实现方式,但遗憾的是dynamo并不开源。紧随其后,来了位号称是当年亚马逊dynamo的开发人员之一的同志,实现了的cassandra,并且值得表扬的是还将其开源了。与此同时,相同理论下产生的,还有linkedin的voldemort系统。

百家争鸣还是百家讲坛

分布式存储的目标,是解决大规模数据在数据量不断增长的情况下,让服务更加稳定,更容易扩展。

其主要具备以下几个特点:

1.高可靠性:系统能够长时间高效运行不迭机。严格的说即使坏了一部分机器也没事。

2.可扩展性:可以随意增加减少机器,不用担心额外的数据损失。

3.负载均衡:要保证每个节点的数据都是负载均衡的,不出现集中负载到一个节点的情况。

4.一致性:因为是分布式的节点,就需要保证节点与节点之间保存数据的一致。

鱼与熊掌不可兼得,这几点,往往完成了其中几点就会损失另外一点,要全部达到完美,是一件非常困难的事情。

在国内的几个存储来看,基本都是只实现了其中的一部分,再按照自己业务的需求,来加强其中更为关心的建设。

beansdb的最终一致性通过哈希树实现快速完整数据同步(短时间内数据可能不一致);可以在不中断服务的情况下进行容量扩展;异步IO和高性能的KeyValue数据TokyoCabinet:通过N,W,R进行配置(这点其实是dynamo的文档里的方案,并非beansdb所创);Memcache兼容协议,大量可用客户端。sdd也大同小异。

Nuclear完成了这些功能,并且可以适配到mysql\tc\bdb等存储引擎之上。

为什么已经有开源的项目,还要去自己实现呢?简单的说,weibo敢用,你敢用吗?

分布式key-value存储之所以稳定的原因

从设计之初,注定这个系统会很稳定。为什么呢,主要是下面几点:

1.dynamo文档中的NWR的观点,可以让节点在损坏的情况下也能稳定如新。基本上这些系统都实现了。

2.dynamo文档中的两层数据节点的观点,可以让各节点在大负载的情况下负载均衡。部分实现了这一点。

3.底层存储的时候是key-value的读和取,只有一个维度的底层作,对引擎来说,所有的作都是可计算时间的。这一点的意思是说,假设都是MYSQL的底层存储,这个系统只会有一堆的select value form table where key=num这样的查询,而不会出现select * from table where key in(num1,num2,num3....)这样的查询,这两个查询不同的地方在于,如果都是1000次的查询,那么前一条的时间是可以准确预估的,而后一条取决于mysql底层实现的逻辑,而这个逻辑对上层是不可见的。

更多不明原因。。。

适合使用的范围

这套系统也不是放之四海而皆准的东西,如果说您的系统有如下的特征,可以考虑考虑:

1.数据插入后不需要各维度的查询。

2.数据不需要100%精确立即展示。

更多不明特点。

总结

其实这个系统,在过十亿的数据量下才有意思。
本文作者:
54chen(陈臻),人人网分布式存储研究人员,业余时间混迹于各技术组织且乐此不疲。目前关注实施PHP培训。对flex等前端技术有一点研究。
个人技术站点:http://www.54chen.com/ 。可以通过电子邮件 cc0cc@126.com 联系到他。

[文中所提及的链接]

beansDB:http://code..com/p/beansdb/

SDD:http://code..com/p/sina-sdd/

Nuclear:http://ugc.renren.com

S3:http://aws.amazon.com/s3/

dynamo:http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf

cassandra:http://incubator.apache.org/cassandra/

voldemort:http://project-voldemort.com/