海量用户通讯系统-显示在线用户列表(5)|学习笔记

简介: 快速学习海量用户通讯系统-显示在线用户列表(5)

开发者学堂课程【Go 语言核心编程 - 面向对象、文件、单元测试、反射、TCP 编程:海量用户通讯系统-显示在线用户列表(5)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/626/detail/9817


海量用户通讯系统-显示在线用户列表(5)

 

内容简介

一、需解决的问题

二、思路分析

 

一、需解决的问题

这是比较关键相对来说也比较麻烦的地方,看代码就可以发现代码明显比之前多,但也还是要解决登录时的问题,要解决的问题是:当一个新的用户上线后,其他已经登录的用户也能获取最新在线用户列表,总的来说就是当一个新的用户上线以后,其他已经登录的用户也知道他上线了,即要通知别人他上线了。比如 A 客户上线了他要告诉 B说”我来了”, B 上线了过后他也告诉 A ,反过来也是这样,假设A 上线了,上面有10个人,比如有客户端 C 、客户端 D 、客户端E 、客户端 F ...,那就要通知其他人”我来了”,并且列表要有所显示,这么小小的功能应该怎么做呢?

 

二、思路分析

1. 思路方案一

比如 B 客户端上线了, A 客户端上线只能通过服务器去发送一个推送消息给各个已经上线的客户说:有人上线了,赶紧去更新以下你的在线列表。大体思路便是这样,那客户端应该怎么做呢?第一种方案先讲一下思路,思路可能每个人都不一样,但是哪个思路更优秀更好一点,就需要动脑筋了,回顾一下需解决的问题是当一个新的用户上线以后,其他已经登录的用户也能获取最新在线用户列表信息,所以第一种思路是:

1、当有一个用户上线后,服务器就马上把维护的 onlineUsers.map整体推送。假设在线用户1000人,就推送给1000人。

2. 思路方案二

当有一个用户上线后不去管他,有自己的节奏,即时你上线也不去管,在服务器启动一个 timer , timer 其实很简单,学加速课时肯定学过类似的东西,启动一个 timer ,定时的去完成,所以第二种思路方案是:

服务器有自己的策略,每隔一定的时间,把维护的 onlineUsers.map整体推送。因为不管上线还是状态变化,都会通知到 online ,所以也可以把这个推送出去。

3. 思路一与思路二的比较

思路二的代价比思路一的更高,因为不去管,量会是很大的,好比一般的聊天软件一般在线10万人,像 QQ 有时在线几千万人,推送给几千万人是很恐怖的,且每个人好友列表也不一样,需要把张三的好友列表撸出来、再把李四的好友列表撸出来,这是很复杂的过程,所以思路一和思路二虽然可行,但是代价比较高。

4. 思路方案三

(1)第一小节

有一个用户上线过后,他只把自己的状态推送给在线的各位用户,比如其变化了通知别人其变化了,并不是把整个 online 整体推送,所以第三种思路方案的第一小节是:

当一个用户 A 上线,服务器就把 A 用户的上线信息,推送给所有在线的用户。当然如果再加一个功能说不推送给所有在线用户,只推送给好友即可。现在还没有加好友,加好友之后便更复杂了,但逻辑还是一样的,即当 A 上线过后就把 A 上线的信息推送给所有在线用户即可。

(2)第二小节

这时就有个问题了,因为是单个推送的,那以前的用户状态到哪儿去了?比如 A 上线了,他把自己的信息推送给 B ,但是 B 本身也在维护其他人的信息,所以就意味着客户端应该有一个 map ,它要接入他现在掌握的用户的状态,也就是客户端这边也应该有个 map 来记录他所持有的或者他关心的在线用户的信息,这就便有了逻辑,所以第三种思路方案的第二小节是:

客户端也需要维护一个 map , map 中记录了他的好友(目前是所有人)。 map 结构为: map[int]User 。在不停的维护 map 信息,然后当状态有变化了,就更新到这里,若要看或者要更新,就调一下方法,把 map 里面取出来就可以了。这样把一个重的服务器端的功能分散给各个客户端,服务器的压力就不至于很大。因为 map 是客户端的,它肯定不会去维护这个东西,拿都拿不到又怎么去维护,它是客户端它有自己的连接,因此它必须去维护一个所有的 User 信息,即它维护的是它关心的人的信息,他的 ID 、他的名字、他的昵称等等,这听起来比较容易,操作起来却不是。

(3)第三小节

还需要完成一个事情,就是比如当用户上线过后,要怎么通知他、推送他,这时就要用服务器端和客户端维护的协程,曾经留了一个接口,在登录成功以后启了一个重要的协程叫 serverProcessMessage ,此协程有重大的作用,它会不停的说服务器有人变化,所以此东西就变得很重要,该协程保存和服务器端的通讯,如果服务器有数据推送给客户端,就接受并显示在客户端的终端,这样的很多,比如用户的状态变化、有人跟我私聊或有人群发消息或开视频会议等等,这个就需要通过协程来完成,所以复杂度明显增加了,所以第三种思路的第三小节是:

客户端和服务器的通讯通道,要依赖 serverProcessMes 协程。

相关文章
|
13天前
|
弹性计算 运维 搜索推荐
|
网络协议 测试技术 Go
海量用户通讯系统-显示在线用户列表(2)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(2)
62 0
|
网络协议 测试技术 Go
海量用户通讯系统-显示在线用户列表(1)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(1)
148 0
海量用户通讯系统-显示在线用户列表(1)|学习笔记
|
JSON 网络协议 测试技术
海量用户通讯系统-显示在线用户列表(6)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(6)
90 0
|
机器学习/深度学习 JSON 网络协议
海量用户通讯系统-显示在线用户列表(3)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(3)
98 0
|
机器学习/深度学习 JSON 前端开发
海量用户通讯系统-显示在线用户列表(4)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(4)
80 0
|
机器学习/深度学习 JSON 网络协议
海量用户通讯系统-显示在线用户列表(7)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(7)
93 0
|
NoSQL 网络协议 关系型数据库
海量用户通讯系统-完成界面|学习笔记
快速学习海量用户通讯系统-完成界面
132 0
海量用户通讯系统-完成界面|学习笔记
|
JSON 网络协议 测试技术
海量用户通讯系统-登录(指定用户)|学习笔记
快速学习海量用户通讯系统-登录(指定用户)
74 0
|
NoSQL 网络协议 测试技术
海量用户通讯系统-用户登录(2)|学习笔记
快速学习海量用户通讯系统-用户登录(2)
64 0