spark streaming 流式计算---跨batch连接池共享（JVM共享连接池）

在流式计算过程中，难免会连接第三方存储平台（redis,mysql...)。在操作过程中，大部分情况是在foreachPartition/mapPartition算子中做连接操作。每一个分区只需要连接一次第三方存储平台就可以了。假如，当前streaming有100分区，当前流式计算宫分配了20个cpu，有4个cpu负责接收数据。那么，在一个批次中一共需要对第三方平台创建100次连接，同时最大并行连接第三方平台个数20-4=16个。假如30s一个批次，一天就需要频繁释放连接24*60*60/2=43200次，假如每次创建连接和释放连接总共需要100ms,那么一天中有43200/10/60/60=4.8h的cpu时间在做创建连接和释放连接操作。这个消耗还是比较大的。

那个，该如何优化这个问题？

大家可以这样想一下：既然每一个executor就是一个JVM进程。那么，流式计算每一个批次结束，会销毁执行任务的executor吗？答案显然不会！ 既然executor不会被销毁，在executor(JVM）中保持一个连接池达到连接池共享就有了可能。其次，一个executor可能会分配多于一个cpu core的情况，在执行前期，每一个executor(JVM)会同时执行多于一个的task。每一个task都需要一个连接。那么在executor中保持一个连接池，不仅可以达到跨batch的连接池共享，而且还可以达到同一个批次，被分到同一个executor(JVM）的任务的连接池共享。这样的优化可以大大减少，因为频繁连接第三方存储平台的压力，其次还可以节省频繁创建连接所消耗的时间。缺点就是，连接不释放，第三方平台需要更高的内存，才能提供更高的连接要求。

问题已经清楚，解决方案也出来了。该怎么编程，才能实现executor持有全局连接池？

别告诉我说你会在driver端创建好连接，然后通过广播将连接广播到executor中。因为大部分连接类在实现过程没有考虑序列化的问题（实现Externalizable或Serializable接口），所以无法将连接池广播。即使能够广播，这个方式在获取连接时也会遇到千奇百怪的错误。