拿来吧 你 的博客

读写分离 CQRS读写分离是数据库扩展最简单实用的玩法了，这种方法针对读多写少的业务场景还是很管用的，而且还可以有效地把业务做相应的隔离。如下图所示，数据库只有一个写库，有两个读库，所有的服务都写一个数据库。对于读操作来说，服务 A 和服务 B 走从库 A，服务 D 和服务 E 走从库 B，服务 C 在从库 A 和从库 B 间做轮询。这样的方法好处是：比较容易实现。数据库的 master-slave 的配置和服务框架里的读写分离都比较成熟，应用起来也很快。 可以很好地把各个业务隔离开来

异步处理在分布式架构中，我们的系统被拆成了很多的子系统。如果想把这堆系统合理地用好，并更快地处理大量的任务，我们就需要统一地规划和统筹整体，这样可以达到整体的最优。本质上，这和邮递公司处理邮件一样，是相同的道理。在计算机的世界里，到处都是异步处理。比如：当程序读写文件时，我们的操作系统并不会真正同步地去操作硬盘，而是把硬盘读写请求先在内存中 hold 上一小会儿（几十毫秒），然后，对这些读写请求做 merge 和 sort。这就是异步系统所带来的好处——让我们的系统可以统一调度。异步处理的设

基本上来说，在分布式系统中最耗性能的地方就是最后端的数据库了。一般来说，只要小心维护好，数据库四种操作（select、update、insert 和 delete）中的三个写操作 insert、update 和 delete 不太会出现性能问题（insert 一般不会有性能问题，update 和 delete 一般会有主键，所以也不会太慢）。除非索引建得太多，而数据库里的数据又太多，这三个操作才会变慢。绝大多数情况下，select 是出现性能问题最大的地方。一方面，select 会有很多像 join、g

服务网格是 CNCF（Cloud Native Computing Foundation，云原生计算基金会）目前主力推动的新一代的微服务架构——Service Mesh 服务网格。Service Mesh 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施，并让整个架构更为的先进和 Cloud Native。在工程中，Service Mesh 基本来说是一组轻量级的服务代理和应用逻辑的服务在一起，并且对于应用服务是透明的。说白了，就是下面几个特点。Ser

所谓的边车模式，对应于我们生活中熟知的边三轮摩托车。也就是说，我们可以通过给一个摩托车加上一个边车的方式来扩展现有的服务和功能。这样可以很容易地做到 " 控制 " 和 " 逻辑 " 的分离。也就是说，我们不需要在服务中实现控制面上的东西，如监视、日志记录、限流、熔断、服务注册、协议适配转换等这些属于控制面上的东西，而只需要专注地做好和业务逻辑相关的代码，然后，由 " 边车 " 来实现这些与业务逻辑没有关系的控制功能。边车模式设计具体来说，你可以理解为，边车就有点像一个服务的 Agent，这个服务

所谓的降级设计（Degradation），本质是为了解决资源不足和访问量过大的问题。当资源和访问量出现矛盾的时候，在有限的资源内为了能够扛住大量的请求，我们就需要对我们的系统进行降级操作。也就是，暂时牺牲掉一些东西，保障整个系统的平稳运行。一般来说，我们的降级需要牺牲掉的东西有：降低一致性。从强一致性变成最终一致性。 停止次要功能。停止访问不重要的功能，从而释放出更多的资源。 简化功能。把一些功能简化掉，比如，简化业务流程，或是不再返回全量数据，只返回部分数据。降低一致性我们要清楚地认识到

保护系统不会在过载的情况下导致问题，那么，我们就需要限流。限流的策略限流的目的是通过对并发访问进行限速，相关的策略一般是，一旦达到限制的速率，那么就会触发相应的限流行为。一般来说，触发的限流行为如下。 拒绝服务。把多出来的请求拒绝掉。一般来说，好的限流系统在受到流量暴增时，会统计当前哪个客户端来的请求最多，直接拒掉这个客户端，这种行为可以把一些不正常的或者是带有恶意的高并发访问抵挡掉。 服务降级。关闭或是把后端服务做降级处理。这样可以让服务有足够的资源来处理更多的请求。降级有很多方式

什么是分布式事务随着互联网的快速发展，软件系统由原来的单体应用转变为分布式应用。​ 分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务分布式事务解决方案两阶段提交（2PC）熟悉mysql的同学对两阶段提交应该颇为熟悉，mysql的事务就是通过日志系统来完成两阶段提交的。两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，由一.

熔断机制借鉴于我们电闸上的 " 保险丝 "，当电压有问题时（比如短路），自动跳闸，此时电路就会断开，我们的电器就会受到保护。不然，会导致电器被烧坏，如果人没在家或是人在熟睡中，还会导致火灾。所以，在电路世界通常都会有这样的自我保护装置。同样，在我们的分布式系统设计中，也应该有这样的方式。前面说过重试机制，如果错误太多，或是在短时间内得不到修复，那么我们重试也没有意义了，此时应该开启我们的熔断操作，尤其是后端太忙的时候，使用熔断设计可以保护后端不会过载。熔断设计熔断器模式可以防止应用程序不断地尝试

关于重试，这个模式应该是一个很普遍的设计模式了。当我们把单体应用服务化，尤其是微服务化掉，本来在一个进程内的函数调用就成了远程调用，这样就会涉及到网络上的问题。重试的场景所以，我们需要一个重试的机制。但是，我们需要明白的是，" 重试 " 的语义是我们认为这个故障是暂时的，而不是永久的，所以，我们会去重试。所以，设计重试这个事时，我们需要定义出什么情况下需要重试，例如，调用超时、被调用端返回了某种可以重试的错误（如繁忙中、流控中、维护中、资源不足等）。而对于一些别的错误，则最好不要重试，比如：

分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。所以对于分布式系统，我们就不得不说下补偿。ACID 和 BASE谈到这里，有必要先说一下 ACID 和 BASE 的差别。传统关系型数据库系统的事务都有 ACID 属性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、

所谓幂等性设计，就是说，一次和多次请求某一个资源应该具有同样的副作用。为什么我们需要这样的操作？说白了，就是在我们把系统解耦隔离后，服务间的调用可能会有三个状态，一个是成功（Success），一个是失败（Failed），一个是超时（Timeout）。前两者都是明确的状态，而超时则是完全不知道是什么状态。比如，超时原因是网络传输丢包的问题，可能是请求时就没有请求到，也有可能是请求到了，返回结果时没有返回到等情况。于是我们完不知道下游系统是否收到了请求，而收到了请求是否处理了，成功 / 失败的状态在返回

前面所说的隔离设计通常都需要对系统做解耦设计，而把一个单体系统解耦，不单单是把业务功能拆分出来，正如上面所说，拆分完后还会面对很多的问题。其中一个重要的问题就是这些系统间的通讯。通讯一般来说分同步和异步两种。同步通讯就像打电话，需要实时响应，而异步通讯就像发邮件，不需要马上回复。各有千秋，我们很难说谁比谁好。但是在面对超高吐吞量的场景下，异步处理就比同步处理有比较大的优势了，这就好像一个人不可能同时接打很多电话，但是他可以同时接收很多的电子邮件一样。同步调用虽然让系统间只耦合于接口，而且实时性也会比

容错设计又叫弹力设计，其中着眼于分布式系统的各种“容忍”能力，包括容错能力（服务隔离、异步调用、请求幂等性）、可伸缩性（有 / 无状态的服务）、一致性（补偿事务、重试）、应对大流量的能力（熔断、降级）。可以看到，在确保系统正确性的前提下，系统的可用性是弹力设计保障的重点。故障隔离隔离设计对应的单词是 Bulkheads，中文翻译为隔板。但其实，这个术语是用在造船上的，也就是船舱里防漏水的隔板。一般的船无论大小都会有这个东西，大一点的船都会把船舱隔成若干个空间。这样，如果船舱漏水，只会进到一个小空间里

首先，我们需要一个全栈系统监控的东西。它就像是我们的眼睛，没有它，我们就不知道系统到底发生了什么，我们将无法管理或是运维整个分布式系统。所以，这个系统是非常非常关键的。这个监控系统需要完成的功能为：全栈监控； 关联分析； 跨系统调用的串联； 实时报警和自动处置； 系统性能分析。多层体系的监控所谓全栈监控，其实就是三层监控。 基础层：监控主机和底层资源。比如：CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等。 中间层：就是中间件层的监控。比如：Nginx、Redis、Ac

最近在极客时间看到一个课程叫《左耳听风》，第一反应是叫这个名字，太不突出重点了，能好卖吗。但当了解作者后，发现是我错了。作者好牛比啊。所以要感受下骨灰级程序员的魅力。先从分布式系统入手学习吧。分布式系统架构的冰与火首先，阐述一下为什么需要分布式系统，而不是传统的单体架构。这个其实对于大部分人来说已经不是问题了。但还是阐述下吧，使用分布式系统主要有两方面原因。 增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。

今天看到一盘文章是写reids分布式锁的，感觉写的还可以。同时也发现了自己在之前使用redis锁的时候的一些问题，所以总结下redis作为分布式锁使用的注意事项。一、原子性 因为在设置redis key的时候，同时要设置过期时间。我们要保证 设置 key成功的时候，设置过期时间也要成功， 不然就可能出现死锁的可能。这里我们可以使用 lua 脚本，把这俩个命令封装在一起，一起发送到服务端，保证原子性。二、锁互斥机制 客户端1加了锁，在客户端2过来加锁的时候，要保证客户端...

今天重学下cap理论，加强下理解。一、分布式系统的三个指标1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。Consistency Availability Partition tolerance它们的第一个字母分别是 C、A、P。Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。二、Partition tolerance中文名叫 分区容错，意思是 区间通信可能失败。比如，一台服务器放在中国，另.