Dubbo

alibaba有好几个分布式框架，主要有：进行远程调用(类似于RMI的这种远程调用)的(dubbo、hsf)，jms消息服务(napoli、notify)，KV数据库(tair)等。这个框架/工具/产品在实现的时候，都考虑到了容灾，扩展，负载均衡，于是出现一个配置中心(ConfigServer)的东西来解决这些问题。 基本原理如图： 在我们的系统中，经常会有一些跨系统的调用，如在A系统中要调用B系统的一个服务，我们可能会使用RMI直接来进行，B系统发布一个RMI接口服务，然后A 系统就来通过RMI调用这个接口，为了解决容灾，扩展，负载均衡的问题，我们可能会想很多办法，alibaba的这个办法感觉不错。 本文只说dubbo，原理如下： ConfigServer 配置中心，和每个Server/Client之间会作一个实时的心跳检测（因为它们都是建立的Socket长连接），比如几秒钟检测一次。收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表，如： serviceName serverAddressList clientAddressList UserService 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 172.16.0.1，172.16.0.2 ProductService 192.168.0.3

alibaba有好几个分布式框架，主要有：进行远程调用(类似于RMI的这种远程调用)的(dubbo、hsf)，jms消息服务(napoli、notify)，KV数据库(tair)等。 这个框架/工具/产品在实现的时候，都考虑到了容灾，扩展，负载均衡，于是出现一个配置中心(ConfigServer)的东西来解决这些问题。 基本原理如图： 在我们的系统中，经常会有一些跨系统的调用，如在A系统中要调用B系统的一个服务，我们可能会使用RMI直接来进行，B系统发布一个RMI接口服务，然后A系统就来通过RMI调用这个接口，为了解决容灾，扩展，负载均衡的问题，我们可能会想很多办法，alibaba的这个办法感觉不错。 本文只说dubbo， 原理如下： ConfigServer 配置中心， 和每个Server/Client之间会作一个实时的心跳检测（ 因为它们都是 建立的Socket长连接 ） ，比如几秒钟检测一次。 收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表，如： serviceName serverAddressList clientAddressList UserService 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 172.16.0.1，172.16.0.2 ProductService 192

　　Dubbo是分布式服务架构，是一个优秀的开源服务型框架，使得应用可以通过高性能的rpc实现服务的输入和输出功能。其实dubbo就是资源调度和治理中心的管理工具。 发布dubbo服务：在提供服务的应用中发布服务 <!-- spring和service整合 --> <!-- 配置全局注解扫描 --> <context:component-scan base-package="nyist.e3.service"></context:component-scan> <!-- 使用dubbo发布服务 --> <!-- 1.提供服务的应用名称 name：一般为发布服务的项目名（可以随意））--> <dubbo:application name="e3-manager" /> <!--2.在zookeeper上注册服务：address：zookeeper注册中心所在的机器的ip地址：2181（端口号默认为2181），使用zookeeper的协议 --> <dubbo:registry address="ip:2181" protocol="zookeeper" /> <!-- 3.暴露服务的端口er ,默认为20080 --> <dubbo:protocol name="dubbo" port="20080"></dubbo:protocol> <!-- 4.声明需要暴露的服务接口

spring-boot-2整合dubbo 新框架学习，必须上手干。书读百遍，其义自见。 本文主要介绍spring-boot-2整合dubbo， 使用xml配置 实现一个provider和consumer。 1.创建Maven项目： spring-boot-parent：父工程，统一管理jar依赖，版本 spring-boot-service：子工程，dubbo服务提供方 spring-boot-web：子工程，dubbo服务消费方 2.spring-boot-parent： 父工程，统一管理jar依赖，版本 pom文件 <!--集中定义依赖版本号--> <properties> <maven_javadoc_version>3.0.1</maven_javadoc_version> <maven_surefire_version>2.19.1</maven_surefire_version> <spring-boot.version>2.1.2.RELEASE</spring-boot.version> <jedis.version>2.7.2</jedis.version> </properties> <!-- 就是管理版本的标签 其下的dependencies标签只是版本的管理 并不依赖jar--> <dependencyManagement> <dependencies>

因为疫情的原因，大家在家耽误了很多时间，但是云面试也应运而生，现在就来跟着看看朋友面完阿里滴滴美团之后总结的Java文档 那些在准备面试小伙伴们，快来，考点来啦 一.阿里面试题 1.自我介绍 2.序列化的底层怎么实现的 3.Synchronized的底层是怎么实现的 4.Tomcat集群怎么保证同步 5.了解nosql吗？redis? 6.怎么解决项目中超卖的问题 7.Int的范围 8.问了项目中超卖的问题怎么解决 9.你熟悉什么数据结构 10. 说说快排，我说了快拍实现的过程，相当于口述代码，然后问了复杂度 11. 乐观锁vs悲观锁 12. Gc 13. Concurrenthashmap分段锁的细节 14. 设计模式怎么分类，每一类都有哪些 15. 并发包里了解哪些 16. B树，b+树，b*树 二.滴滴面试题 1. 应该怎么优化简历才有BATJ面试机会 2. HashMap底层执行原理 3. Hashtable和ConcurrentHashMap如何实现线程安全？ 4. JVM的内存布局，垃圾回收机制 5. 类加载机制里的双亲委派模型 6. 阐述事物的隔离级别和传播属性 7. 高并发下，如何做到安全的修改同一行数据？ 8. A系统给B系统转100块钱，如何把实现 9. A服务调用B服务多接口，响应时间最短方案 10. 动态代理的几种实现方式及优缺点 11.

【推荐】2020年最新Java电子书集合.pdf(吐血整理) >>> 最近有很多朋友去目前主流的大型互联网公司面试（阿里巴巴、京东、字节跳动、蚂蚁金服、滴滴），面试回来之后会发给我一些面试题。有些朋友轻松过关，拿到offer，但是有一些是来询问我答案的。 我特意整理了一下，有很多问题不是靠几句话能讲清楚，所以整理了一些资料来解答这些面试题。很多问题其实答案很简单，但是背后的思考和逻辑不简单，要做到知其然还要知其所以然。 先来看下用手机记录的面试材料： 一，阿里巴巴面试题 二，滴滴面试题 三，美团面试题 四，携程面试题 五，本次面试得到的结论 通过面试题来看，可以看出目前互联网公司面试考点为： 性能调优、算法数据机构 高并发下数据安全、接口冪等性、原子性等 分布式下协同、已经锁的处理 数据库的分库分表、项目之间的垂直拆分 出现频率高的技术点有： HashMap JVM Dubbo Mybatis Zookeeper http tcp/ip docker 六，解惑资料与福利 以上部分面试题的答案整理了资料来解惑： 来源： oschina 链接： https://my.oschina.net/u/4441013/blog/3191021

前言 上篇文章 《Dubbo之服务暴露》 分析 Dubbo 服务是如何暴露的，本文接着分析 Dubbo 服务的消费流程。主要从以下几个方面进行分析： 注册中心的暴露 ； 通过注册中心进行服务消费通知 ； 直连服务进行消费 。 服务消费端启动时，将自身的信息注册到注册中心的目录，同时还订阅服务提供方的目录，当服务提供方的 URL 发生更改时，实时获取新的数据。 服务消费端流程 下面是一个服务消费的流程图： 上图中可以看到，服务消费的流程与服务暴露的流程有点类似逆向的。同样，Dubbo 服务也是分为两个大步骤：第一步就是将远程服务通过 Protocol 转换成 Invoker (概念在上篇文章中有解释)。第二步通过动态代理将 Invoker 转换成消费服务需要的接口。 org.apache.dubbo.config.ReferenceConfig 类是 ReferenceBean 的父类，与生产端服务的 ServiceBean 一样，存放着解析出来的 XML 和注解信息。类关系如下： 服务初始化中转换的入口 当我们消费端调用本地接口就能实现远程服务的调用，这是怎么实现的呢？根据上面的流程图，来分析消费原理。 在消费端进行初始化时 ReferenceConfig#init ，会执行 ReferenceConfig#createProxy 来完成这一系列操作。以下为

Zookeeper为注册中心，Dubbo是分布式服务框架 首先搭建服务的提供者，并将服务注册到Zookeeper上，当然前提是按好了zookeeper的服务： 所需的依赖(注意：dubbo使用的是阿里的依赖包不是apache的： <!-- dubbo依赖 --> <dependency> <groupId>com.alibaba.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>0.2.0</version> </dependency> <!-- Zookeeper依赖 --> <dependency> <groupId>com.github.sgroschupf</groupId> <artifactId>zkclient</artifactId> <version>0.1</version> </dependency> 配置文件，配置zookeeper的地址和扫描的需要注册服务的包： dubbo: registry: address: zookeeper://127.0.0.1:2181 application: name: provider scan: com.dubbo.springbootdubboprovider.server 注册到zookeeper的服务是一个接口：

分布式事务模型 TCC 模型：TCC-Transaction、Hmily XA 模型：Sharding Sphere、MyCAT 2PC 模型：raincat、lcn MQ 模型：RocketMQ BED 模型：Sharding Sphere Saga 模型：ServiceComb Saga TCC TCC事务解决方案本质上是一种补偿的思路，它把事务运行过程分成try、confirm/cancel 两个阶段，每个阶段都由业务代码来控制。需要注意的是，TCC事务和2pc的思想类似，但与2pc实现不同，TCC不再是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑。 实现过程： try：完成所有业务检查（一致性），预留业务资源。 confirm：确认执行业务操作，只使用try阶段预留的业务资源。 cancel：取消try阶段预留的业务资源。 XA模型（规范） xa是个规范，根据这个思想衍生二阶段提交协议和三阶段提交协议。 XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。 资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。 事务管理器

程序的运行，其本质上，是对系统资源（CPU、内存、磁盘、网络等等）的使用。如何高效的使用这些资源是我们编程优化演进的一个方向。今天说的线程池就是一种对CPU利用的优化手段。 网上有不少介绍如何使用线程池的文章，那我想说点什么呢？我希望通过学习线程池原理，明白所有 池化技术 的基本设计思路。遇到其他相似问题可以解决。 池化技术 前面提到一个名词——池化技术，那么到底什么是池化技术呢？ 池化技术简单点来说，就是提前保存大量的资源，以备不时之需。在机器资源有限的情况下，使用池化技术可以大大的提高资源的利用率，提升性能等。 在编程领域，比较典型的池化技术有： 线程池、连接池、内存池、对象池等。 本文主要来介绍一下其中比较简单的线程池的实现原理，希望读者们可以举一反三，通过对线程池的理解，学习并掌握所有编程中池化技术的底层原理。 创建一个线程 在Java的并发编程中，线程是十分重要的，在Java中，创建一个线程比较简单： 我们通过创建一个线程对象，并且实现Runnable接口就可以实现一个简单的线程。可以利用上多核CPU。当一个任务结束，当前线程就接收。 但很多时候，我们不止会执行一个任务。 如果每次都是如此的创建线程->执行任务->销毁线程，会造成很大的性能开销。 那能否一个线程创建后，执行完一个任务后，又去执行另一个任务，而不是销毁。这就是线程池。 这也就是池化技术的思想