[ 咨询 ] 好友聊天功能如何实现

[NeverBelieveMe]

公司项目需要增加这么一个社交的功能，网上搜了一下，基本都是 socket 的方式去实现。这种方案也比较好理解，tcp 长链之后进行消息收发。自己简单写了一下多种事件的处理，可以运行。

这里有几个问题

1. 我是在全局变量里面保存了每一个 client ，根据 IP 来取，然后进行消息发送。用户量不大，应该不会出现数据量过大的内存问题。不过还是想问一下，有没有什么好的方案。
2. 以前写过一个类似的东西，是 socket 用多线程做事件并发处理的，现在改用 python 的 streams ，直接使用协程方法了，想问一下，这一块还需要搞协程池或者设置协程数量吗？我看文档上没写这个。
3. socket 是单线程，可支持的并发量能有多大？虽然用不到高并发高可用，但是想了解一下，如果说用户量很大的情况下，单台服务器无法支撑的情况下，如何升级架构？

[npe]

Websocket / MQTT

[assiadamo]

社交做下去就要各种审核屏蔽字，准备好了吗

[darkengine]

集成个第三方吧，这玩意儿是个无底洞

[jiaoery]

能用第三方尽量用第三方，分之前公司就搞过自己的聊天系统，分享一下自己的踩坑之旅（各位大佬不喜勿喷）后端用的方案是 socket 做及时推送，http 做同步的方式；一开始只有简单的 1v1 的服务，当时就搞了个 id 对 id 的方式来搞；后面又搞群聊，如果群里只有两个人，容易误发到之前 id 对 id 的情况下，而且只要有新用户加入群聊，又要迁移数据，就搞了一个

[so1n]

有对接前端的话，可以考虑用下 socketio ，不然就 websocket

[jiaoery]

@jiaoery conversationId ，然而还有个麻烦，就是如果群聊所有人都退出，需要回收资源；这就必须搞一个定时任务来检查所有的 conversation ；这个解决了；后面业务从国外转入国内，又出现国内某些厂商杀后台的情况，本身及时推送就是在一个 service 里，然后各种保活的方案，适配国内的各个 OEM 又是一地鸡毛，当时团队里搞这个就压了一半的人，痛苦不行；而且上面的问题还是我遇到过的，没遇到的估计更多；要问为什么自己搞，也是当时用第三方的，如个推，信鸽，友盟等上 Google Play 由于内部带广告 API 给扫出来，直接给下架了；甚至当时还给个推写过投诉邮件

[lx271896700]

能用第三方，就用第三方。我曾在两个公司负责 im 项目，开发周期都在 1 年左右，两家公司都是辛辛苦苦开发了一年，最后兜兜转转，都回到了第三方。第三方应该也有按量计费的，你可以找找看。

[coderxy]

@lx271896700 兄弟，不至于吧？ 开发了一年最后还转回第三方了？ 你们最后是啥问题解决不了？ 说出来让大家涨涨见识。

[NeverBelieveMe]

@assiadamo #22 接入阿里云的审核的。

[NeverBelieveMe]

@jiaoery #24 感谢分享经验

[LindsayZhou]

我觉得你们在讨论怎么重新造 irc （小声）

只是不能发图片语音，irc 服务端应该有不少开源实现的，找个来改改？
irc 也能分布式横向扩展 ( rfc2813 )，不过许多服务端并没有实现。

[lx271896700]

@coderxy #28 第一家公司是比较奇葩，公司只有四五个人，一个 iOS+一个安卓+一个后台，用 websocket 搞了一年，app 没什么用户，ios 和安卓都跑了，app 没有人维护，就换了第三方的 im 。第二家公司，也用 websocket 搞了几个月，后来换了小米的 MIMC ，因为 MIMC 免费，初用没发现什么问题，但后来我们使用量大了之后，qps 受限，消息积压严重，只好又换成腾讯 IM(旗舰版)，好在之前写的 UI 界面可以继续使用，所以改动不算太大。

[coderxy]

@lx271896700 原来如此， 第三方 im 在 app 早期的时候肯定是够用的，量大了费用就上来了，这个阶段再自研也不迟。

[NeverBelieveMe]

@lx271896700 #27 我也想用第三方，不过客户不愿意掏钱

[chong3397]

http://www.52im.net/

[linnana]

1.用 ip 存映射关系可能不是一个好的选择？可以考虑用户的 uid 存映射关系，比如以 uid 映射 connected-client ， 也方便后继要做多设备同步等等。

2.网络和 IO 等层面的东西用网络编程库和框架来替代就可以了，比如我们用的 Netty ，Python 不太熟但应该也有类似的东西。

3.单台服务器无法支撑的情况下，可以前置一个 im-route 模块用某种规则路由（往往取决于业务需要）到不同的 im-server 上，同时所有当消息需要做跨 im-server 路由时，需要全局的在线记录表来找到一个用户在哪个 im-server 实例上。这时候需要一个全局在线记录映射等等。扩展可能还会有 login/broker/store/sensitive-censor 等子模块拆分。

[tyzandhr]

我很好奇，为什么发在 python 标签

[fluyy]

我觉得直接用第三方的比较好。单纯的看你这个问题，第一个问题最好最好以用户 id 来存 client ，

[fluyy]

第二个问题不太清楚了。第三个规模扩大了，那就要有多台机器。简单的可以再搭一个接入层，然后根据 userid hash 到后端业务机器。

[kuituosi]

im 主要分两种类型，是否支持离线消息。支持离线消息复杂很多，其中又分服务器是否集群，毕竟单点故障会影响用户体验。如果只支持在线消息这个很简单。如果不支持集群的离线消息，难度也不大。如果支持离线消息并且服务器集群，那难度相当大。至于 python 单机支持的连接数其实问题不太大，比较聊天很多时候处理逻辑不复杂，大不了多进程就能解决