随笔分类 - 通用架构
摘要：设计松耦合 系统可监控 系统无单点 系统可降级 可水平扩展原则 分离原则 动静分离 读写分离 冷热分离 前后端分离 接口实现分离
阅读全文
摘要：如何快速实现流量削峰？ 第一步进行的削峰是，先做恶意用户拦截。 基于用户维护设置限制。比如同一个账号在 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 的
阅读全文
摘要：拆分是架构设计大型复杂系统的第一步，对降低系统复杂性有着决定性的意义，它也是架构师的必备技能之一。 人解决复杂问题的能力是有限的，当问题涉及面广、情况复杂时，自然会去寻找方法提升效率。 业务后台系统就是一个“复杂问题”，而解决“这个问题”的方法便是拆分——将复杂问题拆解为多个相对简单的小问题，分而治
阅读全文
摘要：短视频、微博、新闻资讯、电商、打车等）梳理分类 业务后台系统在系统实现上均可分为读业务、写业务、扣减业务 读业务是越快越好 首先介绍的是读业务场景。任何业务最基本的要求是高可用，随时保障服务可用，还要求能够在海量读请求下保障高性能。 写业务需要 101% 高可用 读业务的技术实现分析里提到，保障高可
阅读全文
