分布式服务
按照功能进行系统拆分,拆分成独立的功能工程,可单独部署到一个服务器。
淘宝系统,由不同的子系统组成,交易系统,物流系统,购物车系统,订单系统,商品系统,
搜索系统,客服系统,结算系统等等
耦合节点:
共享数据库,通过消息中间件来维持联系,通过 rpc 来耦合
中间件系统来粘合两个系统
分布式系统架构的第一原则是不要分布!
- 目标:
提升系统的整体性能和吞吐量; - 设计的思路:
中心化和去中心化
中心化设计:master、node
问题:master宕机后,整体集群崩塌;master管理能力、
去中心化设计:
不是不要中心,是由节点自由选择中心
问题:脑裂
一般的设计思路是,当集群判断发生了脑裂问题时,规模较小的集群就“自杀”或者拒绝服务。
CAP定理(CAP theorem)
又称:布鲁尔定理
Consistence 一致性:
所有节点访问同一份最新的数据副本;
强一致性:在分布式系统中,更新操作执行成功后,所有用户都应读到最新的值,这样的系统被认为具有强一致性;
因果一致性 causal consistency:进程A通知进程B它已跟新了一数据,那进程B后续访问将是更新后的值,与A没有因果关系的进程C访问则遵守最终一致性规则;
读己之所写一致性 read-your-writes:进程A更新一个数据后,它总是访问更新过的值,不会看到旧值,也是因果一致性模型的一个特例;
会话一致性 session:把访问存储系统的进程放到会话的上下文中,只要会话存在,系统保障“读之所写一致性”一致性;
单调(monotonic)读一致性:进程已经看到过数据对象的某个值,那么任何后续访问都不会返回那个值之前的值;
单调写一致性:系统保证来自一个进程的写操作顺序执行;
Availability 可用性:
保证每次请求都能获取正确的响应
Partition tolerance 分区容错性:
分布式系统在某个节点或者网络分区发生故障时,仍可以对外提供一致性和可用性服务。
CAP的证明: 假设两个节点集{G1, G2},由于网络分片导致G1和G2之间所有的通讯都断开了,如果在G1中写,在G2中读刚写的数据, G2中返回的值不可能G1中的写值。由于A的要求,G2一定要返回这次读请求,由于P的存在,导致C一定是不可满足的。
引用:https://www.cnblogs.com/hxsyl/p/4381980.html