消息机制

JMS 消息传送模型 : 　　 消息传送机制 , 是基于 拉取 (pull) 或者 轮询 (polling) 的方式. JMS 具备两种 " 消息传送模型 ": P2P 和 Pub/sub. (1) P2P： 点对点消息传送模型 , 允许 JMS 客户端通过队列 (queue) 这个虚拟通道来同步或 异步发送消息 ; 消息的生产者为 Sender, 消费者为 receiver . 　　　　 receiver 主动到队列中请求消息 , 而不是 JMS 提供者将消息推送到客户端 ; 　　　　 主要原因是一个队列通道可能有多个 receiver, 每个 receiver 可能对消息的处理速率不同 ( 因处理消息而造成的阻塞时间不同 ), 对于 JMS 提供者而言 , 它无法意识到哪个 receiver 处于 " 空闲 " 状态 , 如果 JMS 提供者主动推送会造成通道的阻塞或者消息在客户端积压等问题 ; 所以基于客户端 pull 的方式 , 当 receiver 空闲时向 JMS 提供者请求消息 , 很好的解决了这个问题 , 而且还能进行良好的 " 负载均衡 ". 　　 Queue 中的消息如果被某个 recervier 成功接收 ( 确认成功 ) 后 , 消息就会被移除 . 　　 P2P 消息传送模式即支持异步 " 即发即失 ", 也支持同步的 " 请求 / 应答 " . (2)

原创声明 本文作者：黄小斜 转载请务必在文章开头注明出处和作者。 什么是消息队列 “RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词，可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消息队列的一些基本理论。如果你是老手，你可能从本文学到你之前不曾注意的一些关于消息队列的重要概念，如果你是新手，相信本文将是你打开消息队列大门的一板砖。 根据百度百科的说法，“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。` 为什么要使用消息队列 我觉得使用消息队列主要有两点好处： 1.通过异步处理提高系统性能（削峰、减少响应所需时间）; 2.降低系统耦合性。如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。 《大型网站技术架构》第四章和第七章均有提到消息队列对应用性能及扩展性的提升。 在我平时的日常工作中，用到消息队列的场景可不少，比如，我有一个定时任务需要在A应用每天7点开始调度，那么定时任务系统如何告诉这个A应用呢

原创声明 本文作者：黄小斜 转载请务必在文章开头注明出处和作者。 什么是消息队列 “RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词，可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消息队列的一些基本理论。如果你是老手，你可能从本文学到你之前不曾注意的一些关于消息队列的重要概念，如果你是新手，相信本文将是你打开消息队列大门的一板砖。 根据百度百科的说法，“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。` 为什么要使用消息队列 我觉得使用消息队列主要有两点好处： 1.通过异步处理提高系统性能（削峰、减少响应所需时间）; 2.降低系统耦合性。如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。 《大型网站技术架构》第四章和第七章均有提到消息队列对应用性能及扩展性的提升。 在我平时的日常工作中，用到消息队列的场景可不少，比如，我有一个定时任务需要在A应用每天7点开始调度，那么定时任务系统如何告诉这个A应用呢

消息通信机制NSNotificationCenter的学习。最近写程序需要用到这类，研究了下，现把成果和 NSNotificationCenter是专门供程序中不同类间的消息通信而设置的，使用起来极为方便， 长话短说。 设置通知，就是说要在什么地方（哪个类）接受通知，一般在初始化中做。 [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(test:) name:@"test" object:nil]; 我仅对以上参数做以说明：addObserver　这个是观察者，就是说　在什么地方接收通知; selector　这个是收到通知后，调用何种方法; name：　这个是通知的名字，也是通知的唯一标示，编译器就通过这个找到通知的。 发送通知，就是说此时要调用观察者处的方法。 [[NSNotificationCenter defaultCenter] postNotificationName:@"test"　object:searchFriendArray]; 我仅对以上参数做以说明： postNotificationName：通知的名字，也是通知的唯一标示，编译器就通过这个找到通知的。 object：传递的参数 发送通知时，默认调用test方法。 - (void) test:

最近写程序需要用到这类，研究了下，现把成果和大家分享。 NSNotificationCenter 是专门供程序中不同类间的消息通信而设置的，使用起来极为方便， 长话短说。 设置通知，就是说要在什么地方（哪个类）接受通知，一般在初始化中做。 [[ NSNotificationCenter defaultCenter] addObserver :self selector :@selector(test:) name:@"test " object : nil ]; 我仅对以上参数做以说明： addObserver 　这个是观察者，就是说　在什么地方接收通知 ; 　 selector 　这个是收到通知后，调用何种方法 ; 　 name ：　这个是通知的名字，也是通知的唯一标示，编译器就通过这个找到通知的。 发送通知，就是说此时要调用观察者处的方法。 [[NSNotificationCenter defaultCenter ] postNotificationName :@"test"　 object : searchFriendArray ]; 我仅对以上参数做以说明： postNotificationName ：通知的名字，也是通知的唯一标示，编译器就通过这个找到通知的。 object ：传递的参数 发送通知时，默认调用 test 方法。 - ( void ) test:(

　　IOS的消息机制其实是观察者模式的一个实践。你对某个事件感兴趣，那就就去注册成为他的观察者，这样当这个事件发生时就会收到人家的通知啦，就这么简单。还记得我们在《IOS之MVC》中说过，model不能直接调用controller，但是可以通过某种特殊的手段，间接的告诉controller去干什么，从而达到调用的目的。通过发送消息可以达到代码的彻底解耦。 　　消息机制的主要流程是： 　　 　　与notification相关的类及方法使用： NSNotification 　　NSNotification封装了一些信息是的通过NSNotificationCenter发送消息的时候可以携带一些额外的信息。一个NSNotification对象包括一个name，object和一个额外的dictionary。name是用来标识一个消息的tag，object是消息的发送者想告诉消息接受者的一个对象(通常是消息的发送者)，而dic存储了一些消息相关的信息。NSNotification是不可变的对象。 　　你可以通过下面的这些方法创建一个NSNotification对象： 　　 + notificationWithName:object: 　　+ notificationWithName:object:userInfo: 　　 – initWithName:object:userInfo: 　　-

作者:FlyElephant 出处: http://www.cnblogs.com/xiaofeixiang iOS中委托模式和消息机制基本上开发中用到的比较多，一般最开始页面传值通过委托实现的比较多，类之间的传值用到的比较多，不过委托相对来说只能是一对一，比如说页面A跳转到页面B，页面的B的值改变要映射到页面A，页面C的值改变也需要映射到页面A，那么就需要需要两个委托解决问题。NSNotificaiton则是一对多注册一个通知，之后回调很容易解决以上的问题。 基础概念 iOS消息通知机制算是同步的，观察者只要向消息中心注册， 即可接受其他对象发送来的消息，消息发送者和消息接受者两者可以互相一无所知，完全解耦。这种消息通知机制可以应用于任意时间和任何对象，观察者可以有多个，所以消息具有广播的性质，只是需要注意的是，观察者向消息中心注册以后，在不需要接受消息时需要向消息中心注销，属于典型的观察者模式。 消息通知中重要的两个类： （1）NSNotificationCenter: 实现NSNotificationCenter的原理是一个观察者模式，获得NSNotificationCenter的方法只有一种，那就是[NSNotificationCenter defaultCenter] ，通过调用静态方法defaultCenter就可以获取这个通知中心的对象了

99% 的人都能看懂的「补偿」以及最佳实践 也许你对降级已经有了一些认识，这次，我们来聊一聊在保证对外高可用的同时，憋出的“内伤”该如何通过「补偿」机制来自行消化。 「补偿」机制的意义 以电商的购物场景为例： 客户端 ----> 购物车微服务 ----> 订单微服务 ----> 支付微服务。 这种调用链非常普遍。 那么为什么需要考虑补偿机制呢？ 正如之前几篇文章所说，一次跨机器的通信可能会经过 DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。 而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。 但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。 可能你会问，之前也看到过「补偿」和「事务补偿」或者「重试」，它们之间的关系是什么？ 你其实可以不用太纠结这些名字，从目的来说都是一样的。就是一旦某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。 题外话：在笔者看来，不管用什么方式，只要通过额外的方式解决了问题都可以理解为是「补偿」，所以「事务补偿」和「重试」都是「补偿」的子集。前者是一个逆向操作，而后者则是一个正向操作。 只是从结果来看，两者的意义不同。「事务补偿」意味着“放弃”

1. 什么是RocketMQ？ 　　 　　 　　是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。 　　Producer、Consumer、队列都可以分布式。 　　 Producer 吐一些队列轮流収送消息，队列集合称为Topic，Consumer 如果做广播消费，则一个consumer 　　实例消费返个Topic 对应的所有队列，如果做集群消费，则多个Consumer 实例平均消费返个topic 对应的 　　队列集合。 　　能够保证严格的消息顺序 　　提供丰富的消息拉叏模式 　　高效的订阅者水平扩展能力 　　实时的消息订阅机制 　　亿级消息堆积能力 　　较少的依赖 　　RocketMQ作为阿里巴巴的两大分布式技术之一，是一款纯java、分布式、队列模型的开源消息中间件，他参考了Java的JMS规范，但是它并没有遵循JMS的规范，经历了淘宝双十一的洗礼，在功能和性能上据说是远超ActiveMQ。 2. RocketMQ发展史 　　1. Metaq(Metamorphsis) 1.x 　　　由开源社区killme2008维护，开源社区非常活跃。 　　　github地址：https://github.com/killme2008/Metamorphosis 　　2. Metaq 2.x 　　　于2012年10月份上线，在淘宝内部被广泛使用。 　　3.

Redis提供了发布订阅功能，可以用于消息的传输，Redis的发布订阅机制包括三个部分，分别是发布者、订阅者、频道(channel)。注意：redis属于即发即弃的机制，信息发送后则会丢失，如果订阅者断网就收不到该信息了。这里的机制是客户端绑定了发布者，和订阅者。channel属于服务端。发布者客户端发送一条消息到channel后，channel会将消息发送至订阅者，同时这条消息它不会存储，也不管订阅者是否能成功接收到消息。使用场景应该属于哪种不重要的消息队列环境。 发布者和订阅者都是Redis客户端，channel则为Redis服务端，发布者将消息发送到某个频道，订阅了这个频道的订阅者就能接收到这条消息。Redis的这种发布订阅机制与基于主题的发布订阅类似，channel相当于主题。 (1)发送消息 Redis采用PUBLISH命令发送消息，其返回值为接收该消息的订阅者的数量。 127.0.0.1:6379> PUBLISH redis123 "hello" //表示有两个订阅者数量 (integer) 2 (2)订阅某个频道 Redis采用SUBSCRIBE命令订阅某个频道，其返回值包括客户端订阅的频道，目前已订阅的频道数量，以及接收到的消息，其中subscribe表示已经成功订阅了某个频道 Reading messages... (press Ctrl-C to quit)