关于架构师成长之路:读书笔记-之软件架构设计-大型网站技术架构与业务架构融合之道

大家好呀，我是小菜~

帅哥美女，晓得你们工夫贵重，那么就由小菜为你读好一本书，读一本好书，取其精华，与你共享~！

本文次要分享 《软件架构设计：大型网站技术架构与业务架构交融之道》
如有须要，能够参考
如有帮忙，不忘点赞 ❥
微信公众号已开启，菜农曰，没关注的同学们记得关注哦！

明天带来的是 《软件架构设计：大型网站技术架构与业务架构交融之道》 的读书笔记

（文中应用到的例子贴图均出于原书）

在正式进入分享之前，咱们想看下这本树的目录架构

这本书总共分为 五 个局部，共计 17 章，总体来说内容还是挺多的。内容绝对全面，但并没有八面玲珑，还是比拟举荐浏览的一本书，话不多说，进入注释！

第一局部由两个章节组成，简略的介绍了下什么是架构

1.1 架构师职业分类

当初轻易找一个招聘网站或猎头公布的招聘广告，咱们都能看到各式各样的架构师头衔，比方有：Java 架构师，前端架构师，后端架构师，数据架构师，中间件架构师 … 等等，而且年限的要求也各不一，3~5 年，8~10 年。

然而从这些岗位的需要咱们能够看出，“架构师”中的 架构 是一个很虚的词，不同畛域和行业对员工要求的能力和工作教训差别很大。

当初问起很多开发者的倒退路线都不谋而合的是要成为一名架构师，那么对架构师的定义是怎么样的？架构师在我的项目体系和团队构造中该当着一个怎么样的角色？如何成为一名架构师？这些你是否都有一个明确的答案，是否也为之指标而致力前行着！

1.2 架构的分类

单纯以技术的角度来看，软件系统自底向上能够分为三层

第一层：基础架构

基础架构是指云平台、操作系统、网络、存储这些形成，一些中小公司大多会抉择应用大公司研发的云计算平台，研发成本低，稳固有保障

第二层：中间件与大数据层

中间件属于公司中必有的，相似消息中间件，数据库中间件，缓存中间件，而大数据层对于中小公司来说比拟少有积淀，相似开源的 Hadoop 生态体系，Hive、Spark、Storm、Fink 等

第三层：业务零碎架构

对于第三层的划分并不是相对，图中体现了三种架构类型：通用软件架构 、 离线业务零碎架构 、 在线业务零碎架构，但因为事实中软件的品种过多，比方还存在嵌入式零碎。这里简略形容下图中第三种具备的类种：

通用软件架构：罕用的办公软件、浏览器、播放器等
离线业务零碎： 基于大数据的 BI（商业智能）剖析、数据挖掘、报表与可视化等
在线业务零碎架构： 搜寻、举荐、即时通信、电商、游戏、广告、企业 ERP 或 CRM 等

2.1 何为道，何为术

不禁感叹这年头聊架构，这能够上道与术的层面了。

这张图是大多数我的项目的根本架构图，能够将每层映射到你们的我的项目中，是不是不会感觉很生疏。

那么理论中这张图可能反映出架构抉择吗，架构师的工作是否就是简略的划分层级构造，而后就能够埋头进行开发了？

咱们依赖这张图将问题进行扩大：

如何拆分微服务？
如何组织服务与服务之间的层级关系？
如何设计接口？
如何保障高可用？如何分库分表？如何保证数据一致性？…

想要表白的问题切实是太多了，由此可见架构师的工作并不简略。

2.2 道与术的辩证关系

问题那么简单，咱们就以道与术来了解。如果你要成为一名武林高手，那么花里胡哨的招式对于某些人来说很重要，因为要谋求难看，所谓的花架子，而招式咱们便可了解为术，那么谋求高手的层面，咱们是否要修炼内功心法，底子扎实，能力成为顶级高手。

那么道重要还是术重要，这是个公说公有理婆说婆有理的问题，段誉的内功厉害，但使不出招式可能也有些枉然，招式难看，却没有内功撑持，也只能成为花架子的笑谈，而道术兼备，方能顶级。

这部分的内容颇多，重在道的修炼

语言是在是太多了，忍不住吐槽~ 只管语言如此之多，市面上还是一直地新陈代谢，咱们面对语言的一直迭代要谋求潮流还是岿然不动？在我看来，咱们要谋求道，底层把握牢固，管它日转星移，我亦坦然绝对。

语言再多再繁冗，都具备独特的典型个性，无外乎一些语法糖应用纯熟与否

I/ O 是绕不过来的一个根本问题。从文件 I / O 到网络 I /O，存在着各式各样的概念和 I / O 模型

4.1 缓存 I /O 和间接 I /O

在理解两个原理之前，咱们先分明几个概念：

应用程序内存： 通常写代码用 malloc/free、new/delete 等调配进去的内存
用户缓冲区： 位于用户空间中缓冲区，如 C 语言 FILE 构造体外面的 Buffer
内核缓冲区： Linux 操作系统的 Page Cache。一个 Page 的大小个别为 4K

以上三个概念理解后，咱们持续看 I/O 操作

缓冲 I /O

读：磁盘 -> 内核缓冲区 -> 用户缓冲区 -> 应用程序

写：应用程序 -> 用户缓冲区 -> 内核缓冲区 -> 磁盘

对于缓冲 I /O，一个读操作会有 3 次数据拷贝，一个写操作会有反向的 3 次数据拷贝

间接 I /O

读：磁盘 -> 内核缓冲区 -> 应用程序

写：应用程序 -> 内核缓冲区 -> 磁盘

对于间接 I /O，一个读操作会有 3 次数据拷贝，一个写操作会有返现的 2 次数据拷贝

总结：间接 I /O 并不是没有缓冲，而是没有用户级的缓冲，对于操作系统自身的缓冲还是有的

4.2 内存映射文件与零拷贝

1）内存映射文件

从缓冲 I / O 到间接 I /O，读写操作从 3 次的数据拷贝缩减到 2 次数据拷贝。而到了内存映射文件，读写操作再次缩减到了 1 次数据拷贝，也就是：

读：磁盘 -> 内核缓冲区
写：内核缓冲区 -> 磁盘

应用程序尽管读写的是本人的内存，但这个内存只是一个 “ 逻辑地址 ”，理论读写的是内核缓冲区

2）零拷贝

零拷贝（Zero Copy）又是晋升 I/O 效率的一大利器，在平时有问到 Kafka 是如何做到读写那么快的时候，其中一个很大的起因便是 Kafka 用到了零拷贝技术。

这是一个利用间接 I / O 进行收发文件的过程

这是一个利用内存映射文件进行收发文件的过程

整个过程从 4 次的数据拷贝升高到了 3 次，不再通过应用程序内存，间接在内核空间中从内核缓冲区拷贝到 Socket 缓冲区

这是一个利用零拷贝进行收发文件的过程

利用零拷贝的话，连内存缓冲区到 Socket 缓冲区的数据拷贝步骤都能够省略。在内核缓冲区和 Socket 缓冲区之间并没有做数据拷贝，只是一个地址的映射，底层的网卡驱动程序要读取数据并发送到网络的时候，看似读的是 Socket 缓冲区中的数据，实际上读得是内核缓冲区的数据。

总结：为什么称之为零拷贝呢，因为从内存的角度上看，数据在内存中没有产生数据拷贝，只在内存与 I / O 之间传输。利用的还是内核缓冲区与 Socket 缓冲区之间的映射，数据自身只有一份

4.3 网络 I/O 模型

网络 I/O 模型也是一个极易混同的概念，至今为止咱们听过几种网络 I / O 模型呢

网络阻塞 I/O
网络非阻塞 I/O
I/O 多路复用
异步 I/O

很多时候咱们容易混同的概念是 非阻塞 和异步

1）网络模型

1. 网络阻塞 I/O

这种模型很好了解，就是调用的时候会被阻塞，直到数据读取实现或写入胜利

2. 网络非阻塞 I/O

和上述相同，但没有数据的时候会立刻返回，不会阻塞，而后通过轮询的形式一直查问直到获取到数据

如果只有几十乃至上百个连贯的时候，下面两种 I/O 模型解决的形式问题都不大，当连接数达到几十万乃至上百万时，那问题就很重大了

3. I/O 多路复用

该形式也是阻塞调用，一次性将所有的连贯申请传进来，当某个连贯申请具备条件后，会立刻将后果放回，告知应用程序有哪些连贯可读或可写。罕用的 I/O 多路复用的办法有：select、poll、epoll、Java 的 NIO，其中 epoll 的效率最高，也是目前最支流的。

epoll

整个 epoll 分为三个步骤

事件注册
轮询查问是否就绪
事件就绪后进行读写

其中又可分为两种模式：LT(程度触发 / 条件触发) 和 ET(边缘触发 / 状态触发)

LT 程度触发：只有读缓冲区不空就会始终触发读事件；写缓冲区不满，就会始终触发写事件
ET 边缘触发：读缓冲区的状态从空转为非空的时候触发一次；写缓冲区的状态从满转为非满的时候触发一次

总结：理论的开发中，大家个别偏向于 LT（默认模式）。但应用的时候须要防止 “ 写死循环 ” 的问题，因为写缓冲区为满的概率很小，会始终触发写事件

4. 异步 I/O

异步 I/O 是指所有的读写操作都由操作系统实现，当解决完结后，将后果通过指定的回调函数或其余机制告知应用程序

总结： 阻塞和非阻塞是从函数调用的角度来说，而同步和非同步是从 “ 读写是由谁来实现 ” 的角度来说

2）设计模式

除了下面几种网络 I / O 模型，咱们还常常听到 Reactor 模式与 Proactor 模型，这两种并不是网络 I / O 模型。而是网络框架中的两种设计模式，无论操作系统的网络 I/O 模型的设计，还是下层网络框架的网络 I/O 模型的设计，用的都是这两中设计模型之一

1. Reactor 模式

这是一种被动模式。应用程序会一直地轮询，询问操作系统或网络框架、I/O 是否就绪。select、poll、epoll、Java 中的 NIO 就属于这种被动模式。

2. Proactor 模式

这是一种被动模式。应用程序会将所有的读写操作都交给操作系统实现，实现后再将后果通过肯定的告诉机制告知应用程序

4.4 过程、线程和协程

不同语言有不同的应用习惯。如 Java 个别是写 单过程多线程 ，C++ 个别是 单过程多线程 或 多过程单线程

1）为什么要应用多线程？

进步 CPU 使用率
进步 I/O 吞吐

2）多线程会带来的问题？

锁（乐观锁、乐观锁、互斥锁、读写锁、自旋锁、偏心 / 非偏心锁等）
Wait 与 Signal 操作
Condition

3）为什么须要多过程？

线程间锁的存在，会导致并发效率降落，同时减少编码难度
线程上下文切换须要工夫，过多的切换会导致效率低下
多过程互相独立，其中一个解体后，其余过程能够持续运行，进步可靠性

不要通过共享内存来实现通信，而应通过通信实现共享内存
艰深了解：尽可能通过音讯通信，而不是共享内存来实现过程或线程之间的同步

4）为什么须要协程？

更好地利用 CPU，协程能够由应用程序本人调度，而线程不行
更好地利用内存，协程的堆栈大小不是固定的，用多少申请多少

4.5 无锁（内存屏障与 CAS）

1）内存屏障

读能够多线程、写必须单线程，如果多线程写，则做不到无锁

基于内存屏障（避免代码重排序），有了 Java 中的 volatile 关键字，再加上单线程写的准则，就有了 Java 中的无锁并发框架

2）CAS

如果是多线程写，内存屏障并不实用，这是就须要用到 CAS。CAS 是在 CPU 层面提供的一个硬件原子指令，实现对同一个值的 Compare 和 Set 两个操作的原子化。

网络的具体认知能够空降：把握《网络》，见微能力知著

6.1 范式与反范式

第一范式：每个字段都是原子的，不能再合成。（反例：某个字段是 JSON 串，或数组）
第二范式：表必须有主键，主键能够是单个属性或几个属性的组合，非主属性必须齐全依赖，而不能局部依赖（反例：有张好友关系表，主键是 关注人 ID+ 被关注人 ID，但该表中还存储了名字、头像等字段，这些字段只依赖组合主键中其中一个字段（关注人 ID），而不是齐全依赖主键）
第三范式：没有传递依赖，非主属性必须间接依赖主键，而不能间接依赖主键（反例：有张员工表，有个字段是部门 ID，还有其余部门字段，比方部门名称，部门形容等，这些字段间接依赖部门 ID，而不是员工 ID，不应该在员工表中存在）

看了三大范式不禁有些汗颜，理论开发中为了性能或便于开发，违反范式的设计亘古未有，但也无可非议，尽管范式不肯定要恪守，但还是须要认真衡量。

6.2 分库分表

分库分表使分布式系统设计中一个十分广泛的问题。

1）分库分表的目标

业务拆分。通过业务拆分咱们能够把一个大的简单零碎拆成多个业务子系统，零碎与零碎之间能够通过 RPC 或消息中间件的形式通信。
应答高并发。高并发咱们能够具体分为是读多写少还是读少写多的并发场景。读多咱们能够利用缓存中间件缩小压力，而写多咱们就须要思考是否要进行分库分表
数据隔离。外围业务辨别开来，区别对待，投入的开发和运维老本也能够侧重点偏移

2）拆分维度的抉择

依照 Id 维度拆分：依据 Id % 64 取模拆成 0~63 的 64 张表
固定位拆分：取 Id 指定二位，例如倒数 2，3 位组成 00~99 张表
hash 值拆分：将 Id 取 hash 值，而后 % 表数
range 拆分：依照 userId 指定范畴拆分，0 – 1 千万一张表，这种用的比拟少，容易产生热点数据问题
业务域拆分：把不同业务域的表拆分到不同库中，例如订单相干的表，用户信息相干的表，营销相干的表离开在不同库
把不罕用的字段独自拿进去存储到一张表中

3）面对 JOIN 问题

拆分成多个单表查问，在代码层做逻辑拼装
做宽表（JOIN 好的表），重写轻读
利用搜索引擎，例如 Elasticsearch

6.3 B+ 树

B+ 树具备了哪些查问个性：

范畴查问
前缀匹配含糊查问
排序和分页

1）逻辑构造

这个是一个 B+ 树结构，相对来说比拟形象，咱们提取下其中的几个要害特色：

叶子节点之间所有记录的主键，并依照 从小到大 的顺序排列，造成一个双向链表。叶子节点的每一个 key 都指向一条记录
非叶子节点取的是叶子节点外面 key 的最小值。同层的非叶子节点也互相串联，造成一个双向链表

为什么只反对前缀匹配含糊查问 – like abc%
前缀匹配含糊查问能够转换为范畴查问，例如 abc% 能够转换为 key in [abc, abcz]，而如果是全含糊查问是没有方法转换的

2）物理构造

下面形容的树只是一个逻辑构造，而不是实际上的物理构造，因为数据最终都是要存储到磁盘上的。

磁盘都是以块为单位

在 InnoDB 引擎中默认的块大小是 16 KB（可通过 innodb_page_size 参数指定），这里的块，指的是逻辑单位，而不是磁盘扇区的物理块，块是 InnoDB 读写磁盘的根本单位，InnoDB 每次进行磁盘 I / O 读取的都是 16 KB 的整数倍，无论是叶子节点还是非叶子节点都是装在 Page 外面

一个 Page 大略能够装 1000 个 key（意味着 B + 树有 1000 个分叉），每个 Page 大略能够装 200 条记录（叶子节点），那么三层构造能够装多少？1000 1000 200 = 2 亿条，约 16GB 的数据，这就是 B+ 数的弱小之处

3）非主键索引

每一个非主键索引都对应一个 B+ 树，与主键索引不同的是非主键索引每个叶子节点存储的是主键的值而不是记录的指针。也就是说对于非主键索引的查问，会先查到主键的值，再拿主键的值去查问主键的 B + 数，这就须要两次 B+ 树的查问操作，也就咱们常说的 回表查问

6.4 事务与锁

1）事务的隔离级别

什么事务？事务就是一个"代码块"(一条船的蚂蚱)，要么都不执行，要么都执行。多个事务之间，为了想实现工作，那么它们之间就很容易发生冲突，抵触产生就容易带来问题，比方：有两个事务别离是小王和小李

脏读：小王读取了小李不想要的货色，给小王带来了脏数据
不可反复读： 小王两次读取同一个记录，发现两次都不一样，原来是小李在搞鬼，始终在更新数据
幻读： 小王两次读取数据，发现读出来的条数都不一样，原来是小李在搞鬼，始终在减少 / 删除数据
失落更新：小王正在将一条数据的值批改为 5，没想到小李也在批改这条数据批改为 4，在小李批改完结之前，小王先批改实现了，小李才完结批改，这是小王发现数据怎么变成了 4

看了下面的 4 个问题，咱们都感觉小李切实是太坏了，那有没有什么办法能够帮忙到小王？

RU（Read Uncommited）：徒有其名，什么都没做，什么问题都没解决
RC（Read Commited）：能够解决脏读问题
RR（Repeatable Read）：能够解决 脏读、不可反复读、幻读 问题
Serialization（串行化）：解决所有问题

只管串行化能够解决所有问题，但所有操作都是串行的，性能无奈终局，所以罕用的隔离级别是 RC 和 RR（默认）。RR 能够解决 脏读、不可反复读、幻读 问题，那最初一个 失落更新 咱们就要另外想办法解决了

2）乐观锁

乐观心态，认为数据发生冲突的概率很大，在读之前就间接上锁，能够利用 select xxx for update 语句。但会存在拿到锁之后始终没开释的问题，在高并发场景下会造成大量申请阻塞

3）乐观锁

乐观心态，认为数据发生冲突的概率很小，读之前不上锁，写的时候才判断原有的数据是否被其余事务批改了，也就是常说的 CAS。

CAS 的核心思想是：数据读出来的时候有一个版本 v1，而后在内存外面批改，当再写回去的时候，如果发现数据库中的版本不是 v1（比 v1 大），阐明在批改的期间内别的事务也在批改，则放弃更新，把数据从新读出来，从新计算逻辑，再从新写回去，如此一直地重试。

6.5 事务实现原理之 1：Redo Log

事务的四大外围属性：

原子性： 事务要么不执行，要么齐全执行。如果执行一半，宕机重启，已执行的一半要回滚回去
一致性：事务的执行使得数据库从一种正确状态转换成另外一种正确状态
隔离性：在事务正确提交之前，不容许把该事务对数据的任何扭转提供给其余事务
持久性：一旦事务提交，数据就不能丢

1）Write-Ahead

一个事务存在批改多张表的多条记录，而多条记录又可散布在不同的 Page 外面，对应着磁盘的不同文职。如果每个事务都间接写磁盘，性能势必达不到要求。

解决的形式就是在内存中进行事务提交，而后通过后盾线程异步地把内存中的数据写入到磁盘中。但这个时候又会有个问题，那就是如果产生宕机，内存中的数据没来得及刷盘就失落了。

而这个时候 Redo Log 就是用来解决这种问题

一样是先在内存中提交事务，而后写日志（Redo Log），而后后台任务把内存中的数据异步刷到磁盘中。日志是程序的记录在尾部，这样就能够防止一个事务产生屡次磁盘随机 I /O 问题。

从图中咱们能够看到，在事务提交之后，Redo Log 先写入到内存中的 Redo Log Buffer 中，而后异步地刷到磁盘的 Redo Log。因而不光光事务批改的操作是异步刷盘的，Redo Log 的写入也是异步刷盘的。

既然都是先写到内存中，那么产生宕机还是会呈现失落数据的问题，因而 InnoDB 有个参数 innodb_flush_log_at_trx_commit 能够管制刷盘策略：

0：每秒刷一次，默认的策略
1：每提交一个事务，就刷一次（最平安）
2：不刷盘。而后依据参数 innodb_flush_log_at_timeout 设置的值决定刷盘频率。

总结：0 和 2 都可能失落数据，1 是最平安的，然而性能是最差的

2）日志构造

从物理构造上来看，日志是一个永不完结的字节流，但从逻辑构造上看，日志不可能是一个永不完结的字节流

因而在 Redo Log 中存在一个 LSN（Log Sequence Number）的编号（依照工夫程序），在肯定工夫后之前的历史日志就会归档，并从头开始循环应用

在 Redo Log 中会采纳逻辑和物理的形式总和记录，先以 Page 为单位记录日志，而后每个 Page 中在采纳逻辑记法（记录 Page 外面的哪一行被批改了），这种记法也称为 Physiological Logging

3）解体后复原

不同事务的日志在 Redo Log 中是穿插存在的，也就意味着未提交的事务也在 Redo Log 中。而解体后复原就会用到一个名为 ARIES 算法，不论事务有没有提交，日志都会记录到 Redo Log 中，当解体再复原的时候就会把 Redo Log 全部重放一遍，提交和未提交的事务都会重放，从而让数据库回到宕机之前的状态，称之为 Repeating History。重放完结后再把宕机之前未实现的事务找进去，而后逐个利用 Undo Log 进行回滚。

4）总结

一个事务对应多条 Redo Log，并且是不间断存储的
Redo Log 只保障事务的持久性，而无关原子性
未提交的事务回滚是通过 Checkpoint 记录的“沉闷事务表”+ 每个事务日志的开始 / 完结标识 + Undo Log 实现的
Redo Log 具备幂等性，通过 LSN 实现
无论是提交的、还是未提交的事务，其对应的 Page 数据都可能被刷到了磁盘中。未提交的事务对应的 Page 数据，在宕机重启后会回滚。

6.6 事务实现原理值 2：Undo Log

下面说到进行 Redo Log 宕机回滚的时候，如果 Redo Log 中存在未提交的事务，那么就须要借助 Undo Log 进行辅助，换言之，如果 Redo Log 外面记录的都是曾经提交的事务，那么回滚的时候也就不须要 Undo Log 的帮忙

那么 Undo Log 除了在宕机复原时对未提交的事务进行回滚，还具备以下两个核心作用：

实现 隔离性
高并发

在多线程的场景中应答并发问题的策略通常有三种：

互斥锁： 一个数据对象下面只有一个锁，先到先得。（写写互斥，读写互斥，读读互斥）
读写锁： 一个数据对象一个锁，两个视图。（写写互斥，读写互斥，读读并发）
CopyOnWrite： 写时复制，写完之后再把数据对象的指针一次性赋值回去（写写并发，读写并发，读读并发）

Undo Log 的作用就是在 CopyOnWrite 局部。每个事务批改记录之前，都会先把记录拷贝一份进去，拷贝进去的那个备份就是存在 Undo Log 外面。每个事务都有惟一的编号，ID 从小到大递增，每一次批改就是一个版本，因而 Undo Log 负责的就是保护数据从旧到新的每个版本，各个版本之间的记录通过链表串联

为了不能让事务读取到正在批改的数据，只能读取历史版本，这就实现了 隔离性

Undo Log 不是 log 而是数据，因为 Undo Log 只是长期记录，当事务提交之后，对应的 Undo Log 文件就能够删除了，因而 Undo Log 成为记录的备份数据更为精确

正是有了 MVCC 这种个性，通常的 select 语句都是不加锁的，读取的全副是数据的历史版本，从而撑持高并发的查问，也就是所谓的 快照读 ，与之绝对应的是 以后读

快照读 / 以后读

读取历史数据的形式就叫做 快照读 ，而读取数据库最新版本数据的形式叫做 以后读

快照读

当执行 select 操作时，InnoDB 默认会执行快照读，会记录下这次 select 后的后果，之后 select 的时候就会返回这次快照的数据，即便其余事务提交了不会影响以后 select 的数据，这就实现了 可反复读。

快照的生成当在第一次执行 select 的时候，也就是说假如当 A 开启了事务，而后没有执行任何操作，这时候 B insert 了一条数据而后 commit，这时 A 执行 select，那么返回的数据中就会有 B 增加的那条数据。之后无论再有其余事务 commit 都没有关系，因为快照曾经生成了，前面的 select 都是依据快照来的。

以后读

对于会对数据批改的操作（update、insert、delete）都是采纳 以后读 的模式。在执行这几个操作时会读取最新的版本号记录，写操作后会把版本号改为以后事务的版本号，所以即便是别的事务提交的数据也能够查问到。

假如要 update 一条记录，然而在另一个事务中曾经 delete 掉这条数据并且 commit 了，如果 update 就会产生抵触，也正是因为这样所以会产生幻读，所以在 update 的时候须要晓得最新的记录。

6.7 Binlog 与主从复制

Binlog 称之为记录日志，它与 Redo Log 和 Undo Log 不同之处在于，后两者是 InnoDB 引擎层面的，而 Binlog 是 Mysql 层面的，它的次要作用是用来做主从复制，它同样具备刷盘机制：

0：事务提交之后不被动刷盘，依附操作系统本身的刷盘机制
1：每提交一个事务，刷一次磁盘
n：每提交 n 个事务，刷一次磁盘

总结：0 和 n 都是不平安的，为了不失落数据，个别都是倡议双 1 保障，即 sync_binlog 和 innodb_flush_log_at_trx_commit 的值都是 1

1）Binlog 与 Redo Log 的区别

Redo Log 和 Binlog 的产生形式不同。redo log 是在物理存储引擎产生，而 Binlog 是在 mysql 数据库的 server 层产生。并且 Binlog 不仅针对 InnDB 存储引擎，MySQL 数据库中的任何存储引擎对数据库的更改都会产生 Binlog
Redo Log 和 binlog 记录的形式不同。Binlog 记录的是一种逻辑日志，即通过 sql 语句的形式来记录数据库的批改；而 InnoDB 层产生的 Redo Log 是一种物理格局的日志，记录磁盘中每一个数据页的批改
Redo Log 和 Binlog 记录的工夫点不同。Binlog 只是在事务提交实现后进行一次写入，而 Redo Log 则是在事务进行中一直写入，Redo Log 并不是随着事务提交的程序进行写入的，这也就是说在 Redo Log 中针对一个事务会有多个不间断的记录日志

2）主从复制

Mysql 有三种主从复制的形式

同步复制： 所有的 Slave 都承受完 Binlog 才认为事务提交胜利，便返回胜利的后果
异步复制： 只有 Master 事务提交胜利，就对客户端返回胜利，而后通过后盾线程的形式把 Binlog 同步给 Slave（可能会丢数据）
半同步复制： Master 事务提交，同时把 Binlog 同步给 Slave，只有局部 Slave 接管到了 Binlog（数量可设置），就认为事务提交胜利，返回胜利后果

总结：无论异步复制，还是半异步复制（可能进化为异步复制），都可能在主从切换的时候丢数据。业务个别的做法是就义一致性来换取高可用性，即在 Master 宕机后切换到 Slave，忍耐大量的数据失落，后续再人工修复

3）并行复制

原生的 MySQL 主从复制都是单线程的，将 Master 的 Binlog 发送到 Slave 上后生成 RelayLog 文件，Slave 再对 RelayLog 文件进行重放

而所谓的并行复制实际上是并行回放，传输还是单线程，然而回放是使多线程

开源运行的衰亡，最不缺的便是开发框架，现市面上有各种各样的轮子

任何问题都是速途同归，到最初只能通过两种操作：读和写。

8.1 高并发读

1. 加缓存

缓存可分为 本地缓存 和 集中式缓存。应用缓存的同时咱们须要思考缓存的更新策略：

被动更新： 当数据库中的数据产生变更的时候，被动删除或更新缓存中的数据
被动更新： 当用户查问申请到来时，再对缓存进行更新

同样应用缓存可能会面临的几个问题：

缓存雪崩： 即缓存的高可用问题。如果缓存宕机 / 过期，所有申请会霎时压垮数据库
缓存穿透： 查问缓存中不存在的数据，导致短时间内大量申请写入并压垮数据库
缓存击穿： 缓存中热点数据过期，间接拜访数据库，导致数据库被压垮

那么缓存的应用无外乎都是对数据进行冗余，达到空间换工夫的成果

2. 并发读

单线程不行，通常就会应用多线程。这种显著治本不指标，容易达到性能瓶颈

3. 重写轻读

当微博这种大流量的平台，查看关注人和本人公布的微博列表看似很简略需要，通常只须要两张表，一个是 关注关系表 ，一个是 微博公布表。然而对于高并发查问的时候很容易将数据库打崩。

那咱们就须要改成 重写轻读 的形式，不是查问的时候才聚合，，而是提前为每个 userId 筹备一个 收件箱

当某个被关注的用户公布微博时，只须要将这条微博发送给所有关注本人每个用户的收件箱中，这样用户查问的时候只须要查看本人的收件箱即可。

但通过应用 重写轻读 容易带来一个问题，那就是如果一个人领有了 500 万粉丝，那就意味着他须要往 500 万个收件箱中推送，这对系统来说同样是个不小的挑战，那这个时候就须要采纳 推拉联合 的形式

对于粉丝量少的用户（设个阈值），发送微博后能够间接推送到用户的收件箱，对于粉丝较多的用户，只推送给在线的用户，对于读的一端，用户有些能够通过收件箱获取，有些须要本人手动去拉，这种就是推拉联合的形式

8.2 高并发写

1. 数据分片

常见的有：分库分表、Java 的 ConcurrentHashMap、Kafka 的 partition

2. 工作分片

数据分片是对要解决的数据（或申请）进行分片，工作分片是对处理程序自身进行分片。

常见的有：CPU 的指令流水线、Map/Reduce、Tomcat 的 1 +N+ M 网络模型

3. 异步化

通过消息中间件，分流解决

4. 批量解决

不论是 Mysql、Redis、Kafka 通常上都不会将数据一条一条的进行解决，而是多条合并成一条，一次性写入

8.3 容量布局

高并发读写是一种定性分析，而压力测试和容量布局就是一种定量分析

1）吞吐量、响应工夫与并发数

这三个概念都是比拟常见的

吞吐量：单位工夫内解决的申请数，例如 QPS、TPS 等指标
响应工夫：解决每个申请须要的事件
并发数：服务器同时并行处理的申请个数

三者关系：吞吐量 * 响应工夫 = 并发数

关键点阐明：议论吞吐量（QPS）的时候，肯定须要谈对应的响应工夫是多少，随着 QPS 的减少，响应工夫也在减少，尽管 QPS 提上来了，但用户端的响应工夫却变长了，客户端的超时率减少，用户体验变差，所以这两者须要衡量，不能一昧地晋升 QPS，而不顾及响应工夫

2）压力测试与容量评估

容量评估的基本思路：

机器数 = 预估总流量 / 单机流量

其中分子是一个预估的值（通过历史数据预估），分母通过压力测试失去

在计算的时候须要应用峰值测算，而不能应用均值。只管有时候峰值继续的工夫很短，但不容忽视。

压力测试方法：

线上压力测试比照测试环境压力测试
读接口压力测试比照写接口压力测试
单机压力测试比照全链路压力测试

高并发使零碎更有效率，高可用使零碎更牢靠

9.1 多正本

不要把所有鸡蛋放到一个篮子里

1）本地缓存多正本

利用音讯两头（公布 / 订阅机制），一条音讯收回，多台机器收到后更新本人的本地缓存

2）Redis 多正本

Redis Cluster 提供了 Master – Slave 之间的复制机制，当 Master 宕机后能够切换到 Slave。

3）MySQL 多正本

MySQL 之间能够用到异步复制或半异步复制，同步复制性能较差，比拟少用

4）消息中间件多正本

对于 Kafka 类的消息中间件，一个 Partition 通常至多会指定三个正本，为此 Kafka 专门设计了一种称为 ISR 的算法，在多个正本之间做音讯的同步

9.2 隔离、限流、熔断和降级

1）隔离

隔离是指将零碎或资源宰割开，在零碎产生故障时能限定流传范畴和影响范畴，即产生故障后不会呈现滚雪球的效应

数据隔离
机器隔离
线程池隔离：外围业务的线程池须要和非核心业务的线程池隔离开
信号量隔离

信号量隔离是 Hystrix 提出的一种隔离形式，比线程池隔离更要轻量，因为线程池太多会导致线程过多从而导致切换的开销大，而应用信号量隔离不会额定减少线程池，只在调用线程外部执行。信号量实质上是一个数字，记录以后拜访某个资源的并发线程数，在线程拜访资源之前获取信号量，拜访完结时开释信号量，一旦信号量达到阈值，便申请不到信号量，会间接 抛弃申请，而不是阻塞期待

2）限流

限流能够分为技术层面的限流和业务层面的限流。技术层面的限流比拟通用，各种业务场景都能够用到；业务层面的限流须要依据具体的业务场景做开发。

具体操作能够空降：《餐厅小故事》| 服务限流的施行

3）熔断

依据申请失败率做熔断
依据申请响应做熔断

留神点： 限流是服务端，依据其能力下限设置一个过载爱护；而熔断是调用方对本人的一个爱护。能熔断的服务必定不是外围链路上的必选服务，如果是的话，则服务超时或者宕机，前端就不能用了，而不是熔断。熔断其实也是降级的一种形式

4）降级

降级是一种兜底计划，是在零碎出故障之后的一个尽力而为的措施，比拟偏差业务层面

9.3 灰度公布与回滚

频繁进行零碎变更是个危险较高的操作。灰度与回滚能够使该操作变的绝对牢靠稳固

1）新性能上线的灰度

当一个新的性能上线时，能够将一部分流量导入到这个新的性能，如果验证性能没有问题，再一点点减少流量，最终让所有流量都切换到这个新性能上。

按 userId 进行流量划分
固定位数进行流量划分
属性或标签进行流量划分

2）旧零碎重构的灰度

如果旧的零碎被重构了，咱们不可能在一瞬间把所有旧的零碎下线，齐全变成新的零碎，个别会继续一段时间，新旧零碎同时共存，就须要减少流量分配机制。

3）回滚

回滚的形式：

安装包回滚： 这种形式最简略，不须要开发额定的代码，发现线上有问题间接重新部署之前的装置版本
性能回滚： 在开发新性能的时候，能够配置相应的配置开关，一旦发现新性能有问题，则敞开开关，让所有流量进入老零碎

分布式解决方案

1）2 PC 实践

2 PC 中有两个角色：事务协调者 与事务参与者

每一个数据库就是一个参与者，调用方也就是协调者，2 PC 将事务的提交分为两个阶段：

阶段一：协调者向所有参与者询问是否能够提交事务，并期待回复，各参与者执行事务操作，将 undo 和 redo 日志计入事务日志中，执行胜利后给协调者反馈 ack
阶段二：如果阶段一胜利，则告诉参与者提交事务，否则利用 undo 日志进行回滚

这种形式也存在了许多问题：

性能问题：所有参与者在事务比拟阶段处于同步阻塞状态，容易导致性能瓶颈
可靠性问题：如果协调者呈现问题，那么会始终处于锁定状态
数据一致性问题：在阶段 2 中如果协调者和参与者都挂了，有可能导致数据不统一

2）3PC 实践

解决了 2PC 同时挂掉的问题，将 2PC 的筹备阶段再次一分为二

阶段一：协调者向所有参与者收回蕴含事务内容的 canCommit 申请，询问是否能够提交事务
阶段二：如果阶段一胜利，协调者会再次收回 preCommit 申请，进入筹备阶段，参与者将 undo 和 redo 日志计入事务日志中。如果阶段一失败，协调者则收回 abort 申请，参与者便会中断事务
阶段三：如果阶段二胜利，协调者收回 doCommit 申请，参与者便会真正提交事务。如果失败，便会收回 rollback 申请，参与者会利用 undo 事务进行回滚，并完结事务

该形式仍然会造成数据不统一问题：如果 preCommit 阶段存在局部节点返回 nack，那么协调者刚要中断事务便挂掉了，肯定工夫后参与者便会持续提交事务，造成数据不统一问题

3）弥补事务 TCC

TCC（try-confirm-cancel）是服务化的二阶段编程模型，核心思想是：针对每个操作都要注册一个与其对应的确认和弥补（撤销操作）。他同样也是分为三个步骤

try 阶段：次要是对业务零碎做检测及资源预留
confirm 阶段：次要是对业务零碎做确认提交。try 阶段执行胜利并开始执行 confirm 阶段，默认状况下 try 胜利，confirm 肯定会胜利
cancel 阶段：次要是业务执行谬误，执行回滚，将预留的资源开释

例子：转账操作，第一步在 try 阶段，首先调用近程接口把本人和对方的钱解冻起来，第二步在 confirm 阶段，执行转账操作，如果胜利则进行冻结，否则执行 cancel

它解决了数据最终一致性的问题，通过 confirm 和 cancel 的幂等性，保证数据一致性

4）最终一致性（消息中间件）

能够基于 RocketMQ 实现最终一致性。为了能通过消息中间件解决该问题，同时又不和业务耦合，RocketMQ 提出了“事务音讯”的概念

步骤 1：零碎 A 调用 Prepare 接口，预发送音讯。此时音讯保留在消息中间件里，但消息中间件不会把音讯给生产方生产，音讯只是暂存在那。
步骤 2：零碎 A 更新数据库，进行扣钱操作。
步骤 3：零碎 A 调用 Comfirm 接口，确认发送音讯。此时消息中间件才会把音讯给生产方进行生产。

RocketMQ 会定期（默认是 1min）扫描所有的预发送但还没有确认的音讯，回调给发送方，询问这条音讯是要收回去，还是勾销。发送方依据本人的业务数据，判断这条音讯是应该收回去（DB 更新胜利了），还是应该勾销（DB 更新失败）

无论是 MySQL 的 Master/Slave，还是 Redis 的 Master/Slave，或是 Kafka 的多正本复制，都是通过就义一致性来换取高可用性的。

本章次要对 Paxos、Zab、Raft 三种算法进行解析。做出的笔记内容较多，保障本篇篇幅的状况下，思考独自抽出解说，有趣味的小伙伴能够后续关注~！

强一致性 Consistency：是指所有节点同时看到雷同的数据。
可用性 Availability：任何时候，读写操作都是胜利的，保障服务始终可用
分区容错性 Partition tolerance：当局部节点呈现音讯失落或分区故障的时候，分布式系统依然可能运行

CP 的零碎谋求强一致性，比方 Zookeeper，但就义了肯定的性能

AP 的零碎谋求高可用，就义了肯定的一致性，比方数据库的主从复制、Kafka 的主从复制

1）分布式锁

1. 基于 Zookeeper 实现

能够利用 Zookeeper 的 刹时节点 的个性。每次加锁都是创立一个刹时节点，开释锁则删除刹时节点。因为 Zookeeper 和客户端之间通过心跳探测客户端是否宕机，如果宕机，则 Zookeeper 检测到后主动删除刹时节点，从而开释锁。

2. 基于 Redis 实现

Redis 的性能比 Zookeeper 更好，所以通常用来实现分布式锁。但 Redis 绝对 Zookeeper 也存在些许问题

没有强一致性的 Zab 协定。如果 Master 宕机，Slave 会失落局部数据，造成多个过程拿到同一把锁
没有心跳检测。在开释锁之前宕机，会导致锁永远不会开释

1）产品经理与需要分析师

产品经理从某种意义上来说就称之为需要分析师。作为一个技术人员，不须要像产品经理或需要分析师那样对需要一目了然，但具备良好的业务意识确是做业务架构的根本条件

那么什么业务意识？

理解需要来自何处

有时需要来自何处，技术为谁而坐，往往和公司的基因、盈利模式严密挂钩，公司自身决定了需要从什么中央来

判断是真需要还是假需要

很多起因都会导致伪需要，比方老板的决定，面向 KPI 的需要。而其中存在一个因素便是：信息流传的递加效应

当产生一个事件时，第一个人 A 看到事件的全过程，把握 100 的信息量，形容给 B 的时候，受制于记忆力、表达力等因素只能形容出 90 的信息，往下递推，到 D 的时候可能只剩 60 的信息。

所以，作为一个技术人员，当从产品经理接到需要的时候，肯定要回溯，明确需要是在什么背景下提出的，到底要解决用户的什么问题。

需要的优先级

人力资源和工夫资源是无限的。如何正当调配尤为重要

2）业务是什么

一个内容能称为一个业务，往往具备一个特点，就是闭环。

什么是闭环？

团队闭环：有本人的产品、技术、经营和销售联合作战
产品闭环：从内容的生成到生产，整条链路把控
商业闭环：具备自负盈亏的能力
纵向闭环：某个垂直畛域，涵盖从前到后
横向闭环：平台模式，横向笼罩某个横切面

3）业务架构的双重含意

业务架构既关乎组织架构，也关乎技术架构

从实践上讲，正当的团队的组织架构应该是依据业务的倒退来决定的，不同的公司在不同的倒退阶段会依据业务的倒退状况，将壮大的业务拆分，萎靡的业务合并
反对业务的技术架构，业务架构和计数架构会相互作用，相互影响

1）伪分层

不论是业务架构还是技术架构，C 端业务还是 B 端业务，咱们都会用到分层技术

伪分层的特色

底层调用下层：设计分层的时候应深刻思考 DIP（依赖反转）准则
同层之间，服务之间各种双向调用： 这个很容易造成循环依赖问题，思考是否要抽取 Middle 层来作为中间层
层之间没有隔离，参数层层透传，始终穿透到最低层，导致底层零碎常常变动

总结

越底层的零碎越繁多、越简略、越固化
越下层的零碎花色越多、越容易变动。要做到这一点，须要层与层之间有很好的隔离和形象。
层与层之间的关系应该严格遵守下层调用上层的准则

2）边界思维

1. 对象层面（SOLID 准则）

一个函数、一个类、一个模块只做一件事，不要把不同的职责糅在一起，这就是边界思维的一种体现

2. 接口层面

首先想到的不是如何实现，而是把零碎当做一个黑盒，看零碎对外提供的接口是什么，接口也就是零碎的边界，定义了零碎能够反对什么、不反对什么。所以接口的设计往往比接口的实现更重要！

3. 产品层面

外部实现很简单，用户界面很简略，把简单留给本人，把简略留给用户

4. 组织构造层面

总结：边界思维的重点在于束缚，是一个 “ 负办法 ” 的思维形式。架构强调的不是零碎能反对什么，而是零碎的“束缚”是什么，不论是业务束缚，还是技术束缚。没有“束缚”，就没有架构。一个设计或零碎，如果“无所不能”

3）系统化思维

系统化零碎不在于头痛医头脚痛医脚，而是追溯源头，关注整体上的影响，把不同的货色串在一起思考，而不是割裂后离开来看

4）利益相关者剖析

当谈到零碎的时候，首先要确定的是零碎为哪几类人服务，同哪几个内部零碎交互，也就确定了零碎的边界。

5）非功能性需要剖析（以终为始）

软件有性能需要和非性能需要，非功能性需要有：

并发性：关注点在于零碎能抵制多大的流量
一致性：数据一致性问题
可用性：是否保障服务始终处于可用状态
可维护性：关注点在于代码的可了解性
可扩展性： 零碎性能是否可能灵便扩大，而不会遇到一个需要就须要大刀阔斧地批改
可重用性： 开发新的需要，旧的功能模块能够拿过去间接用

6）形象

语言只是对事实中咱们所留神到的事务特色的一种形象，每一次命名，都是一个抽象化的过程，这个过程会疏忽掉事实事务的许多特色。然而形象的目标是为了交换提供便当，而不是给交换带来累赘，因而咱们须要对本人的每一次形象负责，不能形象到最初本人都不明确形象的含意是什么。

形象的几种特色：

越形象的词，在词典中个数越少；越具象的词，在词典中个数越多。
越形象的词，自身所表白的特色越少；越具象的词，特色越丰盛。
越形象的词，意义越容易被多重解读；越具象的词，意义越明确

7）建模

建模的实质：把重要的货色进行 显性化 ，进而把这些显性化的 结构块 相互串联起来，组成一个体系

8）正交合成

合成是一个很奢侈的思维形式，把一个大的货色分成几个局部。比合成更为谨严，更为零碎的是 正交合成，须要保障两个准则：

分清：同一档次的多个局部之间要互相独立，无重叠
分净：齐全穷尽，无脱漏

该章节次要是对 DDD(畛域驱动模型) 做出解释，比拟泛化，这里举荐一本好书 《实现畛域驱动设计》，书中对 DDD 讲解的绝对具体，这本书小菜最近也在啃读中，后续会出相应的读书笔记，请搭档们点点关注，后续不会迷路！

1）能力模型

对于程序员来说，咱们是干技术，很纯正，技术很好示意你能力越强。然而当你缓缓职位上涨的时候，会发现技术不能代表你的全副。

1. 格局

关上格局，关上格局，平时常说的一句调侃的话却分外重要。

做技术咱们须要开阔视野关上格局，咱们能力理解更多的技术栈，更好的使用到我的项目中。

做产品咱们须要开阔视野关上格局，咱们能力理解市面上的竞品是什么样子，更好的借鉴到本人的我的项目中。

2. 历史观

格局是从空间的角度对待问题，而 历史观 则是从工夫的角度对待问题。任何一种技术，都不是凭空想进去的，任何一个需要，都不是凭空捏造的，咱们须要进行回溯，理解它诞生的背景，能力知其所以然。

3. 形象能力

有些人形象进去的事物能够让他人一眼贯通，有些人形象进去的事物却连本人的看不懂。这就是形象能力的体现。

很多写代码的人习惯利用 自底向上 的思维解决问题，探讨需要的时候首先想到的是这个需要如何实现，而不是这个需要自身合不合理，对于很多新人来说 需要的合不合理，依赖于需要好不好实现 ，这样的形式很容易导致 只见树木，不见森林，最初吞没在各种盘根错节的细节中。

4. 深刻思考的能力

深刻思考的能力次要考查技术的深度

深度并不示意要在所有畛域都很精通，而是专一于某个畛域，对于专家和全栈工程师的区别，想想哪个职位的薪资可能会更高

5. 落地能力

落地能力值的就是执行力，有空头画大饼的能力，却无落地去实现的能力，只会妨碍我的项目的失常前行。这大略就是技术不喜销售的起因吧

2）影响力的塑造

进入职场的前几年尤为要害，有的人青云直上，有的人却止步不前。那就是没能很好的塑造本人的影响力。影响力该如何塑造？

1. 要害时候能顶上

最怕的是 事不关己高高挂起 的心态，如果下次摊上事的是你如何？如果当团队中遇到问题，这个时候可能迎上，相对能够让人晓得还有你这一号人物（当然要斟酌抗下的危险，迎难而上并不意味着示弱）

2. 打工思维和老板思维

尽管咱们常说本人是打工人，但有的时候何不把本人当成合伙人？

打工的思维，安顿的事须要干一件，绝不多一点，只管好本人的一亩三分地

老板的思维，这个产品的价值在哪？这个产品存在哪些问题，须要如何改良？为何用户始终投诉的事，还没及时处理？

3. 空杯心态

术业有专攻，程度再高的人都须要谨记山外有山人外有人，否则就会始终待在本人的舒服圈中，刚愎自用

4. 建言献策

不用胆怯本人的答复是否正确，而前怕狼; 后怕虎不敢发言，充分发挥 圆桌文化，有倡议有想法大胆提出，不然你是想留给本人的蛔虫晓得吗

1）不确定性与危险把控

技术治理的首要任务就是 项目管理，通常存在以下几种不确定性

1. 需要的不确定性

因为各种内部条件，导致需要提议的想法不是很成熟（可能只是头脑风暴），处于须要一直优化的阶段，那么这个时候过早的进行开发容易浪费资源。作为技术负责人就须要和产品经理以及相干的业务方进行宽泛的头痛，须要达成共识的状况，能力投入。

2. 技术的不确定性

启动新我的项目的时，最怕的就是一开始技术没有很好的选型，到两头开发阶段时候再进行替换，这种劳民伤财的事件还是尽量避免产生。必须在我的项目晚期的时候就进行过多的调研和测试。

3. 人员的不确定性

当初的大多数职员都是面向金线开发，大多数退职状况并不是那么稳固，而将我的项目的大多权限与业务集中在一名成员上是个不明智的抉择，可能进行 AB 岗位开发是个不错的抉择，两人之间的业务互相相熟，哪怕是因为销假的起因也能很快的进行代替补充

4. 组织的不确定性

公司越大，业务越简单，部门越多。轻易做一个我的项目，都可能与好几个业务部门打交道。这些部门可能还在异地，平时只能即时通信，或者近程电话沟通。对于这种状况，在项目前期必须要做尽可能多的沟通，调研对方提供的业务能力，哪些目前有，哪些还在开发中，哪些还没有开发。在充沛沟通的根底上，和对方敲定排期表，不定期地同步进度，保障对方的进度和本人在一个节奏上。