订阅与发布

之前的实例我们都是将任务精确的转发给某一个工作线程（消费者）。这节我们讲讲怎么将一个任务转发给多个消费者。这种模式就是闻名的“订阅/发布”模式。

我们的初步想法便是一个发布者发布了一个消息，多个消费者接收到消息，做不同的事情。

交换机(Exchanges)

前面已经说了了我们是通过队列来接受和发送消息的(p-q-c)[p:发布者，q:队列，r:消费者]。消息是由p 发布到q,q 再发给c。其实Rabbit又一个消息模型，在我们完成实例前，我们先来看看Rabbit的所有消息模型。

在Rabbit消息模型中最核心的点是生产者从不直接发送消息给队列。实际上，生产者都不知道生产的消息给了那个队列。

相反的，生产者只是给exchange(交换机)发送消息。交换机实际上是一个非常简单的东西，一边是从生产者接受消息，另一边就是将消息推送给队列。交换机必须明确的知道他们接到消息后该怎么处理消息：应该是将消息发送给一个明确的队列？还是应该给所有的队列？又或者是直接忽略不管？这些规则都是由交换机的类型去定义的。

有一些可用的交换机类型是：direc,topic,headers,fanout。今天我们讲的类型主要是fanout。我们可以先声明一个类型：

Java IO流

Java IO流简述

JavaIO 中流都分别在java.io包中，主要分为几类：

• 字节流：Byte Stream->InputStream/OutputStream
• 字符流: Character Stream->Reader/Writer
• 缓冲流：Buffered Stream
• 数据流：Data Stream 只针对基本数据类型：(boolean, char, byte, short, int, long, float, double) 还有String
• 对象流: Object Stream,继承自Serializable,必须序列化
• 控制台的流..

InputStream

字节流其实又叫做二进制流，因为它是最基本的二进制的数据的读取，也就是010101的读取与传输。如果读取的数据全是文字类型，那么推荐使用字符流的，如果是图片或者其它的图片可以使用字节流。看下InputStream 类里面的相关方法：

InputStream实现了Closeble,Closeble继承了AutoCloseable，其实就是相当与一个标记，AutoCloseable是1.7才出来的，主要是为了t-w-r语法主动关闭流。

InputStream是abstract的，一定要注意它是一个抽象类。我们说的装饰者模式里面，InputStream的实际实现(实现了InputStream的相关方法)基本都是类似于组件，而InputStream相当与一个超类。里面的主要构成是8个方法一个属性。

available()

1
2
3

public int available() throws IOException {
    return 0;
}

先看我们的第一个方法available(),它的作用是返回流中估计的长度，而这个长度怎么设置？看源码中的介绍最后归结两句话：

1
2

1. 永远也不要调用此方法来确认分配多大的缓存空间，因为它永远返回0。
2. 任何继承`InputStream`的子类必须重写该方法。

意思就是子类自己去实现这个方法。

Dockerfile 文件导读

Dockerfile 是一个包含了很多指令的文本文件，基于这些指令我们可以使用build创建一个image。

docker build创建image是从dockerfile和context。构建中的上下文(context)是PATH和URL的文件集合，PATH是指本地的文件系统，URL是一个Git仓库地址。一个上下文通常是递归的，对于PATH包含了子目录，URL包含了它的子模块。docker build .

build是有Docker 守护进程执行的，执行的第一件事就是将完整的上下文路径（包括递归的子目录）都会发送给守护进程，在大多场景下，最好的方式是用一个空目录作为上下文路径，然后里面放一个Dockerfile.然后在构建(build)将需要的文件加入到目录里面来。

千万注意不要使用根路径”/“作为PATH，它会导致将整个硬盘的文件都会发送给Docker的守护进程

如果要在构建上下文中使用一个文件，Dockerfile 引用了一些特殊的指令，比如COPY指令，为了优化构建，不需要的文件和目录可以加入到上下文目录的.dockerignore文件中。dockerignore file

一般地，Dockerfile被称作Dockerfile，并且放在上下文目录的根目录。你也可以在构建的时候使用 -f 标记来指定一个你文件系统任何地方中的Dockerfile。
docker build -f /path/to/a/Dockerfile .

你也可以在构建成功后保存image时指定远端源仓库(repositories)和标签。

docker build -t shykes/myapp .

如果要在构建之后给多个仓库(repositories) 打tag，使用多个-t参数就可以了：
docker build -t shykes/myapp:1.0.2 -t shykes/myapp:latest .

在Docker守护进程执行Dockerfile中的指令之前，它都会进行一下预编译来校验语法是否准确，如果有错误的话会返回error。

1
2
3

$ docker build -t test/myapp .
Sending build context to Docker daemon 2.048 kB
Error response from daemon: Unknown instruction: RUNCMD

设计模式-装饰者模式

组合比继承更具有灵活性

简述

装饰者模式其实一开始我没想明白，怎么给装饰法？就像当初看Java IO包，始终也没明白怎么这么多类啊。很多人都说它是什么什么装饰者设计模式，那个时候也不怎么懂，就走马观花般过了就过了。
最近重新回到基础，又买了本设计模式的书，其实真的不想看，但是看了一两章发现，我靠，这不就是我之前的搞法么？猛回首，发现自己踩过的坑人家也踩过，而我还在踩。当然能力也有限，记下此博客，一，如果有人能看到这里有点了解，那是甚好；二，如果以后自己忘记了，也有个标记，让我返回至此，然后来个回忆。

回到正途，装饰者，啥事装饰者？看看平常我们说装饰房屋，那么是不是先有个房子，然后再给房子搞下装饰，刷墙啊，放书架啊，这就是一个装饰。那么装饰者模式怎么回事了？动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的扩展方案。 装饰者模式的最大特点是在装饰类里面进行了组合，组合的威力发挥到最大。当然这种组合也必须要有一个约束，那么就是必须在同一类中，总不能指驴为马吧。所以装饰的是一类或者一组类似的对象。

自我的理解

有时候光想真的会发现自己很多地方好像已经明白了，但是实际上，当我们写代码的时候会发现，要注意点细节真的很多。

消息中间件 RabbitMQ (二) 任务队列

第一篇中简单介绍了mq的使用，那么第二节中来了解下mq的其它内容.

工作队列

这节我们将建立一个工作队列来讲任务分发到不同的消费工作者中去。工作队列的主要思想是避免在做资源密集型任务的同时又不得不等待一个个完成。这种时候我们像消息一样封装所要完成的任务然后将它发送到队列中，在后台运行的工作线程会将任务拿出，然后执行这个任务。当运行多个工作线程的时候，任务对他们都是可见的。

网络应用中如果一个任务无法快速执行完，那么工作队列就非常有用。

消息中间件 RabbitMQ (一)

简述

RabbitMQ 是一个消息中间件，类似于传统的邮局，不过RabbitMQ充当了邮箱，邮局，邮递员的角色。和邮局不同的是，它使用消息接受，存储，发送二进制数据。

RabbitMQ 的一些术语

Producing: 生产者，发送消息方，只发送消息。

queue: 消息队列，允许消息从RabbitMQ传送到应用程序，消息只能被存储在队列中。队列仅仅被宿主机的内存和磁盘空间限制，本质上它是一个大的缓存块。生产者可以往队列发消息，消费者也可以从队列中接受消息。

Consuming:消费者，类似于收信人，消费者程序通常是在等待接收消息。

ps:生产者，消费者和中间件不应该在同一台宿主机上面，实际中大多数应用都不会这样做。

“Hello World”

设计模式-观察者模式

简述

观察者模式的有点类似现在的手机消息推送，比如你注册了一个APP，然后app有了更新一定会通知你，不然你看看手机里面的推送栏是不是每天淘宝都会推送给你一条消息。哈哈。当然为什么它知道要给你推送，不给哪些非智能机推送了？简单的更类似与现在报纸-订阅。只要你订了报纸，那么每天报纸更新都会把报纸给你送过来。所以我认为观察者模式应该也叫”订阅模式”，因为必须客户端先去注册（订阅）然后才能收到注册中心的更新或者通知。

实例

我们先来想想观察者模式中有哪些主体：

1. 注册中心（主题（或者叫被观察对象））
2. 客户端 (观察者)

现在我们分析下里面的行为：

报社（注册中心-主题）怎么知道有哪些人订了报纸（客户注册）了？那么就是报社必须要有一个记录有哪些人（客户端-观察者）在报社注册的’花名册’；那么现在是法治社会，当然不能强迫去订报纸吧，所以人们订报纸都是自愿的，那么自愿就必须自己去报社订阅(主动注册)。订了报纸之后，不能收不到报纸吧？那报社现在都是比较强势的，一般把报纸送到门口，所以你必须有一个接受的地址，这种算是约定；既然可以订阅，那么当然也有取消订阅（取消注册）；那么报社也就在’花名册’把你的名字去掉就可以了。

整个实现过程就是这样，观察者模式并不复杂，主要是报社(注册中心-主题)，花名册(订阅者名单)，订阅者（接受通知者），订阅(行为)，门(注册中心通知接受者的地址)。

Java设计模式-策略模式

简述

策略，什么是策略？就在不同情况下用不同的方式去处理。那么策略模式是什么？ 模式，模式简而言之就是套路，就是前人总结下来得到验证的套路。所以策略模式其实就是用策略去解决一类事情的套路。

策略模式的一个小思考

说到套路，那么一个套路就要有组成部分，不然怎么套路？而策略模式中，它的主要点就是变化的情况，以及应对变化的处理方法。比如有一家超市打折，可能为了吸引顾客、庆祝节日等，但是可能中途来个产品经理，他说为了利润最大化，要根据付款总数来对顾客实行不同打折额度。这种时候程序员心中都是千万匹马儿在奔腾，就不能为为别人做点好事么？（其实心里就是想着，tmd，又改需求，我还想回家陪老婆孩子的）~~~咳咳，走远了。 就这个超市打折来说，打折这种事情是一定存在的，而对打折的方式可能还会有各种变化。那么怎么去应对这种变化？再说一个例子，如果有个制造鸭子的工厂，我们都知道鸭子有很多类（比如死的，活的），死的就像玩具类~，活的就像烤鸭类(貌似烤之前才是活的.),不管怎样，我想说大多数鸭子都有一些基本行为，比如：飞？叫？游泳？诸如此类..但是我们会发现，鸭厂产出的鸭子最终还是要卖出去的，那么这个鸭子能不能飞？能不能叫？能不能游泳？那都是买家说了算，谁给钱听谁的。那么好了A可能要一个能飞，但不能叫，也不能游泳；B呢想要个能飞，能叫，能游泳；这下如果鸭厂只能生产一种只会飞，或者只会叫的鸭子，那肯定是不行的，但是也不能为了A专门搞个生产线，B专门搞个生产线，这样搞，要是N多客户，N多需求，那可怎么办？说了这么多，基本是废话，那么还是来代码看看。

使用FastJson 转换成HashMap<String,List