首页
学习
活动
专区
工具
TVP
发布

性能与架构

专栏作者
597
文章
1146889
阅读量
116
订阅数
购物车之架构设计!
在上一篇文章 购物车设计之需求分析 描述了购物车的通用需求。本文重点则在如何实现上进行架构上的设计(业务+系统架构)。
dys
2021-11-12
1.5K0
Facebook 直播是如何承受海量压力的?
挑战 Facebook 在 2016 年底时的月活用户数有 1860 万,Facebook live 的压力很大,有大量的人开直播,有大量的用户观看直播 整体来看,直播的挑战在于: 需要能够同时支持数百万的直播流 对于同一个直播流,需要能够支持数百万的用户 而且直播有一个非常明显的特点,就是非常集中的流量峰值,例如某个名人开了直播,很快就会有大量的用户进来,产生巨大的流量峰值 架构 当很多请求一起进来时,会引发惊群效应,导致严重的流问题,例如延迟、丢包、新用户无法连接 …… 对于这种情况,首先要做的就是阻止
dys
2018-04-04
7620
大型图片网站 500px 是如何处理图片的?
500px 是一个国际大型图片类网站,致力于摄影分享、发现、售卖的专业平台 需要处理海量用户上传的图片,并且有N倍于上传量的图片展示量 根据一年前公布的数据,500px 每天会产生20TB的数据传输量 500px 的基础架构 开发语言主要是 Ruby on Rails 前端请求处理使用 Nginx 服务集群使用 HAProxy 处理负载均衡 数据存储使用 MySQL, MongoDB, Redis, Memcached Sidekiq 在后台做任务处理 服务器使用 Amazon 的弹性云服务 EC2 图片
dys
2018-04-03
1.4K0
美国建站平台 Wix 的架构变迁
背景 Wix 是全世界最大的自助建站云平台,可以让每一个人通过拖拽等简单的方式轻松的创建一个漂亮的网站 这个平台上已经创建了6000万个网站,覆盖190个国家 2PB 的用户文件,每天增长1.5TB 3个数据中心,使用2个云平台(Google, AW) 每天150亿次的http请求 400人的工程师团队 架构 Wix创建于2006年,初始阶段使用的是传统的单体架构,技术构成包括Java, Hibernate, Ehcache, Tomcat, MySQL 2008年时,这个架构逐渐显现出一些问题 Wix
dys
2018-04-03
2.7K0
系统高峰限流
限流是通过限制访问数量,防止系统压力过大而崩溃,是保障系统稳定性的一道屏障 例如网站计划做促销活动 活动前会预估访问量,然后进行压力测试和预演,如果现在的性能无法满足,那么就需要通过优化或者扩容来达成目标 活动开始后,如果实际情况超过了预估值,通常会使用服务降级等方式来降低压力,如果还是不行,就要限流了,放弃一部分用户的访问,来保证系统整体的稳定 具体如何限流呢?之前看过淘宝工程师龙隆介绍的策略,思路很简洁,因为我的系统访问量比较平稳,没有做限流的处理,就没做相关测试,下面把龙隆的方法整理出来,来给自己
dys
2018-04-03
9830
使用服务降级来减低系统负载
之前在京东的技术交流会上,京东架构师分享了服务降级策略 1为什么使用服务降级 在618店庆、双十一购物节等大型活动中,系统压力非常大,这个时候最重要的就是系统的可用性和稳定性 对于非必要的功能服务,都可以通过降级的方式暂时停掉,等到系统压力平稳后在升到可用 例如在交易下单环节,推荐服务就不是核心功能,可以降级为暂停,让出系统资源来保证核心服务 2服务降级的维度 (1)页面降级 比如下单后的成功页面挂了,那么就直接跳转到订单中心,用户可以看到订单,也可以操作 如果订单中心也挂了,那么就直接跳转到订单详情页面
dys
2018-04-03
6220
又拍网数据库架构案例分析
这篇文章是对又拍网公布的数据库案例的分析总结 又拍网是一个大型照片分享社区,数据库架构也是从简单到复杂发展起来的 数据库进化过程 (1)一主一从 最初是由一台主库和一台从库组成,当时从库只用作备份和容灾,当主库出现故障时,从库就手动变成主库 随着压力的增加,加上了memcached (2)一主多从 通过添加多个从库来分流查询压力 (3)数据库拆分 随着数据量的增加,读写压力都迅速增加,决定进行数据库拆分,将数据存放到不同的数据库服务器中 数据库拆分 一般可以按两个纬度来拆分数据:
dys
2018-04-03
7100
1号店架构演进读后感
前几天看了一篇介绍1号店架构演进的文章,其中给我印象最深的是他们的日志系统,非常完善,我之前所在的大公司,和现在创业中的小公司都没有做到,日志是一种重要思维方式,值得关注 日志思维已经深入融入1号店的架构理念,成为重要的基础设施 早期的1号店,也是用简单的MVC架构,控制层处理业务逻辑、数据库交互,在初期,方便快捷,成本低响应快 随着业务变得复杂、人员规模爆发式增长,这种强耦合结构成了巨大的瓶颈,代码耦合度高互相冲突、出错概率和事故概率明显提升,业务需求不能快速响应,于是Service化成为第一前提
dys
2018-04-03
5700
网站架构演化过程
网站的架构通常都是逐渐演化完善的,下面就是一个常规的成长过程 (1)初识阶段 一台服务器 最初的架构,应用程序、数据库、文件都部署在一台服务器上 (2)应用服务和数据服务分离 随着业务的扩展,一台
dys
2018-04-03
8230
构建可伸缩的Web架构
互联网产品的一个特点是开始的时候规模都很小, 几个人的小团队,少量的启动资金,就开始运营了 刚开始的时候,用户也少,所以只要一台服务器就可以应付所有的用户访问,这时整个系统(数据库、Web应用、文件
dys
2018-04-02
1K0
高可用性方案Keepalived工作原理
随着系统架构的逐渐演化,服务器的数量和结构会越来越复杂,例如web服务器集群的搭建,提高了系统的性能,同时也提高了系统维护的复杂度,我们需要对集群中各台服务器进行监控,来保证为用户提供服务的是正常运行的服务器,整体系统的可用性就至关重要 Keepalived提供了很好的高可用性保障服务,它可以检查服务器的状态,如果有服务器出现问题,Keepalived会将其从系统中移除,当这台服务器可以正常工作后,Keepalived再将其放入服务器群中,这个过程是Keepalived自动完成的,不需要人工干涉,我们只需要
dys
2018-04-02
5720
没有更多了
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档