1.公民身份证是如何生产的?
根据中华人民共和国国家标准GB 11643-1999 公民身份号码规则
文章插图
示例:
文章插图
校验码公式
文章插图
校验码规则说明
文章插图
2.分布式系统中"身份证"
分布式系统 , 有的业务系统 , 都有生成ID的需求 , 如订单id , 商品id , 文章ID等 。这个"身份证"一般要求:
>>全局唯一
>>有序
分布式系统中"身份证"生成常用方法:
1.数据库生成法
沈剑老师在<细聊分布式ID生成方法>中提到两个方法:1.单个法(auto_increment) 2.批量法(也称步长法) 其中详述了它们的优缺点 , 我就不一一赘述了 。
2.redis生成法
分布式唯一ID极简教程 中提到 , 不赘述
3.zk生成法
与redis类似 , 不赘述 。
4.mongo生成法
分布式唯一ID极简教程 中提到 , 不赘述
5.类snowflakes生成法
沈剑老师在<细聊分布式ID生成方法>中也提到 , 不赘述
6.uuid法
沈剑老师在<细聊分布式ID生成方法>中也提到 , 不赘述
7.msic法
其中 , 1~6种方法 , 网上都可以轻易找到 , 这里就不赘述了 。
重点是方式 7 , 通过业务结合 , 灵活利用1~6来做 , 下面是我根据公民身份证唯一的思路来设计订单号一种方式 , 仅供参考
说明:
1.时间戳为毫秒级
2.用户号9位可以满足大部分系统需求 , 可以根据系统修正
3.顺序码 3位 是该用户同时下单的顺序码 , 先从redis查找 , 该用户在1分钟之内是否有订单 , 没有则设置为1 , 返回1 , 否则增加1
4.校验码 , 验证订单号是否符合规则 , 不符合规则的抛弃 。
文章插图
5. 建议使用数据库+redis缓存方式来做 , 多库的时候订单号也可以加上库信息
文章插图
小结:
总体而言 , 分布式唯一ID需要满足以下条件:
- 高可用性:不能有单点故障 。
- 全局唯一性:不能出现重复的ID号 , 既然是唯一标识 , 这是最基本的要求 。
- 趋势递增:在MySQL InnoDB引擎中使用的是聚集索引 , 由于多数RDBMS使用B-tree的数据结构来存储索引数据 , 在主键的选择上面我们应该尽量使用有序的主键保证写入性能 。
- 时间有序:以时间为序 , 或者ID里包含时间 。这样一是可以少一个索引 , 二是冷热数据容易分离 。
- 分片支持:可以控制ShardingId 。比如某一个用户的文章要放在同一个分片内 , 这样查询效率高 , 修改也容易 。
- 单调递增:保证下一个ID一定大于上一个ID , 例如事务版本号、IM增量消息、排序等特殊需求 。
- 长度适中:不要太长 , 最好64bit 。使用long比较好操作 , 如果是96bit , 那就要各种移位相当的不方便 , 还有可能有些组件不能支持这么大的ID 。
- 信息安全:如果ID是连续的 , 恶意用户的扒取工作就非常容易做了 , 直接按照顺序下载指定URL即可;如果是订单号就更危险了 , 竞争对手可以直接知道我们一天的单量 。所以在一些应用场景下 , 会需要ID无规则、不规则 。
【1】https://mp.weixin.qq.com/s/0H-GEXlFnM1z-THI8ZGV2Q
【2】https://mp.weixin.qq.com/s?__biz=MzI4NDY5Mjc1Mg==&mid=2247484269&idx=1&sn=795446b290f75c3129c50f8fa2e0b2c8&chksm=ebf6db12dc815204e81f6fddc4e690c3315c0e3ce71753b73720e74d47b9d08c633a617ccd95&scene=27#wechat_redirect
【分布式系统中"身份证"是如何生成的?】
推荐阅读
- MySQL使用WHERE子句来过滤结果集中的行记录
- 五种材质让你了解中国茶具文化
- 电视是给穷人看的 古代穷人吃什么
- 家中茶具的设计摆放原则
- 宝宝受风起疙瘩怎么办?
- 中国五大名窑,定瓷
- 中国五大名窑,哥瓷
- 中国茶具的发展历史
- 每天6克茶叶抗衰老
- 中国历代茶具发展