分布式架构

--- 数据库管理系统 数据库管理系统主要分为俩大类：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的实现原理

Kafka概述 a distributed streaming platform Kafka架构和核心概念 producer, 生产者，生产馒头。 consumer, 消费者，吃馒头。 broker, 篮子。 topic, 主题，给馒头带一个标签，topica的馒头是给你吃的，topicb的馒头是给你弟弟吃。 Zookeeper集群部署 安装包解压 ， 1 tar -xzvf zookeeper-3.4.5.tar.gz -C / export /servers zookeeper配置文件修改 ， 1 cp zoo_sample.cfg zoo.cfg 2 vi zoo.cfg 3 #数据目录. 可以是任意目录,其中的dataDir目录和dataLogDir需要提前建立好 4 #注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能，如果将日志存储在比较繁忙的存储设备上，那么将会在很大程度上影响系统的性能。 5 dataDir=/ export /servers/data/zookeeper 6 #log目录, 同样可以是任意目录. 如果没有设置该参数, 将使用和dataDir相同的设置，其中的dataDir目录和dataLogDir需要提前建立好 7 #注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。Spring Cloud大型企业分布式微服务云架构源码请加企鹅求求：一七九一七四三三八零 为了解决这个问题，业界提出了断路器模型。 一、断路器简介 Netflix has created a library called Hystrix that implements the circuit breaker pattern. In a microservice architecture it is common to have multiple layers of service calls. . —-摘自官网 Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图：

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