03 2023 档案
摘要：批量导入接口Bulk POST http://localhost:9200/_bulk 过URI Query GET http://localhost:9200/job/_search?q=springboot&df=description&sort=jid:desc&from=0&size=10&
阅读全文
摘要：groupadd elsearch useradd elsearch -g elsearch -p codingwhychown -R elsearch:elsearch elasticsearch-7.9.3su elsearch ./elasticsearch -d 解决办法：1、在config
阅读全文
摘要：1. 新增job索引 PUT http://localhost:9200/job 2. 查询job索引元数据 GET http://localhost:9200/job 3. 删除索引 DELET http://localhost:9200/job 4. 查询所有索引元数据 GET localhos
阅读全文
摘要：消息队列，顾名思义，就是传递消息的队列 消息队列有哪些应用 系统解耦 设计模式中有一个开闭原则，指的是软件实体应该对扩展开放、对修改关闭，尽量保持系统之间的独立，这里面蕴含的是解耦思想。而消息队列的使用，可以认为是在系统中隐含地加入了一个对外的扩展接口，能够方便地对业务进行解耦，调用方只需要发送消息
阅读全文
摘要：ElasticSearch 是一个基于 Lucene 的分布式全文检索框架，在 Lucene 类库的基础上实现，可以避免直接基于 Lucene 开发，这一点和 Java 中 Netty 对 IO/NIO 的封装有些类似。 ElasticSearch 开放了一系列的 RESTful API，基于这些
阅读全文
摘要：现在要设计电商网站的订单数据库模块，经过对业务增长的估算，预估三年后，数据规模可能达到 6000 万，每日订单数会超过 10 万。 存储实现，订单作为电商业务的核心数据，应该尽量避免数据丢失，并且对数据一致性有强要求，肯定是选择支持事务的关系型数据库，比如使用 MySQL 及 InnoDB 存储引擎
阅读全文
摘要：单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。 要避免过度设计。因为分库分表虽然可以提高性能，但是盲目地进行分库分表只会增加系统的复杂度。 数据库连接限制 数据库的连接是有限制的，不能无限制创建，比如 MySQL 中可以使用 max_connections 查看默认的最大连
阅读全文
摘要：互联网大部分业务场景都是读多写少的，对于电商等典型业务，读和写的请求对比可能差了不止一个数量级。为了不让数据库的读成为业务瓶颈，同时也为了保证写库的成功率，一般会采用读写分离的技术来保证。 读写分离的实现是把访问的压力从主库转移到从库，特别在单机数据库无法支撑并发读写，并且业务请求大部分为读操作的情
阅读全文
摘要：Sidecar 设计模式 在系统设计时，边车模式通过给应用程序添加边车的方式来拓展应用程序现有的功能，分离通用的业务逻辑，比如日志记录、流量控制、服务注册和发现、限流熔断等功能。通过添加边车实现，微服务只需要专注实现业务逻辑即可，实现了控制和逻辑的分离与解耦。 边车模式中的边车，实际上就是一个 Ag
阅读全文
摘要：容器化技术简介 相比传统虚拟化技术，容器技术是一种更加轻量级的操作系统隔离方案，可以将应用程序及其运行依赖环境打包到镜像中，通过容器引擎进行调度，并且提供进程隔离和资源限制的运行环境。 虚拟化技术 虚拟化技术通过 Hypervisor 实现虚拟机与底层硬件的解耦，是一种运行在基础物理服务器和操作系统
阅读全文
摘要：一部分配置会经常发生修改，比如限流降级开关配置、业务中的白名单配置等。这些配置项除了变更频繁，还要求实时性，如果采取和应用一起发布的方式，那么每次变更都要重新发布服务，非常不方便。 配置管理如何实现 分布式配置管理的本质就是一种推送-订阅模式的运用。配置的应用方是订阅者，配置管理服务则是推送方，客户
阅读全文
摘要：随着服务的拆分，系统的模块变得越来越多，不同的模块可能由不同的团队维护，一个请求可能会涉及几十个服务的协同处理， 牵扯到多个团队的业务系统。 假设现在某次服务调用失败，或者出现请求超时，需要定位具体是哪个服务引起的异常，哪个环节导致的超时，就需要去每个服务里查看日志，这样的处理效率是非常低的。 系统
阅读全文
摘要：为什么需要服务注册和发现 分布式系统下微服务架构的一个重要特性就是可以快速上线或下线，从而可以让服务进行水平扩展，以保证服务的可用性。 假设有一个电商会员服务，随着业务发展，服务器负载越来越高，需要新增服务器。如果没有服务注册与发现，就要把新的服务器地址配置到所有依赖会员模块的服务，并相继重启它们，
阅读全文
摘要：开放平台类网关是企业内部系统对外的统一入口，承担了很多业务,比如内外部数据交互、数据安全、监控统计等功能。 为什么需要网关 移动互联网时代，我们的系统不仅会通过 Web 端提供服务，还有 App 端、小程序端等，各个调用端单独去发起连接，会出现很多问题，比如不容易监控调用流量，出现问题不好确定来源，
阅读全文
摘要：RPC（Remote Procedure Call）是一种进程间通信方式,通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议”。 RPC 允许程序调用另一个地址空间的过程或函数，而不用程序员显式编码这个远程调用的细节。 RPC 框架代表 Dubbo、Thrift、gRPC RPC 框
阅读全文
摘要：完备的分布式锁，需要支持哪些特性？ 互斥性，互斥是锁的基本特征，同一时刻只能有一个线程持有锁，执行临界操作；超时释放，超时释放是锁的另一个必备特性，可以对比 MySQL InnoDB 引擎中的 innodb_lock_wait_timeout 配置，通过超时释放，防止不必要的线程等待和资源浪费；可重
阅读全文
摘要：大促活动有一个共同特点就是访问量激增，在高并发下会出现成千上万人抢购一个商品的场景。虽然在系统设计时会通过限流、异步、排队等方式优化，但整体的并发还是平时的数倍以上，参加活动的商品一般都是限量库存，如何防止库存超卖，避免并发问题呢？分布式锁就是一个解决方案。 分布式锁的常用实现 基于数据库、Redi
阅读全文
摘要：如果 MySQL 数据库断电了，未提交的事务怎么办？ 答案是依靠日志，因为在执行一个操作之前，数据库会首先把这个操作的内容写入到文件系统日志里记录起来，然后再进行操作。当宕机或者断电的时候，即使操作并没有执行完，但是日志在操作前就已经写好了，我们仍然可以根据日志的内容来进行恢复。 MySQL Inn
阅读全文
摘要：分布式事务就是一个业务操作，是由多个细分操作完成的，而这些细分操作又分布在不同的服务器上；事务，就是这些操作要么全部成功执行，要么全部不执行。 数据库事务 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabilily），简称 ACID。
阅读全文
摘要：区块链是一个注重安全和可信度胜过效率的一项技术，如果说互联网技术解决的是通讯问题，区块链技术解决的则是信任问题。 Consistency 侧重的是内容在时间顺序上的一致和统一，而 Consensus 则是指由许多参与者对某项内容达成共识，所以一般把 Consistency 翻译为“一致性”，把 Co
阅读全文
摘要：在分布式场景中，ZooKeeper 的应用非常广泛，比如数据发布和订阅、命名服务、配置中心、注册中心、分布式锁等。 ZooKeeper 提供了一个类似于 Linux 文件系统的数据模型，和基于 Watcher 机制的分布式事件通知，这些特性都依赖 ZooKeeper 的高容错数据一致性协议。 Zab
阅读全文
摘要：Quorum 机制 Quorum 选举算法。在各种一致性算法中都可以看到Quorum 机制的身影，主要数学思想来源于抽屉原理，用一句话解释那就是，在 N 个副本中，一次更新成功的如果有 W 个，那么我在读取数据时是要从大于 N－W 个副本中读取，这样就能至少读到一个更新的数据了。 Paxos 的节点
阅读全文
摘要：Base 是三个短语的简写，即基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent） Base 理论的核心思想是最终一致性，即使无法做到强一致性（Strong Consistency），但每个应用都可以根据自身的业
阅读全文
摘要：分布式系统技术就是用来解决集中式架构的性能瓶颈问题，来适应快速发展的业务规模 分布式系统是建立在网络之上的硬件或者软件系统，彼此之间通过消息等方式进行通信和协调。 分布式系统的核心是可扩展性，通过对服务、存储的扩展，来提高系统的处理能力，通过对多台服务器协同工作，来完成单台服务器无法处理的任务，尤其
阅读全文
摘要：Nacos 集群架构的设计要点 微服务并不是直接通过 IP 地址访问后端服务，而是采用域名访问。通过 DNS（域名解析服务）转换为具体的 IP 地址，通过域名方式屏蔽后端容易产生变化的 IP 地址。 底层 Nacos 自带集群间节点与数据同步方案，因此需要 Nacos 节点对外暴露 8848 与 7
阅读全文
摘要：单实例情况下，服务间通常采用点对点通信，即采用 IP+端口+接口的形式直接调用。但考虑避免单点负载压力过大以及高可用的性能要求，通常会部署多实例节点保障系统的性能，但增加多实例后，调用方该如何选择哪个服务提供者进行处理呢？还有当服务提供者出现故障后，如何将后续请求转移到其他可用实例上呢？面对这些问题
阅读全文
摘要：通用的微服务架构应包含哪些组件 注册中心（Service Registry） 注册中心是微服务架构最核心的组件。它起到新服务节点的注册与状态维护的作用，通过注册中心解决了上述问题 1。微服务节点在启动时会将自身的服务名称、IP、端口等信息在注册中心中进行登记，注册中心会定时检查该节点的运行状态。注册
阅读全文
摘要：《人月神话》中提到，软件世界没有“银弹”，这句话当然适用于架构领域 从网络、性能、运维成本、组织架构与集成测试五个方面分别进行阐述。 第一点，跨进程通信带来的新问题。 单体应用是在单机中进行进程内通信，通信稳定性相当好。但是打散为分布式系统后，变为进程间通信，往往这个过程还伴随着跨设备的网络访问 第
阅读全文
摘要：微服务架构风格是一种将单机应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并以轻量级的机制来进行通信。这些服务围绕着业务能力所建立，并且由完全自动化的部署机构独立部署，这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据库存储技术。 任何架构都不是一蹴而就的，每一
阅读全文
摘要：相比于形式，思维过程最为重要 不仅要关注专业技术（术），还要有自己的分析能力（道），并且要懂得顺势而为（势）。 思考 的思维是敏感的，通过敏感驱动思考，通过思考驱动学习和总结，直至敏锐。这确实需要大量的练习，它也是一个潜移默化的过程，最终你会因为这个习惯受益一生。 表达 良好的表达能力，无论是和同事
阅读全文
摘要：能力 基础技术架构：这部分是纯技术架构，所有非功能性的技术都是基础技术的范畴。 业务架构：在业务场景下对业务需求的抽象。 开发技能：这是架构师落地架构的能力。 把握系统技术 在需求分析阶段：架构师对于业务架构，要给出一个合理的需求分析抽象模型。 在架构设计和架构选型阶段：架构师要充分考虑技术的合理性
阅读全文
摘要：全链路的视角上进行高性能的设计 前端优化 减少请求次数、页面静态化、边缘计算。 减少请求次数 增加缓存控制：前端研发同学经常会设置 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 间进行取舍。假如要保证服务的可用性
阅读全文
摘要：对架构设计的认知 架构设计的问题，一定要立足于点、连接成线、扩散成面 为什么做架构拆分？通常最直接目的就是做系统之间解耦、子系统之间解耦，或模块之间的解耦。 为什么要做系统解耦？系统解耦后，使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中，从而使得拆封后的各个系统职责更单一，功能更为内聚。
阅读全文
摘要：知道做什么永远比怎么做更为重要 架构师视角就是全局的视角 全局包括空间全局和时间全局 空间全局上你要看到整个系统的领域边界 时间全局上你要看到整个系统的发展周期 解决技术问题的方法有很多，这是“术”，但解决技术问题的底层思维逻辑是一样的，这是“道” 以道御术
阅读全文
摘要：微服务的好处 易于扩展 发布简单 技术异构 便于重构 微服务的痛 微服务职责划分 微服务粒度拆分 重复代码多 耗费更多服务器资源 分布式事务 服务之间的依赖 联调的痛苦 部署上的难题
阅读全文
摘要：设计秒杀架构时，我们一般需要遵循 东西不能超卖、 下单成功的订单数据不能丢失、 服务器和数据库不能挂、 尽量别让机器人抢走商品 大流量要注意，出口带宽 PC 网站，首先必须前后端分离，然后静态资源能上 CDN 就上 CDN 动态的请求静态化， 秒杀商品的详情页面变成静态页面，然后再放入 CDN 用户
阅读全文
摘要：日活用户高达 500 万，基于现有业务模式，业务侧要求我们根据用户的行为做埋点，旨在记录用户在特定页面的所有行为、开展数据分析与第三方进行费用结算 技术选型思路 原始数据海量： 对于这点，我们初步考虑使用 HBase 进行持久化 后台查询原始数据： 如果使用 HBase 直接作为查询引擎，查询速度太
阅读全文
摘要：分表分库实现思路 1. 使用什么字段作为分片键？ 2. 分片的策略是什么？ 根据范围分片 简单，容易尾部过热 根据 hash 值分片 指的是根据用户 id 的 hash 值 mod 一个特定的数进行分片。（为了方便后续扩展，一般是 2 的几次方。） 根据 hash 值及范围混合分片 跨库查询 跨库查
阅读全文
摘要：系统里有一个工单查询功能，工单表中存放了几千万条数据，且查询工单表数据时需要关联十几个子表，每个子表的数据也是超亿条。 面对如此庞大的数据量，跟前面的冷热分离一样，每次客户查询数据时几十秒才能返回结果，即便我们使用了索引、SQL 等数据库优化技巧，效果依然不明显。 采用了查询分离的解决方案，才得以将
阅读全文
摘要：如何快速实现流量削峰？ 第一步进行的削峰是，先做恶意用户拦截。 基于用户维护设置限制。比如同一个账号在 5 秒内最多可以请求扣减多少次 基于来源 IP 设置限制 手机以及电脑都有唯一编码，如手机的 IMEI、电脑的网卡地址等。可以在限制账号、IP 之外，再增加对这些维度的限制。 增加一定的过滤比例。
阅读全文
摘要：数据库和纯缓存实现的扣减方案 数据库方案的性能较差； 纯缓存方案虽不会导致超卖，但因缓存不具备事务特性，极端情况下会存在缓存里的数据无法回滚，导致出现少卖的情况。 顺序写的性能更好 在向磁盘进行数据操作时，向文件末尾不断追加写入的性能要远大于随机修改的性能。数据库同样是插入要比更新的性能好。 借力顺
阅读全文
摘要：架构是面向业务功能、成本、实现难度、时间等因素的取舍，而不是绝对地追求高性能、高并发及高可用等非功能性指标。 纯数据库的方案虽然避免了超卖与少卖的情况，但因采用了事务的方式保证一致性和原子性，所以在 SKU 数量较多时性能下降较明显。 扣减只需要保证原子性即可，并不需要数据库提供的 ACID 在提升
阅读全文
摘要：读业务的特点是写少读多 扣减类业务的定义，我把关于扣减的实现，需要关注的技术点总结如下： 当前剩余的数量需要大于等于当次需要扣减的数量，即不允许超卖； 对同一个数据的数量存在用户并发扣减，需要保证并发一致性； 需要保证可用性和性能，性能至少是秒级； 一次的扣减会包含多个目标数量； 当次扣减有多个数量
阅读全文
摘要：数据按路由规则分散后，如何满足无路由字段的多维度富查询？ 为了满足和原有分库维度不一样的查询，最简单的方式是按新的维度异构一套数据 业界应对多维度实时查询的最常见方式便是借助 ElasticSearch 相比数据库，ES 里所有的内容都可以分词建立索引且 ES 不需要保障数据的 ACID 等特性，因
阅读全文
摘要：分库分表只解决了容量的问题，并没有解决写服务的高可用问题 读服务里，可以采用数据冗余来保障架构的高可用 写冗余需要有满足 CAP 原则的存储支持，而我们知道，CAP 原则最多只能同时满足两个特性，要么 CP 要么 AP 写入业务的目标是成功写入 存储依然使用分库分表，但写入规则则发生了一些变化。它不
阅读全文
摘要：是否真的要分库？ 容量提升了，但也带来了很多其他问题。比如： 分库数据间的数据无法再通过数据库直接查询了。比如跨多个分库的数据需要多次查询或借助其他存储进行聚合再查询。 分库越多，出现问题的可能性越大，维护成本也变得更高。 无法保障跨库间事务，只能借助其他中间件实现最终一致性 分表后的子表仍在原有库
阅读全文
摘要：全量缓存抗住秒级百万的 QPS 毫无压力 “百万 QPS”有一个非常重要的限制条件，即这百万的 QPS 都是分属于不同用户的 当百万的 QPS 属于不同用户时，因缓存是集群化的，所有到达业务后台的请求会根据一定路由规则（如 Hash），分散到请求缓存集群中的某一个节点 假设一个节点最大能够支撑 10
阅读全文
摘要：如何发送Binlog MySQL 的 Binlog 分为三种数据格式：statement、row 及 mixed 格式 1. statement 格式 update demo_table set status='无效' where id =1 内容太少，传输速度快。解析上述的 SQL 获取变更的字段
阅读全文
摘要：全量缓存是指将数据库中的所有数据都存储在缓存中，同时在缓存中不设置过期时间的一种实现方式 基于 Binlog 的全量缓存架构 Binlog 的同步方案后，全量缓存的架构变得更加完整 1. 降低了延迟 缓存基本上是准实时的，数据库的主从同步保持在毫秒级别 2. 解决了分布式事务的问题 Binlog 的
阅读全文
摘要：架构尽量不要分层 读服务的业务逻辑都比较简单，性能主要消耗在网络传输上，以 Java 举例，直接将数据访问层编译为 JAR 包并由读服务进行依赖。这样在部署时，它们在同一个进程里 读服务要尽可能和数据靠近，减少网络传输。 浏览器都自带本地缓存的功能，CDN 也是一样的道理 在读服务对于性能要求非常严
阅读全文
摘要：拆分是架构设计大型复杂系统的第一步，对降低系统复杂性有着决定性的意义，它也是架构师的必备技能之一。 人解决复杂问题的能力是有限的，当问题涉及面广、情况复杂时，自然会去寻找方法提升效率。 业务后台系统就是一个“复杂问题”，而解决“这个问题”的方法便是拆分——将复杂问题拆解为多个相对简单的小问题，分而治
阅读全文
摘要：短视频、微博、新闻资讯、电商、打车等）梳理分类 业务后台系统在系统实现上均可分为读业务、写业务、扣减业务 读业务是越快越好 首先介绍的是读业务场景。任何业务最基本的要求是高可用，随时保障服务可用，还要求能够在海量读请求下保障高性能。 写业务需要 101% 高可用 读业务的技术实现分析里提到，保障高可
阅读全文
