极客时间架构 1 期：第 6 周 技术选型（二） - 学习总结

关系型数据库

关系型数据库（如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 的原因：

ZooKeeper

ZooKeeper 是一个分布式开源的应用程序协调服务。ZooKeeper 的实现得益于 Zab 协议作为基础的 fast Paxos 算法。ZooKeeper 主要用途：

• Hadoop：使用 Zookeeper 的事件处理确保整个集群只有一个 NameNode，存储配置信息等

• HBase：使用 Zookeeper 的事件处理确保整个集群只有一个 HMaster，察觉 HRegionServer 联机和宕机，存储访问控制列表等

• Kafka：使用 ZooKeeper 协调协调 Kafka 的各个 broker，实现 broker 的负载均衡



搜索引擎

小结

这周主要讲了 DB 和分布式集群管理的内容。说实在这些知识我很少在实际项目中用到过，所以只能复述一下知识，顺便补充了一些我所学过的相关内容。

除了上面的内容，老师大约用了两个小时的时间，讲述了他自己实现的系统案例——Doris，设计非常精彩。但是我最大的收获是：优秀的架构师要学会向老板推销自己的设计：找到痛点、归纳需求、提出目标、设计系统，最后验证实践。我自己就是一个每天等着领导指派任务的底层小职员，除了在底下喷一些傻乂的设计，碌碌无为，毫无创新。有时候机会摆在眼前，也羞于表现，只看它一次次地从眼前划过；至今还在做一些毫无技术含量的体力活。唉，抓住机会要比个人奋斗重要得太多太多了。

作者：anOnion

链接：https://www.jianshu.com/p/1903e4d7c330

来源：简书

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。