1. 同步和异步
同步和异步描述的是消息通信的机制。
同步
当一个request发送出去以后，会得到一个response，这整个过程就是一个同步调用的过程。哪怕response为空，或者response的返回特别快，但是针对这一次请求而言就是一个同步的调用。
异步
当一个request发送出去以后，没有得到想要的response，而是通过后面的callback、状态或者通知的方式获得结果。可以这么理解，对于异步请求分两步：
1）调用方发送request没有返回对应的response（可能是一个空的response）；
2）服务提供方将response处理完成以后通过callback的方式通知调用方。
对于1）而言是同步操作（调用方请求服务方），对于2）而言也是同步操作（服务方回掉调用方）。从请求的目的（调用方发送一个request，希望获得对应的response）来看，这两个步骤拆分开来没有任何意义，需要结合起来看，而这整个过程就是一次异步请求。异步请求有一个最典型的特点：需要callback、状态或者通知的方式来告知调用方结果。
2. 阻塞和非阻塞
阻塞和非阻塞描述的是程序在等待调用结果（消息，返回值）时的状态。
阻塞
阻塞调用是指调用方发出request的线程因为某种原因（如：等待系统资源）被服务方挂起，当服务方得到response后就唤醒挂起线程，并将response返回给调用方。
非阻塞
非阻塞调用是指调用方发出request的线程在没有等到结果时不会被挂起，直到得到response后才返回。
阻塞和非阻塞最大的区别就是看调用方线程是否会被挂起。
3. 同步、异步、阻塞和非阻塞IO
针对Sender而言，请求发送出去以后，一直等到Receiver有结果了才返回，这是同步。在Sender获取结果的期间一直被block住了，也就是在此期间Sender不能处理其它事情，这是阻塞。
场景：
有一天你饿了，想吃饭，但是你不会做，这时候你就跟你妈说：妈，我饿了，我要吃饭。然后你妈就去厨房做饭，你就在外面等着饭做好，啥也不干，这就是同步阻塞。（调用方阻塞不能干其他的事）
同步非阻塞IO
针对Sender而言，请求发送出去以后，立刻返回，然后再不停的发送请求，直到Receiver处理好结果后，最后一次发请求给Receiver才获得response。Sender一直在主动轮询，每一个请求都是同步的，整个过程也是同步的。在Sender等待Receiver的response期间一直是可以处理其它事情的（比如：可以发送请求询问结果），这是非阻塞。
场景：
有一天你饿了，想吃饭，但是你不会做，这时候你就跟你妈说：妈，我饿了，我要吃饭。然后你妈就去厨房做饭，你就在外面等着饭做好，啥也不干，这就是同步阻塞。（调用方阻塞不能干其他的事）
异步方式1
同样，有一天你饿了，想吃饭，但是你不会做，这时候你就跟你妈说：妈，我饿了，我要吃饭。然后你妈就去厨房做饭，然后你就去看电视了。你妈做好饭就给你说，宝，饭做好了，去厨房把饭端到餐桌上。（调用方啥也不管，等好了自己去拿结果）
4、异步方式2
同样，有一天你饿了，想吃饭，但是你不会做，这时候你就跟你妈说：妈，我饿了，我要吃饭。然后你妈就去厨房做饭，然后你就去看电视了。你妈做好饭就给你说，宝，饭做好了、快来吃，你直接去餐桌上吃饭就是了。（调用方啥也不管，结果已经放好了，直接去看结果就可以了）
异步方式2肯定是比异步方式1更好，但是Linux内核不支持，只能使用异步方式1，需要自己去拿结果。
针对Sender而言，请求发送出去以后，立刻返回，然后再等待Receiver的callback，最后再次请求获取response，这整个过程是异步。在Sender等待Receiver的callback期间一直被block住了，也就是在此期间Sender不能处理其它事情，这是阻塞。
异步非阻塞IO
针对Sender而言，请求发送出去以后，立刻返回，然后再等待Receiver的callback，最后再次请求获取response，这整个过程是异步。在Sender等待Receiver的callback期间一直是可以处理其它事情的，这是非阻塞。
总结
- 同步和异步就看调用方是否需要通过callback、通知或者状态来获取结果
- 阻塞和非阻塞就看调用方在发送请求后是否block住了
同步:发送一个请求,等待返回,然后再发送下一个请求
异步:发送一个请求,不等待返回,随时可以再发送下一个请求
同步可以避免出现死锁，读脏数据的发生，一般共享某一资源的时候用，如果每个人都有修改权限，同时修改一个文件，有可能使一个人读取另一个人已经删除的内容，就会出错，同步就会按顺序来修改。
异步则是可以提高效率了，现在cpu都是双核，四核，异步处理的话可以同时做多项工作，当然必须保证是可以并发处理的。
同步和异步最大的区别就在于。一个需要等待，一个不需要等待。
比如发短信，就是一个异步例子。发起者不关心接收者的状态。不需要等待接收者的返回信息，则可以进行下一次发送。
电话，就是一个同步例子。发起者需要等待接收者，接通电话后，通信才开始。需要等待接收者的返回信息
而我们平时经常讨论的同步问题多发生在多线程环境中的数据共享问题。即当多个线程需要访问同一个资源时，它们需要以某种顺序来确保该资源在某一特定时刻只能被一个线程所访问，如果使用异步，程序的运行结果将不可预料。因此，在这种情况下，就必须对数据进行同步，即限制只能有一个进程访问资源，其他线程必须等待。
实现同步的机制主要有临界区、互斥、信号量和事件
临界区：通过对多线程的串行化来访问公共资源或一段代码，速度快，适合控制数据访问。在任意时刻只允许一个线程对共享资源进行访问，如果有多个线程试图访问公共资 源，那么在有一个线程进入后，其他试图访问公共资源的线程将被挂起，并一直等到进入临界区的线程离开，临界区在被释放后，其他线程才可以抢占。
互斥量：采用互斥对象机制。 只有拥有互斥对象的线程才有访问公共资源的权限，因为互斥对象只有一个，所以能保证公共资源不会同时被多个线程访问。互斥不仅能实现同一应用程序的公共资源安全共享，还能实现不同应用程序的公共资源安全共享 .互斥量比临界区复杂。因为使用互斥不仅仅能够在同一应用程序不同线程中实现资源的安全共享，而且可以在不同应用程序的线程之间实现对资源的安全共享。
信号量：它允许多个线程在同一时刻访问同一资源，但是需要限制在同一时刻访问此资源的最大线程数目 。信号量对象对线程的同步方式与前面几种方法不同，信号允许多个线程同时使用共享资源，这与操作系统中的PV操作相同。它指出了同时访问共享资源的线程最大数目。它允许多个线程在同一时刻访问同一资源，但是需要限制在同一时刻访问此资源的最大线程数目。
事件：通过通知操作的方式来保持线程的同步，还可以方便实现对多个线程的优先级比较的操作 。
应用场景
异步的使用场景：
1、不涉及共享资源，或对共享资源只读，即非互斥操作
2、没有时序上的严格关系
3、不需要原子操作，或可以通过其他方式控制原子性
4、常用于IO操作等耗时操作，因为比较影响客户体验和使用性能
5、不影响主线程逻辑
同步的使用场景：不使用异步的时候
同步的好处：
1、同步流程对结果处理通常更为简单，可以就近处理。
2、同步流程对结果的处理始终和前文保持在一个上下文内。
3、同步流程可以很容易捕获、处理异常。
4、同步流程是最天然的控制过程顺序执行的方式。
异步的好处：
1、异步流程可以立即给调用方返回初步的结果。
2、异步流程可以延迟给调用方最终的结果数据，在此期间可以做更多额外的工作，例如结果记录等等。
3、异步流程在执行的过程中，可以释放占用的线程等资源，避免阻塞，等到结果产生再重新获取线程处理。
4、异步流程可以等多次调用的结果出来后，再统一返回一次结果集合，提高响应效率
---------------------
典型的用户场景
在公众号的运营过程中，典型的事件包括：
- 发送短信验证码
- 购买成功或者抽奖成功短信通知
- 卡券或优惠券发放
- 发放微信红包
- 微信消息通知
- 订单流程处理
- 定时批处理（比如数据同步）
- 工作流性质的异步任务（未完成异步任务补偿）
面详细说明不同场景能够异步的原因：
- 不同场景（用户注册，用户购买产品等）下的短信验证码发送，可以使用异步方式发送： 一方面是因为客户这个时效性要求没有那样高，另一方面在特定时间范围内用户没有收到验证码，用户可以点击再次发送验证码。
- 购买成功或者抽奖成功后短信或者邮件通知，可以通过异步的方式进行。 因为涉及用户的利益，要谨慎对待。一方面一定要把数据先存到数据库或者日志里面（注意信息安全^-^,别存敏感明文信息或者加密存储），然后再放入到异步队列中执行。
另一个方面，要考虑到应用服务意外停止时，没有发送成功数据的补偿机制。 这种情况不常见，并且为了减少耦合和当前异步程序的复杂度。我们使用单独的服务上部署异步任务补偿程序，来扫描未完成的任务，并且进行重放（一定要注意严谨性）。 - 优惠券和卡券的发放，跟购买成功或抽奖成功的方式类似。\u000b可以在当前活动高峰后延时发放，并且使用异步的方式进行。
- 微信红包，因为需要跟微信进行交互，并且微信会通知客户红包的情况，可以使用异步的方式进行。 当涉及资金或者礼品时，一定要谨慎对待设计，并且需要有方便进行异步任务停止和启动的功能。
- 微信消息通知，因为跟微信进行交互，成功后微信进行通知，可以使用异步。 这个跟短信验证码类似。
- 订单流程处理，可以使用异步，因为涉及到后续步骤可以使用简单工作流来完成。有几个开源的框架可以参考。
- 数据同步或者异步任务补偿，因为是延时处理，可以使用异步进行处理。在使用时，可以配合定时任务，比如cron4j来周期性的进行补偿。适合后面总-分-总的任务处理模式。
使用异步后的烦恼
烦恼一： 数据丢失的风险
解决方式：先写日志或数据库，后放入异步队列.
烦恼二：对其他系统的压力变大
解决方式：使用一定的限流和熔断，对其他系统进行保护。
烦恼三：数据保存后异步任务未执行
解决方式：使用异步任务补偿的方式，定期从数据库中获取数据，放到队列中进行执行，执行后更新数据状态位。
烦恼四：怎样队列长设置和消费者数量
解决方式：使用实际的压力测试来获得队列长度。或者使用排队论的数学公式得到初步的值,然后进行实际压测。
最后介绍一下项目中的经验：
- 量力而行：根据业务特点进行技术选型，业务量小尽量避免使用异步。有所为，有所不为
- 数据说话：异步时一定要进行必要的压力测试
- 先找出系统的关键点：优化单体系统内的性能，再通过整体系统分解来全局优化
- 根据团队和项目的特点选择框架。
