假如表q_reportkeywordsum 的存储使用了分布式数据库,那么假如执行如下语句:
insert into q_reportkeywordsum (id, keywordid) values (2, ...)
由于没有加分库字段,会在所有的数据库的表中插入这个记录,对于不同的分区表, 数据库主键可以重复。 因此, 需要额外使用主键生成机制保障在不同表内的主键不会发生重复。
问题:请问可以采用何种主键生成机制来确保分布式数据库当中的主键唯一。
小伙看你根骨奇佳,潜力无限,来学PHP伐。
采用redis的ID自增生成器 就行,每次插入之前,都去调用一个自增长的函数,返回的数值永远是唯一,全局唯一的
http://www.qixing318.com/article/use-redis-mysql-table-on-the-id-solution.html
方案@情迷丶安瑾年已经给出了具体的方案,具体我补充几点
必须有一个单独的Id生成器服务来为你提供唯一键的生成,可以把这个唯一键的服务集成到分布式数据库,让它来生成唯一键(并不一定依赖数据库生成唯一键,也可以仅仅依赖redis),前提是保持Id服务的高可用,数据的准确性和比较高的QPS,你也不可能仅仅让一个Redis仅仅为你提供唯一Id生成的工作
redis
QPS
Redis
在1中提到了高可用,@情迷丶安瑾年的Redis方案是完全不满足的,因为只要Redis一挂,Id生成规则就很难持续下去(虽然Redis有持久化功能,但是还是会有延迟的).按照@情迷丶安瑾年链接给的方案也有不足之处:第一点,这个Id方案生成的client依赖于具体的数据库,所以它只能放在分布式系统中的服务层;第二点,这里用到了分布式锁,分布式锁的一些异常情况处理也是一件另人头疼的事;第三点,代码中会有并发的BUG,具体在select max(id)这里,除非锁表让其它操作不能插入新的记录
client
BUG
select max(id)
所以无论如何,这些Id在Id生成器服务中必须落库,但是如果每条都落库的话,QPS的天花板很容易就能触碰到,我这里推荐微信唯一Id生成方案万亿级调用系统:微信序列号生成器架构设计及演变
Id服务器里面怎么玩就是你的事情了,但是你必须保证数据的准确性.所以我觉得如果仅仅就依赖Redis来生成Id的话,可能处理的太粗糙了.还是需要对内部实现的细节进行一层封装,可以随时替换生成的方案
楼上的说的很好,redis基本够用了,实现又简单,如果你担心多了一次网络开销影响性能可以参考twitter的snowflake算法,非常高效,网上很多java版本的代码
采用redis的ID自增生成器 就行,每次插入之前,都去调用一个自增长的函数,返回的数值永远是唯一,全局唯一的
http://www.qixing318.com/article/use-redis-mysql-table-on-the-id-solution.html
方案@情迷丶安瑾年已经给出了具体的方案,具体我补充几点
必须有一个单独的Id生成器服务来为你提供唯一键的生成,可以把这个唯一键的服务集成到分布式数据库,让它来生成唯一键(并不一定依赖数据库生成唯一键,也可以仅仅依赖
redis
),前提是保持Id服务的高可用,数据的准确性和比较高的QPS
,你也不可能仅仅让一个Redis
仅仅为你提供唯一Id生成的工作在1中提到了高可用,@情迷丶安瑾年的
Redis
方案是完全不满足的,因为只要Redis
一挂,Id生成规则就很难持续下去(虽然Redis
有持久化功能,但是还是会有延迟的).按照@情迷丶安瑾年链接给的方案也有不足之处:第一点,这个Id方案生成的client
依赖于具体的数据库,所以它只能放在分布式系统中的服务层;第二点,这里用到了分布式锁,分布式锁的一些异常情况处理也是一件另人头疼的事;第三点,代码中会有并发的BUG
,具体在select max(id)
这里,除非锁表让其它操作不能插入新的记录所以无论如何,这些Id在Id生成器服务中必须落库,但是如果每条都落库的话,
QPS
的天花板很容易就能触碰到,我这里推荐微信唯一Id生成方案万亿级调用系统:微信序列号生成器架构设计及演变Id服务器里面怎么玩就是你的事情了,但是你必须保证数据的准确性.所以我觉得如果仅仅就依赖
Redis
来生成Id的话,可能处理的太粗糙了.还是需要对内部实现的细节进行一层封装,可以随时替换生成的方案楼上的说的很好,redis基本够用了,实现又简单,如果你担心多了一次网络开销影响性能可以参考twitter的snowflake算法,非常高效,网上很多java版本的代码