有时我们需要能够生成类似 MySQL 自增 ID 这样不断增大,同时又不会重复的 id。以支持业务中的高并发场景。比较典型的,电商促销时,短时间内会有大量的订单涌入到系统,比如每秒 10w+。明星出轨时,会有大量热情的粉丝发微博以表心意,同样会在短时间内产生大量的消息。
在插入数据库之前,我们需要给这些消息/订单先打上一个 ID,然后再插入到我们的数据库。对这个 id 的要求是希望其中能带有一些时间信息,这样即使我们后端的系统对消息进行了分库分表,也能够以时间顺序对这些消息进行排序。
Twitter 的 snowflake 算法是这种场景下的一个典型解法。先来看看 snowflake 是怎么一回事:
QQ20181218-163552.png

首先确定我们的数值是 64 位,int64 类型,被划分为四部分,不含开头的第一个 bit,因为这个 bit 是符号位。用 41 位来表示收到请求时的时间戳,单位为毫秒,然后五位来表示数据中心的 id,然后再五位来表示机器的实例 id,最后是 12 位的循环自增 id(到达 1111 1111 1111 后会归 0)。
这样的机制可以支持我们在同一台机器上,同一毫秒内产生 2 ^ 12 = 4096 条消息。一秒共 409.6w 条消息。从值域上来讲完全够用了。
数据中心 + 实例 id 共有 10 位,可以支持我们每数据中心部署 32 台机器,所有数据中心共 1024 台实例。
表示 timestamp 的 41 位,可以支持我们使用 69 年。当然,我们的时间毫秒计数不会真的从 1970 年开始记,那样我们的系统跑到 2039/9/7 23:47:35 就不能用了,所以这里的 timestamp 实际上只是相对于某个时间的增量,比如我们的系统上线是 2018-08-01,那么我们可以把这个 timestamp 当作是从 2018-08-01 00:00:00.000 的偏移量。

worker_id 分配
timestamp,datacenter_id,worker_id 和 sequence_id 这四个字段中,timestamp 和 sequence_id 是由程序在运行期生成的。但 datacenter_id 和 worker_id 需要我们在部署阶段就能够获取得到,并且一旦程序启动之后,就是不可更改的了(想想,如果可以随意更改,可能被不慎修改,造成最终生成的 id 有冲突)。
一般不同数据中心的机器,会提供对应的获取数据中心 id 的 api,所以 datacenter_id 我们可以在部署阶段轻松地获取到。而 worker_id 是我们逻辑上给机器分配的一个 id,这个要怎么办呢?比较简单的想法是由能够提供这种自增 id 功能的工具来支持,比如 MySQL:

QQ20181218-163720.png

从 MySQL 中获取到 worker_id 之后,就把这个 worker_id 直接持久化到本地,以避免每次上线时都需要获取新的 worker_id。让单实例的 worker_id 可以始终保持不变。
当然,使用 MySQL 相当于给我们简单的 id 生成服务增加了一个外部依赖。依赖越多,我们的服务的可运维性就越差。
考虑到集群中即使有单个 id 生成服务的实例挂了,也就是损失一段时间的一部分 id,所以我们也可以更简单暴力一些,把 worker_id 直接写在 worker 的配置中,上线时,由部署脚本完成 worker_id 字段替换。

github.com/bwmarrin/snowflake
是一个相当轻量化的 snowflake 的 Go 实现。其文档指出:

1 Bit Unused41 Bit Timestamp10 Bit NodeID12 Bit Sequence ID

和标准的 snowflake 完全一致。使用上比较简单:

package main

import (
    "fmt"
    "os"

    "github.com/bwmarrin/snowflake"
)

func main() {
    n, err := snowflake.NewNode(1)
    if err != nil {
        println(err)
        os.Exit(1)
    }

    for i := 0; i < 3; i++ {
        id := n.Generate()
        fmt.Println("id", id)
        fmt.Println(
            "node: ", id.Node(),
            "step: ", id.Step(),
            "time: ", id.Time(),
            "\n",
        )
    }
}

当然,这个库也给我们留好了定制的后路:

 // Epoch is set to the twitter snowflake epoch of Nov 04 2010 01:42:54 UTC
// You may customize this to set a different epoch for your application.
Epoch int64 = 1288834974657

// Number of bits to use for Node
// Remember, you have a total 22 bits to share between Node/Step
NodeBits uint8 = 10

// Number of bits to use for Step
// Remember, you have a total 22 bits to share between Node/Step
StepBits uint8 = 12

Epoch 就是本节开头讲的起始时间,NodeBits 指的是机器编号的位长,StepBits 指的是自增序列的位长。

转载来源

php中使用日期函数,遇到奇怪现象,

date("Y-m-d", strtotime("-1 month", strtotime("2018-10-31")));

上面的理论输出2018-09-30,但是确输出2018-10-01,
后来查了一下,发现鸟哥博客里有答案,他是这么解释的

我们来模拟下date内部的对于这种事情的处理逻辑:

  1. 先做-1 month, 那么当前是10-31, 减去一以后就是09-31.
  2. 再做日期规范化, 因为9月没有31号, 所以就好像2点60等于3点一样, 9月31就等于了7月1

那怎么办呢?

从PHP5.3开始呢, date新增了一系列修正短语, 来明确这个问题, 那就是”first day of” 和 “last day of”, 也就是你可以限定好不要让date自动”规范化”:

 date("Y-m-d", strtotime("last day of -1 month", strtotime("2018-10-31")));

这样输出2018-09-31,如果想输出当月第一天,就改成


date("Y-m-d", strtotime("first day of -1 month", strtotime("2018-10-31")));
[鸟哥博客有答案][1]

(?!exp) 匹配后面跟的不是exp的位置

有时候用sprintf 会用%s之类的,但是如果字符串中含有50%的字符会出错
例:aaaabbb50% %ssswwl

regex: %(?!s)

匹配结果:aaaabbb50% %ssswwl (加粗部分是匹配到到,然后做正则替换即可)

分布式事务之Try-Confirm-Cancel,简称tcc

比如我把500元从某个银行卡账户转入到微信钱包。那么对微信这边的转入接口进行的操作便是一个补偿操作。

看到这里,你可能在想,原来是调用一个远程接口啊。没错,直接去调用现有的远程接口就是一种补偿操作。

除了这种补偿外,还有另外一种补偿方式。那就是TCC,也就是Try-Confirm-Cancel。

补偿方式:

    直接方式

    TCC

那接下来就重点来说TCC。
TCC的方式和直接方式其实都是调用服务方提供的接口。但他们有所不同的是,直接方式更加的简单,不用服务提供方再额外提供接口就可以实现业务。

而TCC则需要服务方提供更多更具体的接口,分别有Try接口、Confirm接口和Cancel接口。

TCC相比直接方式的好处就是在有的场景下,TCC让你的分布式事务更加的符合业务体验。

比如买飞机票的例子。我要买机票从布鲁塞尔到多伦多。这是一个事务,可以分为两个部分,从布鲁塞尔到华盛顿的航班和从华盛顿到多伦多的航班。假设这两张机票分别有自己的预订系统。那么此时如果用直接方式来实现补偿的后果就是,我可能买到了一张布鲁塞尔到华盛顿的机票,但却没有买到华盛顿到多伦多的机票,此时我就得急匆匆的又去看看华盛顿到多伦多其他时间段的航班,毕竟买到手的机票退起来还是比较麻烦的。这显然是不友好的。

而此时如果使用TCC的方式,我先分别对布鲁塞尔到华盛顿和华盛顿到多伦多的机票进行Try,也就是仅仅占用一个名额(仅仅是预留)。然后第二阶段的时候,我才真正决定自己要不要最终下单,如果两个都成功Try,那么就最终下单,然后把状态改为CONFIRMED,如果第二张机票没有成功Try,那么依然还有机会去取消第一张机票,把第一张机票改为CANCELED。

上面我们已经对比了直接方式和TCC两种方式。可以发现TCC在特定的场景,比如预订有限资源的购买场景下就非常适合,通过Try来预留资源,然后通过confirm和cancel两个补偿动作来最终决定是否购买。

当然有的场景下,使用直接方式则显得更加的简单,而不需要服务提供方提供额外的接口。比如买股票。股票买就买了,赔就赔了,也不需要TCC如此稳妥的方式,哈哈。

TCC开源实现

TCC开源框架,比较著名的有Atomikos、国内的TCC-transaction。更多框架欢迎补充。

总结

通过上面的梳理,我们首先明确了事务的概念:完成一件事情。然后明白事务中是由多个片段来组成。然后明确了两种事务一致性标准ACID和BASE。然后我们明确了补偿这一概念。补偿有两种方式,直接方式和TCC的方式。且在诸多BASE中,TCC是在特定的预订购买场景下较为适合的处理方式之一。