消息机制

openstack各项目之间通过restful api进行通信，相同项目内不同组件进程组件之间通过消息总线进行通信。服务进程通过向消息总线上发送和获取消息，openstack是基于消息驱动的。 目前项目内部消息通信采用两种方式实现RPC和事件通知。 1、RPC（remote procedure call）主要包含call和cast两种（call：同步调用；cast：异步接口）。 2、事件通知（event notification） AMQP的架构如图所示 消息的处理分发主要有Exchange（消息交换）和Queue（消息队列）实现。 当producer将消息发送给消息服务器时，由Exchange和消息的routing key决定将消息发送给哪个queue队列，然后consumer在queue拿取自己感兴趣的消息进行处理。 Exchange并不会保存消息，只是对消息进行分发，负责指定消息发送到哪个队列上。 基于AMQP的RPC实现 client发送消息request给exchange，routing key指明到op_queue消息队列，并从res_queue取返回。 Exchange将消息推送到op_queue消息队列 server端从op_queue取出自己需要处理的数据，执行对应的任务，并将执行的响应结果发送给exchange，指明到res_queue

在之前的程序中已经使用过事件，例如在Qt程序的main()函数中创建一个应用对象QApplication，然后调用它的exec()函数，该exec()函数就是开始Qt的事件循环，在执行exec()函数之后，程序就会进入事件循环来监听应用程序的事件。当事件发生时，Qt将创建一个事件对象，Qt中所有事件都继承于QEvent，在事件对象创建完毕后，Qt将这个事件对象传递给QObject的event()函数。event()函数并不直接处理事件，而是根据事件对象的类型分派给特定的事件处理函数（Event handler）。 事件处理函数为protected类型，为虚函数，举例： 新建工程，基类为widget，在ui界面中添加label标签： 之后在工程界面添加类文件，由于是添加Label的槽函数，而文件基类中没有Label基类，所以新建的文件基类选为QWidget，之后在生成的mylabel.h与myabel.cpp文件中将基类改为QLabel，.h与.cpp文件如图所示： #ifndef MYLABEL_H #define MYLABEL_H #include <QLabel> class MyLabel : public QLabel { Q_OBJECT public: explicit MyLabel(QWidget *parent = 0); protected: //鼠标按下事件

一、Kafka的优势 Kafka是一个 分布式、可分区、多副本、高吞吐 ，基于zookeeper协调的分布式消息系统。 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 可扩展性：kafka集群支持热扩展 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） 高并发：支持数千个客户端同时读写。 二、Kafka的使用场景 Kafka主要适用的场景有：消息队列（构造实时流数据管道，它可以在系统或应用之间可靠地获取数据）、流处理（构建实时流式应用程序，请处理流数据）等。 日志收集：企业可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。 消息系统：解耦和生产者和消费者、缓存消息等。 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。 运营指标

Handler简介 Handler在日常开发中或多或少的都用过，在Android开发中是一个比较重要的知识点，希望通过这篇文章会使你对Handler有更全面的理解。 Hanlder设计的初衷或用途主要有两点： 在不同线程中执行任务。 执行定时任务。 Handler基本使用方式 下面代码展示了Handler使用的基本流程。 // 定义一个消息标识符 final int MESSAGE_WHAT_TEST = 100 ; // 1.创建一个Handler对象。 Handler handler = new Handler ( ) { @Override public void handleMessage ( Message msg ) { // 2. 重写handleMessage方法处理发送过来的Message // 判断Message类型 if ( msg . what == MESSAGE_WHAT_TEST ) { // 接收Message中的数据 String data = ( String ) msg . obj ; // 展示数据 textView . setText ( data ) ; } } } ; // 3. 新建一个Message对象承载要传输的数据。 Message msg = new Message ( ) ; // 4. 给Message设置一个标识符

转自：http://blog.csdn.net/haomcu/article/details/7371835 Linux中的进程间通信机制源自于Unix平台上的进程通信机制。Unix的两大分支AT&T Unix和BSD Unix在进程通信实现机制上的各有所不同，前者形成了运行在单个计算机上的System V IPC，后者则实现了基于socket的进程间通信机制。同时Linux也遵循IEEE制定的Posix IPC标准，在三者的基础之上实现了以下几种主要的IPC机制：管道(Pipe)及命名管道(Named Pipe)，信号(Signal)，消息队列(Message queue)，共享内存(Shared Memory)，信号量(Semaphore)，套接字(Socket)。通过这些IPC机制，用户空间进程之间可以完成互相通信。为了完成 内核空间 与 用户空间 通信，Linux提供了基于socket的Netlink通信机制，可以实现内核与用户空间数据的及时交换。 本文第2节概述相关研究工作，第3节与其他IPC机制对比，详细介绍Netlink机制及其关键技术，第4节使用KGDB+GDB组合调试，通过一个示例程序演示Netlink通信过程。第5节做总结并指出Netlink通信机制的不足之处。 2 相关研究 到目前Linux提供了9种机制完成内核与用户空间的数据交换，分别是内核启动参数

1 引言 Linux中的进程间通信机制源自于Unix平台上的进程通信机制。Unix的两大分支AT&T Unix和BSD Unix在进程通信实现机制上的各有所不同，前者形成了运行在单个计算机上的System V IPC，后者则实现了基于socket的进程间通信机制。同时Linux也遵循IEEE制定的Posix IPC标准，在三者的基础之上实现了以下几种主要的IPC机制：管道(Pipe)及命名管道(Named Pipe)，信号(Signal)，消息队列(Message queue)，共享内存(Shared Memory)，信号量(Semaphore)，套接字(Socket)。通过这些IPC机制，用户空间进程之间可以完成互相通信。为了完成内核空间与用户空间通信，Linux提供了基于socket的Netlink通信机制，可以实现内核与用户空间数据的及时交换。 本文第2节概述相关研究工作，第3节与其他IPC机制对比，详细介绍Netlink机制及其关键技术，第4节使用KGDB+GDB组合调试，通过一个示例程序演示Netlink通信过程。第5节做总结并指出Netlink通信机制的不足之处。 2 相关研究 到目前Linux提供了9种机制完成内核与用户空间的数据交换，分别是内核启动参数、模块参数与 sysfs、sysctl、系统调用、netlink、procfs、seq_file

一、RabbitMQ 1）生产者弄丢了数据 　　生产者将数据发送到rabbitmq的时候，可能因为网络问题导致数据就在半路给搞丢了。 1.可以选择用rabbitmq提供的事务功能，在生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，开始rabbitmq事务机制，基本上吞吐量会下来，因为太耗性能。 2.（推荐）可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。 　　 　　事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息

设计理念 1 时间换空间 1.1 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）， 反向代理缓存，应用端的缓存(memcache)，内存数据库，Buffer、cache机制（数据库，中间件等）。 1.2 索引 哈希、B树、倒排、bitmap 哈希索引:适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引:适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引:实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap:是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 2.1 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2.2 多进程

linux各种IPC机制 　　docker中的资源隔离，一种就是IPC的隔离。IPC是进程间通信。 下面的文章转载自https://blog.csdn.net/yyq_9623/article/details/78794775 原帖发表在IBM的developerworks网站上，是一个系列的文章，作者郑彦兴，通过讲解和例子演示了Linux中几种IPC的使用方式，我觉得很好，在这里做一个保留，能看完的话Linux IPC的基础是没有问题的了。 一）Linux环境进程间通信（一）管道及有名管道 http://www.ibm.com/developerworks/cn/linux/l-ipc/part1/ 二）Linux环境进程间通信（二）: 信号 上： http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html 下： http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html 三）Linux环境进程间通信（三）消息队列 http://www.ibm.com/developerworks/cn/linux/l-ipc/part3/ 四）Linux环境进程间通信（四）信号灯 http://www.ibm.com/developerworks

0. 项目结构 rabbitmq04 rabbitmq-provider rabbitmq-consumer common 1. 什么是消息回调 消息回调，其实就是消息确认(生产者推送消息成功，消费者接收消息成功) 2. 为什么要进行消息确认 经常会听到丢消息的字眼, 对于程序来说，发送者没法确认是否发送成功，消费者处理失败也无法反馈， 没有消息确认机制，就会出现消息莫名其妙的没了，也不知道什么情况 3. 生产者推送消息[确认] 0.前提：使用直连交换机完成消息的发送和接收 1.在rabbitmq-provider项目的application.yml文件上，添加消息确认的配置项 #1.开启 confirm 确认机制 spring.rabbitmq.publisher-confirms=true #2.开启 return 确认机制 spring.rabbitmq.publisher-returns=true #3.设置开启Mandatory,才能触发回调函数,无论消息推送结果怎么样都强制调用回调函数 spring.rabbitmq.template.mandatory=true server : port : 8081 servlet : context-path : /rabbitmq - provider spring : rabbitmq : virtual-host : /