MQ ， 就是 消息队列（Message Queue），
不知从什么时候起， MQ 被用来 搭建 分布式 业务系统 架构， 一个重要作用 就是用来 “削峰” 。
我们 这里 就来 讨论 如何 设计 业务系统 来 应对 高并发， 不需要 MQ 。
应对 高并发， 很简单， 水平扩展 就可以 。 增加 服务器 数量 就可以 。
MQ 通常用来 分解 一个 用户 请求 中的 各项 子任务， 尤其 是 异步任务， 尤其是 需要 和 第三方 平台 交互 的 任务 。
比如 支付 业务 就是 一个 典型 的 场景 。
假设 我们 做一个 支付 相关 的 业务， 用户 的 一次 支付， 我们的 系统 可能 需要 和 微信（支付宝） 交互， 等待 回调 ， 等等 。
同时 还需要 处理 我们自己的 各种 业务 逻辑， 如果 业务逻辑 比较 庞大， 也可能 拆分 为 异步任务 进行 。
但 不管 是 削峰 还是 分解业务， 都不需要使用 MQ 。
我们 只 需要 用 进程内的 队列 （Queue） 和 多线程 就可以 很好 的 实现这些 。
削峰， 可以使用 进程内的 队列（Queue）， 简单的说， 比如 C# 的 System.Collection.Generics.Queue<T> ，
分解业务， 多个异步任务， 用 多线程 就可以 。
大家可能会问， 在 水平扩展（负载均衡） 和 情况下， Server 之间怎么通信， 怎么共享数据 ？
答案 是 一般情况 下 水平扩展 的 Server 之间 不需要 通信，
一个 用户 的 一个 请求， 在 一台 Server 内 就可以 完成， 不需要 和 其它 水平 Server 通信 。
这个 请求 如果分解为 多个 子任务， 在 一台 Server 内 开 多个线程 执行 就可以 。
同理， 对于 削峰， 我们使用 进程内的 队列（Queue） 就可以 ， 比如 ：
private static Queue<T> payQueue;
这行么 ？
水平 Server 之间的 通信 ， 或者说 共享数据， 可以通过 分布式缓存 （比如 Redis 什么的） 来实现，
我之前也说过， 分布式缓存 实际上是 Web 集群 的 共享内存 。
但从 简化 的 角度 来看， 一个 请求， 或者说 一个 业务， 通常 在 一台 Server 内 就可以 完成 。 如果需要 多任务， 就使用 多线程 。
如果 一个 业务 需要 多个 请求 才能 完成 ，
这种情况 就可能 跨 Server，
因为 负载均衡 的 话， 第一次 请求 在 Server 1， 第二次 请求 在 Server 2，
此时， 可以通过 分布式缓存 来 在 Server 之间 共享数据， 比如 保存 状态信息 。
第三点 是， 对于一个 庞大的业务， 可能采用了 削峰 多任务 等 复杂的架构， 那么， 如何 保证 这个架构 的 稳定性 和 透明性 ？
所谓 透明性 就是 开发人员 和 运维人员 对 这个 系统 里 发生了 什么 看的 很清楚， 出现问题 可以 清楚 的 知道 定位 追溯 解决 问题 。
要实现 透明性 ， 需要 在 代码 中 规范 和 适当 的 加入 Log 。
这样 可以 记录下来 每个 子任务 的 创建 执行 报错 结束 状况 。
在 分布式架构 下， 传统的 文件 Log 已经不能 适应， 需要 升级 为 数据库 Log（DB Log） 。
DB Log 的 优点 是 ：
1 支持 分布式架构， 各台 Server 的 Log 可以汇总到一起（数据库 ， 表）
2 便于 分析查询， 用 Sql 很容易 查询追溯， 以及 产出 报表 。
那 这个 DB Log （或者叫 分布式 Log ^^） ， 要怎么搞定 ？
其实 很简单， 我自己就写了一个， 可以看一下 ：
《SOALog》
今天说的这个 架构， 就是我之前说过的 “1 Binary n Deploy” 架构，
也是我之前说过的 “3.5 层架构” （在 传统 的 三层架构 上 加上 缓存层 叫做 3.5 层架构） 。
还有一点就是， 将 业务 分解 为 子任务 不一定能 提高效率 。
除了 要等待 第三方平台 回调， 或者 响应时间不确定 的 这类情况， 一般情况 分解为 子任务 效率 不一定高 。
因为 现在 高并发 是 常态，
在 高并发 下， CPU 实际上没有 多余的 资源（核） 来 执行 分解出来的 子任务 ， 反而还会 增加 线程间 通信 的 性能消耗 。
比如， 我们 的 CPU 假设 有 16 个 核， 要处理 每秒 1600 个 请求， 每个 核 要处理 每秒 100 个 请求，
把 请求 分解成 子任务 实际上 并不能 起到 “并行执行， 利用多核， 提升效率” 的 作用 。