一文网罗分布式架构原理和方法( 三 ) _分布式架构

BASE 理论
从前面的分析中我们知道 : 在分布式(数据库分片或分库存在的多个实例上)前提下，CAP 理论并不适合数据库事务(因为更新一些错误的数据而导致的失败，无论使用什么高可用方案都是徒劳的，因为数据发生了无法修正的错误) 。此外 XA 事务虽然保证了数据库在分布式系统下的 ACID (原子性、一致性、隔离性、持久性)特性，但同时也带来了一些性能方面的代价，对于并发和响应时间要求都比较高的电商平台来说，是很难接受的。
eBay 尝试了另外一条完全不同的路，放宽了数据库事务的 ACID 要求，提出了一套名为 BASE 的新准则。BASE 全称为 Basically Available,Soft-state,Eventually Consistent. 系统基本可用、软状态、数据最终一致性。相对于 CAP 来说，它大大降低了我们对系统的要求。
Basically Available(基本可用)
表示在分布式系统出现不可预知的故障时，允许瞬时部分可用性

比如我们在淘宝上搜索商品，正常情况下是在 0.5s 内返回查询结果，但是由于后端的系统故障导致查询响应时间变成了 2s
再比如数据库采用分片模式，100W 个用户数据分在 5 个数据库实例上，如果破坏了一个实例，那么可用性还有 80%，也就是 80%的用户都可以登录，系统仍然可用
电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现

Soft-state(软状态).
表示系统中的数据存在中间状态，并且这个中间状态的存在不会影响系统的整体可用性，也就是表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时; 比如订单状态，有一个待支付、支付中、支付成功、支付失败，那么支付中就是一个中间状态，这个中间状态在支付成功以后，在支付表中的状态同步给订单状态之前，中间会存在一个时间内的不一致。
Eventually consistent(数据的最终一致性)
表示的是所有数据副本在一段时间的同步后最终都能达到一个一致的状态，因此最终一致性的本质是要保证数据最终达到一致，而不需要实时保证系统数据的强一致
BASE 理论的核心思想是 : 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
七、分布式架构下的高可用设计避免单点故障

负载均衡技术(failover/选址/硬件负载/ 软件负载/去中心化的软件负载(gossip(redis- cluster)))
热备(linux HA)
多机房(同城灾备、异地灾备)

应用的高可用性

故障监控(系统监控(cpu、内存)/链路监控/日志监控) 自动预警
应用的容错设计、(服务降级、限流)自我保护能力
数据量(数据分片、读写分离)

分布式架构下的可伸缩设计

垂直伸缩
提升硬件能力
水平伸缩
增加服务器

加速静态内容访问速度的 CDN
CDN 全称是 Content Delivery Network，中文释义是内容分发网络。CDN 的作用是把用户需要的内容分发到离用户最近的地方进行响应，这样用户能够快速获取所需要的内容。CDN 本质上就是一种网络缓存技术，能够把一些相对稳定的资源放到距离最终用户较近的地方，一方面可以节省整个广域网的带宽消耗，另外一方面也可以提升用户的访问速度、改善用户体验。现实系统中我们一般会把静态的文件(图片、脚本、静态页面等)放到 CDN 中。