给几十万用户发消息,如何保证消息的即时性?

123咔哒 发布于 08/14 16:57
阅读 959
收藏 2

java开发语言,

比如发公众号消息短信消息

光查询用户就要花好多时间,要如何保证消息的即时性?

加载中
2
前端大师傅
前端大师傅

楼主可能对消息推送的机制不太了解。服务器是不可能主动向客户端推的。只有客户端上线时请求连接服务端,这样服务端的消息才能到客户端。网页端的应用H5都是这个原理。BS结构基本上都是被动式的。所谓的推送其实叫订阅推送。

首先客户端首先订阅,然后在客户端里面有个定时器会根据订阅的时间向服务端去请求。这时不存在楼主所谓的服务端主动轮询的情况出现!如果楼主这样想肯定实现不了。原因很简单,服务端根本不知道客户端在哪里,只有客户端主动与服务端联系以后并建立长连接的机制以后才能把消息实时转送(如socket这种)。

其次用户用什么设备(设备的外网ip)是服务端无法知道的,根本不存在服务端知道用户所在ip然后往用户那边发的可能性。所有的互动都是客户端发起的,然后只要不断开这时才可以实现所谓的消息推送。即只有客户端发出长连接以后服务端才能把消息推送过去。而且一般这个推送也不是服务端主动,而是客户端定时请求。当然socket请求的时候是无须像http那样每次发消息都是完整的4步,而是不需要连接,断开和中间4次握手。只用发消息然后等服务端响应消息。

最后我觉得很多朋友学开发认为就是编程,只要看到需求就想到用什么技术实现。但是并不知道这整个实现的过程。而很多自以为是的朋友觉得这个实现的过程很清清楚楚,但其实是他们以为了解的过程吹牛b还是可以。也只能这样,不能转化为开发的过程流程。就好像楼主问的问题,其实是楼主对技术原理不了解,而盲目的说要xx语言来实现。这已经不是初学者的问题。什么都来个java解决。java只是一门技术而不是解决问题的方法和过程。

gammey
gammey
回复 @不会飞的小龙人 : 所以对于你来说只需要做到接近服务商的水平就行了,超出部分完全就是浪费钱。因为即使你内部做的再高效,也不会提高效率。而服务商的效率和你的需求(几十万条数据的即时性),根本就是天差地别。
不会飞的小龙人
回复 @gammey : 当然核心效率因素,还是服务商,他才是发送到终端的决定者;自已系统内部做好优化也是必然;
不会飞的小龙人
回复 @gammey : 也不是没有意义;他的问题,更多是集中在,如何在已知的外部固定(有限)传输通道下,不增加外部服务成本,最大化将内部大批量数据,高效传送出去;比如,在短信运营商支持的最大并发数下,尽快完成几十万的用户消息发送;多服务多线程效率上总比单服务单线程要强些(举例而已);毕竟外部环境优化,会额外的增加生产成本(前提公司有服务器资源);城市内交通不畅也会影响出城效率;
gammey
gammey
回复 @不会飞的小龙人 : 所以说这种讨论没有意义啊,就像你如果需要解决两个城市之间的交通问题,两个城市之间只有一条两车道小路,你反而要去在城市内修各种高架桥,有意义吗?决定因素在于能否拓宽或新增两个城市之间的道路。
不会飞的小龙人
回复 @前端大师傅 : 对于运营商的发送速度不在开发的可控范围内,那是商务或服务商平台本身决定的;我的讨论是指数据到服务商的这个过程;外在因素很多有一定效率影响,但内部业务在可控合理的范围内达到最佳效率;理性讨论,多包容;
下一页
1
ubibi
ubibi
用户数据分片,放在不同机器的内存缓存里。思想就是把一个大任务,拆分成多个小任务,各个小任务并行去执行。
0
gammey
gammey

有这个必要吗?短信的服务商能帮你保证吗?

0
不会飞的小龙人

把数据放到redis中做队列,部署多个服务,每个服务适当的多线程机制轮询获取发送;消息发送的能力,就交给服务商吧;

123咔哒
123咔哒
几十万数据 放到队列中具体要怎么去操作 呢?
0
疏影横斜
疏影横斜

短信不可能~~大量短信,短信服务商直接给你风控了~~~微信也差不多~~

0
前端大师傅
前端大师傅

楼主知道短信网关吗?知道短信猫,知道云MAS吗?楼主除了知道java和sms这些之外,当然知道这些吹牛打屁没问题。做不了东西。sms走网关通过上下行表由运营商调度到客户端的短信的速度和你的代理级别有关。和java有一毛钱关系?还公众号发短消息推送,你除了知道公众号这三个字以外还知道个球呀。像楼主这种和同事吹牛逼说自己多牛掰,但上级给了任务却找个种借口完成不了,最后被一家又一家的公司开除的人,本人见得多了。

0
风--样的男子
风--样的男子

不如推送到自己的客户端吧。比如客户端主动获取消息。

0
红薯官方
红薯官方

几十万个用户能有多少数据量,如果一个用户记录8KB,80万*8KB=6400000KB=6250MB。

6GB的数据,从关系数据库过滤满足这些数据,如果索引使用得当,过滤条件比较简单,硬盘性能500MB/S,内存足够大,数据库服务器与应用服务器之间的网络千兆以上并且不堵塞,1~2分钟左右能取完数据(猜测取60万条,10000Row/Sec≈78.12MByte/Sec)。

什么是消息即时性,达到什么样的标准才算即时?你说是RTC类似这样的几百毫秒的类似吧。

好,那么:必定有延迟!没办法做到真正的没有延迟。你想要像聊天那么及时,那OK,必须客户端是跟服务端是有建立TCP长连接,这种可以做到消息即可就推送客户端,延迟可达几百毫秒级别。

论证需求必要性,什么样的消息推送需求需要如此讲究即时?真的有必要吗,产品他想过吗?这样做的成本值得吗?

好,如果非得要毫秒级别,那么又论:有什么办法可以毫秒级将这些消息生成并且存储给用户订阅。

假设你用发布-订阅的方式实现,采用数据库的方式来存储:

订阅消息表:用户ID(int)->订阅ID(int)

如果有60万个用户订阅,那么这个方式如果每秒写入1~3万条,那么就需要20~60秒(32Byte*30000Row/Sec=937.5KByte/Sec),就算最快最快你也要几秒。

这里就已经延迟了。经常遇到有APP消息推送延迟,朋友看到的消息而你还没有看到,你买卖交易成功而后很多秒才收到交易成功的提醒。

想要更即时,就需要保证客户端与服务端的沟通延迟最小,还要保证消息的生产延迟最小。

可以用:TCP长连接/WebSocket/HTTP2,Netty 框架有支持这些应用协议。

123咔哒
123咔哒
回复 @红薯官方 : 运营的需求 产品没有参与设计 ,cto那边提的,小公司有些流程还不是很规范
红薯官方
红薯官方
以上是不严谨的瞎说,事实上客户端所在的设备会让你的APP一直活着联网吗?为了即时性同学你又要开始APP不要被系统Kill的研究了,路漫漫。
返回顶部
顶部