随笔分类 - 认识架构
摘要：相比于形式，思维过程最为重要 不仅要关注专业技术（术），还要有自己的分析能力（道），并且要懂得顺势而为（势）。 思考 的思维是敏感的，通过敏感驱动思考，通过思考驱动学习和总结，直至敏锐。这确实需要大量的练习，它也是一个潜移默化的过程，最终你会因为这个习惯受益一生。 表达 良好的表达能力，无论是和同事
阅读全文
摘要：能力 基础技术架构：这部分是纯技术架构，所有非功能性的技术都是基础技术的范畴。 业务架构：在业务场景下对业务需求的抽象。 开发技能：这是架构师落地架构的能力。 把握系统技术 在需求分析阶段：架构师对于业务架构，要给出一个合理的需求分析抽象模型。 在架构设计和架构选型阶段：架构师要充分考虑技术的合理性
阅读全文
摘要：全链路的视角上进行高性能的设计 前端优化 减少请求次数、页面静态化、边缘计算。 减少请求次数 增加缓存控制：前端研发同学经常会设置 HTML 的缓存控制头部（Cache-Control 头），这样浏览器在请求同一个文件时，只访问本地保存的资源副本，从而加速文件的访问速度。 减少图像的请求次数：你可能
阅读全文
摘要：系统建立的会话数量就是用户同时访问系统的数量。你也可以通过公式，估算出系统的吞吐量（throughput）和延迟（latency）。 吞吐量（系统处理请求的速率）：反映单位时间内处理请求的能力（单位一般是TPS或QPS）。 延迟（响应时间）：从客户端发送请求到接收响应的时间（单位一般是ms、s）。
阅读全文
摘要：一次系统查询的流程经历了三次调用，从网关系统开始，然后依次调用商品系统、促销系统、积分系统的三个服务，如果此时积分系统的响应时间变长，那么整条请求的响应时间也会因此变长，整体服务甚至会发生宕机。这就是服务雪崩现象：即局部故障最终导致了全局故障。 在分布式系统中，当检测到某一个系统或服务响应时长出现异
阅读全文
摘要：高级研发工程师和架构师的区别不在于掌握了多少技术，而在于你所能驾驭系统的边界。这其实也反映了一个研发工程师的成长历程，起初独立负责一个功能，然后负责一个系统模块，再负责一个系统，最后负责多个系统或业务条线。 服务等级协议（Service-Level Agreement，SLA） 一般来讲，2 个 9
阅读全文
摘要：缓存穿透问题 查询缓存中不存在的数据时，每次都要查询数据库。 解决缓存穿透的通用方案是： 给所有指定的 key 预先设定一个默认值，比如空字符串“Null” 缓存并发问题 如果没有读取到数据，那么就在 Redis 中使用 setNX 方法设置一个状态位，表示这是一种锁定状态； 缓存雪崩问题 将缓存失
阅读全文
摘要：Redis 属于单线程还是多线程？ Redis 是单线程的，主要是指 Redis 的网络 I/O 线程，以及键值的 SET 和 GET 等读写操作都是由一个线程来完成的 但 Redis 的持久化、集群同步等操作，则是由另外的线程来执行的。 Redis 采用单线程为什么还这么快？ Redis 的大部分
阅读全文
摘要：数据库写入请求量过大，导致系统出现性能与可用性问题 常见的方式就是对数据库做“分库分表”，在实现上有三种策略：垂直拆分、水平拆分、垂直水平拆分 分库分表的整体设计方案和技术实现的落地思路。一般会涉及这样几个问题： 什么场景该分库？什么场景该分表？ 复杂的业务如何选择分片策略？ 如何解决分片后的数据查
阅读全文
摘要：MySQL 主从复制的原理 MySQL 的主从复制依赖于 binlog ，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。这个过程一般是异步的 写入 Binlog：主库写 binlog 日志，提交事务，并更新本地存储数据。
阅读全文
摘要：MySQL 的事务隔离级别（Isolation Level） 数据库锁，分为悲观锁和乐观锁，“悲观锁” 悲观锁一般利用 SELECT … FOR UPDATE 类似的语句 乐观锁利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，实现版本判断。 脏读： 读到了未提交事务的数据。
阅读全文
摘要：下面这条 SQL，你怎么通过索引来提高查询效率呢？ select * from order where status = 1 order by create_time asc 更优的方式是建立一个 status 和 create_time 组合索引，这是为了避免 MySQL 数据库发生文件排序。因为
阅读全文
摘要：抢购系统大概可以分为四个阶段 商品预约：用户进入商品详情页面，获取购买资格，并等待商品抢购倒计时。 等待抢购：等待商品抢购倒计时，直到商品开放抢购。 商品抢购：商品抢购倒计时结束，用户提交抢购订单，排队等待抢购结果，抢购成功后，扣减系统库存，生成抢购订单。 订单支付：等待用户支付成功后，系统更新订单
阅读全文
摘要：在使用 MQ 的时候，怎么确保消息 100% 不丢失？ 引入 MQ 消息中间件最直接的目的是：做系统解耦合流量控制，追其根源还是为了解决互联网系统的高可用和高性能问题。 系统解耦：用 MQ 消息队列，可以隔离系统上下游环境变化带来的不稳定因素，比如京豆服务的系统需求无论如何变化，交易服务不用做任何改
阅读全文
摘要：对于整条 RPC 调用链路（从 App 到网关再到各个服务系统），怎么设置 RPC 的超时时间，要考虑哪些问题？” 结合 TP99 请求耗时：首先如果你要回答“超时时间设置和重传次数问题”，需要根据每一个微服务 TP99 的请求耗时，以及业务场景进行综合衡量。 RPC 调用方式：你要站在业务场景下，
阅读全文
摘要：基于关系型数据库实现分布式锁 select id from order where order_id = xxx for update 基于 MySQL 行锁的方式会出现交叉死锁 数据库的事务隔离级别 读未提交（READ UNCOMMITTED）； 读已提交（READ COMMITTED）； 可重复
阅读全文
摘要：主流实现分布式系统事务一致性的方案（也就是基于 MQ 的可靠消息投递的机制） 提出 2PC 或 TCC （这是一种交流方案）。因为 2PC 或 TCC 在工业界落地代价很大，不适合互联网场景，所以只有少部分的强一致性业务场景（如金融支付领域）会基于这两种方案实现。 基于两阶段提交的解决方案 过程分为
阅读全文
摘要：如何设计一个支持海量商品存储的高扩展性架构？ 在互联网业务场景下，为了解决单台存储设备的局限性，会把数据分布到多台存储节点上，以此实现数据的水平扩展。既然要把数据分布到多个节点，就会存在数据分片的问题。 数据分片即按照一定的规则将数据路由到相应的存储节点中，从而降低单存储节点带来的读写压力。常见的实
阅读全文
摘要：CAP 理论指的是什么：C（Consistency）是数据一致性、A（Availability）是服务可用性、P（Partition tolerance）是分区容错性。C、A、P 只能同时满足两个目标，而由于在分布式系统中，P 是必须要保留的，所以要在 C 和 A 间进行取舍。假如要保证服务的可用性
阅读全文
摘要：对架构设计的认知 架构设计的问题，一定要立足于点、连接成线、扩散成面 为什么做架构拆分？通常最直接目的就是做系统之间解耦、子系统之间解耦，或模块之间的解耦。 为什么要做系统解耦？系统解耦后，使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中，从而使得拆封后的各个系统职责更单一，功能更为内聚。
阅读全文
