分布式ID解决方案

开发十年,就只剩下这套Java开发体系了
>>>   

在游戏开发中,我们使用分布式ID。有很多优点

  • 便于合服
  • 便于ID管理
  • 等等

一、单服各自ID系统的弊端

1. 列如合服

在游戏上线后,合服是避免不了的事情。如果按照传统的数据库表自增来作为数据的唯一ID、或者每个游戏中是相同的自增。这样在合服的时候你就会相当的麻烦了。

比如上图我们要把GameServer_2的数据合并到GameServer_1中,它们都有一个Player ID = 1的玩家,这个时候你就必须要重建GameServer_2中的Player_ID了。而引用了PlayerID的相关数据的PlayerID也全部需要修改。这还只是PlayerID的变化。在游戏中很多的表和关联,如果都要去修正ID,想想都可怕!

2. ID管理

在很多手游、页游中。都设计有跨服系统。一旦ID是各自自增。在跨服服务器你就傻傻分不清楚了。还有比如GM后台查询等等一系列问题。

二、分布式ID推荐

为了解决上面的问题,最好的解决办法就是采用分布式ID方案,分布式ID方案很多。java有自带的UUID。但是考虑到排序、存储空间等。UUID不是最佳的解决方案。下面我介绍一种分布式ID解决方案。

Twitter_Snowflake

SnowFlake的结构如下(每部分用-分开):
 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 
 1位标识,由于long基本类型在Java中是带符号的,最高位是符号位,正数是0,负数是1,所以id一般是正数,最高位是0
 41位时间截(毫秒级),注意,41位时间截不是存储当前时间的时间截,而是存储时间截的差值(当前时间截 - 开始时间截)
 得到的值),这里的的开始时间截,一般是我们的id生成器开始使用的时间,由我们程序来指定的(如下下面程序IdWorker类的startTime属性)。41位的时间截,可以使用69年,年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69
 10位的数据机器位,可以部署在1024个节点,包括5位datacenterId和5位workerId<br>
 12位序列,毫秒内的计数,12位的计数顺序号支持每个节点每毫秒(同一机器,同一时间截)产生4096个ID序号
 加起来刚好64位,为一个Long型。<br>
 SnowFlake的优点是,整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分),并且效率较高,经测试,SnowFlake每秒能够产生26万ID左右。

上面这种分位,可能有些不是很适合服务器很多的游戏。这里留给我们可部署的服务器节点站位10个

System.out.print(1 << 10);

算得结果就是1024个服务器,1024个服务器对于大多数游戏应该是够用了。但是极个别的1024个服务器节点可能不够。我们可以有很多办法解决此问题。

1.独立ID服务器:

同一个ID_SERVER可以同时为多个游戏服务器提供ID,游戏服务器可以固定自定ID服务器,也可以吧ID服务器做成集群。这样我们的游戏就不受1024个节点的限制了!
    但是有注意的一点,不要一个一个的去拿ID。毕竟不是当前进程去远程拿ID还是有网络、IO等消耗。较好的做法是一次拿一批,比如每次拿1000个然后缓存在本地服务器,当1000个快要耗尽时再去拿一批ID。

2.就是改Snowflake的分位

Snowflake能使用69年,如果觉得时间过长可以缩短时间的位数。比如39位可以用17年。那么我们机器标示就是12位就可以有4096个服务器节点。如果还是觉得不好我们可以把单位时间做到秒级时间占31位,我们现在还有32位可支配。后面自增系列16位,一秒钟可以生成65536个ID,同样机器标示位16位也可以65536个服务器节点。怎么组合就看你自己的需求了。

Snowflake源码

package com.sojoys.artifact.tools;
/**
 * Twitter_Snowflake<br>
 * SnowFlake的结构如下(每部分用-分开):<br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * 1位标识,由于long基本类型在Java中是带符号的,最高位是符号位,正数是0,负数是1,所以id一般是正数,最高位是0<br>
 * 41位时间截(毫秒级),注意,41位时间截不是存储当前时间的时间截,而是存储时间截的差值(当前时间截 - 开始时间截)
 * 得到的值),这里的的开始时间截,一般是我们的id生成器开始使用的时间,由我们程序来指定的(如下下面程序IdWorker类的startTime属性)。41位的时间截,可以使用69年,年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * 10位的数据机器位,可以部署在1024个节点,包括5位datacenterId和5位workerId<br>
 * 12位序列,毫秒内的计数,12位的计数顺序号支持每个节点每毫秒(同一机器,同一时间截)产生4096个ID序号<br>
 * 加起来刚好64位,为一个Long型。<br>
 * SnowFlake的优点是,整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分),并且效率较高,经测试,SnowFlake每秒能够产生26万ID左右。
 */
public class SnowflakeIdWorker {

    // ==============================Fields===========================================
    /** 开始时间截 (2015-01-01) */
    private final long twepoch = 1420041600000L;

    /** 机器id所占的位数 */
    private final long workerIdBits = 5L;

    /** 数据标识id所占的位数 */
    private final long datacenterIdBits = 5L;

    /** 支持的最大机器id,结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);

    /** 支持的最大数据标识id,结果是31 */
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);

    /** 序列在id中占的位数 */
    private final long sequenceBits = 12L;

    /** 机器ID向左移12位 */
    private final long workerIdShift = sequenceBits;

    /** 数据标识id向左移17位(12+5) */
    private final long datacenterIdShift = sequenceBits + workerIdBits;

    /** 时间截向左移22位(5+5+12) */
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

    /** 生成序列的掩码,这里为4095 (0b111111111111=0xfff=4095) */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);

    /** 工作机器ID(0~31) */
    private long workerId;

    /** 数据中心ID(0~31) */
    private long datacenterId;

    /** 毫秒内序列(0~4095) */
    private long sequence = 0L;

    /** 上次生成ID的时间截 */
    private long lastTimestamp = -1L;

    //==============================Constructors=====================================
    /**
     * 构造函数
     * @param workerId 工作ID (0~31)
     * @param datacenterId 数据中心ID (0~31)
     */
    public SnowflakeIdWorker(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can‘t be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can‘t be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }

    // ==============================Methods==========================================
    /**
     * 获得下一个ID (该方法是线程安全的)
     * @return SnowflakeId
     */
    public synchronized long nextId() {
        long timestamp = timeGen();

        //如果当前时间小于上一次ID生成的时间戳,说明系统时钟回退过这个时候应当抛出异常
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        //如果是同一时间生成的,则进行毫秒内序列
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒内序列溢出
            if (sequence == 0) {
                //阻塞到下一个毫秒,获得新的时间戳
                timestamp = tilNextMillis(lastTimestamp);
            }
        }
        //时间戳改变,毫秒内序列重置
        else {
            sequence = 0L;
        }

        //上次生成ID的时间截
        lastTimestamp = timestamp;

        //移位并通过或运算拼到一起组成64位的ID
        return ((timestamp - twepoch) << timestampLeftShift) //
                | (datacenterId << datacenterIdShift) //
                | (workerId << workerIdShift) //
                | sequence;
    }

    /**
     * 阻塞到下一个毫秒,直到获得新的时间戳
     * @param lastTimestamp 上次生成ID的时间截
     * @return 当前时间戳
     */
    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    /**
     * 返回以毫秒为单位的当前时间
     * @return 当前时间(毫秒)
     */
    protected long timeGen() {
        return System.currentTimeMillis();
    }

    //==============================Test=============================================
    /** 测试 */
    public static void main(String[] args) {
        SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
        for (int i = 0; i < 1000; i++) {
            long id = idWorker.nextId();
            System.out.println(Long.toBinaryString(id));
            System.out.println(id);
        }
    }
}

? 著作权归作者所有

原文地址:https://my.oschina.net/dengying/blog/1838133

原文地址:https://www.cnblogs.com/jpfss/p/9968476.html

时间: 2024-10-08 13:16:43

分布式ID解决方案的相关文章

我爱java系列之---【分布式ID生成解决方案:UUID、Redis生成id、snowflake】

唯一id生成方案: a. 使用UUID生成唯一主键: 优点: 全局唯一. 缺点: 因为生成的内容是字符串, 不能排序, 不能按照时间先后排序,因为生成的是字符串类型的id, 可读性差. b. 使用redis来生成全局唯一主键: 优点: redis是内存操作, 速度快, 生成的是数字, 可读性好, 并且可以按照生成的时间先后排序. 缺点: 如果整个系统没有用到redis技术, 那么这里使用redis会增加系统的技术复杂度.   应用服务器到redis服务器获取唯一id, 增加网络io. c. sn

Java分布式ID生成解决方案

分布式ID生成器 我们采用的是开源的twitter(  非官方中文惯称:推特.是国外的一个网站,是一个社交网络及微博客服务)  的snowflake算法(推特雪花算法). 封装为工具类,源码如下: package util; import java.lang.management.ManagementFactory; import java.net.InetAddress; import java.net.NetworkInterface; /** * <p>名称:IdWorker.java&

【G】开源的分布式部署解决方案(三) - 一期规划定稿与初步剖析

G.系列导航 [G]开源的分布式部署解决方案 - 预告篇 [G]开源的分布式部署解决方案(一) - 开篇 [G]开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的 [G]开源的分布式部署解决方案(三) - 一期规划定稿与初步剖析 抱歉 首先我先说声抱歉,因为上一篇结尾预告第三篇本该是“部署项目管理”,那为什么变成本篇呢? 请容我解释一下,在预告篇到现在为止,经常会有人问我这个项目到底是干什么的.或许之前写的比较粗糙.那我相信目前定稿后的功能概览图应该会给大家一个比较清晰的认识.

分布式事务解决方案---阅读--篇1--关于分布式系统的数据一致性问题

self: 这篇文章逻辑不算很清晰,但讲到的点还算是比较好的.自己总结一下可以做不错的参考: 1. 这边文章主要讲了两个方面,一方面是MQ的消息可靠性问题,另一方面是MQ可以被利用来做补偿机制的最终一致性分布式事务解决方案. 2. 关于MQ消息的问题大致有下面三个 2.1 如何保证A->M的消息,M一定接收到了,同样,如何保证M->A的消息,M一定接收到了 2.2 如果数据需要一致性更新,比如A发送了三条消息给M,M要么全部保存,要么全部不保存,不能够只保存其中的几条记录.我们假设更新的数据是

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

阿里微服务架构下分布式事务解决方案-GTS

虽然微服务现在如火如荼,但对其实践其实仍处于初级阶段.即使互联网巨头的实践也大多是试验层面,鲜有核心业务系统微服务化的案例.GTS是目前业界第一款,也是唯一的一款通用的解决微服务分布式事务问题的中间件,而且可以保证数据的强一致性.本文将对GTS做出深入解读. 微服务倡导将复杂的单体应用拆分为若干个功能简单的.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.概念2012年提出迅速火遍全球,被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.根据Netfl

阿里开源分布式事务解决方案 Fescar 全解析

广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为"Fescar",希望帮助业界解决微服务架构下的分布式事务问题,今天我们一起来深入了解. FESCAR on GitHub https://github.com/alibaba/fescar 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,系统微服务化后,一个看似简单的功能,

搞懂分布式技术11:分布式session解决方案与一致性hash

搞懂分布式技术11:分布式session解决方案与一致性hash session一致性架构设计实践 原创: 58沈剑 架构师之路 2017-05-18 一.缘起 什么是session? 服务器为每个用户创建一个会话,存储用户的相关信息,以便多次请求能够定位到同一个上下文. Web开发中,web-server可以自动为同一个浏览器的访问用户自动创建session,提供数据存储功能.最常见的,会把用户的登录信息.用户信息存储在session中,以保持登录状态. 什么是session一致性问题? 只要

搞懂分布式技术12:分布式ID生成方案

搞懂分布式技术12:分布式ID生成方案 ## 转自: 58沈剑 架构师之路 2017-06-25 一.需求缘起 几乎所有的业务系统,都有生成一个唯一记录标识的需求,例如: 消息标识:message-id 订单标识:order-id 帖子标识:tiezi-id 这个记录标识往往就是数据库中的主键,数据库上会建立聚集索引(cluster index),即在物理存储上以这个字段排序. 这个记录标识上的查询,往往又有分页或者排序的业务需求,例如: 拉取最新的一页消息 select message-id/