聊天软体实作(2):从读写需求评估资料储存

理想是美好的，但现实是骨感的。上一篇只能说是”基本到不行的资料库设计”，聊天软体的Fan-out是很可怕的，考验工程师的能力。
(如果你写的东西，用户多，就是标準的高病发高流量~)

对于聊天软体而言，聊天室活跃的用户数、每秒传给伺服器的请求、资料库读写的比率等，都会影响系统的负载，更会影响资料流处理的选择。

假设讯息用WebSocket推送，那么推送一笔讯息的流程，大致是:

1.新增讯息request
2.储存讯息资料
3.找出发送对象的WebSocket
4.推送

以下是几种储存讯息资料的模式，先停下来想想自己会怎做吧!

1.每个使用者存一份需要推送的资料
2.每个离线使用者存一份需要的资料
3.存一份完整推送资料，用户则有待推送的 Id 清单
4.存一份完整推送资料，用户则有最后一笔推送的 Id
5.其他你的想法

架构有时没有好坏。Refine, refine, and then Refined.

(1)每个使用者存一份需要推送的资料

Websocket在推送时，只需要读取发送对象的待发送 Queue。

这方法最无脑，但做对了一件事，为了预防推送失败，每个人都有一份备份，不担心讯息石沉大海。不过，写入重複、肥大的资料，佔用了储存空间。读取时需要耗费的资料传输成本也很惊人。

(2)每个离线使用者存一份需要的资料

新增讯息 Request 成功送出后，合理的情况是:如果使用者在线上，那马上就会被推送；而那些没在线上的，就下次再说。

那么，Server 只要负责判断上线状态，遇到没有上线的使用者，再把这份消息存起来，省去一部分储存空间，结束这回合。

缺点就是，那些推送过程消失的讯息，随风去了。

(3)存一份完整推送资料，用户则有待推送的 Id 清单

Websocket在推送时，同时需要读取"讯息资料" 和 "发送对象的待发送 Queue"。

这个方法省去存很多冗余的讯息资料，用户的待推送 Id 清单可以搭配 Ack 机制，在使用者端(client) WebSocket 回复收到讯息后，即可移除 Id ，也就确保了讯息有送达。

(4)存一份完整推送资料，用户则有最后一笔推送的 Id

除了省去存重複资料，接受后也只需要更新一个值，之后只推送大于该值的讯息。听起来是很理想，但也要看需要推送的 Id 是否连续等。需求决定一切。

(5)欢迎讨论~

上一篇: 聊天软体实作(1): 从资料储存开始