杨老板在群里讨论了一个系统设计题的内容。
聊天系统后台怎么存聊天记录？
开宇提出declearing
看需求了 什么样的业务模型，以后怎样scale。比如 支不支持group 支不支持群发。语音 图片。
杨老板提出进阶
比如只是文字，当然是大型的，先不说群发。Nosql 用什么，Cassandra? 存成什么形式，怎么查找。
Beny提出细节：
先讨论问题范围吧：
1）要存多久？能否删除？
2）是否有搜索的需要？有无搜索的实效性需求？对旧信息的搜索需求？
3）群消息还是单独的消息居多？当然可以共存，但是如果有侧重可以进行特殊处理。
4）预计用户量和写入量是多少？可以估计peak traffic和存储量的需求。
等你快速过完problem definiation再开始讨论设计，思路会清晰一点。
特殊消息类型例如图片、表情、视频也可以特殊讨论。
感觉存储和搜索是两个主要需求，要大概估算需要存多少数据量。
第一印象是分层存储，信息和索引都要存下来，老信息加上他们的索引可以写到file system、较新信息放storage（nosql）、需要快速读取、推送的新信息放cache。需要考虑multi-Data center的写入速度和错误处理，写入需要回执确认成功，为了提高写入速度可以考虑支持物理层支持同时在disk两端写入。
每个人有自己的index，按时删除过时的部分，搜索应该可以支持分页，先搜新信息，后搜旧信息。
讨论的时候可以根据不同的constrain调整你的设计，例如QPS 乘100倍的情况会怎样，支持图片、视频这类大文件的情况如何支持。
杨老板小结
这是一道很常见的题面试。比如就是Facebook messager, 总流量很大。
图片，视频那些无所谓，在聊天记录里肯定是存链接或者id。假设没有搜索，没有删除，先不考虑群聊。Query就是个返回某个时间段的聊天记录。
另一个问题：nosql里，data具体怎么存？是table还是简单的key value pair?
query是什么样子的？
例如A给B发了一条信息，给C发了一条信息，然后收了D一条信息。
你的query结果是不是：
query(A, begin, end) ->
{
to B: xxxx
to C: xxxx
from D: xxxx
}
应该是(uid, timestamp, mid) 比较合适。毕竟有同时发送、接收的信息。
用这样的key,可以取字段时间的两人聊天记录吗？
可以的
这并不是几个字符构成的string，对于noSQL来说他们支持这类复合的key，我记得是实际上是某个带有索引功能的 hash，具体实现就不清楚了。
晓斌接上
只能按prefix搜索。
在后面的key拿不到只能说全表查然后手动filter。如果prefix太接近了 好像某一个node会造成瓶颈。如果prefix太接近了 好像某一个node会造成瓶颈。我一直觉得这个可以搞一个通用的解决方案然后开源一下。
end
