2017 gitlab宕机事件回顾
今天大家都在热议AWS down掉的事情,突然想起来了2017年gitlab.com的宕机事件,所以又去回顾了一下当时究竟发生了什么,顺便也根据当时事件的记录整理一个中文版本,其中还是有很多东西值得我们学习的。 事件回顾 这次事件发生在2017年的1月31号,当时gitlab.com整个不能访问,持续时间从17:20 UTC到第二天17:00...
东哥和系统设计开荒小分队的基地
今天大家都在热议AWS down掉的事情,突然想起来了2017年gitlab.com的宕机事件,所以又去回顾了一下当时究竟发生了什么,顺便也根据当时事件的记录整理一个中文版本,其中还是有很多东西值得我们学习的。 事件回顾 这次事件发生在2017年的1月31号,当时gitlab.com整个不能访问,持续时间从17:20 UTC到第二天17:00...
我们在前面的文章中已经介绍了Kafka的基础部分包括Producer,consumer等基本概念,本文来稍微深入聊一聊Kafka内部Cluster的架构。这个部分的理解对我们Debug相关的问题会有很大的帮助。 Cluster成员 Kafka在3. 0版本之前使用的是ZooKeeper来进行管理broker的列表的。每一个broker都用一个唯一的ID来进行标识。当一个broker启动的时候,它会去ZooKeeper中利用它的ID来创建一个ephemeral node。其它的broker包括controller可以subscribe到/brokers/ids这个路径下,这样每次有新的broker加入或者删除的时候都可以得到通知。当然如果有同样的ID试图加入,也会有error信息报出。...
我们知道在Twitter中的时间线和搜索是两个很主要的功能,那么它背后的架构是怎样的呢?Twitter的架构师Raffi Krikorian在QCon 2012上有一个讲座提到了背后的实现,虽然时间较早,但当时的QPS也已经很大了,所以其实现的架构哪怕在今天仍然值得我们去学习。本文就从笔者理解的角度来聊聊Twitter是如何实现这两个功能的。 概述 首先我们知道Twitter最重要的功能就是你可以发布一些Twitter的消息,然后一些follow你的人可以及时看到你发布的消息。当然你也可以看到所有你follow的人发布的消息,我们把这个你可以看到所有follow人的消息的这个页面称之为时间线页面,它如下所示:...
我们在《Kafka基础介绍之Consumer》中有提到可以使用poll函数来获取消息,而每次调用poll函数的时候,它返回的其实是Kafka中你这个consumer所在group还没有读的message。那这个还没有读是通过什么来判断的呢?它在Kafka中是通过offset来决定的,本文就来详细和大家聊聊Kafka中是如何通过offset来进行commit的。 概述 Kafka中consumer是通过offset来track每个partition中读的位置的,和一般的Queue的处理有些不同,在Kafka中你不需要每个message都进行commit,你可以一段一段地进行commit,也就是说假如Kafka收到你对offset 9的commit,那么它会默认你已经接受了9以前的所有的信息,而不需要你对8,7,6等都进行commit。 这种commit的方式在正常情况下是没有问题的,但是当出现我们以前提到的rebalance的情况,比如说consumer...
在今年的全球架构师大会上,来自DAZN的方案架构师Ivan Rigoni给我们分享了DAZN是如何做到每十分钟处理百万请求的,本文尝试从笔者自己理解的角度来和大家分享一下DAZN的实现。也许你还没有听说过DAZN这个公司,它是一个体育流媒体,主要提供体育赛事直播和视频点播服务。 问题的概述 这次演讲本身是一个系统设计的面试题,当然也是基于DAZN真实的架构演变进行抽象的。我们知道DAZN作为一个体育赛事的直播平台,每天都有很多新用户慕名而来,尤其是一些大型赛事正在进行的时候。当一个新用户来到DAZN,他需要进行注册付费才能够观看相关的赛事。而这个付费注册的过程需要调用第三方API来实现,是一个同步的call(transactional),需要一定的时间才能完成。而DAZN作为一个同时服务超过200个国家的体育直播平台,通常来说每秒需要新注册的用户超过1600个,当有大型赛事举办的时候,峰值可能会超过3000/s。我们的目标就是如何让新用户在这个量级的QPS下能够快速完成注册,并及时开始观看直播。 我们可以假设最初架构是如下所示的,有一个单体架构的前后端,它需要调用external的同步call来进行payment和subscribe,它的QPS是1600...
本周非常感谢David大佬给我们带来《分布式事务的介绍》,相关总结如下: Slides David使用的slides。 David的知乎讨论帖:分布式事务选型该怎么取舍? Q&A...
我们在前面的《Kafka基本架构和概述》中知道Kafka最基本的两个组成部分就是producer和Consumers,producer已经在之前的《Kafka基础介绍之Producer》中介绍过了,本文就来继续和大家详细聊一聊Consumers的概念。 Consumers和Consumer Groups 假如我们有一个应用需要从Kafka中读数据,并且把它写到一个data store中,我们首先就需要创建一个consumer的object,然后subscribe到对应的topic中,然后就可以开始接收数据了。这就是最基本的consumer形式,但是假如我们的数据写入的速度很快,而一个consumer处理不过来,这个时候就需要多个consumer一起来接收数据,我们把它称之为consumer...
我们在之前的《Kafka基本架构和概述》中提到了Kafka的几个重要的组成部分,本文就来深入聊一聊其中的Producer的概念。 简介 我们知道要想使用Kafka,其实最开始就是要创建一个Producer来往其中写消息,可以称之为消息源头吧,没有Producer来写,也就谈不上后面的consumer读了。 写消息粗听起来很简单,但是我们仔细思考一下这里就有很多问题需要确认。比如你的应用可以接受某些消息没有成功写进去吗?或者能够接受有重复的消息被写入吗?亦或是你的应用对写入的速度和延时有要求吗? 各种应用显然对我上面提到的问题有不同的答案,比如说一个log系统,丢一条或者少一条数据并不重要,延时一个几十秒甚至几分钟也不是什么大的问题。但假如是一个销售的系统,丢一条或者少一条销售数据可能就不行了。因此对于不同的应用,不同的要求,Kafka的producer可能都需要有不同的设置来进行匹配。...
本周我们很高兴再次邀请到Shihao给我们带来《TiDB的深入介绍》的讲座,相关总结如下: Slides Shihao使用的Slides见这里。 Q&A 感谢张程给我们做的详细笔记,相关的总结如下:...
现如今直播领域非常火爆,而一个大V的直播很容易就会吸引上百万的用户同时在线。LinkedIn的直播领域专家Akhilesh Gupta在QCon London 2020上介绍了LinkedIn是如何实现百万点赞的架构,本文就根据Akhilesh在会议上的介绍总结了相关的实现方法供大家参考。 场景分析...
Follow:
More
Recent Comments