• [Go WebSocket] 多房间的聊天室(二)代码实现


    我是HullQin,公众号线下聚会游戏的作者(欢迎关注公众号,发送加微信,交个朋友),转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋等游戏,不收费没广告。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我 HullQin 噢~我有空了会分享做游戏的相关技术。

    背景

    第一篇文章:《为什么我选用Go重构Python版本的WebSocket服务?》,介绍了我的目标。

    第二篇文章:《你的第一个Go WebSocket服务: echo server》,介绍了一下怎么写一个WebSocket server。

    第三篇文章:《单房间的聊天室》,介绍了如何实现一个单房间的聊天室。

    第四篇文章:《多房间的聊天室(一)思考篇》,介绍了实现一个多房间的聊天室的思路。

    今天我们实现一个多房间的聊天室。如果你没阅读上面的文章,一定要先看一下,因为这篇文章更复杂,如果你不弄懂上面几篇,这篇可能跟不上节奏噢。

    方案回顾

    1.png

    上篇文章,有2个决策点:

    1. 何时创建房间?
    2. 如何决定客户端连哪个房间?

    上篇文章都提到了多种解决方案,都是可以选择的。但是本文要开始写代码实现了,必须作出一个选择,选择如下:

    决策点1选择「方案二:动态创建房间」。决策点2选择「方案一:URL里指定」。

    这也是我的「联机桌游合集」所采用的方案。

    直接看源码

    多房间聊天室案例代码的地址:https://github.com/HullQin/go-websocket-examples

    chat-multi-rooms文件夹中,文章可配套commit记录阅读:

    初始代码

    我们用《单房间的聊天室》的代码为基础,在它上面改造。

    URL指定房间号:路由参数

    因为我们要在URL里指定房间号,怎么实现呢?我们可以借助gorilla/mux这个库,它可以实现强大的路由能力。Github介绍如下:Package gorilla/mux implements a request router and dispatcher for matching incoming requests to their respective handler.

    安装依赖:

    go get github.com/gorilla/mux
    
    • 1

    我们把之前的代码改为:

    import (
       "github.com/gorilla/mux"
    )
    // ...
    r := mux.NewRouter()
    r.HandleFunc("/", serveHome)
    r.HandleFunc("/ws/{room}", func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        roomId := vars["room"]
        // ...
    }
    err := http.ListenAndServe(*addr, r)
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    可以看到,我们在路有中增加了{room},这是个动态参数,可以匹配字符串,赋值给room。具体参数的值如何取值呢?通过vars := mux.Vars(r)即可获得一个map,这个map的key是参数名,value是参数的值,均为字符串类型。

    所以到现在,我们从URL中获得了roomId。

    动态创建房间逻辑

    不像单房间聊天室,我们需要在全局开启一个hub goroutine。这次,我们必须动态新增hub goroutine。

    怎么办呢?我们需要有一个全局变量,保存所有的hub,可以用map。每当连接来的时候,就检查该roomId是否存在,如果存在,就取对应的hub,如果不存在,就需要新建hub。

    在addr定义下方,新建house定义。

    var addr = flag.String("addr", "localhost:8080", "http service address")
    var house = make(map[string]*Hub)
    
    • 1
    • 2

    完善处理器逻辑。

    r.HandleFunc("/ws/{room}", func(w http.ResponseWriter, r *http.Request) {
       vars := mux.Vars(r)
       roomId := vars["room"]
       room, ok := house[roomId]
       var hub *Hub
       if ok {
          hub = room
       } else {
          hub = newHub()
          house[roomId] = hub
          go hub.run()
       }
       serveWs(hub, w, r)
    })
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14

    到现在,我们已经把后端逻辑改完了!你敢信?

    得益于上上篇文章出色的设计(把hub设计为可扩展为多房间的),从单房间改造到多房间,竟然如此轻松!

    但是并没有完,为了方便测试,我们还需要修改一下home.html

    修改http服务

    home.html

    32行代码改造如下:

    conn = new WebSocket("ws://" + document.location.host + "/ws" + document.location.pathname);
    
    • 1

    也就是说,你前端访问的是localhost:8080/ha,就会进入ha房间。当然你可以修改ha进入其它房间。

    main.go

    这几行代码先删掉:

    //if r.URL.Path != "/" {
    // http.Error(w, "Not found", http.StatusNotFound)
    // return
    //}
    
    • 1
    • 2
    • 3
    • 4

    因为我们之后要访问的是localhost:8080/ha,而非localhost:8080/,所以r.URL.Path一定不能是/,不然就不知道房间号了。

    此外,路由逻辑也适配一下房间号参数:

    r.HandleFunc("/{room}", serveHome)
    
    • 1

    至此,大功告成!快去测试一下!

    浏览器打开3个Tab,分别访问http://localhost:8080/123http://localhost:8080/123http://localhost:8080/444。然后去发消息,你会发现123房间是消息互相广播的,而且不会发送到444房间;而且444房间的消息也不会发送到123房间!

    多房间的聊天室,我们实现啦!

    待优化项

    现在房间数只会源源不断的增多,house这个map会越来越大,终将造成内存不足,这不是一个好事情。

    所以我们后续需要加一个优化:当最后一个客户端断开连接时,回收(删除)这个房间。

    写在最后

    我是HullQin,公众号线下聚会游戏的作者(欢迎关注公众号,发送加微信,交个朋友),转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋等游戏,不收费没广告。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我 HullQin 噢~我有空了会分享做游戏的相关技术。

  • 相关阅读:
    数据结构:图(树也是图的一种),有向图和无向图,连通图和非连通图,有向图出度入度
    Postman内置动态参数和自定义的动态参数以及断言方式
    【第六周】组合数据类型
    自动化测试框架该如何搭建?一文4个步骤轻松实现!
    基于智慧城市与储住分离数字家居模式垃圾处理方法
    数据结构与算法【递归】Java实现
    机器学习课程复习——逻辑回归
    Spring后置处理器BeanFactoryPostProcessor与BeanPostProcessor源码解析
    【leetcode】剑指 Offer 22. 链表中倒数第k个节点(简单)
    ​k8s如何做容器的高可用?
  • 原文地址:https://blog.csdn.net/kd_2015/article/details/126964936