LNMP虽是传统的Web应用架构组合，无奈NginX + PHP-FPM的搭配运行效率实在太低；而Swoole HTTP服务器具有NginX级别的性能，且本身嵌入在PHP中，完全可以替代NginX + PHP-FPM。于是一直在探索用Swoole HTTP服务器运行传统PHP应用的途径。这里主要介绍一下Swoole HTTP服务器运行Lumen项目的实现方法：
Swoole1.7.7增加了内置HTTP服务器的支持，使用了跟NginX一样的IO多路复用机制epoll，可以达到NginX级别的性能，并且只需几行代码即可写出一个异步非阻塞多进程的HTTP服务器（epoll属于同步非阻塞，这里说“异步非阻塞”主要是因为“多进程”，单个进程内部依然是同步非阻塞）。
Docker Store是Docker官方提供的公共的镜像仓库，但有时会需要在局部内共享镜像，那么可以利用Docker Registry工具搭建一个私有的镜像仓库。
直接运行官方registry镜像，即可开启镜像仓库服务：
1 | $ docker run -d -p 5000:5000 --restart=always --name registry registry |
若要定制使用，还需更多配置。
介绍一下在Ubuntu16.04系统下源码安装GitLab10.04且以MySQL作为数据库、SSL加密传输的步骤：
最近做一个移动端的Web应用，因为是单页模式，所以少不了各种各样的弹出框，侧边栏，结果发现这些元素在滚动到边界时，滚动事件会传递给父元素，导致父元素开始滚动（在PC端也是一样存在这样的问题，而在移动端更为突出，有时即使不在边界也会导致父元素滚动，自身却不动）。
在网上搜寻一番后，找到很多关于这个问题的讨论，解决方法大致可以分为两类：
el滚动事件event，当el.scrollTop或者el.scrollLeft到达边界值的时候，用event.preventDefault()方法取消浏览器默认操作和用event.preventDefault()方法停止事件往上传播；body）的样式，如position:fixed、overflow:hidden等等，使其不可滚动。具体可以参考移动端滚动穿透问题，其中提到的“终极完美解决方案”便属上面的第二类。
一个网关服务器就跟快餐店一样，总是希望客人来得快、去得也快，这样在相同时间内才可以服务更多的客人。如果快餐店的服务员在一个顾客点餐、等餐和结账时都全程跟陪的话，那么这个服务员大部分时间都是在空闲的等待。应该有专门的服务员负责点餐，专门的服务员负责送餐，专门的服务员负责结账，这样才能提高效率。同样道理，网关服务器中也需要分工明确。举个例子：
假设有一个申请发送重置密码邮件的网关接口，须知道发送一封邮件可能会花费上好几秒钟，如果网关服务器直接在线上给用户发送重置密码邮件，高并发的情况下就很容易造成网络拥挤。但实际上，网关服务器并非一定要等待邮件发送成功后才能响应用户，完全可以先告知用户邮件会发送的，而后再在线下把邮件发送出去（就像快餐店里点餐的服务员跟顾客说先去找位置坐，饭菜做好后会有人给他送过去）。
那么是谁来把邮件发送出去呢？
为了网关接口能够尽快响应用户请求，无需即时知道结果的耗时操作可以交由任务队列机制来处理。
任务队列机制中包含两种角色，一个是任务生产者，一个是任务消费者，而任务队列是两者之间的纽带：
任务队列的整体运行流程是：任务生产者把当前操作的关键信息（后续可以根据这些信息还原出当前操作）抽象出来，比如发送重置密码的邮件，我们只需要当前用户邮箱和用户名就可以了；任务生产者把任务放进队列，实际就是把任务的关键信息存储起来，这里会用到MySQL、Redis之类数据存储工具，常用的是Redis；而任务消费者就不断地从数据库中取出任务信息，逐一执行。
任务生产者的工作是任务分发，一般由线上的网关服务程序执行；任务消费者的工作是任务调度，一般由线下的程序执行，这样即使任务耗时再多，也不阻塞网关服务。
这里主要讨论的是任务调度（任务消费者）的程序设计。
最近看到一篇文章一张优惠券引发的血案，文章作者实现一个获取优惠券列表的RPC接口，接口中的执行流程大概是先在缓存里获取优惠券列表，有则返回，没有则在数据库里获取，将结果写入缓存再返回。然而，在高并发请求的情况下，缓存优惠券列表中出现大量的重复数据。
主要原因是：
文章作者最后通过反复判断来解决这个问题，但并不是一个好办法。其实这样需要动态更新缓存场景在开发中十分常见，所以在这里探讨一下相对完善的解决方案。
RabbitMQ是基于高级消息队列协议（AMQP）实现的开源消息代理软件，主要提供消息队列服务。这里介绍用Docker Compose搭建RabbitMQ高可用集群的过程。
RabbitMQ自身提供部署集群的功能，通过命令：
1 | $ rabbitmqctl -n rabbit@rmqha_node1 stop_app |
就可以很容易的将节点rabbit@rmqha_node1加入到集群rabbit@rmqha_node0中。--ram选项表示节点以内存存储方式运行，读写速度快，重启后内容会丢失；不加--ram选项，节点则以磁盘存储方式运行，虽然读写速度慢，但是内容一般可以持久保持。
在同一个RabbitMQ集群中，节点之间并没有主从之分，所有节点会同步相同的队列结构，队列内容（消息）则各自不同，不过消息会在节点间传递。这样的集群只是提高了应对大量并发请求的能力，整体可用性还是很低，因为某个节点宕机后，寄存在该节点上的消息不可用，而在其他节点上也没有这些消息的备份，若是该节点无法恢复，那么这些消息就丢失了。
为了解决这个问题，RabbitMQ提供镜像队列功能，通过命令：
1 | $ rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}' |
可以设置镜像队列，"^"表示匹配所有队列，即所有队列在各个节点上都会有备份。在集群中，只需要在一个节点上设置镜像队列，设置操作会同步到其他节点。
最近要做一个H5活动页面，大概功能是给图片人脸换妆，自然也少不了上传原始图片和导出最终图片等功能。如果图片加工（即人脸换妆）放在服务器处理，那么并发量高的时候，肯定产生大量阻塞。于是想把图片加工放在客户端处理，用HTML堆砌出图片的最终效果，但是怎样把HTML导出成图片呢？
图片上传可以参考HTTP文件上传的一个后端完善方案（NginX），或者使用现有的云存储服务，如七牛等等。
人脸识别和五官定位可以利用OpenVC自行实现，或者使用成熟的云识别服务，如Face++等等。这里使用腾讯云的人脸识别服务。
MySQL MHA（Master High Availability）是目前相对成熟的一个MySQL高可用解决方案。
这篇文章主要介绍用Docker Compose编排MySQL MHA高可用集群的实践过程。
Docker Compose编排中使用了两个现有镜像，分别是breeze2/mha4mysql-manager和breeze2/mha4mysql-node，这两个镜像的相关信息可以查看《制作mha4mysql的Docker镜像》。
本次实践源码上传在GitHub的breeze2/mysql-mha-docker。
本来想记录一下用Docker构建MySQL MHA集群的实践过程的，但是整个篇幅有点长，所以这里先来介绍一下怎样制作mha4mysql的Docker镜像。
mha4mysql是日本工程师Yoshinori Matsunobu开发的一款MySQL高可用软件。mha4mysql分为两部分，一是管理器部分mha4mysql-manager，二是结点部分mha4mysql-node。mha4mysql-node要运行在每台受管理的MySQL服务器上；而mha4mysql-manager所在服务器则不需要MySQL，但需要mha4mysql-node。因为mha4mysql-manager依赖mha4mysql-node，即安装mha4mysql-manager前必须先安装mha4mysql-node。
下面讲解一下，基于debian:jessie制作mha4mysql-manager的Docker镜像和
基于mysql:5.7制作mha4mysql-node的Docker镜像。