千里之行始于足下，开始新的学习吧！
一、什么是分布式系统，分布式系统解决了什么问题？
分布式系统： 分布式系统是由多个独立计算机或服务节点协同工作的系统。这些节点通过网络通信进行协调和合作，以完成共同的任务或提供服务。
1，分布式系统解决了什么问题
-
**解决了单机性能瓶颈导致的成本问题。**由于摩尔定律失效，廉价 PC 机的性能瓶颈无法继续突破，虽然小型机和大型机能实现更高的单机性能，但是成本太高，一般的公司很难承受。
-
解决了用户量和数据量爆炸性增长导致的成本问题。
-
硬件成本：随着用户量和数据量的增加，可能需要更高配置的服务器或更多的服务器来支持系统的处理需求。这将导致更高的硬件投资和维护成本。
-
网络带宽成本：用户量的增长将导致服务器与用户之间的数据传输量增加，这可能需要增加网络带宽以保持良好的用户体验。增加网络带宽通常会导致更高的网络服务费用。
-
存储成本：随着数据量的增加，需要更多的存储空间来存储用户数据。这将导致存储设备的成本增加，包括硬盘、SSD等存储介质以及相关的存储管理和备份工作所需的投入成本。
-
数据处理成本：随着数据量的增加，可能需要更强大的计算资源来处理和分析数据。这可能需要升级现有的服务器硬件或增加额外的计算资源，以满足数据处理的需求。这将增加计算设备的投资和运维成本。
-
运维成本：随着用户量和数据量的增加，可能需要增加运维人员的数量和工作量，以管理和维护单机系统。这包括系统监控、故障排除、性能优化等方面的工作，将带来额外的运营成本。
-
解决了互联网产品对于停机服务等故障无法容忍的问题。单机系统在面对停机和服务故障问题时，由于只有一个单独的服务器，通常无法提供高可用性和容错性。以下是单机系统面临的停机和服务故障问题：
-
单点故障：在单机系统中，如果服务器发生故障或停机，整个系统将无法提供服务。这种单点故障会导致系统完全不可用，使用户无法访问应用或网站。
-
维护和升级时间：单机系统需要进行维护和升级，但在这些过程中，系统必须停机。停机时间会影响用户体验并对业务运营造成影响。
-
容错性欠缺：单机系统无法提供容错性，即使出现故障或错误，也无法自动恢复或切换到备用系统。这增加了系统无法提供连续服务的风险。
-
-
分布式系统解决了大规模软件系统的迭代效率和成本的问题：如果一个大规模的软件系统是一个单体系统，那么大量的开发人员就只能将一个大规模软件，整体进行编译、测试和发布，这样一来开发语言和生态都比较单一，系统的迭代效率就会非常低。同时，对于系统的各个部分，我们也不能有针对性地进行成本优化，这会产生非常大的成本问题。
总结：我们可以总结出在互联网时代，单机系统是无法解决成本、效率和高可用问题的，但是这三个问题，对所有的公司来说都是非常关键的问题，所以分布式系统就这样应运而生了，你也会发现，从单机系统到分布式系统的发展，是无法阻挡的技术大潮流。
2，分布式系统怎么解决这些问题？
其实解决方法很容易想到，就是将一些廉价的PC 机，通过网络连接起来共同完成工作，并且在系统中提供冗余，来解决高可用的问题。
其实我们从分布式系统的定义中，也能找到这个方法，分布式系统指的是由一组通过网络进行通信，为了完成共同的任务，而协调工作的计算机节点组成的系统。在这个定义中，可以看出分布式系统是通过多工作节点，来解决单机系统面临的成本、效率和高可用问题的。
3，这些解决方式引入的新的挑战是什么？
了解了分布式系统的前因，知道了分布式系统是通过多个工作节点，来解决单机系统面临的成本，效率高可用问题。但是事情向来都是利弊兼备的， 它的出现也引入了分布式系统内部工作节点的协调问题， 主要提现在分布式系统内部组件、实例之间，通过异步网络进行通信和协调的问题。
那么针对内部工作节点的协调问题，分布式系统是怎么做的？
首先我们要知道分布式系统，分为有状态，和无状态两种。
下面讲一下什么是有状态，什么是无状态：
有状态分布式系统是指在系统的执行过程中需要维护和管理状态信息的分布式系统。状态信息是指在系统中记录的应用程序的运行状态、用户会话信息、数据缓存等需要被多个节点共享和同步的信息。有状态分布式系统在处理请求时需要考虑状态的更新、同步和恢复等问题。
无状态分布式系统是指在系统的执行过程中不需要维护和管理状态信息的分布式系统。每个请求在处理时都是相互独立的，系统不需要关心之前的请求处理状态。无状态分布式系统对于每个请求的处理是无状态的，节点之间的通信更加简单和灵活。
有状态分布式系统和无状态分布式系统的主要区别在于对状态信息的处理。有状态系统需要维护、同步和管理状态信息，需要考虑状态一致性、更新和恢复等问题；而无状态系统不需要维护状态信息，每个请求都是独立的。有状态分布式系统相对复杂一些，但可以支持更丰富的应用场景，例如需要维护用户会话、数据缓存等场景；而无状态分布式系统相对简单，更适用于处理独立的请求，例如静态资源的分发、负载均衡等场景。
我们先从简单的无状态说起。对于无状态服务，我们需要从以下几个问题开始思考：
-
一， 怎么找到服务？ 在分布式系统内部，会有不同的服务（角色），服务 A 怎么找到服务 B 是需要解决的问题。一般来说，服务注册与发现机制是常用的思路，所以，我们可以了解一下服务注册发现机制的实现原理，并且思考一下服务注册发现，是选择做成 AP 系统还是 CP 系统更合理。
-
二，怎么找到实例？在找到服务之后，当前的请求应该发往服务的哪一个实例呢？一般来说，如果同一个服务的实例是完全对等的（无状态），那么按负载均衡的策略来处理就足够（轮询、权重、Hash、一致性Hash，FAIR 等各种策略的适用场景）。
-
三，怎么管理配置？在分布式系统内部，会有不同的服务（角色），每一个服务都有多个实例，并且还可能自动扩容和缩容。在这样的情况下，通过配置文件的方式，来管理配置是低效、易出错的，对于这个问题，一般的思路是通过一个中心化的存储来统一管理系统的配置，即配置中心。
-
四，怎么进行协同？在单体系统中，所有的功能模块都在一个进程中，系统内部进行协同非常简单， 直接调用系统的API 加锁就可以了。但是在分布式系统中，由于不同的功能模块已经拆分为不同的服务，并且一般都运行在不同的机器上，这个时候系统中加锁相关 API 就不能使用了。对于这个问题，我们可以通过一个跨进程与机器的分布式锁来解决。
-
五，怎么保证幂等？ 就是怎么保证请求只执行一次。在分布式系统中，各个模块之间通过网络进行连接。如果出现了网络抖动等情况，会导致模块之间的调用失败，而调用失败就有可能触发重试策略，使得程序可能出现没有执行或者多次执行的情况。一般来说，重试加上幂等是分布式系统中，确保请求只执行一次的方法。
-
六，怎么避免雪崩？什么是雪崩：系统雪崩是指由于正反馈循序导致不断扩大规则的故障。一次雪崩通常是由于整个系统中，一个很小的部分出现故障而引发，进而导致系统的其他部分也出现故障。比如，系统中某一个服务的一个实例出现故障，导致负载均衡将该实例摘除，从而引起其他实例负载升高，最终导致该服务的所有实例像多米诺骨牌一样，一个一个全部出现故障。
避免雪崩的策略比较简单，主要是两个思路，一个是快速失败和降级机制（熔断、降级、限流等），通过快速减少系统负载来避免雪崩的发生；另一个是弹性扩容机制，通过快速增加系统的服务能力来避免雪崩的发生。我们可以根据不同的场景做出不同的选择，或者两个策略都使用。
一般来说，快速失败会导致部分的请求失败，如果分布式系统内部，对一致性要求很高的话，快速失败会带来系统数据不一致的问题。这种情况下，弹性扩容会是一个比较好的选择，但是弹性扩容的实现成本比快速失败要大，响应时间也更长。 -
**七，怎么监控告警和故障恢复？**对于一个分布式系统来说，如果我们不能清楚地了解内部的状态，那么系统的稳定性是没有办法完全保障的。所以我们一定要完善分布式系统的监控（比如接口的时延和可用性等信息），分布式追踪 Trace ，模拟故障的混沌工程以及相关的告警等机制。同时做好故障恢复预案，确保在故障发生的时候，能够快速恢复故障。
以上就是分布式计算的协调方式， 分布式存储也是一样的。
对于有状态系统，需要考虑的内容可以类比无状态系统，但需额外关注以下问题
-
数据一致性：在有状态系统中，需要考虑如何保证多个节点之间的数据一致性，包括使用一致性协议或分布式事务等方式。为了保证多个节点上的数据一致性，可以采用一致性协议（如Paxos、Raft）或者分布式事务来实现。这些协议和机制可以确保在分布式系统中的数据操作具有原子性、一致性、隔离性和持久性（ACID特性）。
-
状态管理：有状态系统需要维护和管理状态信息，需要考虑状态的更新、同步和恢复等问题。状态系统需要维护和管理状态信息。可以采用状态复制或分片存储等技术来确保状态的可靠存储和访问。状态更新和同步可以使用主从复制、副本协议等机制来实现。
-
高可用性：有状态系统的节点故障可能导致状态数据丢失或操作失败，因此需要考虑故障恢复和故障转移的机制，以保证系统的高可用性。为了确保有状态系统的高可用性，可以使用主从复制和故障转移机制。在主节点发生故障时，可以自动切换到备用节点来保证系统的可用性。此外，使用冗余和备份技术可以帮助恢复状态数据
-
数据安全性：有状态系统的数据安全性是一个重要问题，需要使用合适的加密和身份验证方式来保护数据的机密性和完整性。
为了确保有状态系统的数据安全性，可以采取数据加密、身份认证和访问控制等安全手段。合理的安全策略和机制可以确保数据的保密性、完整性和可用性。
