网站建设的源代码有什么作用,网站维护包括哪些,wordpress添加,网站建设人员分工摘自#xff1a;Java技术栈一、数据库瓶颈不管是IO瓶颈#xff0c;还是CPU瓶颈#xff0c;最终都会导致数据库的活跃连接数增加#xff0c;进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是#xff0c;可用数据库连接少甚至无连接可用。接下来就可以…摘自Java技术栈一、数据库瓶颈不管是IO瓶颈还是CPU瓶颈最终都会导致数据库的活跃连接数增加进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。1、IO瓶颈第一种磁盘读IO瓶颈热点数据太多数据库缓存放不下每次查询时会产生大量的IO降低查询速度 - 分库和垂直分表。第二种网络IO瓶颈请求的数据太多网络带宽不够 - 分库。2、CPU瓶颈第一种SQL问题如SQL中包含joingroup byorder by非索引字段条件查询等增加CPU运算的操作 - SQL优化建立合适的索引在业务Service层进行业务计算。第二种单表数据量太大查询时扫描的行太多SQL效率低CPU率先出现瓶颈 - 水平分表。二、分库分表1、水平分库1.概念以字段为依据按照一定策略(hash、range等)将一个库中的数据拆分到多个库中。2.结果每个库的结构都一样;每个库的数据都不一样没有交集;所有库的并集是全量数据;3.场景系统绝对并发量上来了分表难以根本上解决问题并且还没有明显的业务归属来垂直分库。4.分析库多了io和cpu的压力自然可以成倍缓解。2、水平分表1.概念以字段为依据按照一定策略(hash、range等)将一个表中的数据拆分到多个表中。2.结果每个表的结构都一样每个表的数据都不一样没有交集;所有表的并集是全量数据;3.场景系统绝对并发量并没有上来只是单表的数据量太多影响了SQL效率加重了CPU负担以至于成为瓶颈。推荐阅读MySQL全面优化速度飞起来。4.分析表的数据量少了单次SQL执行效率高自然减轻了CPU的负担。3、垂直分库1.概念以表为依据按照业务归属不同将不同的表拆分到不同的库中。2.结果每个库的结构都不一样每个库的数据也不一样没有交集所有库的并集是全量数据3.场景系统绝对并发量上来了并且可以抽象出单独的业务模块。4.分析到这一步基本上就可以服务化了。例如随着业务的发展一些公用的配置表、字典表等越来越多这时可以将这些表拆到单独的库中甚至可以服务化。再有随着业务的发展孵化出了一套业务模式这时可以将相关的表拆到单独的库中甚至可以服务化。4、垂直分表1.概念以字段为依据按照字段的活跃性将表中字段拆到不同的表(主表和扩展表)中。2.结果每个表的结构都不一样每个表的数据也不一样一般来说每个表的字段至少有一列交集一般是主键用于关联数据所有表的并集是全量数据3.场景系统绝对并发量并没有上来表的记录并不多但是字段多并且热点数据和非热点数据在一起单行数据所需的存储空间较大。以至于数据库缓存的数据行减少查询时会去读磁盘数据产生大量的随机读IO产生IO瓶颈。4.分析可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来进而减少了随机读IO。拆了之后要想获得全部数据就需要关联两个表来取数据。但记住千万别用join因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据应该在业务Service层做文章分别获取主表和扩展表数据然后用关联字段关联得到全部数据。三、分库分表工具sharding-spherejar前身是sharding-jdbcTDDLjarTaobao Distribute Data LayerMycat中间件。注工具的利弊请自行调研官网和社区优先。四、分库分表步骤根据容量(当前容量和增长量)评估分库或分表个数 - 选key(均匀)- 分表规则(hash或range等)- 执行(一般双写)- 扩容问题(尽量减少数据的移动)。五、分库分表问题1、非partition key的查询问题(水平分库分表拆分策略为常用的hash法)端上除了partition key只有一个非partition key作为条件查询映射法基因法注写入时基因法生成userid如图。关于xbit基因例如要分8张表238故x取3即3bit基因。根据userid查询时可直接取模路由到对应的分库或分表。数据库怎么分库分表垂直水平这篇也可以看下。根据username查询时先通过usernamecode生成函数生成username_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。端上除了partition key不止一个非partition key作为条件查询映射法冗余法注按照orderid或buyerid查询时路由到dbobuyer库中按照sellerid查询时路由到dbo_seller库中。感觉有点本末倒置有其他好的办法吗改变技术栈呢后台除了partition key还有各种非partition key组合条件查询NoSQL法冗余法2、非partition key跨库跨表分页查询问题(水平分库分表拆分策略为常用的hash法)注用NoSQL法解决(ES等)。3、扩容问题(水平分库分表拆分策略为常用的hash法)1.水平扩容库(升级从库法)注扩容是成倍的。2.水平扩容表(双写迁移法)第一步(同步双写)应用配置双写部署第二步(同步双写)将老库中的老数据复制到新库中第三步(同步双写)以老库为准校对新库中的老数据第四步(同步双写)应用去掉双写部署注双写是通用方案。六、分库分表总结分库分表首先得知道瓶颈在哪里然后才能合理地拆分(分库还是分表水平还是垂直分几个)。且不可为了分库分表而拆分。选key很重要既要考虑到拆分均匀也要考虑到非partition key的查询。只要能满足需求拆分规则越简单越好。
