Java面试（5）

RPC与Http区别

RPC：Remote Produce Call远程过程调用;自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型.

• RPC的框架：webservie(cxf)、dubbo(阿里巴巴开源的基于 Java 的高性能 RPC)

Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。现在热门的Rest风格，就可以通过http协议来实现。

• http的实现技术：HttpClient

类别	相同点	特点	性能
RPC	底层通讯都是基于socket;都可以实现远程服务调用服务	要求服务提供方和服务消费方 都必须使用统一的RPC框架 跨操作系统在同一编程语言内使用 开发难度高,限制较多	高 (只传输主要的报文信息)
Http		无需关注服务提供/消费方使用的编程语言 服务提供方只需要提供restful风格的接口，服务消费方，按照restful的原则请求服务即可	中 (传输了大约70%的无用报文信息)

参照:

https://www.cnblogs.com/liang1101/p/13083965.html

-----------------------------------------------------------------------------------

消息中间件常见问题及解决方案

一, 各种消息中间件该如何选择?

	ActiveMQ	RabbitMQ	RocketMQ	Kafka
性能(单台-并发量)	6000+	万级(12000+)	十万级	百万级
消息持久化	支持(磁盘+数据库)	支持(磁盘)	支持(磁盘)	支持(磁盘)
多语言支持	支持	支持	很少	支持
社区活跃度	高	高	高	高
支持协议	多(JMS、AMQP、、、)	多(AMQP、PMQ、、、)	自定义协议	自定义协议
开发语言	java	erlang	java	scala
分布式事务	支持	不支持	支持	支持
消息积压	支持	影响性能	支持	支持
延时消息	支持	不支持	支持	不支持
消息查询	支持	不支持	支持	不支持
优缺点	优点: 成熟 缺点: 性能较弱	优点: 性能较好,管理界面较丰富,有多个语言的成熟客户端 缺点: 内部机制很难了解,也意味着很难定制和掌控. 集群不支持动态扩展	优点: 模型简单接口易用. 在阿里有大规模应用. 分布式系统,性能很好,版本更新快 缺点: 支持的语言较少	优点: 天生分布式,性能最好,常见用于大数据领域. 缺点: 运维难度大,对Zookeeper强依赖,多副本机制下对带宽有一定的要求.

二, MQ遇到几百万消息持续积压怎么解决?

临时扩容. 一般消息积压是因为消费者端出现了故障导致未能及时消费消息,可以通过临时扩容MQ以及消费者端的方式将积压的消息迅速处理完,等到消息消费差不多后,在回滚到原有架构.

三, 如何解决MQ中消息丢失与消息重复问题?

消息丢失一般有三种情况:

1, 生产者端发送消息到MQ过程

重试机制. 如重试三次,这种方式可以降低消息丢失的概率,同时将消息发送成功的状态记录下来.

2, MQ服务器端消息丢失

采用多主多从+同步复制与异步刷盘的架构. 即采用集群架构+持久化消息机制

3, 消费者端消费消息失败

重试机制+死信队列.如重试15次,这种方式可以降低消息丢失的概率,同时将消息消费成功的状态记录下来. 如果一直消费失败,则将消息丢到死信队列中,然后通过人工来进行手动处理.

消息重复一般有两种情况:

1, 生产者端重复发送消息

增加一张去重复表,将某个业务唯一性ID字段作为主键约束,当发送消息时,如果发现去重复表已经存在数据了则不再进行发送,从而保证幂等性.

2, 消费者端重复消费消息

增加一张去重复表,将某个业务唯一性ID字段作为主键约束,当消费消息时,如果发现去重复表已经存在数据了则不再进行消费从而保证幂等性.