2022分布式系统架构关于分布式系统架构对于软件架构，更多的是一种思想，即内功修为。在道与术层面则更偏重道的修炼，道的深度确定架构的境界。相对而言，术是手段随不同的环境应运而生，就像太极剑法和独孤九剑，能做到随境而变。架构是一种权衡没有一种架构可以应用到全部环境，也没有一个技术或框架可以解决全部问题，即使是针对同一种场景也往往存在多种解决方案。在架构的时候，更多的是方案和手段的权衡，例如高可用性、高并发性第1页共10页一样性本身就存在肯定的冲突;而异步还是同步、是否须要事务、如何应用事务、缓存、拆分、容灾、发布等等，每一项都须要从各种技术实现中进行权衡。细化到框架，ActiveMQ、RocketMQ、Kafka、Redis、ZooKeeper等等都可以实现消息队列模型，详细运用哪个就须要结合场景进行权衡了。分与合天下大事，合久必分、分久必合，在解决高并发分布式的问题时绝大部分都在运用分与合的思想。当数据量很大、并发量许多的时候就须要考虑拆分(分而治之)，第2页共10页例如分层设计、横向拆分、纵向拆分、分IDC、分库分表...等等。并且这些拆分本身就是分层的，例如在DNS层可以将流量根据地域或运营商安排到不同的IDC、业务层可以将业务处理逻辑安排到多个子系统、系统层可以依据用户进行横向拆分、而存储层可以依据规则将数据安排到不同的库不同的表;另外读写分别、热点分别、独立出缓存层也体现了分布式系统架构中分的思想。为什么要做这么多的拆分，拆分就是为了化多为少，在单节点处理实力有限的状况下，通过横向拆分供应无线的扩展实力，当巨大的流量通过拆分后，每个节点要处理的QPS就会下降;拆分是为了化繁第3页共10页为简，简化单节点的困难度，现在的微服务(当然微服务引发的服务治理须要另说)、二阶段事务提交，就是将困难的业务通过多维度的拆分降解单节点困难度的手段。拆多了就要合，hadoop将困难的任务分解到一个个的mapreducejob处理和聚合后，处理效率得到了极大的提升，而这种分解必定伴随着聚合。而在有些业务场景，两类节点相互调用特别频繁，通过合并将原本的RPC调用转换为本地JVM调用，则可以很大的提升系统性能。隔离第4页共10页隔离也是一种思想，其中也包含了分的意思，例如灰度、压测隔离、动静隔离、多版本发布等。转换路由与转换，可以看做是分思想的衍生物。分的太多，就须要能将恳求转发到正确的位置，此外也须要将各种通信格式与协议进行转换。重复与唯一(幂等)幂等伴随着恳求的靠套投递而产生，在发送恳求时可能会存在如下几个场景：接收端不肯定要接收、接收端只能接收一次、接收端可第5页共10页重复接收。对于配置推送平台，大多场景要求接收端可重复接收配置信息，但只保存最终一次消息即可;而对于一笔付款恳求，假如重复发送，接收端要限制只能处理一次(即要进行幂等限制)。最终一样在分布式系统架构中，面对事务性业务有两种选择，一种是分布式事务、一种是最终一样性处理。分布式事务限制比较困难，一般采纳二阶段提交的方式，其思想是要么胜利要么失败，留意要么失败是指其中有一步出错就全部回滚，看似是保证了数据一样性但实际业务却失败了。而最终一样性相对于分布式事务的核心思想是让业务尽可第6页共10页能胜利，即当业务处理过程中可能会存在中间步骤失败的状况，但通过补偿逻辑可以保障失败的步骤后续接着执行，此时就应当尽可能的标记业务胜利。并行与串行将大量的计算分散到多个节点、多个进程、多个线程进行并行处理，是应对大数据计算的常用技巧。而伴随并行的就是串行(或者说是并发锁)的处理，在分布式环境，并发锁的可以通过数据库、zookeeper等进行实现。主动与被动第7页共10页主动与被动主要是针对客户端如何获得服务端内容的场景，典型的.就是消息队列中的推模式(push)和拉模式(pull)。详细底层实现上，无外乎轮询、长链接等等，其中运用轮询不肯定就是拉模型，许多推模型其底层也是通过轮询实现的。同步与异步同步与异步也是常常要面临选择的事情，异步可以削减系统的堵塞，例如Ajax、消息队列(还可以达到消峰填谷的作用)等等。此外流式计算与离线计算，也可以看做是同步与异步的衍生技术。再深...
