Golang的sync的包有一个并发原语WaitGroup，在日常开发中比较的有用。

WaitGroup的用途：它能够一直等到所有的goroutine执行完成，在其期间会会阻塞主线程的执行，直到所有的goroutine执行完成。

这里要注意一下，在其中的多个goroutine 的执行结果是没有顺序的，调度器不能保证多个 goroutine 执行次序，且进程退出时不会等待它们结束。

WaitGroup总共有三个方法：Add(delta int), Done() 和 Wait()。简单的说一下这三个方法的作用。

Add: 添加或者减少等待goroutine的数量

Done: 相当于Add(-1)

Wait: 执行阻塞，直到所有的WaitGroup数量变成0

举个例子

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var wg sync.WaitGroup

    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(n int) {
            defer wg.Done(),注意这个Done的位置，是另一个函数
            // 也可以将 defer wg.Done() 换成 defer wg.Add(-1)
            EchoNumber(n)
        }(i)
    }

    wg.Wait()
}

func EchoNumber(i int) {
    time.Sleep(3e9)
    fmt.Println(i)
}

golang中的同步是通过 sync.WaitGroup 来实现的。它实现了一个类似队列的结构，可以一直向队列中添加任务，当任务完成后便从队列中删除，如果队列中的任务没有完全完成，可以通过 Wait() 函数来出发阻塞，防止程序继续进行，直到所有的队列任务都完成为止．

这篇文章主要介绍了Go语言的GOPATH与工作目录详解,本文详细讲解了GOPATH设置、应用目录结构、编译应用等内容,需要的朋友可以参考下

GOPATH设置

go 命令依赖一个重要的环境变量：$GOPATH

（注：这个不是Go安装目录( GOROOT)。下面以笔者的工作目录为说明，请替换自己机器上的工作目录。）

在类似 Unix 环境大概这样设置：

export GOPATH=/home/apple/mygo

为了方便，应该把新建以上文件夹，并且把以上一行加入到 .bashrc 或者 .zshrc 或者自己的 sh 的配置文件中。

Windows 设置如下，新建一个环境变量名称叫做GOPATH：

GOPATH=c:mygo

GOPATH允许多个目录，当有多个目录时，请注意分隔符，多个目录的时候Windows是分号，Linux系统是冒号，当有多个GOPATH时，默认会将go get的内容放在第一个目录下

以上 $GOPATH 目录约定有三个子目录：

1.src 存放源代码（比如：.go .c .h .s等）

2.pkg 编译后生成的文件（比如：.a）

3.bin 编译后生成的可执行文件（为了方便，可以把此目录加入到 $PATH 变量中，如果有多个gopath，那么使用${GOPATH//://bin:}/bin添加所有的bin目录）

以后我所有的例子都是以mygo作为我的gopath目录

应用目录结构

建立包和目录：$GOPATH/src/mymath/sqrt.go（包名：”mymath”）

以后自己新建应用或者一个代码包都是在src目录下新建一个文件夹，文件夹名称一般是代码包名称，当然也允许多级目录，例如在src下面新建了目录$GOPATH/src/github.com/astaxie/beedb 那么这个包路径就是“github.com/astaxie/beedb”，包名称是最后一个目录beedb

cd $GOPATH/src
mkdir mymath

新建文件sqrt.go，内容如下：

// $GOPATH/src/mymath/sqrt.go源码如下：
package mymath

func Sqrt(x float64) float64 {
  z := 0.0
  for i := 0; i < 1000; i++ {
    z -= (z*z - x) / (2 * x)
  }
  return z
}

这样我的应用包目录和代码已经新建完毕，注意：一般建议package的名称和目录名保持一致

序言

新浪微博在2014年3月公布的月活跃用户（MAU）已经达到1.43亿，2014年新年第一分钟发送的微博达808298条，如此巨大的用户规模和业务量，需要高可用（HA）、高并发访问、低延时的强大后台系统支撑。

微博平台第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。

随着应用规模的增长，衍生出的第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。

在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。

我们先看一张微博的核心业务图（如下），是不是非常复杂？但这已经是一个简化的不能再简化的业务图了，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠地发布新产品新功能。

第三代技术体系

微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层；在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图：

如上图所示，正交分解法将整个图分解为3*4=12个区域，每个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构。

下面详细介绍水平方向与垂直方向的设计原则，尤其会重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。

水平分层

水平维度的划分，在大中型互联网后台业务系统的设计中非常基础，在平台的每一代技术体系中都有体现。这里还是简单介绍一下，为后续垂直维度的延伸讲解做铺垫：

1. 接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（Feed）服务、用户关系服务及通讯服务（单发私信、群发、群聊）。
2. 服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类。图中使用泳道隔离，表示它们的独立性。另外一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
3. 资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。

水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。

与分层模型相对应，微博系统中的服务器主要包括三种类型：前端机（提供 API 接口服务）、队列机（处理上行业务逻辑，主要是数据写入）和存储（mc、mysql、mcq、redis 、HBase等）。

垂直延伸技术架构

随着业务架构的发展和优化，平台研发实现了许多卓越的中间件产品，用来支撑核心业务，这些中间件由业务驱动产生，随着技术组件越来越丰富，形成完备的平台技术框架，大大提升了平台的产品研发效率和业务运行稳定性。

区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台，下面介绍一下其中的核心组件。

接口层Web V4框架

接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用了Spring的面向切面（AOP）设计理念。接口框架基于Jersey 进行二次开发，基于annotation定义接口(url, 参数)，内置Auth、频次控制、访问日志、降级功能，支撑接口层监控平台与服务治理，同时还有自动化的Bean-json/xml序列化。

服务层框架

服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。

MCQ消息队列

消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接提高了DB操作性能，另外一个应用场景，平台通过消息队列，向搜索、大数据、商业运营部门提供实时数据。

微博平台内部大量使用的MCQ(SimpleQueue Service Over Memcache)消息队列服务，基于MemCache协议，消息数据持久化写入BerkeleyDB，只有get/set两个命令，同时也非常容易做监控（stats queue），有丰富的client library，线上运行多年，性能比通用的MQ高很多倍。

Motan RPC框架

微博的Motan RPC服务，底层通讯引擎采用了Netty网络框架，序列化协议支持Hessian和Java序列化，通讯协议支持Motan、http、tcp、mc等，Motan框架在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了High Availability与Load Balance策略（支持灵活的FailOver和FailFast HA策略，以及Round Robin、LRU、Consistent Hash等Load Balance策略），服务治理方面，生成完整的服务调用链数据，服务请求性能数据，响应时间（Response Time）、QPS以及标准化Error、Exception日志信息。

资源层框架

资源层的框架非常多，有封装MySQL与HBase的Key-List DAL中间件、有定制化的计数组件，有支持分布式MC与Redis的Proxy，在这些方面业界有较多的经验分享，我在这里分享一下平台架构的对象库与SSD Cache组件。

对象库

对象库支持便捷的序列化与反序列化微博中的对象数据：序列化时，将JVM内存中的对象序列化写入在HBase中并生成唯一的ObjectID，当需要访问该对象时，通过ObjectID读取，对象库支持任意类型的对象，支持PB、JSON、二进制序列化协议，微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象，一共定义了几十种对象类型，并抽象出标准的对象元数据Schema，对象的内容上传到对象存储系统（Sina S3）中，对象元数据中保存Sina S3的下载地址。

SSDCache

随着SSD硬盘的普及，优越的IO性能使其被越来越多地用于替换传统的SATA和SAS磁盘，常见的应用场景有三种：1）替换MySQL数据库的硬盘，目前社区还没有针对SSD优化的MySQL版本，即使这样，直接升级SSD硬盘也能带来8倍左右的IOPS提升；2）替换Redis的硬盘，提升其性能；3）用在CDN中，加快静态资源加载速度。

微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为 Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。

上篇文章我们介绍了 amqp扩展在windows下的安装方法，这里我们看一下用法。

消费者：接收消息

逻辑： 创建连接–>创建channel–>创建交换机–>创建队列–>绑定交换机/队列/路由键–>接收消息

<?php
/*************************************
* PHP amqp(RabbitMQ) Demo - consumer
* Author: Linvo
* Date: 2012/7/30
*************************************/
//配置信息
$conn_args = array(
    'host' => '192.168.1.93',
    'port' => '5672',
    'login' => 'guest',
    'password' => 'guest',
    'vhost'=>'/'
);
$e_name = 'e_linvo'; //交换机名
$q_name = 'q_linvo'; //队列名
$k_route = 'key_1'; //路由key

//创建连接和channel
$conn = new AMQPConnection($conn_args);
if (!$conn->connect()) {
    die("Cannot connect to the broker!\n");
}
$channel = new AMQPChannel($conn);

//创建交换机
$ex = new AMQPExchange($channel);
$ex->setName($e_name);
$ex->setType(AMQP_EX_TYPE_DIRECT); //direct类型
$ex->setFlags(AMQP_DURABLE); //持久化
echo "Exchange Status:".$ex->declare()."\n";

//创建队列
$q = new AMQPQueue($channel);
$q->setName($q_name);
$q->setFlags(AMQP_DURABLE); //持久化
echo "Message Total:".$q->declare()."\n";

//绑定交换机与队列，并指定路由键
echo 'Queue Bind: '.$q->bind($e_name, $k_route)."\n";

//阻塞模式接收消息
echo "Message:\n";
while(True){
    $q->consume('processMessage');
    //$q->consume('processMessage', AMQP_AUTOACK); //自动ACK应答
}
$conn->disconnect();

/**
* 消费回调函数
* 处理消息
*/
function processMessage($envelope, $queue) {
    $msg = $envelope->getBody();
    echo $msg."\n"; //处理消息
    $queue->ack($envelope->getDeliveryTag()); //手动发送ACK应答
}

生产者：发送消息

从php官方下载相应的版本 http://pecl.php.net/package/amqp，我这里使用的是1.4.0版本（ http://pecl.php.net/package/amqp/1.4.0/windows） 根据当前使用的php版本选择相应的扩展dll，下载后是一个压缩包，里面有两个dll扩展(php_amqp.dll和rabbitmq.1.dll)。

我的环境是64位的,php5.5.12.所以使用的是 http://windows.php.net/downloads/pecl/releases/amqp/1.4.0/php_amqp-1.4.0-5.5-ts-vc11-x64.zip

1.将php_amqp.dll放在php的ext目录里，然后修改php.ini文件，在文件的最后面添加两行

[amqp\]
extension=php_amqp.dll

2.将rabbitmq.1.dll文件放在php的根目录里(也就是ext目录的父级目录)，然后修改apache的httpd.con文件，文件尾部添加一行

LoadFile "d:/wamp/bin/php/php5.5.12/rabbitmq.1.dll"

这里的路径根据情况修改，我这里使用的wampserver软件。

3.重启apache，并查看phpinfo信息。只要看到amqp 字样即可。

下面我们看一下rabbitmq扩展amqp的用法: 用PHP尝试RabbitMQ（amqp扩展）实现消息的发送和接收

Pull Request是Bitbucket、GitHub等源代码托管系统为了方便开发者之间协作而提供的一个功能，它提供了一个用户友好的Web界面来帮助审查人员进行代码审查。开发人员可以通过GitHub发出Pull Requests要求请求他人将程序拉下来进行代码审查。一个好的Pull Request不仅仅只是代码的事情，还牵涉到代码审查者对代码的审查，所以开发者不仅要写出好的代码，还必须迎合审查者的审查工作，才能给使得自己贡献的代码顺利通过审查并合并到master分支。现对丹麦的程序员、软件架构师、独立顾问Mark Seemann在自己博客中发布的一篇题为《关于Pull Request的十个建议》的文章进行一个全面的整理，以供读者阅读和参考。具体内容如下：

1. 进行较小的Pull Request

一个小且集中的Pull Request会使得提交的代码更加容易通过审核。据Mark Seemann根据自己的经验透漏，对提交代码进行审查所花费的时间是随着代码大小呈指数增长，而非线性增长；Pull Request多大才合适与Pull Request做了什么相关，最好少于12个文件的改变。如果Pull Request非常大，审查者就需要安排连续、相对比较长的时间进行审查，就会造成审查过程的延迟。

** **

2. 每个Pull Request只做一件事

就如软件设计模式中的单一责任原则所指：一个类只负责一个功能领域中的相应职责，因此一个Pull Request也应只关注一件事情。如果一次Pull Request做了多件事情的话，将会增加审查过程的延迟、审查被拒绝的可能性。

3. 注意代码行的字数,最好少于80个字

代码审查者会使用不同的审查工具来审查提交的代码，并且GitHub和Stash还提供了不同形式的视图，这样就使得代码审查者能通过不同视图非常方便来审查用户的提交。如果代码行比较宽的话，审查者就不能在一个屏幕或者半个屏幕中来阅读代码，不得不拖动滚动条来阅读代码。为了使得代码比较容易审查，每行代码最好少于80个字符。

4. 避免重新格式化代码

就算自己觉得应该改变当前代码的格式以适合自己的风格，但是请不要这么做。在源代码上，用户对每个字节的改变将会在不同的审查视图显示出来。有些审查者会选择忽略空格改变，但是有些审查者会审查这些代码，对这些格式化引起的代码审查属于不必要的审查。如果真需要解决空格问题的话，就需要在其他文件里移动代码、改变格式或者对代码做其他样式改变，并在Pull Request注释中给出相应的说明。

5. 确保代码能够编译通过

在提交Pull Request时，应该首先在自己的电脑上进行编译构建。在编译构建过程中，务必注意编译过程出现的警告，要把警告当作错误来对待，这些警告可能不会阻止编译，就有可能被忽略。然而，当用户Pull Request操作引起了很多编译警告的话，代码审查者就有可能拒绝对应的提交。

##

6. 确保提交的代码能够通过所有测试

即使问题代码已经做了自动化测试，但是在提交Pull Request时，也要务必保证针对代码的所有测试都必须通过。

7. 添加测试

为代码建立测试规则，即使出现问题的代码已经做过了自动化测试，最好也要为自己提交的代码也做下测试。

8.记录下自己提交的原因

利用文档对代码进行注释、对自己的代码直接进行注释、利用版本控制器提供的提交信息功能备注信息、利用Pull Request 管理系统（如GItHub或者Stash）添加自定义的Pull Request注释信息。

9. 编写符合编码规范的代码

按照代码正确性规则编写代码，并附上有效的代码注释、提交信息、Pull Request信息等。

10. 避免颠簸

不同审查者对Pull Request有可能具有不同的观点，这就会导致颠簸的情况，就需要用户移除冲突的提交和推送修改的分支，并备注有效的信息。

转： http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=204712314&idx=3&sn=c25d2651958926bef713bcb2413bb3e1&scene=0#rd

此教程只供参考，未进行整理！

使用fdisk命令查看新添加的硬盘

会看到类似这种页面信息的(说明：这里的图为已经有两个硬盘在使用了， 新添加的硬盘为sdc,尚未使用)

• 第一步：添加硬盘/新建分区（fdisk）
• 第二步：格式化分区（mkfs.ext4）
• 第三步：加载分区（mount）

1、第一步：添加硬盘/新建分区（fdisk）

a、查看当前系统所有硬盘及分区情况：fdisk -l

b、在指定的硬盘（例：/dev/sdb）上创建分区：fdisk /dev/sdb ， 根据提示进行下一步操作，如：查看帮助（h），新建分区（n），删除分区（d），查看分区情况（p）

c、分区成功后，写分区表并退出（w）

注：fdisk 支持硬盘最大尺寸为 2TB，更详细说明请参看 Linux 在线手册（man fdisk）或百度一下。

2、第二步：格式化分区（mkfs.ext4）

对新建分区（例：/dev/sdb1）进行格式化：mkfs.ext4 /dev/sdb1 。

3、第三步：加载分区

a、创建分区挂接目录，例：mkdir /disk-cache-1 和 mkdir /disk-cache-2

b、编辑 /etc/fstab 配置文件，将分区信息写进去。

添加：/dev/sdb1 /fikker ext3 defaults 0 0

c、加载新建分区：mount -a

参考： http://soft.chinabyte.com/461/7749961.shtml

对git不熟悉的我，经常把git提交搞得很乱，导致在master上有许多无用的commit，最终决定好好地看一下git的使用教程，却不小心发现了还有一个git-flow的工具可以帮助我管理好git项目的代码。

git-flow在ubuntu上使用比较简单。首先安装，可以通过apt-get来获取。命令如下：

sudo apt-get install git-flow

如果是在windows下，可以参考这篇文章进行安装： http://my.eoe.cn/sunxun/archive/158.html

如果你的git已经装好，则方便多了，下载下面两个地址的文件，并解压出getopt.exe和libintl3.dll放到git的安装目录的bin目录下。 http://sourceforge.net/projects/gnuwin32/files/util-linux/2.14.1/util-linux-ng-2.14.1-bin.zip/download http://sourceforge.net/projects/gnuwin32/files/util-linux/2.14.1/util-linux-ng-2.14.1-dep.zip/download

然后检出github上gitflow项目，如下命令：

1. git clone –recursive git://github.com/nvie/gitflow.git

进入并执行里面的contribmsysgit-install.cmd，提示复制成功，就可以了。

接下来是初始化项目。我在我原来的git项目上执行以下命令来进行初始化：

1. git flow init

它会创建或转换一个新的版本分支结构，当然在初始化的过程中，会问到以下这边问题，我都选择了默认：

1. Which branch should be used for bringing forth production releases?

2.    – master

3. Branch name for production releases: [master]

4. Branch name for “next release” development: [develop]

5. How to name your supporting branch prefixes?

6. Feature branches? [feature/]

7. Release branches? [release/]

8. Hotfix branches? [hotfix/]

9. Support branches? [support/]

10. Version tag prefix? []

完成之后，通过git branch 命令，可以看到它为我们新建好了一个develop的分支。

一 mpstat – 查看CPU使率信息 vmstat – 报告虚存统计数据 iostat – 报告CPU状态和存储I/O统计数据 netstat – 报告络栈各项参数 ps – 系统上运的进程及其状态 top – 报告占CPU和内存最的进程 sar – 报告系统活动状态 pidstat – 检查具体某个进程的CPU和内存情况 perf – 综合性能检查具

二 sysctl – 调整内核参数 strace – 跟踪进程的执 dtrace – 综合跟踪具 stap – 综合跟踪具 taskset – 绑定执CPU pmap – 报告进程内存映射信息 free – 报告物理帧和虚拟帧信息 dmesg – 系统启动信息，包括对各设备的监测 /proc – 各项系统参数读写接

三 /sys – 额外系统参数读写接 iotop – 类似top，但于检测I/O ionice – 类似nice，但于设置进程的I/O优先级 ifcong – 监测与配置络接 tcpdump – 捕获某个络接上的流量 nicstat – 监测卡状态 sysctl – 调整内核参数 strace – 跟踪进程的执 dtrace – 综合跟踪具 stap – 综合跟踪具 taskset – 绑定执CPU pmap – 报告进程内存映射信息 free – 报告物理帧和虚拟帧信息 dmesg – 系统启动信息，包括对各设备的监测 /proc – 各项系统参数读写接 mpstat – 查看CPU使率信息 vmstat – 报告虚存统计数据 iostat – 报告CPU状态和存储I/O统计数据 netstat – 报告络栈各项参数 ps – 系统上运的进程及其状态 top – 报告占CPU和内存最的进程 sar – 报告系统活动状态 pidstat – 检查具体某个进程的CPU和内存情况 perf – 综合性能检查具

no_ack 的用途：确保 message 被 consumer “成功”处理了。这里“成功”的意思是，（在设置了 no_ack=false 的情况下）只要 consumer 手动应答了 Basic.Ack ，就算其“成功”处理了。

对于ack简单的说就是“消费者”先从queue里读取一条数据，然后去处理，等处理完了，再给queue一个 ack 回应，表示处理完了，这时queue就将这条数据从队列中删除。如果不回应给队列ack的话，则这条消息仍然存在在queue中（这个也属于一种应用场景）。

• 在 no_ack=true 的情况下，RabbitMQ 认为 message 一旦被 deliver 出去了，就已被确认了，所以会立即将缓存中的 message 删除。所以在 consumer 异常时会导致消息丢失。

• no_ack=false（此时为 手动应答）

  在这种情况下，要求 consumer 在处理完接收到的 Basic.Deliver + Content-Header + Content-Body 之后才回复 Ack 。而这个 Ack 是 AMQP 协议中的 Basic.Ack 。此 Ack 的回复是和业务处理相关的，所以具体的回复时间应该要取决于业务处理的耗时。

如果Ack 未被 consumer 发回给 RabbitMQ 前出现了异常，RabbitMQ 发现与该 consumer 对应的连接被断开，之后将该 message 以轮询方式发送给其他 consumer （假设存在多个 consumer 订阅同一个 queue）。

参考： http://www.kankanews.com/ICkengine/archives/8904.shtml

对于ack的介绍可以参考：

RabbitMQ架构图

rabbitmq 架构图

基本概念

Broker：简单来说就是消息队列服务器实体。 Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。 Queue：消息队列载体，每个消息都会被投入到一个或多个队列。 Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。 Routing Key：路由关键字，exchange根据这个关键字进行消息投递。 vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。 producer：消息生产者，就是投递消息的程序。 consumer：消息消费者，就是接受消息的程序。 channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

操作流程

• （1）客户端连接到消息队列服务器，打开一个channel。
• （2）客户端声明一个exchange，并设置相关属性。
• （3）客户端声明一个queue，并设置相关属性。
• （4）客户端使用routing key，在exchange和queue之间建立好绑定关系。
• （5）客户端投递消息到exchange。

exchange 接收到消息后，就根据消息的 key 和已经设置的 binding，进行消息路由，将消息投递到一个或多个队列里。

总结 消费端：需要将queue与exchange绑定，通过routing_key来实现规则绑定。 生产端：将消息发送到exchange时附加上 routing_key 即可以了，exchange会根据上面的规则来决定放在哪个queue里。（要考虑Exchange Type设置）

Exchange类型有四种

这是一道常见面试题，共四类：

• 直连交换机：Direct exchange
• 扇形交换机：Fanout exchange
• 主题交换机：Topic exchange
• 首部交换机：Headers exchange

Direct Exchange  – 处理路由键。

需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键 “dog”，则只有被标记为“ dog”的消息才被转发，不会转发 dog.puppy，也不会转发 dog.guard，只会转发 dog。

direct exchange

Topic Exchange – 将路由键和某模式进行匹配。

此时队列需要绑定要一个模式上。符号“#”匹配一个或多个词，符号“”匹配不多不少一个词。因此“audit.#”能够匹配到“audit.irs.corporate”，但是“audit.” 只会匹配到“audit.irs”。

topic exchange

Fanout Exchange – 不需要routing key

你只需要简单的将队列绑定到交换机上。一个发送到交换机的消息都会被转发到与该交换机绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。Fanout交换机转发消息是最快的。

消息持久设置：

1. 将交换机置为可持久；

2. 将通道置为可持久

3. 消息发送时设置可持久。

当我们“生产”了一条可持久化的消息，尝试中断MQ服务，启动消费者获取消息，消息依然能够恢复。相反，则抛出异常。

上面三条必须全部设置，不然消息将无法持久化。

刚刚安装过的rabbitmq 消息队列，并启用了插件管理功能，3.3.1版中，处于安全的考虑，guest这个默认的用户只能通过http://localhost:15672 来登录，其他的IP无法直接使用这个账号。 这对于服务器上没有安装桌面的情况是无法管理维护的，除非通过在前面添加一层代理向外提供服务，这个又有些麻烦了，这里通过配置文件来实现这个功能。

只要编辑 /etc/rabbitmq/rabbitmq.config 文件，添加以下配置就可以了。

[ {rabbit, [{tcp_listeners, [5672]}, {loopback_users, [“asdf”]}]} ].

现在添加了一个新授权用户asdf，可以通过外网使用这个用户名和密码访问.(记得要先用命令添加这个命令才行,#rabbitmqctl  add_user asdf pwd123456)我是通过在管理平台里直接添加的用户和密码的，我的测试环境装有桌面的。 参考文档： http://www.rabbitmq.com/access-control.html

# rabbitmqctl add_user asdf pwd123456

# rabbitmqctl list_users
Listing users ...
asdf
guest   [administrator]

Setting permissions for user “asdf” in vhost “/” …

# rabbitmqctl set_permissions -p "/" asdf ".*" ".*" ".*"

# rabbitmqctl list_permissions -p /
Listing permissions in vhost "/" ...
asdf .* .* .*
guest .* .* .*

可以看到添加用户成功了，但不是administrator角色，这里我们也将asdf用户设置为administrator角色.

# rabbitmqctl set_user_tags asdf administrator
Setting tags for user "asdf" to [administrator] ..

# rabbitmqctl list_users
Listing users ...
asdf [administrator]
guest [administrator]

我用rpm包安装的rabbitmq，所以提供默认的配置参考文件(/usr/share/doc/rabbitmq-server-3.5.0/rabbitmq.config.example),如果你使用源码编译的话，可以找到一个默认的配置文件rabbitmq.config.example,点击这里下载此文件 rabbitmq.config

1      什么是RabbitMQ？

RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然：

单向解耦 双向解耦（如：RPC）

例如一个日志系统，很容易使用RabbitMQ简化工作量，一个Consumer可以进行消息的正常处理，另一个Consumer负责对消息进行日志记录，只要在程序中指定两个Consumer所监听的queue以相同的方式绑定到同一个exchange即可，剩下的消息分发工作由RabbitMQ完成。

使用RabbitMQ server需要：

1. ErLang语言包；

2. RabbitMQ安装包；

RabbitMQ同时提供了java的客户端（一个jar包）。

2      概念和特性

2.1      交换机（exchange）：

1. 接收消息，转发消息到绑定的队列。四种类型：direct, topic, headers and fanout

direct：转发消息到routigKey指定的队列

topic：按规则转发消息（最灵活）

headers：（这个还没有接触到）

fanout：转发消息到所有绑定队列

2. 如果没有队列绑定在交换机上，则发送到该交换机上的消息会丢失。

3. 一个交换机可以绑定多个队列，一个队列可以被多个交换机绑定。

4. topic类型交换器通过模式匹配分析消息的routing-key属性。它将routing-key和binding-key的字符串切分成单词。这些单词之间用点隔开。它同样也会识别两个通配符：#匹配0个或者多个单词，*匹配一个单词。例如，binding key：*.stock.#匹配routing key：usd.stcok和eur.stock.db，但是不匹配stock.nana。

还有一些其他的交换器类型，如header、failover、system等，现在在当前的RabbitMQ版本中均未实现。

5. 因为交换器是命名实体，声明一个已经存在的交换器，但是试图赋予不同类型是会导致错误。客户端需要删除这个已经存在的交换器，然后重新声明并且赋予新的类型。

6. 交换器的属性：

– 持久性：如果启用，交换器将会在server重启前都有效。

– 自动删除：如果启用，那么交换器将会在其绑定的队列都被删除掉之后自动删除掉自身。

– 惰性：如果没有声明交换器，那么在执行到使用的时候会导致异常，并不会主动声明。

2.2      队列（queue）：

1. 队列是RabbitMQ内部对象，存储消息。相同属性的queue可以重复定义。

2. 临时队列。channel.queueDeclare()，有时不需要指定队列的名字，并希望断开连接时删除队列。

3. 队列的属性：

– 持久性：如果启用，队列将会在server重启前都有效。

– 自动删除：如果启用，那么队列将会在所有的消费者停止使用之后自动删除掉自身。

– 惰性：如果没有声明队列，那么在执行到使用的时候会导致异常，并不会主动声明。

– 排他性：如果启用，队列只能被声明它的消费者使用。

这些性质可以用来创建例如排他和自删除的transient或者私有队列。这种队列将会在所有链接到它的客户端断开连接之后被自动删除掉。它们只是短暂地连接到server，但是可以用于实现例如RPC或者在AMQ上的对等通信。4. RPC的使用是这样的：RPC客户端声明一个回复队列，唯一命名（例如用UUID），并且是自删除和排他的。然后它发送请求给一些交换器，在消息的reply-to字段中包含了之前声明的回复队列的名字。RPC服务器将会回答这些请求，使用消息的reply-to作为routing key（默认绑定器会绑定所有的队列到默认交换器，名称为“amp.交换器类型名”）发送到默认交换器。注意这仅仅是惯例而已，可以根据和RPC服务器的约定，它可以解释消息的任何属性（甚至数据体）来决定回复给谁。

2.3      消息传递：

1. 消息在队列中保存，以轮询的方式将消息发送给监听消息队列的消费者，可以动态的增加消费者以提高消息的处理能力。

2. 为了实现负载均衡，可以在消费者端通知RabbitMQ，一个消息处理完之后才会接受下一个消息。

channel.basic_qos(prefetch_count=1)

11.2. 数值类型

MySQL支持所有标准SQL数值数据类型。这些类型包括严格数值数据类型(INTEGER、SMALLINT、DECIMAL和NUMERIC)，以及近似数值数据类型(FLOAT、REAL和DOUBLE PRECISION)。关键字INT是INTEGER的同义词，关键字DEC是DECIMAL的同义词。

BIT数据类型保存位字段值，并且支持MyISAM、MEMORY、InnoDB和BDB表。

作为SQL标准的扩展，MySQL也支持整数类型TINYINT、MEDIUMINT和BIGINT。下面的表显示了需要的每个整数类型的存储和范围。

对于数据类型与所保存的值的大小的计算方法为：

MySQL还支持选择在该类型关键字后面的括号内指定整数值的显示宽度(例如，INT(4))。该可选显示宽度规定用于显示宽度小于指定的列宽度的值时从左侧填满宽度。

显示宽度并不限制可以在列内保存的值的范围，也不限制超过列的指定宽度的值的显示。

当结合可选扩展属性ZEROFILL使用时， 默认补充的空格用零代替。例如，对于声明为INT(5) ZEROFILL的列，值4检索为00004。请注意如果在整数列保存超过显示宽度的一个值，当MySQL为复杂联接生成临时表时会遇到问题，因为在这些情况下MySQL相信数据适合原列宽度。

所有整数类型可以有一个可选(非标准)属性UNSIGNED。当你想要在列内只允许非负数和该列需要较大的上限数值范围时可以使用无符号值。

浮点和定点类型也可以为UNSIGNED。同数类型，该属性防止负值保存到列中。然而，与整数类型不同的是，列值的上范围保持不变。

如果为一个数值列指定ZEROFILL，MySQL自动为该列添加UNSIGNED属性。

对于浮点列类型，在MySQL中单精度值使用4个字节，双精度值使用8个字节。

FLOAT类型用于表示近似数值数据类型。SQL标准允许在关键字FLOAT后面的括号内选择用位指定精度(但不能为指数范围)。MySQL还支持可选的只用于确定存储大小的精度规定。0到23的精度对应FLOAT列的4字节单精度。24到53的精度对应DOUBLE列的8字节双精度。

MySQL允许使用非标准语法：FLOAT(M,D)或REAL(M,D)或DOUBLE PRECISION(M,D)。这里，“(M,D)”表示该值一共显示M位整数，其中D位位于小数点后面。例如，定义为FLOAT(7,4)的一个列可以显示为-999.9999。MySQL保存值时进行四舍五入，因此如果在FLOAT(7,4)列内插入999.00009，近似结果是999.0001。

MySQL将DOUBLE视为DOUBLE PRECISION(非标准扩展)的同义词。MySQL还将REAL视为DOUBLE PRECISION(非标准扩展)的同义词，除非SQL服务器模式包括REAL_AS_FLOAT选项。