TeamTalk源码分析之服务端描述

TTServer(TeamTalk服务器端)主要包含了以下几种服务器:

  • LoginServer (C++): 登录服务器,分配一个负载小的MsgServer给客户端使用
  • MsgServer (C++): 消息服务器,提供客户端大部分信令处理功能,包括私人聊天、群组聊天等
  • RouteServer (C++): 路由服务器,为登录在不同MsgServer的用户提供消息转发功能
  • FileServer (C++): 文件服务器,提供客户端之间得文件传输服务,支持在线以及离线文件传输
  • MsfsServer (C++): 图片存储服务器,提供头像,图片传输中的图片存储服务
  • DBProxy (C++): 数据库代理服务器,提供mysql以及redis的访问服务,屏蔽其他服务器与mysql与redis的直接交互

系统结构图

TeamTalk中用到了其他开源库,比如Google Protobuf、redis、log4cxx等。

服务端流程

服务端的启动没有严格的先后流程,因为各端在启动后会去主动连接其所依赖的服务端,如果相应的服务端还未启动,会始终尝试连接。不过在此,如果是线上环境,还是建议按照如下的启动顺序去启动(也不是唯一的顺序):

1、启动db_proxy。

2、启动route_server,file_server,msfs

3、启动login_server

4、启动msg_server

那么我就按照服务端的启动顺序去讲解服务端的一个流程概述。
第一步:启动db_proxy后,db_proxy会去根据配置文件连接相应的mysql实例,以及redis实例。
第二步:启动route_server,file_server,msfs后,各个服务端都会开始监听相应的端口。
第三步:启动login_server,login_server就开始监听相应的端口(8080),等待客户端的连接,而分配一个负载相对较小的msg_server给客户端。
第四步:启动msg_server(端口8000),msg_server启动后,会去主动连接route_server,login_server,db_proxy_server,会将自己的监听的端口信息注册到login_server去,同时在用户上线,下线的时候会将自己的负载情况汇报给login_server.

各个服务的端口号

(ps:这里是按照新版TeamTalk部署教程上的设置的,不同设置会有不同结果^_^,详情见新版TeamTalk完整部署教程,注意:如果出现部署完成后但是服务进程启动有问题或者只有部分服务进程启动了,请查看相应的log日志,请查看相应的log日志,请查看相应的log日志,重要的事情说3遍。)


服务


端口


login_server


8080/8008


msg_server


8000


db_proxy_server


10600


route_server


8200


http_msg_server


8400


file_server


8600/8601

参考

1、新版TeamTalk完整部署教程(这个是完整部署教程,当时就是按照这个配置来的^_^)

2、mogujie/TeamTalk(ps:官方貌似好久没更新了)

3、google protobuf安装与使用(ps:TeamTalk中用到了protobuf)

时间: 2024-11-05 02:20:05

TeamTalk源码分析之服务端描述的相关文章

zookeeper源码分析之五服务端(集群leader)处理请求流程

leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcessor -> ProposalRequestProcessor ->CommitProcessor -> Leader.ToBeAppliedRequestProcessor ->FinalRequestProcessor 具体情况可以参看代码: @Override protected v

zookeeper源码分析之一服务端处理请求流程

上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析各自一下消息处理过程: 前文可以看到在 1.在单机情况下NettyServerCnxnFactory中启动ZookeeperServer来处理消息: public synchronized void startup() { if (sessionTracker == null) { createSe

netty源码分析之服务端启动

ServerBootstrap与Bootstrap分别是netty中服务端与客户端的引导类,主要负责服务端与客户端初始化.配置及启动引导等工作,接下来我们就通过netty源码中的示例对ServerBootstrap与Bootstrap的源码进行一个简单的分析.首先我们知道这两个类都继承自AbstractBootstrap类 接下来我们就通过netty源码中ServerBootstrap的实例入手对其进行一个简单的分析. // Configure the server. EventLoopGrou

libevent源码分析-TCP服务端代码

先贴一段代码再说,Linux下使用g++ -g-o server server.c -levent 可以直接使用gdb调试,而且可以跟踪到libevent的库里. 1 #include <stdio.h> 2 #include <string.h> 3 #include <iostream> 4 #include <sys/socket.h> 5 #include <netinet/in.h> 6 #include <arpa/inet.h

TeamTalk源码分析之login_server

login_server是TeamTalk的登录服务器,负责分配一个负载较小的MsgServer给客户端使用,按照新版TeamTalk完整部署教程来配置的话,login_server的服务端口就是8080,客户端登录服务器地址配置如下(这里是win版本客户端): 1.login_server启动流程 login_server的启动是从login_server.cpp中的main函数开始的,login_server.cpp所在工程路径为server\src\login_server.下表是logi

TeamTalk源码分析(七) —— 服务器端msf源码分析

"-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> TeamTalk源码分析(七) -- 服务器端msf源码分析 - 左雪菲的专栏 - 博客频道 - CSDN.NET 左雪菲的专栏 欢迎访问我的个人网站:http://www.hootina.org 目录视图 摘要视图 订阅 [活动]2017 CSDN博客专栏评选 &n

源码分析Dubbo服务消费端启动流程

通过前面文章详解,我们知道Dubbo服务消费者标签dubbo:reference最终会在Spring容器中创建一个对应的ReferenceBean实例,而ReferenceBean实现了Spring生命周期接口:InitializingBean,接下来应该看一下其afterPropertiesSet方法的实现. 1.源码分析ReferenceBean#afterPropertiesSet ReferenceBean#afterPropertiesSet if (getConsumer() ==

Dubbo源码分析系列-服务的发布

RPC简化类图 RPC模块核心接口和抽象实现 默认实现Dubbo协议的接口和抽象实现 服务发布过程 调用过程 上图是服务提供者暴露服务的主过程: 首先ServiceConfig类拿到对外提供服务的实际类ref(如:HelloWorldImpl),然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例,到这一步就完成具体服务到Invoker的转化.接下来就是Invoker转换到Exporter的过程. Dubbo处理服务暴露的关键

skynet源码分析:服务

skynet是为多人在线游戏打造的轻量级服务端框架,使用c+lua实现.使用这套框架的一个好处就是,基本只需要lua,很少用到c做开发,一定程度上提高了开发效率. skynet的例子是怎么调用的 服务器: simpledb.lua: skynet.register "SIMPLEDB" 向skynet里注册一个服务 agent.lua: skynet.call("SIMPLEDB", "text", text) 调用相应的服务 main.lua: