文本数据处理—结合mysql模拟实现消息队列

1、前言

对大文本数据的分割，结合mysql数据库，实现以mysql为队列的分布式数据处理服务。

---

2、业务场景

场景一：
每天需要处理100G左右的数据，对应请求约12亿，每次请求包含6~50条待处理的数据，每条数据处理时间约20ms。业务方要求每次请求处理时间不超过30ms，但是可以延迟处理内容。

场景二：
每天需要处理100G左右的数据，对应请求约12亿，这100G数据分布在如干大文件中，要求分布式服务读取这些文件内容，并给指的业务方发送请求，要求数据当天处理完。

---

3、实现

（1）当前

由于业务方要求返回时间不超过30ms，使用redis缓存请求数据并立刻返回业务方，后续从redis取出数据慢慢处理。

（2）问题

redis资源占用；服务器资源没有充分利用；redis可能出现问题，例如某些redis实例故障导致请求丢失等。

（3）改造

a、定时任务

最开始，业务方每小时产生一份几个G大小的文件，处理是将文件拆分为若干小文件，并将小文件的路径存入数据库，程序中启动定时任务每小时执行一次，定时任务每次去数据库获取有效的文件路径，并读取文件，读取文件后更新数据库，并删除文件。

b、消息队列

后来，业务方数据并不是每小时产生的，可能会有若干小时的时延，这样定时任务就没法满足要求了。将定时任务改成消息队列，每隔一段时间去请求数据库，看是否有可以读取的路径，如果有的话就处理，没有的话在尝试若干次后休眠一段时间，此时的数据库就相当于消息缓存区域。每小时或者若干小时产生的文件会作为消息通过脚本推送到数据库中。这样的话，任何时候有文件产生，都能够及时处理。

c、实时

由于每小时或若干小时产生的文件需要从HDFS获取下来，对文件进行拆分，作为消息推送给服务进行处理，这期间可能会导致数据的延时。考虑到数据的实时性，从业务方获取的大文本数据，会经过一个代理服务实时处理后，形成一条一条的请求，代理服务会将请求推送到消息队列，服务从消息队列获取请求直接处理就行。这样就减少了数据中间的处理过程，增加了数据的实时性。

---

4、总结

对于大量的文件处理，一般的情况是分而治之，将大文件切割为小文件，然后进行处理，但是这期间存在着时间的耗费，期望通过一种方式，将大文件的数据以消息的形式发布到某一个队列，服务从队列读取信息然后进行处理。但是，队列大小的配置和策略又是需要考虑的问题，大量的数据不停放入队列，业务代码是否能处理的完？如果处理不完怎么办？队列阻塞怎么？这些都是需要考虑的问题。正如一个问题开始，可能会牵扯到另一个问题的出现。凡事都要三思而后行，不断总结和进步。