这是个类库，可以百度一下：\Godruoyi\Snowflake\Snowflake

刚刚了解到的算法

针对每个公司，随着服务化演进，单个服务越来越多，数据库分的越来越细，有的时候一个业务需要分成好几个库，这时候自增主键或者序列之类的主键id生成方式已经不再满足需求，分布式系统中需要的是一个全局唯一的id生成规则。既然号称在全局分布式系统中唯一，那么主键的生成规则必然要复杂一些，以前看过很多资料，

Snowflake 是 Twitter 内部的一个 ID 生算法，可以通过一些简单的规则保证在大规模分布式情况下生成唯一的 ID 号码。其组成为：

第一个 bit 为未使用的符号位。

第二部分由 41 位的时间戳（毫秒）构成，它的取值是当前时间相对于某一时间的偏移量。

第三部分和第四部分的 5 个 bit 位表示数据中心和机器 ID，其能表示的最大值为 2^5 -1 = 31。

最后部分由 12 个 bit 组成，其表示每个工作节点每毫秒生成的序列号 ID，同一毫秒内最多可生成 2^12 -1 即 4095 个 ID。

需要注意的是：

在分布式环境中，5 个 bit 位的 datacenter 和 worker 表示最多能部署 31 个数据中心，每个数据中心最多可部署 31 台节点。

41 位的二进制长度最多能表示 2^41 -1 毫秒即 69 年，所以雪花算法最多能正常使用 69 年，为了能最大限度的使用该算法，你应该为其指定一个开始时间。

雪花算法 基于内存、速度快；性能高；不会产生额外的网络开销；数据依次成递增 依赖于服务器时间，如变动服务器时间则存在重复的情况

实现

/**
 *  分布式 id 生成类     组成: <毫秒级时间戳+机器id+序列号>
 *  默认情况下41bit的时间戳可以支持该算法使用到2082年，10bit的工作机器id可以支持1023台机器，序列号支持1毫秒产生4095个自增序列id
 *  @author zhangqi
 */
class IdCreate
{
    const EPOCH = 1479533469598;    //开始时间,固定一个小于当前时间的毫秒数
    const max12bit = 4095;
    const max41bit = 1099511627775;

    static $machineId = null;      // 机器id

    public static function machineId($mId = 0)
    {
        self::$machineId = $mId;
    }

    public static function createOnlyId()
    {
        // 时间戳 42字节
        $time = floor(microtime(true) * 1000);
        // 当前时间 与 开始时间 差值
        $time -= self::EPOCH;
        // 二进制的 毫秒级时间戳
        $base = decbin(self::max41bit + $time);
        // 机器id  10 字节
        if(!self::$machineId)
        {
            $machineid = self::$machineId;
        }
        else
        {
            $machineid = str_pad(decbin(self::$machineId), 10, "0", STR_PAD_LEFT);
        }
        // 序列数 12字节
        $random = str_pad(decbin(mt_rand(0, self::max12bit)), 12, "0", STR_PAD_LEFT);
        // 拼接
        $base = $base.$machineid.$random;
        // 转化为 十进制 返回
        return bindec($base);
    }
 

使用

 $this->load->library('IdCreate');

            $machineId = 1;

            $peopleData['id']  = $cast_id = IdCreate::createOnlyId($machineId);

奇怪的知识：唯一值的实现方式

实现方案	优势	劣势
UUID	实现简单、方便；重复性低；	数据库查询效率低 可读性低；过于冗长
雪花算法	基于内存、速度快；性能高；不会产生额外的网络开销；数据依次成递增	依赖于服务器时间，如变动服务器时间则存在重复的情况
Redis	基于内存、速度库；使用简单；可分布数据、扩展性强	需要独立搭建一套服务、增加了维护成本；跨应用调用、存在网络开销
数据库自增	代码层面无需任何特殊处理；利用MySQL特点实现数据递增	并发性能差；MySQL负担重