一些问题

目前消息存储服务器设计的是所有消息文件都扁平的存放在一个目录下。如果数据量大了的话，一个目录存放较多的文件，会影响文件系统读取性能。

128M的块文件大约能存多少条数据？

一个目录下有多少文件的时候会显著影响文件读取性能？

重建消息索引文件时，peer_index和group_index是单独重建的，也就是会进行两遍消息文件的遍历？

如果消息历史记录较多时，这个重建消息索引文件的过程会特别耗时，IMS启动时间会比较长。

我们可以删除一部分历史消息，如删除message_0,message_1而不影响整个系统的运行，具体是怎么做到的？

是否只能删除最前面的历史消息？

是否可以删除中间部分的历史消息？

如果丢失任何一个消息块文件，对整个系统会有什么影响？

GetNewCount()方法会提供一个last_received_id，IMS会从消息文件末尾往前遍历直到last_received_id，这样会带来性能问题

如果客户端提供的last_received_id比较小，比如为0，那么必然要把所有的消息文件逐个遍历一遍，容易被恶意攻击。

我们应该控制一个最大遍历条数，防止这种大数据量的遍历！

LoadLatestMessages、LoadHistoryMessages、LoadGroupHistoryMessages这三个方法就提供了limit参数，防止大数据量的遍历。

IM服务器可以分别设置单聊消息IMS和群组消息IMS，如果分开存储的话，获取最新消息条数以及获取最近消息返回的结果准确么？

IM服务器有两个配置：storage_rpc_pool 和 group_storage_rpc_pool。

注意，这里不是将单聊消息和群组消息分开存储，而是将超级群单独存储，放到group_storage_rpc_pool指定的IMS服务器上。

为什么超级群需要单独进行存储呢？

TODO 有可能是群里用户太多，每条消息都要进入用户的消息队列，比较耗费磁盘资源。