南京做网站建设有哪些,网站建设内部需求调查表,免费甜点网站模板下载,网页设计与制作教学设计文章目录 1. 为什么要分库分表#xff1f;2. 用过哪些分库分表中间件#xff1f;不同的分库分表中间件都有什么优点和缺点#xff1f;3. 你们具体是如何对数据库如何进行垂直拆分或水平拆分的#xff1f;4. 分库分表时#xff0c;数据迁移方案5. 如何设计可以动态扩容缩容… 文章目录 1. 为什么要分库分表2. 用过哪些分库分表中间件不同的分库分表中间件都有什么优点和缺点3. 你们具体是如何对数据库如何进行垂直拆分或水平拆分的4. 分库分表时数据迁移方案5. 如何设计可以动态扩容缩容的分库分表方案6. 分库分表之后id 主键如何处理7. 如何实现 MySQL 的读写分离8. MySQL 主从复制原理的是啥9. MySQL 主从同步延时问题 1. 为什么要分库分表
说白了分库分表是两回事儿大家可别搞混了可能是光分库不分表也可能是光分表不分库都有可能。我先给大家抛出来一个场景。假如我们现在是一个小创业公司现在注册用户就 20 万每天活跃用户就 1 万每天单表数据量就 1000然后高峰期每秒钟并发请求最多就 10。天就这种系统随便找一个有几年工作经验的然后带几个刚培训出来的随便干干都可以。结果没想到我们运气居然这么好碰上个 CEO 带着我们走上了康庄大道业务发展迅猛过了几个月注册用户数达到了 2000 万每天活跃用户数 100 万每天单表数据量 10 万条高峰期每秒最大请求达到 1000好吧没事现在大家感觉压力已经有点大了为啥呢因为每天多 10 万条数据一个月就多 300 万条数据现在咱们单表已经几百万数据了马上就破千万了。但是勉强还能撑着。高峰期请求现在是 1000咱们线上部署了几台机器负载均衡搞了一下数据库撑 1000QPS 也还凑合。但是大家现在开始感觉有点担心了接下来咋整呢…再接下来几个月我的天CEO 太牛逼了公司用户数已经达到 1 亿因为此时每天活跃用户数上千万每天单表新增数据多达 50 万目前一个表总数据量都已经达到了两三千万了扛不住啊数据库磁盘容量不断消耗掉高峰期并发达到惊人的 5000~8000别开玩笑了哥。我跟你保证你的系统支撑不到现在已经挂掉了好吧所以你看到这里差不多就理解分库分表是怎么回事儿了实际上这是跟着你的公司业务发展走的你公司业务发展越好用户就越多数据量越大请求量越大那你单个数据库一定扛不住。
分表
比如你单表都几千万数据了你确定你能扛住么绝对不行单表数据量太大会极大影响你的 sql 执行的性能到了后面你的 sql 可能就跑的很慢了。一般来说就以我的经验来看单表到几百万的时候性能就会相对差一些了你就得分表了。分表是啥意思就是把一个表的数据放到多个表中然后查询的时候你就查一个表。比如按照用户 id 来分表将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内比如每个表就固定在 200 万以内。
分库
分库是啥意思就是你一个库一般我们经验而言最多支撑到并发 2000一定要扩容了而且一个健康的单库并发值你最好保持在每秒 1000 左右不要太大。那么你可以将一个库的数据拆分到多个库中访问的时候就访问一个库好了。
#分库分表前分库分表后并发支撑情况MySQL 单机部署扛不住高并发MySQL从单机到多机能承受的并发增加了多倍磁盘使用情况MySQL 单机磁盘容量几乎撑满拆分为多个库数据库服务器磁盘使用率大大降低SQL 执行性能单表数据量太大SQL 越跑越慢单表数据量减少SQL 执行效率明显提升
2. 用过哪些分库分表中间件不同的分库分表中间件都有什么优点和缺点
这个其实就是看看你了解哪些分库分表的中间件各个中间件的优缺点是啥然后你用过哪些分库分表的中间件。比较常见的包括 Cobar TDDL Atlas Sharding-jdbc Mycat
1. Cobar
阿里 b2b 团队开发和开源的属于 proxy 层方案就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 Cobar 集群Cobar 根据 SQL 和分库规则对 SQL 做分解然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用但是最近几年都没更新了基本没啥人用差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
2. TDDL
淘宝团队开发的属于 client 层方案。支持基本的 crud 语法和读写分离但不支持 join、多表查询等语法。目前使用的也不多因为还依赖淘宝的 diamond 配置管理系统。
3. Atlas
360 开源的属于 proxy 层方案以前是有一些公司在用的但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以现在用的公司基本也很少了。
4. Sharding-jdbc
当当开源的属于 client 层方案目前已经更名为 ShardingSphere后文所提到的 Sharding-jdbc等同于 ShardingSphere。确实之前用的还比较多一些因为 SQL 语法支持也比较多没有太多限制而且截至 2019.4已经推出到了 4.0.0-RC1 版本支持分库分表、读写分离、分布式 id 生成、柔性事务最大努力送达型事务、TCC 事务。而且确实之前使用的公司会比较多一些这个在官网有登记使用的公司可以看到从 2017 年一直到现在是有不少公司在用的目前社区也还一直在开发和维护还算是比较活跃个人认为算是一个现在也可以选择的方案。
5. Mycat
基于 Cobar 改造的属于 proxy 层方案支持的功能非常完善而且目前应该是非常火的而且不断流行的数据库中间件社区很活跃也有一些公司开始在用了。但是确实相比于 Sharding jdbc 来说年轻一些经历的锤炼少一些。
6. 总结
综上现在其实建议考量的就是 Sharding-jdbc 和 Mycat这两个都可以去考虑使用。Sharding-jdbc 这种 client 层方案的优点在于不用部署运维成本低不需要代理层的二次转发请求性能很高但是如果遇到升级啥的需要各个系统都重新升级版本再发布各个系统都需要耦合 Sharding-jdbc 的依赖Mycat 这种 proxy 层方案的缺点在于需要部署自己运维一套中间件运维成本高但是好处在于对于各个项目是透明的如果遇到升级之类的都是自己中间件那里搞就行了。通常来说这两个方案其实都可以选用但是我个人建议中小型公司选用 Sharding-jdbcclient 层方案轻便而且维护成本低不需要额外增派人手而且中小型公司系统复杂度会低一些项目也没那么多但是中大型公司最好还是选用 Mycat 这类 proxy 层方案因为可能大公司系统和项目非常多团队很大人员充足那么最好是专门弄个人来研究和维护 Mycat然后大量项目直接透明使用即可。
3. 你们具体是如何对数据库如何进行垂直拆分或水平拆分的
水平拆分的意思就是把一个表的数据给弄到多个库的多个表里去但是每个库的表结构都一样只不过每个库表放的数据是不同的所有库表的数据加起来就是全部数据。水平拆分的意义就是将数据均匀放更多的库里然后用多个库来扛更高的并发还有就是用多个库的存储容量来进行扩容。 垂直拆分的意思就是把一个有很多字段的表给拆分成多个表或者是多个库上去。每个库表的结构都不一样每个库表都包含部分字段。一般来说会将较少的访问频率很高的字段放到一个表里去然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的你访问频率高的行字段越少就可以在缓存里缓存更多的行性能就越好。这个一般在表层面做的较多一些。 这个其实挺常见的不一定我说大家很多同学可能自己都做过把一个大表拆开订单表、订单支付表、订单商品表。还有表层面的拆分就是分表将一个表变成 N 个表就是让每个表的数据量控制在一定范围内保证 SQL 的性能。否则单表数据量越大SQL 性能就越差。一般是 200 万行左右不要太多但是也得看具体你怎么操作也可能是 500 万或者是 100 万。你的SQL越复杂就最好让单表行数越少。好了无论分库还是分表上面说的那些数据库中间件都是可以支持的。就是基本上那些中间件可以做到你分库分表之后中间件可以根据你指定的某个字段值比如说 userid自动路由到对应的库上去然后再自动路由到对应的表里去。你就得考虑一下你的项目里该如何分库分表一般来说垂直拆分你可以在表层面来做对一些字段特别多的表做一下拆分水平拆分你可以说是并发承载不了或者是数据量太大容量承载不了你给拆了按什么字段来拆你自己想好分表你考虑一下你如果哪怕是拆到每个库里去并发和容量都 ok 了但是每个库的表还是太大了那么你就分表将这个表分开保证每个表的数据量并不是很大。而且这儿还有两种分库分表的方式 一种是按照 range 来分就是每个库一段连续的数据这个一般是按比如时间范围来的但是这种一般较少用因为很容易产生热点问题大量的流量都打在最新的数据上了。或者是按照某个字段 hash 一下均匀分散这个较为常用。 range 来分好处在于说扩容的时候很简单因为你只要预备好给每个月都准备一个库就可以了到了一个新的月份的时候自然而然就会写新的库了缺点但是大部分的请求都是访问最新的数据。实际生产用 range要看场景。hash 分发好处在于说可以平均分配每个库的数据量和请求压力坏处在于说扩容起来比较麻烦会有一个数据迁移的过程之前的数据需要重新计算 hash 值重新分配到不同的库或表。
4. 分库分表时数据迁移方案
1. 停机迁移方案
先是app 挂个公告说 0 点到早上 6 点进行运维无法访问。接着到 0 点停机系统停掉没有流量写入了此时老的单库单表数据库静止了。然后使用之前得写好一个导数的一次性工具此时直接跑起来然后将单库单表的数据读出来写到分库分表里面去。导数完了之后修改系统的数据库连接配置啥的包括可能代码和 SQL 也许有修改那你就用最新的代码然后直接启动连到新的分库分表上去。验证一下ok了。但是这种方法的问题就是必须停机若一天没有迁移成功需要接连几天凌晨进行迁移
2. 双写迁移方案
这个是我们常用的一种迁移方案比较靠谱一些不用停机。简单来说就是在线上系统里面之前所有写库的地方增删改操作除了对老库增删改都加上对新库的增删改这就是所谓的双写同时对老库和新库写入。然后系统部署之后新库数据差太远使用导数工具跑起来读老库数据写新库写的时候要根据更新时间这类字段判断这条数据最后修改的时间除非是读出来的数据在新库里没有或者是比新库的数据新才会写。简单来说就是不允许用老数据覆盖新数据。导完一轮之后有可能数据还是存在不一致那么就程序自动做一轮校验比对新老库每个表的每条数据接着如果有不一样的就针对那些不一样的从老库读数据再次写。反复循环直到两个库每个表的数据都完全一致为止。最后将向老库写数据的代码删除重新部署一次就好了这种方式也不需要停机只需要导数工具在后台一直运行即可。
5. 如何设计可以动态扩容缩容的分库分表方案
对于分库分表来说主要是面对以下问题 选择一个数据库中间件调研、学习、测试设计你的分库分表的一个方案你要分成多少个库每个库分成多少个表比如 3 个库每个库 4 个表基于选择好的数据库中间件以及在测试环境建立好的分库分表的环境然后测试一下能否正常进行分库分表的读写完成单库单表到分库分表的迁移双写方案线上系统开始基于分库分表对外提供服务扩容了扩容成 6 个库每个库需要 12 个表你怎么来增加更多库和表呢
分库方案
设定好几台数据库服务器每台服务器上几个库每个库多少个表推荐是 32 库 * 32 表对于大部分公司来说可能几年都够了。路由的规则orderId % 32 库orderId / 32 % 32 表扩容的时候申请增加更多的数据库服务器装好 mysql呈倍数扩容4 台服务器扩到 8 台服务器再到 16 台服务器。由 dba 负责将原先数据库服务器的库迁移到新的数据库服务器上去库迁移是有一些便捷的工具的。我们这边就是修改一下配置调整迁移的库所在数据库服务器的地址。重新发布系统上线原先的路由规则变都不用变直接可以基于 n 倍的数据库服务器的资源继续进行线上系统的提供服务。
6. 分库分表之后id 主键如何处理
1. 基于数据库的实现方案 使用一个单独的库这个库不做分库分表就只有它一个此时当系统里每次得到一个 id都是往这个库的一个表里插入一条没什么业务含义的数据然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。 这个方案的好处就是方便简单谁都会用 缺点就是单库生成自增 id要是高并发的话就会有瓶颈的如果你硬是要改进一下那么就专门开一个服务出来这个服务每次就拿到当前 id 最大值然后自己递增几个 id一次性返回一批 id然后再把当前最大 id 值修改成递增几个 id 之后的一个值但是无论如何都是基于单个数据库。
2. UUID 好处就是本地生成不要基于数据库来了 不好之处就是 UUID 太长了、占用空间大作为主键性能太差了UUID 不具有有序性会导致 B 树索引在写的时候有过多的随机写操作连续的 ID 可以产生部分顺序写由于在写的时候不能产生有顺序的 append 操作而需要进行 insert 操作将会读取整个 B 树节点到内存在插入这条记录后会将整个节点写回磁盘这种操作在记录占用空间比较大的情况下性能下降明显。 适合的场景如果你是要随机生成个什么文件名、编号之类的你可以用 UUID但是作为主键是不能用 UUID 的。
3. snowflake 算法 snowflake 算法是 twitter 开源的分布式 id 生成算法采用 Scala 语言实现是把一个 64 位的 long 型的 id1 个 bit 是不用的用其中的 41 bit 作为毫秒数用 10 bit 作为工作机器 id12 bit 作为序列号。 0 | 0001 1001 0100 0101 0111 1101 0001 0010 1011 1000 0 | 1000 1 | 1100 1 | 0000 0000 0000 1 bit不用为啥呢因为二进制里第一个 bit 为如果是 1那么都是负数但是我们生成的 id 都是正数所以第一个 bit 统一都是 0。41 bit表示的是时间戳单位是毫秒。41 bit 可以表示的数字多达 241 - 1也就是可以标识 241 - 1 个毫秒值换算成年就是表示69年的时间。10 bit记录工作机器 id代表的是这个服务最多可以部署在 210台机器上哪也就是1024台机器。但是 10 bit 里 5 个 bit 代表机房 id5 个 bit 代表机器 id。意思就是最多代表 25个机房32个机房每个机房里可以代表 25 个机器32台机器。12 bit这个是用来记录同一个毫秒内产生的不同 id12 bit 可以代表的最大正整数是 212 - 1 4096也就是说可以用这个 12 bit 代表的数字来区分同一个毫秒内的 4096 个不同的 id。 Java 改写的雪花算法 public class IdWorker {private long workerId;private long datacenterId;private long sequence;public IdWorker(long workerId, long datacenterId, long sequence) {// sanity check for workerId// 这儿不就检查了一下要求就是你传递进来的机房id和机器id不能超过32不能小于0if (workerId maxWorkerId || workerId 0) {throw new IllegalArgumentException(String.format(worker Id cant be greater than %d or less than 0, maxWorkerId));}if (datacenterId maxDatacenterId || datacenterId 0) {throw new IllegalArgumentException(String.format(datacenter Id cant be greater than %d or less than 0, maxDatacenterId));}System.out.printf(worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d,timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);this.workerId workerId;this.datacenterId datacenterId;this.sequence sequence;}private long twepoch 1288834974657L;private long workerIdBits 5L;private long datacenterIdBits 5L;// 这个是二进制运算就是 5 bit最多只能有31个数字也就是说机器id最多只能是32以内private long maxWorkerId -1L ^ (-1L workerIdBits);// 这个是一个意思就是 5 bit最多只能有31个数字机房id最多只能是32以内private long maxDatacenterId -1L ^ (-1L datacenterIdBits);private long sequenceBits 12L;private long workerIdShift sequenceBits;private long datacenterIdShift sequenceBits workerIdBits;private long timestampLeftShift sequenceBits workerIdBits datacenterIdBits;private long sequenceMask -1L ^ (-1L sequenceBits);private long lastTimestamp -1L;public long getWorkerId() {return workerId;}public long getDatacenterId() {return datacenterId;}public long getTimestamp() {return System.currentTimeMillis();}public synchronized long nextId() {// 这儿就是获取当前时间戳单位是毫秒long timestamp timeGen();if (timestamp lastTimestamp) {System.err.printf(clock is moving backwards. Rejecting requests until %d., lastTimestamp);throw new RuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds, lastTimestamp - timestamp));}if (lastTimestamp timestamp) {// 这个意思是说一个毫秒内最多只能有4096个数字// 无论你传递多少进来这个位运算保证始终就是在4096这个范围内避免你自己传递个sequence超过了4096这个范围sequence (sequence 1) sequenceMask;if (sequence 0) {timestamp tilNextMillis(lastTimestamp);}} else {sequence 0;}// 这儿记录一下最近一次生成id的时间戳单位是毫秒lastTimestamp timestamp;// 这儿就是将时间戳左移放到 41 bit那儿// 将机房 id左移放到 5 bit那儿// 将机器id左移放到5 bit那儿将序号放最后12 bit// 最后拼接起来成一个 64 bit的二进制数字转换成 10 进制就是个 long 型return ((timestamp - twepoch) timestampLeftShift) | (datacenterId datacenterIdShift)| (workerId workerIdShift) | sequence;}private long tilNextMillis(long lastTimestamp) {long timestamp timeGen();while (timestamp lastTimestamp) {timestamp timeGen();}return timestamp;}private long timeGen() {return System.currentTimeMillis();}// ---------------测试---------------public static void main(String[] args) {IdWorker worker new IdWorker(1, 1, 1);for (int i 0; i 30; i) {System.out.println(worker.nextId());}}}大概这个意思吧就是说 41 bit 是当前毫秒单位的一个时间戳就这意思然后 5 bit 是你传递进来的一个机房 id但是最大只能是 32 以内另外 5 bit 是你传递进来的机器 id但是最大只能是 32 以内剩下的那个 12 bit序列号就是如果跟你上次生成 id 的时间还在一个毫秒内那么会把顺序给你累加最多在 4096 个序号以内。 所以你自己利用这个工具类自己搞一个服务然后对每个机房的每个机器都初始化这么一个东西刚开始这个机房的这个机器的序号就是 0。然后每次接收到一个请求说这个机房的这个机器要生成一个 id你就找到对应的 Worker 生成。 这个 snowflake 算法相对来说还是比较靠谱的所以你要真是搞分布式 id 生成如果是高并发啥的那么用这个应该性能比较好一般每秒几万并发的场景也足够你用了。
7. 如何实现 MySQL 的读写分离
其实很简单就是基于主从复制架构简单来说就搞一个主库挂多个从库然后我们就单单只是写主库然后主库会自动把数据给同步到从库上去。一个主库最多也就挂三五个从库就可以了再多也会影响到性能。
8. MySQL 主从复制原理的是啥 主库将变更写入 binlog 日志然后从库连接到主库之后从库有一个 IO 线程将主库的 binlog 日志拷贝到自己本地写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog然后回放 binlog 日志中的内容也就是在自己本地再次执行一遍 SQL这样就可以保证自己跟主库的数据是一样的。 这里有一个非常重要的一点就是从库同步主库数据的过程是串行化的也就是说主库上并行的操作在从库上会串行执行。所以这就是一个非常重要的点了由于从库从主库拷贝日志以及串行执行 SQL 的特点在高并发场景下从库的数据一定会比主库慢一些是有延时的。所以经常出现刚写入主库的数据可能是读不到的要过几十毫秒甚至几百毫秒才能读取到。 而且这里还有另外一个问题就是如果主库突然宕机然后恰好数据还没同步到从库那么有些数据可能在从库上是没有的有些数据可能就丢失了。 所以 MySQL 实际上在这一块有两个机制 一个是半同步复制用来解决主库数据丢失问题一个是并行复制用来解决主从同步延时问题。 半同步复制也叫 semi-sync 复制指的就是主库写入 binlog 日志之后就会将强制此时立即将数据同步到从库从库将日志写入自己本地的 relay log 之后接着会返回一个 ack 给主库主库接收到至少一个从库的 ack 之后才会认为写操作完成了。 并行复制指的是从库开启多个线程并行读取 relay log 中不同库的日志然后并行重放不同库的日志这是库级别的并行。
9. MySQL 主从同步延时问题 以前线上确实处理过因为主从同步延时问题而导致的线上的 bug属于小型的生产事故。 是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据再立马把它查出来然后更新这条数据。在生产环境高峰期写并发达到了 2000/s这个时候主从复制延时大概是在小几十毫秒。线上会发现每天总有那么一些数据我们期望更新一些重要的数据状态但在高峰期时候却没更新。 我们通过 MySQL 命令 show status查看 Seconds_Behind_Master可以看到从库复制主库的数据落后了几 ms。 一般来说如果主从延迟较为严重有以下解决方案 分库将一个主库拆分为多个主库每个主库的写并发就减少了几倍此时主从延迟可以忽略不计。打开 MySQL 支持的并行复制多个库并行复制。如果说某个库的写入并发就是特别高单库写并发达到了 2000/s并行复制还是没意义。重写代码写代码的同学要慎重插入数据时立马查询可能查不到。如果确实是存在必须先插入立马要求就查询到然后立马就要反过来执行一些操作对这个查询设置直连主库。不推荐这种方法你要是这么搞读写分离的意义就丧失了。
