分布式服务

分布式服务

按照功能进行系统拆分，拆分成独立的功能工程，可单独部署到一个服务器。

淘宝系统，由不同的子系统组成，交易系统，物流系统，购物车系统，订单系统，商品系统，
搜索系统，客服系统，结算系统等等
耦合节点：
共享数据库，通过消息中间件来维持联系，通过 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