① 在linux下安装rabbitmq失败怎么解决
RabbitMQ 是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成，因此也是继承了这些优点。
AMQP 里主要要说两个组件：Exchange 和 Queue （在 AMQP 1.0 里还会有变动），如下图所示，绿色的 X 就是 Exchange ，红色的是 Queue ，这两者都在 Server 端，又称作 Broker ，这部分是 RabbitMQ 实现的，而蓝色的则是客户端，通常有 Procer 和 Consumer 两种类型：
1：mq的安装需要Erlang，所以首先下载Erlang，下载地址：http://www.erlang.org/download.html直接下载源码，编译安装即可。
将下载好的tar包解压编译安装，如下命令：
tar -zxvf otp_src_R16B03-1.tar.gz
cd otp_src_R16B03-1
./configure && make install
安装过程中可能出现如下错误：
configure:error:
No curses library functions found
configure: error:/bin/sh'/home/niewf/software/erlang_R13B01/erts/configure'
failed for erts
解决方法：
yum list|grep ncurses
yum -y install ncurses-devel
yum install ncurses-devel
或者直接下载ncurses包编译安装。
下载地址：http://download.chinaunix.net/download/0008000/7242.shtml
tar zxvf ncurses.tar.gz #解压缩并且释放 文件包
cd ncurses #进入解压缩的目录（注意版本）
./configure #按照你的系统环境制作安装配置文件
make #编译源代码并且编译NCURSES库
su root #切换到root用户环境
make install #安装编译好的NCURSES库
完成后继续返回上一步操作。
2：安装python，如果系统中python版本低于2.5的话需要升级python到2.6以上，具体可参考：http://gavinshaw.blog.51cto.com/385947/610585
3：安装simplejson，直接下载simplejson源码包编译安装即可，下载地址：https://pypi.python.org/pypi/simplejson/。
下载simplejson源码包后，运行python setup.py install即可完成安装。
4：安装rabbit mq，下载地址：https://www.rabbitmq.com/install-generic-unix.html
下载后放入相应目录解压，进入%RABBITMQ_HOME%/sbin目录下运行：./rabbitmq-server start即可启动mq。
如果遇到如下错误，则参考http://leeon.me/a/rabbitmq-start-fail-note解决方案
ERROR: epmd error for host "xxx": address (cannot connect to host/port)
到此mq已经安装完成。
在%RABBITMQ_HOME%/sbin目录运行./rabbitmqctl status可查看当前mq状态。
同时mq也提供了界面查看当前mq状态，但是需要启用该插件功能，运行如下命令：
rabbitmq-plugins enable rabbitmq_management，然后在浏览器中输入：http://host-name:15672/#/即可访问，页面结果如下：
② 程序员应知应会之自动化运维那些事儿
对于一个开发人员来讲，可能运维并不是自己的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。
而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。
一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。
反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。
所以今天我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。
一、自动化运维的概念
随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。
所谓自 动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统7*24小时高效稳定运行 。这是所有业务系统运维的终极目标。
按照运维的发展成熟度来看， 运维大致可分为三个阶段 ：
（1）依靠纯手工，重复地进行软件的部署与运维；
（2）通过编写脚本，方便地进行软件的部署与运维；
（3）借助第三方工具，高效地进行软件的部署与运维；
二、自动化运维需要解决的问题
自动化运维通常来讲，需要解决以下几个问题： 自动部署配置、风险事前预警、故障事中解决、和故障事后管理 。
三、自动化运维的常用工具
自动化运维常用的工具包括以下几种：
1、Ansible
ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。
ansible具有如下一些特性：
(1)模块化：调用特定的模块，完成特殊的任务。
(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。
(3)支持自定义模块，可使用任何编程语言写模块。
(4)基于python语言实现。
(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。
(6)安全，基于OpenSSH
(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。
(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。
(9)较强大的多层解决方案role。
2、Chef
Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。
Chef 主要分为三个部分 Chef Server、Workstation 以及 Chef Client。用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上面实施安装和部署工作。所以，对于 Cookbook 地编写在整个自动化部署中起到了重要的作用。
Chef Server 包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。
Workstations 用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。
Chef命令行工具 是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。
Knife 用于与ChefNodes进行交互。
Test Kitchen 用于验证Chef代码
Chef-Repo 是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。
Nodes 由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes 是一台机器，例如物理云，云主机等。
Chef-Client 负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。
Cookbook 是Chef 框架的重要基础功能之一。在 Chef Server 对目标机器做安装部署的时候，是通过 Runlist。而 Runlist 里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook 上。而对于 Cookbook 来说，其中包含了多个组件，我们可以将 Cookbook 简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata 等信息。这些信息用于配置我们的目标机器。
3、Puppet
puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。
客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；
Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；
Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；
Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；
Puppet服务端再把客户端的执行结果写入日志。
4、Saltstack
SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。
在saltstack架构中服务器端叫Master，客户端叫Minion。
在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。
saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master 服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。
saltstack提供如下一些功能：
（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。
（2）配置管理/状态管理 ：（描述想到达到的状态，saltstack就会去执行）
（3）云管理(cloud)：用于管理云主机
（4）事件驱动：被动执行，当达到某个值会自动触发
这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：
③ 如何把程序从windows平台移植到linux平台
需要用到的技术举厅有：
1. 抽取其中用到的 Win32API, 分为通信类， 多线程类，时间字符串等函数类， 逐一封装成 Linux 的函数；
2. 调试移植后的整个代码库， 并作必要的调整和修正；
3. 需要 C++11/14 的辩芦经验；
4. 需要 Windows 和 Linux 高性能多线程 C++服务器程序开发和调试的正灶隐经验，
5. 需要 boost 及 zeromq, 以及异步通信库， 异步日志库等方面的经验；
④ 为啥linux使用zeromq出现未定义zmq
Windows下VS2008使用ZeroMQ说明一、下载ZeroMQ
二、编译ZeroMQ库文件
解压zeromq-4.0.3.zip文件，进入builds\msvc目录，用VS打开*.sln工程文件，编译生成解决方案。编译完成后，会在lib目录下生成dll和lib文件
三、编写简单的测试工程
用VS新建2个项目，一个是server端，一个是client端
将ZeroMQ源码项目的include目录下的两个文件“zmq.h”，“zmq_utils.h”拷贝至自己新建的工程
将ZeroMQ源码项目的lib目录下的两个文件“libzmq.dll”，“libzmq.lib”拷贝至自己新建的工程
将文件“zmq.h”，“zmq_utils.h”和“libzmq.lib”添加进自己新建的项目。
client端代码：
#include <stdio.h>
#include <iostream>
#include <string.h>
#include "zeroMQ/zmq.h"
#include "zeroMQ/zmq_utils.h"
int main(int argc,char** argv)
⑤ Linux下各种锁的理解和使用及总结解决epoll惊群问题(面试常考)-
锁出现的原因
临界资源是什么: 多线程执行流所共享的资源
锁的作用是什么, 可以做原子操作, 在多线程中针对临界资源的互斥访问... 保证一个时刻只有一个线程可以持有锁对于临界资源做修改操作...
任何一个线程如果需要修改，向临界资源做写入操作都必须持有锁，没有持有锁就不能对于临界资源做写入操作.
锁 ： 保证同一时刻只能有一个线程对于临界资源做写入操作 (锁地功能)
再一个直观地代码引出问题，再从指令集的角度去看问题
上述一个及其奇怪的结果，这个结果每一次运行都可能是不一样的，Why ？ 按照我们本来的想法是每一个线程 + 20000000 结果肯定应该是60000000呀，可以就是达不到这个值
为何？ (深入汇编指令来看) 一定将过程放置到汇编指令上去看就可以理解这个过程了.
a++; 或者 a += 1; 这些操作的汇编操作是几个步骤?
其实是三个步骤：
正常情况下，数据少，操作的线程少，问题倒是不大，想一想要是这样的情况下，操作次数大，对齐操作的线程多，有些线程从中间切入进来了，在运算之后还没写回内存就另外一个线程切入进来同时对于之前的数据进行++ 再写回内存, 啥效果，多次++ 操作之后结果确实一次加加操作后的结果。 这样的操作 (术语叫做函数的重入) 我觉得其实就是重入到了汇编指令中间了，还没将上一次运算的结果写回内存就重新对这个内存读取再运算写入，结果肯定和正常的逻辑后的结果不一样呀
来一幅图片解释一下
咋办? 其实问题很清楚，我们只需要处理的是多条汇编指令不能让它中间被插入其他的线程运算. （要想自己在执行汇编指令的时候别人不插入进来） 将多条汇编指令绑定成为一条指令不就OK了嘛。
也就是原子操作！！！
不会原子操作？操作系统给咱提供了线程的 绑定方式工具呀：mutex 互斥锁(互斥量)， 自旋锁(spinlock)， 读写锁（readers-writer lock） 他们也称作悲观锁. 作用都是一个样，将多个汇编指令锁成为一条原子操作 (此处的汇编指令也相当于如下的临界资源)
悲观锁：锁如其名，每次都悲观地认为其他线程也会来修改数据，进行写入操作，所以会在取数据前先加锁保护，当其他线程想要访问数据时，被阻塞挂起
乐观锁：每次取数据的时候，总是乐观地认为数据不会被其他线程修改，因此不上锁。但是在更新数据前， 会判断其他数据在更新前有没有对数据进行修改。
互斥锁
最为常见使用地锁就是互斥锁, 也称互斥量. mutex
特征，当其他线程持有互斥锁对临界资源做写入操作地时候，当前线程只能挂起等待，让出CPU，存在线程间切换工作
解释一下存在线程间切换工作 : 当线程试图去获取锁对临界资源做写入操作时候，如果锁被别的线程正在持有，该线程会保存上下文直接挂起，让出CPU，等到锁被释放出来再进行线程间切换，从新持有CPU执行写入操作
互斥锁需要进行线程间切换，相比自旋锁而言性能会差上许多，因为自旋锁不会让出CPU, 也就不需要进行线程间切换的步骤，具体原理下一点详述
加互斥量(互斥锁)确实可以达到要求，但是会发现运行时间非常的长，因为线程间不断地切换也需要时间, 线程间切换的代价比较大.
相关视频推荐
你绕不开的组件—锁，4个方面手撕锁的多种实现
“惊群”原理、锁的设计方案及绕不开的“死锁”问题
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享
自旋锁
spinlock.自旋锁.
对比互斥量(互斥锁)而言，获取自旋锁不需要进行线程间切换，如果自旋锁正在被别的线程占用，该线程也不会放弃CPU进行挂起休眠，而是恰如其名的在哪里不断地循环地查看自旋锁保持者(持有者)是否将自旋锁资源释放出来... （自旋地原来就是如此）
口语解释自旋：持有自旋锁的线程不释放自旋锁，那也没有关系呀，我就在这里不断地一遍又一遍地查询自旋锁是否释放出来，一旦释放出来我立马就可以直接使用 (因为我并没有挂起等待，不需要像互斥锁还需要进行线程间切换，重新获取CPU，保存恢复上下文等等操作)
哪正是因为上述这些特点，线程尝试获取自旋锁，获取不到不会采取休眠挂起地方式，而是原地自旋（一遍又一遍查询自旋锁是否可以获取）效率是远高于互斥锁了. 那我们是不是所有情况都使用自旋锁就行了呢，互斥锁就可以放弃使用了吗????
解释自旋锁地弊端：如果每一个线程都仅仅只是需要短时间获取这个锁，那我自旋占据CPU等待是没啥问题地。要是线程需要长时间地使用占据（锁）。。。 会造成过多地无端占据CPU资源，俗称站着茅坑不拉屎... 但是要是仅仅是短时间地自旋，平衡CPU利用率 + 程序运行效率 （自旋锁确实是在有些时候更加合适）
自旋锁需要场景：内核可抢占或者SMP(多处理器)情况下才真正需求 (避免死锁陷入死循环，疯狂地自旋，比如递归获取自旋锁. 你获取了还要获取，但是又没法释放)
自旋锁的使用函数其实和互斥锁几乎是一摸一样地，仅仅只是需要将所有的mutex换成spin即可
仅仅只是在init存在些许不同
何为惊群，池塘一堆, 我瞄准一条插过去，但是好似所有的都像是觉着自己正在被插一样的四处逃窜。 这个就是惊群的生活一点的理解
惊群现象其实一点也不少，比如说 accept pthread_cond_broadcast 还有多个线程共享epoll监视一个listenfd 然后此刻 listenfd 说来 SYN了，放在了SYN队列中，然后完成了三次握手放在了 accept队列中了, 现在问题是这个connect我应该交付给哪一个线程处理呢.
多个epoll监视准备工作的线程 就是这群 ()，然后connet就是鱼叉，这一叉下去肯定是所有的 epoll线程都会被惊醒 (多线程共享listenfd引发的epoll惊群)
同样如果将上述的多个线程换成多个进程共享监视 同一个 listenfd 就是(多进程的epoll惊群现象)
咱再画一个草图再来理解一下这个惊群:
如果是多进程道理是一样滴，仅仅只是将所有的线程换成进程就OK了
终是来到了今天的正题了: epoll惊群问题地解决上面了...
首先 先说说accept的惊群问题，没想到吧accept 平时大家写它的多线程地时候，多个线程同时accept同一个listensock地时候也是会存在惊群问题地，但是accept地惊群问题已经被Linux内核处理了: 当有新的连接进入到accept队列的时候，内核唤醒且仅唤醒一个进程来处理
但是对于epoll的惊群问题，内核却没有直接进行处理。哪既然内核没有直接帮我们处理，我们应该如何针对这种现象做出一定的措施呢?
惊群效应带来的弊端: 惊群现象会造成epoll的伪唤醒，本来epoll是阻塞挂起等待着地，这个时候因为挂起等待是不会占用CPU地。。。 但是一旦唤醒就会占用CPU去处理发生地IO事件， 但是其实是一个伪唤醒，这个就是对于线程或者进程的无效调度。然而进程或者线程地调取是需要花费代价地，需要上下文切换。需要进行进程(线程)间的不断切换... 本来多核CPU是用来支持高并发地，但是现在却被用来无效地唤醒，对于多核CPU简直就是一种浪费 （浪费系统资源） 还会影响系统的性能.
解决方式（一般是两种）
Nginx的解决方式:
加锁：惊群问题发生的前提是多个进程（线程）监听同一个套接字(listensock)上的事件，所以我们只让一个进程（线程）去处理监听套接字就可以了。
画两张图来理解一下：
上述还没有进行一个每一个进程都对应一个listensock 而是多线程共享一个listensock 运行结果如下
所有的线程同时被唤醒了，但是实际上会处理连接的仅仅只是一个线程，
咱仅仅只是将主线程做如上这样一个简单的修改，每一个线程对应一个listensock；每一个线程一个独有的监视窗口，将问题抛给内核去处理，让内核去负载均衡 ： 结果如下
仅仅唤醒一个线程来进行处理连接，解决了惊群问题
本文通过介绍两种锁入手，以及为什么需要锁，锁本质就是为了保护，持有锁你就有权力有能力操作写入一定的临界保护资源，没有锁你就不行需要等待，本质其实是将多条汇编指令绑定成原子操作
然后介绍了惊群现象，通过一个巧妙地例子，扔一颗石子，只是瞄准一条鱼扔过去了，但是整池鱼都被惊醒了，
对应我们地实际问题就是， 多个线程或者进程共同监视同一个listensock。。。。然后IO连接事件到来地时候本来仅仅只是需要一个线程醒过来处理即可，但是却会使得所有地线程（进程）全部醒过来，造成不必要地进程线程间切换，多核CPU被浪费喔，系统资源被浪费
处理方式 一。 Nginx 源码加互斥锁处理。。 二。设置SO_REUSEPORT, 使得多个进程线程可以同时连接同一个port , 为每一个进程线程搞一个listensock... 将问题抛给内核去处理，让他去负载均衡地仅仅将IO连接事件分配给一个进程或线程