目录
- 实现基本可用的几个策略
- 1、流量削峰（不同地区售票时间错峰出售）
- 2、延迟响应，异步处理（买票排队，基于队列先收到用户买票请求，排队异步处理，延迟响应）
- 3、体验降级（看到非实时数据，采用缓存数据提供服务）
- 4、过载保护熔断/限流，直接拒绝掉一部分请求，或者当请求队列满了，移除一部分请求，保证整体系统可用）
- 5、 故障隔离（出现故障，做到故障隔离，避免影响其他服务）
- 6.、弹性扩容（基于Metric和Monitor实现系统态势感知，做到弹性伸缩）
- 实现最终一致性的具体方式
- 1、读时修复
- 2、写时修复
- 3、异步修复
- 使用BASE理论
- 总结
- reference
BASE理论是CAP理论中AP的延申，强调可用性。它的核心是基本可用（Basically Available）和最终一致性（Eventually consistent）
实现基本可用的几个策略
基本可用本质是一种妥协，也就是出现节点故障或者系统过载时，通过牺牲非核心功能的可用性，保障核心功能的稳定运行。
实现基本可用的几个策略：
1、流量削峰（不同地区售票时间错峰出售）
以订票系统设计为例，在春运期间，开始售票前后会出现及其海量的请求峰值。
可以在不同的时间，出售不同区域的票，将访问请求错开，削弱请求峰值。
2、延迟响应，异步处理（买票排队，基于队列先收到用户买票请求，排队异步处理，延迟响应）
还以订票系统为例。用户提交购票请求后，往往会在队列中排队等待处理，可能几分钟或十几分钟后，系统才开始处理，然后响应处理结果。
3、体验降级（看到非实时数据，采用缓存数据提供服务）
以互联网系统为例，若出现网络热点事件，产生了海量的突发流量，系统过载，大量图片因为网络超时无法显示，那么可以用小图片代替原始图片，降低图片的清晰度和大小，提升系统处理能力。
4、过载保护熔断/限流，直接拒绝掉一部分请求，或者当请求队列满了，移除一部分请求，保证整体系统可用）
把接收到的请求放在指定的队列中排队处理，如果请求等待时间超时，这时直接拒绝超时请求；如果队列满了之后，就清除队列中一定数量的排队请求，保护系统不过载，实现系统基本可用。
5、 故障隔离（出现故障，做到故障隔离，避免影响其他服务）
6.、弹性扩容（基于Metric和Monitor实现系统态势感知，做到弹性伸缩）
实现最终一致性的具体方式
最终一致性是指：系统中所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。也就是说在数据一致性上存在一个短暂的延迟。
实现最终一致性有几种具体的方式：
1、读时修复
在读取数据时，检测数据的不一致，进行修复。
如Cassandra 的 Read Repair，在Cassandra 系统查询数据的侍好，如果检测到不同节点的副本数据不一致，系统就自动修复数据
2、写时修复
在写入数据时，检测数据的不一致，进行修复，主要通过失败重试。
如Cassandra 的Hinted Handoff实现，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致。
3、异步修复
通过定时对账检测副本数据的一致性，并修复。
写时修复不需要做数据一致性比对，性能消耗较低，推荐使用。
在实现最终一致性的时候，推荐同时实现自定义写一致性级别（比如 All、Quorum、One、Any）让用户可以自主选择相应的一致性级别。
使用BASE理论
DATA节点的核心功能是读和写，所以基本可用是指读和写的基本可用。可以通过分片和多副本，实现读和写的基本可用。即将同一业务的数据先分片，然后以多份副本的形式分布在不同的节点上。保障多节点多副本集群。
为了达到最终一致性，通过写时修复和异步修复。并且实现自定义写一致性级别，用户在写数据的时候，可以根据业务数据的特点设置不同的写一致性级别。
总结
ACID 理论是传统数据库常用的设计理念，追求强一致性模型。BASE 理论支持的是大型分布式系统，通过牺牲强一致性获得高可用性。BASE 理论在很大程度上，解决了事务型系统在性能、容错、可用性等方面痛点。BASE 理论在 NoSQL 中应用广泛，是 NoSQL 系统设计的事实上的理论支撑。
对于任何集群而言，不可预知的故障的最终后果，都是系统过载。如何设计过载保护，实现系统在过载时的基本可用，是开发和运营互联网后台的分布式系统的重中之重。
reference
《分布式协议与算法实战.韩健》
