snowflake

算法概述 分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID，并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求，最初Twitter把存储系统从MySQL迁移到Cassandra，因为Cassandra没有顺序ID生成机制，所以开发了这样一套全局唯一ID生成服务。 该项目地址（Scala实现）： https://github.com/twitter/snowflake python版项目地址： https://github.com/erans/pysnowflake ID结构 Snowflake生成的是Long类型的ID，一个Long类型占8个字节，每个字节占8比特，也就是说一个Long类型占64个比特。 snowflake的结构如下(每部分用-分开): 注：上图的 工作机器id（10比特）=数据中心（占左5比特）+ 机器ID（占右5比特） Snowflake ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 数据中心（占5比特）+ 机器ID（占5比特）+ 自增值（占12比特） 第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)

一、数据库瓶颈 不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。 1、IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。 第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。 2、CPU瓶颈 第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。 第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念： 以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。 结果： 每个库的结构都一样； 每个库的数据都不一样，没有交集； 所有库的并集是全量数据； 场景： 系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。 分析： 库多了，io和cpu的压力自然可以成倍缓解。 2、水平分表 概念： 以字段为依据，按照一定策略（hash、range等）

一般单机或者单数据库的项目可能规模比较小，适应的场景也比较有限，平台的访问量和业务量都较小，业务ID的生成方式比较原始但是够用，它并没有给这样的系统带来问题和瓶颈，所以这种情况下我们并没有对此给予太多的关注。但是对于大厂的那种大规模复杂业务、分布式高并发的应用场景，显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成，而且在分布式环境下这种方式已经无法满足业务的需求，不仅无法完成业务能力，业务ID生成的速度或者重复问题可能给系统带来严重的故障。所以这一次，我们看看大厂都是怎么分析和解决这种ID生成问题的，同时，我也将我之前使用过的方式拿出来对比，看看有什么问题，从中能够得到什么启发。 分布式ID的生成特性 在分析之前，我们先明确一下业务ID的生成特性，在此特性的基础上，我们能够对下面的这几种生成方式有更加深刻的认识和感悟。 全局唯一，这是基本要求，不能出现重复。 数字类型，趋势递增，后面的ID必须比前面的大，这是从MySQL存储引擎来考虑的，需要保证写入数据的性能。 长度短，能够提高查询效率，这也是从MySQL数据库规范出发的，尤其是ID作为主键时。 信息安全，如果ID连续生成，势必会泄露业务信息，甚至可能被猜出，所以需要无规则不规则。 高可用低延时，ID生成快，能够扛住高并发，延时足够低不至于成为业务瓶颈。 分布式ID的几种生成办法

最近在研究分布式框架的组件和整体设计思路。所有的问题，一旦涉及分布式难度就呈几何倍数的提升。包括最常见的ID生成也是，单机情况下，使用数据库自增ID、UUID都是简单易行的选择 但在分布式环境下，就需要考虑同业务部署多套以后，ID重复的问题。使用数据库则数据库容易成为瓶颈，使用UUID又没有顺序，数据库集成又会遇到递增步长等问题。最后，数据库（也可使用redis）号段生成器和snowFlake就成为了目前分布式ID生成器的主流 我所知大部分互联网公司的分布式ID生成器，其实都是一个网络服务或集群，单独部署。其他应用程序通过网络去获取分布式的全局唯一ID。使用网络服务的方式，好处显而易见，就是方便集中管理，只要生成器设计的没问题，基本ID就能保证整体趋势是递增的。坏处就是获取效率被明显降低了 另外针对我司来说，由于项目的性质，采用分布式ID生成器，对开发和上线部署及其后期的运维都会带来一定的麻烦。毕竟上线后，项目的管理权就不在我们手上了，所以为了保证分布式ID生成器的稳定性，尽量不采取分布式ID生成中心的策略。于是，留给我的选择就只剩下了SnowFlakeID（雪花ID）了。 什么是SnowFlakeID SnowFlake是twitter公司内部分布式项目采用的ID生成算法，开源后广受国内大厂的好评。由这种算法生成的ID，我们就叫做SnowFlakeID

文章目录 MyBatis-Plus （一）概述 （二）快速入门 1. 创建数据库和表 2. 创建SpringBoot项目导入项目依赖 3. 配置 application.properties 4. 主体测试代码 （三）日志输出 1. 配置 2. 结果 （四）基本操作测试 1. 数据插入测试&雪花算法 2. 主键生成策略 2.1 主键自增 2.2 注解TableId 3. 更新数据操作 4. 自动填充 5. 查询操作 6. 分页查询 7. 删除操作 8. 逻辑删除 9. 乐观锁操作 （五）性能分析插件 1. 配置 2. 测试 （六）条件构造器 1. isNotNull、ge、gt、lt、le 2. eq 3. between 4. 模糊查询 5. inSql 6. orderByAsc、orderByDesc （七）代码生成器 1. 新建一个SpringBoot项目 2. 编写代码生成器 3. 测试结果 MyBatis-Plus （一）概述 MyBatis-Plus（简称 MP）是一个 MyBatis 的增强工具，在 MyBatis 的基础上只做增强不做改变，为简化开发、提高效率而生；是 MyBatis 最好的搭档，就像魂斗罗中的 1P、2P，基友搭配，效率翻倍！ 官网地址： https://mp.baomidou.com/ 特性： 无侵入、损耗小、强大的 CRUD 操作、支持

去年做了一个产品，会经常导入导出大量的外部数据，这些数据的ID有的是GUID类型，有的是字符串，也有的是自增。GUID类型没有顺序，结果要排序得借助其它业务字段，整体查询效率比较低；字符串ID本来是用来转换GUID的或者数字ID的，结果有些字符串ID不符合规范，常常有特殊数据需要处理；自增主键ID的数据导入合并经常有冲突。 为了避免GUID主键的“索引页分裂”问题，提高查询效率，同时为了解决分布式环境下的数据导入合并问题，强烈需要一种分布式的，有序的ＩＤ生成方案。我参考了雪花ＩＤ（Twitter-Snowflake，64位自增ID算法）实现方案，设计一个更容易肉眼观察数值连续有序的分布式ＩＤ方案。 跟雪花ＩＤ方案一样，都是使用时间数据做为生成ＩＤ的基础，不同的在于对数据的具体处理方式。另外，为了确保每台机器ＩＤ的不同，可以配置指定此ID，在应用程序配置文件中如下配置： <!-- 分布式ID标识，3位整数，范围101-999 大小 --> < add key ="SOD_MachineID" value ="101" /> 如果不配置分布式ID，默认将根据当前机器ＩＰ随机生成３位分布式机器ＩＤ。 该算法的实现比雪花算法简单不少，详细的不多说，先直接看代码： /// <summary> /// 获取一个新的有序GUID整数 /// </summary> /// <param name=

一、概念先行 1）SQL相关的 逻辑表：水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为2张表，分别是t_order_0到t_order_1，他们的逻辑表名为t_order。 真实表：在分片的数据库中真实存在的物理表。例：示例中的t_order_0到t_order_1 数据节点：数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0；ds_0.t_order_1； 绑定表：指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。 广播表：指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表，示例中的t 2）分片相关 分片键：用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。 分片算法：通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片

刷题记录 2019.12.26 【暴力】Temporarily unavailable 【dp】B. K for the Price of On 【找规律】CF1263A Sweet Problem 【结论题】Everyone is a Winner! 【并查集+思维】Codeforces Round #603 (Div. 2) D. Secret Passwords 【线段树+思维】E. Editor 没调出来 2019.12.28 【线段树+思维】E. Editor 没调出来 【dp+dfs】P1441 砝码称重 【模拟】T112459 「SWTR-03」Password 【贪心】增减描述的排列 2019.12.29 【dp】P1387 最大正方形 【树形dp】P2279 [HNOI2003]消防局的设立 【线段树+思维】E. Editor 依旧没调出来 2019.12.31 【dfs+剪枝】P1120 小木棍 ［数据加强版］ 从04-19 15:16:20就开始提交一直到12-31 14:53:54终于A了 2020.1.2 【神仙hash表+空间优化】Snowflake Snow Snowflakes 【字符串hash】兔子与兔子 2020.1.4 【kmp,奇妙的next数组用法】Period poj1961 【trie】前缀统计 【trie】最大异或对 【 \(

【推荐阅读】微服务还能火多久？>>> 写在前边 前两天公众号有个粉丝给我留言吐槽最近面试：“四哥，年前我在公司受点委屈一冲动就裸辞了，然后现在疫情严重两个多月还没找到工作，接了几个视频面试也都没下文。好多面试官问完一个问题，紧接着说还会其他解决方法吗？ 能干活解决bug不就行了吗？那还得会多少种方法？ ” 面试官应该是对应聘者的回答不太满意，他想听到一个他认为最优的解决方案，其实这无可厚非。同样一个bug，能用一行代码解决问题的人和用十行代码解决问题的人，你会选哪个入职？显而易见的事情！所以看待问题还是要从多个角度出发，每种方法都有各自的利弊。 一、为什么要用分布式ID？ 在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？ 1、什么是分布式ID？ 拿MySQL数据库举个栗子： 在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。 但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有 唯一ID 做标识。此时一个能够生成 全局唯一ID 的系统是非常必要的。那么这个 全局唯一ID 就叫 分布式ID 。 2、那么分布式ID需要满足那些条件？ 全局唯一

面试中关于分布式的问题很多。（分布式事务，基本理论CAP,BASE,分布式锁）先来一个简单的。 简单说一下分布式ID的设计方案？ 首先要明确在分布式环境下，分布式id的基本要求。 1， 全局唯一，在分布式集群下，不同的节点并发生成的分布式id要唯一； 2， 顺序性，分布式id是有序生成 然后给出分布式id的设计方案。 1， 基于数据的自增id生成分布式ID，使用比较简单，缺点是扩展性和可靠性有限； 基于数据库表的自增id 2，基于 snowflake 算法生成； snowflake生成的分布式id是一个64位整数；位数标识如下： 1 标识正负 41位，一般使用System.currentTimeMilles()得到； 5 数据中心标识 5 机器ip标识 12 单位毫秒内可以生成的序数极限 snowflake的生成跟时间相关的使用的是System.currentTimeMilles(),跟冬令时没有关系。 分布式id的进一步要求 可靠性： 即高可用 紧凑性： 64位的整数比较长，不太紧凑，作为索引，存储不占优势。 有意义： 可以放入业务标识或者时间 snowflake的缺点 受时间影响：需要保证分布式集群的时间同步，即NTP ; 可以预测到：容易按照时间规律预测到，进而影响安全性； 小结 回答了分布式id的基本要求，已经常用方案。 原创不易，点赞关注支持一下吧！转载请注明出处