![](https://img-blog.csdnimg.cn/20201014180756738.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
方案设计
库昊天
这个作者很懒,什么都没留下…
展开
-
商品中心 --- 淘宝类目属性体系
转载:浅谈淘宝类目属性体系:商品搜索背后的逻辑架构商品分类体系的演变商品数量很少,没有分类;商品数量过百,开始使用一级类目;商品数量成千上万,开始使用多级类目,即类目树;商品数量达到百万级,甚至亿级别,开始使用“类目+属性”的分类体系,避免类目层级过深;前后台类目分离,满足不同用户需求(卖家通过后台类目发布商品,买家通过前台类目选购商品);整体架构 淘宝类目属性体系主要由后...转载 2019-11-13 17:41:12 · 6093 阅读 · 1 评论 -
商品中心 --- 基本概念
SPU和SKU SPU指的是商品,SPU属性就是不会影响到库存和价格的属性, 又叫关键属性,与商品是一对一的关系;SKU指的是具体规格单品,SKU属性就是会影响到库存和价格的属性, 又叫销售属性,与商品是多对一的关系。 以iphone6s举例,它身上有很多的属性和值, 比如毛重: 420.00 g产地: 中国大陆容量: 16G, 64G, 128G颜色: 银, 白, 玫瑰金...原创 2019-07-24 23:18:31 · 3540 阅读 · 0 评论 -
库存扣减
扣减时机 何时扣减扣减库存,目前有两种主流方式:方式1:下单减库存——即用户下单成功时减少库存数量优点:用户体验好,系统逻辑简单;缺点:会导致恶意下单或下单后却不买,使得真正有需求的用户无法购买,影响真实销量;解决办法:设置订单有效时间,若订单创建成功N分钟不付款,则订单取消,库存回滚;限购,用各种条件来限制买家的购买件数,比如一个账号、一个ip,只能买一件;风控,从技术角...原创 2019-10-17 17:13:37 · 3837 阅读 · 0 评论 -
订单系统设计 --- 订单中心存储方案
目标 为某垂直领域的电商平台设计一个订单中心,用户、商家和运营可以对订单中心进行不同的操作;需求分析C端:访问量大,数据的实时性和一致性要求高,主要是订单列表和订单详情的查询;B端:访问量适中,对数据的实时性和一致性有一定容忍度,主要是B端展示的几个维度的分页查询;M端:访问量低,查询条件复杂多变,查询的数据量大,对系统可用性、数据的实时性和一致性等容忍度最高;存储方案设计...原创 2019-10-16 10:08:40 · 3203 阅读 · 0 评论 -
订单系统设计 --- SaaS订单中心存储方案
SaaS订单中心作用 为油站提供订单管理能力,管理线上(各种互联网加油平台,比如小桔加油、车主邦等)、线下等不同渠道的订单;需求分析原创 2019-10-14 09:37:57 · 1953 阅读 · 0 评论 -
用户中心 --- 存储方案
需求分析用户侧 用户侧对用户中心的查询特点是:查询频次高,基本上都是单条查询,对数据的实时性和一致性要求高,99%的请求为uid查询用户信息,1%的请求为根据用户名/邮箱/手机号等条件查询用户信息;运营侧 运营侧对用户中心的查询特点是:查询频次低,查询数据量大,查询条件复杂(年龄、性能、注册时间等),对数据的实时性和一致性容忍度高;存储方案设计 整体思路:用户表按照uid分库分表...原创 2019-10-12 17:47:15 · 472 阅读 · 0 评论 -
RESTFUL理解
RESTful是什么? Http协议作者提倡的一种协议使用风格:用HTTP动词(GET,POST,DELETE等)描述操作,用URL定位资源;RESTful提出背景 随着Http协议的广泛使用,越来越多的开发人员都将其作为传输协议,而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子,SOAP消息完全就是将Http协议作为消息承载,以至于对于Http...原创 2018-07-27 11:24:09 · 229 阅读 · 0 评论 -
转账方案设计
数据一致性方案方案1A业务处理和消息发送在同一个本地事务中执行,执行完成后本地消息表中有条status=0记录;B收到消息后,在同一个事务中进行业务处理和消息发送(返回响应);如果B处理失败,由Broker进行失败重试;A收到响应消息后更新对应的消息状态为1;A端本地会启动定时任务,定时扫描状态为0的消息,发出告警,甚至进一步可以执行数据补偿操作;方案2A业务...原创 2018-08-09 15:36:43 · 1316 阅读 · 0 评论 -
如何合理地估算线程池大小?
整体思路首先,确定线程池要执行任务的性质:CPU密集型或者IO密集型;如果是CPU密集型,说明请求的处理比较占用CPU资源,瓶颈在于CPU,增加线程数作用不大;如果是IO密集型,说明请求的处理占用IO资源,CPU比较空闲,此时应该合理地增加线程数;实际操作Step1:预估初始大小 Step2:调整初始大小 根据压测目标,对初始值进行调整,得到最佳的性能指标。...原创 2018-08-01 11:31:57 · 1090 阅读 · 0 评论 -
系统日志方案设计
前后端交互系统前端感知异常与不感知异常的区分有多重方法:不同的异常类或者相同的类,不同的错误码区间等等;有多种交互形式的开放系统原创 2018-10-02 17:11:32 · 1927 阅读 · 0 评论 -
权限模型 --- RBAC模型
RBAC模型 RBAC(Role-Based Access Control)基于角色的访问控制:引入角色的概念,将用户和权限解耦,避免每加入一个用户添加众多权限;一个用户可以同时有一个或多个角色;每个角色拥有一组权限,当用户有多个角色时,其拥有的权限为多个角色权限的并集;参考:https://www.uisdc.com/100-solutions-for-character-p...转载 2019-04-03 23:19:53 · 249 阅读 · 0 评论 -
系统过载保护
什么是系统过载? 系统过载是指当前的外部请求量超过了系统的最大处理能力。比如,某系统每秒最多处理100条请求,但是它每秒收到的请求有200条,此时则认为该系统已经过载;系统过载的影响 系统过载会导致系统负载变高,其影响按照严重程度从低到高依次为:请求RT变长、服务不可用、上下游系统级联故障;过载保护的最终的目的:在系统过载时,服务还能提供一个稳定的较高的处理能力;系统过载方案 ...原创 2019-06-01 12:32:33 · 2396 阅读 · 0 评论 -
读超时小于系统处理时间问题思考
问题描述 系统A调用系统B的服务,系统A设置了超时上限t1(读超时,或者熔断超时等),系统B服务处理时间为t2。当t1 < t2时,系统A会抛出超时异常,系统B可能处理成功也可能失败,但是系统A无法感知,如下图所示:...原创 2019-07-01 09:32:53 · 261 阅读 · 0 评论 -
订单系统设计 --- 交易快照
含义 买卖双方在成交时记录当时交易状况的一张“照片”,即交易快照为一份静态数据,记录了交易时的数据,特别是容易变化的数据,比如商品信息,以及优惠信息等;作用 作为发生交易争执时的判断依据;范围 订单信息中已经包含了交易时的很多信息,为避免重复,交易快照存储容易发生变化的信息的详情,比如淘宝存储了商品详情,如上图所示;存储时间 不同公司根据具体的业务情况来决定,目前淘宝是永久...原创 2019-09-28 16:09:04 · 12423 阅读 · 0 评论 -
订单系统设计 --- 系统优化
订单查询实时性要求高的查询走DB;复杂查询或非实时查询走ES;避免深分页查询,即limit m,n中的m不要过大;原创 2019-09-28 16:58:51 · 431 阅读 · 0 评论 -
ConfigServer架构
ConfigServer2.0架构Consumer/Provider启动时,通过统一域名从Address Server获取ConfigServer集群的地址列表;Provider随机选取一台机器建立长连接,并进行服务注册;ConfigServer集群中的机器接受到服务注册信息后,广播到集群其它机器;ConfigServer集群中的机器推送对应的服务注册信息到连接的Consumer;...原创 2018-07-07 17:56:50 · 2980 阅读 · 1 评论 -
前后端分离演化史
什么是前后端分离?过去,前后端分离是从物理上做区分的:认为只要是客户端的就是前端,服务器端的就是后端;当前,前后端分离从职责上进行划分:前端负责 View 和 Controller 层,后端只负责 Model 层; MVC模式 缺点:前后端代码混杂在一起,前端开发重度依赖后端的开发环境,且部署成本大;前后端职责不够明确,Controller仍处于灰色地带,页面路由等功...原创 2018-07-24 17:05:14 · 1959 阅读 · 0 评论 -
系统预热方案
JIT预热问题:机器重新部署时出现load高、rt高的现象; 原因:重新部署后,JVM需要一段时间识别出热点代码,这段时间内代码都是边解释边执行的,损耗性能。 方案:定制JVM,通过Beta检测出节点代码,生成预热文件,然后推送到集群其它机器,JVM加载到预热文件后将热点代码通过JIT编译成机器代码。原创 2017-11-22 20:46:46 · 1541 阅读 · 0 评论 -
插件平台设计方案
可能的技术点: 待补充。。。原创 2017-11-14 16:19:48 · 351 阅读 · 0 评论 -
慢SQL熔断方案
问题 现有数据开放平台,通过执行用户的SQL命令提供数据查询服务。用户的SQL命令具有不确定性,当出现慢sql时会影响系统的稳定性,主要表现是服务器线程池被占满,造成雪崩效应,其它正常sql无法正常执行,出现系统假死现象。熔断方案 按照某个维度(用户、SQL等)进行熔断,如果采样周期T内SQL超时的情况的超过设定阈值N,进行熔断降级并且发送通知,如下图所示: 该方案具有以下特点:及时性:原创 2017-11-09 17:26:45 · 1533 阅读 · 0 评论 -
系统稳定性保障
常见保护措施限流算法漏桶算法漏桶算法的主要思想如下:漏桶容量固定,按照固定速率流出水滴直到桶变空;水滴可以以任意速率流入漏桶,如果桶满则溢出(丢弃); 令牌桶算法令牌桶算法的主要思想如下:桶的容量固定,令牌被按照固定的速率加入到桶中;桶满则溢出(丢弃);请求到来时先获取令牌,获取到则进行处理,否则阻塞、等待或者拒绝; Guava的RateLimiter提供了原创 2017-11-09 14:29:24 · 2848 阅读 · 0 评论 -
Groovy脚本热更新
背景: Java应用定时调用脚本,采集系统监控信息。调用方式1:边解释边执行 如下图所示,当监听到脚本变化后,只需要在内存中更新脚本内容即可,下次执行eval时就能执行最新的脚本了。 调用方式2:一次编译,多次执行 如下图所示,当监听到脚本变化后,需要重新编译脚本,然后缓存CompiledScript,定时执行CompiledScript.eval()。原创 2017-10-30 17:29:52 · 1877 阅读 · 0 评论 -
分布式监控中心设计方案
要求:作为各个应用的配置中心,提供持久化存储和配置变更推送的服务。持久化意味着应用的配置数据不能丢失,配置变更推送是指配置变更后能后通知到客户端。方案1:Zookeeper作为配置中心 原理: Znode节点数据会被持久化到磁盘文件,不存在数据丢失情况;Wather机制,Znode节点变更时会发出通知。读写能力无法水平扩展的方案:读能力水平扩展,写能力不变的方案: 局限性: 配置数据总量不能超原创 2017-11-06 20:22:23 · 792 阅读 · 0 评论 -
分布式环境下全局唯一ID的生成方案
方案1:UUID优点:能够非常简便地保证分布式环境中的唯一性; 缺点:长度过长,包含32个字符和4个短线;没有业务含义,不便于问题排查;方案2:数据库主键单库:主键id 优点: id连续、唯一,且id大小反应先后顺序; 缺点:分布式应用需要共享该单表,且单表的存储量有上限;原创 2017-10-19 21:06:00 · 471 阅读 · 0 评论 -
监控中心方案设计
场景1:公司内部的机器有数万台,需要对每台机器的运行情况进行监控告警,包括系统监控、JVM监控及JDBC监控等,要求尽可能让应用无感知,且易升级维护。 部署方案 启动: StartAgent作为系统基础环境,机器分配之后就启动。应用启动之后与StartAgent建立连接传输JVM、JDBC等监控信息,StartAgent本身采集系统监控信息,然后将所有的监控汇总传送到监控中心。 升级:如果是D原创 2017-10-26 20:58:36 · 1817 阅读 · 0 评论 -
自适应流控方案
入口流控自适应方案问题:在Netty中引入业务线程池带来的问题就是速率不匹配,如果IO线程接受数据的速度超过业务线程的处理速度,就会出现缓冲队列溢出,此时需要能够对客户端的发送速率进行控制。 如下图所示,提供了一种基于TCP Flow-Control机制的自适应流控方案。当缓冲区溢出时,服务端会按一定的规则选取出最消耗业务线程资源的客户端,然后将客户端对应连接的auoread属性设置为f原创 2018-01-23 14:28:40 · 900 阅读 · 0 评论 -
客户端隔离策略
应用场景 应用依赖了某个客户端的Jar包,其依赖1.0版本的Jar包X。按照Maven的依赖仲裁原则,如果存在更短的依赖路径或者依赖路径相同,依赖声明靠前,都会影响客户端依赖的X包的版本,需要通过某种方式能够让客户端依赖的X包不受应用的影响。 解决方案方案一:scope为provided说明:使用maven对客户端打包时,将scope改为provided,由应用提供依赖的X包。这种方案要求X包的原创 2018-02-26 16:02:51 · 586 阅读 · 0 评论 -
消息中间件MetaQ高性能原因分析
转载:https://yq.aliyun.com/articles/52533?spm=a2c4e.11153940.blogcont93815.18.626e2684nqgU88#序列化和反序列化各序列化框架时间性能对比: 各序列化框架空间性能对比: 综合来看,Google的Protocol Buffers是最佳选择,不管软件的质量、社区活跃、软件的后续发展上来说,都...转载 2018-07-09 09:33:49 · 517 阅读 · 0 评论 -
分布式配置中心Diamond
架构设计 Diamond架构由三部分组成:ConfigServer、DataServer和MySql存储,如下图所示: ConfigServer:管理DataServer集群,将客户端与DataServer集群解耦,上下线、扩容对客户端不感知;DataServer:提供配置的持久化管理、动态推送等服务; MySql存储:配置数据的持久化存储,采用一主两备的部署方式保障数据的安全;...原创 2018-06-24 11:37:20 · 6010 阅读 · 0 评论 -
系统设计 --- 异常处理
整体思路应用内部:在逻辑上对应用分层,所有的异常统一抛到某层处理(日志处理和异常封装);对外服务或接口:统一返回封装成Result返回,如下图所示: 应用分层 开放接口层:对外暴露的RPC 接口等;显示层:模板渲染并执行显示的层。当前主要是 velocity 渲染,JS 渲染,JSP 渲染,移动端展示等。Web 层:主要是对访问控制进行转发,各类基本...原创 2018-05-15 20:05:16 · 3246 阅读 · 0 评论 -
日志规约
使用日志框架API 应用中不可直接使用日志系统(Log4j、Logback)中的 API,而应依赖使用日志框架SLF4J 中的 API,使用门面模式的日志框架,有利于日志框架的升级和使用统一。import org.slf4j.Logger;import org.slf4j.LoggerFactory;private static final Logger logger = Logge...转载 2018-05-15 15:49:02 · 358 阅读 · 0 评论 -
DPS安全策略
术语AK(Acess Key):唯一标识用户身份;SK(Secret Key):给用户颁发的密钥,与AK唯一对应;安全校验内容身份认证;数据完整性校验;权限控制(水平权限控制、垂直权限控制和过期时间);安全校验过程前置机从服务端获取Token 利用HMAC算法验证前置机的身份和数据完整性校验,使用Https进行数据传输,保证数据通道的安全性。服务...原创 2018-04-20 14:06:08 · 502 阅读 · 0 评论 -
系统稳定性保障之网络篇
背景:在弱网、海量连接场景下,系统稳定性的保障。 参考:http://www.infoq.com/cn/articles/netty-million-level-push-service-design-points?utm_source=infoq&utm_campaign=user_page&utm_medium=link;原创 2018-05-01 17:08:25 · 516 阅读 · 0 评论 -
DPS多域架构方案设计
实现目标数据容灾:重要数据域间存在备份;跨域数据推送;低延时;设计方案设备使用统一域名,实现就近接入;内部应用就近写入当前所在域,通过OSS实现数据备份;DPS基础配置数据通过GN实现多域同步;目标实现低延时:内部引用就近写,前置机就近读,使用OSS跨域复制将数据同步到其它域(阿里云专有网络);数据容灾:使用OSS跨域复制实现数据的备份;...原创 2018-04-17 19:54:00 · 708 阅读 · 0 评论 -
用户间的通信方案设计
问题描述 实现一个利用 WebSocket 进行实时通讯的基于 Web 的即时通讯应用,假设未来用户量会很大,要用到多个服务器,如何实现两个用户间的通讯呢?方案1:负载均衡+一致性哈希 负载均衡算法和消息路由算法均采用“一致性哈希算法”。具体过程是:客户端连接时根据IP或者客户端标识通过一致性哈希算法定位到某台服务器,消息路由时同样根据目标客户端标识计算出对应服务器。 优点:性能高,不依赖分布原创 2018-03-11 17:39:47 · 547 阅读 · 0 评论