一步步搭建分布式----消息队列activeMQ

activeMMQ是基于jms（java message service----消息中间件）

传统服务是串联的，用了消息中间件，可将服务并行化

rabbitMq用的是AMQP—它是c++写的，通用性比较强

kafaka----处理大数据的日志–是大数据的mq，集群性好，会出现消息重复，无法保证发送顺序等

redis—利用list实现mq，队列体积大时性能会急剧下降，业务简单/数据量不大时可使用它做mq

http是应用对外提供服务的，tcp一般是集群之间通信用的比较多

tomcat/

传递和发送消息—传输的要求很高，要求很快传输，消息不能有滞后性—tcp-----MQ，它不需要解析页面，他是低级协议

http-----tomcat/elesearch/nginx—与用户的ui交互，安全性越高越好，–他是高级协议

小的负载均衡mq层----消息分发的实例—类似springmvc里的handermapping

队列模式/话题模式（又叫订阅者模式）

与spring整合的通用步骤—先写工厂实例，再写配置文件，然后spring容器，把某个东西加载出来。tcp是单次连接（request，response就结束了），不需要建立工厂，池之类，但他也可以建立自己的连接工厂和连接池

connnecttion和session的区别是什么

a--------b建立连接，这条高速路就是connection，其中的某一次运输就叫session。session的一次提交相当于connection的一次任务，session的crud是运输的事务

消息持久化： 老板将消息写到小黑板上，即使当时无人，但后面有人看到了就能收到消息。
非持久化：老板在办公室里以说话的方式发送了一条消息。当时在场有人则他们能收到消息，可以去执行消息。后来的人不能收到这条消息。如果当场没有人，这条消息也不会被收到和被执行

集群是一样的东西—同一个项目部署到不同的机器上就叫集群（集群—=》负载均衡—》高并发这是一个整体）

分布式是不一样的东西–把一个项目切成若干块，然后部署到不同的机器上（服务是以集群形式存在的）

支付订单是典型的—队列模式的消息（支付发消息----订单发消息—通知库存）–只能消费一次，干的活是一样的

登录属于话题模式。–登录成功的消息一经发出----支付/订单/库存/日志 就并驾齐驱的开始执行任务。能消费多次，干的活是不一样的

被消费的消息（pending message），入队消息（meq），出队消息（mdq），消息名称，消费者（消息执行者NOC）

消费端是一个监听器（他是客户端从服务端拉下来的，他是不断尝试从服务端取数据），而非推送（不是服务端主动推送给客户端i）。监听器是实时运行的。基于消息队列的补偿性行为分布式事务

消息阻塞：服务器上消息过多，导致服务器上消息处理不过来。。。。。
一万多个学生报名。但只有一个老师消费消息。有的消息以被消费，在出队的时候，有没来得及清理。报完名的还不走，等在那，一个老师无法处理的过来，后来的同学就消息阻塞了

将一部分呢消息隔离，或者优化消息清理机制。消息只能被消费一次。我还设置了 消息的持久化。轮询机制

• 现在我发出了3条消息，但是由于今天是周末，所以没人来消费消息。
  

• 周一员工开始上班了。消息被执行
  

• 阻塞：比如现在有10000条消息，但只有2个消费者，且每个消费者每秒只能消费2000条消息，现在如果又来了2000条消息，则他们就会出现消息阻塞，阻塞时间应该是3秒钟。

话题模式

它的消息默认是不持久化的。消费者没启动，话题已发出5条，那么这5条因为没有持久化，所以就丢掉了，永远不会被执行。
有消息在队里，有人执行完，消息就出队了，如果后面的消费者到队列中发现没有这条消息 了，它就跳过就好了。好比老板把消息写在了黑板上，只要有人来看到了，就执行消息，然后把黑板上的消息擦掉（或者打上标记：有人以去做），那么后面的人看到后就不做处理（或者压根就没有看到）。
没有办法标记哪个consumer消费了。a的消费和b的消费之间没有关系。消息发出，听到或看到的人就都有权力去消费。没听到的就算了。1年前的，你发现了，你是执行还是不执行

mq和spring整合

mq可以保证数据同步，实现服务的并行处理。

分布式事务

分布式下如何保证这一系列事务（对数据库的crud）（订单—>支付—>库存---->其他）合成的分布式事务的原子性。要么（订单—>支付—>库存---->其他）都成功，要么都失败。

保证分布式事务的有
xa协议（tcc----try confirm cancle）
基于消息的最终一致性。（最常用，性能效率都由于其他方式）

不求同年同日升，但求同你同日死（分布式环境下，有些服务并发处理，不同服务的不同数据结构在一个业务中，大家（分布式环境下，在支付这个业务中，订单—>支付—>库存这些事务）可以同时提交或者回滚）

消息的持久化和非持久化

消息持久化： 老板将消息写到小黑板上，即使当时无人，但后面有人看到了就能收到消息。
非持久化：老板在办公室里以说话的方式发送了一条消息。当时在场有人则他们能收到消息，可以去执行消息。后来的人不能收到这条消息。如果当场没有人，这条消息也不会被收到和被执行

安装和启动

Linux安装和使用ActiveMQ

使用

Broker----小的消息的负载均衡（消息分发的实例）

一个链接（允许同行，高速路）可创建多个session，一个session（货车）可执行多个业务（货物）。

什么是消息阻塞，服务器上的消息过多，并且消息清理出现问题，导致消息队列服务器出现了没办法顺利消费情况。平常1台服务器就可流畅处理，结果遇上搞活动，流量爆炸，好比一个门，5个人出去，整么都不会拥挤，可是100人就出现拥挤，可能画1天时间这些人由于拥挤都不能出门，好比高速路，正常从重庆到遵义，客车只需3小时，可遇上过年客运高峰期，高速路堵塞了。结果5小时才回到家（消息消费完清理消息也需要时间，）----解决：多增加consumer消费端，消费的过期时间设置短一点，规定时间没处理完消息就进入死性队列（diemessage），设置消息的清理机制

话题模式默认在服务器上不持久化（不能持久化-------通过监听不知道有多少人链接你，所以谁处理了消息无法做标记。无法记录消费这件事。A做完这件事，b，c都还可以再做一遍，一件事可以被重复做多次）（不知道多少人消费了消息）
队列模式默认在服务器上持久化（有人消费，这件事情就结束了。10个人在队列中准备搬运，包工头抓阄，抓到谁，谁来做。类似抢购。一件事只能被做一次）

话题模式用的较少。即使开会时我不在现场，但是我仍然会执行会议精神

解决并发：有些服务不是单个服务器就能解决的
（用消息队列实现服务的并行处理）
解决：下单成功，但库存没有（所以可做数据同步）修改商品数据，既要es，也要redis（商品详情和商品搜索）。服务有各自独立运行，用mq比较好

订单消费支付

7次异常进入死信队列