《架构300讲》学习笔记（1-50）

newProxyInstance

已于 2023-01-11 17:19:27 修改

阅读量3.8k

点赞数 2

分类专栏：笔记文章标签：架构

于 2021-12-01 11:10:12 首次发布

本文链接：https://blog.csdn.net/qq_37151886/article/details/119909919

版权

笔记专栏收录该内容

36 篇文章 1 订阅

订阅专栏

前言

内容来自B站IT老齐架构300讲内容。

02 十分钟说明白MySQL集群模式与应用场景

单库

一个数据库存放所有业务数据。

读写分离

将一个数据库拆分为读库和写库，

读写分离集群模式：在原有的基础上增加中间层，与后端数据集构成读写分离的集群。整体基础结构：原有的主库派生出字库1，字库2，
利用mysql原有的主从同步机制（即为：binlog日志同步），将主库的数据变化在从库中复现，保证数据同步。主库一般用于写入处理，
从库负责读取。细节：如果直接面对主库进行操作无法完成读写分离，需要在前端分配分片中间件（阿里mycat，京东ShardingSphere）,
该中间件通过curd请求,来决定由哪个库处理。MHA中间件实现高可用（即：主服务器坏了，MHA中间件可以将某个从表提升为主服务器）。
所有节点数据均保持同步。适用于读多写少，单表不过千万的互联网应用。

分库分表（分片）集群模式：一个mysql数据库撑不住的情况下。将数据库的数据分到不同的节点数据库（即：节点数据库的数据合起来为完整的数据体）。
需要用到中间件进行路由。（对sql进行解析，将请求发到对应的数据库，分发请求的过程叫路由）。不具备高可用性。

分片算法：
1.范围法，对主键（即为分片键进行划分。如id），mysql默认提供的特性（分区表为典型的范围法），易扩展，适用范围检索，但数据不均匀，局部负载大，适用流水账应用。
2.HASH法，对id取模。取模和一致性Hash（独特的环形算法）。数据分布均匀。扩展复杂，数据迁移大。建议提前部署。

主流模式：读写分离和分片的组合运用

03 为什么大厂要做数据垂直分表?

一个表中有100个字段，字段太多，将一个表分表为两个表，一个基础表，一个详细表。

分表前
select * from 商品表 where 商品列表 = 'ad钙奶' 
分表后
select * from 商品基本信息表 a,商品详情表 b where a.商品id = b.商品id and a.商品标题 = 'ad钙奶'

什么是水平分表？
以行为单位对数据进行拆分（范围法，hash法）。特点：所有的表结构完全相同。用于解决数据量大的存储问题。

什么是垂直分表？
将表按列拆分成2张以上的小表，通过主外键关联获取数据。

为什么要这么做？
需要了解mysql的InnoDB处理引擎。
行数据称为：row
管理数据基本单位称为页：page；每一页的默认大小：16k
保存页的单位称为区：Extent。
关系：区由连续页组成，页由连续行组成。1024/16=64(即：一个1M的区有64个页)

InnoDB1.0后新特性，压缩页。
压缩页：对数据底层进行压缩，使实际大小小于逻辑大小。
在跨页检索数据的过程中，压缩和解压缩的效率低。在表设计时，尽可能在页内多存储行数据，减少跨页检索，增加页内检索。

分析：
1行数据为1K，1页16K，即1页16条数据，1亿的数据需要625万页
垂直分页后，1行数据为64字节（1K=1024字节），即1页256条数据，1亿的数据需要39万页。分页后的数据根据id等关系进行快速提取。
通过将重要字段单独剥离成小表，让每页容纳更多行数据，页减少后，缩小数据扫描范围，达到提高执行效率的目的。

垂直分表条件：
1.单表数据达千万
2.字段超20个，且包含vachar，CLOB,BLOB等字段

字段放大小表的依据：
小表：数据查询、排序时需要的字段；高频访问的小字段
大表：低频访问字段；大字段

垂直分表依据：

单表数据量可能千万。
字段超过20个，且包含了超长到varchar、clob、blob字段。

什么字段放小表：
数据查询、排序需要到字段、如分类编号、商品id、品牌编号、逻辑删除标志位等。
高频访问的小字段：如商品名称、子标题、价格、厂商基本等。
什么字段放大表：
配送信息、售后声明、最后更新时间等、大字段：商品图文详情、图片BLOB、JSON元数据等。

04 为什么架构师对多级缓存架构情有独钟？

缓存是提升性能最直接的方法
多级缓存分为：客户端，应用层，服务层，数据层

客户端缓存：主要对浏览器的静态资源进行缓存
通过在浏览器设置Expires，时间段内以文件形式把图片保存在本地，减少多次请求静态资源带来的带宽损耗（解决并发手段）

应用层缓存：
浏览器只负责读取Expires，Expires在CDN内容分发网络和Nginx进行设置

CDN内容分发网络是静态资源分发的主要技术手段，有效解决带宽集中占用以及数据分发问

CDN的核心技术：
根据请求访问DNS节点，自动转发到上海CDN节点，检查资源是否被缓存，若已缓存则返回资源否则回源北京提取到并缓存到上海CDN节点，再由上海CDN节点进行返回。

响应头Expires和Cache-control的区别：
1.均为通知浏览器进行文件缓存
2.Expires指在这个时间点缓存就到期
3.Cache-control指缓存时间有多长
即：你明天还钱给我Expires，时间是一天Cache-control

Nginx缓存管理：
Nginx对Tomcat集群做软负载均衡，提供高可用性。有静态资源缓存和压缩功能（在本地缓存文件）

服务层缓存：进程内缓存和进程外缓存
进程内缓存：即数据运行时载入程序开辟的缓存中JAVA框架的运用（hibernate，mybatis一二级缓存，springmvc页面缓存）
开源实现：ehcache，Caffeine

进程外缓存：即为分布式缓存（redis）
常见的加缓存是直接加redis是不严谨
需要按照：先近到远，先快后慢逐级访问
场景：商品秒杀，若无本地缓存，都保存在redis 每完成一笔交易，局域网会进行若干网络通信，可能存在网络异常不稳定因素
且redis会承担所有节点的压力，当突发流量若超过容载上限redis会崩溃
所有java的应用端也需要设计多级缓存

一般会通过进程内缓存和进程外缓存（分布式缓存）组合分担压力
ehcache（进程内缓存）可以在缓存不存在时去redis进程外缓存进行读取，redis没有读取数据库数据库再对ehcache，redis进行更新

缓存一致性处理：
场景：修改商品价格为80，如何保证缓存也进行更新
处理方法：引入消息队列（MQ）的主动推送功能，对服务实例推送变更实例
即：修改商品价格为80，向MQ发送变更消息，MQ将消息推送到服务实例服务实例将原缓存数据删除，再创建缓存

什么情况适用多级缓存架构
1、缓存数据稳定
2、可能产生高并发场景（12306）应用启动时进行预热处理，访问前将热点数据先缓存，减少后端压力
3、一定程度上允许数据不一致不重要的信息更新处理方式：T+1,ETL日中处理（处理方式这块不懂）

07 为什么大厂在大表做水平分表时严禁使用自增主键

自增主键在分布式环境下不适用。
由于自增主键必须连续，所以按范围法进行分片，ID的数量已固定。无法进行动态扩展。会产生“尾部热点”效应。
尾部热点：即按范围法进行分片后，前面的分片已储存数据，最后一个分片的压力很大。
Hash分片的效率更高。

使用UUID替代自增主键吗？不可以、
涉及数据库底层机制：
1.uuid，唯一无序。无序导致索引重排。主键有序的情况下，B+树只需要在原有的数据后面追加即可。

怎么解决？分布式且有序的主键生成算法？
雪花算法（SnowFlake），推特公司。
结构：符号位（1bit）+时间戳（41bit）+机器ID（10bit）+序列（12bit）
使用方法：直接调用JAR包

雪花算法需要注意时间回拨带来的影响。可能出现id重复的可能。

08 布隆过滤器在亿级流量电商系统的应用

hutool - Bloom Filter

在这里插入图片描述

场景：正常redis有1000条缓存数据，忽然遭到爬虫/流量攻击攻击，大量不存在的于redis的数据批量查询，
由于redis不存在这些数据，会到数据库进行查询。由于数据库对于瞬时高并发访问的承载能力弱，所以可能
对数据库造成影响，甚至崩溃。
绕过redis服务器进入数据库查询的方式叫做缓存穿透。

缓存穿透攻击：
指恶意用户在短时间内大量查询不存在的数据，导致大量请求在被送达数据库进行查询，
当请求数量超过数据库负载上限时，使系统响应出现高延迟甚至瘫痪的行为。

如何预防缓存穿透？布隆过滤器。

布隆过滤器：由一个很长的二进制向量和一系列随机映射函数组成，可以用于检索一个元素是否在一个集合中。
特点：
1.一定的误识别率（即某一元素存在于某集合中，但是实际上该元素并不在集合中）
2.但是没有识别错误的情形（即如果某个元素确实没有在该集合中，那么Bloom Filter 是不会报告该元素存在于集合中的，所以不会漏报）。
也就是：我说你不在你就一定不在，我说在，可能不在。
3.删除困难

了解hash:
Hash （散列函数）：是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值。
由于这种转换，可能存在不同的输入可能会散列成相同的输出。
Hash算法可以将一个数据转换为一个标志，这个标志，就是视频说的hash，hash后若不存在，就由0变为1。存在，不变。

视频hash1（858），hash2（858），hash3（858）的原理是：
Hash面临的问题就是冲突。假设 Hash 函数是良好的，如果我们的位阵列长度为 m 个点，那么如果我们想将冲突率降低到例如 1%, 这个散列表就只能容纳 m/100 个元素。显然这就不叫空间有效了（Space-efficient）。
解决方法也简单，就是使用多个 Hash，如果它们有一个说元素不在集合中，那肯定就不在。如果它们都说在，虽然也有一定可能性它们在说谎，不过直觉上判断这种事情的概率是比较低的。
（我搬运的，前半句我看不懂，只看懂后半句，理解就是：hash有冲突的可能，多个hash减少冲突率。原来1个说在，但可能不在。若2个，1个说在，另一个说不在，就肯定不在）

减少误判的措施：
1.增加二进制数组位数。
2.增加Hash次数。

项目中如何使用：
应用启动时初始化布隆过滤器（将商品在布隆过滤器中先从0转换成1）
用户请求时判断布隆过滤器是否有编号，若布隆过滤器有，读取redis，若redis没有，则读取数据库，载入redis缓存。
若布隆过滤器没有，返回数据不存在消息。

假如布隆过滤器初始化后，有商品被删除了，怎么办？
布隆过滤器某一位二进制可能被多个编号hash引用（看hash的特点：不同的输入可能会散列成相同的输出）
所以，不能直接处理删除布隆过滤器的数据。
解决方案：
1.定时异步重建布隆过滤器
2.计数BloomFilter（可以知道该位被几个引用）

我一开始觉得，删就删了呗，管他干嘛，但是不管他，冲突率会高，处理后，这个数据就不会再引起冲突。
即：A商品被删后，当你查询A商品时，布隆过滤器说他在（布隆过滤器特点：我说你不在你就一定不在，我说在，可能不在），那我就要去redis查，但实际数据库查不到这个A商品，redis也没有。
这就存在冲突了。如果处理之后，布隆过滤器说不在就不在。

09 为啥京东开发要禁用IP直连？

IP直连有什么问题？（存在强耦合问题）
jdbc:mysql//192.168.3.21:3306:db（写法没问题，但存在强耦合问题）
线上建议用域名代替ip地址，因为在架构设计中需要考虑解耦问题。

场景：原代码连接数据库地址是192.168.3.21，现在业务需要连接到另一台数据库192.168.3.31，则可能存在代码修改，编译，部署，走流程等。
所以ip直连不可取。

解决方法1：
1.引入内部DNS，即建立一个域名解析服务器。
jdbc:mysql//域名:3306:db，直接访问数据库ip对应的域名，域名解析服务器根据配置解析该域名对应的IP返回。
优点：IP地址迁移变得灵活，后续直接修改域名解析服务器域名对应的IP地址即可。
缺点：1.没有故障发现和转移，2.一个域名绑定多个ip，负载均衡只有轮询规则。

方法2：加入注册中心（Nacos/Eureka/Consul）
弥补没有故障发现和转移。
多个数据库IP，在注册中心进行配置，注册中心通过多种负载均衡，选取某个IP进行返回（跟内部DNS类似）
如果发现故障和故障转移。
数据库注册到注册中心，两者之间通过注册保持连续，注册相当于一个心跳包，服务器节点定时向注册中心发送信息，告知服务器正常。
若某节点异常，异常服务器会被注册中心移除。

优点：支持故障发现和转移。具有多种负载均衡策略。
缺点：架构复杂度增加。（注册中心需要维护节点的状态，并且定时监听心跳包。一般会部署成集群，比内部DNS复杂，还需考虑高可用）

10 5分钟大白话什么是CAP定理

什么是CAP定理。
分布式架构的基本理论。
指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
C：更新操作成功后，所有节点在同一时间的数据完全一致。(复习：事务的一致性：事务前后的数据完整性保持一致)
A：用户访问数据时，系统能否在正常响应时间返回预期结果。（复习：事务的原子性：事务是一个不可分割的工作单位，事务要么发生要么不发生）
P：分布式系统遇到某节点或网络分区故障的时候，仍能对外提供一致性和可用性的服务。

CAP这三个要素最多只能同时实现两点，不可能三者兼顾。
所有只有CP,AP,AC

当前场景：订单系统下单买了1瓶酒，库存系统酒的数量-1。分布式系统中，系统之间需要网络通信等各种问题。无法实现买了1瓶酒，库存即时-1。
CP：订单创建后，等待库存减少后才返回结果。保证数据一致，强一致性表现，用户体验差。（类似银行存钱）
AP：订单创建后，不等待库存减少后就返回结果。那库存数据怎么办？（异步处理后通知订单系统，若异步处理失败，有补偿机制（重新发请求，补录，校对程序）保证数据一致）。（类似淘宝）
AC：不拆分数据库系统，在一个数据库的一个事务中完成操作，即单体应用。下单，减库存在一个事务。缺点：不能做分区，分区涉及网络，进而涉及分区容错性，进而选CP,AP。

11 关于负载均衡器，你学会（fei)了吗？

负载均衡
优点：高可用、设备压力瓶酒分配，支持故障发现和转移

负载均衡的种类：

1、硬件负载均衡（F5），软件负载均衡
2、网络层面：
4层代理（指网络7层模型（OSI）的传输层，TCP），举例：Linux的LVS
7层代理（指网络7层模型（OSI）的应用层，HTTP），举例：Nginx

Nginx：内置负载均衡策略有哪些？
轮询策略（默认）、权重策略、IP_HASH、URL_HASH(第三方模块)、FAIR（第三方模块）

轮询策略：4个任务，你负责1，我负责2，你负责3，我负责4，类似。适用于性能相当的服务器。
权重策略：4个任务，你能力强，你做3个，我能力差，我做1个。适用于性能不一致的服务器。
IP_HASH：有多个用户访问Nginx，通过用户的IP对N取模（N台服务器），该IP一直由对应的服务器负责。不建议使用，无法保证服务器的均衡。
URL_HASH：类似IP_HASH，比IP_HASH更精确，但仍无法保证服务器的均衡。
FAIR：谁有空谁干活。使用心跳包判断哪台服务器闲置，然后把请求送达闲置服务器。现实使用较少。了解即可

12 阿里开发规范解读：为啥禁用外键约束？

阿里规范：不得使用外键与级联，一切外键概念必须在应用层（代码层面）解决。

不喜欢外键约束的理由：测试人员和开发人员，在做delete或update受到外键约束，需要处理外键约束涉及的其他表的数据。
拥护外键约束的理由：保证数据的一致性和完整性，级联操作方便，数据一致性交给数据库，代码量少。

场景：订单表跟订单明细表。这时订单id主外键关联。
1.性能问题，额外的数据一致性校验查询。往订单明细表添加一条数据，会强制查询对应订单表中的订单id是否存在。
2.并发问题：外键约束会启用行级锁，主表写入会进入阻塞。
并发环境下，往订单明细表添加一条数据，会强制查询对应订单表中的订单id是否存在，所以订单表开启共享锁（共享锁【S锁】，又称为读锁，可以查看但无法修改和删除的一种数据锁）。
某种情况下对订单id进行更新操作，这时该数据开启排它锁（排他锁【X锁】，又称写锁）。若写锁不被释放，订单明细表处于被锁定的状态。会造成线层积压，系统崩溃。
3.级联删除问题：多层级联删除会让数据变得不可控，触发器严禁使用。
4.数据耦合：数据库层面数据关系产生耦合，数据迁移维护困难。
场景：订单明细表数据增长，数据量10亿后，需要迁移到Hbase。这时数据不在同一个库，没有了主外键约束，代码上无校验，就会产生属于一致性问题。

13 前后端分离架构到底做了啥，让互联网项目情有独钟？

14 巧用阿里Canal实现MySQL异构数据同步

场景：
商户在后台系统添加数据，消费者需要在前台获取数据
这时候需要将后台的数据同步到es中。
mysql的数据跟es存储的数据不一样，称为异构数据。

如何将后台的数据同步到es？
做法：团队A在java代码中新增mysql数据时，调用团队B的接口新增es商品数据。
缺点：1、协作中两个团队存在代码强耦合。
2、扩展困难。场景：团队C的MongoDB也要同步mysql的数据，团队A再次修改代码？

目标实现：数据能做到实时同步，团队间解耦，团队A不用多次调用接口。

引出Canal。
Canal:阿里巴巴的，基于db增量日志解析，提供增量数据订阅和消费

先说下mysql数据库的主从同步的功能。
原理：基于binlog实现（二进制日志文件）。
场景：用户新增、删除数据，主库执行完相应sql语句后，会将sql记录到binlog中。
主库将binlog传给从库，从库接收到binlog的sql，将其写入relaylog（重放日志）中。
从库执行relaylog的sql语句，就此实现同步。
最后从库还会将执行relaylog的sql语句写入从库的binlog中。

当引入Canal，相当于从库被Canal代替（假的mysql从库，主要监听主库的binlog，relaylog的sql语句）

怎么执行？
通过Canal的配置文件，当获取新的数据时，自动触发指定的java代码完成同步工作。
（我拙见是：指定的java代码这里应该完成了数据异构的转换）

引入MQ，解决解耦问题。
团队A新增删除数据，将消息发到MQ，其他团队从MQ订阅消息。

16 七张图讲明白MySQL高可用MHA架构方案

MHA:最成熟的mysql高可用方案。(很好的兼容性)
看14了解清楚mysql主从原理
场景：主服务器挂了，从服务器不会切换到主服务器，从而引出高可用MHA方案。

MHA故障发现与转移
1、启动：前置检查（配置文件等，不细说）
2、运行过程：若master挂了，MHA如何认定需要进行故障转移？
1、manger每3秒向主节点发送select 1 的SQL语句，判断主节点是否执行。3次ping无反应，认定master异常
2、避免网络导致的无法ping通，manger让从属服务器MHA node尝试SSH登录检查，若所有node连接不上，从而认定，开始故障转移。

故障转移：
1、切断外界链接（断开虚拟IP跟怀疑挂掉的主机链接），主从同步也断开
2、manager使用SSH拉取备份服务器的binlog（复制保存到manager）
3、由于binlog跟从服务器的relaylog的数据可能存在不一致，从而进入转移，使得数据保持一致。
4、从属服务器之间进行比对，node会检查relaylog哪个是最新的（理解上不管他怎么检查吧），向其他节点发送差异数据并应用。
5、这时从属服务器的relaylog一致了，但和主服务器的binlog还可能不一致。这时将旧的master binlog差异的数据发送到从属服务器上并应用。
6、数据均一致后，面临以谁为主服务器进行迁移的问题？有三种方案
1、manger指定谁主
2、看哪个节点的日志最新
3、按注册实例列表向后选择（manger中对sql有记录）
7、确定谁是主后，从服务器通过changer master命令完成主从链接。
8、将原虚拟IP指向新的主服务器
9、当旧的主服务器恢复正常，作为从服务器和新的主服务器进行同步（MHA自动完成）

这个过程存在的细节问题有：（按实际情况解决）
1、binlog不完整
2、迁移丢包，数据不完整
3、旧主服务器跟binlog日志不一致

18 Redis架构很难懂？非也，七张图讲明白Sentinel高可用架构

1、主从复制
一主多从架构
master主要负责写入，slave负责读取。有读写分离的功能

redis主从同步原理：
1、slave执行命令向master建立连接
2、master执行bgsave（后台存储），生成rdb快照（redis备份方式，data以二进制方式保存在本地），发送到slave上
3、slave获取快照后读取，对data还原，保证初始化数据一致
4、master接受命令发送到salve，salve执行保证后续数据一致

缺点：master挂掉，redis集群瘫痪。
引出高可用，sentinel（哨兵模式）

1、建立sentinel集群，有一个leader角色
2、一般需要6个节点，3个sentinel，3个主从。
3、sentinel安装在节点上，根据配置信息监听redis的健康状态。
（每个sentinel 1次/秒频率向master，salve及其他sentinel实例发送ping命令）

若master挂了，怎么办？
先判断是否真挂了：
主动下线（不靠谱，存在网络问题误判）：实例最后一次有效回复时间超时
客观下线：多个sentinel ping不通（多个=总数除以2+1）

19 阿里巴巴Seata分布式事务解决方案

20 京东金融是如何保障接口幂等性的？

20.1什么是接口幂等性？

发一次接口调用与发多次相同的接口消息都能得到与预期相符的结果。

20.2 数据库受影响的阶段

查询（select）和删除（delete）操作是天然幂等的，受影响的是创建（Create）、更新（Update）。

重复创建和重复更新的问题。

20.3 产生场景

前端重复提交：提交订单，用户快速重复点击多次，造成后端生成多个内容重复的订单。
接口超时重试：对于给第三方调用的接口，为了防止网络抖动或其他原因造成请求丢失，这样的接口一般都会设计成超时重试多次。
消息重复消费：MQ消息中间件，消息重复消费。

20.4 后端实现幂等性策略

传统方法:前置判断。

Token机制
主要流程就是：

服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。
调用业务接口请求时，请求头携带Token。
服务器判断token是否存在redis中，存在表示第一次请求，这时把redis中的token删除，继续执行业务。
如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行。