[RFC] 132 - 服务端发送消息实现优化

[arvinxx]

背景与问题

由于在 1.0 中我们采用了 service 的区分，以相对较低的成本实现了 LobeChat 从客户端到服务端的转型。但实际上，客户端与服务端在延迟开销上有数量级上的差异，虽然我们采用了乐观更新等手段来尝试弥补其中的体验问题。但在经过一年的运行，逐步暴露出来了 DB 版本发消息感觉很慢的问题。因此本 RFC 将针对这个环节做定向的优化。

从 0 开始实现 LoebChat 经历了四阶段的数据流的获取与存储，做一个完整的回顾：

1. Zustand Store + localStorage 同步读写： 这个方案是一开始的数据存储方案，从纯前端出发最自然也是最简单的方案，数据存储如果采用这个方案，在小规模数据量下不会有任何问题， 但是 localStorage 本身有 5M 存储数据量的限制，消息一多就直接存不了爆栈了。Next Chat 就存在大量相关的 issue。
2. Zustand Store + IndexedDB layer 异步读写： 由于在 Next Chat 中看到了相关用户的问题，于是我在当时都没啥人的时候就做了一轮迁移改造 ，将原本 localStorage 的持久化层迁移到了 indexedDB ，彼时的存储数据结构仍然和 localStorage 时期一致，就是一个大 JSON 来存储所有的 session、topic 和 messages。随着我自己的消息数据膨胀到了 4000 多条，我发现一个大 JSON 存储的数据结构会存在非常大的解析与读取开销，于是迫使我寻找了新的解决方案。
3. Zustand Store 前端状态 + dexie ORM 模拟 DB 存储： 介于前者的问题，于是有了 [RFC] 010 - 数据持久层框架重构 ，这一轮大的数据存储架构改造，使我们可以基于 IndexedDB 存储 几百M 甚至上 GB 的消息，可以说保存你一生的消息都不为过。 而此时 zustand 的 store 层已经完全抽成了前端状态层，dexie 也基本做成了一个关系型数据库的模样，而 store 和 dexie 的通信通过 swr 的请求来完成获取，这种实现逻辑正是我们可以通过 service 来切换 db 模式的根本。（通过 dexie 这个 ORM 我也第一次浅浅感受了 database 相关的设计，感觉有 db 真的好爽，再也不用自己手写 filter 了！）而用户对于数据同步的呼声越来越大，基于 yjs + WebRTC 的同步探索以失败告终，且第一次有用户提出在 IndexedDB 下会有概率导致消息全丢失 ，我发现真正的终解还得是服务端 DB。
4. drizzle + postgres 后端存储数据：这也是我们在 1.0 正式版中提出的一个关键特性。此时我们的存储架构已经变成了标准的前端 store 通过 service 往 server 路由请求数据的模式，所有数据也都存储在了 postgres db 上。而基于 drizzle + pg 的这套方案在运转半年后的稳定表现，让我们坚定了这是真正正确的道路。而第一次正儿八经用 database 也是让我发现了 SQL 的好用与强大之处。但此时另外一个问题暴露出来：后端/前端后面怎么新增功能呢？因为前端是 dexie ，后端又是 drizzle，如果未来要新增功能可能就得同时写两套，这会是一个非常高的维护成本，对于我们来说是不太能接受的。
5. 前端 db 转向 pglite： 彼时另外一个很重要的消息则是 drizzle 支持了 pglite ，pglite 则是一个 postgres 的 wasm 封装，这意味着它可以很好地跑在浏览器里，而由于 drizzle 支持 pglite，我们就可以有一套统一的编程界面，通过替换不同的 db instance 来实现不同环境下的 db 执行。这大大降低了在浏览器模式下的开发维护成本。但 pglite 毕竟是一个非常新的项目，我们实现后为了不影响现有项目的情况，专门为其开了一个镜像。运行至今基本上没有太大问题，2.0 我们也将正式废弃 dexie 模式的 db，在浏览器中全量开启 pglite。

而正是这样的一个演进过程，使得我们现有的大部分业务逻辑是写在前端的 store 层的。这在原本的 client 模式下没有什么问题，因为前端操作是非常快的。但如果换到后端 db 的请求上就不 work 了，因为请求延迟会高到可感知。

数据处理模式	延迟开销
zustand store setState	0.1ms ~ 1ms
IndexedDB 读取	1ms ~ 10ms
trpc 网络请求	200ms ~ 2s+

比如一个发生消息，包含了 topic 的创建、用户消息的创建、助手消息的创建，其中会有 6 个请求，如果每个请求要 500ms，那么用户硬生生需要等待 3s 才会开始流式输出内容，体感上就是会非常慢。哪怕用了乐观更新也无济于事。

而 2.0 开始，我们将以 Server / Desktop 作为功能迭代的核心模式，因此大量业务逻辑也会从 store 下沉到 server 端，进而减少请求次数这个最大的开销部分。

实现思路

将原本在前端 store 中的 create messge/createTopic 之类的逻辑下沉到到 server 端实现，并且去掉需要用 refreshMessages/Topics 等重新拉取数据逻辑，换成在一个请求中全量获取，在这个请求中实现：

• 创建用户消息
• 创建topic
• 创建助手消息
• 获取最新的message 和 topic

这样只需一次请求即可完成本来 8 次请求才能完成的动作，大大提升响应速度。同时经过实践验证，该方案可以简化乐观更新的实现，并且不再出现首次新建 topic 消息闪烁的问题。

但由于这个是针对 serverDB 模式的优化，因此只会在 server db 模式下才会走到。

进展

• ✨ feat: refactor to speed up send message in server mode #9046