默认
开启辅助访问
发表评论 13
即时通讯网»社区 › 专项技术区 › IM开发 › IM中用户重复登陆判断的问题怎么实现好？
想开发IM：买成品怕坑？租第3方怕贵？找开源自已撸？尽量别走弯路了... 找站长给点建议
推荐 方案：MobileIMSDK框架、RainbowChat产品、RainbowChat-Web产品 / 签到领积分！ / 官方技术交流群：185926912
IM中用户重复登陆判断的问题怎么实现好？
阅读（49939） | 评论（13） 收藏1 淘帖1 赞
sxb Lv.2 8 年前 | 只看该作者 倒序浏览 |阅读模式
用户登陆服务时，我会根据用户的id和fd通道作为一个对应关系存起来，把用户状态改为在线状态，当用户某时间断网客户端立即又登陆，服务端根据用户id，看哈希表中是否有对应关系，有对应关闭老的fd，删除对应关系，把状态置为下线，同时再添加新的对应关系重复上述动作，因为多线程顺序不能保证，所以我用了类似生产者消费者，，，，我模拟时发现有死锁想象，，是否有好的思路呢？或者更好的解决办法？？？用的（mina2）

即时通讯网 - 即时通讯开发者社区！ 来源： - 即时通讯开发者社区！

标签:即时通讯 IM开发
上一篇：关于最近接受了一个聊天项目，但是不知道用什么好▪下一篇：伪即时通讯：分享滴滴出行iOS客户端的演进过程

本帖已收录至以下技术专辑

相关文章
推荐方案
评论 13
2 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
我把之前的回复也帖上来：
把设备的唯一id带上来呗，关闭的时候只要要关闭的是当前设备，那你就不用关，解决误关最新登陆的问题。
自已写线程模型，除非你有足够的经验和自信，不然还是换个成熟的实现或方案吧，死锁是个槛。
3 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
我说的唯一ID不是登陆账号或者你系统里的ID，这个ID是跟设备有关的，可以唯标识这台手机或PC设备的。

iOS里可以轻易取到device id；
android由于各厂商ROOM不一样，固定取某项硬件序列号并不是万能药，但利用各种硬件序列号也可以组出唯一ID；
PC上可以通过读取MAC地址、硬盘序列号等通过摘要算法自已加工出唯一id。

理论上，准确判断一个“会话”的重复性，应该是唯一设备ID+用户登陆账号。
4 楼: sxb Lv.2 楼主 8 年前 | 只看该作者
引用：JackJiang 发表于 2016-04-23 15:00
我说的唯一ID不是登陆账号或者你系统里的ID，这个ID是跟设备有关的（iOS里可以轻易取到device id。android ...

就是设备的唯一标示，我要记录这个设备的在线状态，如果混乱在线状态会不准确
5 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
引用：sxb 发表于 2016-04-23 15:03
就是设备的唯一标示，我要记录这个设备的在线状态，如果混乱在线状态会不准确

你的问题里涉及两个问题：
1）你目前因为异步登陆问题，容易让重复登陆判断不够准确；
2）死锁问题。

第1）个问题，用唯一设备ID+登陆账号的问题显然是可以处理的，因为你说的最新登陆会话，就是你当前正在处理的会话本身，当然不能被错误地中断掉。而你之前就是会误中断当前会话的问题。
第2）个问题，死锁显然是你的代码实现问题，建议别把问题复杂化，先实现业务需求，再考虑性能，想一步到位的话，如果并发编程经验不是很多的话，会让你的思维混乱。
6 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
另外，我对你的需求有点好奇。你是想实现QQ早期的重复登陆逻辑，还是移动端+PC端混合平台的重复登陆判断逻辑。

- 1）QQ早期的重复登陆路逻辑简单粗暴，只要判定该账号已处于登陆状态，就无条件把之前的登陆给踢掉。
- 2）现在的QQ移动端+PC端混合平台的重复登陆判断逻辑比较复杂，它会判断，当QQ已登陆于手机端时，手机端是不踢的，除非你已经PC端登陆。这就需要增加一层设备类型的判断（我没有试过ios和android能否同时登陆，如果这个也不能重复，则逻辑就更复杂了）。
7 楼: sxb Lv.2 楼主 8 年前 | 只看该作者
引用：JackJiang 发表于 2016-04-23 15:17
另外，我对你的需求有点好奇。你是想实现QQ早期的重复登陆逻辑，还是移动端+PC端混合平台的重复登陆判断逻 ...

群主你把我问题想复杂了，
1、一个通道重复发送登陆协议这个可以判断，抛弃下就行
2、断网前端设备又重复发送登陆协议，这不是一个通道，要把老的fd关掉，设置相应的信息，如根据设备id修改登陆时间、删除哈希表、修改状态。当登陆存储在前关闭再后就会出现混乱。
8 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
引用：sxb 发表于 2016-04-23 15:32
群主你把我问题想复杂了，
1、一个通道重复发送登陆协议这个可以判断，抛弃下就行
2、断网前端设备又重 ...

我懂你的意思了。

你可以这么干：客户端提交登请求的时候，把它本地时间戳带上来（如果你怕完整时间戳浪费几个字节流量的话，可以取天或小时的时间戳，这样就短了），在服务端异步判断重复时，已存在连接早于这个时间戳，肯定可以关，晚的，显然就是你描述的问题了，不关就行了。实际上包括微信在内，请求的时候，应该都会有时间戳这个东西在，只是进行了加密加工而已，在用到的时候道理是一样。
9 楼: sxb Lv.2 楼主 8 年前 | 只看该作者
引用：JackJiang 发表于 2016-04-23 15:43
我懂你的意思了。

你可以这么干：客户端提交登请求的时候，把它本地时间戳带上来（如果你怕完整时间戳 ...

我明白你意思，这样改动比较大，我是这样考虑的，设备登陆成功 把设备唯一标示、fd存储哈希表中，把设备状态改为在线，退出删除哈希表，状态改为离线。
为了保持数据准确性（防止关闭立即登陆，新的fd登陆再前，老的fd关闭再后，把哈希表中对应关系删除），我用了类似生产者消费者，但是发现有死锁想象，有啥好的思路吗？？？
10 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
引用：sxb 发表于 2016-04-25 16:44
我明白你意思，这样改动比较大，我是这样考虑的，设备登陆成功 把设备唯一标示、fd存储哈希表中，把设备 ...

上面回复了那么多，你又回到问题的起点了。。。

你所谓生产者消费者模式实现，理论上的最大问题应是线程不同步导致数据不一致，仅此而已，既然你想省事，那你就随它去吧。而你现在发生了死锁，显然是你那块代码有问题，死锁是肯定可以解决的，我猜测你现在所纠结的，应该是你不知道怎么准确地找出死锁发生的地方吧。。
11 楼: sxb Lv.2 楼主 8 年前 | 只看该作者
引用：JackJiang 发表于 2016-04-25 17:45
上面回复了那么多，你又回到问题的起点了。。。

你所谓生产者消费者模式实现，理论上的最大问题应是线 ...

嗯，想不明白为啥
12 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 8 年前 | 只看该作者
引用：sxb 发表于 2016-04-25 18:06
嗯，想不明白为啥

去下一个jProfile，如果死锁可以很轻松的找到问题代码。
13 楼: coolkk Lv.2 8 年前 | 只看该作者
嘿嘿，看了你们讨论这么热烈，又学了一个jProfiler
14 楼: chylhzk Lv.1 8 年前 | 只看该作者
我用的mina，内存里面存储着一个userId和session的map，如果session是链接状态，那么userid重复了的话，就是重复登录
返回列表 发新帖 发表评论
打赏楼主 ×
使用微信打赏！ 使用支付宝打赏！
即时通讯技术的分享和传播需要您的支持，感谢打赏！

返回顶部