为了避免服务单点，也为了负载均衡，我们会加一层 Nginx 层。这个 Nginx 层要有多于一台机器，不然它自身也成为一个单点。

最初加 Nginx 层会变成这样：

                   schaepher.com
                       +
                       |
               +-------+
               |
               v
           +---+---+          +-------+
           |       |          |       |
           | Nginx |          | Nginx |
           |       |          |       |
           +--+----+          +---+---+
              |                   |
    +---------+---+-------------+-+-----------+
    |             |             |             |
    v             v             v             v
+---+----+    +---+----+    +---+----+    +---+----+
|        |    |        |    |        |    |        |
| Real   |    | Real   |    | Real   |    | Real   |
| Server |    | Server |    | Server |    | Server |
|        |    |        |    |        |    |        |
+--------+    +--------+    +--------+    +--------+

如果有一台 Real Server 发生故障，则 Nginx 就不会转发到故障的机器，保证服务正常进行。

在实践 RESTful API 设计的时候，会碰到很多需要选择的地方。而这些在 RFC 7230 - 7235 里面没有说明。例如这次要说的 DELETE 方法。

根据 RFC 7231 的说法， DELETE 是幂等的。

幂等（idempotent）是什么？在 RFC 7231 定义幂等方法的时候，是这样说的：
A request method is considered “idempotent” if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. —— RFC 7231
如果使用同一种请求方法的多个等效请求对服务器的预期影响，与一个等效请求对服务器的预期影响一样，那么这种请求方法被认为是幂等的。

英汉翻译

RFC 7230 - 7235 系列

汉英翻译

执行 ALTER 创建索引的时候， MySQL 的处理过程是怎么样的呢？

MySQL 5.5 之前（默认使用 MyISAM 作为存储引擎）

过程：

1. 取旧表 ALTER TABLE 后的结构，以该结构创建临时表
2. 原表加写锁，原表数据导入到临时表
3. 删除原表
4. 临时表重命名为原表的表名

缺点：

1. array_merge() 、array_combine() 和 + 处理 key 冲突的区别

   操作	数字 key	字符串 key
   array_merge	自增	覆盖已存在值
   +	使用已存在值	使用已存在值
   array_combine	覆盖已存在值	覆盖已存在值

   通常使用 array_merge 比 + 多。+ 的使用场景例如以数字 ID 为 key 做深度遍历的时候，由于数组会加上子节点。如果用 array_merge，则会使 key 重制，并从 0 递增。

孤儿进程：一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。