分布式技术

作者：李小翀 链接： https://www.zhihu.com/question/22764869/answer/31277656 来源：知乎 1.初始 初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP特征：应用程序、数据库、文件等所有的资源都在一台服务器上。描述：通常服务器操作系统使用linux，应用程序使用JSP/PHP/ASP开发，然后部署在Apache上，数据库使用Mysql，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。 特征： 应用程序、数据库、文件等所有的资源都在一台服务器上。 描述： 通常服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了 2.应用服务和数据服务分离 好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver 特征： 应用程序、数据库、文件分别部署在独立的资源上。 描述： 数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。 3.使用缓存提高性能 特征： 数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力

在信息产业高速发展的今天， 企业 间的竞争将更加激烈。随着规模的不断扩大和业务的不断更新，企业迫切需求完整的分布式解决方案，用于管理复杂的异构环境，实现不同硬件设备、软件系统、网络环境及数据库系统之间的完整集成。 背景介绍 纵观人类计算机的发展历史，每隔十年至十五年，信息产业就会发生周期性的变革，1950年至1970年期间，企业主要采用大型主机－终端的体系结构，企业 应用 系统则采用单一、集中的方式为用户提供资源共享服务。80年代初期，开放系统与关系型数据库管理系统被企业大量采用，有别于集中式系统，应用程序逻辑分散在主从两端。随着Windows的普及，90年代则是图形化的应用时代，Client/Server体系结构也被广泛采用。90年代后期，信息产业出现了分布式对象技术，应用程序可以分布在不同的系统平台上，通过分布式技术实现异构平台间对象的相互通信。将企业已有系统集成于分布式系统，可以极大地提高企业应用系统的扩展性。90年代末出现的 多层 分布式应用为企业进一步简化应用系统的开发指明了方向。 在传统的Client/Server结构中，应用程序逻辑通常分布在 客户端 和 服务器 两端，客户端发出数据资源访问请求，服务器端将结果返回客户端。Client/Server结构的缺陷是，当客户端数目激增时，服务器的性能将会因为无法进行负载平衡而大大下降。而一旦应用的需求发生变化

某厂面试归来，发现自己落伍了！>>> RPC 简介 RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的细节的技术。 通过RPC我们可以充分利用非共享内存的多处理器环境（例如通过局域网连接得多台工作站）,这样可以简便地将你的应用分布在多台工作站上，应用程序就像运行在一个多处理器的计算机上一样。你可以方便的实现过程代码共享，提高系统资源的利用率，也可以将以大量数值处理的操作放在处理能力较强的系统上运行，从而减轻前端机的负担。 在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。 RPC 的主要目的是为组件提供一种相互通信的方式，使这些组件之间能够相互发出请求并传递这些请求的结果。 RPC 调用过程 客户机对服务器的一次RPC调用,其内部操作大致有如下十步： 1.调用客户端句柄；执行传送参数 2.调用本地系统内核发送网络消息 3.消息传送到远程主机 4.服务器句柄得到消息并取得参数 5.执行远程过程 6.执行的过程将结果返回服务器句柄 7.服务器句柄返回结果，调用远程系统内核 8.消息传回本地主机 9.客户句柄由内核接收消息 10.客户接收句柄返回的数据 RPC 的应用场景 RPC 在分布式系统中的系统环境建设和应用程序设计中有着广泛韵应用

--- 数据库管理系统 数据库管理系统主要分为俩大类：RDBMS、NOSQL。在个人电脑、大型计算机和主机上应用最广泛的数据库管理系统是关系型DBMS。NoSQL是对不同于传统的关系数据库的数据库管理系统的统称。 两者最重要的不同点是NoSQL不使用SQL作为查询语言。其数据存储可以不需要固定的表格模式，也经常会避免使用SQL的JOIN操作，一般有水平可扩展性的特征。 常见的数据库管理系统，及其排名情况如下： NoSQL数据库四大家族 NoSQL中的四大家族主要是：列存储、键值、图像存储、文档存储，其类型产品主要有以下这些。 存储类型 NoSQL 键值存储 最终一致性键值存储 Cassandra、Dynamo、Riak、Hibari、Virtuoso、Voldemort 内存键值存储 Memcached、Redis、Oracle Coherence、NCache、Hazelcast、Tuple space、Velocity 持久化键值存储 BigTable、LevelDB、Tokyo Cabinet、Tarantool、TreapDB、Tuple space 文档存储 MongoDB、CouchDB、SimpleDB、 Terrastore 、 BaseX 、Clusterpoint 、 Riak、No2DB 图存储 FlockDB、DEX、Neo4J、AllegroGraph

分布式消息队列 kafka介绍 基本架构 Kafka是开源的分布式消息队列，能够轻松实现高吞吐、可扩展、高可用，并且部署简单快速、开发接口丰富。 kafka分布式消息队列的作用： 解耦：将消息生产阶段和处理阶段拆分开，两个阶段互相独立各自实现自己的处理逻辑，通过kafka提供的消息写入和消费接口实现对消息的连接处理。降低开发复杂度，提高系统稳定性。 高吞吐量：kafka通过顺序读写磁盘提供可以和内存随机读写相匹敌的读写速度，灵活的客户端API设计，利用Linux操作系统提供的“零拷贝”特性减少消息网络传输时间，提供端到端的消息压缩传输，对同一主题下的消息采用分区存储，kafka通过诸多良好的特性利用廉价的机器就可以轻松实现高吞吐率。 高容错、高可用：kafka允许用户对分区配置多副本，kafka将副本均匀分配到各个broker存储，保证同一个分区的副本不会再同一台机器上存储（集群模式下），多副本之间采用Leader-Follower机制同步消息，只有Leader对外提供读写服务，当Leader以外失败、Broker进程关闭、服务宕机等情况导致数据不可用时，kafka会从Follwer中选择一个Leader继续提供读写服务。 可扩展：理论上kafka的性能随着Broker的增多而增加，增加一个Broker只需要为新增加的Broker设置一个唯一编号，编写好配置文件后

整理了一些Java方面的架构、面试资料（微服务、集群、分布式、中间件等），有需要的小伙伴可以关注公众号【程序员内点事】，无套路自行领取 更多优选 一口气说出 9种 分布式ID生成方式，面试官有点懵了 面试总被问分库分表怎么办？你可以这样怼他 3万字总结，Mysql优化之精髓 技术部突然宣布：JAVA开发人员全部要会接口自动化测试框架 9种分布式ID生成之美团（Leaf）实战 絮絮叨叨 还记得刚入行开始写Java时，接触的第一个项目是国家电网的一个业务系统，这个系统据说投资了5亿人民币进行研发，鼎盛时期研发人员一度达到过500人。项目采用当时最流行的ssh（Struts+Spring+Hibernate）框架，典型的三层架构（controller - > service -> dao）简单又粗暴，所有人写的代码都放在一个大工程里，项目文件大小达到几百M，解决代码冲突是当时最大的工作量。 然而戏剧性的是，交测当天五人同时上线，项目崩 崩 崩溃了。。。 哎！你永远想象不到甲方愤怒的样子，项目组每个人的祖宗都被问候到了。 说了一些没用的，脑子里总想起这个事，不说不痛快，大家姑且就当笑话听吧，下边我们进入正题 引言 前两天有个学弟公众号留言，说让讲讲分布式事务，面试就挂在这个问题上。时下随着微服务架构体系的流行，面试的题目也都慢慢开始升级，不再是早些年单纯的问点SSH框架知识、数据结构了。

微服务来源 单体应用 微服务是相对于单体应用的，在介绍微服务之前，先简单介绍一下单体应用：通常是由三个重要部分组成：客户端界面（由HTML、JavaScript组成）、数据库（由许多的表组件构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理客户端的HTTP请求、执行逻辑、检索并更新数据库中的数据、然后将处理后的数据返回给客户端。 一个单体应用被构建成一个系统时，业务中所有请求都要在单一的进程中处理完成，当访问量很高情况下服务器压力是很大的。当然可以水平扩展，利用负载均衡将实例布署到多台服务器中。 单体架构的缺点 [ ] 开发效率低 [ ] 代码维护难 [ ] 部署不灵活 [ ] 稳定性不高 [ ] 扩展性不高 云时代 在此之前单体应用也是很成功的，但是随着云时代的到来，单体应用就显得有些不妥了，特别是应用程序发布到云端的时候，一个功能的变更，需要统一的编译和发布。这样的架构模式很难使得一个模块的变更不影响到其他模块，而且在扩展方面也只能进行整体的扩展，不能根据正在运行的部分进行扩展。 微服务架构风格 云时代单体应用的尴尬导致了微服务架构风格的出现：以服务构建应用。 一个系统由多个服务组成，各服务可以被独立布署、独立扩展，每个服务也都提供了清晰的模块边界，甚至不同的服务都可以使用不同的编程语言来实现，也可以由不同的团队进行管理。 微服务介绍

架构设计的演进过程 业务驱动技术的发展是亘古不变的道理。最开始的时候，业务量少，业务复杂度低，采取的技术也相对简单，基本满足用户对功能的需求。随着IT信息化的普及，更多的交易放到了网络上，信息量增加和访问次数频繁就是要解决的问题了。因此，逐渐加入了缓存、集群等技术手段。同时对业务的扩展性和伸缩性的要求也越来越高。高并发、高可用、可伸缩、可扩展、够安全的软件架构一直是架构设计追求的目标。今天我们来看一下架构设计经历了哪些阶段，每个阶段都解决了哪些问题，又引出了哪些新问题。主要是引起大家的思考，在不同的业务发展阶段采取合适技术手段，用变化拥抱变化是IT人追求的目标。 应用与数据一体模式 最早的业务应用以网站、OA等为主，访问的人数有限，单台服务器就能够应付。通常，将应用程序和数据库部署到一台服务器上面，如图1-1所示。在这一阶段，我们利用LAMP（Linux Apache MySQL PHP）技术就可以迅速搞定，并且这些工具都是开源的。很长一段时间内，有各种针对这种应用模式的开源代码可以使用。这种模式基本上没有高并发的要求，可用性也很差。有的服务器采用托管模式，上面就安装了不同的业务应用，一旦服务器出现问题，所有的应用就罢工了。不过其开发和部署成本相对较低，适合刚刚起步的应用服务。图1 就描述了单个应用和数据库运行在单台服务器的模式，我们称这种模式为应用与数据一体模式。 图 1

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/l4vuYpNRjKxQRkRTDhyg2Q 作者：陈王荣 分布式任务调度框架几乎是每个大型应用必备的工具，本文介绍了任务调度框架使用的需求背景和痛点，对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践，并分析了这几种框架的优劣势和对自身业务的思考。 一、业务背景 1.1 为什么需要使用定时任务调度 （1）时间驱动处理场景： 整点发送优惠券，每天更新收益，每天刷新标签数据和人群数据。 （2）批量处理数据： 按月批量统计报表数据，批量更新短信状态，实时性要求不高。 （3）异步执行解耦： 活动状态刷新，异步执行离线查询，与内部逻辑解耦。 1.2 使用需求和痛点 （1）任务执行监控告警能力。 （2）任务可灵活动态配置，无需重启。 （3）业务透明，低耦合，配置精简，开发方便。 （4）易测试。 （5）高可用，无单点故障。 （6）任务不可重复执行，防止逻辑异常。 （7）大任务的分发并行处理能力。 二、开源框架实践与探索 2.1 Java 原生 Timer 和ScheduledExecutorService 2.1.1 Timer使用 Timer缺陷： Timer底层是使用单线程来处理多个Timer任务，这意味着所有任务实际上都是串行执行，前一个任务的延迟会影响到之后的任务的执行。

摘自： https://www.cnblogs.com/yangyuanhu/p/12439106.html Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 2 | 0 什么是RPC RPC全称(Remote Procedure Call)远程过程调用 过程指的是某个代码片段的执行,远程调用则意味着我们可以在其他进程,甚至其他机器上去调用这段代码,当然也能获取到其执行后的返回值,按照这个定义,我们请求某个http地址得到相应数据其实也算一次RPC,但是这样的方式太过麻烦,(数据要先打包成http请求格式,在调用相关的请求库,拿到的结果也是文本格式的需要在进行转换),执行效率,和开发效率相比RPC则低一些; 我们需要一种更简单的方式来完成分布式开发中的RPC环节,这也是Dubbo的核心所在,有多简单呢? 调用远程服务器上的某个服务时就像是调用本地的某个方法一样简单,就像下面这样 2 | 1 为什么需要rpc RPC是用来实现分布式构架的基石,分布式构架将同一个系统中的不同模块拆分到不同的子系统中,而子系统又分布在不同的服务器上,这时就需要RPC在来完成子系统之间的相互访问; 可以这么说分布式少不了RPC,RPC也要在分布式系统中才能发挥其核心价值; 2 | 2 rpc的实现原理