架构师课程第六周 作业

一、简述CAP原理

在数据分布式系统中，出现了一些与以前的关系型数据库不一样的新问题：

1. 一致性（Consistency）：当一个数据写入请求完成之后，从任何节点拿到的数据都应该是一致的，不能出现从不同节点拿到的数据不一致的情况。这里讲的一致性是严格的强一致性，在有的时候需求不那么严格的情况下，可以损失一部分一致性，满足最终一致性即可。

2. 可用性（Availability）：每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据。由于在分布式系统中一般以集群方式提供服务，因此，当有部分节点故障时，不能影响提供服务，保证系统是可用的。

3. 分区容忍性（Partiton tolerence）：由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。

二、针对Doris案例，请用UML时序图描述Doris临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程。）

三、总结

本周只要内容有：分布式数据库解决方案、NoSQL、CAP原理、Doris分布式KV数据库、Zookeeper。

随着互联网的不断发展，互联网的业务数据呈现爆炸式的增长，传统的关系型数据库随着遇到了瓶颈。传统的关系型数据库单表随着数据越多性能越差，已不能满足未来的互联网的发展，而且单机硬件设备（尤其是磁盘容量与随机写速率）性能有限，于是聪明的互联网人们想到各种办法改进关系型数据库以及启用新型数据库引擎。首先，将单机数据库变成多台，实现多台之间的数据同步，且可以进行读写分离，大大缓解了读多写少场景下数据库的压力。其次，为了解决主库单点的问题，引入主主复制，增加高可用。但是，数据库之间的复制只是增加了读并发能力，没有增加写并发能力。为了能缓解数据库的写压力，使用了将单机数据库根据业务拆分、数据分片等手段。在分布式存储系统中，数据需要分散存储在多台设备上，数据分片（Sharding）就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的：

1. 分布均匀，即每台设备上的数据量要尽可能相近；

2. 负载均衡，即每台设备上的请求量要尽可能相近；

3. 扩缩容时产生的数据迁移尽可能少。

为了达到这些目的，需要一个好的分片路由算法，所以能设计出一个好的分片路由算法在分布式系统的数据分片中至关重要。一般时候使用取模hash、一致性hash、带虚拟节点的一致性hash等算法。

数据越来越多，而且很多时候不需要关系数据库的强结构模式，只需要一些简单的Key-Value即可满足要求，于是国外大神们设计出了NoSQL数据库，不只是SQL数据库。现在用的比较好的NoSQL数据库有MongoDB、Cassandra、大数据分布式数据库HBase以及我们经常用作缓存的Redis、Memcached等。NoSQL数据库一开始就是相比较与SQL数据库而出现的，在特定的场景中，NoSQL表现出比SQL数据库更好的性能。

分布式系统中经常要对面的CAP理论。CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。由于在分布式系统中，受各种环境的影响，分区出错一定会出现，所以必须要满足分区容错性的要求，因此大部分时候人们都是在多一点一致性或者多一点可用性上选择，当然不同的场景选择不同。很多时候，只要集群不出问题，这三个要求都可以同时兼顾，这里说的选择指的是在集群因各种状况出现了问题的时候，我们应该保谁弃谁。当我们需要做出选择的时候，往往是我们无奈的部分。说明我们还没有完全解决办法的出路。这说明了世界的不完美，也说明我们的技术还没有成熟。分布式系统中的问题主要是由于网络及多实例引起的，所以如果有一天的技术可以突破这2个方面，我相信分布式的未来才能更美好。

相比于以前的单机模式，分布式场景下有多实例，因此在严格的数据写请求下，为了保证数据的一致性，我们引入了Zookeeper这种工具。Zookeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。其实Zookeeper在如今的分布式系统中已经广泛使用，实践证实了Zookeeper的强大，不需多说。在HBase、Kafka等分布式软件中都有Zookeeper的身影。