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字段作为主键约束,当消费消息时,如果发现去重复表已经存在数据了则不再进行消费从而保证幂等性.