写点什么

极客时间架构 1 期:第 6 周 技术选型(二) - 学习总结

用户头像
Null
关注
发布于: 2020 年 11 月 01 日

关系型数据库

关系型数据库(如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

来源:简书

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



用户头像

Null

关注

还未添加个人签名 2017.12.29 加入

还未添加个人简介

评论

发布
暂无评论
极客时间架构 1 期:第6周 技术选型(二) - 学习总结