分布式计算是通过计算机网络将计算工作分布到多台主机上，多个主机一起协同完成工作。

  网络通讯，网络是分布式的基础，对分布式的理解建立在对网络的理解上，包括：

  RPC，Socket使用不是很方便，很多分布式应用是基于RPC的，包括：

  负载均衡，如何将大量工作负载分配到多个主机上，最大化吞吐量，最小化平均响应时间，最大化资源利用率。

  分片（Sharding），把数据分成多个数据集，由多个服务器来分别处理。

  分布式一致性，在分布式环境中如何维持状态的一致性，严格一致性，还是最终一致性

  题主问的是 Java，不过这样的一个问题其实不局限于 Java，因此我试着以“分布式”本身来回答。

  分布式——一个高大上的名词，是计算机软件设计中人民群众喜闻乐见的“逼格满满”、“不明觉厉”的几个名词之一。但很可惜，这玩意儿一点也不复杂，甚至有些“简单”。不信？你只要遵循下述步骤即可将任何一个软件拆分为“分布式”的：

  蹬蹬蹬蹬～大功告成。哈哈别打我，这真的是很严肃的通用型三步骤大杀器，对付任何软件，是任何软件都可以的。接下来我当然要解释清楚为什么。

  人们常常把分布式系统自然而然的和并行计算联系起来。然而这并不正确。实际上，分布式系统并不一定是并行的，举个简单的例子就能理解——

  很简单吧？这三个步骤是无法并行的。它们需要被依次执行。但是这个软件依然可以被改为分布式的，方法就是用前面提到的方法，把步骤 2 的计算过程独立为一个 Process 移动到另外一台计算机上完成。

  如果我们从总系统流程的观点来看，并没什么并行。整一个完整的过程都是顺序执行的。只不过执行时出现了“跨设备”的现象而已。可见，分布式本身就只如其字面意思所指，指的仅仅是从结构角度的分散而已。

  当然啊，现实世界中，我们更多的时候钟情于分布式，还是因为它与并行之间可以相互配合。例如实现既是分布同时也是并行的系统。

  好了，理解这一点之后就不难解释为什么我会说前文提到的三步骤是万用了。接下来我们继续讨论分布式本身。

  所谓分布式，无非就是”将一个系统拆分成多个子系统并散布到不同设备“的过程而已。

  如何拆分——可以有很多方式，核心依据一是业务需求，二是成本限制。这是实践中构建分布式系统时最主要的设计依据。

  如何连接——光把系统拆开成 Process 还不够，关键是拆开后的 Process 之间还要能通信，因此涉及通信协议设计的问题，需要仔细考虑的因素很多，好消息是这部分其实成熟方案很多

  分布式系统并非灵丹妙药，处理问题的关键还是看你对问题本身的了解。通常我们应该使用分布式的常见理由是：

  笼统的讨论分布式没有过大的意义，就如我刚才所谈的，实际上分布式很容易实现。真正难的地方在于如何明智的选择正确的分布方案。

  例如，当你想要建立一个分布式的数据管理系统的时候，你就必须得面对“一致性”问题。如果你对数据一致性要求很高，你就不得不容忍一些缺陷例如规模伸缩困难；而如果你放弃它，你可以轻松伸缩规模，但你一定要解决好由此带来的一系列数据不一致导致的问题。（CAP 问题）

  于是你会意识到，有许多种分布方案，为了正确解决你的问题，你需要对每一个方案都来了解，并评估，选不一样的方案有时候区别不大，有时候却会深刻的影响总系统中别的部分的工作方式，甚至影响用户界面中用户操作时的流程。这是我们学习分布式系统的重点所在。

  通信协议。Process 间需要相互配合才能完成工作，因此通信协议是最基本要解决的问题。这部分其实挺复杂，牵涉面光，不过核心还是抓住两方面，一是存在哪些需求，二是各个协议如何满足这些需求

  命名法。两个 Process 要通信，必须相互知道对方的名字，名字可以是数字，也可以是结构化的字符串。例如众所周知域名系统就是一种命名方案，但是方案还有很多，各有特点

  协作。上面都在谈 Process 之间的通信，可是为何需要通信？因为要协作。协作是个复杂的主题，其中最基本最基本的一个问题是同步问题。而聊同步问题必然要聊“锁”……知识点就这么展开了

  上面几点是最基础的知识。了解了这些其实就算入门了。可是如何进阶呢？那么必然要开始有效学习下面的问题：

  好了，如果这些你都学的差不多了，那咱们“纸上谈兵”也就告一段落了。接下来进入实战演练。

  你有没有开发过简单的增删改查软件？这类软件通常都需要搭配一个独立的数据库管理系统共同完成功能。实际上，只要你开发过这么简单的软件，那么你就已经开发过分布式系统了。

  真的，我没开玩笑。还记得我们前面提到的吗，什么是分布式？不就是一个大系统拆分成多个小系统分散到不同的设备上吗。回想一下，当你写一个简单的增删改查软件时，只要用到数据库管理系统，是不是具有如下特点：

  关于「集群」的问题我们之后会谈到，它也是分布式系统的一个应用，但谈集群的时候，我们谈的往往是更具体的东西。但咱们看问题，需要抓住本质。别看麻雀小，五脏却俱全。

  不过，你已经熟悉的东西，我们在这里就不再展开了，我们不妨关注其他一些更有趣的话题。

  2.确认选用什么样的框架，推荐Tuscany。一个孤独的被抛弃了的Apache开源项目。

  B。一个Service请只对应一个DB，任何对这个DB有读写的需求，仅限于使用这个Service。不要直接通过DB取。

  C。尽可能的保持调用结构相对比较简单。如果有可能，只允许 WEB层调用Service。

  在回答这样的一个问题之前，首先我们要明白，为何会出现分布式架构技术？要了解这样的一个问题的话我们应该往前回溯，从主流互联网系统发展的历程来看，我们大家可以看到在不同阶段，流行的系统架构其实是不一样的。比如一开始的单体应用把所有东西都部署在一起就可以满足业务需求，然后随着业务规模的发展，用户量和访问量逐步增加，这时系统会不断面临性能压力和存储压力，具体体现就是：

  这个时候就需要考虑提升系统的性能和容量了。最传统的方式就是增加硬件配置，比如处理速度跟不上，那么就「增加CPU配置，8c不够就加到16c、32c」；然后数据存不下就「增加硬盘容量，500G不够就增加到1T、2T」；再比如服务器抗不住了，就换小型机，再不行换商用大型机；还有一些有更多预算的特殊项目，还可以用上“超算”（超级计算机）。这种扩展模式我们称之为“纵向扩展”，而这种模式恰恰是以前很多传统大型企业所采用的方式，比如银行、保险、证券行业的IT系统；还有一些大型的系统。这种方式虽然简单，但是越往上设备越昂贵，在当前提倡开源节流的大背景下，显现是不可持续的，架构转型势在必行。

  那么“纵向扩展”行不通，就采用“横向扩展”呗。一台服务器干不了的事情就用两台，两台不行就继续加。这种方式的优点很显然，三个臭皮匠顶一个诸葛亮，以前租赁一台小型机的费用都可以租很多台普通服务器了。但这个模式也不是单纯的横向扩展这么简单，这种方式需要考虑很多问题，比如多个节点数据怎么同步？一个交易怎么保证完整一致？节点之间网络出现分区怎么办？这一系列问题随着而来！所以为了提升系统的弹性伸缩能力，缩减硬件成本，采用横向扩展的模式给系统架构设计带来了一些复杂性，但是这些问题，相比起大幅下降的费用成本来说，在老板面前不值得一提。于是各路老板，纷纷拍板，分布式搞起来，复杂的分布式技术问题你们架构师来搞定！好吧受伤的总是憨厚老实的IT（挨踢）工程师 _！！

  那么既然要解决一个问题，我们就先分析这个问题，我们前面说“横向扩展”，从一个节点横向扩展为多个节点：

  这些都是分布式架构要研究和解决的问题，而不可避免地，这些也都是每个Java工程师需要去面临的问题和挑战，尤其在当前很多企业大力推行数字化转型的背景下，分布式微服务的系统架构可以说是目前行业主流甚至标准，所以说，学习好分布式架构相关的技术，是当下每位Java工程师必须踏出去的一步。

  而最直观的，我们也可以看看目前招聘市场上主流企业针对 Java工程师的招聘需求，首先从数量上看，企业对 Java 工程师发放的面邀数量远高于其他岗位，说明目前市场对Java工程师的需求量还是巨大的。另外从技能要求上，我们能够正常的看到不管是针对工作2年左右的中级工程师，还是3-5年的高级工程师，或者是5年以上的资深工程师或架构师，这些岗位描述里面都不约而同地提到了：有分布式系统架构设计能力、有大型分布式系统经验的要求。（以下是我从一个知名的招聘网站上简单的找的几个岗位描述供参考）

  从上面的分析来看，不论是从公司发展的需要、还是从个人能力提升考虑，分布式架构技术对于每位Java工程师来说，能够说是一项必备技能了！每一位想要在职业发展之路上更进一步的Java从业者，都需要牢牢掌握分布式架构思想，牢牢掌握分布式实战技能，最后用三个字总结一下：

  在讲解深入学习Java分布式并发编程的方法之前，先分析如下若干错误的观点和学习方法。

  这话其实是说明了表面现象，多线程其实还真是并发编程的实现方式，但在实际高并发的项目里，程序员正常情况下不会通过多线程去实现并发的需求，而是利用一些后文会提到的高并发组件来实现高并发的需求。

  甚至能这样说，线程方面的技能对实现高并发需求的帮助很少，与其用很多精力去学多线程并发，还不如花精力去学组件乃至应对高并发的集群。

  严格来说，这句话不能算错，但学习并发编程算法和底层原理时，要讲究学习的时机。

  一般来说，学并发编程的过程是，会用组件以及API，能（通过日志）解决并排查有关问题，能搭建解决高并发的架构。在刚开始学并发编程乃至用并发编程技术干活时，其实没必要用大量的精力去了解算法和底层原理，只有当进阶成架构师乃至资深架构师时，才有必要学原理和底层源码，而且还不是全学，而是针对要解决的问题，针对性地看算法和源码。

  错误观点3：单凭看书和看视频等资料，能学好Java分布式高并发组件，以及并发编程。

  通过看书看资料，确实能了解并发编程的一些技术和方法，但如果不实践，甚至连并发编程相关的API都用不好，更别论解决并发问题和搭建能应对高并发的框架。

  而且，由于在个人电脑上不能模拟高并发场景，所以通过学习，只能掌握个皮毛，能学到能应对高并发面试的程度，如果学习方法不当，甚至连通过面试的程度都达不到。要学好并发编程，只能是先通过面试得到相关的实践机会，在项目中学。

  学习Java并发编程的目的是，掌握应对类似双十一等场景的高并发技术，并能以此进入好公司，拿到更高的工资。从应用角度来看，Java并发编程包含了如下方面的技术。

  1 在应对高并发需求的项目中，一般会把业务模块部署在多个服务器上，以此形成集群，用nginx等组件进行负载均衡，同时限流。

  2 为了减缓因高并发请求对数据库产生的压力，一般会在系统里引入Redis缓存，甚至是Redis集群，或者用数据库主从集群来进行读写分离，或者引入MyCAT组件来进行分库分表，把一张大表拆分成若干子表，降低每次请求数据的数据样本。

  3 系统里不同的模块处理请求的速度是不同的，比如订单模块一秒能处理5000个请求，而风控模块一秒才能出3000个，对此可以引入消息中间件，或者可以用消息中间件来异步处理业务。

  4 为了应对高并发，系统里的模块正常情况下不会用RestFul的方式相互调用，而会直接用RPC的方式，所以在学习Java并发技术的过程中，程序员还要掌握Dubbo以及对应的Zookeeper注册中心技术。

  在实际项目开发过程中，实现高并发的方式是通过组件，进而用组件搭建集群，而不是程序员在理解限流熔断负载均衡等算法和原理的基础自己实现限流负载均衡和熔断等模块。

  看到这里你们可以自己想一下，哪怕你根据一些所谓的学习路线，学会了final、violate、选举算法、多线程对象和锁的相关原理和算法等知识以后，其实用处不大，再啰嗦一下，在项目中还是没法入门并发编程，因为项目是靠组件，而不是算法和底层对象等来实现并发。

  2 能根据项目的高并发需求，使用组件解决实际问题，比如会用Kafka组件实现高并发场景下的异步处理或消息缓存的流程，同时能根据实际的需求，配置Kafka或dubbo等组件的参数。

  3 使用组件实现高并发需求时，能解决遇到的实际问题。比如项目中遇到Netty或Dubbo方面的OOM问题，能通过查资料和查日志解决。

  4 熟练掌握扩容、搭建集群和部署组件和业务模块的技术，能在一无所有的前提下，帮助项目组搭建一个能应对高并发的系统，同时能解决里面的问题。

  其中对Java初级开发而言，最好要掌握第一个层次的技能，对Java高级开发而言，要掌握第二层次的技能，最好再要有一定的解决分布式组件问题的经验，即需要部分达到第三层次的标准。而Java架构师一定得达到第三层次的标准，至于第四层次的标注，是针对资深架构而言的。

  讲到这里大家其实能够理解，平时在并发层面出现频率不少的锁、原子类或Synchronized等技术，其实是包含在Netty，Dubbo或Kafka等组件背后的原理或实现机制，学好了不能说没用，但也就是聊胜于无，或者说顶多面试时能用到，平时项目开发中未必会直接用到这些原理或底层算法。

  举例来说吧，比如要实现高并发场景下的分布式锁，大多数项目的做法是用Seata等组件，通过配置和API实现分布式锁里的提交或回滚等功能，而绝不是自己根据二阶段提交等算法，自己设计开发一套实现分布式锁的组件。

  上文用了不少篇幅，给出了项目组实现java高并发的一些方式和实现并发编程的几个层次，在这基础上，大家就能很好地理解后文给出的Java并发编程的学习路径和学习技巧了。

  讲到这里，本人忍不住要吐槽，其实在不少公司的项目里，程序员是只要求用增删改查的API开发业务，项目没有高并发的需求，对应的程序员其实是没机会全方面接触到高并发技术的，或者顶多用到些组件的API，或者是用到高并发组件或技术里的一部分。

  在没有在项目实践中全方面接触到Java高并发技术，并解决过高并发产线问题的前提下，认为并发编程技术就是Java多线程中的一些技术，或者是一些诸如线程互斥或调度等算法，这也能理解的，但本人好歹在一些大厂呆过，多少接触过一些高并发需求和技术，也多少解决过一些实际问题，所以下文给出的学习路径和学习技巧应当对大家有帮助。

  这里需要说明的是，学的时候绝不能但看理论，更要动手实践，如果项目里有用这些组件的机会，就从项目里学，否则的话，就在自己的电脑上搭建个环境学。

  2 在自学阶段，由于缺乏项目实践机会，其实只能掌握到“熟悉组件API”的程度。有些程序员在工作中有分布式组件的实践机会，或者还能结合项目来学，但大多数程序员，真是因为在平时项目开发过程中只接触到基本技能，所以才要通过自学来掌握分布式高并发的技能。

  自学阶段需要达成的目标一般不是熟练掌握高并发相关的实践技能，而是能在未来的面试中验证自己有高并发相关的项目经验。

  3 通过自学组件或其他技能，能让自己掌握基本但必需的分布式高并发技能后，就要准备面试，争取挑战大厂或网络公司的那些真正能提供高并发项目实践机会的职位。

  在这个阶段，由于程序员一般只具有并发方面的理论知识，或是api技能，顶多外带些实际应用和解决有关问题的经验，所以在这个准备面试阶段，能够使用“项目嫁接”的技巧，即尽量在你当前做的项目里，结合该技术的项目使用情况，这样就能证明该并发技术项目实践经验，进而能证明大多数并发技术有项目实践经验。

  比如对于基于redis的缓存技术，你们可以在熟悉基本缓存和读取数据的api前提下，为缓存找个项目需求落脚点，比如因为在本项目里，多次去查询用户数据会导致性能慢，所以会引入redis。引入后redis的键是什么，值是什么，同时设的超时是多少，解决过缓存穿透问题，同时用RDB的方式做redis持久化。

  当然，在面试中证明并发技术的项目实践经验也是个互动的过程，你说了以后，面试官会问细节问技术，所以在为技术找好项目实践背景后，还要背题，比如背redis面试题，甚至去看redis背后的线程和缓存处理流程。但还是这句话：如果但学算法和细节，不证明有关技术的项目实践经验，一定没发通过面试。

  4 通过了解并发技术外带按上文准备好面试说辞，当然再需要经过多次面试试错，程序员一般有机会找到能真正提供并发技术实践机会的公司和项目。

  上文说了，这一些企业和项目不多，但程序员如果准备得当，不是找不到这种机会，毕竟不少互联网大厂的面试机会摆在那里，而且也有不少程序员，甚至是初级开发的程序员通过准备面试技巧成功地进大厂。

  当大家真正在互联网等公司全方面接触到高并发技术以后，甚至都不用问，就能背项目推动着，自行不断地积累并深化java高并发技术，因为在这种项目里，不仅需要大量接触高并发的需求，还要一直地搭建集群，同时解决限流熔断等实际问题，当然还要一直解决并发方面的线上问题。

  到了此阶段，其实大家就能发现，我上文给出的一些并发学习的观点不能说没有道理，甚至有可能有不少架构师会赞同我的上述论断。

  1 那些java多线程、锁或并发对象，和相关的算法和原理，不能说一点用都没有，可能一些资深架构在排查问题时，需要接触到这些底层源码或对象，但这已经是很后面的事情。但至少在学习并发技术的开始阶段，不需要用这些技术打基础。这些技术的价值顶多是让你背，让你以此过面试。

  2 在开始阶段，学java并发技术就是学和用分布式组件，这句话虽然会引起争议，但通过分布式组件入门java并发技术，至少也是个学习路线。毕竟在真正的高并发项目里，是通过相关组件来实现限流，熔断和负载均衡等高并发需求的。

  3 学并发技术能分两阶段走，第一步通过项目或自学，了解组件或有关技术的基本api以及其他基本用法，随后通过相应的面试技巧，结合项目证明并发技术，以此找到能提供并发实践机会的项目，在项目中真正提升并发技术。

  也写了将近4000字的原创性文字了，相信多少会对大家起到一定的帮助，所以这里也允许我介绍下我最近出的和分布式并发技术有关的书。

  其实在学并发组件时，难点在于搭建环境，比如redis和dubbo等组件一般是搭建在linux系统上，要在windows上搭建这些组件的开发环境不容易。没有环境，后面的学习也无从谈起了。

  这本书会在讲述spring boot有关技术的前提下，讲述在windows系统上搭建mongdb，redis，dubbo，rabbitmq，nginx和mycat等分布式高并发组件开发环境的做法，并在此基础上讲述在spring boot框架里使用这一些组件的api，所以应该能让大家对并发组件有个初步的认识，同时能掌握用这些组件解决高并发问题的一些方法。

  同时发起个付费咨询。如果大家要逐步了解写简历和准备面试的技巧，能咨询我，本人最近密集帮助了不少程序员朋友成功跳槽，薪资涨幅均在30%以上，多的薪资翻番的例子也有。

  而且最近，本人还有上海知名外企的内推机会。上海知名外企内推的要求是，java起码有3年经验，肯上进，英语当然最好是好些，但英语绝非时是阻碍性因素。

  1 我会用我自己出的书的电子版来帮大家提升，这些资料的价格都比咨询的价格要贵。

  2 顺带辅导简历和面试。如果你在上海，学历可以，我还能帮忙内推知名外企和其他公司，并全程辅导面试。

  最后祝广大程序员都能寻找自我心仪的工作，拿到自己期望中的薪资。若能，也请大家多多点赞我的文章。