58沈剑用3个小时的视频告诉你高可用的那些事儿


本文是58到家技术总监沈剑在MPD2016 北京站上的演讲视频。全面解析单点系统的可用性架构与优化/消息系统的可达性架构与优化/事务系统的一致性架构与优化。

1.互联网单点系统可用性架构与优化:
点击此处观看视频。时长63分钟,建议收藏和转发后在Wifi环境下观看

PPT





关于单点系统可用性架构的小结:
1、单点系统存在的问题:可用性问题,性能瓶颈问题
2、shadow-master是一种常见的解决单点系统可用性问题的方案
3、减少与单点的交互,是存在单点的系统优化的核心方向,常见方法有批量写,客户端缓存
4、水平扩展也是提升单点系统性能的好方案

2.互联网消息系统可达性架构与优化:
点击此处观看视频。时长36分钟,建议收藏和转发后在Wifi环境下观看。

ppt







3.互联网事务系统一致性架构与优化:
点击此处观看视频。时长67分钟,建议收藏和转发后在Wifi环境下观看。

ppt





沈剑:58到家技术总监,互联网架构技术专家,“架构师之路”公众号作者。曾任百度高级工程师,58同城高级架构师,58同城技术委员会主席,58同城C2C技术部负责人,58同城技术学院优秀讲师。

时间: 2024-10-10 18:45:46

58沈剑用3个小时的视频告诉你高可用的那些事儿的相关文章

58沈剑:秒杀系统架构优化思路

有个兄弟分享秒杀系统的优化,其观点有些赞同,大部分观点却并不同意,结合自己的经验,谈谈自己的一些看法. 一.为什么难 秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如12306抢票,亦与秒杀类似,瞬时流量更甚. 二.常见架构 流量到了亿级别,常见站点架构如上: 1)浏览器端,最上层,会执行到一些JS代码 2)站点层,这一层会访问后端数据,拼html页面返回给浏览器 3)服务层,向上游屏

【58沈剑架构系列】一分钟了解负载均衡的一切

什么是负载均衡 负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据[均匀]分摊到多个操作单元上执行,负载均衡的关键在于[均匀]. 常见的负载均衡方案 常见互联网分布式架构如上,分为客户端层.反向代理nginx层.站点层.服务层.数据层.可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现“将请求/数据[均匀]分摊到多个操作单元上执行”. [客户端层->反向代理层]的负载均衡 [客户端层]到[反向代理层]的负

【58沈剑架构系列】lvs为何不能完全替代DNS轮询

上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点: 1)nginx前端加入lvs和keepalived可以替代“DNS轮询” 2)F5能搞定接入层高可用.扩展性.负载均衡,可以替代“DNS轮询” “DNS轮询”究竟是不是过时的技术,是不是可以被其他方案替代,接入层架构技术演进,是本文将要细致讨论的内容. 一.问题域 nginx.lvs.keepalived.f5.DNS轮询,每每提到这些技术,往往讨论的是接入

【58沈剑架构系列】互联网架构,如何进行容量设计?

一,需求缘起 互联网公司,这样的场景是否似曾相识: 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题: (1)机器能抗住么? (2)如果扛不住,需要加多少台机器? 场景二:系统设计阶段,技术老大杀过来,又问了两个问题: (1)数据库需要分库么? (2)如果需要分库,需要分几个库? 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.常见的容量评估包括数据量.并发量.带宽.CPU/MEM/DISK等,今天分享的内容,就以[并发量]为例,看看如何回答好这两个问题.

【58沈剑架构系列】秒杀系统架构优化思路

一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据: 3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 二

【58沈剑架构系列】如何实施异构服务器的负载均衡及过载保护?

零.需求缘起 第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层.站点层.服务层.数据层的常用负载均衡方法. 第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进. 在这两篇文章中,都强调了“负载均衡是指,将请求/数据[均匀]分摊到多个操作单元上执行,负载均衡的关键在于[均匀]”. 然而,后端的service有可能部署在硬件条件不同的服务器上: 1)如果对标最低配的服务器“均匀”分摊负载,高配的服务器的利用率不足: 2

【58沈剑架构系列】线程数究竟设多少合理

一.需求缘起 Web-Server通常有个配置,最大工作线程数,后端服务一般也有个配置,工作线程池的线程数量,这个线程数的配置不同的业务架构师有不同的经验值,有些业务设置为CPU核数的2倍,有些业务设置为CPU核数的8倍,有些业务设置为CPU核数的32倍. “工作线程数”的设置依据是什么,到底设置为多少能够最大化CPU性能,是本文要讨论的问题. 二.一些共性认知 在进行进一步深入讨论之前,先以提问的方式就一些共性认知达成一致. 提问:工作线程数是不是设置的越大越好? 回答:肯定不是的 1)一来服

【58沈剑架构系列】一分钟写好连接池

一.如何通过连接访问下游 工程架构中有很多访问下游的需求,下游包括但不限于服务/数据库/缓存,其通讯步骤是为: (1)与下游建立一个连接 (2)通过这个连接,收发请求 (3)交互结束,关闭连接,释放资源 这个连接是什么呢,通过连接怎么调用下游接口?服务/数据库/缓存,官方会提供不同语言的Driver.Document.DemoCode来教使用方建立连接与调用接口,以MongoDB的C++官方Driver API为例(伪代码): DBClientConnection* c = new DBClie

【58沈剑架构系列】缓存架构设计细节二三事

本文主要讨论这么几个问题: (1)“缓存与数据库”需求缘起 (2)“淘汰缓存”还是“更新缓存” (3)缓存和数据库的操作时序 (4)缓存和数据库架构简析   一.需求缘起 场景介绍 缓存是一种提高系统读性能的常见技术,对于读多写少的应用场景,我们经常使用缓存来进行优化. 例如对于用户的余额信息表account(uid, money),业务上的需求是: (1)查询用户的余额,SELECT money FROM account WHERE uid=XXX,占99%的请求 (2)更改用户余额,UPDA