Ignite vs Hazelcast

内存数据网格HazelcastIgnite是大家非常熟悉的两种分布式内存数据网格工具。

Hazelcast 是一款基于 Java的内存数据网格,它的名称和公司的名称相同。hazelcast支持分布式队列,集合,map,线程池,锁,支持事务处理,分布式的监听和事件,支持动态增加集群节点,动态备份数据,动态failover等。

关于Apache Ignite 的中文介绍可以参考李玉珏写的Apache Ignite(一):简介以及和Coherence、Gemfire、Redis等的比较等系列文章。Ignite来源于尼基塔·伊万诺夫于2007年创建的GridGain系统公司开发的GridGain软件,2015年1月,GridGain通过Apache 2.0许可进入Apache的孵化器进行孵化,很快就于8月25日毕业并且成为Apache的顶级项目,9月28日即发布了1.4.0版,2016年1月初发布了1.5.0版,迭代速度很快。

两个产品背后的公司Hazelcast和GridGain都有风投的背影。所以产品在开源免费的基础上还会提供商业版的支持。

我没有在实际产品中使用过这两款产品,仅仅关注过这一类的产品,所以并不完全了解它们的详细特性,但是最近的一些有趣的争论引起了我的兴趣,特地跟踪了多个帖子,弄清楚了争论的来龙去脉,特地整理了一下,也算作为我的性能系列的文章的一部分吧。

最近的事件是这两个产品背后的公司进行了激烈的性能之争。

起因是GridGain发布了一篇性能报告:GridGain vs. Hazelcast Benchmarks, 它比较了最新的GridGain Community Edition 1.5.0 和 最新的Hazelcast 3.6-EA2的性能,测试数据显示Ignite的性能要好于Hazelcast。相关的测试代码可以参照yardstick-ignite yardstick-hazelcast

进一步GridGain还到Hazelcast的用户讨论组中踢馆子,他们把测试结果和代码发布在Hazelcast的邮件列表中,请Hazelcast的人review和提意见。嚣张啊!
Hazelcast的CEO Luck把这个帖子从邮件列表中删除了,并说:

我们认为你在我的地盘上发布这样的性能数据是不合适的。 我们将删除这个帖子,请发布在你的地盘上。

当然,这也不是GridGain第一次踢馆子,在2015初Apache孵化器Ignite项目的导师Konstantin Boudnik就到Tachyon 的邮件列表中比较这两个项目的缓存特性差异,也被认为是营销惨遭删帖。

阅读全文

uriDB网站的可扩展的技术栈

背景

uriDB本身不生产干货,uriDB技术流网站只是大自然的搬运工。
Hacker News诞生依赖,已经有多个中文技术头条的网站了,比如开发者头条极客头条,为什么还要做这样一个雷同的头条网站呢?

有两个原因:
一是我想做一个分类头条的网站,按照技术领域对文章进行分类,这样只对前端感兴趣的同学可以只跟踪最新的前端文章。 同时uriDB只会筛选最新的技术干货,不会将问答,闲聊等技术层次低的文章收录。
二是这么多年来,我涉及的领域包括后台,大数据,前端和移动端的技术也是我感兴趣的领域。心中那份对技术的持久的热情,促使我将多年的技术积累以某种具体的形式呈现出来,籍此展示并能持久的进行技术架构的演化。

因此,uriDB技术流网站也就孵化出来了。虽然目前的访问量比较少,但是看的用户数和访问量在逐步的提升,也是一件令人欣慰的事。至少,这个网站收集的干货也为那些执着学习的同学带来些许的便利和技能提升。

与其说uriDB类似Hacker News网站, 还不说说它类似今日头条, 只不是今日头条上全是新闻类的内容,而uriDB上全是技术干货。今日头条会将目标网站上的内容抓去过来进行重新排版,更加适合阅读。我也抓去了目标文章的内容,却没有进行重新排版显示,主要是考虑到了版权的问题,还是老老实实的做Hacker News一样的转发。

这个网站是2015年国庆节期间开始启动的,也是作为我的side project在维护。我会时不时的将我的新的想法,技术灵感应用于这个网站上。

阅读全文

雪球在股市风暴下的高可用架构改造分享

本文根据唐福林老师在“高可用架构”微信群所做的《股市风暴下的雪球架构改造经验分享》整理而成,转发请注明来自微信公众号ArchNotes。

唐福林,雪球首席架构师,负责雪球业务快速增长应对及服务性能与稳定架构优化工作。毕业于北京师范大学,硕士学位。之前曾任微博平台资深架构师,微博技术委员会成员。长期关注并从事互联网服务后端性能及稳定性架构优化工作。

阅读全文

大型网站系统架构的演化

原文: 大型网站系统架构的演化, 作者:李平

一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索、下单、支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段可以广泛运行在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。

阅读全文

LinkedIn架构这十年

原文: A Brief History of Scaling LinkedIn

Josh Clemm是LinkedIn的高级工程经理,自2011年加入LinkedIn。他最近(2015/07/20)写了一篇文章,介绍了LinkedIn针对用户规模急速扩大带来的架构方面的变革。
文章有点像子柳写的淘宝技术这十年

2003年是LinkedIn元年,公司成立的目标是连接你的个人人脉以获得更好的的工作机会。上线第一周才有2700个会员注册,时光飞梭,LinkedIn的产品、会员数量、服务器负载都极大的增长了。
今天,LinkedIn全球用户已经超过3.5亿。我们每秒有数十万个页面被访问,移动端流量已占到50%以上 (mobile moment)。所有这些请求都从后台获取数据,而我们的后台系统可以处理每秒上百万次查询。

问题来了: 所有这些是怎么做到的呢?

阅读全文

架构学习资料整理(2013)

地瓜哥2013攒的架构资料:分享D瓜哥最近攒的资料(架构方面)

以前见过零零散散地介绍一些知名网站架构的分析文章。最近D瓜哥也想研究一下各大知名网站的架构。所以,就搜集了一下这方面资料。限于时间问题,这篇文章分享的文章并没有都看完,所以不保证所有文章的质量。另外,如果有朋友发现更好的文章,欢迎留言告知。再补充进来。

阅读全文

CQRS 和 Event sourcing

CQRS全称为Command Query Responsibility Segregation。 CQRS并不是一个完整的架构,而是一个小的模式。这个模式首先由Greg Young 和 Udi Dahan提出,Martin Flower有一篇文章专门介绍这个模式,微软也有一个专门教程介绍CQRS。
CQRS描述起来很简单,就是命令和查询职责分离。

阅读全文