Redis pub sub 缓存区的限制
对于Redis服务器的输出（也就是命令的返回值）来说，其大小通常是不可控制的。有可能一个简单的命令，能够产生体积庞大的返回数据。另外也有可能因为执行了太多命令，导致产生返回数据的速率超过了往客户端发送的速率，这是也会导致服务器堆积大量消息，从而导致输出缓冲区越来越大，占用过多内存，甚至导致系统崩溃。
所幸，Redis设置了一些保护机制来避免这种情况的出现，不同类型的客户端有不同的限制参数。限制方式有如下两种：
（1）、大小限制，当某一个客户端的缓冲区超过某一个大小值时，直接关闭这个客户端的连接；
（2）、持续性限制，当某一个客户端的缓冲区持续一段时间占用过大空间时，会直接关闭客户端连接。
我们来看看配置文件关于客户端输出缓冲区的配置：
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 8mb 2mb 60
所以在大数据量使用 pub sub 时候，很容易被限制。
我们的场景就是 一个 行情客户端，使用了 pub/sub 功能，在flink source 中订阅了 行情，结果收到很少的数据。
就是因为超过了 buffer 限制。修改限制之后
client-output-buffer-limit pubsub 0 0 0
就可以收到全部的数据，但是 flink 端 依旧无法完整的处理数据。
可能就是使用 redis 做 pub sub，还是有点问题。使用 分布式的kafka 可能会好一些。
flink 窗口 和状态
我们在flink 窗口中计算因子，一般 的windowFunction 会把所有的 数据缓存到 state 中，如果数据太大也会对性能有影响。
使用一些 reduce， aggreate 等 聚合函数，可以实现部分增量聚合，对性能的影响会稍微少一些。
性能的问题
使用python 的 Redis sub 我们发现，是完全可以处理 4000个股票3s 一次的 行情数据的。
可是使用flink 默认配置的时候，能够接受到的数据量大大减少？
这个问题从根源上还是没有想清楚？
配置了 parallelism.default =30 后，这种情况得到了很好的缓解。
taskSlot = 6 之后， 刚好有30个slot 可以做并行。 这种情况可以很好的缓解。
我的疑问是，为啥 redis 单个的节点就能做的事情， flink 之后反而需要多个节点来处理了？
做一下测试就知道:
本机， redis， 单机： java 2万/s 的吞吐
本机， flinl 单机： flink，不 collection 2万/s 的吞吐
本机， flinl 单机： flink，collection 2万/s 的吞吐
统一网络：单一机器：python 20万/s 的吞吐。
统一网络，单一机器， java 20 吞吐，没有任何区别。
统一网络, fink para =1， 吞吐就是起不来。
统一网络，flink 单机， 吞吐，20万/吞吐，完全没有问题
吞吐之类的程序应该 没什么问题的。
现在看下， snap 行情的每分钟的统计：
上海就是5万的吞吐。
加上 深证，每分钟要到10万，保险的是处理12万的吞吐。
为啥，用了集群之后，单个吞吐反而下降了那么多。
其实集群，上收到数据量也是一个吞吐，但是使用窗口之后。能够纳入到一个窗口中的就是另外算了。
如果16万的数据，通过一些算子之后，再到窗口中，那么时间是算哪个？
在ubuntu5上，读取的pub的速度和在ubuntu6上就有完全不同的差别。所以还是得分散。
5-7万的吞吐。还是万兆网络。
网友评论