你升任你升，我选 PHP

新建表必有 extra，remark 两个字段 开发就是来填坑的

@xz 我表示 SE2 比我的 MIX3 续航好多了

给自己业务用就没必要，对外开放就有必要。

手写

@xmumiffy 我觉得乘 PI 就可以了，开发人员估时间的时候太太谦虚了。

自己在拐角处做路标。。。
很有用

@liuzhaowei55 我忘记在哪里看到的，苹果 app 审核策略也是如此，如果你困惑于某个功能是否会通过审核，那他大概率就不能通过审核。

这肯定不正常了，按照苹果的一贯思路，如果用户在使用产品时产生了疑惑，那这个产品肯定是有问题的或者说有可以做的更好的地方。

线下小米之家预约就挺好买的，销售策略变了，线下获多。

看描述只是酒量不好，不是过敏，过敏反应一般会有明确感知。

http://redis.cn/topics/distlock.html

可以参看这里的说明，主要是为了程序的鲁棒性。

--- 以下内容为复制

为什么基于故障转移的实现还不够
为了更好的理解我们想要改进的方面，我们先分析一下当前大多数基于 Redis 的分布式锁现状和实现方法.

实现 Redis 分布式锁的最简单的方法就是在 Redis 中创建一个 key，这个 key 有一个失效时间（ TTL)，以保证锁最终会被自动释放掉（这个对应特性 2 ）。当客户端释放资源(解锁）的时候，会删除掉这个 key 。

从表面上看，似乎效果还不错，但是这里有一个问题：这个架构中存在一个严重的单点失败问题。如果 Redis 挂了怎么办？你可能会说，可以通过增加一个 slave 节点解决这个问题。但这通常是行不通的。这样做，我们不能实现资源的独享,因为 Redis 的主从同步通常是异步的。

在这种场景（主从结构）中存在明显的竞态:

客户端 A 从 master 获取到锁
在 master 将锁同步到 slave 之前，master 宕掉了。
slave 节点被晋级为 master 节点
客户端 B 取得了同一个资源被客户端 A 已经获取到的另外一个锁。安全失效！
有时候程序就是这么巧，比如说正好一个节点挂掉的时候，多个客户端同时取到了锁。如果你可以接受这种小概率错误，那用这个基于复制的方案就完全没有问题。否则的话，我们建议你实现下面描述的解决方案。

砍你一刀给颗枣，早着呢，全在高位。