![](https://img-blog.csdnimg.cn/20190927151026427.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
系统设计
文章平均质量分 86
系统设计
zhifeng687
这个作者很懒,什么都没留下…
展开
-
慢sql熔断方案--饿了么数据库中间件DAL
代理层(DAL),最直观的需求是能做分库分表,能做读写分离,还可以做资源隔离、连接数隔离、连接的管理等,更重要的是还能对数据库进行相应的保护。外卖业务大多数人都是在中午下单,所以 11 点左右是饿了么的业务高峰。为了缓解数据库压力,我们会通过 DAL 层做削峰处理,当流量过大时我们会让用户消息做排队的处理,由此缓解对数据库的瞬间冲击。如果流量特别大的时候还可以做限流、熔断等处理。还有黑白名单机制,大家了解数据库运维的话会知道,如果研发写的 SQL 有问题,放入到数据库里风险会比较高。如果..转载 2022-04-20 20:10:27 · 949 阅读 · 0 评论 -
慢sql熔断方案--美团的数据库中间件DBProxy
概述首先介绍一下为什么要使用DBProxy:使用DBProxy之后,应用程序只需要在连接串中设置DBProxy的地址,不需要关注整个数据库集群的结点; DBProxy内部实现负载均衡,读写分离; Slave上下线的操作由DBA在自动化运营系统上点一下鼠标就能够完成。这样极大的减轻了DBA和应用开发人员的工作;而没有DBProxy的情况下,这些工作是由RD来实现的,引入DBProxy对于系统的可管理性和便利性都有非常大的帮助。DBProxy的主要功能介绍DBProxy的软件模...转载 2022-04-20 20:00:27 · 648 阅读 · 0 评论 -
如何设计一个URL短链服务
1. 什么是URL短链URL短链,就是把原来较长的网址,转换成比较短的网址。我们可以在短信和微博里可以经常看到短链的身影。如下图,我随便找了某一天躺在我短信收件箱里的短信。上图所示短信中,https://j.mp/38Zx5XC,就是一条短链。用户点击蓝色的短链,就可以在浏览器中看到它对应的原网址:那么为什么要做这样的转换呢?来看看短链带来的好处: 在微博,Twitter这些限制字数的应用中,短链带来的好处不言而喻:网址短、美观、便于发布、传播,可以写更多有意义的文字;...转载 2016-03-27 21:57:53 · 1242 阅读 · 0 评论 -
处理redis热key的流程思维导图
LFU缓存机制LFU(Least Frequently Used)算法,即最少访问算法,根据访问缓存的历史频率来淘汰数据,核心思想是“如果数据在过去一段时间被访问的次数很少,那么将来被访问的概率也会很低。实现class LFUCache { // 缓存容量,时间戳 int capacity, time; Map<Integer, Node> key_table; TreeSet<Node> S; public LFUCa...原创 2022-04-10 00:59:22 · 2869 阅读 · 0 评论 -
饿了么解决redis热key的业务实践
背景在 Redis 中,热 key 指的是那些在一段时间内访问频次比较高的键值,具体到业务上,商品的限时抢购、瞬时的新闻热点或某个全局性的资源,都极有可能产生热点 key。热点 key 的出现可能会对系统的稳定性和可用性造成影响,比如对应节点的网卡带宽被打满,出现丢包重传,请求波动耗时大幅上升,甚至影响到业务的正常使用,引发用户的不满。因此,在日常的工作中,我们需要着重避免这种情况的出现,比如在设计和编码阶段避免引入全局性热 key,或者在设计时考虑热 key 出现时的应对方案。可能的方案热转载 2022-04-09 23:20:49 · 291 阅读 · 0 评论 -
缓存热点自动发现和处理的架构设计实践
一、为什么要用缓存集群啥叫热 Key 和大 Value 呢?简单来说,热 Key,就是你的缓存集群中的某个 Key 瞬间被数万甚至十万的并发请求打爆。大 Value,就是你的某个 Key 对应的 Value 可能有 GB 级的大小,导致查询 Value 的时候出现网络相关的故障问题。先来看看下面的一幅图:简单来说,假设你手头有个系统,他本身是集群部署的,然后后面有一套缓存集群,这个集群不管你用 Redis Cluster,还是 Memcached,或者是公司自研缓存集群,都可以。那么转载 2022-04-09 20:25:50 · 436 阅读 · 0 评论 -
京东毫秒级热key探测框架设计与实践
在拥有大量并发用户的系统中,热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款,或许是海量用户突然涌入某个店铺,或许是秒杀时瞬间大量开启的爬虫用户, 这些突发的无法预先感知的热key都是系统潜在的巨大风险。风险是什么呢?主要是数据层,其次是服务层。热key对数据层的冲击显而易见,譬如数据存放在redis或者MySQL中,以redis为例,那个未知的热数据会按照hash规则被存在于某个redis分片上,平时使用时都从该分片获取它的数据。由于redis性能还不错,再加上集群模式,每秒我们转载 2022-04-09 19:57:09 · 484 阅读 · 0 评论 -
直播系统解决高并发下缓存热key的业务实践
直播是人类智慧的极佳体现,通过技术将模拟数据数字化,打破自然界光线和声音传播的刚性约束,实现隔空重放,让信息摆脱物理学的约束低成本传播,并自然地实现价值放大。在手机 APP、浏览器等终端上,我们可以通过一个个窗口,便捷地看到那些隔空重放的信息,或一个鲜活的人或一场热闹的戏或一堆精美的物品,商业上的人、场、” 货 “都能在这个虚拟的载体上呈现。这个载体我们一般称为直播间,或者叫房间。也引出不少耳熟的词汇,如进房间、出房间、开启房间等等。直播的场景天然以人为核心,场由人造,“货” 因人而存在,可以是转载 2022-04-09 18:48:22 · 389 阅读 · 0 评论 -
评论系统架构设计
架构设计最重要的就是理解整个产品体系在系统中的定位。搞清楚系统背后的背景,才能做出最佳的设计和抽象。不要做需求的翻译机,先理解业务背后的本质,事情的初衷。功能模块评论系统,我们往小里做就是视频评论系统,往大里做就是评论平台,可以接入各种业务形态。发布评论: 支持回复楼层、楼中楼。 读取评论: 按照时间、热度排序。 删除评论: 用户删除、作者删除。 管理评论: 作者置顶、后台运营管理(搜索、删除、审核等)。架构设计概览 BFF: comment 复杂评论业务的服务编排,比如访问转载 2022-04-09 12:15:19 · 3543 阅读 · 4 评论 -
怎么实现接口幂等性
通俗的说,用户在系统中有操作,不管重复多少次,都应该产生一样的效果或返回一样的结果的。幂等性的概念幂等(Idempotent)是一个数学与计算机学的概念,常见于抽象代数中。f(n) = 1^n // 无论n等于多少,f(n)永远值等于1在编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行,并能获得相同结果的函数 / 方法。这些函数 / 方法不会影响系统状态,因此不用担心重复执行会对系统造成改变。例如:1. 前端重复转载 2016-05-17 16:21:52 · 10664 阅读 · 0 评论 -
雪花算法解决时钟回拨问题
SnowFlake算法据国家大气研究中心的查尔斯·奈特称,一般的雪花大约由10^19个水分子组成。在雪花形成过程中,会形成不同的结构分支,所以说大自然中不存在两片完全一样的雪花,每一片雪花都拥有自己漂亮独特的形状。雪花算法表示生成的id如雪花般独一无二。snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每转载 2022-03-23 16:20:03 · 12521 阅读 · 3 评论 -
冗余数据最终一致性的架构设计
一,为什么要冗余数据互联网数据量很大的业务场景,往往数据库需要进行水平切分来降低单库数据量。水平切分会有一个patition key,通过patition key的查询能够直接定位到库,但是非patition key上的查询可能就需要扫描多个库了。此时常见的架构设计方案,是使用数据冗余这种反范式设计来满足分库后不同维度的查询需求。例如:订单业务,对用户和商家都有查询需求:Order(oid, info_detail);T(buyer_id, seller_id, o...转载 2016-08-24 14:47:32 · 1635 阅读 · 0 评论 -
1亿数据用户中心的分库分表架构设计
这里是以下面的symbol和label的形式出现。label是可以修改的,即是用户自定义用于方便阅读的由于是用class的属性值进行符号的分类,所以这里的value值,是class的属性值之一转载 2015-09-20 20:50:17 · 1209 阅读 · 0 评论 -
1亿数据订单中心的分库分表架构设计
订单中心,是互联网业务中,一个典型的“多key”业务,即:用户ID,商家ID,订单ID等多个key上都有业务查询需求。随着数据量的逐步增大,并发量的逐步增大,订单中心这种“多key”业务,架构应该如何设计,有哪些因素需要考虑,是本文将要系统性讨论的问题。什么是“多key”类业务?所谓的“多key”,是指一条元数据中,有多个属性上存在前台在线查询需求。订单中心是什么业务,有什么典型业务需求?订单中心是一个非常常见的“多key”业务,主要提供订单的查询与修改的服务,其核心元数据为:Or.转载 2015-09-21 23:47:43 · 593 阅读 · 0 评论 -
1亿数据帖子中心的分库分表架构设计
帖子中心,是互联网业务中,一类典型的“1对多”业务,即:一个用户能发布多个帖子,一个帖子只有一个发布者。随着数据量的逐步增大,并发量的逐步增大,帖子中心这种“1对多”业务,架构应该如何设计,有哪些因素需要考虑,是本文将要系统性讨论的问题。什么是x对x?所谓的“1对1”,“1对多”,“多对多”,来自数据库设计中的“实体-关系”ER模型,用来描述实体之间的映射关系。什么是“1对1”业务?用户中心,一个用户只有一个登录名,一个登录名只对应一个用户,这是典型的1对1业务。什么是“1对多”业务转载 2015-09-22 00:31:14 · 561 阅读 · 0 评论 -
调度系统设计精要
系统设计精要是一系列深入研究系统设计方法的系列文章,文中不仅会分析系统设计的理论,还会分析多个实际场景下的具体实现。这是一个季更或者半年更的系列,如果你有想要了解的问题,可以在文章下面留言。调度是一个非常广泛的概念,很多领域都会使用调度这个术语,在计算机科学中,调度就是一种将任务(Work)分配给资源的方法1。任务可能是虚拟的计算任务,例如线程、进程或者数据流,这些任务会被调度到硬件资源上执行,例如:处理器 CPU 等设备。图 1 - 调度系统设计精要本文会介绍调度系统的常见场景以及设计.转载 2015-10-04 19:46:15 · 555 阅读 · 0 评论 -
使用DDD重构事务脚本实现
架构这个词源于英文里的“Architecture“,源头是土木工程里的“建筑”和“结构”,而架构里的”架“同时又包含了”架子“(scaffolding)的含义,意指能快速搭建起来的固定结构。而今天的应用架构,意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在应用开发中架构之所以是最重要的第一步,因为一个好的架构能让系统安全、稳定、快速迭代。在一个团队内通过规定一个固定的架构设计,可以让团队内能力参差不齐的同学们都能有一个统一的开发规范,降低沟通成本,提升效率和代码质量。在做架构设计.转载 2016-09-01 16:53:51 · 11136 阅读 · 0 评论 -
交易系统的领域驱动设计
背景交易系统作为电商平台架构的核心系统之一,它为解决什么问题呢?我认为它应最大化满足买卖双方的价值交换,在交易前、后提供完备的服务。交易前:客户购买下单,支付金额,电商网站确认支付后,进行配送发货。交易后:在退换周期内,客户申请退换,电商进行退换处理,并返还客户金额;同时对交易金额进行结算。完整交易需要图中多个核心流程来支撑,其本身的业务链条比较长;它会引入订单、支付单、配送单、售后服务单等多个领域概念;产生营销活动抵扣、支付方式、退换货策略等不同的业务规则;使系统具有较高的复杂性。对于交转载 2015-09-21 22:20:49 · 1063 阅读 · 0 评论 -
领域建模分析方法
领域模型之间的联系,我们要怎么理解呢?以上面这位某人A为例,本次我们所要提取的特征,是父亲。父亲与母亲,丈夫与配偶,关系是1对1的。也就是一夫一妻制。父亲与孩子,关系是1对N的,一位父亲,可以有一个孩子,也可以有多个孩子。母亲与孩子的关系,也是1对N的。所以这一家三口之间的联系,可以简单用这张图来表示:当然领域模型的图形化还有很多种方式,例如UML类图、状态图、时序图等,这边就不一一介绍。1.2 为什么要学习领域模型“基础设施决定上层建筑” —— 马克思。老祖宗教导我..转载 2015-09-21 22:53:51 · 1808 阅读 · 0 评论 -
阿里限流中间件Sentinel 原理-如何为系统设置扩展点
一个好的框架有一个很重要的特性就是扩展性要好,不能把系统写死,后期想要新增功能时,可以通过预留的扩展点进行扩展,而不是去修改原来的代码。本篇文章我就来跟大家分享下 Sentinel 在扩展性这块是怎么做的,都有哪些扩展点。1模块设计第一点从模块设计上,Sentinel 就充分考虑了扩展性,Sentinel 核心的功能其实就在 sentinel-core 模块中,要想在自己的系统中使用 Sentinel 最少只需要引入这一个依赖就够了。其他的都是为了框架的易用性和高可用性等做的扩展。我们来转载 2017-02-09 15:34:30 · 1360 阅读 · 0 评论 -
业务架构与产品架构设计实践
系统架构的分解,先从业务域进行分解。狭义的业务域具有商业的概念,从这个概念来看,有的系统没有业务域,当如果宽泛一点来看,业务域就是问题域,问题域总是存在的。业务域的分解,首先是从系统需求入手,在需求初期可能你就得到的只是一句比较模糊的需求描述,这些需求可能来自于老板、运营或者用户(比如下图的场景)。直接把这句话作为核心产品功能是不恰当的,合理的做法是先把这个产品的所有问题域列清楚。列出问题域问题域,是指自己的产品能够解决的所有问题的空间集合。从核心需求出发,将所有当前需要解决、未来可能需要解转载 2015-09-22 00:21:47 · 2396 阅读 · 0 评论 -
系统架构系列(一):系统架构概念、分类和特性
一、推导系统架构的公式1.1 系统架构概念拆分在学习一门技术的时候,一定要知道是什么、为什么、怎么做。系统架构这个概念本身就非常大,而且有各种各样的定义,初学者会遇到这样的困境:到底什么是系统架构?不管什么样的定义,笔者相信知识只有内化成为自己的才最重要,否则我们只是不断地输入而没有消化。先不看之前的定义是什么,从 " 系统架构 " 这四个字开始推导其公式。" 系统架构 " 可以拆分成两部分:“系统 " 和 " 架构”。“系统 " 在百科中的定义是" 系统就是若干相互联系、相互作用、相互依赖的要转载 2015-09-23 11:21:12 · 2753 阅读 · 0 评论 -
业务架构设计方法论- 业务与业务隔离、业务与平台隔离
在上一篇文章中主要讲了业务架构的基础部分,整体的业务架构还有一些其它点要考虑,如业务之间的彼此隔离、业务与技术 (平台) 的隔离、业务能力地图的可视化、业务 mock 能力、业务监控等,本篇文章主要讲述这些内容。一、业务彼此隔离在较小的公司可能要体现这个没有对应的业务场景,但在大公司中,如果业务是平台型的,承接的业务方较多,业务方之间的需求还不一样时,就体现出了业务与业务之间的隔离。比如,优惠券业务是平台型业务,有多个业务线的业务方接入,它们的诉求也不尽相同:有的要实现业务线内不同用户角色的打通 (转载 2015-10-05 21:41:45 · 4526 阅读 · 1 评论 -
技术架构之高可扩展系统设计方法论—— 规范、识别、注册、运行
可扩展性是衡量架构设计的一个因素,也经常被开发者提到。但是,一个系统要设计出比较好的可扩展性是有一定难度的,而且可扩展性体现在不同层次上,有大的可扩展性,也有小的可扩展性,本文从可扩展的本质出发,通过平时常用的框架来印证,最后通过实际案例说明如何设计高可扩展性系统。一、可扩展的本质是什么?可扩展的意思是在面对变化时,用最少的代价去实现,平时我们听得最多的是面向抽象(接口) 编程,如果只是把这里的抽象理解成接口,那么就有些狭隘了,抽象是通式通法,而接口只是其中一个,所以在谈可扩展实现之前一定要讲清楚可转载 2015-10-04 17:23:05 · 4016 阅读 · 0 评论 -
技术架构之高并发系统设计方法论
技术架构在业内并没有形成约定的统一认识,不同人的理解也不一样,有的人认为引入了中间件就是技术架构。笔者并不这么认为,如果是这样的话,只是将中间件堆在一起就是技术架构,那技术架构就是千篇一律了。在相似的业务场景下,技术架构相似是可能的,但绝对不是一种技术架构能包含所有的架构。这篇文章主要是探讨什么是技术架构、技术架构要解决什么问题、最后以高并发场景为例画出技术架构图。一、什么是技术架构技术架构是系统架构设计的一种,换言之,它是系统架构的一个实例,那它应该是具备系统架构的普遍特征,在第一篇文章中已经提到转载 2017-02-15 21:03:51 · 4696 阅读 · 0 评论 -
系统架构系列(二):系统架构的目的、难点和方法
引言在本系列的第一篇文章中已经给出系统架构的公式定义:系统架构 = 要素 + 连接 + 解决特定的问题,本篇文章重点讨论应对系统架构的方法。如今,系统架构在业内还没有定型的固定方法,一般会讲:需求分析、系统分析与设计、UML、领域建模、设计模式、软件工程等,笔者不打算这样讲,这样下来会有厚厚一本书,希望从简洁、可落地实践的角度去阐述系统架构,后面的文章再给出每种架构具体可实践操作的方法。一、系统架构的本质目的我们已经知道系统架构是什么,有必要讲一下系统架构的目的,即为什么要进行系统架构。对于转载 2015-09-28 20:59:30 · 4484 阅读 · 0 评论 -
业务架构的定义、特性和方法
引言业务架构一般不被开发重视,开发人员喜欢追求新技术,而技术是服务于业务的,现在没有一项技术是自娱自乐的,一定要支撑业务,否则没有场景。设计好业务架构要考虑的方面比较多,要做到业务彼此隔离、业务与技术 (平台) 隔离,从业务架构中能看得出整体业务的流程运转、业务产品的能力、业务领域对象…接下来的两篇文章将重点讲业务架构。一、什么是业务架构在上篇文章中提到系统架构的方法:系统性思考、分解、抽象、模式,这是总的纲要,针对不同类型的业务架构,要结合本身的特性再加以细化。业务架构是系统架构的一种,那转载 2016-06-01 15:05:40 · 11632 阅读 · 1 评论 -
分布式缓存重建并发冲突问题
什么是分布式缓存重建并发冲突问题?很简单,多个缓存服务实例提供服务,发现缓存失效,那么就会去重建,这个时候回出现以下几种情况: 多个缓存实例都去数据库获取一份数据,然后放入缓存中 新数据被旧数据覆盖 缓存 a 和 b 都拿了一份数据,a 拿到 12:00:01 的数据,b 拿到 12:00:05 的数据 缓存 b 先写入 redis,缓存 a 后写入。 以上问题有多重解决方案,如: 利用 hash 分发 相同商品分发到同一个服务中,服务中再用队列去重建 但是这就转载 2017-01-21 15:06:00 · 6060 阅读 · 0 评论 -
缓存多维度化(解决大value缓存问题)
如果实时性要求的不高的怎么解决?三级缓存架构的技术方案如果是做实时性要求不高的数据,比如说商品的基本信息,等等,我们采取的是三级缓存架构的技术方案,就是说由一个专门的数据生产的服务,去获取整个商品详情页需要的各种数据,经过处理后,将数据放入各级缓存中,每一级缓存都有自己的作用。注意事项1、大型缓存全量更新问题(1)网络耗费的资源大(2)每次对redis都存取大数据,对redis的压力也比较大(3)redis的性能和吞吐量能够支撑到多大,基本跟数据本身的大小有很大的关系如果数据.转载 2016-11-12 23:08:14 · 1677 阅读 · 0 评论 -
有赞缓存热点探测实现
TMC,即“透明多级缓存(Transparent Multilevel Cache)”,是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。TMC 在通用“分布式缓存解决方案(如 CodisProxy + Redis,如有赞自研分布式缓存系统 zanKV)”基础上,增加了以下功能: 应用层热点探测 应用层本地缓存 应用层缓存命中统计 以帮助应用层解决缓存使用过程中出现的热点访问问题。为什么要做 TMC使用有赞服务的电商商家数量和类型很多,商家会不定期做一些“商转载 2017-07-18 11:25:04 · 13874 阅读 · 1 评论 -
记一次评论系统缓存优化实践
背景该项目是当时公司最重点落地战略性的项目之一,离开项目组时DAU达到了6000W以上,主要做富媒体feed流。评论指的是对单条feed的评论,要求评论近实时展示。本文主要分析缓存模型。公司当时的缓存中间件主要是couchbase,所以主要是使用了couchbase缓存。倒也不影响对缓存架构的理解。优化过程第一版评论系统主要的需求是,第一可展示评论,第二可翻页(一页20条以内)由于项目初期用户量不大,评论量自然有限,同时feed的热点数据也比较少,所以缓存设计上相对简单。仅缓存最新的转载 2016-05-31 10:02:49 · 16146 阅读 · 1 评论 -
长列表分页缓存策略
通常,对于长列表加载的场景,都需要进行分页, 如最近的世界杯体育垂站项目中的赛程页,评论流,直播流。而为了提高分页加载的性能,往往需要对分页进行缓存。 下面总结对两种常见的分页缓存的策略, 适用场景以及各自的优缺点。策略一: 直接对分页结果缓存顾名思义,就是直接缓存每次分页查询的结果。适用场景 列表长度无法提前预知 数据和排序不经常变更 优点: 实现简单 通常能获得不错的性能。由于直接缓存分页的结果,因此只需一次IO就能把数据...转载 2017-01-13 20:40:25 · 15768 阅读 · 0 评论 -
AutoLoadCache – 再谈缓存的穿透、数据一致性和最终一致性问题
缓存是用于解决高并发场景下系统的性能及稳定性问题的银弹。本文主要是讨论我们经常使用的分布式缓存 Redis 在开发过程中的相关思考。1. 如何将业务逻辑与缓存之间进行解耦?大部分情况,大家都是把缓存操作和业务逻辑之间的代码交织在一起的,比如(代码一):从上面的代码可以看出以下几个问题:缓存操作非常繁琐,产生非常多的重复代码; 缓存操作与业务逻辑耦合度非常高,不利于后期的维护; 当业务数据为 null 时,无法确定是否已经缓存,会造成缓存无法命中; 开发阶段,为了排查问题,经常需转载 2015-09-24 00:34:53 · 12013 阅读 · 0 评论