c网站制作,徐汇网站设计,川畅咨询 做网站多少钱,网页设计制作成品转自#xff1a;https://my.oschina.net/u/142836/blog/174465 在大型互联网应用中#xff0c;随着用户数的增加#xff0c;为了提高应用的性能#xff0c;我们经常需要对数据库进行分库分表操作。在单表时代#xff0c;我们可以完全依赖于数据库的自增ID来唯一标识一个用…转自https://my.oschina.net/u/142836/blog/174465 在大型互联网应用中随着用户数的增加为了提高应用的性能我们经常需要对数据库进行分库分表操作。在单表时代我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库分表后就不能依赖于每个表的自增ID来全局唯一标识这些数据了。因此我们需要提供一个全局唯一的ID号生成策略来支持分库分表的环境。下面来介绍两种非常优秀的解决方案 1. 数据库自增ID——来自Flicker的解决方案 因为MySQL本身支持auto_increment操作很自然地我们会想到借助这个特性来实现这个功能。Flicker在解决全局ID生成方案里就采用了MySQL自增长ID的机制auto_increment replace into MyISAM。一个生成64位ID方案具体就是这样的先创建单独的数据库(eg:ticket)然后创建一个表 CREATE TABLE Tickets64 (id bigint(20) unsigned NOT NULL auto_increment, stub char(1) NOT NULL default , PRIMARY KEY (id), UNIQUE KEY stub (stub) ) ENGINEMyISAM 当我们插入记录后执行SELECT * from Tickets64查询结果就是这样的 -------------------------
| id | stub |
-------------------------
| 72157623227190423 | a |
-------------------------在我们的应用端需要做下面这两个操作在一个事务会话里提交 REPLACE INTO Tickets64 (stub) VALUES (a); SELECT LAST_INSERT_ID(); 这样我们就能拿到不断增长且不重复的ID了。到上面为止我们只是在单台数据库上生成ID从高可用角度考虑接下来就要解决单点故障问题Flicker启用了两台数据库服务器来生成ID通过区分auto_increment的起始值和步长来生成奇偶数的ID。 TicketServer1:
auto-increment-increment 2
auto-increment-offset 1 TicketServer2: auto-increment-increment 2 auto-increment-offset 2 最后在客户端只需要通过轮询方式取ID就可以了。 优点充分借助数据库的自增ID机制提供高可靠性生成的ID有序。缺点占用两个独立的MySQL实例有些浪费资源成本较高。参考http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/ 2. 独立的应用程序——来自Twitter的解决方案 Twitter在把存储系统从MySQL迁移到Cassandra的过程中由于Cassandra没有顺序ID生成机制于是自己开发了一套全局唯一ID生成服务Snowflake。GitHub地址https://github.com/twitter/snowflake。根据twitter的业务需求snowflake系统生成64位的ID。由3部分组成 41位的时间序列精确到毫秒41位的长度可以使用69年
10位的机器标识10位的长度最多支持部署1024个节点
12位的计数顺序号12位的计数顺序号支持每个节点每毫秒产生4096个ID序号最高位是符号位始终为0。 优点高性能低延迟独立的应用按时间有序。缺点需要独立的开发和部署。 转载于:https://www.cnblogs.com/hxphp/p/6824640.html
