消息机制

1. 背景： 1. 对于以下这段代码： 按照想法应该输出 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 但是，输出结果是： 0 1 2 3 4 5 6 7 8 9 2. 原因： 在goroutine还未来得及跑loop函数时，主函数main已经退出。 解决主函数退出太快最直接的方法是让主函数睡眠一段时间： 这次输出结果确实是两趟。 可是等待的办法并不好，因为并不知goroutine要执行多长时间，只能尽可能长的设置主函数的sleep，这样会让主函数执行时间远大于实际执行时间。 3. 需要找一个方法，让goroutine快执行完时通知主函数，即阻塞住主routine，类似Java中的A.join()函数（调用方必须等待A执行完毕返回后再返回），那么涉及多个goroutine间通信，go中的channel就起了这样的作用。 2. channel 1.定义： channel是Golang语言在语言层级提供的goroutine间的通信方式，可以使用channel在多个goroutine之间传递消息。 2.使用： channel是类型相关的，一个channel只能传递一种类型的值，传递类型需要在声明channel时指定。 3.声明： 1. var chanName chan ElementType 举例：声明一个传递int类型的channel：var ch

openstack RPC通信 Openstack 的主要组件有 Nova、Cinder、Neutron、Glance 等，分别负责云平台的计算、存储、网络资源管理。OpenStack 各组件之间是通过 REST 接口进行相互通信，而各组件内部则采用了RPC通信。 什么是RPC RPC即Remote Procedure Call(远程方法调用)，是Openstack中一种用来实现跨进程(或者跨机器)的通信机制。Openstack中同项目内(如nova, neutron, cinder…)各服务(service)均通过RPC实现彼此间通信。Openstack中还有另外两种跨进程的通信方式： 数据库和Rest API 。 Openstack中服务主要以进程的形式实现。也可以以线程的形式实现，但是Python中的线程是协作模型，无法发挥系统中多CPU(或多CPU核心)的能力。RCP只定义了一个通信接口，其底层的实现可以各不相同。目前Openstack中的主要采用AMQP的实现满足组件内部的松耦合性。 什么是AMQP AMQP即Advanced Message Queuing Protocol()是一种基于队列的可靠消息服务协议，具体可参考 http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol 。作为一种通信协议

原文地址 消息的可靠性是RabbitMQ的一大特色，那么RabbitMQ是如何保证消息可靠性的呢――消息持久化。 为了保证RabbitMQ在退出或者crash等异常情况下数据没有丢失，需要将queue，exchange和Message都持久化。 queue的持久化 queue的持久化是通过durable=true来实现的。 一般程序中这么使用： Connection connection = connectionFactory . newConnection (); Channel channel = connection . createChannel (); channel . queueDeclare ( "queue.persistent.name" , true , false , false , null ); 关键的是第二个参数设置为true,即durable=true. Channel类中queueDeclare的完整定义如下： /** * Declare a queue * @see com.rabbitmq.client.AMQP.Queue.Declare * @see com.rabbitmq.client.AMQP.Queue.DeclareOk * @param queue the name of the queue * @param durable

本篇的代码使用的前面两篇文章《RabbitMQ与Spring整合之消息生产方》和《RabbitMQ与Spring整合之消息消费方》的代码，这两篇文件里配置文件的名称不正确，不可直接运行。 一 自动确认机制 在服务消费者rabbitmq.xml 做修改： 添加了配置 acknowledge="auto"，这里来配置mq的确认机制，auto 自动确认，这也是默认缺省的配置。 文章来源: RabbitMQ 消息消费方处理消息时候抛出了异常

记录几个RabbitMQ使用过程中容易踩的那些坑： 简要代码如下，设置消息自动ack，会导致消息未处理完，出异常了，结果消息丢失了， 解决方法就是把代码里的true，改成false，并在消息处理完后发ack响应。 // 要监听队列，所以不能用using关闭channel通道 var channel = GetChannel(); var consumer = new EventingBasicConsumer(channel); channel . BasicConsume( queue , true , consumer); // 消息自动ack 为了解决问题1，做了改进，简要代码如下： var channel = GetChannel(); var consumer = new EventingBasicConsumer(channel); // 开启acknowledge机制，在接收事件里ack channel.BasicConsume(queue, false , consumer); consumer.Received += (sender, e) => { try { callback(e.Body, e.BasicProperties.Headers); ((EventingBasicConsumer) sender).Model.BasicNack(e

先来一张图: #### 下面简单的来描述一下HTTP Cache机制 ： 当资源资源第一次被访问的时候，http status返回200，在头部携带当前资源的描述信息，eg: 最后修改的时间:```Last-Modified``` 资源状态唯一标识:```Etag``` 资源在客户端缓存的过期时间:```Expires``` 同时浏览器会将资源缓存到cache目录，并保存文件描述信息。 当客户端第二次请求资源时，会先检查cache目录中是否含有该资源，如果有，并且还没到Expires设置的时间， 即文件还没有过期，那么此时客户端将直接从Cache目录中读取文件，而不再发送请求 如果资源已经过期，客户端会发送一次http请求到服务器，同时在header携带上次修改的时间： ```text If-Modified-Since Thu, 26 Nov 2009 13:50:19 GMT If-None-Match "8fb8b-14-4794674acdcc0" ``` 如果你对编程感兴趣或者想往编程方向发展，可以关注微信公众号【筑梦编程】，大家一起交流讨论！小编也会每天定时更新既有趣又有用的编程知识！ #### 为什么会返回上一次的信息呢？ web服务器在接收到请求时，会先解析header里面的信息，然后校验头部信息。 如果该资源文件从上次时间到现在都没有修改或者Etag信息没有变化，

不能再非主线程中修改UI控件属性，不建议在主线程中做耗时操作 UI线程 ：主线程Activity Thread Message: Handler发送和处理的消息，由MessageQueue管理 MessageQueue： 消息队列，用来存放Handler发送的消息，按照先进先出执行，内部使用的单链表的结构。 Handler： 负责发送消息和处理消息 Looper： 负责消息循环，创建MessageQueue并循环取出MessageQueue里面的Message，并交给相应的Handler进行处理 Looper package com.example.handerdemo; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.os.Bundle; import android.util.Log; import android.view.View; import android.widget.TextView; import java.lang.ref.WeakReference; public class MainActivity extends AppCompatActivity { TextView

一、消息机制概述 1.消息机制的简介 （1）Handler是什么 handler使Android给我们提供的用来更新UI的一套机制，也是一套消息处理机制；我们可以用它发送处理消息。 （2）Android为什么设计只能通过handler机制来更新ui？ 最根本问题使解决多线程并发问题。假设一个activity由多个线程去更新UI，并且都没有加锁机制，那么会造成更新界面错乱。如果都加锁则会造成性能下降； （3）在子线程中，进行耗时操作，执行完操作后，发送消息，通知主线程更新UI。这便是消息机制的典型应用场景。我们通常只会接触到Handler和Message来完成消息机制，其实内部还有两大助手来共同完成消息传递。 2.消息机制的模型 消息机制主要包含：MessageQueue，Handler和Looper这三大部分，以及Message，下面我们一一介绍。 Message：需要传递的消息，可以传递数据； MessageQueue：消息队列，但是它的内部实现并不是用的队列，实际上是通过一个单链表的数据结构来维护消息列表，因为单链表在插入和删除上比较有优势。主要功能向消息池投递消息(MessageQueue.enqueueMessage)和取走消息池的消息(MessageQueue.next)； Handler：消息辅助类，主要功能向消息池发送各种消息事件(Handler

MessageQueue 标签（空格分隔）： MessageQueue 911行，百行码 看的我瑟瑟发抖，涉及到了一些jni的知识还有Linux的管道，所以我推荐一篇： 聊一聊Android的消息机制 【源码分析】关于MessageQueue，这一篇就够了！ Android Handler机制(二)―MessageQueue源码解析 聊一聊Android的消息机制 文章来源: MessageQueue源码解析

1.微服务跟SOA有什么区别 可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。 2.优点 每个服务足够内聚，足够小，代码容易理解、开发效率提高；服务之间可以独立部署，微服务架构让持续部署成为可能；每个服务可以各自进行负载均衡扩展和数据库扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；容易扩大开发团队，可以针对每个服务（service）组件开发团队；提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；系统不会被长期限制在某个技术栈上。 3.缺点 开发人员要处理分布式系统的复杂性；开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性；服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹（PS：现在docker的出现适合解决这个问题）；应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。 4.微服务架构的关键问题 （1）微服务架构的通信机制 客户端与服务器之间的通信 在单块应用架构下