浅谈teamtalk

       蘑菇街开源的teamtalk可以作为2-3年初学者学习之用，或者小型公司当作内部im办公交流之用。至于源码讲解，网上开源的挺多。迷茫且闲着没事的初学者们可以简单看看，看网络框架大概一天可以看明白，看业务，大概需要一到两周，需要去centos7.0以上部署下，msgserver可以看完代码配置2个试试，调试。客户端代码也可以简单看看。还是有一定价值的，像网络框架通用，简单，没有过多炫技，且业务逻辑简单实用，数据表的设计，我之前调试的时候，里面是缺了一张表，具体那张表记不太清了。不过不影响大局。通信协议用的是protobuf，简单搞笑，虽然可视化程度不够，但取舍之下相对于后端来说，protobuf前后兼容（此处可以看看为啥兼容），各个语言都支持，使用起来也简单。

     可供学习的点，大概如下几点：

     1：网络库设计包括定时器设计，消息队列设计，超时处理这里。

     2：protobuf使用学习，logserver里面的http解析代码可以简单看看。

     3：整体逻辑架构设计，业务设计，数据表设计。

     4：一个用户退出登录服务器这里如何处理可以简单看看。

      可优化的点，大概有如下几点：

     1：里面的网络框架，大多是单进程单线程服务，虽说可以部署多进程，但难免消耗资源，且配置文件搞起来也比较麻烦。此处可以修改为类似muduo这种的，单线程处理网络收发包，多线程处理消息队列（此处可以后续接着探讨网络库如何设计），或者直接修改teamtalk的源码，单线程接受fd，多线程处理网络收发包以及具体消息业务逻辑。

    2：日志模块，teamtalk里面用的日志是log4，之前搞客户端的时候市面上倒是有一些公司，用的是log4，服务器来说倒是少见。日志模块，不清楚底层实现，容易出问题，自己写个日志模块倒是也不难，此处建议自己写用来替换。市面上有两种日志模块设计方法：1：直接同步写，这样设计逻辑简单，但多线程写容易乱序且会对同步线程造成损耗。2：异步写，抛到线程里，用任务队列去消费日志，可以先写缓存，再写磁盘。且任务队列大小要做限制，日志一条长度也要做限制，一个日志文件大小也要做限制。市面上也有两种日志存储形式：1：在当前服务log目录下，2：在系统某个目录下。此处仁者见仁，智者见智。还有一些公司日志文件分为三种：error，debug，sys，这样会导致日志分散，不易于查找问题。不建议这种存储方法。简单写写自己玩玩倒是可以，网上也有类似代码。不作赘述。

   3：最重要的设计上面的缺陷在于单点routeserver，此处作为存储所有用户关系的缓存服务以及数据转发服务，后端来说，单点一旦崩溃，整个程序无法运行。此处可以修改为用户关系存在redis里，最好搞一个redis集群模式，具体集群如何设计网上有文章可以查到。且群用户在线这里可以搞一个redis hash key设计，key为群号。redis 集群99.99%的可靠性。转发还是在routeserver这里。msgserver这里转发之前去查找群用户具体在那台机器上，然后定向转发，避免浪费网络带宽，此处做一次查询，也提高效率。

   4：图片，以及文件管理这里，这里直接磁盘存储文件图片，如文件过多，会导致读取效率，磁盘io大幅变低，此处可以搞个什么分布式的小文件管理系统或者数据库啥的。具体啥，网上应该也一大堆文件，可以简单了解下。

   5：消息缓存设计，此处可以添加redis 集群或者ldb作消息缓存，以防止消息过多，mysql爆掉，mysql可以搞个主从啥的，防止丢数据。

   6：loginserver设计，此处负载均衡设计，可以搞一个类似nginx这样的dns负载，或者lvs之类的，大多都是配置域名登录，然后域名解析作负载均衡处理这样。

本人qq交流群：242598595。有啥商榷之处，可以交流探讨，常年不定时在线。

在转载此站点文章时，希望可以声明原作者 ，感谢。