关于Storm实时往HBase存数据的性能优化

在开发中根据业务逻辑，需要存储在Storm中每个Spout和Bolt中产生的数据到HBase表中。在程序调优的过程中不断调整和优化了几种方案。

---

1.直接在每个Spout和Bolt中连接HBase存放数据

这是首先考虑和测试的选择，也是最先放弃的选择，短时多次建立连接会造成资源的浪费和排队，存储的时间的过长也会影响Topology流的稳定性和实时性。

8.16补充：

后期实时性要求降低，HBase调优后性能提高，采用这种方法的稳定性大大提高，并通过生产环境的测试。

---

2.直接在每个Spout和Bolt中数据发送到Kafka，再从外部程序拉取数据并存储

Kafka的性能和消息队列的特性非常适合这种短时大吞吐量的应用场景，短时性能也能满足需求。

但是！一个Topology中几百个节点，每个节点一个生产者，进而导致资源的巨大消耗甚至资源耗尽问题。

---

3.使用Redis的发布订阅模式，再从Topology末尾发到Kafka，再从外部程序拉取数据并存储

这个时候又想到了做缓存的Redis，这次尝试了一下订阅发布模式，在每个Spout和Bolt中发布数据，在Topology末尾订阅数据，channel能非常好满足性能要求，而且接受的顺序也有一定保证。

但是！开启发布端到开启订阅端这段时间会丢数据，其他多种情况也会导致数据的丢失，数据的安全性根本没有保证。

---

4使用Redis的List结构，再从Topology末尾发到Kafka，再从外部程序拉取数据并存储

这也是最终的解决方案，采用Redis List，在每个Spout和Bolt往每个队列通过rpush往表尾放数据。在Topology末尾发送数据，lpop删去并返回表头，发送失败后通过lpush再把数据返回表头。这样也能保证数据的安全性，且经过测试满足性能。

public void send(Jedis jedis, String topic, String key) {
    String msg = jedis.lpop(key);
    if(StringUtils.isNotBlank(msg)){
        try {
            sendMsg(topic,"",  msg);
        } catch (Exception e) {
            // 放回数据
            jedis.lpush(key,msg);
            LOGGER.warn("数据重放",e);
        }
    }
}

8.16补充

外部程序采用spark streaming拉取程序，但因为组件过多，集群负载增加，最后选择为备选方案