dubbo和mq的使用场景

dubbo

1，rpc的分布式集群支持：负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机的形式来分摊压力，挂一台补一台
2，结合zookeeper解藕：(提供者注册和消费者订阅)客户端和服务端启动的时候都会把自己的机器IP注册到zookeeper上。客户端会把zk上的服务端ip拉到磁盘上，并记录哪些ip提供哪些服务（服务端启动的时候暴露给zk）。
   然后调用的时候客户端会根据ip调用服务端的服务，这时候即使zk挂掉也没关系。
3：长连接通讯：nio通信抽象封装（暂时没接触）

可用场景：
1，商城做活动流量暴涨：防止系统崩掉 可以通过dubbo来控制访问量
2，分布式服务器rpc过程调用压力分担



mq的问题的起源：

对分布式系统研究的 CAP定律    分布式事务有强一致，弱一致，和最终一致性  只能同时满足2点，三者不能兼得

比如有订单，库存两个数据，一个下单过程简化为，加一个订单，减一个库存。 而订单和库存是独立的服务，那怎么保证数据一致性

保证两个远程调用“同时成功”，数据一致 当然失败和超时都有可能 ，一般的解决方案，大多数的做法是借助mq来做最终一致



mq一个点对点一个是分布式订阅：

mq的2个好处是：
1，消息不丢失：服务之间端掉消息会保存到mq中间件中，当消费者服务器恢复后就会重新发过去，消息不会丢失
2，异步处理：比如一个商城用户购买产品后后台会去更新数据库然后响应给客户端，如果在高并发的情况下，
这样更新数据库响应客户端会变慢，可以使用mq消息队列的消费者进程中获取数据来进行异步写数据，由于消息对垒的服务处理速度远快于数据库，
因此响应延迟能得到有效改善