transition,夏日绝句,directx-果粒新闻,独立撰稿人喂你“食”新闻

欢迎重视头条号:老顾聊技能

精品原创技能共享,常识的组装工


目录

  1. 前语
  2. UUID
  3. mysql主键自增
  4. mysql多实例主键自增
  5. 雪花算法
  6. redis生成计划
  7. 总结
  8. 悬念

前语

分布式体系中咱们会对一些数据量大的事务进行分拆,如:用户表,订单表。由于数据量巨大一张表无法接受,就会对其进行分库分表。小伙伴们能够去看一下老顾的曾经的文章你知道怎样分库分表吗?怎样做到永不搬迁数据和防止热门吗?

怎样永不搬迁数据和防止热门? 依据服务器目标分配数据量(揭秘篇)

但一旦涉及到分库分表,就会引申出分布式体系中仅有主键ID的生成问题永不搬迁数据和防止热门的文章中要求需求仅有ID的特性

1、整个体系ID仅有

2、ID是数字类型,并且是趋势递加的

3、ID简略,查询功率快

什么是递加?如:第一次生成的ID为12,下一次生成的ID是13,再下一次生成的ID是14。这个便是生成ID递加。

什么是趋势递加?如:在一段时刻内,生成的ID是递加的趋势。如:再一段时刻内生成的ID在【0,1000】之间,过段时刻生成的ID在【1000,2000】之间。但在【0-1000】区间内的时分,ID生成有或许第一次是12,第2次是10,第三次是14。

那有什么计划呢?往下看

UUID

这个计划是小伙伴们第一个能过考虑到的计划

长处:

1、代码完成简略。

2、本机生成,没有功能问题

3、由于是全球仅有的ID,所以搬迁数据简略

缺陷:

1、每次生成的ID是无序的,无法确保趋势递加

2、UUID的字符串存储,查询功率慢

3、存储空间大

4、ID本事无事务意义,不可读

运用场景:

1、相似生成token令牌的场景

2、不适用一些要求有趋势递加的ID场景

此UUID计划是不适用老顾的需求

mysql主键自增

这个计划便是运用了mysql的主键自增auto_increment,默许每次ID加1。

长处:

1、数字化,id递加

2、查询功率高

3、具有必定的事务可读

缺陷:

1、存在单点问题,假如mysql挂了,就无法生成iD了

2、数据库压力大,高并发抗不住

mysql多实例主键自增

这个计划便是处理mysql的单点问题,在auto_increment根本上面,设置step步长

每台的初始值分别为1,2,3...N,步长为N(这个事例步长为4)

长处:处理了单点问题

缺陷:一旦把步长定好后,就无法扩容;并且单个数据库的压力大,数据库本身功能无法满意高并发

运用场景:数据不需求扩容的场景

此计划也不满意老顾的需求,由于不方便扩容(记住这个计划,嘿嘿)

雪花snowflake算法

这个算法网上介绍了许多,老顾这儿就不具体介绍。雪花算法生成64位的二进制正整数,然后转换成10进制的数。64位二进制数由如下部分组成:

  • 1位标识符:始终是0
  • 41位时刻戳:41位时刻截不是存储当时时刻的时刻截,而是存储时刻截的差值(当时时刻截 - 开端时刻截 )得到的值,这儿的的开端时刻截,一般是咱们的id生成器开端运用的时刻,由咱们程序来指定的
  • 10位机器标识码:能够布置在1024个节点,假如机器分机房(IDC)布置,这10位能够由 5位机房ID + 5位机器ID 组成
  • 12位序列:毫秒内的计数,12位的计数顺序号支撑每个节点每毫秒(同一机器,同一时刻截)发生4096个ID序号

长处:

1、此计划每秒能够发生409.6万个ID,功能快

2、时刻戳在高位,自增序列在低位,整个ID是趋势递加的,依照时刻有序递加

3、灵敏度高,能够依据事务需求,调整bit位的区分,满意不同的需求

缺陷:

1、依靠机器的时钟,假如服务器时钟回拨,会导致重复ID生成

在分布式场景中,服务器时钟回拨会常常遇到,一般存在10ms之间的回拨;小伙伴们就说这点10ms,很短能够不考虑吧。但此算法便是建立在毫秒等级的生成计划,一旦回拨,就很有或许存在重复ID。

此计划暂不契合老顾的需求(嘿嘿,看看怎样优化这个计划,小伙伴们先记住)

redis生成计划

运用redis的incr原子性操作自增,一般算法为:

年份 + 当天距当年第多少天 + 天数 + 小时 + redis自增

长处:有序递加,可读性强

缺陷:占用带宽,每次要向redis进行恳求

全体测试了这个功能如下:

需求:一起10万个恳求获取ID
1、并发履行完耗时:9s左右
2、单任务均匀耗时:74ms
3、单线程最小耗时:不到1ms
4、单线程最大耗时:4.1s

功能还能够,假如对功能要求不是太高的话,这个计划根本契合老顾的要求

但不完全契合事务老顾期望id从 1 开端趋势递加。(当然算法能够调整为 就一个 redis自增,不需求什么年份,多少天等)。

总结

假如今日老顾就介绍以上几个计划,其实没有必要,网上多的是

一线大厂的分布式id计划绝没有这个简略,他们对高并发,高可用的要求很高

如redis计划中,每次都要去redis去恳求,有网络恳求耗时,并发强依靠了redis。这个规划是有危险的,一旦redis挂了,整个体系不可用

并且一线大厂也会考虑到ID安全性的问题,如:redis计划中,用户是能够猜测下一个id号是多少,由于算法是递加的。

这样的话竞争对手 第一天正午12点下个订单,就能够看到渠道的订单id是多少,第二天正午12点再下一单,又渠道订单id到多少。这样就能够猜到渠道1天能发生多少订单了,这个是肯定不允许的,公司绝密啊。

悬念

一线大厂是怎样规划的呢?老顾这儿先卖个关子,下一篇文章中会介绍一线大厂是怎样规划的,小伙伴们先想一下,回忆上面的计划

老顾提示一下,许多计划的完成,一线大厂的规划思路其实和小伙伴们思路差不多,仅仅多想了1~2层,规划上面多了1~2个环节

这篇文章先到这儿,下一篇重视介绍一线大厂的规划,谢谢!!!


-End-

如有收成,请帮助转发,您的鼓舞是作者最大的动力,谢谢!

10几年的经历实战共享

相关微服务,分布式,高并发,高可用,企业实战,干货等原创文章正在路上

欢迎重视头条号:老顾聊技能

精品原创技能共享,常识的组装工

引荐阅览

1、怎样永不搬迁数据和防止热门? 依据服务器目标分配数据量(揭秘篇)

2、你知道怎样分库分表吗?怎样做到永不搬迁数据和防止热门吗?

3、你了解大型网站的页面静态化吗?

4、你知道怎样更新缓存吗?怎样确保缓存和数据库双写一致性?

5、你知道怎样处理DB读写别离,导致数据不一致问题吗?

6、DB读写别离情况下,怎样处理缓存和数据库不一致性问题?

7、你真的知道怎样运用缓存吗?

8、怎样运用锁,防止缓存击穿?重构思维的重要性

9、海量订单发生的事务高峰期,怎样防止音讯的重复消费?

10、你知道怎样保证出产端100%音讯投递成功吗?