架构师训练营 - 技术选型 2
数据分片
分片目标
解决数据量超出一张表能承载的能力，或者写操作访问压力特别大。
实现分片的方式
硬编码实现数据分片
映射表外部存储
分布式数据库中间件
数据库部署方案
单一服务与单一数据库
主从复制实现伸缩
两个web服务与两个数据库
随着业务的分离，数据库也开始分离，称为业务分库。
综合部署
CAP原理
分布式数据库的指导思想。三个特性不可能完全满足。
一致性
每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read receives the most recent write or an error），而不是过期数据，也就是说，数据是一致的。要么不给返回，或者返回错误，但是一旦返回了就一定是对的，不能是过期的。
可用性
每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不要求保证是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。
分区耐受性
即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然是可以操作的（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。
CAP原理
当网络分区生效发生时，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据的一致性却得不到保证。
对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐用性说必须要保证的，那么在可用性和一致性上就必须二选一。
当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个错误码或者干脆超时，即系统不可用。而如果选择了可用性，那么系统总是可用返回一个数据，但是不保证这个数据是最新的。
所以，关于CAP原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足。
CAP原理与数据一致性冲突
最终一致性
最终一致写冲突
简单处理冲突策略：根据时间戳或版本号，进行覆盖或合并。
客户端冲突解决
投票解决冲突（Cassandra）
Cassandra分布式架构
HBase架构
HBase一致性比较高，但是可用性稍差。比如HRegionServer宕机的情况，对应的HRegion就不可访问了。
LSM树
HBase写性能非常高，因为写操作都是直接写内存。
BASE
基本可用（Basically Available）系统在出现不可预料故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。
Soft state（软状态），指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程中的延时。
Eventually consistent（最终一致性）指系统中所有数据的副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够最终达到一致，而不需要实时保证系统数据的强一致性。
分布式系统脑裂
在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，称为分布式系统脑裂。
分布式一致性算法Paxos
角色
Proposer，Acceptor，Learner
ZAB协议
Zookeeper选master过程
getData("/servers/leader",true)
if successful follow the leader described in the data and exit
create("/servers/leader", hostname, EPHEMERAL)
if successful lead and exit
goto step 1
Zookeeper性能
作业
请简述 CAP 原理。（如上总结）
针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）。
还未添加个人签名 2018.04.21 加入
还未添加个人简介
评论