理论篇-分布式环境下如何保证消息有序

分布式环境下，保证消息的有序性是一个经典的问题，在分布式环境的很多业务场景中都会遇到该问题。下面让我们从简单到复杂，一步一步分析。

当只有一个生产者一个消费者的时候，这个问题是不存在的。如下所示:

1
生产者 --> 队列 --> 消费者

真正的生产环境下，肯定不会是这么简单的，因为该模型的处理能力真的很有限。一般生产环境的模型应该是如下图所示:

1
2
3
4
5
6
7
8
9
生产者     生产者 ... 生产者
    \       |       /
     \      |      /
      \     |     /
           队列
      /     |     \
     /      |      \
    /       |       \
消费者     消费者 ...  消费者

消息定义: 每个id下有序号分别为1到n的消息。比如xxx_1、xxx_2、xxx_3等分别是id为xxx的序号分别为1 2 3的三条消息。

在该场景下保证消息有序的方案如下:

  • 方案一: 保证某个id的消息只会被分发到特定的消费者
  • 方案二: 使用分布式锁和带有序列信息的消息

方案一的原理很简单，具体实施的时候需要在队列与消费者之间增加一层消息分发模块，保证某一类消息只会被分发到特定的消费者。该方案的缺点:1.使用某些消息队列服务比如RabbitMQ的时候，实现困难 2.不能充分利用多个消费者的能力，比如某些消费者处于饥饿状态

方案二需要生产者和消费者互相配合来完成。

分布式锁保证某一类消息只能同时被一个消费者消费。只有分布式锁还不足以保证消息的有序消费，比如，生产者生产了xxx_1 xxx_2 xxx_3三条消息，虽然消息是按照如上顺序分发的，但是由于网络等原因导致xxx_2消息被提前消费，这样消息就乱序了。

如果消费者在消费xxx_2时能判断出xxx_1还没有被消费，那么就可以采取一些措施来保证消息的有序消费。比如将xxx_2消息重新放到队列里。具体实施的时候需要生产者做一些配合，比如将消息的格式改为如下xxx_1_0 xxx_2_1 xxx_3_2。这样xxx代表id号 1代表消息序号 0代表前一个消息的序号。

该方案的优点:充分利用每个消费者的能力。缺点:实现复杂，依赖分布式锁

方案二的优化版:根据消息的特点，可以做一些优化。比如有如下两种消息序列，时间从1秒开始计时。第一行是某个id的消息完全有序。第二行是某个id的消息区间内有序。

1
2
xxx_1_1 xxx_2_1 xxx_3_2            xxx_70_3  xxx_73_70
xxx_1_1 xxx_2_1 xxx_3_2            xxx_70_70 xxx_73_70

第一种方案需要在缓存里一直维护id与序号之间的关系，并且不知道什么时候该删除该对应关系，给缓存增加了压力。
第二种方案可以给缓存设个有效时间。这样既能保证某区间段内消息有序，又能减少缓存的压力。

展开全文 >>

实战篇-ssh

认证原理

1
2
3
4
A----发送公钥--->B(若A的公钥在B的认证列表里，则省略密码验证部分)
A<---发送公钥----B
A----使用B公钥加密后的密码---->B
A<---通过后连接建立----B

免密登录

原理: 假如想从A免密登录B，需要在A上生成一个.ssh/id_rsa.pub，然后拷贝到B的.ssh/authorized_keys。

1
2
3
A:
ssh-key-gen
ssh-copy-id B

ssh翻墙

1
ssh -qTfnN -D port user@host

展开全文 >>

理论篇-构建工具的历史

构架过程简单来讲就是编译，测试，生成文档，打包，部署。

最简单直接的构建工具应该是我们自己写的shell脚本，通过脚本来管理整个构建过程。这样做的缺点很明显:

  • 风格不统一
  • 不能胜任大型项目的管理工作

于是，make诞生了，通过makefile文件，通过一系列的规则将整个构建过程串起来。每个规则包含目标、依赖、命令。make的强大之处在于可以利用本地系统的所有命令。

1
2
target: prerequisite
	command

由于make使用你了大量的本地系统命令，所以不能很好的跨平台。于是java有了一套自己的构建工具Ant(Another Neat Tool)。配置文件build.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0"?>
<project name="Hello" default="compile">
    <target name="compile" desription="compile java source code to class files">
        <mkdir dir="classes"/>
        <javac srcdir="." destdir="classes/"/>
    </target>
    <target name="jar" depends="compile" description="create a jar file">
        <jar destfile="hello.jar">
            <fileset dir="classes" includes="**/*.class"/>
            <manifest>
                <attribute name="Main-Class" value="HelloProgram">
            </manifest>
        </jar>
    </target>
</project>

make与ant都需要显式的指定每个目标，以及完成目标所需要的工作，所以对于每个项目都需要大量的重复工作。maven只要指定构建过程，每个阶段的工作都由插件完成。maven依赖插件来完成具体工作，这些插件基本都是现成的，而且天生支持依赖管理。配置文件pom.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.xxx</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>
  <name>hello</name>
  <description>测试模板</description>
  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.4.2.RELEASE</version>
    <relativePath/>
  </parent>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>1.8</java.version>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
      <exclusions>
        <exclusion>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-logging</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
    </plugins>
    <resources>
      <resource>
        <directory>src/main/profiles/${conf-dir}</directory>
        <filtering>true</filtering>
      </resource>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
    <testResources>
      <testResource>
        <directory>src/main/profiles/${conf-dir}</directory>
        <filtering>true</filtering>
      </testResource>
    </testResources>
  </build>
  <profiles>
    <profile>
      <id>local</id>
      <properties>
        <env>local</env>
        <conf-dir>local</conf-dir>
      </properties>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
    </profile>
    <profile>
      <id>dev</id>
      <properties>
        <env>dev</env>
        <conf-dir>dev</conf-dir>
      </properties>
    </profile>
    <profile>
      <id>test</id>
      <properties>
        <env>test</env>
        <conf-dir>test</conf-dir>
      </properties>
    </profile>
    <profile>
      <id>stage</id>
      <properties>
        <env>stage</env>
        <conf-dir>stage</conf-dir>
      </properties>
    </profile>
    <profile>
      <id>prod</id>
      <properties>
        <env>prod</env>
        <conf-dir>prod</conf-dir>
      </properties>
    </profile>
  </profiles>
</project>

展开全文 >>

理论篇-maven

印象中第一次接触maven是在2013年，到2017年才真正系统得学习了一下。

Maven本身

解压后maven目录下包含如下内容:

1
2
3
4
5
6
7
bin            # mvn运行的脚本
boot           # mvn的类加载器
conf           # 配置文件，其中包含settings.conf
lib            # 真正的mvn及第三方类库
LICENSE.txt    # 软件许可证
NOTICE.txt     # mvn使用的第三方软件
README.txt     # mvn简介

坐标系统

1
2
3
4
5
groupId           # 必须 当前项目隶属的实际项目 一般为 组织.实际项目
artifactId        # 必须 实际项目中的一个maven项目 一般为实际项目-模块
version           # 必须 当前模块的版本
packaging         # 可选 打包方式
classifier        # 附属构建 暂时还没弄明白

依赖范围

maven在编译项目主代码的时候需要一套classpath，编译和执行测试的时候需要另一套classpath，实际运行项目的时候又会使用另一个classpath。依赖范围就是针对这三种classpath的。

依赖范围 编译 测试 运行 例子
compile Y Y Y spring-core
test N Y Y JUnit
provided Y Y N servlet-api
runtime N Y Y JDBC
system Y Y N 本地的，maven之外的类库文件

传递性依赖

当依赖产生冲突的时候，按序依据如下规则进行解决:

  • 路径最近者优先
  • 第一声明者优先

注意:可选依赖不被传递。

仓库

maven的仓库分为本地仓库和远程仓库两种。当编译项目时，优先从本地仓库获取资源，若本地仓库没有，则从远程仓库获取，若远程仓库也没有，则报错。

从仓库解析依赖的机制

  1. 当依赖的范围是system时，直接从本地文件系统解析构件
  2. 根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功
  3. 在本地仓库不存在相应构件的情况下，如果依赖的版本是显式的发布版本构件，则遍历所有的远程仓库，发现后，下载并解析使用
  4. 如果依赖的版本是RELEASES或LATEST，则基于更新策略读取所有远程仓库的元数据groupId/artifactId/maven-metadata.xml，将其与本地仓库的对应元数据合并后，计算出RELEASES或LATEST的真实值，然后基于这个值检查本地仓库和远程仓库，如步骤2和3
  5. 如果依赖的版本是SNAPSHOT，则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml，将其与本地仓库的对应元数据合并后，得到最新快照版本的值，然后基于该版本检查本地仓库，或者从远程仓库下载
  6. 如果最后解析得到的构建版本是时间戳格式的快照，则复制其时间戳格式的文件至非时间戳格式，并使用该非时间戳格式的构件

生命周期与插件

每一个插件里包含很多功能，每一个功能就是一个插件目标

lifecycle_plugin

lifecycle_plugin_bind

clean生命周期的各个阶段

1
2
3
pre-clean    # 执行一些清理前需要完成的工作
clean        # 清理上一次构建生成的文件
post-clean   # 执行一些清理后需要完成的工作

default生命周期的各个阶段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
validate
initialize
generate-sources
process-sources        # 处理项目主资源文件，一般来说，是对src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录中
generate-resources
process-resources
compile                # 编译项目的主源码，一般来说，是编译src/main/java目录下的java文件至项目输出的主classpath目录中
process-classes
generate-test-sources
process-test-sources   # 处理项目测试资源文件，一般来说，是对src/test/resources目录的内容进行变量替换等工作后，复制到项目输出的测试classpath目录中
generate-test-resources
process-test-resources
test-compile           # 编译项目的测试源码，一般来说，是编译src/test/java目录下的java文件至项目输出的测试classpath目录中
process-test-classes
test                  # 使用单元测试框架运行测试，测试代码不会被打包或部署
prepare-package
package               # 接收编译好的代码，打包成可发布的格式 如jar
pre-integration-test
integration-test
post-integration-test
verify
install               # 安装到本地仓库
deploy                # 发布到远程仓库

site生命周期的各个阶段

1
2
3
4
pre-site
site
post-site
site-deploy

配置文件

配置文件settings.xml

settings.xml配置文件有两个，一个是全局的，位于M2_HOME/conf/settings.xml，另一个是用户级的，位于USER_HOME/.m2/settings.xml。如果两个配置文件都存在，会合并，若出现冲突，优先采用用户级别的内容。

3.0版本之后，settings.xml文件内的值可以采用${USER_HOME}这样的变量。

配置文件的内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
    <localRepository>
        user.home/.m2/repository
    </localRepository>            # 本地仓库地址
    <interactiveMode>true</interactiveMode>
    <usePluginRegistry>false</usePluginRegistry> # 是否使用user.home/.m2/plugin-registry.xml
    <offline>false</offline>     # 若不能联网使用true
    <pluginGroups/>
    <servers/>                   # 服务认证信息
    <mirrors/>                   # 镜像配置
    <proxies>                    # 设置代理服务器
        <proxy>
            <id>my-proxy</id>
            <active>true</active>
            <protocol>http</protocol>
            <host>127.0.0.1</host>
            <port>8888</port>
            <!--
            <username/>
            <password/>
            <nonProxyHosts/>
            -->
        </proxy>
    </proxies>
    <profiles/>
    <activeProfiles/>
</settings>
配置项mirrors
1
2
3
4
5
6
7
8
9
10
11
12
<mirror>
    <id/>
    <name/>
    <url/>
    mirrorOf>*</mirrorOf>   # 匹配所有远程仓库
</mirror>
mirrorOf取值如下:
*
external:*
repo1,repo2
*, !repo1

配置文件pom.xml

pom.xml是每个项目的配置文件，内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    
    <groupId>com.xxx</groupId>
    <artifactId>hello</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>      # 值为pom时是聚合，与modules配合使用
    
    <name>hello</name>
    <description>测试模板</description>
    
    <parent/>                 # 父模块
    <repositories/>           # 远程仓库配置
    <distributionManagement/> # 部署远程仓库
    <properties/>             # maven属性
    <dependencies/>
    <build/>                  # 插件绑定
    <profiles/>
    <modules/>                # 同时编译多个模块
</project>

配置项parent

1
2
3
4
5
6
<parent>
    <groupId/>
    <artifactId/>
    <version/>
    <relativePath/>     # 父模块路径 优先从该目录查找，若找不到，则去本地资源库
</parent>

配置项build

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<build>
    <plugins>
        <plugin>
            <groupId/>
            <artifactId/>
            <version/>
            <configuration/>       # 插件配置
            <executions>
                <execution>
                <id/>
                <phase/>           # 生命周期的某个阶段
                <goals>
                    <goal/>
                </goals>           # 该阶段对应的插件目标
                <configuration/>   # 特定任务的配置
                </execution>
            <executions>
        </plugin>
    </plugins>
</build>

配置项distributionManagement

1
2
3
4
5
6
7
8
9
10
11
12
<distributionManagement>
    <repository>
        <id/>             # 远程仓库id
        <name/>           # 简介
        <url/>            # 远程仓库地址
    </repository>
    <snapshotRepository>
        <id/>
        <name/>
        <url/>
    </snapshotRepository>
</distributionManagement>
配置项repositories
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<repositories>
    <repository>
        <id>jboss</id>
        <name>JBoss Repository</name>
        <url>http://repository.jboss.com/maven2</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
        <layout>default</layout>
    </repository>
</repositories>
配置项dependencies
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<dependencies>
    <dependency>
        <groupId/>
        <artifactId/>
        <version/>
        <type/>                # 对应packaging
        <scope/>               # 依赖的范围
        <optional/>            #
        <exclusions>           # 排除传递性依赖，若还要使用该库，则需再声明
            <exclusion>
                <groupId/>      # 只需这两项
                <artifactId/>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>
配置项modules
1
2
3
<modules>
    <module>xxx</module>       # 值为子模块的目录
</modules>

展开全文 >>

实战篇-maven

官方地址

下载及安装

下载二进制包，解压到自定义目录，比如third

1
2
3
4
5
6
tar xzvf apache-maven-3.5.0-bin.tar.gz
ln -s apache-maven-3.5.0 apache-maven
Mac下在.bash_profile文件下增加
export M2_HOME=$HOME/third/apache-maven
export PATH=$M2_HOME/bin:$PATH
mvn -v

配置

完成安装之后，会在HOME目录下生成.m2目录。
在.m2目录下有一个settings.xml文件。由于访问国外的源速度比较慢，所以在这里推荐阿里云的maven源。settings.xml文件的内容如下:

1
2
3
4
5
6
<mirror>
    <id>nexus-aliyun</id>
    <name>Nexus aliyun</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public</url>
    <mirrorOf>*</mirrorOf>
</mirror>

常用命令

1
2
3
4
5
6
7
8
mvn archetype:generate
mvn clean compile       # 编译
mvn clean test          # 测试
mvn clean install       # 安装资源到本地仓库
mvn clean deploy        # 发布资源到远程仓库
mvn dependency:list     # 查看所有依赖
mvn dependency:tree     # 查看所有依赖，以树的形式表示
mvn dependency:analyze  # 依赖分析 只会分析编译主代码和测试代码需要用到的依赖

搜索库

展开全文 >>

实战篇-装机

本人thinkpad笔记本电脑，原来安装了ubuntu，折腾了好长时间，终于换成了win7+centos。

不懂理论的可看下理论篇-装机

下载镜像

网易开源镜像站

中科大开源镜像站

U盘安装

linux系统下安装

在将系统镜像写到U盘之前，需对U盘做一些处理。处理步骤如下

  1. 确定设备分区类型(MBR还是GPT)
  2. 给设备分区
  3. 给创建的分区创建文件系统
  4. 写镜像到创建的分区
1
2
3
parted device                 # 确定设备分区类型及给设备分区
mkfs.vfat device_partition    # 给分区创建文件系统
dd if=iso of=device_partition # 将镜像写到设备分区

网络安装

服务端配置

安装dhcp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
yum install dhcp
配置文件:/etc/dhcp/dhcpd.conf(注意: 必须与主机在同一网段内)
option domain-name "test";
option domain-name-servers 8.8.8.8, 114.114.114.114;
default-lease-time 6000;
max-lease-time 7200;
subnet 192.168.99.0 netmask 255.255.255.0 {
    range 192.168.99.105 192.168.99.110;    # 指定分配IP地址范围
    option routers 192.168.99.1;
    next-server 192.168.99.250;             # 指定TFTP服务器的地址
    filename "pxelinux.0";                  #指定TFTP服务器上的文件
}
service dhcpd start
安装tftp
1
2
3
4
5
yum install tftp-server tftp
配置文件:/etc/xinetd.d/tftp
disable = no
service xinetd start
安装syslinux
1
2
3
4
5
6
7
8
9
yum install syslinux
cp /usr/share/syslinux/pxelinux.0 /var/lib/tftproot/
mount -o loop -t iso9660 xxx.iso  /mnt/cdrom  # 挂在iso文件
cp /mnt/cdrom/images/pxeboot/vmlinuz /var/lib/tftpboot/
cp /mnt/cdrom/images/pxeboot/initrd.img /var/lib/tftpboot/
mkdir /var/lib/tftpboot/pxelinux.cfg
cp /mnt/cdrom/isolinux/isolinux.cfg /var/lib/tftpboot/pxelinux.cfg/default
安装httpd
1
2
3
4
yum install httpd
mount --bind /mnt/cdrom/ /var/www/html/cdrom/
service httpd start

安装system-config-kickstart

1
2
3
yum install system-config-kickstart
生成ks.conf

系统下安装

ubuntu下安装win7

准备工作:

利用ubuntu下的磁盘分区工具: GParted分出一个安装windows的磁盘空间。

下载grub4dos

1
2
3
4
cp grub4dos/grub.exe /dev/device_1/
mount xxx.iso /mnt/cdrom
cp -r /mnt/cdrom/* /dev/device_1/
update-grub

修改/etc/default/grub

1
2
GRUB_HIDDEN_TIMEOUT=5
GRUB_HIDDEN_TIMEOUT_QUIET=false

win7下安装centos

超级传送门,本人亲测,可用

各系统配置

CentOS

最小化安装时，默认没有安装网络管理工具NetworkManager，所以需要手动配置网络接口。文件路径:/etc/sysconfig/network-script/ifcfg-X。配置内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
自动获取
DEVICE=eth0
HWADDR=08:00:27:9F:0A:FA
TYPE=Ethernet
UUID=b25c6192-d7f9-4838-ba49-0186a1af8529
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=dhcp
手动设置
DEVICE=eth0
HWADDR=08:00:27:9F:0A:FA
TYPE=Ethernet
UUID=b25c6192-d7f9-4838-ba49-0186a1af8529
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
NETMASK=255.255.255.0
IPADDR=192.168.99.100
GATEWAY=192.168.99.1

展开全文 >>

理论篇-装机

BIOS

BIOS(Basic Input/Output System)是固化在电脑硬件上的最基本的代码，保存着计算机基本输入输出程序、系统设置信息、开机后自检程序和系统自启动程序。它为计算机提供最底层、最直接的硬件设置。

UEFI

UEFI(Unified Extensible Firmware Interface)是一种详细描述类型接口的标准，其主要目的是为了提供一组在OS加载之前在所有平台上一致性的、正确指定的启动服务。被看做是BIOS的替代者。

目前支持UEFI引导启动的操作系统只有Win Vista及Win7以上系统。

MBR

MBR(Main Boot Record)是位于磁盘最前边的一段引导代码，由磁盘操作系统对磁盘进行初始化时产生，负责磁盘操作系统进行读写时分区合法性的判断、分区引导信息的定位。

GPT

GPT(GUID Partition Table)是一个实体硬盘的分区表的结构布局标准。作为UEFI的一部分，是用来替代BIOS中的MBR。

GRUB

GRUB是多重操作系统启动管理器，用来引导不同的系统，如linux、windows。

展开全文 >>

电影篇-太空旅行

孤独是最可怕的，可以摧毁任何一切。当男主孤独的在飞船上生活一年多之后，于是产生了轻生的想法。

爱情是希望，爱情可以战胜孤独，可以战胜一切。当男主看到女主后，内心重新燃起了希望。

人是感官动物，总希望可以碰得到摸得着，同时，人也是一种社交动物，总希望可以和别人互动。所以，即使女主近在眼前，但对男主来说却好像远在天边。

男主是善良的。当知道唤醒女主的方法后，开始了选择的挣扎。最后，终于被孤独打败，尝试将女主唤醒。

每个人都不喜欢别人控制自己的人生。当女主知道了事情的真相后，接收不了现实，认为男主谋杀了自己。

当男主舍命拯救飞船的时候，女主开始原谅了他。因为她开始意识到了孤独的可怕。最后，男主告诉女主有一个可以重新进入休眠的机会的时候，女主最终释然了，原因很简单，她终于可以选择自己人生的方向，要么与男主一起在飞船上度过余生，要么重新进入休眠，按照之前自己预定的方向走。善良的人总会选择前者。

总体来说，这是一部非常不错的电影，值得一看！

展开全文 >>

理论篇-rabbitmq

消息队列的历史

从前，有个思想活跃的小伙子突然有一个idea:为什么没有一种通用的软件总线呢？因此他设计了历史上的第一个消息队列，并且在金融领域崭露头角。后来，被其他各大公司看好，各大公司开始开发自己的商用消息队列。比如IBM MQ系列产品，微软消息队列(MSMQ)。这些商用消息队列另中小型公司望而却步，并且渐渐显现出另一个比较严重的问题:这些消息队列都是各自为营，之间不能兼容。后来，JMS诞生了，通过提供公共API的方式隐藏各个消息队列之间的差异性。后来有些人觉得这样设计还是不彻底，于是AMQP诞生了。

AMQP是消息队列的开放标准。RabbitMQ就是使用Erlang语言开发的遵从AMQP的消息队列。

连接与信道

RabbitMQ使用了信道技术，好处是多个线程可以复用tcp连接。那什么是信道技术呢？官方解释，一个tcp连接上的多个虚拟连接(这就是屁话，说了半天等于没说，不明白的还是不明白)。下面讲下复用tcp连接的技术。假设，客户端与服务端有一个tcp连接，客户端有两个线程都在使用这个连接。那问题来了，两个线程同时请求服务器，服务器同时返回两个结果，我怎么区分哪个结果是哪个线程的呢？解决方案如下: 每个线程都需要一个唯一的id号。发送请求时将自己的id号发给服务器，同样服务器返回结果时，也要带上客户端发的id号。如下图所示:

===========================
---------------------------
++++     发送请求id是1   ++++
++++     发送请求id是2   ++++
---------------------------
---------------------------
++++     返回结果id是2   ++++
++++     返回结果id是1   ++++
---------------------------
===========================

因为tcp连接是全双工通信，所以发送请求和接收返回结果可以同时进行。=之间代表一个tcp连接。-之间代表tcp连接里的一个通道，其中一个用于发送请求，另一个用于接收请求。+代表一个信道，标识信道的是id。

当信道设置成confirm模式时，发布的每条消息都会获得唯一的ID。

RabbitMQ的组成部分

RabbitMQ由三部分组成: 交换器、队列和绑定。三者之间的关系如下图所示:

rabbitmq_stack

队列

消费者从队列中取出消息，并进行处理。若有多个消费者监听同一个队列，消息则以轮询的方式发送给每个消费者，消费者需对是否收到消息进行确认，若不确认，该条消息则永不删除。若连接断开，则该条消息会重新入队，发给另一个消费者。

queue.declare  # 创建一个队列
    * exclusive    # 队列是私有的
    * auto-delete  # 当最后一个消费者取消订阅后，自动删除
    * passive      # 探测队列是否存在
basic.consume  # 持续接收消息
basic.get      # 只接收一条消息
basic.ack      # 确认收到消息，若auto_ack=true，则收到消息后，自动确认
basic.reject   # 拒绝消息 
    * requeue   #true，消息重新入队，发给另一个消费者。false，消息直接删除。

交换器与路由规则

交换器的类型: direct fanout topic和headers。headers允许匹配AMQP的header而非路由规则，类似direct，但性能稍差，使用场景不多。前三种如下图所示:

rabbitmq_direct

rabbitmq_fanout

rabbitmq_topic

fanout交换器适用于需对同一个消息做不同处理的场景。

路由规则
1
2
3
. 将路由规则分隔为几部分
* 只匹配某一部分
# 匹配0个或多个部分
相关命令
1
2
exchange.declare       # 声明交换器
channel.queue_bind("queue_name", "exchange_name", "routing_key") #绑定队列到交换器

虚拟主机

一个RabbitMQ服务上可以创建多个虚拟主机，每个虚拟主机之间绝对隔离。

相关命令

1
2
3
rabbitmqctl list_vhosts                 # 列出所有虚拟主机
rabbitmqctl add_vhost [vhost_name]      # 增加虚拟主机
rabbitmqctl delete_vhost [vhost_name]   # 删除虚拟主机

消息持久化

默认情况下，RabbitMQ宕机或重启后，交换器和消息队列需重新建立，队列里面的消息也随即消失。想让消息持久化存储，必须做到以下三点:

  • 把消息的投递模式选项设置为2(持久)
  • 发送到持久化的交换器
  • 到达持久化的队列

持久化机制:消息到达持久化交换器时，只有将消息写入到磁盘的持久化日志文件以后才会返回结果。若消息路由到非持久化队列，则该消息将会从持久化日志文件中删除；若消息路由到持久化队列，当消费者消费了该条消息后，会从持久化日志文件中将该条消息标记为等待垃圾收集。当服务器重启后，服务器会自动重建队列、交换器以及绑定关系，重播持久化日志文件到相应的队列或交换器上(取决于服务器宕机时，消息处在路由的哪个环节)。

使用消息持久化会降低服务器性能，若对性能要求很高(100000qps)，可以使用一些其他机制来保证消息可靠到达。

事务

由于RabbitMQ目的是异步处理，而事务需要同步处理，所以RabbitMQ采用publisher confirms模式实现了类似的事务机制。原理参看连接与信道

展开全文 >>

tag:

    缺失模块。
    1、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    2、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: true
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

王彪<br>计算机科学与技术专业<br>email:841824090@qq.com<br>2009-2013 苏州大学<br>2013-2015 苏州思必驰信息科技有限公司<br>2016-2017 美团<br>2017-至今 搜狗