网站技术与Java中间件培训方案

运算器

控制器

控制器的作用是协调和控制节点之间的动作和行为

实现

1.通过DNS服务器进行调度和控制

2.负载均衡

3.Master-Worker

引用负载均衡设备解决

1、粘滞session

2、session复制

3、session集中存储

4、cookie存储会话数据

问题1：数据复制问题

问题2：应用数据源选择问题

数据缓存

页面缓存

问题：不同应用程序间会存储相同的代码

特点

无限线程池：ExecutorService threadpool = Executors.newCachedThreadPool();

固定线程池：ExecutorService threadpool = Executors.newFixedThreadPool(3);

单线程池：ExecutorService threadpool = Executors.newSingleThreadExecutor();

周期线程池：ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(5);

tryLock方法，不会造成线程阻塞，返回true即获得锁，返回false没有获得锁

其构造方法接受一个Boolean类型参数，描述锁是否是公平锁

ReetrantReadWriteLock，提供了读写锁，使用与读多写少的情况

volatile保证了共享变量在线程间的可见性

volatile相比Synchronized，前者是保证了可见性，后者具备可见性和操作互斥性。

操作互斥性和可见性是两回事，操作互斥性保证了操作的原子性。可见性是共享变量的变化在多个线程间是可见的

JDK提供的原子类，其提供的变量的写操作是线程安全的。内部使用了CAS进行实现

Synchronized

Lock

描述：CountDownLatch是java.util.concurrent并发包下的类

作用：提供的机制是当多个线程到达预期状态或者完成预期工作时触发事件，其他线程等待这个事件来触发自己后续的工作。

构造方法：CountDownLatch latch = CountDownLatch(int count); //count是调用countDown线程的数量

触发事件：countDown()

线程等待：await（）方法

注意：等待的线程可以是多个，也就是说countDown（）可以唤醒多个在等待的线程

描述：循环屏障

作用：可以协作多个线程，让多个线程在这个屏障前等待，知道所有线程都到达这个屏障时，才一起继续执行后续的代码

构造方法：CyclicBarrier barrier = CyclicBarrier(int count); //count是等待线程的数量

等待方法：barrier.awat()；

描述：适用于管理信号量，构造参数传递的是可供管理的信号量的数值。

作用：控制并发的代码，执行前先获得信号（acquire方法），执行后归还信号（release方法），每次获得信号后，总信号量就会-1，如果没有可用的信号，acquire就会阻塞，知道有线程执行release方法释放信号量。

构造方法：Semaphore semaphore = new Semaphore(count); //count是信号的总数

获得信号

释放信号

注意

描述：交换。

作用：用于在两个线程之间进行数据的交换。线程会阻塞在exchange方法上，直到另外一个线程也达到exchange方法时，两者交换数据，然后各自线程再继续执行自身的代码。

注意：无论是谁先达到exchange方法，都会等待另外一个线程也达到

FutureTask可用于异步获取执行结果或取消执行任务的场景。通过传入Runnable或者Callable的任务给FutureTask，直接调用其run方法或者放入线程池执行，之后可以在外部通过FutureTask的get方法异步获取执行结果，因此，FutureTask非常适合用于耗时的计算，主线程可以在完成自己的任务后，再去获取结果。另外，FutureTask还可以确保即使调用了多次run方法，它都只会执行一次Runnable或者Callable任务，或者通过cancel取消FutureTask的执行等。

FutureTask是Future的实现类，帮助实现了具体的任务以及与Future接口的get等方法的关联。

get方法：异步获得线程返回的结果

并发容器主要指的是在JDK并发包中以CopyOnWrite和Concurrent开头的几个容器

优势：相比加锁互斥保证线程安全，并发容器的思路是尽量不使用锁实现线程安全，性能上比直接使用锁要好很多。

CopyOnWrite思路

Concurrent思路

装饰着设计模式

JDK动态代理

CGlib动态代理

Javassist

1. 在运行时，判断一个对象所属的类

2. 在运行时，构造任意类的对象

3. 在运行时，判断一个类的成员变量和方法

4. 在运行时，调用任意一个对象的方法

5. 生成动态代理

接口调用

寻址路由：让调用方确定哪个实例被调用

编码

通讯

通讯

解码

实例定位：被调用的机器上找到对应的实例进行方法调用

服务调用

1. 根据服务名称，获得可用服务列表

2. 确定要调用服务的目标机器

3. 建立连接

4. 请求序列化

5. 发送请求

6. 接受结果

7. 解析结果

1. 设置死循环，监听服务端口号

2. 接受请求

3. 发序列化数据

4. 获得服务对象

5. 通过反射执行服务对象方法

6. 序列化结果数据

7. 响应数据

代码角度看如何使用服务框架

服务框架与应用和容器的关系

分支主题

1. 服务提供者注册服务地址到注册中心

2. 服务调用者从注册中心根据服务名称查找服务地址列表

3. 服务调用者从服务列表中选择一个服务进行调用

4. 服务地址变更后，注册中心主动通知服务调用者

在服务寻址完成后，就要进行实际的远程调用，如果接口中有些方法非常耗时，势必会影响远程调用的性能，导致所有线程会等待在耗时的方法上。

解决方案

分支主题

基本思路是甄别服务调用者的地址，尽量返回同机房的服务提供者的地址，以提高服务调用的效率

流量控制是为了保证系统的稳定性

控制方式

控制维度

序列化就是讲内存对象变为二进制数据

反序列化就是将二进制数据变为内存对象

服务调用方将方法参数进行序列化后，通过网络传输到远程的服务提供端，服务提供端进行反序列化数据后进行相关调用

BIO

NIO

AIO

Oneway

Callback

Future

消息中间件

优化前

优化后

网络通信用BIO

IO线程进行通讯

反序列可以在IO线程也可以在工作线程

调用服务在工作线程

分支主题

根据服务的名称、方法、参数来确定要执行服务的线程池是哪个

分支主题

0-1开关控制服务是否可用

阈值控制限流

针对调用者提供差异化的服务访问，确保优先级高的调用者优先提供服务。

通讯、序列化、协议等功能对服务提供者和调用者来讲应该是公共的

服务框架应该是模块化的

直接修改服务提供者接口实现的代码，使用灰度发布方式验证后全部发布。

增加方法

方法参数变化

将不同业务的数据拆分到不同的数据库

影响

将同一业务的数据拆分到不同数据库

影响

Application Program：应用程序，定义了事务的边界

Resource Manager：资源管理器，可以理解为DBMS，管理应用程序的数据资源

Transaction Manager：事务管理器，负责协调和管理实务

CAP

BASE

分布式系统下节点之间的通信方式

Paxos可以保证分布式系统中状态一致性

Paxos的前提是不存在拜占庭将军问题，也就是说节点之间传递的消息是可靠的

Paxos的角色

二阶段提交

TCC

消息中间件

zookeeper

redis

雪花算法

1. 将Join操作分多次在不同数据库执行

2. 数据冗余，将原来需要Join的操作进行单表查询

3. 借助第三方系统（MyCat）实现

分库库的表尽量内聚，否则只能靠应用判断了。

查询合并

函数处理

分页查询

获得SQL中的关键信息，例如表名、字段、where条件等

规则处理的目的是执行SQL的目标库

固定哈希算法

一致性哈希算法

虚拟节点对一致性哈希的改进

自定义规则

以上的规则使用哪一个没有明确的答案，目标是尽量避免跨库的查询

针对分库后的表，为了避免误操作，通常会将表名重命名

规则处理决定的是一组相同的数据库源，这样做是为了实现实现一写多度，提高数据库的访问速度。

选择数据库源就是选择某一个具体的数据库

需要注意的是对异常的处理判断，要能辨别出来是哪一个库的异常信息

分支主题

DataSource：数据访问层对外提供透明的DataSource

groupDataSource：管理同一组数据源的对象

AtomDataSource：连接具体数据库的数据源对象，这里不使用第三方的数据源c3p0等，是为了配置和实现更加的灵活

分支主题

采用数据库协议，将Proxy看做数据库，Proxy使用JDBC连接数据库。实现方式复杂

采用私有协议，Proxy对外提供的通讯协议是自己设计的，并且需要一个数据层客户端。实现相对简单一些

分支主题

主从复制

数据平滑迁移

分支主题

此种方式有局限性，数据库必须支持分布式事务

分支主题

步骤分析

问题分析

解决方式

分支主题

应用程序自己的业务数据库存储消息数据

消息中间件访问业务数据库

分支主题

消息中间件不需要与业务数据库打交道

分支主题

消息存储到本地文件中

一个消息只能被一个消费者消费

消息消息可以被所有消费者消费

点对点

发布订阅

分支主题

需求

问题

解决方案

接收方启动订阅关系有效，接收方宕机订阅关系失效

接收方启动订阅关系有效，接收方宕机在激动后任然可以接受之前消息

消息中间件及时、明确地返回成功，表示消息可靠达到消息中间件

消息中间件返回错误、出现异常、超时等情况，都表示消息未到达消息中间件

需要注意的是处理异常情况，不要吞掉异常

将消息存储在关系型数据库中

双机内存备份

消息存储的扩容

消息中间件需要收到接受者确认消息处理的信号才能删除消息

消息接受者不能在接收到消息后就发送确认消息，而是在处理完业务后再发送确认消息

消息投递优化

JMS接收到消息后自动确认，此时业务还没来得及处理就确认消息，不可靠

客户端调用message.acknowledge()方法进行确认消息

消息接收方的消息处理函数执行完毕后进行确认

队列轻量化，单个队列数据非常少

对磁盘的访问串行化

把服务提供者的信息主动传输给服务端

提供者的信息变更后负责更新服务端的数据

向服务端告知自己需要的数据

将数据缓存到本地，如果服务信息变更，负责更新本地数据

数据结构：key-value

dataId是数据的唯一标识

同样额dataId内部支持分组（group）

通过dataId和group可以定位到具体的数据

服务使用者将自己需要的信息告知给软负载中心

订阅的粒度和聚合数据的粒度是一直的，也是通过dataId和Group

如果聚合数据有变化时，通过订阅关系找到使用者，通知使用者更新数据

连接数据也是key-value结构，groupId作为Key,物理连接作为Value

当订阅数据发生变更时，通过订阅关系找到需要通知的groupId，通过groupId找到连接，通过连接发送最新数据

分支主题

使用锁或者并发容器保证线程安全

分支主题

根据dataId和groupId分线程处理数据的新增、删除和更新操作，这样就不要锁保证线程安全。

分支主题

软负载中心不管理数据，无状态，这样数据发布者和订阅者连接任何软负载中心都可以

分支主题

软负载中心写数据和读数据分开，分工明确

分支主题

软负载中心保存数据，集群中的各个节点互相通讯，任意节点数据发生变化，其他节点从该节点同步最新数据

这种方式的问题是节点间进行数据同步的成本高

优化

分支主题

分支主题

CPU、内存使用情况、IO情况等

调用次数、成功率、响应时间等