做移门配件的网站自己做的网站怎么放视频

做移门配件的网站,自己做的网站怎么放视频,网站建设_网站设计 app制作,滕州网站制作哪家好为什么需要分库分表 为什么要分库 分库主要解决的是并发量过⼤的问题#xff0c;因为并发量⼀旦上升了#xff0c;那么数据库就可能成为系统的瓶颈#xff0c;因为数据库的连接数量是有上限的#xff0c;虽然你可以进⾏调整#xff0c;但并不是⽆限调整的。所以#xff0…为什么需要分库分表为什么要分库分库主要解决的是并发量过⼤的问题因为并发量⼀旦上升了那么数据库就可能成为系统的瓶颈因为数据库的连接数量是有上限的虽然你可以进⾏调整但并不是⽆限调整的。所以当你的数据库的读或者写的 QPS 太⾼从⽽导致你的数据库连接数量不⾜的时候就需要考虑到分库了通过在增加数 据库实例的⽅式来提供更多的数据库连接从⽽提升系统的并发度。微服务架构出现就是为了应对高并发。它把订单、用户、商品等不同模块拆分成多个应用并且把单个数据库也拆分成多个不同功能模块的数据库订单库、用户库、商品库以分担读写压力。MySQL单机磁盘容量几乎称满。为什么分表分表主要解决的是数据量⼤的问题即通过将数据拆分到多个表减少单表的数据量 从⽽提升查询速度。一般B树层级是2-3层3层大概可以存放两千万左右的记录因此单表数据量超过千万就需要考虑分表啦。数据量过大解决方案阿里开发手册 单表行数超过500W或者单表数据容量超过2G● 分库分表● 冷热数据分离● 历史数据归档如何分库分表垂直拆分垂直分库可以按照系统中的不同业务进行拆分比如拆分成用户库、订单库、积分库、商品库把它们部署在不同的数据库服务器这就是垂直分库。垂直分表如果一个单表包含了几十列甚至上百列管理起来很混乱每次都select *的话还占用IO资源。这时候我们可以将一些不常用的、数据较大或者长度较长的列拆分到另外一张表。比如一张用户表它包含user_id、user_name、mobile_no、age、email、nickname、address、user_desc如果email、address、user_desc等字段不常用我们可以把它拆分到另外一张表命名为用户详细信息表。这就是垂直分表。水平拆分水平分库水平分库是指将表的数据量切分到不同的数据库服务器上每个服务器具有相同的库和表只是表中的数据集合不一样。它可以有效的缓解单机单库的性能瓶颈和压力。水平分表如果一个表的数据量太大可以按照某种规则如hash取模、range把数据切分到多张表去。一张订单表按时间range拆分如下水平分库分表策略分库分表策略一般有几种使用与不同的场景● range范围● hash取模● 一致性hash算法range范围range即范围策略划分表。比如我们可以将表的主键按照从0~1000万的划分为一个表1000 ~ 2000万划分到另外一个表。如下图当然有时候我们也可以按时间范围来划分如不同年月的订单放到不同的表它也是一种range的划分策略。这种方案的优点● 这种方案有利于扩容不需要数据迁移。假设数据量增加到5千万我们只需要水平增加一张表就好啦之前0~4000万的数据不需要迁移。缺点● 这种方案会有热点问题因为订单id是一直在增大的也就是说最近一段时间都是汇聚在一张表里面的。比如最近一个月的订单都在1000万~2000万之间平时用户一般都查最近一个月的订单比较多请求都打到order_1表啦这就导致表的数据热点问题。hash取模hash取模策略指定的路由key一般是user_id、订单id作为key对分表总数进行取模把数据分散到各个表中。比如原始订单表信息我们把它分成4张分表● 比如id1对4取模就会得到1就把它放到第1张表即t_order_0;● id3对4取模就会得到3就把它放到第3张表即t_order_2;这种方案的优点● hash取模的方式不会存在明显的热点问题。缺点● 如果一开始按照hash取模分成4个表了未来某个时候表数据量又到瓶颈了需要扩容这就比较棘手了。比如你从4张表又扩容成8张表那之前id5的数据是在5%41即第一张表现在应该放到5%85即第5张表也就是说历史数据要做迁移了。一致性哈希算法在节点的动态增加或者删除的时候尽可能减少数据迁移和重新分布的成本。实现一致性哈希算法首先需要构造一个哈希环然后把他划分为固定数量的虚拟节点一般都是。那么他的节点编号就是假设现在有4个表在一致性hash算法中取模不是直接对这4个表来完成而是对来实现。将4个表作为节点映射到这个环上。hash(表编号)%然后就把目标表和hash环关联起来了。当添加一个数据的时候同样通过hash和hash环取模得到一个值然后根据目标值所在的hash环的位置顺时针找到最近的一个目标表把数据存储到这个目标表中。当需要删除或者添加某个表时影响到的数据范围是局部的而不是全局。是这个表的节点到逆时针上一个表的节点中间的见会受影响。hash倾斜可能会存在目标表没有均匀分配到hash环中导致大量数据集中在一个表为了解决这个问题必须要保证目标节点要均匀的分布在整个hash环中但是真实的节点就只有4个可以 把这四个节点分别复制一份出来分散到这个hash环中这个复制出来的节点叫虚拟节点根据实际需要可以虚拟出多个节点出来 尽可能分散节点。分库分表的数量为什么一般选择2的幂● 可以位运算代替取模运算效率更高 hash%n hash(n-1)● 可以分的更加分散分库分表会导致哪些问题分库分表之后也会存在一些问题● 事务问题● 跨库关联● 排序问题● 分页问题● 分布式ID标题事务问题分库分表后假设两个表在不同的数据库那么本地事务已经无效啦需要使用分布式事务了。标题跨库关联跨节点Join的问题解决这一问题可以分两次查询实现标题排序问题跨节点的count,order by,group by以及聚合函数等问题可以分别在各个节点上得到结果后在应用程序端进行合并。分页问题当分的库不多的时候可以通过扫表的方式把多个库中的数据读出来在内存中进行排序和分页。当数据量大的时候可以通过下面的方法来实现shardingkey查询以订单为例买家的订单是查询最高频的以买家ID作为分片键就可以路由到单个库进行分页查询了非shardingkey查询如果不仅有买家查询还有卖家查询一般采用空间换时间的方式● 同步出一张按照卖家维度做分表的表一般使用canal基于bin log做自动同步虽然有秒级别的延迟一般业务上来说是可以接受的。● 还可以采用elasticSearch搜索引擎来满足复杂查询。标题分布式IDUUID可以做到全局唯一生成方式也简单但是通常不用它来做唯一ID因为UUID太长了字符串查询效率也比较慢UUID无序 每一次UUID数据的插入都 会对主键的b树进行很大的修改严重影响性能数据库自增方案在数据库中专门创建一张序列表利用数据库表中的自增ID来为其他业务的数据生成一个全局ID那么 每次要用ID的时候直接从这个表中获取即可。优点实现简单成本小ID单号自增可以实现有特殊要求的业务。缺点● 强依赖DB当DB异常时整个系统不可用属于致命问题。配置主从复制可以尽可能的增加可用 性但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。● ID发号性能瓶颈限制在单台MySQL的读写性能。标题雪花算法雪花算法具有全局唯一、递增、高可用特点。它的核⼼思想 就是将⼀个 64位的ID划分成多个部分每个部分都有不同的含义包括时间戳、数据中心标识、机器标识和序列号等⼀般来说雪花算法生成的 ID 有以下几个部分符号位1bit预留的符号位始终为0占⽤1位。时间戳41bit精确到毫秒级别41位的时间戳可以容纳的毫秒数是2的41次幂⼀年所使⽤的毫 秒数是365 * 24 * 60 * 60 * 1000算下来可以使⽤69年。数据中⼼标识5bit可以⽤来区分不同的数据中⼼。机器标识5bit可以⽤来区分不同的机器。序列号12bit)每个节点每毫秒 0 开始不断叠加最多可以叠加到 4095 因此其⼀共可以⽣成 4096个不同的序列号分库分表技术选型Sharding-JDBC定位为轻量级Java框架在Java的JDBC层提供的额外服务。 它使⽤客户端直连数据库以jar包形式提供服务⽆需额外部署和依赖可理解为增强版的JDBC驱动 。支持数据分片、分布式事务、读写分离、数据加密等。分布式事务基于XA和BASE的混合事务引擎。分库分表后的数据迁移分为三个阶段第一阶段新老库双写● 数据库表的双写老的数据库表和新的数据库表同步写入数据事务的成功以老的模型为准查询也走老的。● 通过定时任务对数据进行核对补平差异● 通过定时任务把历史数据迁移到新的模型中第二阶段以新的模型为准到了第二个阶段历史数据已经迁移完了数据校验也没有问题● 仍然保持双写但是事务的成功和查询都以新模型为准。● 定时任务进行数据核对补平差异数据第三阶段结束双写到了第三阶段说明数据已经全部迁移好了● 取消双写所有数据只保存到新的模型中老模型不需要写入新的数据● 如果仍有部分老业务依赖老模型要等到所有业务改造完成后再废弃老模型