大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
受群里小伙伴之邀,搞一个分库分表案例,这样让很多没用过分库分表的心里也有个底,不然永远看到的都是网上的各种概念和解决方案性的文章。
创新互联公司长期为1000+客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为偃师企业提供专业的成都网站建设、成都网站制作,偃师网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。
由于用户表过于庞大,采取相关SQL优化,还是不能满足,所以现对其进行做分库分表。
数据库: my-sharding
数据库表: t_user
建表语句如下:
关于数据库分库分表通常有两种方案:
下面我们来演示水平拆分,大致思路:
加入有2000万条数据,那么为了方便演示,我们就暂定分为五个库,每个数据库对应五个表。
五个数据库:
每个数据库有五张表:
建表语句如下:
使用技术栈: JDK8 + MySQL + Spring Boot + Mybatis + Shardingsphere + Druid
maven 相关依赖:
配置文件相关配置如下:
分库分表的两个分片类:
下面是业务部分代码,先看 UserMapper.xml 内容:
UserMapper 接口:
为了更好地演示,我这里加入了 controller 层和 service 层,这也是大家平常开发套路。
service 层代码如下:
controller层代码如下:
最后是项目的启动类:
启动项目,启动成功:
下面我们来演示一下新增数据和查询。
先来添加数据到数据库中,这里使用的是IDEA中restful工具:
后台日志:
再查看数据库表中:
到此,我们的数据依旧落库,下面我们来演示一下数据查询。
浏览器里输入:
返回数据:
后台日志:
从日志和返回结果可以看出,已经为我们正确的选择到对应的数据库和表了,这样,一个分库分表的查询就成功了。
本文没有太多的概念,直接使用案例演示。相关概念性的文章,还有分库分表解决方案的文章,网上一堆堆的,感兴趣可以自行查阅。
Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的id必须不同。各种主键ID生成策略对比,见 常见分布式主键ID生成策略
把 41位的时间前缀 , 10位的节点标识 , 12位的sequence 组合在一起。
除了最高位bit标记为不可用以外,其余三组bit占位均可浮动,看具体的业务需求而定。 默认情况下41bit的时间戳,1970年算起可以支持该算法使用到2038年,10bit的工作机器id可以支持1024台机器,序列号支持1毫秒产生4096个自增序列id 。
Snowflake是Twitter在2010年用Scala语言写的一套主键生成策略,用Thrift对外发布主键生成服务,其中依赖了Twitter内部的Infrastructure,后来Twitter用 Twitter-server 代替了Snowflake,自2012年起就未更新。见 Twitter-Snowflake项目地址(Tags:snowflake-2010)
之前写了一个Java的实现,改自网上一个版本: Twitter的分布式自增ID算法Snowflake实现分析及其Java、Php和Python版 。后来看到当当网的 Sharding-JDBC 分库分表中间件已实现了此算法。就直接在其中添加了一些新特性,已merge。( 具体实现 , 说明文档 )
添加3种IdGenerator实现。
用笔记本(i7-3632QM 2.2GHz 四核八线程)测试了下,每秒生成409万(理论上的峰值),CPU占用率18.5%。
musql分库分表后java用Mybatis可以很方便的实现分库分表,比如有几个数据源,每个库对应一个数据源,然后配置好负责读写的路由和表的配置,保证读写的数据库一致性就可以了
可以按照时间划分库,或者按照账户数量等,在一张表里面存储账户对应的库名,然后每次操作库的时候从内存中通过账户id获取库名,表名应该是统一的,只是对应的表明前缀不一样而已(前缀是根据账户id或者一定规则开头,后半部分应该都一样的)
水平分表的话,200张,你应该按照实际需求去做,因为200毕竟不是一个小数目,首先举个例子,就像电话号码,130开头的一张表,131开头的一张表,但是你这个具体就不知道了,还有就是例如按照单数双数分也可,然后最好是按照主键列去分表会比较合乎规范。