识别复杂度¶

备注

首先就要分析系统的复杂性。只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向；否则，如果对系统的复杂性判断错误，即使后续的架构设计方案再完美再先进，都是南辕北辙，做的越好，错的越多、越离谱。

实际上大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误，即使真的认为要同时满足这三方面的要求，也必须要进行优先级排序。

备注

将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。

识别复杂度对架构师来说是一项挑战，因为原始的需求中并没有哪个地方会明确地说明复杂度在哪里，需要架构师在理解需求的基础上进行分析。有经验的架构师可能一看需求就知道复杂度大概在哪里；如果经验不足，那只能采取 “排查法”，从不同的角度逐一进行分析。

识别复杂度实战¶

示例:

“微博”实例

这个系统是否需要高性能:

实例:
  每天发送 1000 万条微博，假设平均一条消息有 10 个子系统读取，那么其他子系统读取的消息大约是 1 亿次。

对于架构师来说，关注的不是一天的数据，而是 1 秒的数据，即 TPS 和 QPS。
如:
一天内平均每秒写入消息数为 115 条，每秒读取的消息数是 1150 条；
再考虑系统的读写并不是完全平均的，设计的目标应该以峰值来计算。峰值一般取平均值的 3 倍，那么:
  消息队列系统的 TPS 是 345，QPS 是 3450，这个量级的数据意味着并不要求高性能。

考虑到业务会增长，因此系统设计需要考虑一定的性能余量
我们将设计目标设定为峰值的 4 倍，因此最终的性能要求是:
  TPS 为 1380，QPS 为 13800
  TPS 为 1380 并不高，但 QPS 为 13800 已经比较高了，因此高性能读取是复杂度之一

这个系统是否需要高可用性:

对于微博子系统来说，如果消息丢了，导致没有审核，然后触犯了国家法律法规，则是非常严重的事情；
对于等级子系统来说，如果用户达到相应等级后，系统没有给他奖品和专属服务，
    则 VIP 用户会很不满意，导致用户流失从而损失收入，
    虽然也比较关键，但没有审核子系统丢消息那么严重。

综合来看，消息队列需要高可用性，包括消息写入、消息存储、消息读取都需要保证高可用性。

这个系统是否需要高可扩展性:

对「消息队列」来说不需要考虑可扩展性

总结:

综合分析下来，消息队列的复杂性主要体现在这几个方面：
高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。