GoBelieve UseID及ImID方案

p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px "Helvetica Neue"; color: #454545 }
p.p2 { margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px ".PingFang SC"; color: #454545 }
span.s1 { font: 12.0px "Helvetica Neue" }
span.s2 { font: 12.0px ".PingFang SC" }

  • GoBelieve:

imId = (appid + uid)

IM 服务器用(appid + uid)imid做用户的唯一标示

imid是IM平台上沟通的凭证

客户端请求联系人列表后,会有对应uid.

客户端发送消息的格式是(uid,content),im 后台会拼接(appid + uid)imId,直接走IM服务器。

  • 对比方案:

IM 服务器用imId做用户的唯一标示

imid是IM平台上沟通的凭证

用户在客户端注册(登录),userid发送到你们服务器,你们服务器再向IM服务器发送UserId请求imId。对应(userId->imId)关系保存下来。

你们服务器保存(userId->imId)表

客户端请求联系人列表后,会有对应imId.

客户端发送消息的格式是(imId,content),直接走IM服务器。

时间: 2024-10-18 09:28:52

GoBelieve UseID及ImID方案的相关文章

GoBelieve IM 消息推送的方案

消息推送设计方案如下: 所有接入im SDK的deviceTOken都会存储到IM服务器.就可以 IM服务器来根据你们服务器指定的useId来下发消息.判断客户端在线,并且APP在前台.就是socket下发,IM 消息.如果客户端不在线,或者APP在后台,就走推送(安卓是第三方推送,IOS是apns).SDK使用中,就不不需要管deviceToken.只管给需要的userID 发送消息.消息到服务器后,下发是 IM消息,还是走通知推送.由这个机制来控制 接入主要做的是: 客户端按DEMO获取de

MySQL分库分表方案

1. MySQL分库分表方案 1.1. 问题: 1.2. 回答: 1.2.1. 最好的切分MySQL的方式就是:除非万不得已,否则不要去干它. 1.2.2. 你的SQL语句不再是声明式的(declarative) 1.2.3. 你招致了大量的网络延时 1.2.4. 你失去了SQL的许多强大能力 1.2.5. MySQL没有API保证异步查询返回顺序结果 1.2.6. 总结 MySQL分库分表方案 翻译一个stackoverflow上的问答,关于分库分表的缺点的,原文链接: MySQL shard

C#开发微信门户及应用(47) - 整合Web API、微信后台管理及前端微信小程序的应用方案

在微信开发中,我一直强调需要建立一个比较统一的Web API接口体系,以便实现数据的集中化,这样我们在常规的Web业务系统,Winform业务系统.微信应用.微信小程序.APP等方面,都可以直接调用基于JSON数据格式的Web API接口,在我之前的几篇随笔中,对这方面都有一定的介绍,本篇继续这个主题,细致深入的阐述如何在接口和源码的基础上整合Web API.微信后台管理及前端微信小程序的应用方案. 1.基于Web API的微信开发框架 首先我们各个业务模块,都应该围绕着Web API进行展开,

redis的单机安装与配置以及生产环境启动方案

简单介绍一下redis的单机安装与配置,方便自己记录安装步骤的同时方便他人获取知识. 首先,从官网下载最新版的(稳定版)的redis安装包.官网地址如下:https://redis.io/download 下载源码包后,redis需要编译安装.需要安装gcc和tcl,gcc用于编译tcl用于测试. 使用命令安装gcc,yum install gcc,一路选择yes,gcc就可以安装成功. 接下来安装tcl,首先获取tcl源码包(见百度云盘)或者使用命令:wget http://downloads

Linux分区方案

Linux服务器分区的方案: 分区类型 分区的实际大小 / 1G-2G (最少要150–250MB) /boot 32M-100M (启动分区,最多只要100M左右) /opt 100M-1G (附加应用程序) /tmp 40M-1000M (最大可以设为1G左右,如果加载ISO镜像文件就设为4G左右吧,一般不用那么多) /home 2G-10G (每个用户100M左右,具体自定.用户目录.) /usr 3G-10G 最少要500M左右,一般宽松的服务器要分到4-6G) /usr/local 3

Java实现多线程生产者消费模型及优化方案

生产者-消费者模型是进程间通信的重要内容之一.其原理十分简单,但自己用语言实现往往会出现很多的问题,下面我们用一系列代码来展现在编码中容易出现的问题以及最优解决方案. /* 单生产者.单消费者生产烤鸭 */class Resource { private String name; private int count = 1; //计数器,记录有多少只烤鸭被生产及消费 private boolean flag = false; //停止标记 public synchronized void set

高并发处理方案(转)

时常看到高并发的问题,但高并发其实是最不需要考虑的东西.为何,他虚无缥缈,很少有网站真的需要这些东西,而且其中很多技术,其实你已经在用了.有这个意识就够了,不需要时刻盯着这个问题.只有很少的网站真的能达到高并发. 简单做一个归纳,从低成本.高性能和高扩张性的角度来说有如下处理方案:   1.HTML静态化   2.图片服务器分离   3.数据库集群和库表散列   4.缓存    5.镜像    6.负载均衡;一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种

数据备份方案

经常有朋友发生了数据丢失时找我帮忙,我发现数据备份是最科学的解决方案.于是花时间把我这几年积累的数据备份方案整理出来,希望能帮到大家. 先看看几个典型情景: 我经常用手机拍照,万一我手机丢了,里面的照片的价值比一台新手机还大. 我把我的许多资料存在移动硬盘里了,结果今天硬盘出问题,读不出来,有什么办法可以挽回? 我的许多重要数据都存在我的个人电脑里,结果昨晚电脑被贼偷了. 我刚误修改了一份Excel文件,而且还保存了,我想要回修改前的文件. 以上是常见的几个代表情景,如果真的发生了,往往很难处理

MYSQL 主从同步故障-Error1062--解决方案

MYSQL 主从同步故障-Error1062-解决方案 公司有两台Mysql服务器之前配置了主从同步,今天用户反映数据有差异,登陆到服务器上查看Mysql主从配置,发现有错误: show slave status \G;  果然出现问题了 Slave_IO_Running: Yes Slave_SQL_Running: No 而且出现了1062错误 Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY''