Kafka的复制机制

最近在设计一个多分区多副本的消息系统,以前对kafka有一些了解,在阅读了阿里的RocketMQ、小米的Pegasus等分布式系统后,再仔细阅读的kafka的复制设计,整理出本篇文档,可以和其它系统做一个对比。

Kafka是一种高吞吐量的分布式发布订阅消息系统,有如下特性:

  1. 通过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
  2. 高吞吐量:即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
  3. 支持通过Kafka服务器和消费机集群来分区消息。
  4. 支持流式处理。

7年过去了, kafka已经成为一个羽翼丰满的发布订阅平台、消息存储、流处理的工具。财富500强企业中有三分之一的公司使用了kafka平台。也就是在昨天(2017年11月1日),kafka发布了它的1.0.0版本。

本文主要参考了Jun Rao(饶军)的Intra-cluster Replication in Apache Kafka, Jun Rao毕业于清华大学,哥读到博士,后来在IBM、LinkedIn工作,在LinkedIn期间任Kafka组的技术leader。2014年Kafka一帮人成立了Confluent公司,推广Kafka的商业应用,Jun Rao是共同创始人。

阅读全文

[转]设计一个容错的微服务架构

原文: Designing a Microservices Architecture for Failure
翻译: 设计一个容错的微服务架构 by Jason Geng

微服务架构使得可以通过明确定义的服务边界来隔离故障。但是像在每个分布式系统中一样,发生网络、硬件、应用级别的错误都是很常见的。由于服务依赖关系,任何组件可能暂时无法提供服务。为了尽量减少部分中断的影响,我们需要构建容错服务,来优雅地处理这些中断的响应结果。

本文介绍了基于RisingStack 的 Node.js 咨询和开发经验构建和操作高可用性微服务系统的最常见技术和架构模式。

如果你不熟悉本文中的模式,那并不一定意味着你做错了。建立可靠的系统总是会带来额外的成本。

阅读全文

2016年Web框架性能基准

TechEmpower最近发布了他们的第13轮的web框架的性能测试,得到了一些有价值的测试结果。

由于年初前一轮的测试遭遇到了硬件的瓶颈,微软 Azure 和 ServerCentral 分别提供了云主机和物理主机环境,所以第13轮的测试是在新的测试环境中进行的,所以你把这轮的测试结果和以前的测试进行比较的话可能不太合适。


ServerCentral

物理机环境,由 ServerCentral提供。 Dell R910 (4x 10-Core E7-4850 CPUs) 为应用服务器; Dell R420 (2x 4-Core E5-2406 CPUs) 为数据库服务器; 10G网络

Azure

云测试主机由 Microsoft Azure D3v2 实例提供; 10网络

阅读全文

产品级微服务的八大原则

虽然微服务架构给开发者带来很大的自由,但是确保服务的可用性却要求对微服务进行很好的架构,运维以及组织标准。
O'Reilly这本免费的电子书Microservices in Production介绍了微服务标准化的挑战,以可用性作为微服务标准化的目标,提出了八个标准化微服务的原则,包括在整个工程组织中实现production-readiness标准的策略。

这本书的作者是 Susan J. Fowler, Uber 的 SRE (site reliability engineer),她在Uber也主要做促使Uber项目中的各个微服务达到产品级的状态,所以这本小书也是她的工作思考之作。

阅读全文

[转]DNS 原理入门

转自 阮一峰 的 DNS 原理入门

DNS 是互联网核心协议之一。不管是上网浏览,还是编程开发,都需要了解一点它的知识。
本文详细介绍DNS的原理,以及如何运用工具软件观察它的运作。我的目标是,读完此文后,你就能完全理解DNS。

阅读全文

[转]CDN的原理以及其中的一些技术

这是 Xu Ruochen 总结的通过DNS实现的CDN的一篇条理清晰的文章, 原文链接: CDN的原理以及其中的一些技术

CDN,全称Content Delivery Network,主要作用是为源站减少访问压力的同时,为客户端提供更快速的内容响应。除此之外,CDN还能对源站进行安全防护。 其实真正为CDN付费的是源站,所以CDN的用户其实是源站,例如新浪微博,youku视频,淘宝网啊之类的。而客户端,是CDN的用户的用户。 所以CDN是夹在源站和源站的用户之间的,以下称客户端均指源站的用户。

阅读全文

一个速度快内存占用小的一致性哈希算法

一致性哈希最早由 MIT的 Karger 提出,在发表于1997年的论文 Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web, Karger et al 和合作者们提出了一致性哈希的概念(consistent hash),用来解决分布式Cache的问题。这篇论文中提出在动态变化的Cache环境中,哈希算法应该满足的4个适应条件::Balance(均衡)、Monotonicity(单调性)、Spread(分散性)、Load(负载)。

在分布式缓存系统中使用一致性哈希算法时,某个节点的添加和移除不会重新分配全部的缓存,而只会影响小部分的缓存系统,如果均衡性做的好的话,当添加一个节点时,会均匀地从其它节点移一部分缓存到新的节点上;当删除一个节点的时候,这个节点上的缓存会均匀地分配到其它活着的节点上。

一致性哈希缓存还被扩展到分布式存储系统上。数据被分成一组Shard,每个Shard由一个节点管理,当需要扩容时,我们可以添加新的节点,然后将其它Shard的一部分数据移动到这个节点上。比如我们有10个Shard的分布式存储系统,当前存储了120个数据,每个Shard存储了12个数据。当扩容成12个Shard时,我们从每个Shard上拿走2个数据,存入到新的两个Shard上,这样每个Shard都存储了10个数据,而整个过程中我们只移动了20/120=1/6的数据。

Karger 一致性哈希算法将每个节点(bucket)关联一个圆环上的一些随机点,对于一个键值,将其映射到圆环中的一个点上,然后按照顺时针方向找到第一个关联bucket的点,将值放入到这个bucke中。因此你需要存储一组bucket和它们的关联点,当bucket以及每个bucket的关联点很多的时候,你就需要多一点的内存来记录它。这个你经常在网上看到的介绍一致性哈希的算法(有些文章将节点均匀地分布在环上,比如节点1节点2节点3节点4节点1节点2节点3节点4……, 这是不对的,在这种情况下节点2挂掉后它上面的缓存全部转移给节点3了)。

其它的一致性算法还有Rendezvous hashing, 计算一个key应该放入到哪个bucket时,它使用哈希函数h(key,bucket)计算每个候选bucket的值,然后返回值最大的bucket。buckets比较多的时候耗时也较长,有人也提出了一些改进的方法,比如将bucket组织成tree的结构,但是在reblance的时候花费时间又长了。

Java程序员熟悉的Memcached的客户端Spymemcached、Xmemcached以及Folsom都提供了Ketama算法。其实Ketama算法最早于2007年用c 实现(libketama),很多其它语言也实现了相同的算法,它是基于Karger 一致性哈希算法实现:

  • 建立一组服务器的列表 (如: 1.2.3.4:11211, 5.6.7.8:11211, 9.8.7.6:11211)
  • 为每个服务器节点计算一二百个哈希值
  • 从概念上讲,这些数值被放入一个环上(continuum). (想象一个刻度为 0 到 2^32的时钟,这个时钟上就会散落着一些数字)
  • 每一个数字关联一个服务器,所以服务器出现在这个环上的一些点上,它们是哈希分布的
  • 为了找个一个Key应该放入哪个服务器,先哈希你的key,得到一个无符号整数, 沿着圆环找到和它相邻的最大的数,这个数对应的服务器就是被选择的服务器
  • 对于靠近 2^32的 key, 因为没有超过它的数字点,按照圆环的原理,选择圆环中的第一个服务器。

以上两种算法可以处理节点增加和移除的情况。对于分布式存储系统,当一个节点失效时,我们并不期望它被移除,而是使用备份节点替换它,或者将它恢复起来,因为我们不期望丢掉它上面的数据。对于这种情况(节点可以扩容,但是不会移除节点),Google的 John Lamping, Eric Veach提供一个高效的几乎不占用持久内存的算法: Jump Consistent Hash

阅读全文

[转]各大互联网公司架构演进之路汇总

原文地址:各大互联网公司架构演进之路汇总 by HollisChuang
请转载时务必保留文章的上述原始出处。

Web


支付宝和蚂蚁花呗的技术架构及实践
支付宝的高可用与容灾架构演进
聚划算架构演进和系统优化 (视频+PPT)
淘宝交易系统演进之路 (专访)
淘宝数据魔方技术架构解析
淘宝技术发展历程和架构经验分享(视频+PPT)(2.3日更新)
高德——快速转型时期的稳定性架构实践(视频+PPT)(2.3日更新)
秒杀系统架构分析与实战
腾讯社区搜索架构演进(视频+PPT)
京东峰值系统设计
京东咚咚架构演进
新浪微博平台架构
微博图床架构揭秘
微博推荐架构的演进
当当网系统分级与海量信息动态发布实践
当当网架构演进及规划实现(视频+PPT)
LinkedIn架构这十年
Facebook’s software architecture(英文)
从0到100——知乎架构变迁史
豆瓣的基础架构
搜狗搜索广告检索系统-弹性架构演进之路(视频+PPT)
小米网抢购系统开发实践
小米抢购限流峰值系统「大秒」架构解密
海尔电商峰值系统架构设计最佳实践
唯品会峰值系统架构演变
1号店电商峰值与流式计算
蘑菇街如何在双11中创造99.99%的可用性
麦包包峰值架构实践
苏宁易购:商品详情系统架构设计
携程的技术演进之路
篱笆网技术架构性能演进(视频+PPT)
从技术细节看美团的架构(1.26日更新)
美团云的网络架构演进之路(2.3日更新)
百度开放云大数据技术演进历程(视频+PPT)(2.3日更新)
途牛供应链系统的架构演进(视频+PPT)(2.3日更新)
Airbnb架构要点分享(2.3日更新)
12306核心模型设计思路和架构设计(2.20日更新)

无线


阿里无线技术架构演进
支付宝钱包客户端技术架构(2.3日更新)
手机淘宝构架演化实践
手淘技术架构演进细节
手机淘宝移动端接入网关基础架构演进之路
微信后台系统的演进之路
微信红包的架构设计简介
微信Android客户端架构演进之路
Android QQ音乐架构演进(视频+PPT)
快的打车架构实践
Uber 四年时间增长近 40 倍,背后架构揭秘
Uber容错设计与多机房容灾方案
大众点评移动应用的架构演进(视频+PPT)
饿了么移动APP的架构演进

其他


魅族实时消息推送架构
魅族云端同步的架构实践和协议细节



欢迎补充!~

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 的邮件列表中比较这两个项目的缓存特性差异,也被认为是营销惨遭删帖。

阅读全文