使用过ejabberd的或许知道,也许踩过这个坑。那么就说说咱们踩过的ejabberd的离线消息的坑吧。数据库
ejabberd原生的离线消息的机制是,通常用户保存100条离线消息,管理员保存5000条离线消息。超过以后居然没有删除老的离线消息的机制。😓 仅仅是报一个警告。app
1测试 2spa 3code |
|
1教程 2ci |
|
ejabberd原生的群聊是没有离线消息的,只要用户不在线,这期间其余群成员在群里面的聊天,不在线的用户上线后收不到这些消息的。
彻底跟如今的一些即时聊天软件不同,太很差耍了,并且一些客户都是按照某信的要求来看待的,对比一下就会发现这些问题,而后就是一堆的需求。
按照如今的即时聊天软件,咱们在原来的基础上实现了群聊离线消息的机制,还添加多客户端消息同步的机制,那么一条离线消息就咬保存好几份了,而后的条数限制远远不够了,即便调了离线消息的配置(由原来的100改成2000),在一个群里面疯狂的聊天,一会儿就满了。
好吧,那么就添加删除的机制吧,只要用户的离线消息大于配置的条数,那么就删除超出配置的老的离线消息。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
改造了一些源代码,思路就是先查询到全部的离线消息,排序删除老的离线消息。(原本不熟悉erlang的,业务需求硬着头皮改的。你们轻喷)
而后呢,又有效率问题。只要用户离线消息满了,就会一直循环这个删除动做,不停的查询全部的离线消息,删掉超出的部分。
既然这样,那就不限制离线消息的条数了。注释掉这个方法,测试一下静观其变吧。
好吧,即便这样仍是有问题。mnsia的offline_msg表只要超过2G,模块就会奔溃。
1 |
|
查到一些资料,Mnesia 单表的存储容量(Dets)目前只能处理2G。因为如今咱们是 disc_only_copies,即如今离线消息占用的应该是磁盘。目前 Offline Mod 崩溃都是离线消息存储到达 2G 的时候,因此推测是触到 Mnesia 单表处理上线了。
这个就真的没有办法,那就只能将离线消息保存到MySQL中了,原生的原本就支持ODBC。
按照一些教程配置吧,很快就行了。主要是在mod_offline模块添加db_type:odbc就行。
额,又有小问题,emoji问题,那就又搜教程配置MySQL数据库,改表吧。
一路磕磕碰碰的,献给那些走在路上的人和那些即将走到路上的人。