Redis 定长队列的探索和实践

从技术的角度来说，技术方案的选型都是受限于实际的业务场景，都以解决实际业务场景为目标。,在我们的实际业务场景中，需要以游戏的维度收集和上报行为数据，考虑数据的量级，执行尽最大努力交付且允许数据的部分丢弃。,数据上报支持游戏的维度的批量上报，支持同一款游戏128个行为进行批量上报。,数据上报需要时效控制，上报的数据必须是上报时刻的前3分钟的数据。,整体数据的业务形态如下图所示：,,从业务的角度来说包含数据的收集和数据的上报，我们把数据的收集比作生产者，数据的上报比作消费者，是一个典型的生产消费模型。,生产消费模型在JVM进程内部通过队列+锁或者无锁的Disruptor来实现，在跨进程场景下通过MQ（RocketMQ/kafka）进行处理解耦。,但是细化到具体业务场景来看，消息的消费有诸多限制，包括： 游戏维度的批量行为上报，行为上报的时效限制，细化到各个技术方案选型进行对比。,使用RocketMQ 或者Kafaka等消息队列来存储上报的消息，但是消费侧需要考虑在业务进程中按照游戏维度进行聚合，其中技术细节涉及按照游戏维度进行拆分，在满足消息时效性和批量性的前提下触发上报。在这种方案下消息中间件扮演的角色本质上消息的中转站， 没有解决任何业务场景中提及的游戏维度拆分、批量性和时效性。,在方案一的基础上，寻求一种技术方案来解决游戏维度的 消息分组、批量消费 、时效性 。通过Redis的list结构来实现队列（进一步要求实现定长队列）来解决游戏维度的消息分组；通过Redis的list支持的Lrange来实现批量消费；通过业务侧的多线程来解决时效问题，针对高频的游戏使用单独的线程池进行处理，上述两个手段能够保证消费速度大于生产速度。,对比两种方案后决定使用Redis的实现了一个伪消息中间件：,整体的技术方案如下图所示：,,步骤一：游戏维度的某行为数据PUSH到游戏维度的队列当中。,步骤二：判断游戏是否在游戏的集合Set中，如果在就直接返回，如果不在进行步骤三。,步骤三：往游戏列表中PUSH游戏。,步骤一：从游戏对象的列表中循环取出一款游戏。,步骤二：通过步骤一获取的游戏对象去该游戏对象的行为数据队列中批量获取数据处理。,在Redis的支持命令中，在List和Set的基础命令，结合Lua脚本来实现整个技术方案。,消息数据层面，通过单独的List循环维护待消费的游戏维度的数据，每个游戏维度使用定长的List来保存消息。,消息生产过程中，通过结合List的llen+lpop+rpush来实现游戏维度的定长队列，保证队列的长度可控。,消息消费过程中，通过结合List的lrange+ltrim来实现游戏维度的消息的批量消费。,在整个执行的复杂度层面，需要保证时间复杂度在0(N)常量维度，保证时间可控。,Redis采用相同的Lua解释器去运行所有命令，我们可以保证，脚本的执行是原子性的。作用就类似于加了MULTI/EXEC。,,,,,,在描述完方案的原理和实现细节之后，进一步对适用的业务场景进行下总结。整体方案是基于redis的基本数据结构构建一个伪消息队列，用以解决 消息的单个生产批量消费 的场景，通过多key形式实现消息队列的多Topic模式，重要的是能够借助于redis的原生能力在O(N)的时间复杂度完成批量消费。另外该方案也可以降级作为实现先进先出定长的日志队列。,本文主要探索在特定业务场景下通过Redis的原生命令实现类MQ的功能，创新式的通过Lua脚本组合Redis的List的基础命令，实现了消息的分组，消息的定长队列，消息的批量消费功能；整体解决方案在线上环境落地并平稳运行，为特定场景提供了一种通用的解决方案。