高可用架构笔记

分布式系统中的事务问题

https://www.cnblogs.com/mushroom/p/13788039.html

https://studygolang.com/articles/24701

https://servicecomb.apache.org/docs/distributed_saga_3/

分布式系统的一致性协议之 2PC 和 3PC （很好）

https://www.cnblogs.com/sunsky303/p/9290992.html

一致性协议： * 两阶段递交 2PC * 三阶段递交 3PC 落地方案： * XA规范 最终一致性方案： * TCC

MySQL如何实现 XA 规范

https://www.cnblogs.com/ityannic/p/12901532.html

https://codingnote.cc/zh-tw/p/76430/

https://zhuanlan.zhihu.com/p/35737689

https://blog.lpc-win32.com/2018/11/22/consensus-2pc-3pc/

https://blog.csdn.net/qq_38289815/article/details/108714855

三阶段提交（Three-phase commit），是二阶段提交（2PC）的改进版本。三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，

2PC 存在的问题是当 协作者 崩溃时，参与者 不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。

Paxos 协议

Paxos 协议用于解决多个节点之间的数据一致性问题。

分布式理论：BASE理论

https://baijiahao.baidu.com/s?id=1634401106583534524

BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。

BASE理论的内容

* 基本可用（Basically Available）

* 软状态（Soft State）

* 最终一致性（Eventually Consistent）

总体来说BASE理论面向的是大型高可用、可扩展的分布式系统。与传统ACID特性相反，不同于ACID的强一致性模型，

BASE提出通过牺牲强一致性来获得可用性，并允许数据段时间内的不一致，但是最终达到一致状态。同时，在实际分布式场景中，不同业务对数据的一致性要求不一样。因此在设计中，ACID和BASE理论往往又会结合使用。

etcd

https://pandaychen.github.io/2019/10/24/ETCD-DISTRIBUTED-LOCK/

https://luyanan.com/news/info/20600360060485.html

https://feisky.gitbooks.io/kubernetes/content/components/etcd.html

Kafka 高可用设计 -- 复制原理介绍 ISR （in-sync replica）

https://cloud.tencent.com/developer/article/1083684

https://www.cnblogs.com/qingyunzong/p/9004703.html

redis的高可用

对于生产环境，高可用是避免不了要面对的问题，无论什么环境、服务，只要用于生产，就需要满足高可用；

https://www.cnblogs.com/youzhibing/p/8466491.html

高并发

苏宁高时效、高并发秒杀业务中台的设计与实现

https://www.infoq.cn/article/elltgtrgrjktusobmxrb

浅谈大规模高并发服务的伸缩问题

什么是大规模高并发？

https://www.cnblogs.com/xingxueliao/p/11640952.html

https://www.cnblogs.com/xingxueliao/p/10069479.html

归根结底，方式方法，教你怎么具体去做的都只是表面，最关键的是要认识到，问题的本质是什么？

我的意思并不是让咱们都成为该领域的专家，因为术业有专攻，分工配合才是重中之重，如果我们没有跟业务需求方达成紧密的一致，就有可能造成浪费。

关于游戏场景中，状态一致性那些破事

https://www.cnblogs.com/xingxueliao/p/11561263.html#event_and_state

并发到底带来了什么问题？

https://www.cnblogs.com/xingxueliao/p/11672109.html

分布式系统事务随笔

https://www.cnblogs.com/xingxueliao/p/6706898.html

一个有关微服务模式汇总网站，每一个模式都能解决特定的问题

https://microservices.io/patterns/cn/index.html

什么是状态？

状态就是历史事件的影响累加，在某一个时间点上的数据快照。

再来讲状态的一致性，我们就知道它所要求的具体是什么了，那就是某一个时间点的状态（快照），它必须符合我们的预期，这个预期的来源是我们相对于上一个时间点的状态观察，执行了新的操作（事件），所预测的合理结果。

我们认定发生了不一致，只有在我们发现不符合我们的预期的时候，才能给它下一个定义，说它不一致了。

不一致反映出来的问题是什么？有可能是业务逻辑设计上的缺陷，也有可能是我们的编码问题而造成的，这是在两个层面上看待问题。

所以不同层面反映出的问题，它的解决方法是不一样的，我们没有办法通过技术去解决原本在逻辑上就有缺陷的问题。

分布式系统有两大主题：分区和副本

分区（Partition）是为了解决扩展性的问题——如何拆分工作负载、让多个节点分工合作。

副本（Replication）则是为了解决高可用的问题，对于一个包含成百上千台节点的系统来说，宕机一台是家常便饭的事情，整个系统必须在这种情况下保持可用性。

副本除了带来高可用，也带来了另一个棘手的问题：分布式一致性（Consensus）。

为了高可用就要拷贝多份数据，而操作多份数据就会有不一致的可能，所谓一致性算法就是为了在分布式集群中保证多个副本数据一致。

MMM与MHA以及MGR，高可用架构都有如下的共同点：

对主从复制集群中的Master节点进行监控

自动的对Master进行迁移，通过VIP。

重新配置集群中的其它slave对新的Master进行同步

什么是高可用架构

https://www.cnblogs.com/tengpan-cn/p/7193300.html

在介绍高可用架构的方案之前，先说一下什么是高可用架构，高可用架构应具备但不限于以下特征：

主从切换

很好理解，当其中一台机器的服务宕机后，对于服务调用者来说，能够迅速的切换到其他可用服务，从服务升级为主服务，这种切换速度应当控制在秒级别（几秒钟）。

当宕机的服务恢复之后，自动变为从服务，主从服务角色切换。主从切换一定是要付出代价的，所以当主服务恢复之后，也就不再替换现有的主服务。

负载均衡

当服务的请求量比较高的时候，一台服务不能满足需求，这时候需要多台机器提供同样的服务，将所有请求分发到不同机器上。

高可用架构中应该具有丰富的负载均衡策略和易调节负载的方式。

甚至可以自动化智能调节，例如由于机器性能的原因，响应时间可能不一样，这时候可以向性能差的机器少一点分发量，保证各个机器响应时间的均衡。

易横向扩展

当用户量越来越多，已有服务不能承载更多的用户的时候，便需要对服务进行扩展，扩展的方式最好是不触动原有服务，对于服务的调用者是透明的。

【软件架构篇】浅谈高可用

https://www.jianshu.com/p/35e4c2db6fde

高可用架构(转载）

https://www.cnblogs.com/shizhiyi/p/7750493.html

高可用架构的6大常规方案

https://www.cnblogs.com/tengpan-cn/p/7193300.html

什么是高可用

https://www.cnblogs.com/shizhiyi/p/7750530.html

数据库架构杂谈（2）高可用与一致性

https://zhuanlan.zhihu.com/p/340189997

高可用基本架构

https://blog.csdn.net/u010489158/article/details/87029449

微服务高可用之熔断器实现原理与 Golang 实践

https://mp.weixin.qq.com/s/NwhAqx49FcTafcTRoIdOqQ

go打造分布式系统及中间件设计

https://4m.cn/3034v

微服务高可用之熔断器实现原理与 Golang 实践

https://4m.cn/Xkd5b

限流、负载、降级、柔性

后台必备意识——柔性可用

https://cloud.tencent.com/developer/article/1339887

柔性事务

刚性事务：遵循ACID原则，强一致性。

柔性事务：遵循BASE理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

什么是柔性可用

柔性可用是指：当条件有限而不能向用户提供完美服务时，可以以柔性的方式提供有损的服务。

柔性可用的目标是：最大程度的保证关键服务的可用性。

柔性可用的实现步骤

要实现柔性可用的系统，在产品设计和技术实现两个阶段都应该有柔性的意识。

实现柔性可用的系统，通常包含以下步骤：

服务分级： 在产品设计阶段，需要对服务的应用场景进行还原。要清楚地认识到哪些服务是系统的核心服务，哪些服务是支撑服务。（这不单单是从重要性进行分级，还要考虑，有些服务是需要实时完成还是可以离线完成后延迟同步）

自身能力评估： 在产品设计阶段，要了解自己拥有的资源，对自己的负载能力有较好的评估。简单的说，就是要清楚在各种条件下，自己能提供什么样的服务。

系统划分（分级）： 在技术实现初期（系统设计），需要遵循大系统小做的原则，对系统进行拆分，避免各个服务互相影响，降低子模块耦合性。

自我监控： 系统要有自我监控能力，了解当前负载，评估是否需要提供降级服务。

降级服务： 满足降级条件时，分级提供柔性服务。

系统恢复： 当系统重新满足可以提供完美服务的条件时，升级服务等级（有能力时，还应该对之前放弃的局部服务进行恢复）

高可用方法论

工欲善其事，必先利其器。高可用在不同维度考虑的点也各不相同：

产品策略：轻重逻辑分离、用户分流、功能简化

客户端：重试、失败提示优化、客户端随机丢弃请求

接入层：全局限流、服务降级、鉴权和ACL

逻辑层：识别热点对象和热点对象预处理、事务一致性以及事务回滚

存储层：可靠性（主备/异地容灾/数据持久化）、一致性

运维：灰度发布、故障演练、混沌工程

结合上面的内容，本文主要会从以下几点保障业务高可用：

全链路压测确定业务容量

根据容量设定限流，避免高负载引起雪崩

区分主次业务，优先保障核心业务，次要业务通过限流进行服务降级

高可用性：High Availability（HA），它指的是系统具备较高的无故障运行的能力。可用性是一个抽象的概念，通常使用 MTBF 和 MTTR 等指标进行度量。

服务限流：限流是保护业务系统的利器，通过对并发访问数或者请求数进行限制或者是对一个时间窗内的请求进行限速，用于防止大流量或突发流量导致服务崩溃。

服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。

幂等性和一致性 财务系统

https://blog.csdn.net/liuhuiteng/article/details/94736173

http://suo.im/6u2pqJ

总的来说可以分为强一致性和弱一致性两大类,

弱一致性中又可以继续细分为最终一致性,因果一致性,会话一致性,单调读一致性和单调写一致性等多种,

不过弱一致性中只有最终一致性比较重要,其他的可以暂时忽略。

因而,对于满足分区容错性的系统而言,强一致性和可用性的要求难以同时被满足。

为什么幂等性对分布式系统而言如此重要？因为在分布式环境下,服务的调用一般采用http协议或者rpc的方式,即双方需要通过网络进行通信,

而因为网络故障或者消息超时的存在,可能服务消费方已经成功调用了服务提供方的服务接口,但是消费方并没有收到来自对方的成功响应,

导致消费方以为服务调用失败从而再次进行调用,也就是说网络的不可靠性导致了服务接口被多次调用的可能。分布式系统必须保证在这种情况下,

即使接口被多次调用,它对系统产生的影响应该与该接口只被调用一次的结果一样。

总结:通常只需要对新增请求和更新请求作幂等性保证。

后面还会考虑写一篇形形色色的朋友，以前，在北上广深这些地方，永远有一些你看不见的角落别人看见了，然后你只能说一句：卧槽，还可以这么玩。而现在，在全国都有这样的角落。

什么是幂等？

用户对于同一操作发起的一次请求和多次请求的结果是一致的。不会因为多次请求而产生副作用。

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

熔断/限流

https://github.com/code4wt/RateLimite

https://github.com/code4wt/RateLimiter/blob/master/src/com/tianxiaobo/ratelimiter/TokenBucketLimiter.java

https://github.com/code4wt/RateLimiter/blob/master/src/com/tianxiaobo/ratelimiter/LeakyBucketLimiter.java

http://suo.im/5CNnAI

分布式系统中的数据分为控制数据和应用数据。使用etcd的场景默认处理的数据都是控制数据，对于应用数据，只推荐数据量很小，但是更新访问频繁的情况

而Paxos强一致性算法也是素来以复杂难懂而闻名于世

使用Raft算法保证强一致性让用户易于理解。

这也是新版etcd区别于旧版的一大特性，它摒弃了使用配置文件进行参数配置的做法，转而使用命令行参数或者环境变量的做法来配置参数。

Raft中一个Term（任期）是什么意思？ Raft算法中，从时间上，一个任期讲即从一次竞选开始到下一次竞选开始。从功能上讲，如果Follower接收不到Leader节点的心跳信息，就会结束当前任期，

变为Candidate发起竞选，有助于Leader节点故障时集群的恢复。发起竞选投票时，任期值小的节点不会竞选成功。如果集群不出现故障，那么一个任期将无限延续下去。

而投票出现冲突也有可能直接进入下一任再次竞选。