xyc1211的博客

Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）弱一致性最终一致性（一段时间达到一致性，存在中间的不一致状态）强一致Basic Paxos与Multi Paxos核心思想缺点只能单值达成共识。多值修改 发到多个节点 产生多个Proposer，提案编号相互否定，容易导致活锁改进了Basic Paxos名词解释任期Term：节点选举成功变为Leader后 有自己的任期TermTermId：任期id，全局唯一且单调递增日志：Le

目前还没标准的方案，都在探索文章目录微服务方案1：把微服务要具备的功能耦合在框架里实现方案2：微服务与框架无关，用网络代理实现微服务功能微服务基本思路：把每个功能细化拆分 开发、部署、运维 全拆分开。大量的服务应用 产生了一系列问题：这么多应用如何相互调用这么多应用 风险怎么管，一个宕了影响其他怎么办这么多应用 请求入口都不一样，前端都看懵了这么多应用 一个个改配置文件多麻烦怎么看一个请求 到底调了哪些服务这么多应用 排查日志一个个找要多费时并产生了一套解决思路：.

文章目录XA分布式事务协议两阶段提交（2PC）三阶段提交（3PC）补偿事务（TCC）本地消息表（异步确保）MQ 事务消息XA分布式事务协议引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。XA协议中包含着两个角色：事务协调者和事务参与者两阶段提交（2PC）准备阶段协调者询问参与者事务是否执行成功，参与者执行了事务，但是还未提交把事务执行结果发给协调者。提交阶段如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调

文章目录技术角度思路 :方法 :业务角度思路 :方法 :技术角度思路 :提高性能，接收并处理所有并发请求方法 :扩展硬件性能, 最大化压榨硬件性能集群 加机器分布式 加服务Netty等 能发挥硬件性能的框架业务角度思路 :让业务慢点处理, 处理不了的排队等着或者直接返回失败，降低实际并发方法 :流量削峰消息中间件削峰漏斗分层过滤熔断器...

操作系统限制软件限制javatomcatNginxMySQL单机应用何时进行集群各个性能级别的架构方案qps 100qps 1000qps 1wqps 10wqps 1000w其他需求案例：淘宝从几百到千万级并发的十四次架构演进之路！2000年-C10K(单机1w并发问题)C10M(单机1000w并发)

架构的不确定性优秀程序员和架构师之间还有一个明显的鸿沟需要跨越，这个鸿沟就是“不确定性”。编程本质是确定的，同样一段代码，不管是谁写的，不管什么时候执行，执行的结果应该都是确定的架构设计本质上是不确定的，同样的一个系统，A 公司和 B 公司做出来的架构可能差异很大，但最后都能正常运转；架构设计并没有像编程语言那样的语法来进行约束，更多的时候是面对多种可能性时进行选择关键原因在于架构设计领域并没有一套通用的规范来指导架构师进行架构设计，更多是依赖架构师的经验和直觉有几个共性的原则隐含其中，这就

文章目录CAP理论不是所谓的“3 选 2”`分布式系统理论上不可能选择 CA 架构`CAP理论Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）一致性（Consistence）所有节点访问同一份最新的数据副本可用性（Availability）非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。分区容错性（Partition tolerance）分布式系统出现网络分区的时候，仍然能够对外提供服务。CA

单体架构:简介：所有功能都放在一个应用里.优点：便于开发，测试，部署也很方便缺陷：高访问，高并发的上限是固定的，一个服务有问题影响其他服务比如一个单体架构，能够承受 1000次访问/秒。 但是访问量达到 2000次/秒的时候，就会非常卡顿，严重影响业务，并且仅仅依靠单体架构本身，很难突破这个瓶颈。解决办法通常就是采用分布式和集群来做分布式简介：一个功能做成一...

文章目录架构到底是指什么？梳理几个有关系而又相似的概念系统与子系统模块与组件框架与架构重新定义架构架构到底是指什么？架构和框架是什么关系？有什么区别？Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？梳理几个有关系而又相似的概念系统与子系统系统泛指由一群有关联的个体组成，根据某种规则

文章目录架构设计的历史背景第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）第二次软件危机与面向对象（20 世纪 80 年代）软件架构的历史背景架构设计的历史背景第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）第一次软件危机的根源在于软件的“逻辑”变得非常复杂原因高级语言的出现，解放了程序员。随着软件的规模和复杂度的大大增加，20 世纪 60 年代中期开始爆发了第一次软件危机，典型表现有软件质量低下、项目无法如期完成、项目严重超支

架构目的架构设计的目的架构设计的误区架构设计的真正目的案例：复杂度分析架构设计的目的架构设计的误区因为架构很重要，所以要做架构设计不做架构设计系统就跑不起来么？做了架构设计就能提升开发效率么？设计良好的架构能促进业务发展么？不是每个系统都要做架构设计吗公司流程要求系统开发过程中必须有架构设计为了高性能、高可用、可扩展，所以要做架构设计架构设计的真正目的架构设计的主要目的是为了解决软件系统复杂度带来的问题。架构要有的放矢，而不是贪大求全。通过熟悉和理解需求

可扩展性复杂度来源：可扩展性方案预测变化应对变化的方案方案1方案1的问题方案2在实际工作场景中的解决方案复杂度来源：可扩展性可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。方案设计具备良好可扩展性的系统，有两个基本条件：正确预测变化完美封装变化。预测变化软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的需求需要实现。如果来一个需求就要求系统大改一次，成本会非常高，程序员心里也不爽（改

架构复杂度-高性能复杂度来源：高性能单机复杂度集群的复杂度1.任务分配2.任务分解任务分解能够提升性能的原因：但系统不是划分得越细越好复杂度来源：高性能软件系统中高性能带来的复杂度主要体现在两方面：单台计算机内部为了高性能带来的复杂度；多台计算机集群为了高性能带来的复杂度。单机复杂度而将硬件性能充分发挥出来的关键就是操作系统，操作系统的复杂度直接决定了软件系统的复杂度。操作系统和性能最相关的就是进程和线程。批处理操作系统为了解决手工操作带来的低效，批处理操作系统应运而生。批处理简

高可用复杂度来源：高可用方案应用场景1.计算高可用2.存储高可用传输问题3.高可用状态决策常见的决策方式1. 独裁式2. 协商式3. 民主式复杂度来源：高可用维基百科高可用的定义系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。关键在于“无中断”无论单个硬件还是单个软件，都不可能做到无中断，硬件会出故障，软件会有 bug；硬件会逐渐老化，软件会越来越复杂和庞大……外部环境导致的不可用更加不可避免、不受控制。例如，断电、水灾、地震方案系统的高可用方案五花八门

文章目录复杂度来源：低成本、安全、规模低成本安全规模复杂度来源：低成本、安全、规模低成本如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点需要减少服务器的数量才能达成低成本的目标。因此低成本本质上是与高性能和高可用冲突的往往只有“创新”才能达到低成本目标NoSQL（Memcache、Redis 等）的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。全文搜索引擎（Sphinx、Elasticsearch、Solr）的出现是为了解决关系型数据库 li

文章目录分布式架构遇到的4个问题客户端如何访问这些服务每个服务之间如何通信同步调用异步消息调用如此多的服务，如何实现？基于客户端的服务注册与发现基于服务端的服务注册与发现服务挂了，如何解决？（备份方案，应急处理机制）分布式架构遇到的4个问题客户端如何访问这些服务解决方案：在后台 N 个服务和 UI 之间加一个代理或者叫 API Gateway为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过 API Gateway 也有可能成为 单点故障 点或者性