与tp框架的结合方案中,每次发送消息都得经过web服务器,岂不是增加了web服务器请求压力?

悉地网

612 3 1
3个回答

lunzi

如果用nginx的话不会是瓶颈吧,只是做了下转发,文档只是推荐这样做,你也可以直连gateway

  • 悉地网 2024-04-07

    感觉这样浪费资源啊

  • 悉地网 2024-04-07

    特别是聊天用户多的时候

  • lunzi 2024-04-07

    哈哈,那就直连gateway,我记得很清楚一个事儿,以前和一个同事讨论字段用char还是varchar,刚开始学sql的时候字段长度固定说是最好用char,varchar会多一位记录长度,同事说现在的电脑性能,不需要考虑那个

  • 悉地网 2024-04-07

    这个属于优化细节了

  • 悉地网 2024-04-07

    如果GatewayWorker进程宕机了,怎么办

  • lunzi 2024-04-07

    gateway只是负责长连接,没有业务逻辑,不会那么容易宕机吧,分布式部署,哪个宕机就重启O_o

  • 悉地网 2024-04-07

    能不能进程守护啊?宕机自动重启?

  • lunzi 2024-04-07

    -d啊,不过我用的supervisor,你也可以试试pm2

  • 悉地网 2024-04-07

    是第三方的吗

Tinywan

首次初始化和鉴权走web服务器,其他的直连就行了

walkor

做一个系统稳定性、可扩展、易用、可维护、性能这几点要综合考虑达到一个平衡,不能一味追求性能。

业务逻辑压力要么在web,要么在businessWorker,对于服务器来说都是一样的压力,给谁都差不多。
如果在web做业务,没有学习成本,直接就可以开发了,后面扩展、维护也非常方便。
如果非要在businessWorker做业务,需要你有很强的整合能力,将mvc的数据库等组件移植到businessWorker,还要考虑数据库连接 redis等连接保活问题。并且要保证业务处理足够快,因为一个businessWorker进程卡顿可能影响整个服务消息传递的顺畅性。

  • 悉地网 2024-04-09

    这确实需要很强的专业性,像作者这样的就好了

  • 悉地网 2024-04-10

    所以还是在web端处理业务逻辑比较合理性

  • 悉地网 2024-04-10

    感觉还是直连比较符合即时通讯,每次发消息都得经过web感觉跟轮询有点像,不太符合常理

🔝