请教一下，一个聊天记录存储服务该如何设计

csumck

公司产品有个类似群聊天的功能，现在要求后台服务能够永久保存每个群的聊天记录，还要求前台能够分页查询聊天记录，如果能做到按时间查询那就更好了。

我自己简单归纳了一下一些需要考虑的点：
1. 聊天记录写多读少（大部分人在聊天，但很少有人翻历史聊天记录看），且每条记录字节数很少。
    a. 为了减少磁盘压力，服务可以在内存缓存一部分记录后，延后在某个时刻一次性写入磁盘。
    b. 如果写失败了，要尽量保证磁盘文件的数据完整性，不能导致原记录文件损坏。
2. 越老的聊天记录被用户翻阅的几率越小，所以查询服务里使用cache是很有必要的。
3. 历史久远的聊天记录一般不会在cache里，所以查询服务需要从文件里读取聊天记录时需要能够很快的索引到该记录在磁盘上的位置。 这里肯定要设计一个合适的数据结构和文件存储规则。
    a. 如果需要按页查询聊天记录，那就要知道总页数，每页的起点位于磁盘的哪个位置。
    b. 如果需要按时间查询，那就挺像微博的。

算是海量数据存储吧，本人一点经验都没有。
希望大家能够提供一些设计思路和实战经验，使用开源系统 或者 自己写代码都可以， 欢迎讨论，多谢大家！

linux_c_py_php

1. logic server - proxy---db
   
2.                 |    /
   
3.              cache

复制代码

自己体会。

csumck

回复 2# linux_c_py_php


    多谢。确实用DB能避免了好多麻烦。 看来还是不要考虑自己写文件了，数据完整性太难保证。

bikong0411

回复 3# csumck


    keep it simple and stupid

sxcong

写多读少用mongodb最合适，海量更不成问题

ideawu

回复 1# csumck


说说我们的经验. 聊天记录要按时间排序, 而且数据量大, 冷热明显, 用 MySQL 存储不太适合, 需要做大量的分表分库. 我们开始使用的是开源的 Redis, 一个内存 NoSQL 数据库, 但存储容量太小, 后来改成开源的 SSDB, 可以存储 TB 级别的数据.

SSDB/Redis 有一种数据结构叫 zset(sorted set), 可以理解为关系数据库里的只有两个字段的表: id, order. id 字段是对象的标识, 在聊天中是消息体的标识, 而 order 消息的时间戳. SSDB 将数据按 order 进行排序后写入磁盘, 所以读取时不需要再排序, 速度非常快.

如果要按你自己说的, 自己设计文件结构存储, 自己维护索引, 这样重新发明一个轮子的成本太大, 不建议在这种需求下做.

SSDB: http://www.ideawu.com/ssdb/, https://github.com/ideawu/ssdb
Redis: http://redis.io/

csumck

回复 7# ideawu


    可靠性怎么样啊？
    redis能直接拿来做存储么，这玩意好象是将内存数据定期全量dump到磁盘的，万一dump到一半故障了还能恢复不？
    ssdb第一次听说，我来研究下，多谢！

ideawu

回复 8# csumck
Redis 的持久化机制没有你说的那么简单, 只要数据足够小(不超过内存1/3), 就可以作为存储. 如果数据量大, 可以使用 SSDB, 都是在大并发生产环境验证过的.


   

crazyhadoop

就存储这块来说，leveldb不能再合适了