04stone37

转载：浅谈淘宝类目属性体系：商品搜索背后的逻辑架构商品分类体系的演变商品数量很少，没有分类；商品数量过百，开始使用一级类目；商品数量成千上万，开始使用多级类目，即类目树；商品数量达到百万级，甚至亿级别，开始使用“类目+属性”的分类体系，避免类目层级过深；前后台类目分离，满足不同用户需求（卖家通过后台类目发布商品，买家通过前台类目选购商品）；整体架构  淘宝类目属性体系主要由后...

SPU和SKU  SPU指的是商品，SPU属性就是不会影响到库存和价格的属性, 又叫关键属性，与商品是一对一的关系；SKU指的是具体规格单品，SKU属性就是会影响到库存和价格的属性, 又叫销售属性，与商品是多对一的关系。  以iphone6s举例，它身上有很多的属性和值， 比如毛重: 420.00 g产地: 中国大陆容量: 16G, 64G, 128G颜色: 银, 白, 玫瑰金...

扣减时机  何时扣减扣减库存，目前有两种主流方式：方式1：下单减库存——即用户下单成功时减少库存数量优点：用户体验好，系统逻辑简单；缺点：会导致恶意下单或下单后却不买，使得真正有需求的用户无法购买，影响真实销量；解决办法：设置订单有效时间，若订单创建成功N分钟不付款，则订单取消，库存回滚；限购，用各种条件来限制买家的购买件数，比如一个账号、一个ip，只能买一件；风控，从技术角...

目标  为某垂直领域的电商平台设计一个订单中心，用户、商家和运营可以对订单中心进行不同的操作；需求分析C端：访问量大，数据的实时性和一致性要求高，主要是订单列表和订单详情的查询；B端：访问量适中，对数据的实时性和一致性有一定容忍度，主要是B端展示的几个维度的分页查询；M端：访问量低，查询条件复杂多变，查询的数据量大，对系统可用性、数据的实时性和一致性等容忍度最高；存储方案设计...

SaaS订单中心作用  为油站提供订单管理能力，管理线上（各种互联网加油平台，比如小桔加油、车主邦等）、线下等不同渠道的订单；需求分析

需求分析用户侧  用户侧对用户中心的查询特点是：查询频次高，基本上都是单条查询，对数据的实时性和一致性要求高，99%的请求为uid查询用户信息，1%的请求为根据用户名/邮箱/手机号等条件查询用户信息；运营侧 运营侧对用户中心的查询特点是：查询频次低，查询数据量大，查询条件复杂（年龄、性能、注册时间等），对数据的实时性和一致性容忍度高；存储方案设计  整体思路：用户表按照uid分库分表...

RESTful是什么？　　Http协议作者提倡的一种协议使用风格：用HTTP动词（GET,POST,DELETE等）描述操作，用URL定位资源；RESTful提出背景　　随着Http协议的广泛使用，越来越多的开发人员都将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http...

数据一致性方案方案1A业务处理和消息发送在同一个本地事务中执行，执行完成后本地消息表中有条status=0记录；B收到消息后，在同一个事务中进行业务处理和消息发送（返回响应）；如果B处理失败，由Broker进行失败重试；A收到响应消息后更新对应的消息状态为1；A端本地会启动定时任务，定时扫描状态为0的消息，发出告警，甚至进一步可以执行数据补偿操作；方案2A业务...

整体思路首先，确定线程池要执行任务的性质：CPU密集型或者IO密集型；如果是CPU密集型，说明请求的处理比较占用CPU资源，瓶颈在于CPU，增加线程数作用不大；如果是IO密集型，说明请求的处理占用IO资源，CPU比较空闲，此时应该合理地增加线程数；实际操作Step1：预估初始大小 Step2：调整初始大小　　根据压测目标，对初始值进行调整，得到最佳的性能指标。...

前后端交互系统前端感知异常与不感知异常的区分有多重方法：不同的异常类或者相同的类，不同的错误码区间等等；有多种交互形式的开放系统

RBAC模型  RBAC（Role-Based Access Control）基于角色的访问控制：引入角色的概念，将用户和权限解耦，避免每加入一个用户添加众多权限；一个用户可以同时有一个或多个角色；每个角色拥有一组权限，当用户有多个角色时，其拥有的权限为多个角色权限的并集；参考：https://www.uisdc.com/100-solutions-for-character-p...

什么是系统过载？  系统过载是指当前的外部请求量超过了系统的最大处理能力。比如，某系统每秒最多处理100条请求，但是它每秒收到的请求有200条，此时则认为该系统已经过载；系统过载的影响  系统过载会导致系统负载变高，其影响按照严重程度从低到高依次为：请求RT变长、服务不可用、上下游系统级联故障；过载保护的最终的目的：在系统过载时，服务还能提供一个稳定的较高的处理能力；系统过载方案 ...

问题描述  系统A调用系统B的服务，系统A设置了超时上限t1（读超时，或者熔断超时等），系统B服务处理时间为t2。当t1 < t2时，系统A会抛出超时异常，系统B可能处理成功也可能失败，但是系统A无法感知，如下图所示：...

含义  买卖双方在成交时记录当时交易状况的一张“照片”，即交易快照为一份静态数据，记录了交易时的数据，特别是容易变化的数据，比如商品信息，以及优惠信息等；作用  作为发生交易争执时的判断依据；范围  订单信息中已经包含了交易时的很多信息，为避免重复，交易快照存储容易发生变化的信息的详情，比如淘宝存储了商品详情，如上图所示；存储时间  不同公司根据具体的业务情况来决定，目前淘宝是永久...

订单查询实时性要求高的查询走DB；复杂查询或非实时查询走ES；避免深分页查询，即limit m,n中的m不要过大；

ConfigServer2.0架构Consumer/Provider启动时，通过统一域名从Address Server获取ConfigServer集群的地址列表；Provider随机选取一台机器建立长连接，并进行服务注册；ConfigServer集群中的机器接受到服务注册信息后，广播到集群其它机器；ConfigServer集群中的机器推送对应的服务注册信息到连接的Consumer;...

什么是前后端分离？过去，前后端分离是从物理上做区分的：认为只要是客户端的就是前端，服务器端的就是后端；当前，前后端分离从职责上进行划分：前端负责 View 和 Controller 层，后端只负责 Model 层； MVC模式 缺点：前后端代码混杂在一起，前端开发重度依赖后端的开发环境，且部署成本大；前后端职责不够明确，Controller仍处于灰色地带，页面路由等功...

JIT预热问题：机器重新部署时出现load高、rt高的现象； 原因：重新部署后，JVM需要一段时间识别出热点代码，这段时间内代码都是边解释边执行的，损耗性能。 方案：定制JVM，通过Beta检测出节点代码，生成预热文件，然后推送到集群其它机器，JVM加载到预热文件后将热点代码通过JIT编译成机器代码。

可能的技术点： 待补充。。。

问题　　现有数据开放平台，通过执行用户的SQL命令提供数据查询服务。用户的SQL命令具有不确定性，当出现慢sql时会影响系统的稳定性，主要表现是服务器线程池被占满，造成雪崩效应，其它正常sql无法正常执行，出现系统假死现象。熔断方案　　按照某个维度（用户、SQL等）进行熔断，如果采样周期T内SQL超时的情况的超过设定阈值N，进行熔断降级并且发送通知，如下图所示： 该方案具有以下特点：及时性：

常见保护措施限流算法漏桶算法漏桶算法的主要思想如下：漏桶容量固定，按照固定速率流出水滴直到桶变空；水滴可以以任意速率流入漏桶，如果桶满则溢出（丢弃）； 　　　　　　　　令牌桶算法令牌桶算法的主要思想如下：桶的容量固定，令牌被按照固定的速率加入到桶中；桶满则溢出（丢弃）；请求到来时先获取令牌，获取到则进行处理，否则阻塞、等待或者拒绝； 　　 Guava的RateLimiter提供了

背景： Java应用定时调用脚本，采集系统监控信息。调用方式1：边解释边执行　　如下图所示，当监听到脚本变化后，只需要在内存中更新脚本内容即可，下次执行eval时就能执行最新的脚本了。 调用方式2：一次编译，多次执行　　如下图所示，当监听到脚本变化后，需要重新编译脚本，然后缓存CompiledScript，定时执行CompiledScript.eval()。

要求：作为各个应用的配置中心，提供持久化存储和配置变更推送的服务。持久化意味着应用的配置数据不能丢失，配置变更推送是指配置变更后能后通知到客户端。方案1：Zookeeper作为配置中心　　原理： Znode节点数据会被持久化到磁盘文件，不存在数据丢失情况；Wather机制，Znode节点变更时会发出通知。读写能力无法水平扩展的方案：读能力水平扩展，写能力不变的方案： 局限性： 配置数据总量不能超

方案1：UUID优点：能够非常简便地保证分布式环境中的唯一性； 缺点：长度过长，包含32个字符和4个短线；没有业务含义，不便于问题排查；方案2：数据库主键单库：主键id 优点： id连续、唯一，且id大小反应先后顺序； 缺点：分布式应用需要共享该单表，且单表的存储量有上限；

场景1：公司内部的机器有数万台，需要对每台机器的运行情况进行监控告警，包括系统监控、JVM监控及JDBC监控等，要求尽可能让应用无感知，且易升级维护。 部署方案 启动： StartAgent作为系统基础环境，机器分配之后就启动。应用启动之后与StartAgent建立连接传输JVM、JDBC等监控信息，StartAgent本身采集系统监控信息，然后将所有的监控汇总传送到监控中心。 升级：如果是D

入口流控自适应方案问题：在Netty中引入业务线程池带来的问题就是速率不匹配，如果IO线程接受数据的速度超过业务线程的处理速度，就会出现缓冲队列溢出，此时需要能够对客户端的发送速率进行控制。　　如下图所示，提供了一种基于TCP Flow-Control机制的自适应流控方案。当缓冲区溢出时，服务端会按一定的规则选取出最消耗业务线程资源的客户端，然后将客户端对应连接的auoread属性设置为f

应用场景　　应用依赖了某个客户端的Jar包，其依赖1.0版本的Jar包X。按照Maven的依赖仲裁原则，如果存在更短的依赖路径或者依赖路径相同，依赖声明靠前，都会影响客户端依赖的X包的版本，需要通过某种方式能够让客户端依赖的X包不受应用的影响。 解决方案方案一：scope为provided说明：使用maven对客户端打包时，将scope改为provided，由应用提供依赖的X包。这种方案要求X包的

转载：https://yq.aliyun.com/articles/52533?spm=a2c4e.11153940.blogcont93815.18.626e2684nqgU88#序列化和反序列化各序列化框架时间性能对比： 各序列化框架空间性能对比： 　　综合来看，Google的Protocol Buffers是最佳选择，不管软件的质量、社区活跃、软件的后续发展上来说，都...

架构设计　　Diamond架构由三部分组成：ConfigServer、DataServer和MySql存储，如下图所示： ConfigServer：管理DataServer集群，将客户端与DataServer集群解耦，上下线、扩容对客户端不感知；DataServer：提供配置的持久化管理、动态推送等服务； MySql存储：配置数据的持久化存储，采用一主两备的部署方式保障数据的安全；...

整体思路应用内部：在逻辑上对应用分层，所有的异常统一抛到某层处理（日志处理和异常封装）；对外服务或接口：统一返回封装成Result返回，如下图所示：　　　　应用分层　　　　开放接口层：对外暴露的RPC 接口等；显示层：模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。Web 层：主要是对访问控制进行转发，各类基本...

使用日志框架API　　应用中不可直接使用日志系统（Log4j、Logback）中的 API，而应依赖使用日志框架SLF4J 中的 API，使用门面模式的日志框架，有利于日志框架的升级和使用统一。import org.slf4j.Logger;import org.slf4j.LoggerFactory;private static final Logger logger = Logge...

术语AK（Acess Key）：唯一标识用户身份；SK（Secret Key）：给用户颁发的密钥，与AK唯一对应；安全校验内容身份认证；数据完整性校验；权限控制（水平权限控制、垂直权限控制和过期时间）；安全校验过程前置机从服务端获取Token　　利用HMAC算法验证前置机的身份和数据完整性校验，使用Https进行数据传输，保证数据通道的安全性。服务...

背景：在弱网、海量连接场景下，系统稳定性的保障。 参考：http://www.infoq.com/cn/articles/netty-million-level-push-service-design-points?utm_source=infoq&utm_campaign=user_page&utm_medium=link；

实现目标数据容灾：重要数据域间存在备份；跨域数据推送；低延时；设计方案设备使用统一域名，实现就近接入；内部应用就近写入当前所在域，通过OSS实现数据备份；DPS基础配置数据通过GN实现多域同步；目标实现低延时：内部引用就近写，前置机就近读，使用OSS跨域复制将数据同步到其它域（阿里云专有网络）；数据容灾：使用OSS跨域复制实现数据的备份；...

问题描述　　实现一个利用 WebSocket 进行实时通讯的基于 Web 的即时通讯应用，假设未来用户量会很大，要用到多个服务器，如何实现两个用户间的通讯呢？方案1：负载均衡+一致性哈希　　负载均衡算法和消息路由算法均采用“一致性哈希算法”。具体过程是：客户端连接时根据IP或者客户端标识通过一致性哈希算法定位到某台服务器，消息路由时同样根据目标客户端标识计算出对应服务器。 优点：性能高，不依赖分布