前言
Storm是真的冷落了呀，上stack overflow上去寻求大佬帮助，终是石沉大海。不扯这些没用的。我们来大致总结一下 storm topology 优化的方法论。
我们在设计一个拓扑时，除了需确定拓扑的每个组件以及其需实现的功能外，还需要对拓扑结构进行调优，以期整个拓扑的效率够高。在尝试进行调用之前，我们先熟悉一下 Storm UI，因为 Storm UI 可以提供足够多的信息来支撑我们对拓扑进行优化，也就是说 Storm UI 实际可以作为我们调优的定位工具。
Storm UI 中主要包含了以下几个部分：
- Topology summary：拓扑概要，用于显示当前的状态、运行时间、工作节点数量、指派给拓扑的执行器和任务概要。
- Topology actions：拓扑相关执行动作，可以通过 UI 直接对拓扑执行平衡调整、停止等操作。
- Topology stats：拓扑状态，通过四个时间段来显示拓扑的概要信息。
- spouts：显示 spout 概要统计：执行器（线程）数量，任务数量，由该spout执行发射、应答和失败元组数量，与该 spout 相关的最近一次报错信息。
- bolt：显示 bolt 概要统计：执行器数量，任务数量，由该 bolt 执行发射、应答和失败元组数量，与延迟率相关指标，该bolt负荷，与该 bolt 相关的最近一次报错信息。
- Topology Configuration：拓扑配置，显示该拓扑上的所有配置选项 大致阐述了 Storm UI 上的相关信息字段，那么当有了工具后，我们该如何对拓扑进行调优呢？
调优步骤
一、确定服务等级协议
什么是服务等级协议呢？官方一点的解释为：
SLA服务等级协议（简称：SLA，全称：service level agreement）是在一定开销下为保障服务的性能和可靠性，服务提供商与用户间定义的一种双方认可的协定。
通俗的讲，就是我要达到怎样的程度。在调优中，我要将拓扑优化到什么程度。通常，SLA包含以下几个指标：
- 可用性：指的是系统服务能正常运行所占的比例。
例如我们说要搭建一个”100%“的系统服务，也就意味我们要需要保证在任何时候这个系统都能运行，都说可用的，但实际这在现实中，是非常困难的，成本也是非常的高。
对于大部分的系统而言，能保证4个9的可用性（99.99%的可用性）就可以说这个系统是高可用的。
99.99%的可用性是指一天（60×60×24秒），只有8.64秒（60×60×24×0.0001秒）为不可用，一年就是大概有52.56分钟（8.64*365/60分钟）不可用。一天只有8秒左右的不可能用时间，这已经可用满足大部分系统的要求了。
- 准确性：指的是我们所设计的系统服务中，是否允许某些数据是不准确或丢失，如果允许那么允许的百分比是多少？ 不同系统对准确率都会有一个衡量的指标，大部分系统可以用错误率来衡量。
错误率可由以下公式计算求的：
错误率 = 导致系统内部错误有效请求数 / 总的有效请求数
例如，系统在一分钟内收到的总的有效请求为100个，其中有10个导致系统内部错误，则我们可以认为错误率为10%
那我们可以通过哪些途径来获取系统的准确性呢？大部分情况我们可以通过软件测试或系统日志来判断。在 storm 中我们主要关注bolt的 acked 和 failed 指标。
- 系统容量
在数据处理中，系统容量通常指的是系统能够支持的预期负载量是多少，一般会以每秒请求数为单位来表示。
我们常常听见某个系统的架构可以处理的QPS（Queries Per Second 系统每秒查询数）是多少或者RPS（Requests Per Second系统每秒请求数）是多少。
而对于具体的 Storm 拓扑调优，个人认为应当着重关注 UI 上每个 bolt 的 Capacity 指标，Capacity即容量值，是以百分比的形式展显了时间窗口内该 bolt 花在执行元组的时间。这个值越接近1，说明该 bolt 工作量越饱和。
- 延迟（Latency）
延迟指的是系统在收到用户的请求到响应这个请求的时间间隔。
在定义延迟的SLA时，我们常常看到系统的SLA会有p95或者是p99这样的延迟声明。这里的p指的是percentile（也就是百分比的意思），假设一个p95的系统延迟是1秒，那就表示100个请求里面有95个请求的响应时间是少于1秒的，而剩下的5个大于1秒。
在进行拓扑调优时，相应的我们应关注每个 bolt 对应的 Executelatency 和 Processlatency 指标。
二、判断瓶颈
这一步主要是根据上面所说的系统容量指标来对拓扑结构进行优化，我们着重观察UI上每个bolt的 Capacity 指标，该指标值越接近1，则说明该 bolt 工作量越饱和，越有可能成为整个拓扑的瓶颈，这个时候就需要我们来增加该 bolt 的任务数量了，待调整后的拓扑在集群中运行10分钟以上后，继续在storm ui 上观测该bolt的 capacity 指标，再结合其他 bolt 的 capacity 指标进行进一步任务数量的调整。
三、控制数据流入拓扑的速率
这一步主要是通过控制 spout 的并行度和拓扑中每个 spout 的允许配置的最大云组数量来控制数据流入拓扑的速率，从而实现我们对SLA中QPS的需求。
四、优化延迟
延迟率主要与数据和外部因素有关，相应的优化主要依赖代码的优化以及外部服务的优化。
总结
总的来说，若我们需要对一个拓扑进行优化，首先，先确定优化目标（SLA）。其次，根据 storm ui 上的capacity指标优化拓扑中bolt的任务数量，以期拓扑效率更高。进一步的，通过调整 spout 的并行度和每个 spout 配置的最大云组数来控制数据流入拓扑的速率，以此实现对拓扑吞吐量的优化。最后若 bolt 上存在较大延迟，则需要具体分析导致延迟较大的原因以及可能的优化方法，再进一步的优化。
该博客仅为初学者自我学习的记录，粗浅之言，如有不对之处，恳请指正。
