同步调用有哪些问题？异步通讯有哪些好处？什么是事件驱动设计？异步通讯的设计重点有哪些？幂等性设计是什么？
打卡Day11：今天学习了《43｜弹力设计篇之“异步通讯设计”》和《44｜弹力设计篇之“幂等性设计”》，我的收获如下：
通讯一般分同步和异步。同步通讯就像打电话，需要实时响应，而异步通讯就像发邮件，不需要马上回复。
同步调用的问题
- 需要被调用方的吞吐不低于调用方的吞吐（整个同步调用链的性能会由最慢的那个服务所决定）；
- 调用方一直在等待被调用方完成（并发较高场景极度消耗资源）；
- 只能是一对一的，很难做到一对多；被调用方有问题，其调用方跟着出问题（多米诺骨牌效应）。
异步通讯的好处
增加系统的吞吐量，让服务间的解耦更为彻底，让系统的调用方和被调用方按照自己的速率来处理，系统更有弹力。
异步通讯的方式
- 请求响应式。直接请求接收方，异步回调；
- 直接订阅式。接收方向发送方订阅事件，从消息队列获取请求，无状态只依赖事件；
- 中间人Broker订阅式。接收方向Broker订阅消息，发送方向Broker发送消息，互相看不到对方。
事件驱动设计
订阅式和Broker都是事件驱动架构（EDA – Event Driven Architecture），Broker更优。
Broker需要的特性
- 高可用
- 高性能
- 可以水平扩展
- 数据持久化。
事件驱动方式的好处
- 服务间无依赖，服务可重用或被替换；
- 服务的开发、测试、运维高度隔离；
- 服务间不会相互阻塞block；
- 更容易增加Adapter。日志、认证、版本、限流、降级、熔断等；
- 服务间的吞吐更大，可以按照自己速度来处理。
事件驱动方式的缺点
- 架构变复杂，需要可视化工具呈现整体业务流程；
- 事件可能乱序，需要管理好状态机；
- 事务处理变复杂，要么两阶段提交做强一致性，要么退缩到最终一致性。
异步通讯的设计重点
- Broker高可用。
- 服务消息跟踪机制。
- 业务状态总控如银行的对账程序。
- 幂等处理。
幂等性设计
一次和多次请求某一个资源应该具有同样的副作用。
用数学的语言来表达就是：f(x) = f(f(x))。
服务调用的结果：成功（Success），失败（Failed），超时（Timeout）。
超时原因包括：请求没有到，请求到了返回结果没有正常返回。超时是完全不知道是什么状态，所以需要解决，手段包括：查询调用结果；被调用服务实现幂等性。
分布式系统实现幂等性，需要实现全局ID，来标志交易是同一笔交易。如Twitter的 Snowflake。
幂等性接口的处理流程
收到交易请求时，到存储中去查询。如果查找到了，就把上次做的结果返回。如果没有查到，那么我们就记录下来。
HTTP的幂等性
GET/HEAD/OPTIONS/DELETE/PUT满足幂等，POST不满足幂等。