架构师训练营第六周总结

1. 数据分片

• 分片方式：

• 硬编码实现数据分片

• 映射表外部存储

• 数据分片的挑战：

• 需要大量的额外代码，处理逻辑因此变得更加复杂

• 无法执行多分片的联合查询

• 无法使用数据库的事物

• 随着数据的增长，如何增加更多的服务器

• 分布式数据库中间件：Mycat

• 主要采用Amoeda/Cobar，应用服务器通过Cobar服务器集群访问数据库，通过Amoeba进行配置

• 数据服务请求流程：前端通讯模块-->SQL解析-->SQL路由-->SQL执行代理-->后端通讯模块-->数据查询-->后端通讯模块-->结果合并-->前端通讯模块

• 路由配置项主要包括：分片字段、表达式、对应数据库实例

• 集群的伸缩及扩展：

• 分片之前，评估可能的最大数据量和实例数，每个服务器创建多个实例，按照总实例数取模，添加服务器时，把整个实例移植到添加的服务器中，修改路由规则

• 注意事项：

• 有限考虑按业务分库，数据太大时，再考虑对特定表进行分片

• NOSQL

• CAP原理：

• 概念：在分布式系统必须满足分区耐受性的前提下，可用性和一致性无法同时满足，当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统可能返回一个错误码或者超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但不能保证这个数据是最新的，与一致性表述不符

• C（一致性，Consistency）：每次读取的数据都应该是最近写入的数据或返回一个错误，而不应是过期数据

• A（可用性，Availability）：每次请求都应该得到一个响应，而不是返回一个错误或者失去响应

• P（分区耐受性，Partition tolerance）：即使因为网络原因，部分服务节点之间消息丢失或者延迟，系统依然应该是可以操作的（待理解）

• 数据冲突处理方式：

• 最终一致性，按照时间戳覆盖

• 投票解决冲突（Cassandra）

• HBase架构：应用服务器-->Zookeeper-->HMaster-->HRegionServer-->HRegion-->HFile

• Doris：

• 系统架构层面，保证高可用的主要手段是――冗余：服务器热备，数据多份存储。使整个集群在部分机器故障的情况下可以进行灵活的失效转移（Failover），保证系统整体依然可用，数据持久可靠。

• 路由算法：与redis类似，固定虚拟节点个数，物理节点与多个虚拟节点对应，各服务器之间是不需要通信的，无状态

• 针对三类故障给出了处理方式

• 瞬时故障

• 临时故障

• 永久故障

• 分多个存储服务器序列，每个序列互为备份，并发写入，保证可用性，每个序列包括多个服务器，分布式存储

• Zookeeper：

• 节点数据操作流程：

• 在Client向Follwer发出一个写的请求

• Follwer把请求发送给Leader

• Leader接收到以后开始发起投票并通知Follwer进行投票

• Follwer把投票结果发送给Leader

• Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;

• Follwer把请求结果返回给Client

• Leader选举：

• 半数通过

• 3台机器 挂一台 2>3/2

• 台机器 挂2台 2！>4/2

• A提案说，我要选自己，B你同意吗？C你同意吗？B说，我同意选A；C说，我同意选A。(注意，这里超过半数了，其实在现实世界选举已经成功了。但是计算机世界是很严格，另外要理解算法，要继续模拟下去。)

• 接着B提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；C说，A已经超半数同意当选，B提案无效。

• 接着C提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；B说，A已经超半数同意当选，C的提案无效。

• 选举已经产生了Leader，后面的都是follower，只能服从Leader的命令。而且这里还有个小细节，就是其实谁先启动谁当头。



• 代码