一、分布式架构通信
1、分布式架构通信原理
- SOA架构:
根据实际业务,把系统拆分成合适的、独立部署的模块,模块之间相互独立。
优点:分布式、松耦合、扩展灵活、可重用。
SOA架构系统中,使用Dubbo和Zookeeper进行服务间的远程通信。
优点:
Dubbo使用自定义的TCP协议,可以让请求报文体积更小,或者使用HTTP2协议,也可以减少报文的体积,提高传输效率。
- 微服务架构
SpringCloud中使用Feign解决服务之间远程通信的问题。
Feign:轻量级RESTful的HTTP服务客户端,广泛应用于Spring Cloud中。符合面向接口化的编程习惯。
本质:封装了HTTP调用流程,类似Dubbo的服务调用。
多用于同步远程调用。
RPC主要基于TCP/UDP协议,HTTP协议是应用层协议,是构建在传输层协议TCP之上的,RPC效率更高,RPC长连接:不必每次通信都像HTTP一样三次握手,减少网络开销;
HTTP服务开发迭代更快:在接口不多,系统与系统之间交互比较少的情况下,HTTP就显得更加方便;相反,在接口比较多,系统与系统之间交互比较多的情况下,HTTP就没有RPC有优势。
一切都很完美!
。。。
直到你碰到了下面这个问题:
2、分布式同步通信的问题
电商项目中,如果后台添加商品信息,该信息放到数据库
我们同时,需要更新搜索引擎的倒排索引
同时,假如有商品页面的静态化处理,也需要更新该页面信息
怎么解决?
方式一、可以在后台添加商品的方法中,如果数据插入数据库成功,就调用更新倒排索引的方法,接着调用更新静态化页面的方法。
代码应该是:
Long goodsId = addGoods(goods);
if (goodsId != null) {
refreshInvertedIndex(goods);
refreshStaticPage(goods);
}
问题:
假如更新倒排索引失败,该怎么办?
假如更新静态页面失败怎么办?
解决方式:
问题:
假如更新倒排索引失败,该怎么办?
假如更新静态页面失败怎么办?
解决方式:
如果更新倒排索引失败,重试
如果更新静态页面失败,重试
代码应该是这样:
public Long saveGoods() {
Long goodsId = addGoods(goods);
if (goodsId != null) {
// 调用递归的方法,实现重试
boolean indexFlag = refreshInvertedIndex(goods);
// 调用递归的方法,实现重试
boolean pageFlag = refreshStaticPage(goods);
}
}
private boolean refreshInvertedIndex(Goods goods) {
// 调用服务的方法
boolean flag = indexService.refreshIndex(goods);
if (!flag) {
refreshInvertedIndex(goods);
}
}
private boolean refreshStaticPage(Goods goods) {
// 调用服务的方法
boolean flag = staticPageService.refreshStaticPage(goods);
if (!flag) {
refreshStaticPage(goods);
}
}
以上代码在执行中的问题:
- 如果相应的更新一直失败,岂不是一直死循环直到调用栈崩溃?
- 如果相应的更新一直在重试,在重试期间,添加商品的方法调用是不是一直阻塞中?
- 如果添加商品的时候并发量很大,效率岂不是很低?
或许可以加上迭代的等待时间,迭代的次数加以限制,减少CPU消耗。
或许还可以加上多线程,同时执行更新的操作,减少执行的时间。
但是都是基于该调用一定在可见的时间内调用成功。
还是老问题:如果更新失败怎么办?
归根到底,是同步调用处理不当。这个问题在分布式架构中尤为严重。
方式二:可以先执行添加商品的方法,商品添加成功,将更新索引和更新静态页面的任务缓存到一个公共的位置,然后由相应的服务从该位置获取任务来执行。
Long goodsId = addGoods(goods);
if (goodsId != null) {
goodsTaskService.cache(goods);
}
此时,由于添加商品仅仅是将数据插入数据库,然后将任务信息缓存,调用立刻返回。
对于添加商品方法的调用,不会存在线程阻塞,不会存在调用栈崩溃。
再考虑远一点。
由于更新倒排索引的的服务和更新静态页面的服务要从公共的缓存或者叫任务池中取出任务并执行,它们也会有执行失败的问题,也需要重试。如果一直更新失败,也需要一个方式来处理。
比如如果更新失败,则每隔3秒钟重试一次,重试三次都失败则放弃执行。
然后将错误结果放到另一个公共的地方,等待后续的补偿,无论是手工还是自动的。
还有问题:
- 这个公共的任务池,会不会宕机?会不会服务不可用?如何解决?
- 你一定确信消息发送到任务池了吗?
- 如果在向任务池发送任务失败该如何处理?
- 如果重试的时候发送成功了,但是实际上发送了多次,更新倒排索引服务和更新静态页面服务会不会重复执行?
- 如果重复执行,最终结果会不会不一样?
- . 。。。
看来真是解决了一个问题,引进来三个问题。
如果上述的问题都由我们从0开始解决,开发难度可想而知。
分布式服务中,由于业务拆分,应用也需要拆分,甚至数据库分库分表。
但是完成一个业务处理,往往要设计到多个模块之间的协调处理。此时模块之间,服务与服务之间以及客户端与服务端之间的通信将变得非常复杂。
3、分布式异步通信模式
比较典型的“生产者消费者模式”,可以跨平台、支持异构系统,通常借助消息中间件来完成。
优点:系统间解耦,并具有一定的可恢复性,支持异构系统,下游通常可并发执行,系统具备弹性。服务解耦、流量削峰填谷等
缺点:消息中间件存在一些瓶颈和一致性问题,对于开发来讲不直观且不易调试,有额外成本。
使用异步消息模式需要注意的问题:
- 哪些业务需要同步处理,哪些业务可以异步处理?
- 如何保证消息的安全?消息是否会丢失,是否会重复?
- 请求的延迟如何能够减少?
- 消息接收的顺序是否会影响到业务流程的正常执行?
- 消息处理失败后是否需要重发?如果重发如何保证幂等性?
二、消息中间件简介
1、消息中间件概念
维基百科对消息中间件的解释:面向消息的系统(消息中间件)是在分布式系统中完成消息的发送和接收的基础软件。
消息中间件也可以称消息队列,是指用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型,可以在分布式环境下扩展进程的通信。
消息中间件就是在通信的上下游之间截断:break it,Broker
然后利用中间件解耦、异步的特性,构建弹性、可靠、稳定的系统。
体会一下:“必有歹人从中作梗”,”定有贵人从中相助“
异步处理、流量削峰、限流、缓冲、排队、最终一致性、消息驱动等需求的场景都可以使用消息中间件。
2、自定义消息中间件
并发编程领域经典面试题:请使用java代码来实现“生产者消费者模式”。
BlockingQueue(阻塞队列)是java中常见的容器,在多线程编程中被广泛使用。
当队列容器已满时生产者线程被阻塞,直到队列未满后才可以继续put;
当队列容器为空时,消费者线程被阻塞,直至队列非空时才可以继续take。
KouZhao.java
@Data
public class KouZhao {
private String id;
private String type;
public KouZhao(String id, String type) {
this.id = id;
this.type = type;
}
}
Producer.java
public class Producer implements Runnable {
private final BlockingQueue<KouZhao> blockingQueue;
public Producer(BlockingQueue<KouZhao> blockingQueue) {
this.blockingQueue = blockingQueue;
}
@Override
public void run() {
while (true) {
try {
Thread.sleep(200);
if (blockingQueue.remainingCapacity() > 0) {
KouZhao kouZhao = new
KouZhao(UUID.randomUUID().toString(), "N95");
blockingQueue.add(kouZhao);
System.out.println("我在生产口罩,当前库存是:" +
blockingQueue.size());
} else {
System.out.println("我的仓库已经堆满了" +
blockingQueue.size() + "个口罩,快来买口罩啊!");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
Consumer.java
public class Consumer implements Runnable {
private final BlockingQueue<KouZhao> blockingQueue;
public Consumer(BlockingQueue<KouZhao> blockingQueue) {
this.blockingQueue = blockingQueue;
}
@Override
public void run() {
while (true) {
try {
Thread.sleep(100);
long startTime = System.currentTimeMillis(); // 获取开始时间
KouZhao kouZhao = blockingQueue.take();
long endTime = System.currentTimeMillis(); // 获取结束时间
System.out.println("我消费了口罩:" + kouZhao + ", 等到货时我阻
塞了" + (endTime - startTime) + "ms");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
App.java
public class App {
public static void main(String[] args) throws InterruptedException {
BlockingQueue<KouZhao> queue = new ArrayBlockingQueue<>(20);
Producer producer = new Producer(queue);
Consumer consumer = new Consumer(queue);
new Thread(producer).start();
Thread.sleep(20000);
new Thread(consumer).start();
}
}
上述代码放到生产环境显然是不行的,比如没有集群,没有分布式,玩儿法太单一,不能满足企业级应用的要求。。。
比如:
消息有没有持久化?
怎么确定消息一定能发送成功?
怎么确定消息一定能被消费成功?
高并发下的性能怎么样?
系统可靠吗?
有没有Pub/Sub模式?
有没有考虑过限流?
。。。
3、主流消息中间件及选型
在传统金融机构、银行、政府机构等有一些老系统还在使用IBM等厂商提供的商用MQ产品。
当前业界比较流行的开源消息中间件包括:ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等,其中应用最为广泛的要数RabbitMQ、RocketMQ、Kafka这三款。
Redis在某种程度上也可以是实现类似“Queue”和“Pub/Sub”的机制,严格意义上不算消息中间件。
- 选取原则
首先,产品应该是开源的。开源意味着如果队列使用中遇到bug,可以很快修改,而不用等待开发者的更新。
其次,产品必须是近几年比较流行的,要有一个活跃的社区。这样遇到问题很快就可以找到解决方法。同时流行也意味着bug较少。流行的产品一般跟周边系统兼容性比较好。
最后,作为消息队列,要具备以下几个特性:
- 消息传输的可靠性:保证消息不会丢失。
- 支持集群,包括横向扩展,单点故障都可以解决。
- 性能要好,要能够满足业务的性能需求。
- RabbitMQ
RabbitMQ开始是用在电信业务的可靠通信的,也是少有的几款支持AMQP协议的产品之一。
优点:
- 轻量级,快速,部署使用方便
- 支持灵活的路由配置。RabbitMQ中,在生产者和队列之间有一个交换器模块。根据配置的路由规则,生产者发送的消息可以发送到不同的队列中。路由规则很灵活,还可以自己实现。
- RabbitMQ的客户端支持大多数的编程语言。
缺点:
- 如果有大量消息堆积在队列中,性能会急剧下降
- RabbitMQ的性能在Kafka和RocketMQ中是最差的,每秒处理几万到几十万的消息。如果应用要求高的性能,不要选择RabbitMQ。
- RabbitMQ是Erlang开发的,功能扩展和二次开发代价很高。
- RocketMQ
RocketMQ是一个开源的消息队列,使用java实现。借鉴了Kafka的设计并做了很多改进。
RocketMQ主要用于有序,事务,流计算,消息推送,日志流处理,binlog分发等场景。经过了历次的双11考验,性能,稳定性可可靠性没的说。
RocketMQ几乎具备了消息队列应该具备的所有特性和功能。
- java开发,阅读源代码、扩展、二次开发很方便。
- 对电商领域的响应延迟做了很多优化。在大多数情况下,响应在毫秒级。如果应用很关注响应时间,可以使用RocketMQ。
- 性能比RabbitMQ高一个数量级,每秒处理几十万的消息。
缺点:
- 跟周边系统的整合和兼容不是很好。
- Kafka
Kafka的可靠性,稳定性和功能特性基本满足大多数的应用场景。
- 跟周边系统的兼容性是数一数二的,尤其是大数据和流计算领域,几乎所有相关的开源软件都支持Kafka。
- Kafka高效,可伸缩,消息持久化。支持分区、副本和容错。
- Kafka是Scala和Java开发的,对批处理和异步处理做了大量的设计,因此Kafka可以得到非常高的性能。它的异步消息的发送和接收是三个中最好的,但是跟RocketMQ拉不开数量级,每秒处理几十万的消息。
- 如果是异步消息,并且开启了压缩,Kafka最终可以达到每秒处理2000w消息的级别。但是由于是异步的和批处理的,延迟也会高,不适合电商场景
4、消息中间件应用场景
消息中间件的使用场景非常广泛,比如,12306购票的排队锁座,电商秒杀,大数据实时计算等。
- 电商秒杀案例:
比如6.18,活动从0:00开始,仅限前 200 名,秒杀即将开始时,用户会疯狂刷新 APP或者浏览器来保证自己能够尽早的看到商品
- 当秒杀开始前,用户在不断的刷新页面,系统应该如何应对高并发的读请求呢?
- 在秒杀开始时,大量并发用户瞬间向系统请求生成订单,扣减库存,系统应该如何应对高并发的写请求呢?
系统应该如何应对高并发的读请求
- 使用缓存策略将请求挡在上层中的缓存中
- 能静态化的数据尽量做到静态化
- 加入限流(比如对短时间之内来自某一个用户,某一个IP、某个设备的重复请求做丢弃处理)
系统应该如何应对高并发的写请求
生成订单,扣减库存,用户这些操作不经过缓存直达数据库。如果在 1s内,有 1 万个数据连接同时到达,系统的数据库会濒临崩溃。如何解决这个问题呢?我们可以使用 消息队列。
消息队列的作用:
- 削去秒杀场景下的峰值写流量——流量削峰
- 通过异步处理简化秒杀请求中的业务流程——异步处理
- 解耦,实现秒杀系统模块之间松耦合——解耦
削去秒杀场景下的峰值写流量
将秒杀请求暂存于消息队列,业务服务器响应用户“秒杀结果正在处理中。。。”,释放系统资源去处理其它用户的请求。
削峰填谷,削平短暂的流量高峰,消息堆积会造成请求延迟处理,但秒杀用户对于短暂延迟有一定容忍度。
秒杀商品有 1000 件,处理一次购买请求的时间是 500ms,那么总共就需要 500s 的时间。这时你部署 10 个队列处理程序,那么秒杀请求的处理时间就是 50s,也就是说用户需要等待 50s 才可以看到秒杀的结果,这是可以接受的。这时会并发 10 个请求到达数据库,并不会对数据库造成很大的压力。
通过异步处理简化秒杀请求中的业务流程
先处理主要的业务,异步处理次要的业务。
如主要流程是生成订单、扣减库存;次要流程比如购买成功之后会给用户发优惠券,增加用户的积分。
此时秒杀只要处理生成订单,扣减库存的耗时,发放优惠券、增加用户积分异步去处理了。
解耦,实现秒杀系统模块之间松耦合
将秒杀数据同步给数据团队,有两种思路:
- 使用 HTTP 或者 RPC 同步调用,即提供一个接口,实时将数据推送给数据服务。系统的耦合度高,如果其中一个服务有问题,可能会导致另一个服务不可用。
- 使用消息队列
将数据全部发送给消息队列,然后数据服务订阅这个消息队列,接收数据进行处理。
- 支付宝购买电影票
如上图,用户在支付宝购买了一张电影票后很快就收到消息推送和短信(电影院地址、几号厅、座位号、场次时间等),同时用户会积累一定的会员积分。
这里,交易系统并不需要一直等待消息送达等动作都完成后才返回成功,允许一定延迟和瞬时不一致(最终一致性),而且后面两个动作通常可以并发执行。
如果后期监控大盘想要获取实时交易数据,只需要新增个消费者程序并订阅该消息即可,交易系统,对此并不感知,松耦合。