极客时间《架构师训练营》第六周学习笔记
关系型数据库
关系型数据库（如MySql）是一系列以表的形式组织的数据项集合。 一般通过 ACID 来描述事务特性：
- 原子性（Atomicity）：每个事务内部所有操作要么全部完成，要么全部不完成
- 一致性（Consistency ）：任何事务都使数据库从一个有效的状态转换到另一个有效状态
- 隔离性（Isolation）：并发执行事务的结果与顺序执行事务的结果相同
- 持久性（Durability ）：事务提交后，对系统的影响是永久的
关系型数据库扩展包括许多技术：主从复制、主主复制、联合、分片等等。
主从复制
主库同时负责读取和写入操作，并复制写入的数据到多个从库中，从库只负责读操作。树状形式的从库再将写入复制到更多的从库中去。如果主库离线，系统可以以只读模式运行，直到某个从库被提升为主库或有新的主库出现。
p.s. 为了政治正确，主从用 Leader 和 follower 表示
主主复制
主主复制事实上是主从复制的另一种表现形式，通常情况下也是一读一写，只是当写入的那一台数据库宕机时，另一台作为备份自动升级为写服务。这样可以保证更高可用性。
联合
联合将数据库按对应功能分割。例如，你可以有三个数据库：论坛、用户和产品，而不仅是一个单体数据库，从而减少每个数据库的读取和写入流量，减少复制延迟。较小的数据库意味着更多适合放入内存的数据，进而意味着更高的缓存命中几率。由于没有只能串行写入的中心化主库，你可以并行写入不同功能的数据，这样也提高负载能力。
联合的不利之处：
- 如果你的数据库模式需要大量的功能和数据表，联合的效率并不好
- 你需要更新应用程序的逻辑来确定要读取和写入哪个数据库
- 用 server link 从两个库联结数据更复杂
- 联合需要更多的硬件和额外的复杂度
分片
分片将数据分配在不同的数据库上，使得每个数据库仅管理整个数据集的一个子集。以 User 数据库为例，随着用户数量的增加，越来越多的分片会被添加到集群中。我们可以根据 User 的首字母分片存储到不同的数据库中。分片可以减少读取和写入流量，减少复制并提高缓存命中率。也减少了索引，通常意味着查询更快，性能更好。如果一个分片出问题，其他的仍能运行，你可以使用某种形式的冗余来防止数据丢失。类似联合，没有只能串行写入的中心化主库，你可以并行写入，提高负载能力。
分片不利之处：
- 分片一般需要额外的中间件来帮助读写（如 myCat），但是这样就增加了额外的复杂度
- 分片不合理可能导致数据负载不均衡
- 分片一般就告别 Join 操作了，联结多个分片的数据操作需要在应用程序中完成
NoSQL
NoSQL 是键-值数据库、文档型数据库、列型数据库或图数据库的统称。数据库是非规范化的，表联结大多在应用程序代码中完成。适合 NoSQL 的示例有：
- 埋点数据和日志数据
- 排行榜或者得分数据
- 临时数据，如购物车
- 频繁访问的热表
- 元数据／查找表
CAP
大多数 NoSQL 无法实现真正符合 ACID 的事务，只能支持 CAP 理论——在一个分布式计算系统中，只能同时满足下列的两点:
- 一致性（Consistency）：每次访问都能获得最新数据但可能会收到错误响应
- 可用性（Availability）：每次访问都能收到非错响应，但不保证获取到最新数据
- 分区容错性（Partition Tolerance）：在任意分区网络故障的情况下系统仍能继续运行
BASE
后来人们在实践中又提出了 BASE 理论，完善了 CAP 理论。BASE 理论如下：
- 基本可用（Basically available）：系统保证可用性。
- 软状态（Soft state）：即使没有输入，系统状态也可能随着时间变化。
- 最终一致性（Eventual consistency）：经过一段时间之后，系统最终会变一致，因为系统在此期间没有收到任何输入。
SQL 还是 NoSQL
-
选取 SQL 的原因:
- 严格的模式
- 关系型数据
- 结构化数据
- 需要复杂的联结操作
- 事务
- 清晰的扩展模式
- 既有资源更丰富：开发者、社区、代码库、工具等
- 通过索引进行查询非常快
-
选取 NoSQL 的原因：
- 半结构化数据
- 动态或灵活的模式
- 非关系型数据
- 不需要复杂的联结操作
- 存储 TB （甚至 PB）级别的数据
- 高数据密集的工作负载
- IOPS 高吞吐量
ZooKeeper
ZooKeeper 是一个分布式开源的应用程序协调服务。ZooKeeper 的实现得益于 Zab 协议作为基础的 fast Paxos 算法。ZooKeeper 主要用途：
- Hadoop：使用 Zookeeper 的事件处理确保整个集群只有一个 NameNode，存储配置信息等
- HBase：使用 Zookeeper 的事件处理确保整个集群只有一个 HMaster，察觉 HRegionServer 联机和宕机，存储访问控制列表等
- Kafka：使用 ZooKeeper 协调协调 Kafka 的各个 broker，实现 broker 的负载均衡
小结
这周主要讲了 DB 和分布式集群管理的内容。说实在这些知识我很少在实际项目中用到过，所以只能复述一下知识，顺便补充了一些我所学过的相关内容。
除了上面的内容，老师大约用了两个小时的时间，讲述了他自己实现的系统案例——Doris，设计非常精彩。但是我最大的收获是：优秀的架构师要学会向老板推销自己的设计：找到痛点、归纳需求、提出目标、设计系统，最后验证实践。我自己就是一个每天等着领导指派任务的底层小职员，除了在底下喷一些傻乂的设计，碌碌无为，毫无创新。有时候机会摆在眼前，也羞于表现，只看它一次次地从眼前划过；至今还在做一些毫无技术含量的体力活。唉，抓住机会要比个人奋斗重要得太多太多了。
