一个中间层的思考

最近工作中遇到了一个有趣的场景，讨论怎么设计一个中间层。背景是这样的，有一个Java服务（客户端），用到了自研大模型（服务端）的调用，而这个Java程序和三个大模型在一台服务器上跑着，在正常数据量的情况下服务器倒也没什么问题，凡事都有二八定律，面对特定大数据量时，并行下调用大模型服务器有点吃不消，考虑在客户端和服务端加一层服务，将客户端的请求串行化，就是客户端多个请求进入队列排队等待，服务端一条一条的消化队列中的任务。

因为要做到对客户端和服务端现有调用模式不改变，客户端该怎么请求还是怎么请求，中间层接收请求存入队列并推送给大模型服务端，想了几种方案：

1. 使用redis的stream能力做消息队列

   优点：

   1. 完整的ACK机制，有了ACK机制的加入，确保了消息消费的可靠性，避免了重复消费和遗漏消费。
   2. 队列持久化机制，当机器宕机时，持久化保证了消息的可恢复性，重启服务时，继续消费剩下的消息。
   3. 弹性和扩展性，Redis支持主从复制和集群部署，对要求高度可靠性和可扩展性的服务特别适合。即使在数据量剧增的情况下，通过添加Redis实例来水平扩展系统。
   4. 针对现有系统，不需要添加额外中间件。

   缺点：

   1. 目前没有大量使用的场景，针对定制化的场景没有成熟的解决方案

2. 使用MQ做消息队列

   优点：

   1. 专门做消息队列的中间件，能力方面得到保证，针对各种异常情况都有完整的解决方案。
   2. 完整的ACK机制，保证可消息消费的可靠性。
   3. 消息持久化机制，进一步保证了消息的可靠性。

   缺点：
   4. 添加新的中间件，增加了系统的复杂性。
   5. 扩展性方面需要加入额外的组件，分布式部署需要引入新的中心化管理组件，比如RocketMQ的NameServer，kafka的Zookeeper

总结，考虑的就是服务器性能问题，加入MQ消息队列会额外增加服务器的负担，表现甚至会不如现在，属于丢了西瓜捡芝麻，得不偿失。所以目前暂时打算用Redis来解决消息队列的问题。不知道小伙伴们还有没有更好的解决方案，欢迎大家评论区留言，大家一起进步，众人拾柴火焰高。