分布式ID方案

分布式ID唯一:
整个系统ID唯一
ID是数字类型,而且是趋势递增的
ID简短,查询效率快

趋势递增:
在一段时间内,生成的ID是递增的趋势,在一段时间内生成的ID在 0 - 1000之间
一段时间之后生成的ID在1000 - 2000 之间 但是在 0 -1000 之间的时候 ID有可能 第一次是 12 第二次是10 第三次是14

UUID生成方案:
代码实现简单,本机生成,性能没有问题,ID唯一性强,数据迁移简单

• ID 无序,不能保证趋势递增 字符串存储,查询效率慢,占用的储存空间大

  ID 本身不含有业务含义,不可读

MySQL 主键自增方案:
数字化,id递增
查询效率高
具有一定的业务可读性

• mysql挂掉无法生存ID

• 数据库压力大,高并发扛不住 可以使用多实例下的MySQL主键自增来完成 利用设置步长的主键自增

  
  但是这样的方案仅仅解决了单点问题,并且步长确定,不利于扩容,数据库的压力相对来说也比较大,数据库自身的性能无法满足高并发

  雪花ID的算法依赖于机器的时钟,如果服务器的始终回拨了,会导致重复的ID生成

  Redis自增生成

  改良的Mysql主键自增:
  
  1.注册用户,用户访问ID生成服务, 查询数据库,找到对应类型的id记录,
  max_id 为0,步长为1000
  2.生成ID服务将其返回,并将max_id设置更新+步长为1000
  3.用户服务获取到max_id 0 步长 1000
  4.用户服务用 max_id 1 max_id + 步长范围 1 - 1000范围的ID
  5.用户服务将这个区间保存到jvm中
  6.用户服务需要的时候会在这个区间中获取id
  7.如果将区间的值使用完了,再去请求生产ID服务的接口,获取到max_id是1000,就可以使用下一个步长区间

   这样就可以保证一段时间才会访问MySQL解决并发高的问题
   
   但是在多线程的环境下会存在竞争问题,多个服务同时获取ID,在获取max_id的时候会存在并发问题
   此时可以利用数据库的锁去完成同一时刻只有一个服务能够获取max_id的需求
   
   还可以有双buffer的方案,
   先获取一个区间,使用到一定额度之后判断第二个buffer区有无获取记录,没有就发起请求获取第二次区间缓存,当第一个区间用完之后先使用第二个区间