高速数据处理 400万数据处理最低
- 从接收这个项目开始，了解数据报之间的内容解析，到跟同事后面解决一部分的问题，到现在快一个月的时间了，这段时间一直没有写东西，感觉自己已经飘了起来，但是这一段时间 是给了自己很大的巴掌，需要学习的东西太多了。下面就为这一段时间做个总结。让自己回顾下。
- 从接收项目来看 首先自己分配是数据解析，数据报解析原先没有接触过，而且在大数据处理上 也是了解的不多，导致了在解析的时候还是按照原先的思路进行开发,接下来是几个的问题汇总。
- 创建对象过多导致gc缓慢
- 这个数量级刚开始是200万的数据量，没有达到400.每秒的速度。我原先的思路是根据文档我写了多个对象进行编程， 消息头，中间消息体，消息体基本为三部分，但是消息体里面还有 其他消息内容需要进行剥离 。但是也需要提前解决掉。我们 的数据都是byte 数据 解析是按照字节 进行解析。
- 我第一个思路是 把消息头 消息体都转为对象，然后转换的时候 方便数据解析，然后再把byte数据进行转成json .方便数据利用。 在这里开始我就思路错误了，因为我们数据量每秒需要处理的几百万。java虚拟的gc 需要消耗很多时间，这样的话我们需要的性能就会下降。再次基础上 为了性能 ，那么我们就利用基本对象来解决问题，而不是用包装对象了。byte 数据直接利用。我现在的理解是基础数据类型再方法中是存放再栈中不是存放在堆中 减少了 gc的压力 。当然我们选择这个方法是因为我们是二进制进行数据转换 。如果是其他方式的话那么我们这就不能用这种方式了。然后测试我们单线程解析能力一个1430的数据包 应该解析能力在10万左右。机器型号记不清了。但是这个是跟机器性能有关的。
- 我们在系统中使用了disruptor 这个队列，虽然这个队列是号称最好的高性能队列，但是在系统中，首先我们在测试中发现该单个性能测试能达到900万/s的速度 ，但是加上业务后。还有其中消费者能力跟不上的节奏，导致性能急剧下降。我们一直在加线程 后来发现，单生产者 加三个消费者的能力已经达到顶峰，再加消费者或者生产者 ，性能就提不上去了。那么我们一直以为是我们在disruptor 的使用方式不对。最后在换成其他java队列尝试后发现 是放队列的时候造成的性能损耗，虽然我们想的时候 这边队列放，那边取这样应该是不会有多大的性能损耗的，但是在我们每秒40万的数据包的发送下 ，系统只能撑住20万左右每秒的速度。并且我们还把linux系统中的缓存也增加。但是就是达不到我们需要的效果。最后请教了别的组同事，才明白队列在使用的时候入队和出队。没有我们想的性能损失很小的情况。性能损失是很强大的。我们一直都知缓存 。那么在程序中我们应该怎么用缓存。也知道批量提交，也知道线程池的东西，但是在我们自己写程序的时候还是没有应用到。我们最终在我们接收的程序中加了一个对象池的概念，就是创建了一个通用的容器，创建好对象byte[] 我们只加入就好 ，但是我们这个思路跟disruptor 里面的对象复用类似，但是没有他那个高级。每次加入容器中，然后达到一定的数量后，我们把这一批数据换成另外一个容器数据放到disruptor中。这样的话每次提交的数据就多了。而且减少的提交次数减少了争夺标志位的方式。最终我们现在整个流程已经能走通。当然最大性能还没有测试。这个思路挺好的。总结就是 复用对象，增加对象缓冲池的方式。但是我自己的一个疑问 是。我们自己怎么实现 类似disruptorf方式的对象复用。如果是创建java自带的队列的话 ，是不是也造成类似的队列性能的问题。但是线程池里面还是用的自带的队列来实现的。
- 需要根据书上的内容看下相关容器的知识总结写 。还有队列的信息。这样更好的方便自己在选择容器方面的使用。
