1.前言 本文的上篇<IM消息送达保证机制实现(一):保证在线实时消息的可靠投递>中,我们讨论了在线实时消息的投递可以通过应用层的确认.发送方的超时重传.接收方的去重等手段来保证业务层面消息的不丢不重. 但实时在线投递针对的是消息收发双方都在线的情况(如当发送方用户A发送消息给接收方用户B时,用户B是在线的),那如果消息的接收方用户B不在线,系统是如何保证消息的可达性的呢?这就是本文要讨论的问题.(本文同步发布于:http://www.52im.net/thread-594-1-1.html)…

首先看微信官方的说法: 当用户主动发消息给公众号的时候(包括发送信息.点击自定义菜单.订阅事件.扫描二维码事件.支付成功事件.用户维权), 微信将会把消息数据推送给开发者,开发者在一段时间内(目前修改为48小时)可以调用客服消息接口,通过POST一个JSON数据 包来发送消息给普通用户,在48小时内不限制发送次数. 根据上面消息可以找到发消息的突破口[发送信息.点击自定义菜单.订阅事件.扫描二维码事件.支付成功事件.用户维权]这些事件 可以给公众号48小时的权限无限给触发的了以上事件的关注用户发…

在ESFramework 4.0 快速上手一文中,主要介绍了如何使用ESPlus.Rapid命名空间中的引擎来快速地构建基于TCP的网络通信系统,即使是使用ESPlus.Rapid来进行ESFramework快速开发,也还有很多可以介绍的内容,于是,我想再多写几篇文章来说明现实通信系统中的一些常见需求如何使用ESFramework快速实现.本文是为第一篇,介绍离线消息的原理和实现. 一.如何截获离线消息 阅读了ESFramework 4.0 快速上手朋友都知道,一个在线用户给另一个用户发送文本信…

终篇,三天所学所用,也就这些,如果需要大家要自己去查资料研究研究,功能其实可以很强大的 可惜界面做得不好,一大短处,从大一迄今没整好,主要是个人审美不行,哎 毕业季呀毕业季,明天摆摊卖书,再半月就可能和生活四年的兄弟姐妹说再见,考研考公务员工作的,各奔东西了,我也将南下杭州 感慨,天下无不散之筵席 在此祝所有刚毕业的,学业事业有成吧 不废话了,貌似最近太感性了,理科男,伤不起呀 1.离线消息 openfire本身是支持离线消息的,不需要进行额外处理,可以用spark测试下 使用smack,其实他…

先接收离线消息后再通知openfire上线 //获取离线消息 OfflineMessageManager offlineMessageManager=new OfflineMessageManager(connection); Iterator<Message> messages=offlineMessageManager.getMessages(); while (messages.hasNext()){ Message msg=messages.next(); System.out.pri…

消息的可靠性,即消息的不丢失和不重复,是im系统中的一个难点.当初qq在技术上(当时叫oicq)因为以下两点原因才打败了icq:1)qq的消息投递可靠(消息不丢失,不重复)2)qq的垃圾消息少(它antispam做得好,这也是一个难点,但不是本文重点讨论的内容)今天,本文将用十分通俗的语言,来讲述webim系统中消息可靠性的问题. 一.报文类型im的客户端与服务器通过发送报文(也就是请求包)来完成消息的传递,报文分为三种,请求报文(request,后简称为为R),应答报文(acknowledge…

  消息的可靠性,即消息的不丢失和不重复,是im系统中的一个难点.当初qq在技术上(当时叫oicq)因为以下两点原因才打败了icq:1)qq的消息投递可靠(消息不丢失,不重复)2)qq的垃圾消息少(它antispam做得好,这也是一个难点,但不是本文重点讨论的内容)今天,本文将用十分通俗的语言,来讲述webim系统中消息可靠性的问题. 一.报文类型im的客户端与服务器通过发送报文(也就是请求包)来完成消息的传递,报文分为三种,请求报文(request,后简称为为R),应答报文(acknowled…

一.kafka自带的消费机制 kafka有个offset的概念,当每个消息被写进去后,都有一个offset,代表他的序号,然后consumer消费该数据之后,隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了.下次我要是重启,就会继续从上次消费到的offset来继续消费. 但是当我们直接kill进程了,再重启.这会导致consumer有些消息处理了,但是没来得及提交offset.等重启之后,少数消息就会再次消费一次. 其他MQ也会有这种重复消费的问题,那么针对这种问题,我…

新浪微博:intsmaze刘洋洋哥.   storm框架中的kafkaspout类实现的是BaseRichSpout,它里面已经重写了fail和ack方法,所以我们的bolt必须实现ack机制,就可以保证消息的重新发送:如果不实现ack机制,那么kafkaspout就无法得到消息的处理响应,就会在超时以后再次发送消息,导致消息的重复发送.   但是回想一下我们自己写一个spout类实现BaseRichSpout并让他具备消息重发,那么我们是会在我们的spout类里面定义一个map集合,并以msg…

消息发布者向RabbitMQ进行消息投递时默认情况下是不返回发布者该条消息在broker中的状态的,也就是说发布者不知道这条消息是否真的抵达RabbitMQ的broker之上,也因此会发生消息丢失的情况. 对此,RabbitmQ提供了两种解决方案(以官方提供的SDK为例) 1.通过AMOP提供的事务机制: C#代码: try { channel.TxSelect(); channel.BasicPublish("yu.exchange", "yu.1", props…