panjianlongWUHAN的专栏

目录一、场景背景二、架构分析2.1 分析核心复杂度2.2 计算架构核心数据三、架构改进3.1 结果推导​3.2 改进架构​专栏链接: IT老齐架构300讲笔记一、场景背景 二、架构分析2.1 分析核心复杂度当下架构核心复杂度有3点每个贺卡要占用5mb的带宽，而单台ECS只有200MB，肯定不够用 单台ECS API性能极限有限，肯定扛不住 100万用户在5个小时内预计将产生8000万数据，数据库扛得住吗2.2 计算架构核心数据.

目录一、分析库存超卖的产生二、秒杀场景的分析三、高并发下预防超卖的解决方案一、分析库存超卖的产生二、秒杀场景的分析秒杀商品库存总量固定 先到先得，瞬间并发极大，但写库量有限三、高并发下预防超卖的解决方案利用预减库存方式杜绝超卖 利用Nginx+Lua在网关层面将无效请求阻挡 利用MQ消息队列的限流特性保证MySQL不会被瞬间击垮 APP需要额外设计轮询机制查询订单状态...

目录一、为什么不能直接更新缓存二、Cache Aside Pattern到底说了什么2.1为什么不是“先删缓存，再写库”2.2 Cache Aside Pattern三、延迟双删3.1 Cache Aside Pattern不一致场景3.2 延迟双删解决极端场景数据不一致专栏链接: IT老齐架构300讲笔记一、为什么不能直接更新缓存不要考虑去update更新缓存二、Cache Aside Pattern到底说了什么Cache Asid..

目录一、场景二、如何设计一个简单的订单系统三、如何避免丢单情况四、重构优化4.1 如何设计一个支持日万级的订单系统4.2 千日万级的订单系统可能遇到的问题4.3 如何设计一个支持千日万级的订单系统一、场景我们每天都在使用网络进行下单，购买各种各样的商品和服务，作为一名后端服务的程序员，你有没有好奇地想过，在网络下单后，后台流程是如何处理的，订单是如何生成的，又是如何推送到下游的各个系统的，以及在这个过程中，订单系统是如何保证系统低延迟、高可用的，尤其是不出现丢单.

目录一、动静分离1.1 架构三大分离设计1.2 动静分离1.3 有效区分页面中的动静数据是优化的关键前提二、动静分离案例2.1 缓存架构2.2 动静分离流程图2.3 页面静态化与伪静态化技术2.4 伪静态化2.5 静态化的问题三、动静整合方案3.1利用SSI实现动静分离3.2 Ajax异步请求法 京东动静结合方案专栏链接: IT老齐架构300讲笔记一、动静分离1.1 架构三大分离设计读写分离 动静分离 前后台分离1.2 动静..

目录一、推模式（Push）与拉模式（Pull）有什么不同二、写扩散与读扩散该如何优化应对2.1 写扩散(Push)优化2.2 读扩散(Pull)优化2.3推特的混合模式专栏链接: IT老齐架构300讲笔记一、推模式（Push）与拉模式（Pull）有什么不同 Push模式 Pull拉取模式 实时性 较好，通过网络管道准实时发送 较差，取决于定时轮询时间.

目录一、场景二、UUID的版本2.1 基于时间的UUID2.2 DCE安全的UUID2.3基于命名空间的UUID（MD5、SH1）2.4基于随机数的UUID(最常用)三、为什么 UUID 会引起IO异常一、场景财政部金财工程平台在代理行日终结算时，经常出现磁盘的IO异常，导致经常出现高延迟。这个问题一直困扰我们很长时间，对比发现在大量数据新增时磁盘IO居高不下，多次测试后发现是UUID主键在搞鬼。二、UUID的版本2.1 基于时间的UUID...

目录MVCC1.隔离级别​2.场景分析 ​ReadView1.ReadView数据结构2.读已提交(RC):在每一次执行快照读时生成ReadView3.可重复读(RR):仅在第一次执行快照读时生成ReadView，后续快照读复用MVCC1.隔离级别在MySQL InnoDB存储引擎下,RC、RR基于MVCC（多版本并发控制）进行并发事务控制MVCC是基于”数据版本”对并发事务进行访问2.场景分析 UNDO_LOG不是会被删除吗？中间数据万..

目录为什么会产生并发冲突传统解决方案(悲观锁)增加行锁for update悲观锁缺点乐观锁方案乐观锁遇到冲突后的解决方案为什么会产生并发冲突传统解决方案(悲观锁)增加行锁for update悲观锁缺点悲观锁并发性太差高并发场景用户体验差乐观锁方案实现目标：既要保证用户体验，也要实现数据可靠乐观锁遇到冲突后的解决方案前端应用提示"数据正在处理，请稍后再试!" 附加spring-retry在service上进行.

目录幂等性如何解决类似的幂等性问题幂等表方案幂等性发一次接口调用与发多次相同的接口消息都能得到与预期相符的结果如何解决类似的幂等性问题每重发一次请求1号工资就会+500，幂等性就被破坏了传统办法是代码增加前置判断if(!员工已调薪){进行调薪}缺点需要前置判断的地方太多了，一不留神就漏了这种技术问题不应该成为干扰程序员写业务代码的因素需求我们需要一种无侵入的幂等解决方案构建幂等表是我们的通用解决方案幂等表方...

目录Seata分布式事务场景Seata执行过程分布式事务体系的三个重要角色第一阶段第二阶段Seata AT模式Seata如何避免并发场景的脏读与脏写SeataSeata是一款阿里巴巴提供的开源分布式事务解决方案，微服务架构下提供高性能和简单易用的分布式事务服务分布式事务场景二阶段提交请求阶段 相应阶段Seata执行过程分布式事务体系的三个重要角色事务管理器(TM):决定什么时候全局提交/回滚 司令官 事务.

目录什么是CAP定理CAP这三个要素最多只能同时实现两点​CP​AP​AC什么是CAP定理分布式架构的基本理论。指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）C：一致性 更新操作成功后，所有节点在同一时间的数据完全一致。(复习：事务的一致性：事务前后的数据完整性保持一致)A：可用性 用户访问数据时，系统能否在正常响应时间返回预期结果。（复习：事务的原子性：事务是一个不

目录一、如何对配置进行管理二、配置中心是如何实现的1.配置信息如何存储2.变更推送如何实现3.如何保证配置中心高可用一、如何对配置进行管理在开发应用的时候，管理配置的方式主要有两种：一种是通过配置文件来管理； 一种是使用配置中心来管理随着配置项越来越多，为了更好地对配置项进行管理，同时避免修改配置项后还要重新对代码做编译，你选择把配置项拆分成独立的文件（文件可以是properties格式、xml格式或yaml格式）。不过，这些文件还是会和工程一起打包部署，只是更改配

目录一、压力测试二、如何搭建全链路压测平台​1.压测数据的产生2.数据如何隔离3.压力测试如何实施一、压力测试压力测试的通常的错误之处1.压力测试时最好使用线上的数据和线上的环境，你无法确定自己搭建的测试环境与正式环境的差异，是否会影响到压力测试的结果。2.压力测试时不能使用模拟的请求而是要使用线上的流量。你可以通过拷贝流量的方式，把线上流量拷贝一份到压力测试环境。比如，你在获取商品信息的时候，线上的流量会获取不同商品的数据，这些商品的数据有的命中了缓存，有的没有命中缓

目录一、搭建APM系统二、需要监控用户的哪些信息一、搭建APM系统APM 应用性能管理 Application Performance Management. 对应用各个层面做全方位的监测，期望及时发现可能存在的问题，并加以解决，从而提升系统的性能和可用性。首先，在数据采集方面，我们可以采用类似Agent的方式，在客户端上植入SDK，由SDK负责采集信息，并且经过采样之后，通过一个固定的接口定期发送给服务端。SDK将这几部分数据转换成JSON格式后，就可以发送给APM通道服务了.

目录一、监控指标如何选择二、监控数据的采集、处理和存储一、监控指标如何选择四个黄金信号（Four Golden Signals）。它指的是在服务层面一般需要监控四个指标，分别是延迟、通信量、错误和饱和度。延迟指的是请求的响应时间。比如接口的响应时间、访问数据库和缓存的响应时间。 通信量可以理解为吞吐量，也就是单位时间内请求量的大小。比如访问第三方服务的请求量，访问消息队列的请求量。 错误表示当前系统发生的错误数量。这里需要注意的是， 我们需要监控的错误既有显式的，比如在监控Web服

目录一、跨语言体系带来的挑战1.服务之间的通信协议选择合适的序列化方式2.使用新语言开发的微服务无法使用之前积累的服务治理的策略二、Service Mesh是如何工作的1.什么是Service Mesh2.如何将流量转发到Sidecar中一、跨语言体系带来的挑战微博的主要开发语言是Java和PHP，近几年也有一些使用Go开发的系统。而使用不同的语言开发出来的微服务，在相互调用时会存在两方面的挑战1.服务之间的通信协议选择合适的序列化方式比如用Java开发一个RPC服务

一、多机房部署的难点是什么多机房部署的含义是： 在不同的IDC机房中部署多套服务，这些服务共享同一份业务数据，并且都可以承接来自用户的流量这种架构听起来非常美好，但是在实现上却是非常复杂和困难的假如我们有两个机房A和B都部署了应用服务，数据库的主库和从库部署在A机房，那么机房B的应用如何访问到数据呢？有两种思路。1.直接跨机房读取从库：2.在机房B部署一个从库，跨机房同步主库的数据，然后机房B的应用就可以读取这个从库的数据都涉及到跨机房的数据传输， 这就对机房之间...

一、API网关起到的作用API网关（API Gateway）不是一个开源组件，而是一种架构模式，它是将一些服务共有的功能整合在一起，独立部署为单独的一层，用来解决一些服务治理的问题。你可以把它看作系统的边界，它可以对出入系统的流量做统一的管控1.入口网关部署在负载均衡服务器和应用服务器之间它提供客户端一个统一的接入地址，API网关可以将用户的请求动态路由到不同的业务服务上，并且做一些必要的协议转换工作。在你的系统中，你部署的微服务对外暴露的协议可能不同： 有些提供的是HT...

一、负载均衡服务器的种类负载均衡的含义是: 将负载（访问的请求）“均衡”地分配到多个处理节点上。这样可以减少单个处理节点的请求量，提升整体系统的性能。负载均衡服务器作为流量入口，可以对请求方屏蔽服务节点的部署细节，实现对于业务方无感知的扩容。它就像交通警察，不断地疏散交通，将汽车引入合适的道路上。1.代理类的负载均衡服务代理类的负载均衡服务以单独的服务方式部署，所有的请求都要先经过负载均衡服务，在负载均衡服务中选出一个合适的服务节点后，再由负载均衡服务调用这个服务节点来实现流量的...

目录一、场景分析二、一体化架构中的慢请求排查如何做三、如何来做分布式Trace一、场景分析垂直电商系统在引入RPC框架和注册中心之后已经完成基本的服务化拆分了，系统架构变成了下面的结构。经过了服务化拆分之后，服务的可扩展性增强了很多，可以通过横向扩展服务节点的方式平滑地扩容了，对于应对峰值流量也更有信心了。但是这时出现了问题： 你通过监控发现，系统的核心下单接口在晚高峰的时候，会有少量的慢请求，用户也投诉在APP上下单时，等待的时间比较长。而下单的过程可能会调用多个RPC服务或.

目录一、服务发现二、服务状态管理如何来做1.主动探测2.心跳模式三、总结一、服务发现服务注册和发现不是一个新的概念。Nginx是一个反向代理组件，那么Nginx需要知道应用服务器的地址是什么，这样才能够将流量透传到应用服务器上，这就是服务发现的过程，使用Nginx作为服务发现有几个问题首先在紧急扩容的时候，就需要修改客户端配置后，重启所有的客户端进程，操作时间比较长； 其次，一旦某一个服务器出现故障时，也需要修改所有客户端配置后重启，无法快速修复，更无法做到自动恢复；.

目录一、场景分析二、RPC(Remote Procedure Call)远程过程调用1.RMI2.Web Service3.调用分析三、如何提升网络传输性能1.等待资源的阶段2.使用资源的阶段四、选择合适的序列化方式一、场景分析来思考这样一个场景： 你的垂直电商系统的QPS已经达到了每秒2万次，在做了服务化拆分之后，由于我们把业务逻辑都拆分到了单独部署的服务中，那么假设你在完成一次完整的请求时需要调用4～5次服务，计算下来，RPC服务需要承载大概每秒10万次的请求

目录一、场景分析二、微服务拆分的原则三、微服务化带来的问题和解决思路一、场景分析在这个架构中，我们将用户、订单和商品相关的逻辑抽取成服务独立的部署，原本的Web工程和队列处理程序将不再直接依赖缓存和数据库，而是通过调用服务接口查询存储中的信息。有了构思和期望之后，为了将服务化拆分尽快落地，你们决定抽调主力研发同学共同制定拆分计划。但是仔细讨论后你们发现，虽然对服务拆分有了大致的方向可还是有很多疑问服务拆分时要遵循哪些原则？ 服务的边界如何确定？服务的粒度是怎样的？ 在服

目录一、场景分析二、一体化架构的痛点二、如何使用微服务拆分一、场景分析工程的部署方式还是采用一体化架构。也就是说所有的功能模块，比如电商系统中的订单模块、用户模块、支付模块、物流模块等等都被打包到一个大的Web工程中，然后部署在应用服务器上。系统发展到一定阶段都要做微服务化的拆分，将一体化架构拆分成微服务化架构二、一体化架构的痛点初期优势开发简单直接，代码和项目集中式管理； 只需要维护一个工程，节省维护系统运行的人力成本； 排查问题方便，只需要排查这个应用进

目录一、消息延迟场景二、如何监控消息延迟三、减少消息延迟的正确姿势1.消费端2.消息队列(1)消息的存储(2)零拷贝技术四、课程小结一、消息延迟场景在你的垂直电商项目中，你会在用户下单支付之后向消息队列里面发送一条消息，队列处理程序消费了消息后会增加用户的积分或者给用户发送优惠券。用户在下单之后，等待几分钟或者十几分钟拿到积分和优惠券是可以接受的，但是一旦消息队列出现大量堆积，用户消费完成后几小时还拿到优惠券，那就会有用户投诉了。二、如何监控消息延迟监控.

目录一、消息队列架构场景二、消息为什么会丢失1. 在消息生产的过程中丢失消息2.在消息队列中丢失消息3.在消费的过程中存在消息丢失的可能三、如何保证消息只被消费一次1.什么是幂等2.在生产、消费过程中增加消息幂等性的保证(1)生产端幂等性​(2)消费端幂等性一、消息队列架构场景比如你的电商系统需要上一个新的红包功能：用户在购买一定数量的商品之后，由你的系统给用户发一个现金的红包鼓励用户消费。由于发放红包的过程不应该在购买商品的主流程之内，所以你考虑..

目录一、削去秒杀场景下的峰值写流量二、通过异步处理简化秒杀请求中的业务流程三、解耦实现秒杀系统模块之间松耦合四、课程小结一、削去秒杀场景下的峰值写流量00:00分秒杀活动准时开始，用户瞬间向电商系统请求生成订单，扣减库存，用户的这些写操作都是不经过缓存直达数据库的。1秒钟之内，有1万个数据库连接同时达到，系统的数据库濒临崩溃，寻找能够应对如此高并发的写请求方案迫在眉睫。在秒杀场景下短时间之内数据库的写流量会很高，那么依照我们以前的思路应该对数据做分库分表。如果已经做了分库分表

一、如何平滑地迁移数据库中的数据我们要考虑从支持单库到多库多表的场景。迁移应该是在线的迁移，也就是在迁移的同时还会有数据的写入； 数据应该保证完整性，也就是说在迁移之后需要保证新的库和旧的库的数据是一致的； 迁移的过程需要做到可以回滚，这样一旦迁移的过程中出现问题，可以立刻回滚到源库不会对系统的可用性造成影响。一般来说，我们有两种方案可以做数据库的迁移1.双写方案将新的库配置为源库的从库用来同步数据；如果需要将数据同步到多库多表，那么可以使用一些第三方工具获取Binlog的增..

一、静态资源加速的考虑点我们使用分布式缓存对动态请求数据的读取做了加速，但是在我们的系统中存在着大量的静态资源请求：对于移动APP来说，这些静态资源主要是图片、视频和流媒体信息； 对于Web网站来说，则包括了JavaScript文件、CSS文件、静态HTML文件等等。一般来说，图片和视频的大小会在几兆到几百兆之间不等，如果我们的应用服务器和分布式缓存都部署在北京的机房里，这时一个杭州的用户要访问缓存中的一个视频，那这个视频文件就需要从北京传输到杭州，期间会经过多个公网骨干网络，延迟很高..

一、问题描述在低缓存命中率的系统中，大量查询商品信息的请求会穿透缓存到数据库，因为数据库对于并发的承受能力是比较脆弱的。一旦数据库承受不了用户大量刷新商品页面、定向搜索衣服信息，查询就会变慢，大量的请求也会阻塞在数据库查询上，造成应用服务器的连接和线程资源被占满，最终导致你的电商系统崩溃。一般来说，我们的核心缓存的命中率要保持在99%以上，非核心缓存的命中率也要尽量保证在90%，如果低于这个标准你可能就需要优化缓存的使用方式了。既然缓存的穿透会带来如此大的影响，那么我们该如何减少它的发生呢？..

目录一、重视缓存问题二、客户端方案1.缓存数据如何分片(1)Hash分片的算法(2)一致性Hash算法(3)一致性Hash算法中引入虚拟节点2.主从机制3.多副本三、中间代理层方案四、服务端方案一、重视缓存问题你需要关注缓存命中率这个指标（缓存命中率=命中缓存的请求数/总请求数）。一般来说，在你的电商系统中，核心缓存的命中率需要维持在99%甚至是99.9%，哪怕下降1%，系统都会遭受毁灭性的打击。假设系统的QPS是10000/s，每次调用会访问10次.

针对不同的业务场景，缓存的读写策略也是不同的，不仅仅是优先读缓存，缓存不命中就从数据库查询，查询到了就更新到缓存。我们在选择策略时也需要考虑诸多的因素，比如说，缓存中是否有可能被写入脏数据，策略的读写性能如何，是否存在缓存命中率下降的情况等等。一、Cache Aside(旁路缓存)策略考虑一种最简单的业务场景，比方说在你的电商系统中有一个用户表，表中只有ID和年龄两个字段，缓存中我们以ID为Key存储用户的年龄信息,那么当我们要把ID为1的用户的年龄从19变更为20，要如何做呢？你可能...

一、什么是缓存缓存，是一种存储数据的组件，它的作用是让对数据的请求更快地返回。凡是位于速度相差较大的两种硬件之间，用于协调两者数据传输速度差异的结构，均可称之为缓存做一次内存寻址大概需要100ns，而做一次磁盘的查找则需要10ms。二、缓存案例1.TLBLinux内存管理是通过一个叫做MMU（Memory Management Unit）的硬件，来实现从虚拟地址到物理地址的转换的，但是如果每次转换都要做这么复杂计算的话，无疑会造成性能的损耗，所以我们会借助一个叫做TLB（Tr...

一、数据库的主键要如何选择数据库中的每一条记录都需要有一个唯一的标识，依据数据库的第二范式，数据库中每一个表中都需要有一个唯一的主键。主键一般两种选择方式1.使用业务字段作为主键，比如说对于用户表来说，可以使用手机号，email或者身份证号作为主键。2.使用生成的唯一ID作为主键。我们需要考虑的是作为主键的业务字段是否能够唯一标识一个人，一个人可以有多个email和手机号，一旦出现变更email或者手机号的情况，就需要变更所有引用的外键信息，所以使用email或者手机作为主键是不...

目录一、可能遇到的问题二、如何对数据库做垂直拆分三、如何对数据库做水平拆分1.按照某一个字段的哈希值做拆分2.按照某一个字段的区间来拆分四、课程小结一、可能遇到的问题1.系统正在持续不断地发展，注册的用户越来越多，产生的订单越来越多，数据库中存储的数据也越来越多，单个表的数据量超过了千万甚至到了亿级别。这时即使你使用了索引，索引占用的空间也随着数据量的增长而增大，数据库就无法缓存全量的索引信息，那么就需要从磁盘上读取索引数据，就会影响到查询的性能了。那么这时你要如何提.

一、主从读写分离大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级。刷朋友圈的请求量肯定比发朋友圈的量大，淘宝上一个商品的浏览量也肯定远大于它的下单量。因此，我们优先考虑数据库如何抵抗更高的查询请求，那么首先你需要把读写流量区分开，因为这样才方便针对读流量做单独的扩展，这就是我们所说的主从读写分离。二、主从读写的两个技术关键点一般来说在主从读写分离机制中，我们将一个数据库的数据拷贝为一份或者多份，并且写入到其它的数据库服务器中，原始的数据库我们称为主库，主要负责数据的写入，拷..

目录一、用连接池预先建立数据库连接二、用线程池预先创建线程一、用连接池预先建立数据库连接频繁创建数据库连接会造成响应时间变慢，只要使用连接池将数据库连接预先建立好，这样在使用的时候就不需要频繁地创建连接了,查询性能大大提升了。数据库连接池有两个最重要的配置：最小连接数和最大连接数， 它们控制着从连接池中获取连接的流程如果当前连接数小于最小连接数，则创建新的连接处理数据库请求； 如果连接池中有空闲连接则复用空闲连接； 如果空闲池中没有连接并且当前连接数小于最大连接数，则创建新的连

一、为什么提升扩展性会很复杂在架构设计之初，为什么不预先考虑好使用多少台机器，支持现有的并发呢？答案是峰值的流量不可控。基于成本考虑，在业务平稳期，我们会预留30%～50%的冗余以应对运营活动或者推广可能带来的峰值流量，但是当有一个突发事件发生时，流量可能瞬间提升到2～3倍甚至更高。如何应对突发的流量呢？架构的改造已经来不及了，最快的方式就是堆机器。不过我们需要保证，扩容了三倍的机器之后，相应的我们的系统也能支撑三倍的流量吗？ 答案是否定的集群系统中，不同的系统分层上可能存在一些“..

目录一、可用性的度量二、高可用系统设计的思路1.系统设计(1)Failover(2)调用超时2.系统运维(1)灰度发布(2)故障演练一、可用性的度量一个高并发大流量的系统，系统出现故障比系统性能低更损伤用户的使用体验。想象一下，一个日活用户过百万的系统，一分钟的故障可能会影响到上千的用户。MTBF（Mean Time Between Failure） 是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。