671-聊天服务器的历史消息存储问题

聊天服务器的历史消息存储问题

本地消息存储：
一对一聊天中，可以在本地程序的目录以好友的QQ号作为文件夹（这个肯定是不会重复的），超过200M，存储到下一个文件，也可以按天存储消息。
考虑到安全性，我们可以在存储文件的时候给文件的内容进行对称加密。
由好友的QQ号结合一下系统时间，作为默认生成的密钥，在客户端生成就可以了，直接进行加密，管理起来，方便解密。
也可以把历史消息存到数据库SQLite（嵌入式数据库，嵌入到当前进程中，也是一种关系型数据库，支持标准的SQL），可以根据好友的QQ号或者QQ群号作为一个字段，存储到关系型数据库的表里面，进行加密。
本地存储：只有在当前的计算机上登录你的账号才可以看到这些本地存储的消息，换个机器登录你的账号看看不到了。

云消息存储：
也就是说存储在服务端，不管你用哪个机器登录账号，都可以看到历史消息。因为是从服务器拉消息。
怎么存？
聊天消息如果存储在云上，首先，这个历史消息访问的频率是不大的，我们就不需要存储在redis缓存数据库中提高访问效率了，不需要低延时高并发的访问，存储到mysql也可以，专门起一个服务器专门运行mysql，存储历史的云消息。mysql数据库支持高效的SQL查询，我们对于云消息要进行消息搜索，关键字过滤很方便。我们不能把所有的消息往mysql上存储，因为mysql的单表的上限基本上是千万行，超过了千万行，就算是创建索引，由于索引的文件特别大，导致读索引花费的磁盘I/O也是特别多，导致读索引花费的效率非常低，甚至到最后挂掉。我们可以把半年前，一年前的历史悠久的消息从mysql中dump出来放到fileserver上（文件服务器），进行磁盘存储，文件的序列化存储，毕竟这些数据不是经常访问的。

如果是数据库存储，方便各种各样的SQL的查询，在业务上可以进行非常方便的查询。
如果是文件存储，我们要进行查询的话，我们就只能把文件读出来，读到内存上，在内存上用关键字进行过滤。