标签：执行 记录 应该 alt 复杂 响应 之间 发送消息 流量控制
1、异步处理：
减少等待时间，更快的返回处理结果，提高系统性能以及更好的用户体验。
fe: 在一个秒杀系统中，可能需要如下几步：风险控制，锁定库存，生成订单，消息通知以及统计数据，在未优化的情况下，用户请求到达网关后进入服务端要至少
经历这五个步骤，但是对于秒杀系统而言关键的步骤在于风险控制和锁定库存 后用户的秒杀已经完成，所以后续的生成订单，消息通知，统计数据，这些不影响主要业务
流程的操作我们可以采用异步的方式，来更快的处理用户请求，从而也是服务器端可以更多的处理秒杀请求。
2、流量控制（削峰填谷）：
当海量请求到服务器端时会压垮服务器，所以此时可以使用消息队列。
fe：首先流程是这样的：请求->网关->服务端，当海量请求达到网关（软硬件负载均衡：软件负载均衡nginx,支持十万级并发；硬件负载均衡f5，支持百万级并发）后，
所有的请求到达服务端，会压垮服务端，所以在网关和服务器端加一中间过程：消息队列。所有请求入队列，此时不需要担心 消息队列的存储能力，当硬盘容量足够时，可
无限存储，之后服务器端根据自己的消费能力去消息队列中获取请求进行处理，达到保护后台服务的作用。
fe:流量控制可以采用令牌桶的形式，有令牌生成器，根据规定流量生成指定数量令牌，服务器端获取请求时，首先获取令牌，拿到令牌后放开处理请求，没有令牌则
不能进行请求处理
当然在做优化时也会有相应代价：调用链增长，增加响应时间；同步请求改为异步请求，增加了系统的复杂度。 凡是有利便有弊，权衡项目所需。
3、服务解耦
在当下微服务横行的时代，脱离的单体应用，一个项目会根据不同的粒度拆分为几十个甚至几百个项目，当从几个到几十个再到几百个时复杂度是以直线上升的，各系统之间
的互相调用，在系统类图中可以看见密密麻麻的连线，项目耦合在一起，所以此时可以使用消息队列进行解耦。而且当下游服务发生变化时，所有调用的上游服务都会发生变化，这个是
不允许的，所以在应用过程中，可以采用消息队列
4、分布式事务
通过消息中间件，来保证分布式事物的最终一致性。这是一种比较提倡的解决方案，有利于服务之间解耦，虽然是异步的，但基本上事物也是即时性的。
fe:将业务A的提交操作和发送消息的记录 写在同一个事物中(把消息发送记录在本地库中)，然后业务B接收到消息之后进行相应的操作，成功后，向A发送成功通知。失败则通知A，进行回滚。 当A中的消息发送不成功的时候，则会通过定时任务轮训来进行发送，从而保证消息最终肯定可以到达B。 但是当A接收到B的成功通知后 应该删除消息记录或者修改记录状态，但是突然A挂掉了，A就没有及时修改本地消息记录，导致定时轮训的时候会重发，如果此时B中业务不是幂等的则会出现问题，所以如何避免这种消息重发呢？ 在B方也对消息进行记录，当A中发送过来消息后，B判断消息是否执行过，来避免这种问题
5、发布/订阅者模式
标签：执行 记录 应该 alt 复杂 响应 之间 发送消息 流量控制
原文地址：https://www.cnblogs.com/volare/p/12255103.html
