分库分表:
跨库的问题
分布式事务问题
查询数据结果集合并
全局唯一性ID保证
要求:
1、全局唯一性:不能出现重复的id号(基本的要求)。
2、信息安全:防止恶意用户规矩id的规则来获取数据。混淆效果
3、数据递增:保证我下一个ID一定大于上一个ID。
当前201709122030下一个:201709122031下一个:201709122032
互斥关系:信息安全、数据递增规律
CREATE TABLE `tl_id` (`id` varchar(255) NOT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;
业界分案:
UUID:
通用唯一识别码16个字节128位的长数字、
组成部分:当前日期和时间序列+全局的唯一性网卡mac地址
执行任务数:10000------------------------所有线程共耗时:38.305 s并发执行完耗时:449.0 ms单任务平均耗时:3.8305 ms单线程最小耗时:0.0 ms单线程最大耗时:193.0 ms
总结:
优点代码实现简单、不占用宽带、数据迁移不受影响
缺点无序、无法保证趋势递增(要求3)字符存储、传输、查询慢、不可读
Snowflake雪花算法
国外的twitter分布式下iD生成算法
1bit+41bit+10bit+10+bit=62bit
高位随机+毫秒数+机器码(数据中心+机器id)+10的流水号
国内:
保证数据的唯一性就行了IDC机房。
总结:
优点代码实现简单、不占用宽带、数据迁移不受影响、低位趋势递增缺点强以来时钟(多台服务器时间一定要一样)、无序无法保证趋势递增(要求3)
Mysql:
奇数跟我们偶数递增步长2
适合小型互联网公司、比如可以知道我们一定生成的ID数量 五万的订单量
一年1千8百万
Mysql一张表500万
如果公司每天订单量5万的数据 我们用mysql设置步长位100的话可以用27年
只能为100库 公司来到风投了 每天的订单量50万100万的时候
总结:
优点代码实现方便、性能不错、数字排序、可读性很强缺点受限数据库、扩展麻烦、插入数据库才能拿到ID、单点故障的问题
主从同步的时候:电商下单->支付insert master db select数据 因为数据同步延迟导致查不到这个数据。加cache(不是最好的解决方式)数据要求比较严谨的话查master主库。
CREATE TABLE `tl_num` (
`id` bigint(11) NOT NULL AUTO_INCREMENT,
KEY (`id`) USING BTREE
) ENGINE=InnoDB auto_increment=1 DEFAULT CHARSET=utf8;
Redis:
执行任务数:10000------------------------所有线程共耗时:136.587 s并发执行完耗时:1.515 s单任务平均耗时:13.6587 ms单线程最小耗时:1.0 ms单线程最大耗时:254.0 ms
总结:
优点不依赖数据、灵活方便、性能优于数据库的、没有单点故障(高可用)缺点需要占用网络资源、性能要比本地生成慢、需要增加插件
Copyright © 广州京杭网络科技有限公司 2005-2024 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有